Re: Module Name
Thanks! at the least, it is an example of what one can do with Filter::Simple! I would use HEREIS syntax for building the code blocks, instead of dotting together doublequoted strings, and put the references inside L. Is Text::RewriteRules powerful enough to define code structures with? Implementing a switch statement, or undecorated variables -- the kinds of things one can do with a simple filter -- can you use RewriteRules as a easier filter-writing interface? These are ideas for the examples in the documentation, if you feel energetic :) On Mon, 27 Dec 2004 12:30:39 +, Alberto Manuel Brandão Simões <[EMAIL PROTECTED]> wrote: > Folks, thanks for the brainstorming. > > At the moment, it is named Text::RewriteRules and it is on CPAN. -- David L Nicol You're striving for harmony, and, if you try to take too much, you'll come to grief. -- Michael Redmond
Re: Syntactic sugar was Module Name
Khemir, check the module and its generated code. I don't think it is
syntactic sugar. If it is, every module on cpan is.
Of course I can write is as a function that receives the rules and
returns the function reference. That is what the module does in its
internals, but the code readability really decreases.
Sincerelly,
Alberto.
khemir nadim wrote:
Hi Alberto,
Terrence Brannon" <[EMAIL PROTECTED]> wrote in message news> > RULES foo
aa==>bb
cd==>ef
ENDRULES
I don't get it. Are you just creating syntactics sugar for:
my %rules =
( aa => 'bb',
cd => 'ef'
);
Terrence Brannon wrote:
your original post said something about regular expressions.
RULES foo
a(b+)c==>c$1a!!length($1)>5
ENDRULES
so, abbbc gets cbbba if the number of b greater than 5.
I believe you can do everything that this module does using
Parse::RecDescent.
You can do everything any module does using Perl... don't get your point.
Alberto.
I must admit I share Terrence's view.
In my opinion, Syntactic sugar that brings no new functionality is best
avoided (YMMV)
and if you need something for a specific application, the module shall not
be presented as
a module implementing some generic functionality. Read me right, I believe
it's OK to have
application specific modules but if the app is not generaly available, maybe
th emodule is
better kept out of CPAN.
Perl gives the possibility to ondent and present data in many ways, maybe
you should think
of letting perl do the dirty job for you.
Now this is not only theoretical chat, I have first hand experience I want
to share with you.
We have discussed build system and build tools together on another thread;
Instead for going
for a new syntax or writting a parser for a known syntax, I used perl to
define rules.
Here are some example:
AddRule [VIRTUAL], 'project', [ 'all' => 'msf/all' ], BuildOk('Project
built.') ;
AddRule 'c_objects', [ '*/*.o' => '*.c' ] ,
"%CC %CFLAGS %CDEFINES ... %FILE_TO_BUILD -c %DEPENDENCY_LIST"
Those look "like" make rules but are perl functions. Then I can do much more
complicated stuff
if I want to:
AddRule 'rule_3',
[ AndMatch(qr<\.c$>, NoMatch(qr/xx/)) => '$path/$basename.h'] ;
Of course the AddRule function has to be written and maintained but I leave
the parsing _and_
error reporting to perl.
In the example bellow I forget a dot to concatenate strings
AddConfig 'EXTRA_LDFLAGS'=> GetPerlEmbedConfig('LDFLAGS_INCLUDE') " ".
GetPerlEmbedConfig('LDFLAGS') ;
I get:
String found where operator expected at './Pbsfile.pl' line 4, near ") " ""
(Missing operator before " "?)
Had I written an own parser, I'd have to handle this too.
Here is another example (real life too):
I had a module that allowed me to have configs in this format:
SMED_FORMAT_CLASSES
olive_green 202 255 112 ...
grey 128 128 128
unwanted_separator black cyan
upper_case default olive_green
SMED_FORMAT_CLASSES
then the module did some magic to have all conversions done properly etc...
I now do it this way:
AddConfigTo 'colors' =>
olive_green => [202, 255, 112]
grey=> [128, 128, 128]
...
AddConfigTo 'colors_tuples' =>
unwanted_separator => ['black', 'cyan'] ,
upper_case => [[0, 0, 0] , 'olive_green']
...
NormalizeColorTupless('color_tupless') ;
Don't get fooled by the 'AddConfigTo' (It does configuration checking)
in a simpler case using a hash directely would have been best.
The setup time for writting a config files is longer but it takes very
little time
to _not_ write a module. Once setupn it doesn't take any longer to add
config.
One extra benefit I got from this is that the config can be real object
would I decide
so:
AddConfigTo 'colors' =>
olive_green => \&GetRandomColor
I still would need to check what I get in the config but I do not need to
update any parser.
IMHO, if you are going to run something in perl, it's best to write it in
perl.
Cheers, Nadim.
PS: I agree that Parse::RecDescent is too slow to be usable but writtin a
proper parser
is often worth the time compare with an ad-hoc one.
--
Alberto Simões - Departamento de Informática - Universidade do Minho
,,__
.. .. / o._) .---.
/--'/--\ \-'||...' '.
/\_/ / | .' '..' '-.
.'\ \__\ __.'.' .' ì-._
)\ | )\ | _.'
// \\ // \\
||_ \\|_ \\_ Perl Monger
mrf '--' '--'' '--'www.perl-hackers.net
Re: detecting the invoking perl
Quoting Ovid <[EMAIL PROTECTED]>: http://search.cpan.org/~mschwern/ExtUtils-MakeMaker-6.25/lib/ExtUtils/MakeMaker.pm > > The bug you are referring to appears to be: > http://rt.cpan.org/NoAuth/Bug.html?id=6588 > > bryar-newblog is referenced in the EXE_FILES of the Makefile.PL. and > it's shebang line is "#!/usr/bin/perl". > > According to the ExtUtils::MakeMaker docs: > > If your executables start with something like #!perl > or #!/usr/bin/perl MakeMaker will change this to the > path of the perl 'Makefile.PL' was invoked with so > the programs will be sure to run properly even if perl > is not in /usr/bin/perl. > > So, if the bug author is still finding the shebang line is wrong, I > would suggest either they ran Makefile.PL with the wrong Perl or there > is a bug in their ExtUtils::MakeMaker setup. > > Does this answer the question? > Yes it does. Cool. I was always concerned about this, but haven't had an impetus to find out what the deal was/fix it until i wanted to close out that bug. Thanks Randall and Ovid for the pointers. /me ducks now for not reading the make maker documentation. It never occurred to me that this was install magic. -jason gessner [EMAIL PROTECTED]
Re: detecting the invoking perl
--- [EMAIL PROTECTED] wrote: > Hi All. > > In the bryar distribution, i write out a bryar-newblog script that > sets up a > blog in the current directory. There is a bug filed on rt.cpan.org > about this > script's reliance on /usr/bin/perl. *If* I understand what you're asking, read the docs for: http://search.cpan.org/~mschwern/ExtUtils-MakeMaker-6.25/lib/ExtUtils/MakeMaker.pm The bug you are referring to appears to be: http://rt.cpan.org/NoAuth/Bug.html?id=6588 bryar-newblog is referenced in the EXE_FILES of the Makefile.PL. and it's shebang line is "#!/usr/bin/perl". According to the ExtUtils::MakeMaker docs: If your executables start with something like #!perl or #!/usr/bin/perl MakeMaker will change this to the path of the perl 'Makefile.PL' was invoked with so the programs will be sure to run properly even if perl is not in /usr/bin/perl. So, if the bug author is still finding the shebang line is wrong, I would suggest either they ran Makefile.PL with the wrong Perl or there is a bug in their ExtUtils::MakeMaker setup. Does this answer the question? Cheers, Ovid = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: detecting the invoking perl
> "jason" == jason <[EMAIL PROTECTED]> writes:
jason> In the bryar distribution, i write out a bryar-newblog script that sets
up a
jason> blog in the current directory. There is a bug filed on rt.cpan.org
about this
jason> script's reliance on /usr/bin/perl.
jason> I am nearly always using a custom compiled perl in /usr/local/bin/perl
so this
jason> bites me as well. What i would like to do is be able to write this out
jason> according to whichever perl the user is building the distribution under.
jason> I see this at the top of prove:
jason> -
jason> #!/usr/local/bin/perl
jason> eval 'exec /usr/local/bin/perl -S $0 ${1+"$@"}'
jason> if $running_under_some_shell;
jason> #!/usr/bin/perl -w
"prove" got "installed", which meant that the shbang line was rewritten
during installation to be your favorite Perl.
I believe what you are looking for can be obtained as:
use Config;
print $Config{startperl}, $/;
Or maybe "perlpath" instead. Look at both of them, see what you need.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: detecting the invoking perl
On Wed, Dec 29, 2004 at 10:17:41AM -0600, [EMAIL PROTECTED] ([EMAIL PROTECTED])
wrote:
> I see this at the top of prove:
> -
> #!/usr/local/bin/perl
> eval 'exec /usr/local/bin/perl -S $0 ${1+"$@"}'
> if $running_under_some_shell;
> #!/usr/bin/perl -w
>
>
> Andy, could you shed some light on this? I *think* this might be doing what i
> want, but am not quite sure.
I'm not sure of the script-fu going on when it gets installed, so I'm
not sure. At runtime, you can look at $^X, but I don't think that's
what you're asking.
xoa
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
detecting the invoking perl
Hi All.
In the bryar distribution, i write out a bryar-newblog script that sets up a
blog in the current directory. There is a bug filed on rt.cpan.org about this
script's reliance on /usr/bin/perl.
I am nearly always using a custom compiled perl in /usr/local/bin/perl so this
bites me as well. What i would like to do is be able to write this out
according to whichever perl the user is building the distribution under.
I see this at the top of prove:
-
#!/usr/local/bin/perl
eval 'exec /usr/local/bin/perl -S $0 ${1+"$@"}'
if $running_under_some_shell;
#!/usr/bin/perl -w
Andy, could you shed some light on this? I *think* this might be doing what i
want, but am not quite sure.
Does anyone have any thoughts?
Thanks!
-jason gessner
[EMAIL PROTECTED]
Syntactic sugar was Module Name
Hi Alberto,
>Terrence Brannon" <[EMAIL PROTECTED]> wrote in message news> > RULES foo
> > aa==>bb
> > cd==>ef
> > ENDRULES
>
> I don't get it. Are you just creating syntactics sugar for:
>
> my %rules =
>( aa => 'bb',
> cd => 'ef'
> );
> Terrence Brannon wrote:
> >>>your original post said something about regular expressions.
> >>RULES foo
> >>a(b+)c==>c$1a!!length($1)>5
> >>ENDRULES
> >>
> >>so, abbbc gets cbbba if the number of b greater than 5.
> > I believe you can do everything that this module does using
> > Parse::RecDescent.
> You can do everything any module does using Perl... don't get your point.
> Alberto.
I must admit I share Terrence's view.
In my opinion, Syntactic sugar that brings no new functionality is best
avoided (YMMV)
and if you need something for a specific application, the module shall not
be presented as
a module implementing some generic functionality. Read me right, I believe
it's OK to have
application specific modules but if the app is not generaly available, maybe
th emodule is
better kept out of CPAN.
Perl gives the possibility to ondent and present data in many ways, maybe
you should think
of letting perl do the dirty job for you.
Now this is not only theoretical chat, I have first hand experience I want
to share with you.
We have discussed build system and build tools together on another thread;
Instead for going
for a new syntax or writting a parser for a known syntax, I used perl to
define rules.
Here are some example:
AddRule [VIRTUAL], 'project', [ 'all' => 'msf/all' ], BuildOk('Project
built.') ;
AddRule 'c_objects', [ '*/*.o' => '*.c' ] ,
"%CC %CFLAGS %CDEFINES ... %FILE_TO_BUILD -c %DEPENDENCY_LIST"
Those look "like" make rules but are perl functions. Then I can do much more
complicated stuff
if I want to:
AddRule 'rule_3',
[ AndMatch(qr<\.c$>, NoMatch(qr/xx/)) => '$path/$basename.h'] ;
Of course the AddRule function has to be written and maintained but I leave
the parsing _and_
error reporting to perl.
In the example bellow I forget a dot to concatenate strings
AddConfig 'EXTRA_LDFLAGS'=> GetPerlEmbedConfig('LDFLAGS_INCLUDE') " ".
GetPerlEmbedConfig('LDFLAGS') ;
I get:
String found where operator expected at './Pbsfile.pl' line 4, near ") " ""
(Missing operator before " "?)
Had I written an own parser, I'd have to handle this too.
Here is another example (real life too):
I had a module that allowed me to have configs in this format:
SMED_FORMAT_CLASSES
olive_green 202 255 112 ...
grey 128 128 128
unwanted_separator black cyan
upper_case default olive_green
SMED_FORMAT_CLASSES
then the module did some magic to have all conversions done properly etc...
I now do it this way:
AddConfigTo 'colors' =>
olive_green => [202, 255, 112]
grey=> [128, 128, 128]
...
AddConfigTo 'colors_tuples' =>
unwanted_separator => ['black', 'cyan'] ,
upper_case => [[0, 0, 0] , 'olive_green']
...
NormalizeColorTupless('color_tupless') ;
Don't get fooled by the 'AddConfigTo' (It does configuration checking)
in a simpler case using a hash directely would have been best.
The setup time for writting a config files is longer but it takes very
little time
to _not_ write a module. Once setupn it doesn't take any longer to add
config.
One extra benefit I got from this is that the config can be real object
would I decide
so:
AddConfigTo 'colors' =>
olive_green => \&GetRandomColor
I still would need to check what I get in the config but I do not need to
update any parser.
IMHO, if you are going to run something in perl, it's best to write it in
perl.
Cheers, Nadim.
PS: I agree that Parse::RecDescent is too slow to be usable but writtin a
proper parser
is often worth the time compare with an ad-hoc one.
