Re: 5.8.0
Mark Fowler sent the following bits through the ether: > P.S. 5.6.0? Shall I get you some rocks to bash together too? That was an interesting thread. Now, it's really easy to have multiple version of Perl running on the same box (let's ignore mod_perl for now ;-) so why hasn't everyone done so? I know I'm very lazy, but what's your excuse? Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... All new improved Brocard, now with Template Toolkit!
RE: re-animating regexes
On Wednesday, November 27, 2002 6:50 PM, Mark [SMTP:[EMAIL PROTECTED]] wrote: > I checked if similar would happen with Data::Dumper. From a quick test, > looks like this may allow you to do what you want, if appropriate bits > added to the freeze/thaw subs. > > [mmorgan]$ perl -MData::Dumper -le '$a=qr/a+b/; $b = eval( Dumper $a ); > print /$b/ ? "yep" : "nope" foreach ( "acb", "abc" )' > nope > yep > > The version of Data::Dumper being used is 2.102. This was only a quick > test, and I've not looked into it too deeply, so YMMV. :) > Not sure if this would prove anything as $b does not have to be a Regexp object - it would work just as well as a string. Another niggle: /me avoids $a and $b like the plague, as they have special meaning to sort. Ivor.
Re: 5.8.0
That was an interesting thread. Now, it's really easy to have multiple version of Perl running on the same box (let's ignore mod_perl for now ;-) so why hasn't everyone done so? I know I'm very lazy, but what's your excuse? You make that sound like a good thing... It's easy to have multiple versions of Java on a machine too. That's why I have production boxes with something like 5 or 6 different versions of Java (and different flavours of JVM, natch). It's a living hell. I'm not aware of any software* that comes with it's own particular supported version of Perl, but we don't want to encourage it. It's nifty that you can maintain separate trees of libraries too, but again we don't want to encourge people bundling the supported versions of common modules with their apps so we get $CLASSPATH hell for perl too. Boo for implementing compatability via emulation** or glorified ifdefs Yay for progress. Upgrade and update! :) *I know there used to be some Cisco stuff that bundled Perl4 or something at some point. Ick. ** Yeah that means you Cygwin. Die die die. -- Jonathan Peterson Technical Manager, Unified Ltd, +44 (0)20 7383 6092 [EMAIL PROTECTED]
Re: 5.8.0
On Thu, 28 Nov 2002, Leon Brocard wrote:
> Now, it's really easy to have multiple version of Perl running on the
> same box (let's ignore mod_perl for now ;-) so why hasn't everyone done
> so?
What do you mean, it's really easy to have multiple versions of perl?
Sure I can install as many copies as I want all over the shop, but only
one of them can be registered as "#!/usr/bin/perl". This means that I
have to explicitly set the shebang line and scripts arn't autoupgrading -
every time I install a new perl I'd have to go and change every single
perl script to point to the new version or they'd still be running on the
old.
OTOH, if I had something that only ran on an old version of perl, I supose
I could set up a old version of perl just for that. Of course, this is
going the other way - installing old perls for old software.
Richard has 'mirth' plugged into our house network that has pretty much
every version of perl installed on it (actually, it doesn't have any
version of 2, 3 or 4...but there you go.) This is useful for regression
testing, but *boy* is it a pain to install a module on each of those.
That's enough to put me off multiple versions of perl for a start. Once
I've installed a moudule I want it to be installed on all the perls.
> I know I'm very lazy, but what's your excuse?
We're Perl programmers. Of course we're lazy.
Mark.
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t->Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t->Tgoto(cm,$_,$y)." $w";select$k,$k,$k,.03}$y+=2}
Re: 5.8.0
On Thu, Nov 28, 2002 at 11:16:06AM +, Mark Fowler wrote: > Richard has 'mirth' plugged into our house network that has pretty much > every version of perl installed on it (actually, it doesn't have any > version of 2, 3 or 4...but there you go.) This is useful for regression > testing, but *boy* is it a pain to install a module on each of those. > That's enough to put me off multiple versions of perl for a start. Once > I've installed a moudule I want it to be installed on all the perls. I've just done (literally) this at work: for file in `ls /usr/local/bin/perl5.8.0* | grep -- - | grep -v g | tail +2`; do $file Makefile.PL && make all test && su root -c 'make install'; done the slightly clearer version without the shell lines to strip out the 3 perls I wasn't interesting in installing to would be: for file in `ls /usr/local/bin/perl5.8.0*`; do $file Makefile.PL && make all test && su root -c 'make install'; done > We're Perl programmers. Of course we're lazy. I can be lazy in /bin/sh too. :-) I think to be properly lazy I need something like sudo to save me having to type the root password in for each install above. Nicholas Clark
Re: 5.8.0
On Thu, 28 Nov 2002 08:19:12 +, Leon Brocard wrote: > Now, it's really easy to have multiple version of Perl running on the same > box (let's ignore mod_perl for now ;-) so why hasn't everyone done so? I > know I'm very lazy, but what's your excuse? Laziness and forgetfulness. And being unable to get testing time scheduled. mod_perl isn't an issue if you have a separate backend server for each version of perl :-) Actually, I'm not entirely joking. Even with the same perl/apache/mod_perl versions, we have a separate backend for each service (though there's only one server with more than one service at the moment). Is that bad? -- Peter Haworth [EMAIL PROTECTED] "An IRC channel, in ERROR?! On Undernet no less?! THE DEUCE YOU SAY!! Next thing you're going to tell me the commentary on Slashdot isn't totally impartial!" -- Michael G Schwern
Re: REVIEW: Extending and Embedding Perl
On Wed, Nov 27, 2002 at 10:36:04PM +, Mark Fowler wrote: [reference counting] > Could you, or anyone else, give me a pointer to where this kind of thing > is documented? L, plus, if you're writing some XS and think that you're leaking something, you can always try Devel::LeakTrace (if the something is SVs) or valgrind (if the something is regular malloced blocks). -- Richard Clamp <[EMAIL PROTECTED]>
Re: 5.8.0
On Thu, Nov 28, 2002 at 08:19:12AM +, Leon Brocard wrote: > Mark Fowler sent the following bits through the ether: > > P.S. 5.6.0? Shall I get you some rocks to bash together too? > That was an interesting thread. Now, it's really easy to have multiple > version of Perl running on the same box (let's ignore mod_perl for now > ;-) so why hasn't everyone done so? I know I'm very lazy, but what's > your excuse? My ibook running Jagwyre has 5.8.0 installed. Twice. Because for a previous version of MacOSX I had to compile 5.8 myself and when I upgraded the system- supplied perl must have gotten upgraded to the same version. Even so, my version is linked against different libraries so I'd quite like to keep it. On my server I have /usr/bin/perl as 5.00503 cos that's what debian 2.2 has, and /usr/local/bin/perl is 5.6.1. I don't need anything out of 5.8 so haven't bothered upgrading yet. -- David Cantrell | Member of the Brute Squad | http://www.cantrell.org.uk/david Any technology distinguishable from magic is insufficiently advanced
Re: REVIEW: Extending and Embedding Perl
On Wed, Nov 27, 2002 at 02:35:20PM +, Nicholas Clark wrote: > Review of "Extending and Embedding Perl" > > Author: Tim Jenness and Simon Cozens > ISBN: 1-930110-82-0 > Publisher: Manning > Reviewed by: Nicholas Clark > > > This is a long review. I could have said "the book is missing things that I > think should be there" and leave it at that. But it's trivial to say, easy to > dismiss, and impossible to follow. As I'm clear in my head about the specifics > of what I think is missing but relevant to the book's subject matter, I've > backed things up every time with examples. This makes a much longer review, > but hopefully much clearer to follow, and easier to understand why I hold > my opinions. Maybe it's more of a short article than a review, but it says what > I feel I need to say. Ouch. OK, I will come clean, I did do an early technical review of some parts to this book, but I did not see the completed thing or even if any of my input was taken. Heck I even gave a quote for the cover as I thought it was a very promising book. Having read this please tell me its not there as I have never received my free copy. Graham.
Re: REVIEW: Extending and Embedding Perl
On Thu, 28 Nov 2002, Graham Barr wrote:
> Heck I even gave a quote for the cover as I thought it was a very
> promising book. Having read this please tell me its not there as I have
> never received my free copy.
"Perl's internals and XS can be like black magic. [This] is the 'spell
book' you need to protect and guide yourself though the deepest bepths of
this subject"
-- Graham Barr, Author of the libnet package
Back of book. Also quotes from "Charles Bailey, Alasdair Allan, Abhijit
Menon-Sen and Norman Gray.
Mark.
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t->Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t->Tgoto(cm,$_,$y)." $w";select$k,$k,$k,.03}$y+=2}
vim
I'm playing with vim. Either it's standard perl syntax file doesn't support folding, or I can't get folding to work for some reason (setting fold method to syntax..). Vague comments about remedying either situation appreciated. J -- Jonathan Peterson Technical Manager, Unified Ltd, +44 (0)20 7383 6092 [EMAIL PROTECTED]
Re: REVIEW: Extending and Embedding Perl
On Wed, Nov 27, 2002 at 02:35:20PM +, Nicholas Clark wrote: > Review of "Extending and Embedding Perl" > > [snippety-snip] I have posted this on the web site, at: http://london.pm.org/reviews/extending-and-embedding-perl.html -- David Cantrell | Benevolent Dictator | http://www.cantrell.org.uk/david There is no sigmonster
Re: REVIEW: Extending and Embedding Perl
On Thu, Nov 28, 2002 at 11:45:13AM +, Richard Clamp wrote:
> On Wed, Nov 27, 2002 at 10:36:04PM +, Mark Fowler wrote:
> [reference counting]
> > Could you, or anyone else, give me a pointer to where this kind of thing
> > is documented?
>
> L, plus, if you're writing
> some XS and think that you're leaking something, you can always try
> Devel::LeakTrace (if the something is SVs) or valgrind (if the
> something is regular malloced blocks).
I don't really understand this stuff, but piecing together what I know
and a re-skim of the perl docs and source, I *think* that the summary is
0: "things" (SV, AV, HV, (etc?)) are refcounted - when the refcount hits 0
the "thing" is freed.
(which effectively means that their memory gets marked for re-use, so
you may not always see symptoms if you're prematurely freeing things.
it's got all the potential problems of C if you call free() and then
carry on accessing that memory)
but you need to return "things" from your code; and the things are pointers
that you, not your caller, owns, and so you are responsible for cleaning
them up. (like wanting to return a pointer to malloc()ed space from a C
function). Except that they need cleaning up some point after your code
has returned.
1: "mortal" describes a system for flagging a value for a deferred cleanup.
If you tell perl to make something "mortal", all it does is record on
a TODO list that the "thing" (SV, AV, HV, etc) should have its reference
count decreased by 1 at some later time. The later time corresponds to
"end of statement", ie C<;> in your perl script, or when C code runs
the macro FREETMPS; (defined in scope.h, calls Perl_free_tmps in scope.c)
Not all temporaries are freed; the stack of TODOs can have markers placed
on it to nest scopes, so processing is only for things mortalized since
the last marker was placed (using the ENTER; macro)
mortal doesn't mean automatically freeing something at scope exit; all it
does is decrease the reference count by 1. Things get freed (as a side
effect) if this decrease drops their reference count to zero. One
implication of this is that you can mark something as mortal more than
once - this just means it will get 1 future reference count decrease per
time you marked it.
2: aggregates such as references, AVs and HVs "own" a reference count on each
SV that they contain. So when their reference count drops to 0, they
relinquish ownership of all their contents, by decreasing each item's
reference count by one
[someone check this, please:]
3: so this means if you're returning a reference to an array or hash from
your XS code, you only need to mark the top level reference as mortal; when
that things reference count drops to zero, everything it owns is dropped
by one. (I believe that this means the example on page 366 of Advanced
Perl Programming is wrong - it makes everything it pushes into an array
mortal)
4: If you still own a pointer to something, because it's static and meant
to persist between calls to your routine, then you don't mortalise it.
But you need to clean it up at some point.
This is equivalent to returning a pointer to something you malloc()ed,
but your C code retains "ownership" because at some future point you will
free() it.
5: I believe that all the creation routines (newAV, newHV, the new SV
routines) return you something with a refcount of 1. ie you have to do
something with that reference, ie hold on to it and decrease it at your
cleanup; give it away to someone else ("somebody else's problem"); or
mark it mortal.
All the add it to something routines (store in HV or AV) don't increase
the refcount. They are assuming that you are giving them the reference.
If they fail (you did check the return code, didn't you?) it's still your
problem. [Perl_av_push() etc don't check]
The sole exception to this is newRV, which is now an alias to the more
descriptive newRV_inc, which creates a new SV holding a reference
(ie that SV has a reference count of 1) plus increments the reference count
of the thing you passed it. (being helpful, making an assumption)
use newRV_inc() or newRV_noinc() to make your intent clear.
Nicholas Clark
Re: REVIEW: Extending and Embedding Perl
At 28/11/2002 15:15 [], Mark Fowler wrote: On Thu, 28 Nov 2002, Graham Barr wrote: > Heck I even gave a quote for the cover as I thought it was a very > promising book. Having read this please tell me its not there as I have > never received my free copy. "Perl's internals and XS can be like black magic. [This] is the 'spell book' you need to protect and guide yourself though the deepest bepths of this subject" -- Graham Barr, Author of the libnet package Back of book. Also quotes from "Charles Bailey, Alasdair Allan, Abhijit ^^^ Menon-Sen and Norman Gray. ^ I don't know any of the other names, but that's Crab from #perl on rhizomatic... - ask if he got a book? /rataxis -- S. Joel Bernstein :: joel at fysh dot org :: t: 020 8458 2323 "Nobody is going to claim that Perl 6's OO is "bolted on". Well, except maybe for certain Slashdotters who don't know the difference between rational discussion and cheerleading..." -- Larry Wall
Re: REVIEW: Extending and Embedding Perl
On Thu, 28 Nov 2002, Nicholas Clark wrote:
> On Thu, Nov 28, 2002 at 11:45:13AM +, Richard Clamp wrote:
>
> [someone check this, please:]
> 3: so this means if you're returning a reference to an array or hash from
>your XS code, you only need to mark the top level reference as mortal; when
>that things reference count drops to zero, everything it owns is dropped
>by one. (I believe that this means the example on page 366 of Advanced
>Perl Programming is wrong - it makes everything it pushes into an array
>mortal)
IANAL, but doesn't making it mortal mean that it does not have a reference
"for you", as it were, i.e. it will be freed at the next FREETMPS, which
is correct, since if you're pushing it into an array, you don't want a
reference to it. Presumably (IANAL again) the push operation will add a
reference, so it now has 1, which is correct.
S.
--
Shevek
I am the Borg.
sub AUTOLOAD{my$i=$AUTOLOAD;my$x=shift;$i=~s/^.*://;print"$x\n";eval
qq{*$AUTOLOAD=sub{my\$x=shift;return unless \$x%$i;&{$x}(\$x);};};}
foreach my $i (3..65535) { &{'2'}($i); }
Re: REVIEW: Extending and Embedding Perl
On Thu, Nov 28, 2002 at 04:30:41PM +, Shevek wrote: > On Thu, 28 Nov 2002, Nicholas Clark wrote: > > > On Thu, Nov 28, 2002 at 11:45:13AM +, Richard Clamp wrote: > > > > [someone check this, please:] > > 3: so this means if you're returning a reference to an array or hash from > >your XS code, you only need to mark the top level reference as mortal; when > >that things reference count drops to zero, everything it owns is dropped > >by one. (I believe that this means the example on page 366 of Advanced > >Perl Programming is wrong - it makes everything it pushes into an array > >mortal) > > IANAL, but doesn't making it mortal mean that it does not have a reference > "for you", as it were, i.e. it will be freed at the next FREETMPS, which > is correct, since if you're pushing it into an array, you don't want a > reference to it. Presumably (IANAL again) the push operation will add a > reference, so it now has 1, which is correct. What's L in this case? I can however say that your presumptions are wrong. When you add things to an AV by pushing it nothing ups up the refcount of them for you. av_push is implemented in terms of av_store, which has the following note in perlapi. av_store Stores an SV in an array. The array index is specified as "key". The return value will be NULL if the operation failed or if the value did not need to be actually stored within the array (as in the case of tied arrays). Otherwise it can be dereferenced to get the original "SV*". Note that the caller is responsible for suitably incrementing the reference count of "val" before the call, and decrementing it if the function returned NULL. The last sentence is the kicker. I guess that maybe you're thinking of returning things on the stack, whereby you want to mortalise them, then your caller will up the refcount when it takes the copies of the values[1] if it assigns the values to something. So that my_sub(); # the mortalised SVs die @foo = my_sub(); # they live on within @foo; [1] Unsurprisingly for perl it actually cheats and takes the entire SV if it sees that it's mortal and about to disappear rather than copying the structure about. Yet another Cunning Optimisation. -- Richard Clamp <[EMAIL PROTECTED]>
Re: REVIEW: Extending and Embedding Perl
On Thu, Nov 28, 2002 at 03:56:50PM +, S. Joel Bernstein wrote: > At 28/11/2002 15:15 [], Mark Fowler wrote: > >Back of book. Also quotes from "Charles Bailey, Alasdair Allan, Abhijit > ^^^ > >Menon-Sen and Norman Gray. > ^ I don't know any of the other names, but that's Crab from #perl > on rhizomatic... - ask if he got a book? Charles Bailey is a VMS type, who was the pumpking for a little while back in the low 5s. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: vim
On Thu, Nov 28, 2002 at 03:27:21PM +, Jonathan Peterson wrote: > I'm playing with vim. Either it's standard perl syntax file doesn't > support folding, or I can't get folding to work for some reason (setting > fold method to syntax..). > > Vague comments about remedying either situation appreciated. I had problems with foldmethod=syntax too, as far as I remember. Here's what worked for me: set foldmethod=indent :hi Folded term=NONE ctermfg=LightYellow ctermbg=NONE I had it in for a while, but did take it out lately since I started to get on my nerves to always need to open the folds before I could see my code. -- Well, then let's give that Java-Wussie a beating... (me) Michael Lamertz| +49 2234 204947 / +49 171 6900 310 Sandstr. 122 | [EMAIL PROTECTED] 50226 Frechen | http://www.lamertz.net Germany| http://www.perl-ronin.de
Re: vim
On Thu, Nov 28, 2002 at 05:36:19PM +0100, Michael Lamertz wrote: > On Thu, Nov 28, 2002 at 03:27:21PM +, Jonathan Peterson wrote: > > I'm playing with vim. Either it's standard perl syntax file doesn't > > support folding, or I can't get folding to work for some reason (setting > > fold method to syntax..). > > > > Vague comments about remedying either situation appreciated. > > I had problems with foldmethod=syntax too, as far as I remember. I played with it when it was very new, and I think I got something working, but I can't remember the details. It's funny (or maybe it's not) but I thought I would make a lot of use of folding, and was really looking forward to it. Now it's there, the only time I use it is in vimdiff, which has removed the only reason I ever looked longingly at emacs. > I had it in for a while, but did take it out lately since I started to > get on my nerves to always need to open the folds before I could see my > code. Yep. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: vim
On Thu, 2002-11-28 at 17:26, Paul Johnson wrote: > It's funny (or maybe it's not) but I thought I would make a lot of use > of folding, and was really looking forward to it. Now it's there, the > only time I use it is in vimdiff, which has removed the only reason I > ever looked longingly at emacs. > Which brings to something that I have always been curious about, why isn't there an editor written in perl? Dirk -- Please Note: Some Quantum Physics Theories Suggest That When the Consumer Is Not Directly Observing This Product, It May Cease to Exist or Will Exist Only in a Vague and Undetermined State.
Hello London Perl-Mongers
Dear all, Just wanted to say an offical "Hello" to everyone. I'm trying to teach myself Perl - and think it's great! I've only been doing it for about 3 months, but it's already proving VERY useful at work - where I've volunteered to convert data from our Back Offfice Systems into Excel spreadsheets!!! It's saving a lot of people a lot of time. Anyway, enough rambling ... back to coding!!! Again, hello all!
Re: vim
On Thu, Nov 28, 2002 at 06:48:01PM +, Dirk Koopman wrote: > Which brings to something that I have always been curious about, why > isn't there an editor written in perl? I seem to recall someone starting a vi clone in Perl. Was it part of ppt? I don't know about emacs though. Aren't there already enough editors in the world? Maybe it's just me, but it seems that writing an editor is about as interesting as writing an accounting package. Or a CGI script that accesses a database. Fortunately, it seems there are enough people who disagree. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: vim
>> On Fri, 29 Nov 2002 00:51:18, Paul Johnson <[EMAIL PROTECTED]> said: > I don't know about emacs though. There was a comp.emacs.xemacs thread about embedding Perl in XEmacs. It's the one during which Jamie Zawinski famously said: "Some people, when confronted with a problem, think ``I know, I'll use regular expressions.'' Now they have two problems." The thread starts at: http://groups.google.com/groups?[EMAIL PROTECTED] It's an interesting anti-Perl flame war. :) - Chris. -- $a="printf.net"; Chris Ball | chris@void.$a | www.$a | finger: chris@$a | "We just typed make" -- Stephen Lambrigh, Director of Server Product | Marketing at Informix, about porting Informix to Linux.
