Re: [Fink-devel] Fink module documentation, tests and all that icky stuff.
Am Donnerstag, 30.10.03 um 22:41 Uhr schrieb Michael G Schwern: [...] At this point I need some help normalizing the Fink build system. There's no Makefile or anything like that. I can't build and run the fink program without going through the whole interactive bootstrap.pl. That's not true. Look at inject.pl (which is also mentioned in INSTALL and on our homepage). There's no where to put a test target to make the tests easy to run. Thoughts? You could add a Makefile just for that. It could also have a simple install target which just invokes inject.pl Cheers, Max --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Fink module documentation, tests and all that icky stuff.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Michael G Schwern said the following on 10/30/03 2:36 AM: snip I'd like to keep going, but there's been no motion on any of the above. So... are you folks interested in testing and documenting Fink::*? Would you like me to continue? Hello Mister Schwern, my name is david Höhn (net alias Darian Lanx) and I am somewhat looking after the administrativa for Fink. I would be very glad to have you on board, since documentation and proper testing of the actual fink engine is something that we badly lack. There has been some great efforts by Mister Hansen and Mister Fujinaka to keep the man-pages and User documentation as well as the FAQ up-to date, yet the developer documentation for the code that fink intself user is nearly non existant. If you would like to continue this important work, I would be more than happy to setup a roadmap of your goals and sync them with the Fink team, being your proxy. As Mister Reed said, we are very interested in additional patches to further improve fink and I am sure that you could be added to the development team as soon as the main developers know how you work and how you could improve Fink as a whole. On a related note: how important is backwards compatibility? Some of the Fink::* function interfaces are a bit wonky and could do with some fixing. For example, the tendency for classes to export functions. Lots of exported global variables where class methods should be used. Exported global variables not being distinguished from local variables with $Uppercase. Inconsistent method names (new_with_* vs new_from_*). All basic stuff. According to some including perl guru Mister Schwartz the classes and their model could use some work. Maybe even redoing them with something like Class::MethodMaker. If you feel, that you have the time to improve the handling of that and thus improve fin itself, please do so. Are you worried someone other than fink is using this code and do you care? I would say, that this is not really a concern we are currently looking at, yet it is important, especially to me, that we keeo the documentation availaible that someone COULD do so if they wanted to. Can I go ahead and supply patches that will improve and change the module interface? As I said above, yes of course. According to some it is bitterly needed. Furthermore the Dependency enhone seems to need a reqrite, yet no one is willing to touch it. Do you want to ? Thank you for your efforts - -d -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/oPzyiW/Ta/pxHPQRAxbrAKDS1QsN03oZ3f6Bg0GJuMHeVvfJDwCgjIwq aA2smvQS2NPZegTyyGRIK6A=RB8f -END PGP SIGNATURE- --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Fink module documentation, tests and all that icky stuff.
D. Höhn wrote: If you would like to continue this important work, I would be more than happy to setup a roadmap of your goals and sync them with the Fink team, being your proxy. As Mister Reed said, we are very interested in additional patches to further improve fink and I am sure that you could be added to the development team as soon as the main developers know how you work and how you could improve Fink as a whole. We added Michael to the fink developer team this afternoon (JST), and told him to go nuts in HEAD after he promised not to break anything.:) Should've followed up this thread to let everyone know, sorry. Peter --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Fink module documentation, tests and all that icky stuff.
On Oct 30, 2003, at 06:58, D. Höhn wrote: As I said above, yes of course. According to some it is bitterly needed. Furthermore the Dependency enhone seems to need a reqrite, yet no one is willing to touch it. Do you want to ? I have started a project on sourceforge (libfinch.sourceforge.net), with the end goal of creating a drop in replacement dependency engine, perhaps even something we could patch into dpkg. If anyone is interested in helping, please email me off-list and I will describe the architecture more. Cheers, Kyle Moffett --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Fink module documentation, tests and all that icky stuff.
On Thu, Oct 30, 2003 at 09:20:12PM +0900, Peter O'Gorman wrote: If you would like to continue this important work, I would be more than happy to setup a roadmap of your goals and sync them with the Fink team, being your proxy. As Mister Reed said, we are very interested in additional patches to further improve fink and I am sure that you could be added to the development team as soon as the main developers know how you work and how you could improve Fink as a whole. We added Michael to the fink developer team this afternoon (JST), and told him to go nuts in HEAD after he promised not to break anything.:) I talked with the folks on #fink about backwards compatibility a bit. Fink Commander seems to be the concern, they don't know if its using any internal Fink function calls. I guess I could just look... (ironicly there seems to be no fink commander fink package.) Yeah, its using a few mercifully sane methods and functions of Fink::Services and Fink::Package. For the moment I'll treat the existing interface as sacred as well as I can (it being undocumented and all) and put things through a normal deprecation cycle. For example, I'd like to change the tendency for modules to export $lower_cased_globals. They should instead be using $Upper_Cased_Globals to distinguish them, or Class-methods. But I'll preserve the old $lower_cased_globals as deprecated and we'll sweep them away some time in the future. So my plan, at the moment, is to get myself familiar with the Fink internals and to get everyone else familiar with this whole testing thing. That's why I'm starting with the simple modules like Fink::Base and Fink::Config. Small enough that I can get my head around them. Important enough that I can show that I won't break anything with all this refactoring stuff. I don't plan on doing anything radical like switching to Class::MethodMaker. There's really not much payoff at this point. There's plenty of much more conventional cleanup to be done. At this point I need some help normalizing the Fink build system. There's no Makefile or anything like that. I can't build and run the fink program without going through the whole interactive bootstrap.pl. There's no where to put a test target to make the tests easy to run. Thoughts? But again, I don't want this to sidetrack folks from getting fink working on 10.3. You've been running fine without docs and tests for a while now, it can wait a few more weeks until 10.3 settles down. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ IMHO bugs in Perl 5 shouldn't carry over to Perl 6. (Unless, of course, we *like* the bugs... ;) -- Ken Fox in [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Fink module documentation, tests and all that icky stuff.
On Thu, Oct 30, 2003 at 12:58:37PM +0100, D. Höhn wrote: If you would like to continue this important work, I would be more than happy to setup a roadmap of your goals and sync them with the Fink team, being your proxy. Sure, I'd like to see such a roadmap to get an idea of what parts of fink are most critical. I'll probably also have a look at some CVS statistics to see what parts of the code you guys tend to touch most often and focus on that. Can I go ahead and supply patches that will improve and change the module interface? As I said above, yes of course. According to some it is bitterly needed. Furthermore the Dependency enhone seems to need a reqrite, yet no one is willing to touch it. Do you want to ? Maybe after I understand fink a bit better. However, RR pointed out that horrid $item-[3] stuff. I should be able to at least convert that to a hash or if nothing else, $item-[NAME] to make it a little more easier to read. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Do not try comedy at home! Milk Cheese are advanced experts! Attempts at comedy can be dangerously unfunny! --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Fink module documentation, tests and all that icky stuff.
Michael G Schwern wrote: On Thu, Oct 30, 2003 at 12:58:37PM +0100, D. Höhn wrote: If you would like to continue this important work, I would be more than happy to setup a roadmap of your goals and sync them with the Fink team, being your proxy. Sure, I'd like to see such a roadmap to get an idea of what parts of fink are most critical. I'll probably also have a look at some CVS statistics to see what parts of the code you guys tend to touch most often and focus on that. I don't know that we need someone to manage sync'ing that kind of thing between just a few people; generally discussion can happen on irc (although policy decisions or large changes should always at least go here, and probably fink-core@ as well). I do, however, think it would be great to have a roadmap just for keeping people appraised of what's going on in general, and hopefully making Fink development a bit more transparent and encourage more people to help. I notice that the recent flurry of development has actually prompted others not on the core team to start working on Fink and I think that's wonderful! Anything we can do to get the word out to the people that they can help make fink better is a good thing, and that's definitely your area of expertise, David. =) Traditionally, the fink code has been a black box that even the core team has inherited, so many of the original intentions are not known to us. =) Anything that can make it easier for us to understand and work on, much less others, is great. As I said above, yes of course. According to some it is bitterly needed. Furthermore the Dependency enhone seems to need a reqrite, yet no one is willing to touch it. Do you want to ? Maybe after I understand fink a bit better. However, RR pointed out that horrid $item-[3] stuff. I should be able to at least convert that to a hash or if nothing else, $item-[NAME] to make it a little more easier to read. Yeah. Even in my tinkering, switching to constants made it so much easier to understand. Moving that to a hash would be even better. Be aware that $item-[] is being overloaded to contain deps too, so it will probably take something more than simply replacing stuff. It needs to be done though, the current engine is working, but is so difficult to read, much less understand, that no one wants to work on it. -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ gpg: 6401 D02A A35F 55E9 D7DD 71C5 52EF A366 D3F6 65FE Just try to imagine a world where e-mails are sent by your brain before they are written, and are ready before they arrive by people you have never even met in countries you have never even heard of! pgp0.pgp Description: PGP signature
[Fink-devel] Fink module documentation, tests and all that icky stuff.
So I've started tearing into the fink module sources. This start out with little optimization attempts to make fink list run a little faster. http://sourceforge.net/tracker/index.php?func=detailaid=825801group_id=17203atid=317203 While doing that I got my hands dirty with the fink module sources and also wrote some ad hoc tests for the functions I was touching to make sure I didn't break anything while optimizing. After that I decided to dig into documenting, testing and cleanup up the code wholesale. The first step was to package up the basic Perl testing tools: http://sourceforge.net/tracker/index.php?func=detailaid=831197group_id=17203atid=414256 http://sourceforge.net/tracker/index.php?func=detailaid=831209group_id=17203atid=414256 And then pick a basic module and test it. Fink::Config seemed a good place to start. http://sourceforge.net/tracker/index.php?func=detailaid=831614group_id=17203atid=317203 And now that I've tested it and know how it works, I can document it and cleanup some of the messiest bits. http://sourceforge.net/tracker/index.php?func=detailaid=832063group_id=17203atid=317203 I'd like to keep going, but there's been no motion on any of the above. So... are you folks interested in testing and documenting Fink::*? Would you like me to continue? On a related note: how important is backwards compatibility? Some of the Fink::* function interfaces are a bit wonky and could do with some fixing. For example, the tendency for classes to export functions. Lots of exported global variables where class methods should be used. Exported global variables not being distinguished from local variables with $Uppercase. Inconsistent method names (new_with_* vs new_from_*). All basic stuff. Are you worried someone other than fink is using this code and do you care? Can I go ahead and supply patches that will improve and change the module interface? -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ 1. It Has To Work. -- RFC 1925 --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Fink module documentation, tests and all that icky stuff.
Michael G Schwern wrote: After that I decided to dig into documenting, testing and cleanup up the code wholesale. The first step was to package up the basic Perl testing tools: http://sourceforge.net/tracker/index.php?func=detailaid=831197group_id=17203atid=414256 http://sourceforge.net/tracker/index.php?func=detailaid=831209group_id=17203atid=414256 And then pick a basic module and test it. Fink::Config seemed a good place to start. http://sourceforge.net/tracker/index.php?func=detailaid=831614group_id=17203atid=317203 And now that I've tested it and know how it works, I can document it and cleanup some of the messiest bits. http://sourceforge.net/tracker/index.php?func=detailaid=832063group_id=17203atid=317203 Awesome! I'd like to keep going, but there's been no motion on any of the above. So... are you folks interested in testing and documenting Fink::*? Would you like me to continue? Most definitely. I'll look into your changes tonight and work on merging them. I'm sorry we didn't get to it sooner but everyone's been deep in getting our heads above water in the 10.2-gcc3.3 upgrade and 10.3 upgrade (despite the fact that testing things might have made that easier ;) On a related note: how important is backwards compatibility? Some of the Fink::* function interfaces are a bit wonky and could do with some fixing. For example, the tendency for classes to export functions. Lots of exported global variables where class methods should be used. Exported global variables not being distinguished from local variables with $Uppercase. Inconsistent method names (new_with_* vs new_from_*). All basic stuff. There's very little external code that uses such things; as long as fink itself is internally consistent, and we fix the stuff in the scripts and fix-fink modules accordingly, we should be pretty safe. I don't know if they use any of our bits directly, but we'd best notify the fink commander people of the changes as well, if we're going to break the API. I agree it's very messy, and I've wanted to rewrite it for some time, but making things pretty is lower priority than most of the other things we've been busy with for the past 6 months. Only recently, in preparation for all of our tree changes, has the codebase moved in any significant way. Are you worried someone other than fink is using this code and do you care? Can I go ahead and supply patches that will improve and change the module interface? I'm for it. If you do have such patches, make it clear when you submit them and I'll put them on a branch so we can test and notify people that it's changing. -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ gpg: 6401 D02A A35F 55E9 D7DD 71C5 52EF A366 D3F6 65FE You CAN'T clean the toilet, Neil, it'll lose all it's character! -- Vyvyan pgp0.pgp Description: PGP signature
