Re: Including externally-defined constants
Le jeudi 20 juillet 2006 à 02:41, A. Pagaltzis écrivait: > * Philippe "BooK" Bruhat <[EMAIL PROTECTED]> [2006-07-19 22:10]: > ><< '=cut'; > > > >=pod > > > >[...snip...] > > > >=cut > > Damn, what a cool hack! That's exactly what I thought when I first saw it. :-) -- Philippe "BooK" Bruhat A substitute is never as good as the genuine article. (Moral from Groo The Wanderer #67 (Epic))
Re: Including externally-defined constants
Le mercredi 19 juillet 2006 à 13:59, A. Pagaltzis écrivait:
> * David Landgren <[EMAIL PROTECTED]> [2006-07-19 13:40]:
> > The problem is that these associations are private to the XS
> > and Perl module. The client code does not need to know about
> > them, and in fact shouldn't. So I don't want client code to
> > know the file exists, and people won't go around trying to
> > include it. So the Perl file has to go.
>
> Might Pod::Constants help?
>
> =begin constants
>
> FOO => 1
> BAR => 2
> QUUX => 3
>
> =end constants
In the same vein, and without an external module, you could also simply
expose the information in the documentation, and fetch it from there: (a
trick I discovered thanks to Abigail's additions to Acme::MetaSyntactic,
see the upcoming Acme::MetaSyntactic::tour_de_france for an example):
my %const = map { s/\s+//; $_ }
map { split /\s*=>\s*/ }
grep {/=>/}
map { split /\n/ } << '=cut';
=pod
This module uses the following constants:
bang_eth => 1
biff => 2
krunch => 3
=cut
--
Philippe "BooK" Bruhat
There are two sides to every cause. Do not join one until you know the other.
(Moral from Groo The Wanderer #105 (Epic))
Re: I think we can just scrap CPAN Ratings altogether
Le lundi 12 juin 2006 à 20:09, A. Pagaltzis écrivait: > > > An improvement would be to turn it into a forum, maybe merge > > with CPAN forums but keeping reviews separate from technical > > support questions. (Bad reviews such as "how do I compile > > module X" can be moved into technical support forums too.) > > Reviews that are voted as useless can be culled by moderators. > > I think that’s the most sensible suggestion so far. Now for > someone to supply the tuits and JFDI for it… :-) A forum? As in "a place for flames and uninformed discussion"? How exactly is that an improvement? :-) However, having review editors that can act based on the useful/useless votes is enough to remove the occasional junk comment (or spam ?). -- Philippe "BooK" Bruhat Be careful when you take one side or the other. You could wind up in the middle.(Moral from Groo The Wanderer #33 (Epic))
Re: Net::SSH2 'hijack'
Le dimanche 19 mars 2006 à 22:07, Dr Bean écrivait: > > But perhaps using the same number more effectively hides the > other version. It hides it so well, that search.cpan is confused: if you go on http://search.cpan.org/tools/Net-SSH2 and try do diff releases Net-SSH2-0.07 -- 11 Feb 2006 and Net-SSH2-0.07 -- 18 Mar 2006, search.cpan finds no differences (probably because it picks twice the same release). -- Philippe "BooK" Bruhat Your life is the greatest show of all. Do not let anyone else direct. (Moral from Groo The Wanderer #84 (Epic))
Re: RFC - Data::SelectWithoutReplacement
Le jeudi 17 novembre 2005 à 22:45, David Landgren écrivait: > > I have a simple module written and as far as I can tell, there's nothing > on CPAN that does this. (Algorithm::Permute might, but it segfaults on > my machine). > > From the POD: > > Data::SelectWithoutReplacement - Generate all subsets of a list of elements What about Data::Subsets ? (and the empty list is a subset as well) There is a Set:: top-level namespace, but Set::Subsets sounds odd. > # prints > 3 1 4 > 1 4 > 3 4 > 4 > 3 1 > 1 > 3 Some people might like to receive the subsets ordered by size (ascending or descending) or maybe only a subset of the subsets (!). Like for instance, the 4 elements subsets of a 7 elements set. Specific arguments to the constructor could do the trick. -- Philippe "BooK" Bruhat Your reputation is what you make of it... and what you choose to take with you. (Moral from Groo The Wanderer #48 (Epic))
Re: Hash::HasKeys
Le lundi 15 août 2005 à 11:01, David Golden écrivait:
>
> use Params::Validate;
>
> sub tweedledum {
> my %args = validate( @_, {
> foo => 1, # required
> bar => 1, # required
> bam => { default => 'default' },
> wibble => { default => 0 },
> wobble => { default => 0 },
> });
>
> # process
> }
For all you metasyntactic needs, don't to use forget Acme::MetaSyntactic!
Exemple:
$ meta donmartin 6
chook
plablablablab
ga_shklurtz
spritz
fladip
swap
--
Philippe "BooK" Bruhat
To flaunt your strength is to make it your weakness.
(Moral from Groo The Wanderer #25 (Epic))
Re: Perl6 goes where?
Le jeudi 28 juillet 2005 à 16:32, A. Pagaltzis écrivait: > * Philippe 'BooK' Bruhat <[EMAIL PROTECTED]> [2005-07-28 16:05]: > > I thought I heard (or more probably read somewhere) that the > > name was 6PAN? > > That makes no sense. What is a ???6 Perl Archive Network Okay, > visually, it roughly resembles ???CPAN,??? but I don???t see that as a > good reason to pick a nonsensical initialism??? If found a reference to the name 6PAN here (that was in 2002): http://www.mail-archive.com/perl6-stdlib@perl.org/msg00135.html Anyway, isn't "nonsensical" a prerequisite in the Perl world? Many Perl names started as jokes : Parrot, ponie, CPANTS... -- Philippe "BooK" Bruhat The only certain bet in gambling is that it leads to more gambling (Moral from Groo #11 (Image))
Re: Perl6 goes where?
Le jeudi 28 juillet 2005 à 08:35, _brian_d_foy écrivait: > > Or maybe Ask or Robert will take 10 minutes and create a CP6AN. :) I thought I heard (or more probably read somewhere) that the name was 6PAN? -- Philippe "BooK" Bruhat Even the worst guesser is right once in a while. (Moral from Groo The Wanderer #72 (Epic))
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
Le lundi 20 juin 2005 à 09:09, Eric Wilhelm écrivait: > # The following was supposedly scribed by > # A. Pagaltzis > # on Monday 20 June 2005 08:57 am: > > >I don???t see how being able to *optionally* say something like > > > > GetOptions( > > [EMAIL PROTECTED], > > # ... > > ); > > > >would detract from anything at all. > > I don't think you really need to be able to pass a different array to > GetOptions(). After all, that really is just meant for parsing > command-line arguments, which aren't going to be found anywhere besides > @ARGV. Well, that's a strong assumption. Perl::Tidy, for instance, uses Getopt::Long to parse its parameter list, which has nothing to do with @ARGV. And see http://rt.cpan.org/NoAuth/Bug.html?id=7964 for the kind of trouble that happens when a library uses another library that has a global configuration. In that case, local @ARGV = @whatever is not enough. -- Philippe "BooK" Bruhat The best thing about being apart is getting together again. (Moral from Groo The Wanderer #39 (Epic))
Re: check for errors on close()
Le vendredi 22 avril 2005 à 06:37, Randal L. Schwartz écrivait: > >>>>> "Eric" == Eric Wilhelm <[EMAIL PROTECTED]> writes: > > Eric> Just spent way too much time trying to find a bug when it turns out > that > Eric> I just had a full disk. > > I check for errors on close about as often as I check for errors on > print. I have at least one shell script that uses a Perl one-liner which DOES check for errors in print (which happen when the disk is full) to die early. Since the one-liner basically reads a file and dipatches the lines in different files (based on a date field), there is a small period of time where we have the whole (big) file content duplicated on disk (before the rest of the shell script removes the old file and goes on with its business). The shell script dies when the perl one-liner does, leaving a nice message to be be emailed by the cron daemon. The machine administrator can then make some room and run the shell script again by hand. -- Philippe "BooK" Bruhat Some fair deals are fairer than others. (Moral from Groo The Wanderer #101 (Epic))
Re: Namespace Advice
Le mercredi 06 avril 2005 à 12:11, Smylers écrivait: > Reinhard Pagitsch writes: > > > Chris Dolan wrote: > > > > > I think "Document" may be better than "File" in this case. My first > > > impression was that "Win32::File::Prop" is would interact with > > > Windows filesystem properties, like permissions, hidden flags, > > > ownership, etc. > > > > Or maybe Win32::Storage::PropertySet? > > I would expect something with "storage" in its name to be quite > low-level; it wouldn't occur to me that it would deal with > document-specific properties. > > Also "PropertySet" makes it sounds that it _sets_ properties, whereas > you said your module reads them. It all depends if you hear "set" as a noun or as a "verb", doesn't it? -- Philippe "BooK" Bruhat The shortest distance between two points is not always the safest. (Moral from Groo The Wanderer #69 (Epic))
Re: Module for simple processing of "log" files
Le mercredi 30 mars 2005 à 11:05, Orton, Yves écrivait:
>
> Also, when i say these classes what im thinking is that they encapsulate the
> knowledge about how to convert a rule specification into _source_code_ im
> not thinking that they should have methods that are executed inside of the
> parse loop. IMO there shouldnt be ANY subroutines inside of the parse loop.
> That way the resulting parser is lean and mean and fast. No method lookup BS
> or subroutine call stack overhead.
My goal is to create an object, configure it with everything needed to do
the job (how to split the data, how to select the data to process, what
code to apply to that data). I want the parse/select part of the process
to be as fast as possible. The processing part involves a subroutine call
right now, but that could be optional. I need to leave room to insert as
many hooks as possible. In the end, the run() method should be defined as:
sub run {
my $self = shift;
local @ARGV = $self->files();
eval $self->compute_code();
die $@ if $@; # shouldn't happen
}
Well, that's already the code in my module (roughly 60 lines of code).
> Anyway, as i said i look forward to seeing your work. :-)
I'll try to upload the existing code on CPAN soon.
--
Philippe "BooK" Bruhat
Honesty is its own reward. Dishonesty is its own punishment.
(Moral from Groo The Wanderer #30 (Epic))
Re: Module for simple processing of "log" files
Le mardi 29 mars 2005 à 17:52, Orton, Yves écrivait: > > I started working on a project like this but never got around to finishing > it. I called it "Generic Record Processing System" IE GRPS. The point being > that this isnt a facility related to parsing log files, its a facility > relating to processing any file of parsable records in a mechanical way. Then what do you think of Record::Processor? -- Philippe "BooK" Bruhat You never know what love is until you lose it. (Moral from Groo The Wanderer #38 (Epic))
Re: Module for simple processing of "log" files
Le mardi 29 mars 2005 à 17:52, Orton, Yves écrivait: > > > > Any other name ideas or comments about the module and its interface? > > I started working on a project like this but never got around to finishing > it. I called it "Generic Record Processing System" IE GRPS. The point being > that this isnt a facility related to parsing log files, its a facility > relating to processing any file of parsable records in a mechanical way. This is one reason why I didn't like the Log:: prefix. This also implies that my Regexp::Log suite of modules is badly named as well. > Interesting rules would be stuff like set membership "is field x in set Y" > (which would be implemented as a hash lookup etc). Also interesting would be > a framwork for specifiying which ruleset to apply based on > filename/directory conventions. Additionally stuff like record > transformation, prefix matching and logical evaluation would be cool too. Set operations? Good idea. If the field is a string and the set is a set of strings, computing a regular expression with Regexp::Assemble might be a good option as well. And then, caching the generated code (e.g. because Regexp::Assemble takes some time to run) could be a bonus. -- Philippe "BooK" Bruhat For every winner, there must be one or more losers. (Moral to the Sage story in Groo #111 (Epic))
Re: Module for simple processing of "log" files
Le mardi 29 mars 2005 à 19:05, David Landgren écrivait:
> >$blah->add_filter(
> >bap => 'eq "zlopp"',
> >clank => '!~ /clunk_eth/',
>
> A hash is unordered. Um hang on, or is this a list of pairs or a hash?
It is a list of pairs. For the moment, the right part is pushed on an
array reference stored in a hash indexed by the left part. So yes, I
can do $blah->add_filter( bap => 'ne "zlopp"', bap => 'ne "klonk"' )
> >chomp;
> >my @data = split qr{:};
> >if(( $data[1] !~ /clunk_eth/ )
> >&& ( $data[0] eq "zlopp" ) )
>
> This is ordered. But in any case, it's not in the same order as above.
Sure, it's a hash.
> I would like to be able to specify order in which the checks are run, so
> as to be able to evaluate the check that fails 99% of the time first.
Good point.
> Also, I'm not sure what to suggest, but...
>
> bap => 'eq "zlopp"',
>
> ...feels icky. I'd rather something that would spit out errors at
> compile time, not at eval time. But I can't think of anything
> approaching that level of tersity. At the very least:
>
> bap => { 'eq' => 'zlopp' }
> clunk => { '~!' => qr/^foom\d+$/ }
> sput => { 'between' => [10, 100] }
>
> Hmm, how do I add a new conditional widget, like 'between' above? e.g. I
> want to extract all HTTP transactions whose lengths are prime fibonacci
> numbers.
Moving away from the inner Perl code is a very good option, which Yves
mentionned as well. My first version simply puts the strings into $code,
which has a lot of red flashing lights all around.
Does your asking this kind of questions mean the module is interesting
enough to be posted on CPAN?
--
Philippe "BooK" Bruhat
When you deal in weapons, there are no winners... only losers.
(Moral from Groo The Wanderer #31 (Epic))
Module for simple processing of "log" files
Hi,
I've found myself writing the same script again and again for a client.
Given a set of log files, if such and such field match such and such
condition, then process them in a certain way. I've put the logic
in a module, and I'm now looking for a name for it. I'd also like
to know if this module looks useful to others (it was to me, since it
allowed me to write a CGI that "grepped" through numerous log files
and returned a subset of them as an HTML or CSV file).
The module works like this:
use Blah;# not a very good name for CPAN :-)
my $blah = Blah->new(
delimiter => ':',
fields=> [qw( bap clank glipp plop )],
show => \&show_my_data,
);
# quelques infos utiles
$blah->add_filter(
bap => 'eq "zlopp"',
clank => '!~ /clunk_eth/',
);
$blah->add_file( glob "*.log" );
$blah->run;
When the run() method is called, the object compute a piece of Perl
code which is then eval()ed (with a localised @ARGV). The computed
code is the following (note the use of arrays for the selection pass
and of a hash for the processing):
while(<>) {
chomp;
my @data = split qr{:};
if(( $data[1] !~ /clunk_eth/ )
&& ( $data[0] eq "zlopp" ) )
{
my %data;
@data{qw(bap clank glipp plop)} = @data;
$self->{show}->(\%data);
}
}
In future versions, I may add support for regular expressions for
parsing the fields (thus allowing a nice connection with my other module
Regexp::Log), the possibility to keep using an array for processing,
and have a better interface to add conditions (this is very crude,
and open to attacks if people using this module are not very careful).
I haven't been very successful in finding a name for this module.
Sébastien Aperghis-Tramoni proposed Log::Process, but maybe a name
like Log::Processor would be better.
Any other name ideas or comments about the module and its interface?
--
Philippe "BooK" Bruhat
The greatest monster of them all is ignorance.
(Moral to Pal'n Drumm Storry in Groo #89 (Epic))
