FW: [PATCH] Cwd::abs_path dies on win32 when used against non-exi stant file. This breaks Devel::Cover.

Title: FW: [PATCH] Cwd::abs_path dies on win32 when used against non-existant file. This breaks Devel::Cover. Not sure if this is the right thing to do, but I just sent this off about an error in Cwd on Win32. Yves -Original Message- From: Orton, Yves Sent: Friday, September 09

RE: Comparing a datetime and a scalar?

> I am trying to test the value of a MySQL datetime string to > the current > time. I have the following code fragment but the comparison fails: > > (my $rowid, my $rec_expires) = $sth->fetchrow_array(); > snip ... > my $tst_now = DateTime->now(); > my $cmp = DateTime->compare( $rec_ex

RE: Editor-Jiggery was: Re: [PATCH] Lint support

Jim Cromie wrote on Thursday, June 23, 2005 7:07 PM > Orton, Yves wrote: > > >>The problem is then that we'd also need the existing perl source > >> > >> > >normalised > > > > > >>before and after the patch, which would

RE: Editor-Jiggery was: Re: [PATCH] Lint support

> The problem is then that we'd also need the existing perl source normalised > before and after the patch, which would mean that we'd start of with a big > patch to normalise the existing files. This would loose us almost all the > change annotation, and current version control tools aren't good e

RE: $#foo out of scope (was Re: [perl #36211] local @a inside eva l)

> *: Or 49.7 days on Windows NT, IIRC. I think they've pushed it up to 50 days now. Yves

RE: [perl #35877] Strange regex failure?

> I believe that the following program should print "OK" 5 > times over, but it prints "NOT OK" from the first line. Do you mean the first test fails only (which is what I see) or that all of them fail? > > print qq[>10\n] =~ />\d+$ \n/ix ? "OK\n" : "NOT OK\n"; > print qq[>1\n] =~ />\d+$ \n/i

RE: change to quiet cygwin's perlld

> > --- perl/cygwin/perlld.in 2003-11-24 14:44:26.0 -0800 > > +++ perlpatch/cygwin/perlld.in 2005-05-11 > 23:28:20.203129600 -0700 > > Thanks, applied as #24461 > > > @@ -79,7 +79,7 @@ > > > #- > -- > > sub

RE: Error building Perl 5.8.6 on HPUX, can I ignore them?

H.Merijn Brand wrote on 09 May 2005 17:07 > On Mon, 9 May 2005 15:18:01 +0100 , "Orton, Yves" > <[EMAIL PROTECTED]> > wrote: > > > Hi, > > > > Ive been trying to build Perl 5.8.6 on HPUX and have 3 > errors to report. The > > errors _seem_

Error building Perl 5.8.6 on HPUX, can I ignore them?

Hi, Ive been trying to build Perl 5.8.6 on HPUX and have 3 errors to report. The errors _seem_ to me to be the type that I can ignore, can anybody confim this? Cheers, Yves Errors: lib/Net/Ping/t/510_ping_udp...# Failed test 2 in ../lib/Net/Ping/t/510_ping_udp.t at line 22 # ../lib/

RE: Busting ANSI logical lines?

> Line 2933 of the current maint pp_hot.c is: > > PAD_SET_CUR(padlist, CvDEPTH(cv)); > > On AIX, I'm getting warnings about illegal escapes. > > `sh cflags "optimize='-g'" pp_hot.o` pp_hot.c > CCCMD = ccache cc -DPERL_CORE -c -D_ALL_SOURCE > -D_ANSI_C_SOURCE -D_POSIX_

RE: what gets quoted in parsing warnings could use some improveme nt

> Except now of course it's not so clear at which exact point the parser > gave up; was it at the last token, the first token, or in the > middle; ie > >syntax error near '){' > > is more precise than > >syntax error near 'foo bar baz ){' Is there any reason it can't be made to say

RE: PAUSE indexer being obdurant

For those like me who were wondering wtf "obdurant" meant, believe John actually meant "obdurate" obdurate 1.a) Hardened in wrongdoing or wickedness; stubbornly impenitent: "obdurate conscience of the old sinner" (Sir Walter Scott) 1.b) Hardened against feeling; hardhearted; an obdurate miser. 2.

