Re: avoid running CPAN as root

While the idea of using sudo only at install time is nice, there are two problems: 1. Some modules require extra privileges at test time 2. Far more impact is that sudo requires that you enter your password each time you invoke it. Therefore you will have to enter your password once for each modul

Re: Trimming the CPAN - "Automatic Purging"

The entire point of rsync is to send only changes. Therefore once your mirror initially syncs the old versions of modules is not the issue. Indeed, removing the old versions would present additional burden on synchronization! The ongoing burden is the ever-growing CPAN. The danger in a CPAN::Mini

Re: Using a better compression than .gz for one's CPAN modules

The savings for going to .bz2 over .gz for source code are fairly insignificant. We're talking about source code for a perl module. Is your stuff tens of megabytes in size? That's a lot of code if so. I could understand if you were distributing a sizable database with your code but source code, e

Re: Using a better compression than .gz for one's CPAN modules

>> source code, even 100KLOC? Once you go to .gz you're already at better >> than 2:1. What are you going to save by going to even 3:1, 10Kbytes? >> compared to the nuisance inflicted, it's nothing. > > Over the entire CPAN archive, it'd be significant... > > I agree on the individual case it's pro

Re: The future of Graph::Easy

In terms of considering parser improvements or reimplementation, the first step is to come up with a formal grammar for the language. Preferably a Context Free Grammar (CFG) expressed in BNF or EBNF. Once we have that we have options - any of several Perl implementations including Parse::Yapp / Par

Re: One possible future of parsing Graph::Easy input texts

> > One could describe the Graph::Easy format grammar as a state machine, draw > the state machine with Graph::Easy, then implement a parser from your > diagram, with > Graph::Easy::StateMachine > , > for a future

Re: One possible future of parsing Graph::Easy input texts

> On Mon, Mar 21, 2011 at 4:04 PM, wrote: > > >> An interesting concept but describing the syntax as a grammar is not the >> same as an FSA. The FSA is part of the parser and lexer. >> > > I disagree. "State Machine" is a powerful abstraction that is useful in > many > places. > FSA/FSM are -very-

Re: One possible future of parsing Graph::Easy input texts

I reviewed the list of bugs at https://rt.cpan.org/Public/Dist/Display.html?Name=Graph-Easy Very few seem related to parsing or the input language. The layouter hanging on a 749 edge graph would seem a problem even if you explicitly did it with calls from perl code. Indeed most of the bugs seem t

Re: Benchmark module with some more statistics

> In some cases just getting the average runtime from a benchmark isn't > really informative. Unfortunately this is all that we get from > Benchmark.pm Have you seen Devel::NYTProf?

Re: Making sure your module works on other OS-es as well

For better or worse, the native Perl on Solaris 10 remains 5.8.4 as it was 5 years ago with Solaris 10 GA. IIRC Solaris 9 is 5.6. Lest you think nobody still runs Solaris 9 my employer does and they have a Perl application on it which is in transition to Solaris 10. Solaris 11 is I believe shi

Re: The CPAN Covenant

I've mostly ignored all this but I will step in briefly. I am the author of a few modules on CPAN. None of them are major. The dependency of one on another module which has been broken for years means that I get frequent e-mail that it fails its tests. There's nothing wrong with -my- module and if

Solaris Studio (was Re: The CPAN Morass)

To download stuff from Oracle you have to register with them (free) and agree to their license terms. Download Solaris Studio from http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/index-jsp-141149.html This is not just C/C++ it is also a Java compiler and Netbeans and IIRC