[28490] in Perl-Users-Digest
Perl-Users Digest, Issue: 9854 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Oct 16 18:06:01 2006
Date: Mon, 16 Oct 2006 15:05:08 -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 Mon, 16 Oct 2006 Volume: 10 Number: 9854
Today's topics:
Announce: Win32::GUI V1.04 <rmay@popeslane.clara.co.uk>
Re: FAQ 4.36 How can I expand variables in text strings <brian.d.foy@gmail.com>
Re: I have no problems eating cereal...after it softens <mritty@gmail.com>
Re: I have no problems eating cereal...after it softens <tadmc@augustmail.com>
Re: I have no problems eating cereal...after it softens <tadmc@augustmail.com>
Re: I have no problems eating cereal...after it softens samiam@mytrashmail.com
Re: I have no problems eating cereal...after it softens samiam@mytrashmail.com
Re: I have no problems eating cereal...after it softens samiam@mytrashmail.com
Re: I have no problems eating cereal...after it softens <tadmc@augustmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 16 Oct 2006 22:31:58 +0100
From: Robert May <rmay@popeslane.clara.co.uk>
Subject: Announce: Win32::GUI V1.04
Message-Id: <Oc-dnbFfZI_TZ67YRVnytg@pipex.net>
I am please to announce that v1.04 of Win32::GUI is available for
download from SourceForge and CPAN.
Win32::GUI is a Perl extension allowing creation of native Win32 GUI
applications.
MORE INFORMATION
Project Homepage:
http://perl-win32-gui.sourceforge.net/
Project summary:
http://sourceforge.net/projects/perl-win32-gui/
Downloads:
- Source and ActiveState Perl PPM distributions:
http://sourceforge.net/project/showfiles.php?group_id=16572
- Source only:
http://search.cpan.org/~robertmay/Win32-GUI-1.04/
Release notes:
https://sourceforge.net/project/shownotes.php?release_id=455710
RELEASE NOTES AND CHANGES
NAME
Win32::GUI::ReleaseNotes::RN_1_04 - This is the release notes for
Version 1.04 of Win32::GUI
Release Date
15th October, 2006.
IMPORTANT INFORMATION
This section details issues that are essential to understand when
upgrading from earlier versions of Win32::GUI.
Exported Constants
The way that Win32::GUI exports constants has changed. Ensure that you
read the "Deprecated feature status" section of this document so that
you understand the backwards compatibility issues.
Dual-life modules
This version of Win32::GUI includes the modules Win32::GUI::AxWindow,
Win32::GUI::DIBitmap, Win32::GUI::Grid, and Win32::GUI::Scintilla
(originally by Laurent Rocher: <http://rocherl.club.fr/Win32GUI.html>).
Please uninstall any previous versions of these modules that you may
have installed before installing this version of Win32::GUI.
Summary of Changes
This is a summary of changes between V1.03 and V1.04 See the CHANGELOG
file in the distribution for the full detail.
New Features
New Packages
Win32::GUI::AxWindow
Win32::GUI::Constants
Win32::GUI::DIBitmap
Win32::GUI::DropFiles
Win32::GUI::Grid
Win32::GUI::Scintilla
Win32::GUI::ReleaseNotes
New Methods
Win32::GUI
Acceptfiles (Tracker: 1323988), Animate (Tracker: 1266930),
ClassData, GetKeyState, SetWindowPos (Tracker: 1469648).
Win32::GUI::Region
ExtCreateRegion (Tracker: 1469648), GetRegionData.
Win32::GUI::Tooltip
AdjustRect, GetBubbleSize, SetTitle.
New Events
For all Windows
DropFiles (Tracker: 1323988).
New Documentation
Win32::GUI::ListBox
Better documentation for the differences between SetCurSel and
SetSel (Tracker: 1177898).
Win32::GUI::Textfield
Correct documentation for -autohscroll and -autovscroll.
Win32::GUI::Tooltip
Complete documentation for the Win32::GUI::Tooltip class
Other Features
Better dialog navigation for Textfields
<TAB> can now be used to move out of a multi-line Textfield when
using the -dialogui option on a Window.
A -wantreturn option has been added to stop the <RETURN> key firing
the default Click event for a multi-line Textfield when using the
-dialogui option on a Window. This replaces the previous use of
"-addstyle => ES_WANTRETURN".
Ballon tooltips for NotifyIcon
The Win32::GUI::NotifyIcon package has been re-worked. There is now
no need to use the -id option, and balloon tooltips are
supported on
Win2k and above. (Tracker: 1065072)
More options for Win32::GUI::DoEvents()
It is now possible to select which messages you want to process
with
DoEvents.
More ways to create cursors, icons and bitmaps
The Cursor, Icon and Bitmap constructors have been enhanced to
allow
creation from resources, including the "standard" windows
resources.
See the standard_images.pl sample to browse the standard resources.
Easier way to browse and run the demos
A new script win32-gui-demos will be installed in your perl bin
directory. You should be able to get a full list of the sample code
distributed with Win32::GUI, view the source and run the demos by
typing "win32-gui-demos" at your command prompt.
Better Splitter implementation
The Win32::GUI::Splitter implementation has been re-written to
provide more robust operation. The splitter bar can no longer be
moved outside the parent window, which used to result in drawing
problems, and the bar itself is now more nicely drawn.
(Tracker:1363141)
The -background option now works for splitter windows.
Better behaviour from LoadLibrary
The Win32::GUI::LoadLibrary() function has been enhanced so that it
converts any passed path to a Win32 representation before trying to
use it. Specifically this means that slashes are canonicalised to
'"\"', and under Cygwin, cygwin style paths are converted to Win32
paths.
Complete re-work of Tooltip class
The Win32::GUI::Tooltip implementation has been re-worked to allow
all the features to be used, and now there should be no crashes
with
many of the methods which had been incorrectly implemented. The new
implementation should be backwards compatible with what was there
before, but read the documentation to find out about all the new
features you can use.
The constructor has some new options "-nofade", "-noamimate"
and the
"-balloon" option is documented. "-balloon" option along with the
new SetTitle method allows you to make use of balloon tooltips.
The events (NeedText, Pop, Show) now have a second parameter
allowing you to correctly determine if the first parameter is a
window handle or a tool id.
Bug Fixes
Reported Bugs
Fix some crashes (Trackers 1243378 and 1248578)
Fix some memory leaks (Tracker: 1201190)
Fix drawing problems with coloured backgrounds (Tracker:1363141)
Other Bugs
-background and -foreground options now work for RichEdit windows
The SendMessageTimout implementation now matches the documentation
-truncate option now works correctly for Label windows
SetTabStops() method now works for ListBox windows
The demo code all works
Fix memory leak in Win32::GUI::DIBitmap::AlphaCopyToDC method
Deprecated feature status
This section documents features that have been deprecated in this
release, or in recent releases, and feature that will be deprecated in
up-coming releases.
Win32::GUI::Constants
The introduction of Win32::GUI::Constants means that we now have access
to a very large number of constants, so the current behaviour of
Win32::GUI to export all constants to the calling namespace by default
is no longer appropriate. So, a bare
use Win32::GUI;
now generates a warning that the old default behaviour will be
deprecated - although the export behaviour of Win32::GUI 1.03 is
maintained except for this warning.
To eliminate this warning and correct your script, do one of the
following:
If you don't need any constants, use the empty list:
use Win32::GUI();
If you need some constants, name them explicitly:
use Win32::GUI qw(ES_WANTRETURN CW_USEDEFAULT); # Two
constants exported
use Win32::GUI qw(/^MB_/); # Export all constants starting
with MB_
See the Win32::GUI::Constants documentation for the full allowable
syntax.
You are advised to fix your scripts now, as the next version will stop
exporting any constants by default.
Although not advised, you can suppress the warnings by turning
deprecated warnings off:
no warnings 'deprecated';
Additionally accessing constants from within the Win32::GUI
namespace is
deprecated. I.e.
-addstyle => Win32::GUI::WS_BORDER,
will generate a warning with this release, and will stop working with
the next release. Use one of the following methods instead:
use the Win32::GUI::Constants namespace instead
-addstyle => Win32::GUI::Constants::WS_BORDER(),
use any other namespace you fancy
use Win32::GUI qw(-exportpkg => A::B -autoload);
...
-addstyle => A::B::WS_BORDER(),
maintain compatibility of existing scripts
use Win32::GUI::Constants qw(-exportpkg => Win32::GUI
:compatibility_win32_gui);
...
-addstyle => Win32::GUI::WS_BORDER,
Win32::GUI::NotifyIcon
It is no longer necessary to use the '-id' option to any of the
Win32::GUI::NotifyIcon methods. The ID is now entirely handled
internally. You will receive deprecated warnings if you use it.
In particular, removing Icons from the system tray should be done using
$NI->Remove();
and not by the (now deprecated)
$NI->Delete(-id => 1);
Removal of GUI:: namespace
For at least the last 6 years the Win32::GUI namespace has been aliased
to the GUI namespace for backwards compatibility with very early
scripts. This aliasing has been removed, and any remaining scripts will
need updating.
Contributors to this release
Robert May
Reini Urban
Jeremy White
------------------------------
Date: Mon, 16 Oct 2006 16:27:01 -0400
From: brian d foy <brian.d.foy@gmail.com>
To: "Brian McCauley" <nobull67@gmail.com>
Subject: Re: FAQ 4.36 How can I expand variables in text strings?
Message-Id: <161020061627015569%brian.d.foy@gmail.com>
[[ This message was both posted and mailed: see
the "To," "Cc," and "Newsgroups" headers for details. ]]
In article <1160816617.713814.66790@m7g2000cwm.googlegroups.com>, Brian
McCauley <nobull67@gmail.com> wrote:
> On Oct 13, 2:03 am, PerlFAQ Server <b...@stonehenge.com> wrote:
> >
> > You can use a substitution with a double evaluation. The first /e turns
> > $1 into $foo, and the second /e turns $foo into its value. You may want
> > to wrap this in an "eval": if you try to get the value of an undeclared
> > variable while running under "use strict", you get a fatal error.
> >
> > eval { $text =~ s/(\$\w+)/$1/eeg };
> > die if $@;
> Agghh!!!! Will nobody ever fix this FAQ!
If it needs fixing, I will do it.
Checking the archives I see that you and I talked about this a long
time ago, but by the time you submitted a patch to perlfaq-workers, I
was gone on my Long Camping Trip. I don't remember if I ever saw your
patch. Sorry for the inconvenience....
I'm the one who added the eval { }. I'm not sure of the situation at
the time or which version of Perl I was using, but I do test these
things before they get in there. I could have made a mistake, or
whatever problem there was might have changed since then. Either way,
the new answer removes the eval { }.
http://www.nntp.perl.org/group/perl.perlfaq.workers/403
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: 16 Oct 2006 11:15:33 -0700
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: I have no problems eating cereal...after it softens. Why is replacing a simple string so hard then?
Message-Id: <1161022533.830968.274930@m73g2000cwd.googlegroups.com>
sam...@mytrashmail.com wrote:
> Paul Lalli wrote:
> > sam...@mytrashmail.com wrote:
> > > Paul Lalli wrote:
> > > > samiam@mytrashmail.com wrote:
> > No. You're still not understanding. Without a =~ operator, the bare
> > /match/ syntax ALWAYS makes a comparison to $_. You then assign the
> > results of that pattern match to another variable. You're using a
> > shortcut without realizing it. Expanding that line for completeness
> > would be:
> > $origtext = ( $_ =~ m/<form[.*]?*\/form>/);
>
>
> 888888888888888888
> Oh...I was just thinking that if I do an assign like:
>
> $origtxt= '/foo(.*.bar/'
> then I could do a match =~ preceding or subsequent in the code
No, you can't, but for a different reason. What you've typed here is
COMPLETELY DIFFERENT than your original. Those quotes make ALL the
difference. Yet another reason to use strict, and have it tell you
when you're using a bareword. When you say:
$origtext = /foo(.*)bar/;
that's assigning $origtext to the result of that pattern match applied
to $_
When you say:
$origtext = qr/foo(.*)bar/;
that's assigning $origtext to be a regular expression you will later
applie to some string.
Now this new one you've introduced is:
$origtext = '/foo(.*)bar/';
This one is a string that contains your original pattern plus two
slashes. Those slashes are no long pattern match delimiters. Now
they're part of the string. If you were to later use this string
within a regular expression, you would be looking for the slashes as
well as foo and bar.
> but you are saying the match occurs the exact time the assign line is
> processed: there is not consider previous matches in code above or
> subsequent matches in the code below, because if one is not explicit in
> this assign statement, a match will be made against $_
It's not the assignment that's implicit, it's the binding.
$foo = 'bar'; #assigning 'bar' to $foo
$foo =~ /bar/; #binding the pattern /bar/ to the string $foo.
"Assignment" means to make that variable have that value. "Binding"
means to apply a pattern match to an existing string.
> So, I have learned that one must identify and consider what $_ is
> holding and realize it is being compared with any /regex/ at the exact
> time the /regex/ is evaluated. right?
If and only if you type a pattern match operator without binding it to
another string.
> > > In the same way I could assign a string to $orgtext, can't I assign a
> > > regex to it for comparison to another variable or string later in the
> > > script?
> >
> > Yes you can, but that is not what your syntax above does. If you want
> > to assign a regular expression to a variable, you have to use the qr//
> > operator, not the m// operator (which is what empty slashes implicitly
> > are):
>
> 8888888888
>
> ooooohhhhhh....anytime one uses /foobar/ an m/foobar/ is always
> implied. Hmmm, there is such inconsistent use, I inferred that each
> was different, especially since I read that the m/foo/ means one can
> use alternate delimiters.
Yes it does. You can use any non-alphanumeric characters as delimters.
The slashes are the default delimiter. If you choose to use these
default delimiters, you are permitted to drop the 'm'. Both of these
facts (the implicit binding to $_ and the dropping of 'm') are spelled
out fairly clearly in perldoc perlop:
======================================
m/PATTERN/cgimosx
/PATTERN/cgimosx
Searches a string for a pattern match, and in scalar
context returns true if it succeeds, false if it
fails. If no string is specified via the "=~" or
"!~" operator, the $_ string is searched.
<snip>
If "/" is the delimiter then the initial "m" is
optional. With the "m" you can use any pair of
non-alphanumeric, non-whitespace characters as
delimiters.
======================================
> But again, I misunderstood what I read?
> Perhaps the m/foo/ or s/foo/ have to be explicit to use alternate
> delimiters such as m!foo! or s!foo! ?
Correct. If you want to choose alternate delimiters, you MUST use the
m. You must ALWAYS use the s for a s/// operation. Dropping that is
never permitted, even if you use the / as the delimiter.
> > to assign a regular expression to a variable, you have to use the qr//
>
> Now that's something I have not come across in any of my tutorials or
> perldocs.
perldoc perlop
================================================
qr/STRING/imosx
This operator quotes (and possibly compiles) its
STRING as a regular expression. STRING is
interpolated the same way as PATTERN in
"m/PATTERN/". If "'" is used as the delimiter, no
interpolation is done. Returns a Perl value which
may be used instead of the corresponding
"/STRING/imosx" expression.
================================================
> Thanks Paul! It would have taken me a much longer time to
> find this bit...although...I bet it doesn't work the way I think it
> does :)
Well, I can't speak to that as I don't know how you think it works. It
works exactly as specified in the above documentation, however....
> > Likewise, if you do:
> > $origtext = ($_ =~ m/<form>.*<\/orm>/);
> > you are assigning $orig text to be either 1 or the empty string,
> > depending on whether or not the pattern was found in $_. And as
> > already noted, the above can be reduced through some shortcuts to:
> > $origtext = /<form>.*<\/form>/;
>
> $origtext = ($_ =~ m/<form>.*<\/orm>/); THIS equals
> $origtext = /<form>.*<\/form>/; THIS
Correct, though I'd probably say that in the opposite order. The
second one expands internally to the first....
> Oh...it just occurred to me that you are using a fancy newreader like
> Agent, which parses the >>>> maybe? And that's why my otherwise
> conspicuously helpful unique idents (8888) have no value for you?
There is nothing fancy about Google Groups, I assure you. >>> is a
standard visual indicator for pretty much all Usenet and email mediums.
> A 20 year Perl veteran at work recommended I read these Perl books in
> this order:
>
> 1.) Beginning Perl
> 2.) Perl Best Practices
>
> Then use Programming Perl and Perl Cookbook as needed.
> I thought I might also make Perl, a Problem Solution approach a 1.5 on
> the list?
PBP is great for learning how to make robust well written Perl
programs. It's not a reference. You can't "look up" any feature of
the language in it. I can't speak to the other two as I've never read
them.
> I had a long talk with Mr. Twenty Year Perl Veteran (TYPV) and he said
> that everyone goes through the stage of "Why can't regex be used to
> process multi-line html files?"
>
> And he said I just needed to go through it, take my lumps, and
> eventually learn that cpan and modules are my best friends. He said,
> ALWAYS use a module to parse any html and any multiple line data. He
> said he scours CPAN and uses modules for most everything.
Mr TYPV is a very knowledgable and intelligent man. Follow his advice.
:-)
> I told him I tried using HMLT parser, since deprecated but now a
> wrapper for the Treebuilder module. I mentioned the documents were a
> bit cryptic if not sparse.
I don't know what you mean by "HMLT parser". If you meant
HTML::Parser, then I agree with you. I prefer HTML::TokeParser myself.
Also available on CPAN. In fact, if you downloaded and installed
HTML::Parser, you probably got HTML::TokeParser in the bundle.
> He agreed and said that's just the way it was...but I would have to
> learn how to use the modules in spite of this. He made a big
> impression enough for me to think:
>
> Just don't:
> 1.) Use regex for anything more than a simple replace
Disagree. Regexps can be arbitrarily complicated. They just take
practice.
> 2.) Never attempt to parse html without a module
Agree. HTML is not a regular-enough format for a RegExp to be able to
parse it.
> 3.) Never try to parse multi-line code without a module.
Disagree. A RegExp can parse multi-line data just fine, so long as you
make sure the string you're matching against actually *is* multiline,
and you're not just trying to match one line at a time.
> But modules are going to be the steepest learning curve I think. I
> think one has to pretty much know Perl very well to even begin to
> understand the Module docs?
"has to", no. But it helps.
Paul Lalli
------------------------------
Date: Mon, 16 Oct 2006 13:52:06 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: I have no problems eating cereal...after it softens. Why is replacing a simple string so hard then?
Message-Id: <slrnej7l6m.c7g.tadmc@magna.augustmail.com>
samiam@mytrashmail.com <samiam@mytrashmail.com> wrote:
> Aren't my comments much easier to locate if identified with a new
> string?
No.
They are easier to locate if they are marked the way everybody
else marks them.
Namely with another level of > character.
> A 20 year Perl veteran at work recommended I read these Perl books in
^^^^^^^^^^^^^^^^^^^^
> this order:
Perl was first released on 1987-Dec-18 (perldoc perlhist), so that
level of experience is quite a trick...
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 16 Oct 2006 13:59:46 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: I have no problems eating cereal...after it softens. Why is replacing a simple string so hard then?
Message-Id: <slrnej7ll2.c7g.tadmc@magna.augustmail.com>
samiam@mytrashmail.com <samiam@mytrashmail.com> wrote:
>> > And a sample is at the very bottom of this post. I just want to replace
>> > /<form[.*]?*\/form>/ with the word "block"
>>
>>
>> That is not a "simple string". That is markup. A robust solution
>> requires a Real Parser rather than a pattern match (which is only
>> good for a dirty hack).
>
> jjjjjjjjjjjjjjj: Well, with all the examples I've read in the tutorial,
> ie perdocs, I felt drunk with power and thought regexes could easily
> handle any string multi-line or not.
Regular expressions can handle string in a Regular Grammar.
HTML is not a Regular Grammar, it is a Context Free Grammar.
When you get your code working, see if it does the right
thing with this data:
<!--
<form> there IS NO form element here!</form>
-->
>> Why did you include the square brackets?
>>
>> They are not doing what you think they are doing.
>
>
> jjjjjjjjjjjjjjjjjj: I just love this line - "They are not doing what
> you think they are doing."
So what you should then do, is go read up on them and find out
what the really do.
> I thought the brackets isolated that inside them as a whole to apply to
> the first precedent. I thought I read this in the perl docs.
They are still not doing what you think they are doing.
>> You should put quotes around your strings.
> jjjjjjjjjjjjjjjjjjjjjj: I know...
Then you should put quotes around your strings.
>> Since you don't have a proper binding operator (=~) the pattern
>> is NOT attempting to match against the string in $orgtext, it
>> is trying to match the string in $_, and it appears you do not
>> have a string in there.
>
> jjjjjjjjjjjjjjjjjjjjjj: but since I was not trying to match
If you use the m// operator, then you *are* trying to match.
That is what using the m// operator means.
If you do not want to match, then do not use the m// operator.
> I am surprised there isn't just a:
>
> Start at <form
> read until one gets to </form> regardless of /n /t or anything else
> remove all of it.
>
> If this is not simple...it should be.
You need a better understanding of the data that you are processing.
>> --
>> Tad McClellan SGML consulting
>> tadmc@augustmail.com Perl programming
>> Fort Worth, Texas
It is rude to quote .sigs. Please do not do that.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 16 Oct 2006 12:50:10 -0700
From: samiam@mytrashmail.com
Subject: Re: I have no problems eating cereal...after it softens. Why is replacing a simple string so hard then?
Message-Id: <1161028210.685385.60100@b28g2000cwb.googlegroups.com>
Well...I don't know him very well at all and I tend to keep a stiff
upper lip at work. I prefer to forge my way outside of work, bring
value to the workplace...and if someone is amenable at work to helping
me...fine....but work is the last place where I want to voice my
experimental opinions on code. hope you can relate to that
sensitivity.
In other words - don't you guys go away!!!
Believe it or not, just THIS ONE THREAD has taken me light years from
where I was a few days ago.
I agree with your words Uri - I undoubtedly mis-represented the TYPV -
. He is extremely well paid, and handles major Perl projects with
apparent ease. So if he doesn't look good...it's only because I was his
representative. In fact Uri, you and he would probably get a long great
:)
thanks for the reponse!
L,
Samiam
Uri Guttman wrote:
> >>>>> "s" == samiam <samiam@mytrashmail.com> writes:
>
> s> Aren't my comments much easier to locate if identified with a new
> s> string?
>
> s> inline comments found near 888888888888
>
> a very useless thing. your comments are already demarked by lacking >
> prefixes. notice how no one else needs to do that?
>
> s> 88888888888888
> s> I had a long talk with Mr. Twenty Year Perl Veteran (TYPV) and he said
> s> that everyone goes through the stage of "Why can't regex be used to
> s> process multi-line html files?"
>
> s> Just don't:
> s> 1.) Use regex for anything more than a simple replace
>
> bullshit. why replace only? matching is fine. and you can do very
> complex and powerful things in regexes. no need to restrict them to
> simple stuff. you have to learn what they can do and how do use them
> properly. you have a long way to go there.
>
> s> 2.) Never attempt to parse html without a module
>
> bullshit. in most cases that is correct but there are some where using
> PROPERLY written regexes on FIXED (you know they won't change) html is
> ok. but again, you have to know where and when this can work.
>
> s> 3.) Never try to parse multi-line code without a module.
>
> major bullshit. it all depends on the format of the file. even multiline
> things in a file can be handled by regexes without modules. and you will
> find many file formats without any modules to parse them. one more
> time, you have to learn when and where to use a module to parse vs using
> regexes and other stuff.
>
> looks like your 20 year perl vet (and that makes little sense as perl is
> barely that old if it is 20) isn't giving you good advice. and if he is
> so good, why do you keep coming here for help?
>
> s> But modules are going to be the steepest learning curve I think. I
> s> think one has to pretty much know Perl very well to even begin to
> s> understand the Module docs?
>
> huh???
>
> uri
>
> --
> Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
> --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
> Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 16 Oct 2006 13:01:32 -0700
From: samiam@mytrashmail.com
Subject: Re: I have no problems eating cereal...after it softens. Why is replacing a simple string so hard then?
Message-Id: <1161028892.162170.221690@h48g2000cwc.googlegroups.com>
comments inline with bbbbbbbbbbbb
Paul Lalli wrote:
> sam...@mytrashmail.com wrote:
>
> > Paul Lalli wrote:
> > > sam...@mytrashmail.com wrote:
> > > > Paul Lalli wrote:
> > > > > samiam@mytrashmail.com wrote:
>
> > > No. You're still not understanding. Without a =~ operator, the bare
> > > /match/ syntax ALWAYS makes a comparison to $_. You then assign the
> > > results of that pattern match to another variable. You're using a
> > > shortcut without realizing it. Expanding that line for completeness
> > > would be:
> > > $origtext = ( $_ =~ m/<form[.*]?*\/form>/);
> >
> >
> > 888888888888888888
> > Oh...I was just thinking that if I do an assign like:
> >
> > $origtxt= '/foo(.*.bar/'
> > then I could do a match =~ preceding or subsequent in the code
>
> No, you can't, but for a different reason. What you've typed here is
> COMPLETELY DIFFERENT than your original. Those quotes make ALL the
> difference. Yet another reason to use strict, and have it tell you
> when you're using a bareword. When you say:
> $origtext = /foo(.*)bar/;
> that's assigning $origtext to the result of that pattern match applied
> to $_
> When you say:
> $origtext = qr/foo(.*)bar/;
> that's assigning $origtext to be a regular expression you will later
> applie to some string.
> Now this new one you've introduced is:
> $origtext = '/foo(.*)bar/';
> This one is a string that contains your original pattern plus two
> slashes. Those slashes are no long pattern match delimiters. Now
> they're part of the string. If you were to later use this string
> within a regular expression, you would be looking for the slashes as
> well as foo and bar.
>
> > but you are saying the match occurs the exact time the assign line is
> > processed: there is not consider previous matches in code above or
> > subsequent matches in the code below, because if one is not explicit in
> > this assign statement, a match will be made against $_
>
> It's not the assignment that's implicit, it's the binding.
> $foo = 'bar'; #assigning 'bar' to $foo
> $foo =~ /bar/; #binding the pattern /bar/ to the string $foo.
>
> "Assignment" means to make that variable have that value. "Binding"
bbbbbbbbbbbbbbbbbb
Ahhh....I recognized the logic but didn't know it was called "binding."
Thanks.
> means to apply a pattern match to an existing string.
>
> > So, I have learned that one must identify and consider what $_ is
> > holding and realize it is being compared with any /regex/ at the exact
> > time the /regex/ is evaluated. right?
>
> If and only if you type a pattern match operator without binding it to
> another string.
>
> > > > In the same way I could assign a string to $orgtext, can't I assign a
> > > > regex to it for comparison to another variable or string later in the
> > > > script?
> > >
> > > Yes you can, but that is not what your syntax above does. If you want
> > > to assign a regular expression to a variable, you have to use the qr//
> > > operator, not the m// operator (which is what empty slashes implicitly
> > > are):
bbbbbbbbbbbbbbbb
Yes...I believe I get it now. I am looking up each salient point you
raise in the perldocs.
You have spared me a lot of confused wandering!
> >
> > 8888888888
> >
> > ooooohhhhhh....anytime one uses /foobar/ an m/foobar/ is always
> > implied. Hmmm, there is such inconsistent use, I inferred that each
> > was different, especially since I read that the m/foo/ means one can
> > use alternate delimiters.
>
> Yes it does. You can use any non-alphanumeric characters as delimters.
> The slashes are the default delimiter. If you choose to use these
> default delimiters, you are permitted to drop the 'm'. Both of these
> facts (the implicit binding to $_ and the dropping of 'm') are spelled
> out fairly clearly in perldoc perlop:
> ======================================
> m/PATTERN/cgimosx
> /PATTERN/cgimosx
> Searches a string for a pattern match, and in scalar
> context returns true if it succeeds, false if it
> fails. If no string is specified via the "=~" or
> "!~" operator, the $_ string is searched.
> <snip>
> If "/" is the delimiter then the initial "m" is
> optional. With the "m" you can use any pair of
> non-alphanumeric, non-whitespace characters as
> delimiters.
> ======================================
>
>
> > But again, I misunderstood what I read?
> > Perhaps the m/foo/ or s/foo/ have to be explicit to use alternate
> > delimiters such as m!foo! or s!foo! ?
>
> Correct. If you want to choose alternate delimiters, you MUST use the
> m. You must ALWAYS use the s for a s/// operation. Dropping that is
> never permitted, even if you use the / as the delimiter.
>
> > > to assign a regular expression to a variable, you have to use the qr//
> >
> > Now that's something I have not come across in any of my tutorials or
> > perldocs.
>
> perldoc perlop
bbbbbbbbbbbbbbbbb
I actually beat you to this doc, though I hadn't yet come to this
section :-)
> ================================================
> qr/STRING/imosx
> This operator quotes (and possibly compiles) its
> STRING as a regular expression. STRING is
> interpolated the same way as PATTERN in
> "m/PATTERN/". If "'" is used as the delimiter, no
> interpolation is done. Returns a Perl value which
> may be used instead of the corresponding
> "/STRING/imosx" expression.
> ================================================
>
> > Thanks Paul! It would have taken me a much longer time to
> > find this bit...although...I bet it doesn't work the way I think it
> > does :)
>
> Well, I can't speak to that as I don't know how you think it works. It
> works exactly as specified in the above documentation, however....
>
> > > Likewise, if you do:
> > > $origtext = ($_ =~ m/<form>.*<\/orm>/);
> > > you are assigning $orig text to be either 1 or the empty string,
> > > depending on whether or not the pattern was found in $_. And as
> > > already noted, the above can be reduced through some shortcuts to:
> > > $origtext = /<form>.*<\/form>/;
> >
> > $origtext = ($_ =~ m/<form>.*<\/orm>/); THIS equals
> > $origtext = /<form>.*<\/form>/; THIS
>
> Correct, though I'd probably say that in the opposite order. The
> second one expands internally to the first....
> > Oh...it just occurred to me that you are using a fancy newreader like
> > Agent, which parses the >>>> maybe? And that's why my otherwise
> > conspicuously helpful unique idents (8888) have no value for you?
>
> There is nothing fancy about Google Groups, I assure you. >>> is a
> standard visual indicator for pretty much all Usenet and email mediums.
>
> > A 20 year Perl veteran at work recommended I read these Perl books in
> > this order:
> >
> > 1.) Beginning Perl
> > 2.) Perl Best Practices
> >
> > Then use Programming Perl and Perl Cookbook as needed.
> > I thought I might also make Perl, a Problem Solution approach a 1.5 on
> > the list?
>
> PBP is great for learning how to make robust well written Perl
> programs. It's not a reference. You can't "look up" any feature of
> the language in it. I can't speak to the other two as I've never read
> them.
>
> > I had a long talk with Mr. Twenty Year Perl Veteran (TYPV) and he said
> > that everyone goes through the stage of "Why can't regex be used to
> > process multi-line html files?"
> >
> > And he said I just needed to go through it, take my lumps, and
> > eventually learn that cpan and modules are my best friends. He said,
> > ALWAYS use a module to parse any html and any multiple line data. He
> > said he scours CPAN and uses modules for most everything.
>
> Mr TYPV is a very knowledgable and intelligent man. Follow his advice.
> :-)
bbbbbbbbbbbbbbbbbbbb
Please....God....don't let me be accidentally talking with a
co-worker.....Please....God....
Whenever I hear compliments like that flowing, makes me wonder....uh
oh...it's the man himself!!
>
> > I told him I tried using HMLT parser, since deprecated but now a
> > wrapper for the Treebuilder module. I mentioned the documents were a
> > bit cryptic if not sparse.
>
> I don't know what you mean by "HMLT parser". If you meant
> HTML::Parser, then I agree with you. I prefer HTML::TokeParser myself.
> Also available on CPAN. In fact, if you downloaded and installed
> HTML::Parser, you probably got HTML::TokeParser in the bundle.
>
> > He agreed and said that's just the way it was...but I would have to
> > learn how to use the modules in spite of this. He made a big
> > impression enough for me to think:
> >
> > Just don't:
> > 1.) Use regex for anything more than a simple replace
>
> Disagree. Regexps can be arbitrarily complicated. They just take
> practice.
>
> > 2.) Never attempt to parse html without a module
>
> Agree. HTML is not a regular-enough format for a RegExp to be able to
> parse it.
>
> > 3.) Never try to parse multi-line code without a module.
>
> Disagree. A RegExp can parse multi-line data just fine, so long as you
> make sure the string you're matching against actually *is* multiline,
> and you're not just trying to match one line at a time.
>
> > But modules are going to be the steepest learning curve I think. I
> > think one has to pretty much know Perl very well to even begin to
> > understand the Module docs?
>
> "has to", no. But it helps.
>
>
> Paul Lalli
Thanks for your help Paul!!!
L,
Samiam
------------------------------
Date: 16 Oct 2006 13:04:19 -0700
From: samiam@mytrashmail.com
Subject: Re: I have no problems eating cereal...after it softens. Why is replacing a simple string so hard then?
Message-Id: <1161029059.304949.122440@b28g2000cwb.googlegroups.com>
Well, he's been doing something akin to his present work -so there may
be a slight heterogeneous blend.
But I am on google so I don't know if it will auto >>>> my comments.
And, respectfully, it's easier for me and friends to use distinct
comment marks. The >>> upon >>>>>>>> get a little hazy after a while.
Of course, YMMV :-)
L,
S
Tad McClellan wrote:
> samiam@mytrashmail.com <samiam@mytrashmail.com> wrote:
>
> > Aren't my comments much easier to locate if identified with a new
> > string?
>
>
> No.
>
> They are easier to locate if they are marked the way everybody
> else marks them.
>
> Namely with another level of > character.
>
>
> > A 20 year Perl veteran at work recommended I read these Perl books in
> ^^^^^^^^^^^^^^^^^^^^
> > this order:
>
>
> Perl was first released on 1987-Dec-18 (perldoc perlhist), so that
> level of experience is quite a trick...
>
>
> --
> Tad McClellan SGML consulting
> tadmc@augustmail.com Perl programming
> Fort Worth, Texas
------------------------------
Date: Mon, 16 Oct 2006 15:57:45 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: I have no problems eating cereal...after it softens. Why is replacing a simple string so hard then?
Message-Id: <slrnej7si9.cip.tadmc@magna.augustmail.com>
samiam@mytrashmail.com <samiam@mytrashmail.com> wrote:
> And, respectfully, it's easier for me and friends
That is fine by me, as I have now taken the appropriate action.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 V10 Issue 9854
***************************************