RE: sitecustomize.pl [PATCH]

> ActiveState have received customer requests for a mechanism that allow > the sysadmin to add entries to @INC at runtime. The following patch > make perl run '$sitelib/sitecustomize.pl' at startup if > -DUSE_SITECUSTOMIZE is added to the compilation flags. The -f option > is used to suppress eva

RE: rewinddir on win32 broken

> I found this while using POE::Component::DirWatch, which it's author > mentions this bug on http://poe.perl.org/?Robertbrook Whether there is a a bug or not aside, POE::Component::DirWatch should probably use Win32::ChangeNotify and not code like this. I guess on Win32 P::C:DW should just wrap

RE: Module::CoreList now core

> On Feb 8, 2005, at 12:15 PM, Rafael Garcia-Suarez wrote: > > I also made the following minor change, please integrate in > the CPAN > > version : > > > > Change 23948 by [EMAIL PROTECTED] on 2005/02/08 10:39:21 > > > > Fix typo in corelist > > Thanks, applied as 11945 Maybe im seeing

RE: [RFC] More core integration

> Of course, one could argue that E::MM requiring a `make` equivalent > is a serious problem for certain platforms (like Win32). Im always confused when people say this. MS has released nmake for free for years. Its available for download from the KB article "NMAKE 1.4 on Windows 95 Won't Stop

RE: unusual expression

> This isn't really a bug report, it's just the first demonstration > this year (in this forum) of my ignorance. I was poking around in > the debugger to see what kind of slop perl would tolerate in > floating point literals, and, after trying 3.e1 (which is 30, > of course) I tested the water wit

RE: [perl #33776] my, while and redo

> my $i = 0; > my $a; # goes away when declared before loop > while ($a = ) { > print $a; > $a = "bar\n"; > redo if ++$i < 5; > } Its still a bug even though its easy to work around. Id say the following from perlsyn: "The redo command restarts the loop block without evaluating t

RE: (PATCH: Benchmark.pm, Benchmark.t) RE: IMPLICIT_SYS and Perl_ Mall oc behaviour under Win32 (out of me mory with Perls malloc?)

> Unfortunately (or perhaps, fortunately, depending on how you > look at it ;) I can't reproduce this at all any more. Ok, thats cool. Ill take that as a good sign, although I think the problem is a weird mixture of the Perl and OS. It seems to me that this will be very sensitive to how fast yo

(PATCH: Benchmark.pm, Benchmark.t) RE: IMPLICIT_SYS and Perl_Mall oc behaviour under Win32 (out of me mory with Perls malloc?)

Title: (PATCH: Benchmark.pm, Benchmark.t) RE: IMPLICIT_SYS and Perl_Malloc behaviour under Win32 (out of me mory with Perls malloc?) > I've just tried building bleadperl with USE_ITHREADS + USE_MULTI + > PERL_MALLOC (but not USE_IMP_SYS or DEBUG_MSTATS) and the > test suite ran fine.  Yes

RE: IMPLICIT_SYS and Perl_Malloc behaviour under Win32 (out of me mory with Perls malloc?)

> Steve Hay wrote on 04 January 2005 11:01: > > >I was wondering if anybody had any suggestions, it seems > odd that with > the > > >Perl Malloc i run out of memory when without it I dont. > > > > > Perl's malloc() requires an sbrk() function, which Win32's > CRT doesn't > > provide. Therefore,

RE: IMPLICIT_SYS and Perl_Malloc behaviour under Win32 (out of me mory with Perls malloc?)

Steve Hay wrote on 04 January 2005 11:01: > >I was wondering if anybody had any suggestions, it seems odd that with the > >Perl Malloc i run out of memory when without it I dont. > > > Perl's malloc() requires an sbrk() function, which Win32's CRT doesn't > provide. Therefore, Perl's win32.c sour

IMPLICIT_SYS and Perl_Malloc behaviour under Win32 (out of memory with Perls malloc?)

This message is kindof a follow up to message <[EMAIL PROTECTED]> I just tried out building Perl 5.8.4 (using the sources from Activestate Build 810) without having PERL_IMPLICIT_SYS set and with using Perls malloc. I commented out the USE_IMP_SYS = define line in the makefile as well as uncommen

RE: [PATCH] File::Find dies on find({follow=>1, ...}) on Win32

> I've got most of the work done to make this a dual life module to make work > on improving its tests more easy. If you'd like a tarball I can provide it, > otherwise, I can continue and get it ready. Id be happy to get whatever you have to offer in terms of code and support. :-) Yves

