[32094] in Perl-Users-Digest
Perl-Users Digest, Issue: 3358 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 20 09:09:26 2011
Date: Wed, 20 Apr 2011 06:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 20 Apr 2011 Volume: 11 Number: 3358
Today's topics:
Re: A regex to search for numeric ranges... <misterperl@gmail.com>
Re: A regex to search for numeric ranges... <misterperl@gmail.com>
Re: A regex to search for numeric ranges... <sherm.pendley@gmail.com>
Re: A regex to search for numeric ranges... <*@eli.users.panix.com>
Extended deadline; IFIP sponsorship: IFIP Working Confe <emilie.balland@gmail.com>
Re: parsing a command line, but not the usual problem <*@eli.users.panix.com>
Re: parsing a command line, but not the usual problem <marc.girod@gmail.com>
Re: Perl RegExp question <keithdlee2000@gmail.com>
Re: Perl RegExp question <dsfqsdf@poupidoup.com>
Re: Perl RegExp question <keithdlee2000@gmail.com>
Re: Spreadsheet::WriteExcel, can't write to returned ob <justin.1104@purestblue.com>
Re: Spreadsheet::WriteExcel, can't write to returned ob <willem@toad.stack.nl>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 19 Apr 2011 13:36:50 -0700 (PDT)
From: Mr P <misterperl@gmail.com>
Subject: Re: A regex to search for numeric ranges...
Message-Id: <390f8172-b650-49b5-9ce4-b2911fed178b@e8g2000vbz.googlegroups.com>
On Apr 19, 3:57=A0pm, Eli the Bearded <*...@eli.users.panix.com> wrote:
> In comp.lang.perl.misc, Mr P =A0<misterp...@gmail.com> wrote:
>
> > I read up on this on the www and I found ideas like
>
> > if ( /\b([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\b/ ) ...
>
> > which is pretty uncipherable at a glance and just in general not
> > elegant in any sense.
>
> True. That's why it's much better to not use regexps for numerical
> ranges.
>
> > I generally do something like
>
> > =A0if ( /(\d+)/ && $1 > 256 && $1 < 1024 )
>
> I'd write that as
>
> =A0 =A0if ( /(\d+)/ && ($1 > 256) && ($1 < 1024) )
>
> because I like to make sure things operate in the order I want them
> to.
>
> > Which to me is a lot more readable at a glance, but like the example
> > above not overly elegant..
>
> > But what I'd REALLY like to do is, similar to the =A0trick for numeric
> > sort, a way to do it in the regex like
>
> > /[256-1024]/ # but force it to be numeric, not literal perhaps with a
> > switch
>
> sub mknumre($$) {
> =A0 my $low =3D shift;
> =A0 my $hi =A0=3D shift;
>
> =A0 my $set =3D join('|', ($low .. $hi));
>
> =A0 return qr/($set)/;
>
> }
>
> > Thoughts, Masters?
>
> Why does this have to be a regular expression? Use the right tool
> for the job.
I guess my answer to that question is that my 1-line regex is a lot
easier to read and much shorter than your 9-line monster!
------------------------------
Date: Tue, 19 Apr 2011 13:46:00 -0700 (PDT)
From: Mr P <misterperl@gmail.com>
Subject: Re: A regex to search for numeric ranges...
Message-Id: <1feca533-d2e4-40c8-9490-32847f9ea47c@z31g2000vbs.googlegroups.com>
> > I generally do something like
>
> > =A0if ( /(\d+)/ && $1 > 256 && $1 < 1024 )
>
> I'd write that as
>
> =A0 =A0if ( /(\d+)/ && ($1 > 256) && ($1 < 1024) )
>
> because I like to make sure things operate in the order I want them
> to.
>
There is no ambiguity in the order of my example- study ORDER
PRECEDENCE. Mine is just less syntax-intensive.
------------------------------
Date: Tue, 19 Apr 2011 17:50:28 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: A regex to search for numeric ranges...
Message-Id: <m2bp01ud0b.fsf@sherm.shermpendley.com>
Mr P <misterperl@gmail.com> writes:
> On Apr 19, 3:57 pm, Eli the Bearded <*...@eli.users.panix.com> wrote:
>>
>> Why does this have to be a regular expression? Use the right tool
>> for the job.
>
> I guess my answer to that question is that my 1-line regex is a lot
> easier to read and much shorter than your 9-line monster!
Please tell me you're joking...
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Tue, 19 Apr 2011 23:07:20 +0000 (UTC)
From: Eli the Bearded <*@eli.users.panix.com>
Subject: Re: A regex to search for numeric ranges...
Message-Id: <eli$1104191906@qz.little-neck.ny.us>
In comp.lang.perl.misc, Mr P <misterperl@gmail.com> wrote:
> I guess my answer to that question is that my 1-line regex is a lot
> easier to read and much shorter than your 9-line monster!
My "9-line monster" is computer generated code and not intended for
human reading. Also my example was a gentle nudge that while regexps
may be powerful they should not be the answer to every question.
Which of these is easier to understand:
$lo=128;
$hi=256;
for (qw( 100 200 300 )) {
# method RE:
if (/(\d+) (?(?{
($^N >= $lo) && ($^N <= $hi)
})
()
|(?!))
/x) {
print "RE: $lo <= $_ <= $hi\n";
}
# method code:
if (/(\d+)/ and ($1 >= $lo) and ($1 <= $hi)) {
print "code: $lo <= $_ <= $hi\n";
}
}
I'd never want to see the RE method in production code.
Elijah
------
and not just because of the perlre "experimental code" warning
------------------------------
Date: Tue, 19 Apr 2011 23:40:27 -0700 (PDT)
From: Emilie <emilie.balland@gmail.com>
Subject: Extended deadline; IFIP sponsorship: IFIP Working Conference on Domain-Specific Languages
Message-Id: <2a0deefc-7869-4714-8153-84a6ea0600c0@u12g2000vbf.googlegroups.com>
IFIP Working Conference on Domain-Specific Languages (DSL)
6-8 September 2011, Bordeaux, France
http://dsl2011.bordeaux.inria.fr/
CALL FOR PAPERS (EXTENDED DEADLINE; IFIP SPONSORSHIP)
Domain-specific languages have long been a popular way to shorten
the distance from ideas to products in software engineering. On one
hand, the interface of a DSL lets domain experts express high-level
concepts succinctly in familiar notation, such as grammars for text or
scripts for animation, and often provides guarantees and tools that
take
advantage of the specifics of the domain to help write and maintain
these particular programs. On the other hand, the implementation of a
DSL can automate many tasks traditionally performed by a few experts
to turn a specification into an executable, thus making this expertise
available widely. Overall, a DSL thus mediates a collaboration
between
its users and implementers that results in software that is more
usable,
more portable, more reliable, and more understandable.
These benefits of DSLs have been delivered in domains old and new,
such
as signal processing, data mining, and Web scripting. Widely known
examples of DSLs include Matlab, Verilog, SQL, LINQ, HTML, OpenGL,
Macromedia Director, Mathematica, Maple, AutoLisp/AutoCAD, XSLT, RPM,
Make, lex/yacc, LaTeX, PostScript, and Excel. Despite these
successes,
the adoption of DSLs have been stunted by the lack of general tools
and
principles for developing, compiling, and verifying domain-specific
programs. General support for building and using DSLs is thus
urgently
needed. Languages that straddle the line between the domain-specific
and the general-purpose, such as Perl, Tcl/Tk, and JavaScript, suggest
that such support be based on modern notions of language design and
software engineering. The goal of this conference, following the last
one in 2009, is to explore how present and future DSLs can fruitfully
draw from and potentially enrich these notions.
We seek research papers on the theory and practice of DSLs, including
but not limited to the following topics.
* Foundations, including semantics, formal methods, type theory, and
complexity theory
* Language design, including concrete syntax, semantics, and types
* Software engineering, including domain analysis, software design,
and round-trip engineering
* Modularity and composability of DSLs
* Software processes, including metrics for software and language
evaluation
* Implementation, including parsing, compiling, program generation,
program analysis, transformation, optimization, and
parallelization
* Reverse engineering, re-engineering, design discovery, automated
refactoring
* Hardware/software codesign
* Programming environments and tools, including visual languages,
debuggers, testing, and verification
* Teaching DSLs and the use of DSLs in teaching
* Case studies in any domain, especially the general lessons they
provide for DSL design and implementation
The conference will include a visit to the city of Bordeaux, a tour
and tasting at the wine museum and cellar, and a banquet at La Belle
=C9poque.
INSTRUCTIONS FOR AUTHORS
Papers will be judged on the depth of their insight and the extent
to which they translate specific experience into general lessons
for software engineers and DSL designers and implementers. Where
appropriate, papers should refer to actual languages, tools, and
techniques, provide pointers to full definitions, proofs, and
implementations, and include empirical results.
Proceedings will be published in Electronic Proceedings in Theoretical
Computer Science (http://info.eptcs.org/). Submissions and final
manuscripts should be at most 25 pages in EPTCS format.
IMPORTANT DATES
* 2011-04-25: Abstracts due (extended deadline)
* 2011-05-02: Submissions due (extended deadline)
* 2011-06-10: Authors notified of decisions
* 2011-07-11: Final manuscripts due
* 2011-09-05: Distilled tutorials
* 2011-09-06/2011-09-08: Main conference
PROGRAM COMMITTEE
* Emilie Balland (INRIA)
* Olaf Chitil (University of Kent)
* Zo=E9 Drey (LaBRI)
* Nate Foster (Cornell University)
* Mayer Goldberg (Ben-Gurion University)
* Shan Shan Huang (LogicBlox)
* Sam Kamin (University of Illinois at Urbana-Champaign)
* Jerzy Karczmarczuk (University of Caen)
* Jan Midtgaard (Aarhus University)
* Keiko Nakata (Tallinn University of Technology)
* Klaus Ostermann (University of Marburg)
* Jeremy Siek (University of Colorado at Boulder)
* Tony Sloane (Macquarie University)
* Josef Svenningsson (Chalmers University of Technology)
* Paul Tarau (University of North Texas)
* Dana N. Xu (INRIA)
ORGANIZERS
Local chair: Emilie Balland (INRIA)
Program chairs: Olivier Danvy (Aarhus University),
Chung-chieh Shan (Rutgers University)
------------------------------
Date: Tue, 19 Apr 2011 22:11:53 +0000 (UTC)
From: Eli the Bearded <*@eli.users.panix.com>
Subject: Re: parsing a command line, but not the usual problem
Message-Id: <eli$1104191731@qz.little-neck.ny.us>
In comp.lang.perl.misc, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>> "EtB" == Eli the Bearded <*@eli.users.panix.com> writes:
> EtB> Are there any modules that can help me with this breed of command
> EtB> parsing? Regular command line parsing is dominating my search results.
> EtB> I would like to be able to do variable expansion in double-quoted
> EtB> strings and no expansion in single-quoted ones. I am not interested
> EtB> in file globbing.
>
> Looks like Shell::Parser could do it, although it might be overkill.
It's not exactly what I wanted, but it is a good start. I might just
borrow code from it rather than use it directly.
#!/usr/bin/perl -w
use Shell::Parser;
use strict;
my $parser = new Shell::Parser handlers => { default => \&dumpnode };
sub dumpnode {
my $self = shift;
my %args = @_;
print "$args{type}: <$args{token}>\n"
}
$parser->parse(q*echo "The $cow \"jumps\" over "'the $moon' && $again*);
__END__
Gives me:
text: <echo>
text: < >
text: <"The $cow \"jumps\" over "'the $moon'>
text: < >
text: < >
metachar: <&>
metachar: <&>
text: < >
text: < >
variable: <$again>
The flagging of IFS whitespace as text might be right for what this
was written for, but it isn't right for me. Also I'd have wanted to
see:
dquoted: <The $cow "jumps" over >
squoted: <the $moon>
Elijah
------
is separately sending bugs and a suggestion for improvement to the author
------------------------------
Date: Wed, 20 Apr 2011 02:50:49 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: parsing a command line, but not the usual problem
Message-Id: <9c062033-abdc-4cb5-b851-ec960d96f1bb@d12g2000vbz.googlegroups.com>
On Apr 19, 11:11=A0pm, Eli the Bearded <*...@eli.users.panix.com> wrote:
> It's not exactly what I wanted, but it is a good start. I might just
> borrow code from it rather than use it directly.
What about Text:ParseWords, then?
~> perl -MText::ParseWords -le 'while(<>){print for shellwords $_}'
this is a 'command line' but it has "some $faults"
this
is
a
command line
but
it
has
some $faults
Marc
------------------------------
Date: Tue, 19 Apr 2011 21:56:44 +0000 (UTC)
From: Keith <keithdlee2000@gmail.com>
Subject: Re: Perl RegExp question
Message-Id: <iol0es$bnf$1@dont-email.me>
On Tue, 19 Apr 2011 13:03:58 -0500, Ted Zlatanov wrote:
> On Tue, 19 Apr 2011 16:46:37 +0000 (UTC) Keith <keithdlee2000@gmail.com>
> wrote:
>
> K> OK, I understand now. Here are some more examples of input and
> wanted output.
>
> K> Title of show -- "King of Royal Mounted" or "King's Row" K> Titlle
> of episode -- "Murderer's Row" or "Saps at Sea" K> Number of episode
> -- 1 through 13
>
> K> Input Examples:
> K> King of Royal Mounted Murderer's Row Chapter 2.AVI
>
> K> King's Row Saps at Sea Chapter 11.AVI
>
>
> K> Again, how do I make some generic regexp in Perl in order to change
> the above to the following output?
>
> K> Output Examples:
> K> King of Royal Mounted Ch 2 Murderer's Row.avi
>
> K> King's Row Ch 11 Saps at Sea.avi
>
> Build a list of possible show names. Untested:
>
> my @shows = ('King of Royal Mounted', "King's Row"); foreach my $show
> (@shows)
> {
> # note the i modifier to match AVI, avi, etc. $name =~
> s/^$show\s+(.*)\s+Chapter\s+(\d+).avi/$show Ch $2 $1.avi/i;
> }
>
> Ted
Ted:
What if you don't know what the title is exactly in an .avi file? That is, you know that it's the first word(s)
of the file name but nothing more?
Keith Lee
------------------------------
Date: Wed, 20 Apr 2011 12:48:07 +0200
From: azrazer <dsfqsdf@poupidoup.com>
Subject: Re: Perl RegExp question
Message-Id: <iomdl5$4oq$1@speranza.aioe.org>
> Ted:
> What if you don't know what the title is exactly in an .avi file? That is, you know that it's the first word(s)
> of the file name but nothing more?
> Keith Lee
hulo,
you may try to build a big database (an array in this case will be
sufficient) containing all the show names (extracted from the internet)....
Otherwise, you cannot expect a computer to be "intelligent" and know
what is a show and what is not... this part of the program must come
from the programmer :)
best,
azra
------------------------------
Date: Wed, 20 Apr 2011 12:44:17 +0000 (UTC)
From: Keith <keithdlee2000@gmail.com>
Subject: Re: Perl RegExp question
Message-Id: <iomkf1$2vd$1@dont-email.me>
Azra:
Yes, I have learned about the limitations of Perl RegExp or RegExp in general. Thank you.
Keith
------------------------------
Date: Wed, 20 Apr 2011 11:52:56 +0100
From: Justin C <justin.1104@purestblue.com>
Subject: Re: Spreadsheet::WriteExcel, can't write to returned object?
Message-Id: <8hq288-lvq.ln1@zem.masonsmusic.co.uk>
On 2011-04-19, Jim Gibson <jimsgibson@gmail.com> wrote:
> In article <cim088-vlu.ln1@zem.masonsmusic.co.uk>, Justin C
> <justin.1104@purestblue.com> wrote:
[snip]
>
> The problem is that the top-level spreadsheet object ($workbook) as
> returned by new() is lexically-scoped to the create_excel_file
> subroutine and goes out of scope when the subroutine returns. While you
> are returning and saving the worksheet object, the spreadsheet file has
> probably been closed and written to disk at that point, so further
> writes do not get saved.
>
> Solutions are to either 1) return the workbook object as well or 2)
> make the workbook object global (file scope).
... defeating moving it to a sub to tidy up. However, I do wonder about
the logic of creating a subroutine that is used only once. AIUI they're
to re-use code. Hey ho. Maybe I'll, as you suggest, return the workbook
too... which has worked quite nicely.
Thank you for the suggestion.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 20 Apr 2011 12:09:41 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Spreadsheet::WriteExcel, can't write to returned object?
Message-Id: <slrniqtj85.1n75.willem@toad.stack.nl>
Jim Gibson wrote:
) The problem is that the top-level spreadsheet object ($workbook) as
) returned by new() is lexically-scoped to the create_excel_file
) subroutine and goes out of scope when the subroutine returns. While you
) are returning and saving the worksheet object, the spreadsheet file has
) probably been closed and written to disk at that point, so further
) writes do not get saved.
)
) Solutions are to either 1) return the workbook object as well or 2)
) make the workbook object global (file scope).
Or 3) stick a reference to the workbook object into the worksheet object,
so that the reference sticks around until the worksheet goes out of scope.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3358
***************************************
