what's a good name for a pure-perl OnScopeExit mechanism?
local_onExit is how it is now http://davidnicol.diaryland.com/onExit.html The semantics should be exactly the same as Scope::OnExit, but the syntax is somewhat convoluted, abusing the Clocal mechanism as it does. Scope::OnExit::PurePerl would seem to imply the same syntax, which would be misleading. -- question doubt
Re: Trimming the CPAN - Automatic Purging
On Tue, Mar 30, 2010 at 10:08:57PM +0200, Rene Schickbauer wrote: Now, if we where to put all files into mercurial, git or the like, renaming the files so they don't have version numbers in their names but storing them sequentially as commits so new versions update old ones. Sort of like Schwern already did? http://github.com/gitpan Nicholas Clark
Re: Trimming the CPAN - Automatic Purging
Nicholas Clark wrote: On Tue, Mar 30, 2010 at 10:08:57PM +0200, Rene Schickbauer wrote: Now, if we where to put all files into mercurial, git or the like, renaming the files so they don't have version numbers in their names but storing them sequentially as commits so new versions update old ones. Sort of like Schwern already did? http://github.com/gitpan Yeah, looks about right at first glance. Didn't know that one, definitively have to look into this a bit more ;-) LG Rene
Re: Trimming the CPAN - Automatic Purging
David Nicol wrote: On Sun, Mar 28, 2010 at 2:32 PM, Elaine Ashton eash...@mac.com wrote: On Mar 28, 2010, at 12:48 PM, Randy Kobes wrote: Has some sort of disk quota system for CPAN author accounts ever been considered? Not specifically, no, at least not that I'm aware of. That would have to be implemented on PAUSE and quotas frequently end up not solving the real problem and create a headache both for the sysadmin and the users. new proposal: Make modules pay rent in order to remain on a mirror. Rent could be in the form of actual user interest, or good reviews. Hmm, this can *only* work as long as that model is not applied to the main server: Just because a module is seldomly used doesn't automatically mean it is not vital to *someone*. Modules that might fit into this category are many Acme modules. For example, i use Acme::Don't sometimes, cause it's better better for temporarly commenting out code sections than if(0) LG Rene
Re: Trimming the CPAN - Automatic Purging
Arthur your ignorance is apalling Go look at what ORCA does SAR doesn't give you the info With ORCA i have any thing from kstat or iostat. It goes into roundrobin database with rrdtool. Procallaotr does for linux what orcallator does for solaris where it is the standard performance toool --Original Message-- From: Arthur Corliss To: Dana Hudes Cc: module-authors@perl.org Sent: Mar 29, 2010 1:12 PM Subject: Re: Trimming the CPAN - Automatic Purging On Mon, 29 Mar 2010, Dana Hudes wrote: Orcallator, procallator and friends aren't shiny new toys Adrian Cockroft wrote initial version of orcallator in the early 90s for his book Solaris Performance Tuning. The 2nd edition is I think 1998. The current version of ORCA (processes the collected data) is from I believe 2007 or so www.orcaware.org i think it was I was being facetious. Your immediate dismissal of SAR is ill-advised. I'm wearing my abestos-lined boxers, so I'll lob this little inflammatory gem out there: if you're running a server (especially in production) and you're *not* running SAR, you're a freaking idiot. Profiling individual programs is all well and good for occasional or developer use, but the point of SAR is to give you a global view into the health of your system and to identify architectural bottlenecks. I think it would be greatly entertaining for Elaine or any of the other mirror operators to post their SAR reports so you guys can see the huge amount of abuse being heaped on their servers. SAR is debatably one of the lowest overhead methods of gaining that macroscopic view, and it still has profiling value on development systems when you're testing a specific workload. To ignore SAR is to show zero competence as a sys-admin. --Arthur Corliss Live Free or Die Sent from my BlackBerry® smartphone with Nextel Direct Connect
Re: Trimming the CPAN - Automatic Purging
I've said nothing till now, because I figured more noise wouldn't help much. But I quite like the rsync daemon/proxy idea, and as it so happens I'm attending the OzLabs Unconference in 3 weeks time to hang out with Tridge, Rusty and the other Australia C/Kernel/Samba/RSync elites. So I'd be happy to raise any issues or ideas in this area with them in person over beers. Adam K On Sun, Mar 28, 2010 at 7:08 PM, Eric Wilhelm enoba...@gmail.com wrote: Or even write an rsync daemon (or proxy perhaps) in Perl. So, when the client asks for a file, you can answer without checking the disk. Can something like that work with an unmodified client, or does the amount of data needed to answer a naive client overwhelm any potential gain? Unfortunately the protocol is not formally documented and the perl code I've seen (File::RsyncP) seems to be lagging:
Re: Trimming the CPAN - Automatic Purging
On Wed, Mar 31, 2010 at 01:03:51PM +1100, Adam Kennedy wrote: I've said nothing till now, because I figured more noise wouldn't help much. But I quite like the rsync daemon/proxy idea, and as it so happens I'm attending the OzLabs Unconference in 3 weeks time to hang out with Tridge, Rusty and the other Australia C/Kernel/Samba/RSync elites. So I'd be happy to raise any issues or ideas in this area with them in person over beers. I can see two possibly useful things (and I have no idea if either is yet possible, or a great understanding of how the protocol works) 1: stateful rsync daemon which doesn't scan all the time, either by a: Actually having a means to update b: Simply telling fibs, and pretending that the file system it scanned $n minutes ago is still current. (Which I think would work, at least for a mirror where files aren't edited (much) - if the server discovers that the client's view of that file *is* out of date, then scan that file for real, and give the up to date truth) 2: federated (or federate-able) server (or proxy) - so that you can say hand this subtree off to that other server This would allow the (fast, existing, C) rsync server to serve most of (say) funet.fi, handing off to a stateful server for the CPAN subtree. Nicholas Clark
Re: Trimming the CPAN - Automatic Purging
On Wed, Mar 31, 2010 at 10:45 AM, David Landgren da...@landgren.net wrote: On 31/03/2010 06:52, David Nicol wrote: new proposal: Make modules pay rent in order to remain on a mirror. Rent could be in the form of actual user interest, or good reviews. Use as a dependency could count as rent. Put a value tag on things and people will game the system to ensure their files are up on top. Doomed to failure. I'm not suggesting that there be any kind of who-is-on-top game, the game is who falls out the bottom. If someone cares enough to want to game the system to ensure their files don't fall out, those files will surely stay. pay rent here is intended to mean something like tracking usage over a long period in order to authoritatively identify old and useless based on metrics and a policy. Especially combined with a Dnews-like trick file server that's really a cache and only stores things people actually ask it for, which responds to the OP's pain as I understand it, which is a frustration that their CPAN mirror contains a lot of cruft. Although it still isn't clear why that is a problem. Purpose-based partitioning could be performed like deferred sidewalks: put the pavement where the students make the trails in the grass.
Re: Tidy up your PAUSE directories
On Tue, Mar 30, 2010 at 05:09:53PM +0200, Rene Schickbauer wrote: brian d foy wrote: It's time for Spring cleaning again. If you have ancient versions of modules sitting around in your PAUSE directory, consider letting them retire to BackPAN (http://backpan.cpan.org). They don't disappear from the world, but they don't inflate CPAN either. You don't have to do anything, but many mirror operators might be happy that you did. :) Just my one point nine periodic cents: If you got ancient modules sitting around that you wont be updating anymore be good and ask around if someone wants to take over. It would be handy if there was a way for authors to indicate that new maintainers are sought. Perhaps via the META.yaml/(.json) file. Tim. If the module is simple enough (and possibly an Acme module), you could also ask in beginners: Maintaining a simple module with an existing user base is in my opinion a good learning experience! LG Rene Note: I've taken over three Acme-modules. Among them is Acme-AutoColor. If you lack any non-standard colors (i just added octarine), more features or something like that, just mail me. The other two, Acme::Innuendo and Acme::Mobile::Therbligs need updating too (working on it), ideas are welcome as well.