RE: [PATCH] File::Find dies on find({follow=>1, ...}) on Win32

Michael G Schwern wrote on 27 December 2004 18:30: > On Mon, Dec 27, 2004 at 10:46:27AM -0000, Orton, Yves wrote: > > In light of all of the comments in this thread shouldnt File::Find be made a > > dual life module and be put on CPAN independently? > > Good idea. I volun

RE: [PATCH] File::Find dies on find({follow=>1, ...}) on Win32

> > Neither does patching File::Find as there's no CPAN version. :( > > d'oh, then a stopgap patch is pointless anyway =/ I suppose > we'll just have to live with this on the already released versions of perl and > work around it. > > I would vote however that we fix this properly in maint as s

RE: [ANNOUNCE] Test::Simple/More/Builder 0.54 (problem with signa ture?)

Michael G Schwern wrote on 16 December 2004 23:06 > On Thu, Dec 16, 2004 at 12:59:00PM -0000, Orton, Yves wrote: > > Ah, sorry. I didnt understand. Im just curious if i alter > this file this > > will affect all "make dist" commands? > > Only if that module

RE: [perl #33076] Localized */ isnt observed by magic IO operator

> yo> perl -e "use strict; use warnings; our $foo; local *foo=':'; print > yo> $foo" > > yo> Outputs a newline followed by a dash on my system (Win32). > > As it should, since the glob-aliasing made it equivalent to this: > > # perl -e 'print $:' Right. Thanks. What about the other part?

RE: [perl #33076] Localized */ isnt observed by magic IO operator

> perl -le "$/='foo'; local */; print 'Got:',$/; while(<>) { > chomp; print; }" > > Even though the "Got:" output will be correct <> will still > think that $/ is > equal to 'foo' > > Ive tested this on 5.6.1 and 5.8.4 and both fail. And another glob related oddity: perl -e "use strict; use w

[perl #33076] Localized */ isnt observed by magic IO operator

# New Ticket Created by "Orton, Yves" # Please include the string: [perl #33076] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=33076 > This is a bug report for perl from [EMAIL PROTECTED], generated wit

RE: [ANNOUNCE] Test::Simple/More/Builder 0.54 (problem with signa ture?)

> Not Test::More's MANIFEST.SKIP. The system's default MANIFEST.SKIP. > ExtUtils::MANIFEST.SKIP. > > Run "perldoc -m ExtUtils::MANIFEST.SKIP" and see if it looks like either of > the urls above. Ah, sorry. I didnt understand. Im just curious if i alter this file this will affect all "make dist"

RE: [ANNOUNCE] Test::Simple/More/Builder 0.54 (problem with signa ture?)

> Perhaps you've got a damaged default MANIFEST.SKIP. Check what > "perldoc -m ExtUtils::MANIFEST.SKIP" looks like. It should > look like this. > > http://search.cpan.org/src/MSCHWERN/ExtUtils-MakeMaker-6.24/lib/ExtUtils/MAN IFEST.SKIP > > Not like this. > http://search.cpan.org/src/MSCHWERN/E

RE: [ANNOUNCE] Test::Simple/More/Builder 0.54 (problem with signa ture?)

> Not quite. I'm saying: "Unless you need fork you're probably > better off using a perl without PERL_IMPLICIT_SYS" [on Win32, > obviously]. There's no problem with having ithreads enabled; > it's PERL_IMPLICIT_SYS that requires perl's malloc to be disabled. Got it. Ok, sorry to be so thick.

RE: [ANNOUNCE] Test::Simple/More/Builder 0.54 (problem with signa ture?)

> Your patch needs to account for PERL_IMPLICIT_SYS too like > t/op/fork.t does, as Schwern just pointed out. Ok, ill look into that test to see how it works. > I should have mentioned that rather than just "ithreads" in my mail. > PERL_IMPLCIT_SYS is, in fact, also the reason that I don't bu

RE: [ANNOUNCE] Test::Simple/More/Builder 0.54 (problem with signa ture?)

> Yves Orton wrote: > > >>http://svn.schwern.org/svn/CPAN/Test-Simple/trunk > >>or > >>svn://svn.schwern.org/CPAN/Test-Simple/trunk > >>or > >>http://www.pobox.com/~schwern/src/Test-Simple-0.54.tar.gz > >>or > >>a CPAN near you. > >> > >> > > > >Should the t/fork.t tests should still be skipped on

RE: [ANNOUNCE] Test::Simple/More/Builder 0.54

> http://svn.schwern.org/svn/CPAN/Test-Simple/trunk > or > svn://svn.schwern.org/CPAN/Test-Simple/trunk > or > http://www.pobox.com/~schwern/src/Test-Simple-0.54.tar.gz > or > a CPAN near you. Should the t/fork.t tests should still be skipped on Win32? Win32 Perl has been able to fork since at lea

RE: [perl #32383] DProf breaks List::Util::shuffle

> Ive tried using it with code that uses Inline or XS and it > always fails. I ended up writing my own profiler to deal with it. Gah. I just retested it and the problem has gone away. The only difference was we currently use AS 638 and when I had the problems with Dprof we were using AS 635. (5.

RE: [perl #32383] DProf breaks List::Util::shuffle

> Jarkko Hietaniemi (via RT) wrote: > > $ cat sd.pl > > use List::Util qw(shuffle); > > shuffle; > > $ perl sd.pl > > $ perl -d:DProf sd.pl > > Modification of a read-only value attempted at sd.pl line 2. > > With blead, you get a more, er, porter-friendly error : > > $ bleadperl -d:DP

RE: [perl #2215] redo undefines variables declared like while (my $i ...) { redo; }

Dave Mitchell wrote: > > If your interpretation of this is correct then I think the documentation > > should be changed to clarify the point. I wouldn't have expected this result > > from that description. In fact that description makes me think that > > > > my @a=(2..5); > > while (my $x=shif

RE: [perl #2215] redo undefines variables declared like while (my $i ...) { redo; }

Steve Peters wrote: > This does not appear to be a bug. Quoting "Programming Perl, Second > Edition", "The redo command restarts the loop block without evaluating > the conditional again." So, when it re-enters the block, the shift is > not performed and $i is implicitly defined to undef and the

RE: Should makefiles ask for permission to overwrite files?

> I've just fixed this as change 23616, but it raised the question of > whether the "xcopy" commands should have waited for user input at all. > > I could change the $(XCOPY) macro definition to include the "/y" option > which would do the obvious thing, but I wondered what the policy was on >

RE: [perl #32714] Objects destroyed in the wrong order during glo bal destruction

MJD wrote: > That is talking about something else that is irrelevant in this case. > That paragraph refers to this situation; > > { my $obj = Class->new; > ... > } > > B; > > The question here is whether Class::DESTROY is called immediately at > the end of the b

RE: [perl #32714] Objects destroyed in the wrong order during glo bal destruction

> Subject: [perl #32714] Objects destroyed in the wrong order during global destruction I thought order of destruction in perl in general was undefined? At least Perltoot seems to agree with me: "Perl's notion of the right time to call a destructor is not well-defined currently, which is why yo

RE: [perl #7904] Win32::Console problem

> I might agree with you if it were some nameless, faceless Corporate > Entity, but knowing what I know about ActiveState, this sounds too > much like FUD to me. Argh, obviously I've made things worse. I was not trying to FUD here. Really. Sorry it seems that way. > ActiveState the corporate ent

RE: [perl #7904] Win32::Console problem

Gurusamy Sarathy wrote on 02 December 2004 01:02 > On Wed, 01 Dec 2004 18:24:28 GMT, "Orton, Yves" wrote: > >Rafael Garcia-Suarez said on 01 December 2004 18:45 snip > >> Moreover I'm not very inclined to add modules in the core. > > > >Well, 5.6 is

RE: [perl #7904] Win32::Console problem

Jan Dubois wrote on 01 December 2004 19:52 > On Wed, 01 Dec 2004, Orton, Yves wrote: > > Consider that libwin32 hasn't been updated on CPAN since 08 Jul 2002 > > (libwin32-0.191). > > I have a copy of most/all patches that have been submitted to Sarathy > over the

RE: [perl #7904] Win32::Console problem

Rafael Garcia-Suarez said on 01 December 2004 18:45 > Orton, Yves wrote: > > > > Im just curious about this. Is there a good reason why the core Win32 > > modules are NOT considered to be Core perl in general? Are there any other > > OS'es where core perl doesn&

RE: [perl #7904] Win32::Console problem

> Sorry, but Win32::Console is not part of the core Perl > distribution. It > is part of the core ActiveState distribution, so you can > report the bug > to them at http://bugs.activestate.com//ActivePerl/query.cgi. Im just curious about this. Is there a good reason why the core Win32 modules

RE: OSes that ship perl as core

Steve Hay wrote: > Nicholas Clark wrote: > > >Which operating systems ship perl 5 as core? > > > Not quite core, but even Microsoft ships OS add-ons with Perl > in them: > e.g. Windows 2000 Resource Kit contains ActivePerl 521, and > Services For > Unix 3.5 contains ActivePerl 613. And they m

RE: -problem with CPAN PathTools-3.01 and Cwd-2.21

Nicholas Clark wrote: > On Wed, Nov 17, 2004 at 11:07:19PM -0800, Yitzchak > Scott-Thoennes wrote: > > > So something like: > > > > my $pid = open(REALPATH, "-|"); > > if (! $pid) { > >exec('/usr/bin/fullpath', '-t', $path) if defined $pid; > >die "Can't open /usr/bin/fullpath: $!"; > >

RE: Proposed patch for perldelta.pod for 5.8.6-RC1

> I'm not convinced that the "anyway" actually adds anything to > this sentence. > What ambiguity is it intended to avoid? > > The other part of the change I like a lot. Just an attempt a reparaphrase: There was a long-standing optimization for C that assumed that Perl's C was not stable. Prio

RE: Runaway process problems for hosting companies

Michael G Schwern wrote on 12 November 2004 21:48 > On Fri, Nov 12, 2004 at 07:00:17PM -0000, Orton, Yves wrote: > > I disagree. Having modules in the core is one of the few > ways to guarantee > > that the module will be uniformly available. > > Its very unlikely to ge

RE: Runaway process problems for hosting companies

Nicholas Clark wrote: > On Fri, Nov 12, 2004 at 07:00:17PM -0000, Orton, Yves wrote: > > > Like the hundreds of CPAN modules which are not endorsed > by p5p and don't > > > > > appear in the docs yet somehow manage to be successful? > > > > This

RE: Runaway process problems for hosting companies

> Like the hundreds of CPAN modules which are not endorsed by p5p and don't > appear in the docs yet somehow manage to be successful? This is a specious comparison. We are talking about dealing with server web farms where getting admins to install anything non-standard is particularly difficult.

RE: Runaway process problems for hosting companies

> At a guess I would put that down to a problem with the UI for > task killing and how usable it is when the system is stressed. No it a permissions problem. Users cant kill jobs started as SYSTEM (iirc). I know that ive experienced this problem myself, and sometimes the _only_ solution is to reb

RE: Eval changes the behaviour of shift() ?

Brian McCauley chided: > > Yves Orton wrote: > > > I don't know if this is a bug or not, it seems sorta > reasonable although > > entirely _not_ dwim: > > > > C:\>perl -e "sub X { print eval 'shift' } X(1)" A > > A > > > > Is this correct? > > See >perldoc -f shift > > (I've just dri

Eval changes the behaviour of shift() ?

I don't know if this is a bug or not, it seems sorta reasonable although entirely _not_ dwim: C:\>perl -e "sub X { print eval 'shift' } X(1)" A A Is this correct? I would have expected it to print out '1' and not 'A'. Yves

RE: sharing hash-values

> There's one gotcha with this. If the thing in $ref gets > garbage collected, > the address can be reused, so you actually have to do > > $hash{refaddr $ref} = [do{$r=$ref;weaken($r)}, ...]; > > and then check that ->[0] is still valid. Wrap it up in a > class and it's not > too bad. > > Of c

RE: sharing hash-values

> However there could be a kind of difficulty: I saw many people on > perlmonks.org rely on fact that stringified reference to > scalar (or SV) > being consistent, so they write $hash{"$ref"} = \$ref; > And this could be easily broken by such kind aliasing. Well, IMO this is a bad habit that I pe

RE: sharing hash-values

> I "needed" this too some time ago and ended up writing > . > Ive always wished this was part of Scalar/List Utils and thus/or alternatively in the core modules. It's a very useful module and the code bloat would be minimal as all it does pretty much i

RE: [perl #19679] uncaught exception thrown on 4-line incorrect s cript

Steve Peters wrote via RT on 05 November 2004 15:20 > > The following script causes an uncaught exception on my system: I can repeat the segfault on AS 5.6.1 Build 638. I can't repeat it on a native 5.8.1 MS Build, nor on a cygwin build of 5.8.5 > I get an error immedicately. The declaration o

RE: [perl #32104] Perl doesn't support RAII, part 2 [patch includ ed]

> >> If all we want is a way to execute some code on scope exot > >> (however exited) then we can use the C level scope hooks > >> to ensure that without "clever" objrefcount and DESTROY hooks. > > > >Can this be done from Perl though? > > Not directly. But adding a hook to existing XS utilitie

RE: [perl #32104] Perl doesn't support RAII, part 2 [patch includ ed]

> >sub new { > >my ($class,$sub)[EMAIL PROTECTED]; > >return bless sub { goto &$sub },$class; > >} > > There has been a recent thread to the effect that blessing subs > does not work as expected. Try adding a level of indirection > so you bless say a scalar which holds the subref. Yeah g

RE: optimization idea

Dave Mitchell wrote at 25 October 2004 22:38: > On Mon, Oct 25, 2004 at 09:09:16PM +0200, Elizabeth Mattijsen wrote: > > Wouldn't you need to add taking a ref of the var, to > invalidate this > > optimization? Specifically for this case: > > > > sub statename { > > my $name = 'david'; > >

RE: [perl #31903] perlre /x modifier documentation

> There is _no_ way to do it. That's just as awful as putting > comments in > "..." strings by using ${\( # this is a comment > )}. Forgot that horrible /e hack. It's only for obfuscaters. > Wow, never seen that one before. You have an evil mind Raphael. :-) Yves

RE: Data::Dumper problem...

Rafael Garcia-Suarez wrote on 19 October 2004 14:00 > You have a point. What about : (SNIPPED cause outlook butchers patches) Yep, that's much better, thanks. :-) Cheers, Yves

RE: Data::Dumper problem...

> @@ -689,7 +689,8 @@ > structures correctly. > > The return value can be Ced to get back an identical > copy of the > -original reference structure. > +original reference structure (although you might need to > turn off strictures > +to eval it). > > Any references that are the same as on

RE: making regcomp into a list op

> while /foo$bar{baz}(?{$x=1})/U$x\E/ might give > > handler('foo','constant'); > handler('$bar{baz}' 'scalar'); > handler('$x=1', 're-code'); > handler('U', 'func'); > handler('$x', 'scalar'); > handler('E', 'func'); > > perhaps > > Although I h

RE: [perl #31865] weird results from reverse( %x = reverse %h )

> > D:\Development>perl -le "print (%x = (qw(a 1 b 2 c 3)));" >^ >b in my example > > a1b2c3 > > The required trigger is a duplicate key which you don't have in your > trials. Whoops. So I didn

RE: [perl #31865] weird results from reverse( %x = reverse %h )

> Maybe its also OS specific? On Win32 I couldn't repeat this behaviour using > either AS Perl 5.6.1 (658) or under a home built Perl 5.8.5 nor under the > Cygwin Perl 5.8.5 either. Er, I meant AS 638. Sorry. Also it looks like AS 638 gets it more right but not correct than later versions: D:\De

RE: [perl #31865] weird results from reverse( %x = reverse %h )

> I dunno, but some more data points: > > $ perl5.8.3 -le 'print (%x = ("a",1,"b",2,"b",3));' > bb > $ perl5.6.1 -le 'print (%x = ("a",1,"b",2,"b",3));' > a1bb3 > > I'm not sure what it should print but those are both obviously wrong. Maybe its also OS specific? On Win32 I could

RE: [perl #31793] Data::Dumper: Useqq interacts badly with overlo ading

> I'm using Data::Dumper to display Perl objects for debugging purposes. > I like to use Dumper's Useqq option, because it produces printable > output when given unprintable strings. However, when that option is > used, Dumper fails on an object blessed into a class that overload the > "cmp" opera

RE: Advice about enhancing Hash::Util

Nicholas Clark wrote on Wednesday, March 24, 2004 3:03 PM > On Wed, Mar 24, 2004 at 01:22:20PM +0100, Yves Orton wrote: > > > > I also think that its counterintuitive to have to use > > Internals::SvREADONLY to determin if a hash is locked. Its not at > > all clear that "readonly"ness is the same

RE: perl 5.8.2 on win32 and multiple compilations

> Makefiles work(ed) without prompting on WinNT's cmd.exe - but > of course > Win2k/WinXP seem to have changed things. I believe the dmake and nmake makefiles are out of synch in this regard. IIRC a patch was made to the nmake version that resolved this. Yves

RE: perl562@20985 [PATCH MakeMaker]

> > Patch as follows Er, sorry about the mangled patch. Luckily it isnt that hard to fix by hand. :-) > > --- ExtUtils-MakeMaker-6.16/lib/ExtUtils/Install.pm 2003-06-05 > > 10:04:31.0 +0200 > > +++ ExtUtils-MakeMaker-6.16-pathced/lib/ExtUtils/Install.pm > 2003-09-08 > > 11:58:26

RE: perl562@20985 [PATCH MakeMaker and File::Spec::Win32]

> > Perhaps Ken Williams' new CPAN dist of File::Spec could > simply be plopped > > into 5.6.2? > > I was looking at the diff and I don't see a reason why this would fix > Yves' build. There's no difference in file_path_is_absolute(). > I was considering the upgrade anyway. It looks like the rea

RE: my SLICE = VALUE ?

> Is the above a good idea? I don't think so. Is it intuitive? Well, > just like every suggestion ever made here, sure, to a few people (or > so they say). Is it intuitive to most? Is it intuitive in general? I > doubt it. As you have admitted above, the syntax is inconsistent with > Perl, therefor

RE: my SLICE = VALUE ?

> *yuck* > > my() defines lexicals. Abuse it all you want to create > lexical hash entry > overrides or something like that. Please, please, please > don't make it mean > something nothing to do with lexicals I fail to see whty this behaviour should be restricted to my. Why shouldnt it work

RE: [PATCH] Extra newline in stringified qr/\#/x

> As far as I can tell, the stringified form of a regexp is only useful > for debugging purposes, to dump the inner contents of a regexp. On the contrary. The ability to stringify a regex is a crucial aspect power and flexibility of perls regexes. Consider the following (conceptual demonstrat

Called as a subroutine or as a method?

Hello all, I was wondering if there was a way to determine if a sub was called as a subroutine or as a method? I havent seen any way to do it, caller() doesnt seem to return this information, unless its in one of the "hands off" fields that we arent supposed to use. Incidentally here is a thread