Re: Time for a Revolution
On Fri, 14 Jul 2006 01:25:51 +0200, A. Pagaltzis [EMAIL PROTECTED] wrote: * chromatic [EMAIL PROTECTED] [2006-07-14 00:55]: Sure, but it's only one thing people need to remember. One thing is easier than N things, especially as N changes every time the core changes. Yes, I agree. Don’t get me wrong, I’m not saying Bundle::PerlPlus is a bad idea (though in adding a grain to the sandpile it *can* have a detrimental effect). I’m just saying that I don’t see how it will achieve the purpose for which you proposed it. Sure would be handy, but will hardly single-handedly rejuvenate Perl. I've been talking with someone who has to learn perl over and over again, because this poor person forgets the details because perl is not used on a daily basis. If I got it right, the wish that was expressed is more like the wish for an installer with a GUI. Let's assume YaST2 or so. The interface should be able to show package groups (Graphic, Development, Databases, Network, Math, ...) and squares to tick: I want this module installed. The install program should then automatically tick all the modules it needs to make the install happen. At this point the user should not want to know if it is *possible* that this module *can* be installed at all (at least that is what that user told me). e.g. DBD-Pg needs DBI, but there is no Postgres installed. I for one would shed no tear if CGI would be removed from the CORE, and I will bet that most of you would cheer if all formatting related stuff would be removed from the CORE, which I use heavily on a daily basis. We have to realize that one person's PerlPlus necessities are not the same as someone else's. We - as seasoned perl users/programmers - quite often assume too much, and think too technical in ways of things to be possible or not. That is not how our target audience perceives it. I hope I have expressed the conclusion of that chat correctly. But it *does* make sense to me. -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11, 11.23, SuSE 10.0, AIX 4.3 5.2, and Cygwin. http://qa.perl.org http://mirrors.develooper.com/hpux/ http://www.test-smoke.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: fetching module version from the command line
On Thu, 13 Jul 2006 19:36:52 -0400, Randy W. Sims [EMAIL PROTECTED] said: David Wheeler wrote: On Jul 13, 2006, at 05:56, Fergal Daly wrote: That's funny, it looks like I did put some code in to disable the END block if it's required rather than used. Turns out I did this to make MakeMaker happy, so MakeMaker does actually do a full require, Well, IIRC, both MakeMaker and Module::Build grep for the version line and eval that one line, but not the whole file. The CPAN indexer, OTOH, evals no code but just uses a regular expression search of the module file. Actually, I believe the CPAN indexer now uses META.yml whenever possible. That's correct. -- andreas
Re: Time for a Revolution
On Thursday 13 July 2006 23:37, H.Merijn Brand wrote: If I got it right, the wish that was expressed is more like the wish for an installer with a GUI. Nope, just for a nice, easily-installable bundle of modules that work around the unpleasant backwards compatibilities and warts of Perl 5. For example, I use SUPER a lot because it's completely silly that the method redispatcher works based on the stash of the subroutine, set to its compile time package, not on the current class and method name. I'm warming up to Class::MOP because I'm tired of fiddling with package variables and symbolic references to deal with @ISA. It would include a profiler that actually works, unlike Devel::DProf which, as far as I can tell, is a Perl module to segfault. It would include File::Find::Rule because it has an interface less prone to face-stabbing than File::Find, which is only in the core because it's been in the core forever, not because its interface is nice (it isn't) or the code is nice (it really isn't). It would include Class::Std or Object::InsideOut or one of those because it's about time Perl encouraged people to write classes that make sense. It would include documentation about which modules I chose and why and when to use them. That's what I want -- the useful modules that aren't in the core that do things that should have been in the language for the start but weren't. In other words, it's the modules I use all the time to be productive. Novices shouldn't have to spent eight years learning the language and the good modules the way I did to be productive. -- c
Re: Time for a Revolution
On Thu, 13 Jul 2006 23:52:02 -0700, chromatic [EMAIL PROTECTED] wrote: On Thursday 13 July 2006 23:37, H.Merijn Brand wrote: If I got it right, the wish that was expressed is more like the wish for an installer with a GUI. Nope, just for a nice, easily-installable bundle of modules that work around the unpleasant backwards compatibilities and warts of Perl 5. I was talking about the wish of the person I talked to. Not your wish :) But your exposition makes some things quite clear. For example, I use SUPER a lot because it's completely silly that the method redispatcher works based on the stash of the subroutine, set to its compile time package, not on the current class and method name. I'm warming up to Class::MOP because I'm tired of fiddling with package variables and symbolic references to deal with @ISA. It would include a profiler that actually works, unlike Devel::DProf which, as far as I can tell, is a Perl module to segfault. It would include File::Find::Rule because it has an interface less prone to face-stabbing than File::Find, which is only in the core because it's been in the core forever, not because its interface is nice (it isn't) or the code is nice (it really isn't). It would include Class::Std or Object::InsideOut or one of those because it's about time Perl encouraged people to write classes that make sense. It would include documentation about which modules I chose and why and when to use them. That's what I want -- the useful modules that aren't in the core that do things that should have been in the language for the start but weren't. In other words, it's the modules I use all the time to be productive. For *you* to be productive. For *me*, I would see all that as bloat. I *hate* OO programming. Not only in Perl. It is that DBI and Tk have no alternatives, so I have to do some OO, but it still does not feel like the FUN I get out of the other corners of the many perl features Novices shouldn't have to spent eight years learning the language and the good modules the way I did to be productive. What makes someone productive? They want to get the job done. If they only convert CVS to MS-Excel or vise-versa, they will never ever need all the things you mention. If they want to set up a simple web page with MySQL and DBI, they don't need it either. I cheer your plan. Really I do, but then there should be targetted bundles. Not 'Plus' or 'Extra'. What is Plus for one is Minus or Bloat for others. Look at the list of modules I include in my perl distributions for HP-UX at http://mirrors.develooper.com/hpux/#Perl and you might get an idea of what I think are useful modules that my work more effective. Not quite like yours is it? -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11, 11.23, SuSE 10.0, AIX 4.3 5.2, and Cygwin. http://qa.perl.org http://mirrors.develooper.com/hpux/ http://www.test-smoke.org http://www.goldmark.org/jeff/stupid-disclaimers/
Testing code that forks
Hi all, what is the current best practices for testing code that forks? I saw there was a recent discussion about patching Test::More to support forking. Is that going to happen or are there better ways to do it? Gabor
Re: Time for a Revolution
On Fri, 14 Jul 2006 07:45:55 -0400, Clayton O'Neill [EMAIL PROTECTED] wrote: Why off-list? this is a good reaction. On 7/14/06, H.Merijn Brand [EMAIL PROTECTED] wrote: Look at the list of modules I include in my perl distributions for HP-UX at http://mirrors.develooper.com/hpux/#Perl and you might get an idea of what I think are useful modules that my work more effective. Not quite like yours is it? I think a core difference between your list and Chromatic's is that yours would be part of the standard library in a lot of languages, whereas Chromatic seems to be aiming more for things that would be part of the language. Not to disparage your list, but I think his is oriented more towards higher level abstractions, whereas yours is more task oriented. Probably correct. Because of that, I don't really see the dichotomy as strongly as you. I think you can argue over which inside out object module to use, but that's a different sort of argument than whether or not XPath or SOAP support should be included in core, or some PerlPlus bundle. At least it seems that way to me. IMHO none of those should be included in the core at all. It should be made easier to *add* them after the core is installed. Either by a website or a GUI or whatever. Select the box OO programming choose functionality, tick all that apply, and hit [Install]. If that script/site calls 'curl ...' or 'perl -MCPAN ...' or frobnicator2 ...' is not of any interrest to me at this point. If I'm not mistaken, there has been a lot of effort to enable inside-out objects in perl-5.9 from the core side of view. So it is being appreciated that people want it. Not that I am likely to ever use it, but that is not being discussed here. -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11, 11.23, SuSE 10.0, AIX 4.3 5.2, and Cygwin. http://qa.perl.org http://mirrors.develooper.com/hpux/ http://www.test-smoke.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Time for a Revolution
chromatic wrote: Why is there not a Bundle::PerlPlus (and yes, I've lathered up my yak with that name) that downloads and installs the modules that should have been in the box? For one, that should be Task::PerlPlus. :-) Second, for any pre-packaged distribution like Strawberry Perl (see vanillaperl.com), adding in the must have modules is pretty easy. One of the goals of the Vanilla Perl project is to get win32 Perl to a point where we can offer an end-user Perl with all the best modules already installed. Unlike what others said, core perl shouldn't be the vehicle for this, most likely, given the more stringent support and backwards compatibility. We want to be able to change the composition of PerlPlus overtime, and once things go into core, they're pretty stuck. But I concur with others that that the issue is awareness and usage, not installation. We need an easily accessible way for people to learn that there are some best modules along with best practices. (And thank you, Damian, for encluding lots of module recommendations in that book.) One idea I had is that we need a new edition of the Perl Cookbook, with new recipes that cover not only how to use core built-ins and modules, but that highlight some of the best CPAN modules for certain tasks as well. Or, perhaps we need the Perl CPAN Cookbook -- which would be like the Cookbook but focuses *only* on the greatest-hits modules across all the same categories. If CPAN is one of Perl's greatest strengths, shouldn't that get more attention, too? Or, perhaps, to break up or both Cookbook into individual books covering certain topics in more depth. This might be good for O'Reilly's PDF book series -- low cost and easy to update over time. More generally, I think Perl needs to be focusing on how it helps people get stuff done faster/cheaper/better -- task focused, not tool focused -- and in areas where there is buzz and excitement. E.g. Writing AJAX applications in Perl. Regards, David
Re: CPANDB - was: Module::Dependency 1.84
* Tels [EMAIL PROTECTED] [2006-07-14 02:40]: announced to early - now everybody tells me how I have to implement it and why my way wont work You were saying Adam’s way is inferior to your way. I disagreed. That’s about the size of it. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Time for a Revolution
On Friday 14 July 2006 08:18, David Golden wrote: Or, perhaps we need the Perl CPAN Cookbook -- which would be like the Cookbook but focuses *only* on the greatest-hits modules across all the same categories. If CPAN is one of Perl's greatest strengths, shouldn't that get more attention, too? Or, perhaps, to break up or both Cookbook into individual books covering certain topics in more depth. This might be good for O'Reilly's PDF book series -- low cost and easy to update over time. More generally, I think Perl needs to be focusing on how it helps people get stuff done faster/cheaper/better -- task focused, not tool focused -- and in areas where there is buzz and excitement. E.g. Writing AJAX applications in Perl. Er, right. Now let me don my editor hat. Authors welcome! -- c
Re: Time for a Revolution
Or, perhaps we need the Perl CPAN Cookbook -- which would be like the Cookbook but focuses *only* on the greatest-hits modules across all the same categories. If CPAN is one of Perl's greatest strengths, shouldn't that get more attention, too? Er, right. Now let me don my editor hat. Authors welcome! A book like this is something that's been in the back of my mind for a while. If there were real interest in this topic (and I think there is), I would be happy to help out in a significant way, like writing several chapters. If someone is interested, maybe we can hash out a ToC / outline and submit a proposal to O'Reilly? That would be pretty neat :) Regards, Jonathan Rockway
Re: Time for a Revolution
On Friday 14 July 2006 12:27, Jonathan Rockway wrote: A book like this is something that's been in the back of my mind for a while. If there were real interest in this topic (and I think there is), I would be happy to help out in a significant way, like writing several chapters. If someone is interested, maybe we can hash out a ToC / outline and submit a proposal to O'Reilly? That would be pretty neat :) I should be more clear; I'm looking for 10-15,000 word short books on very specific areas -- XML Processing with Perl, Writing Ajax Applications with Perl, Refactoring Perl, et cetera. I'm not ruling out a book or discouraging people from submitting book ideas, just pointing out that it's much easier and faster to write and produce a short, focused manuscript than a large project. -- c
Re: Time for a Revolution
On 7/14/06, H.Merijn Brand [EMAIL PROTECTED] wrote: Look at the list of modules I include in my perl distributions for HP-UX at http://mirrors.develooper.com/hpux/#Perl and you might get an idea of what I think are useful modules that my work more effective. Not quite like yours is it? I think a core difference between your list and Chromatic's is that yours would be part of the standard library in a lot of languages, whereas Chromatic seems to be aiming more for things that would be part of the language. Not to disparage your list, but I think his is oriented more towards higher level abstractions, whereas yours is more task oriented. Because of that, I don't really see the dichotomy as strongly as you. I think you can argue over which inside out object module to use, but that's a different sort of argument than whether or not XPath or SOAP support should be included in core, or some PerlPlus bundle. At least it seems that way to me.
Re: Time for a Revolution
--- Clayton O'Neill wrote: I think a core difference between your list and Chromatic's is that yours would be part of the standard library in a lot of languages, whereas Chromatic seems to be aiming more for things that would be part of the language. Who's Chromatic? /-\ On Yahoo!7 Messenger - Make free PC-to-PC calls to your friends overseas. http://au.messenger.yahoo.com
Re: Time for a Revolution
On Sat, Jul 15, 2006 at 08:36:54AM +1000, Andrew Savige wrote: --- Clayton O'Neill wrote: I think a core difference between your list and Chromatic's is that yours would be part of the standard library in a lot of languages, whereas Chromatic seems to be aiming more for things that would be part of the language. Who's Chromatic? And it wasn't even the start of a sentence. :-) [When doing the perl 6 summaries, Piers reconciled the forces of accuracy and traditional grammar by ensuring by always rephrasing to some sentence order that didn't start with chromatic] Nicholas Clark
Re: Time for a Revolution
--- Nicholas Clark wrote: On Sat, Jul 15, 2006 at 08:36:54AM +1000, Andrew Savige wrote: Who's Chromatic? And it wasn't even the start of a sentence. :-) [When doing the perl 6 summaries, Piers reconciled the forces of accuracy and traditional grammar by ensuring by always rephrasing to some sentence order that didn't start with chromatic] I thought Chromatic might be the name of chromatic's father or older brother. /-\ On Yahoo!7 Messenger - Make free PC-to-PC calls to your friends overseas. http://au.messenger.yahoo.com
Re: Time for a Revolution
On Friday 14 July 2006 17:59, Andrew Savige wrote: I thought Chromatic might be the name of chromatic's father or older brother. No, that's Mixolydian and Ionian, respectively. -- c (Yes, of course my mother is Dorian. What were you thinking?)
Re: Time for a Revolution
On Jul 14, 2006, at 8:03 PM, chromatic wrote: On Friday 14 July 2006 17:59, Andrew Savige wrote: I thought Chromatic might be the name of chromatic's father or older brother. No, that's Mixolydian and Ionian, respectively. -- c (Yes, of course my mother is Dorian. What were you thinking?) Whoa, this is becoming an unexpectedly educational thread... Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: TAP diagnostic syntax proposal
To summarize. What TAP uses is irrelevant, as long as it works. What the Harness prints is relevant, but easy to fix any time. No worries about TAP 1.0 vs. TAP 1.1, just download the new Test:Harness from CPAN and everything will work. Right? Wrong. Well, maybe... Sometimes it could be yes, sometimes it could be no. Tool chain bootstrapping and back compatibility is an extremely finicky and often misunderstood area, and things are very very often much more complicated than it may seem. In general, the best optimization seems to be to think MORE up front, and release as complete implementations as possible, as few times as possible. This at least minimizes the surface area of the of the problem, and limits the number of annoying corner cases that can appear. Adam K
Re: Time for a Revolution
Unlike what others said, core perl shouldn't be the vehicle for this, most likely, given the more stringent support and backwards compatibility. We want to be able to change the composition of PerlPlus overtime, and once things go into core, they're pretty stuck. I should note for the record that the concept of core has only about 6 months left to live. I had a chat with Larry at the YAPC hackfest about solving this problem more thoroughly for Perl 6 (and back-porting the solution to Perl 5), and I think we are in agreement. So I'll be dealing with this general area (core, preferred sets of modules) starting with perlmodlib and working outwards, in about a month when my main work project is slowing a bit and I have more than just a spare 10 minutes to reply to mailing lists. Adam K
Re: CPANDB - was: Module::Dependency 1.84
Plus, I planned to use YAML because it creates a _much_ less heavy overhead and dependency chain. Using SQLite or similiar is what really creates the problems with CPANTS - you cant just access the raw database without the front-end. Erm, I'm not sure I get you here. The main problem with all the things that loads the index currently is that they tend to consume 50-100 meg of ram, and that's just the active index. Add in extra stuff and you're up into stupid amounts of ram quite quickly. I am not sure what stupid consists, but my system wouldn't have problems handling 512 MB of memory. OTOH, if the raw data in memory is like 100 Megabyte, then where does all the data come from? The CPAN index is surely not 100 Megabyte, right? Raw data inflates into memory, once you factor in Perl's overheads. CPAN.pm uses about 50meg to do it, CPANPLUS used to use about 80meg, although kane has pulled that back a bit now I believe. And while doing this temporarily for the purposes of installing a module might be fine, I have use cases in mind like running a CPAN index inside a Perl editor. And it would most certainly be stupid if your editor uses 250 meg of RAM. It's already necesary, based on the memory load. That's not to say you have to use SQLite to DISTRIBUTE or publish the data, just that when you access and manipulate it computationally, you do it via SQLite. Well, I guess you have more experience on that than I have. I would have tried without it first. This method has worked spectacularly well in the JSAN code, which What is JSAN? implements something very similar to what I'm heading towards. Er, so why aren't you using what JSAN is? *confused* JSAN is the JavaScript Archive Network, the port of CPAN for JavaScript. The implementation was a nice chance to blow away all the CPAN cruft and try some new ideas out, without having to care about back-compatibility. Although I'm reusing the same techniques (SQLite + ORM layer) for CPAN::Index, I can't reuse the code directly, because there are different language concepts involved, so the XPAN client for each needs to work differently as a result. To do dependencies and so on, it just links an Algorithm::Dependency object Another dependency to find out what the dependency is. I know you don't like dependencies, but your choices come down to dependency or reimplementation, if you want some feature. And as long as the dependency has 100% platform support and never fails to install, it isn't a problem. The reason CPAN is in the current situation of dependency == bad is primarily (but not exclusively) that many modules fail on various edge cases, and those edge cases have combined effect. Throw in dependency recursion and unless you are paranoid about the things you depend on being clean, you run into trouble. Nobody would care about dependencies if they never failed (except for the issue of installation time). The bit that isn't finished is the complete grab your CPAN.pm config and stream down all the files and populate the database. I see you have don muchmuch more work and given it much much more though, so I better just shut my mouth, throw my silly alittle attempt at yet-another-wheel into the dustbin and go away. :-/ Good luck with CPAN::Index. I'm all for more wheels, I'm just pointing out some issues you might run into. And if yours exists and mine doesn't, well yours is far better than mine. Adam K
Re: CPANDB - was: Module::Dependency 1.84
A. Pagaltzis wrote: * Tels [EMAIL PROTECTED] [2006-07-14 02:40]: announced to early - now everybody tells me how I have to implement it and why my way wont work You were saying Adam’s way is inferior to your way. I disagreed. That’s about the size of it. I agree my way is inferior, especially on a couple of axis like lightness. The most value you can get from these lists is to treat them as an expert panel. If you put up come idea, people will try to tear it apart, and present you with problems you may not have considered. Despite the particular wording of any given conversation, that is almost never to say you SHOULDN'T do it. Just that if you want to do some problem, there's people that know the problems you are going to face. And you want to know these things now, before you get going, so you can address them YOURSELF and prove to yourself if they are or not a problem for you. Adam K
Re: Time for a Revolution
Adam Kennedy wrote: Unlike what others said, core perl shouldn't be the vehicle for this, most likely, given the more stringent support and backwards compatibility. We want to be able to change the composition of PerlPlus overtime, and once things go into core, they're pretty stuck. I should note for the record that the concept of core has only about 6 months left to live. I had a chat with Larry at the YAPC hackfest about solving this problem more thoroughly for Perl 6 (and back-porting the solution to Perl 5), and I think we are in agreement. So I'll be dealing with this general area (core, preferred sets of modules) starting with perlmodlib and working outwards, in about a month when my main work project is slowing a bit and I have more than just a spare 10 minutes to reply to mailing lists. Why? Oh, why do people lately insist on offering up enticing tidbits of /what is to be the next great ordained (core|6pan|etc)/ without offering the community a chance to comment or participate? =( Randy.
