from:"demerphq"

On 8/3/05, Randy W. Sims [EMAIL PROTECTED] wrote:
 Piotr Fusik (via RT) wrote:
  # New Ticket Created by  Piotr Fusik
  # Please include the string:  [perl #36766]
  # in the subject line of all future correspondence about this issue.
  # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36766 
 
 
  This is a bug report for perl from [EMAIL PROTECTED],
  generated with the help of perlbug 1.35 running under perl v5.8.7.
 
 
  -
 
  It seems that perldoc creates temporary files in \WINDOWS\TEMP,
  but doesn't delete them upon exit.
 
 This is not a bug. 

Actually it IS a bug. Even if its a known bug deliberately left in place.

 I don't recall the specific reason, but temp files
 are kept for a period of time. I think it has something to do with the
 file locking semantics of the temp files created under Windows such that
 they can't be unlinked under certain conditions, but my memory is known
 to be quite faulty and occasionally makes up stuff.

This only holds true for files opened using normal perl file opening
mechanisms as the unixy style file opens dont allow for Win32 users to
exploit Win32 specific mechanisms for achieving this.

use Win32API::File;

$hTemp= createFile( $ENV{Temp}/temp.$$, wn, ,
  { Attributes=hst, Flags=FILE_FLAG_DELETE_ON_CLOSE() } )
  or  die Can't create temporary file, temp.$$: $^E\n;

will create a file that is marked as temporary and which will be
automatically deleted when the handle is closed. Marking it as a
temporary file means that if at all possible the OS will keep the
entire file in cache and avoid writing it to disk, meaning that using
the file is more efficient.

As an aside its a real pity we cant access this type of functionality
via the normal open semantics.

Ie, something like:

open my $fh,!,temp_file or die Failed to open:$!;
unlink temp_file; # this makes unix systems unlink the file immediately, 
   # the ! open modifier makes it delete on
close on Win32
   # systems where this is not allowed.

Of course on systems without this style of opening semantics the !
modifier would be ignored. Although for sanity reasons I would make
this only happen with a three arg open.

cheers,
yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Fixing File::Temp for Win32 (was Re: [perl #36766] perldoc pollutes TEMP)

On 8/5/05, Tim Jenness [EMAIL PROTECTED] wrote:
 
 Do you want to patch File::Temp to make this work properly on Win32 (I
 don't know the API so never implemented something like that). If I recall
 correctly Pod::Perldoc started off using File::Temp until problems with
 win32 temp files turned up. Maybe if File::Temp was fixed on win32
 Pod::Perldoc could switch back to using it.

I think the main problem with this is that libwin32 is not part of
core but instead independently maintained and applied by Activestate
in only their releases. Since File::Temp is core it means the
functionality wouldnt work until libwin32 was installed, which would
cause problems for the code relying on it to do the right thing out of
the box.

I believe Win32API::File (along with Win32::TieRegistry) should be
included in the core distro (at least the Win32 core distro) which
would mean that File::Temp could be made to depend on it without
problem. Both modules provide functionality that is fairly critical
for Win32 system programming which IMHO Perl should be able to do out
of the box.

So yes, id be happy to update File::Temp, but it would mean putting
certain low level win32 functionality into the core first.

cheers,
yves
ps: This a good example of why I think libwin32 should be core
maintained and not an AS specific extension. Also its worth noting
that Win32API::File is not actually written by AS but rather by one of
the perlmonks administrators, Tye McQueen, who im sure would be quite
happy to see his modules bundled with core.

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Fixing File::Temp for Win32 (was Re: [perl #36766] perldoc po llutes TEMP)

On 8/5/05, Konovalov, Vadim [EMAIL PROTECTED] wrote:
   Do you want to patch File::Temp to make this work properly
  on Win32 (I
   don't know the API so never implemented something like
  that). If I recall
   correctly Pod::Perldoc started off using File::Temp until
  problems with
   win32 temp files turned up. Maybe if File::Temp was fixed on win32
   Pod::Perldoc could switch back to using it.
 
  I think the main problem with this is that libwin32 is not part of
  core but instead independently maintained and applied by Activestate
  in only their releases. Since File::Temp is core it means the
  functionality wouldnt work until libwin32 was installed, which would
  cause problems for the code relying on it to do the right thing out of
  the box.
 
 However perl *does* have proper temp files inside core, here is an excerpt
 from win32/win32.c:
 
 DllExport int
 win32_tmpfd(void)
 {
 dTHX;
 char prefix[MAX_PATH+1];
 char filename[MAX_PATH+1];
 DWORD len = GetTempPath(MAX_PATH, prefix);
 if (len  len  MAX_PATH) {
 if (GetTempFileName(prefix, plx, 0, filename)) {
 HANDLE fh = CreateFile(filename,
DELETE | GENERIC_READ | GENERIC_WRITE,
0,
NULL,
CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL
| FILE_FLAG_DELETE_ON_CLOSE,
NULL);
 
 Especially FILE_FLAG_DELETE_ON_CLOSE


Any idea how this can be utilized from the Perl side? 
 
 
 
  I believe Win32API::File (along with Win32::TieRegistry) should be
  included in the core distro (at least the Win32 core distro) which
  would mean that File::Temp could be made to depend on it without
  problem. Both modules provide functionality that is fairly critical
  for Win32 system programming which IMHO Perl should be able to do out
  of the box.
 
 Looking into existing Win32.pm which is part of the core, it seems quite
 normal to have some functions to work with temporary files.

Agreed. Although IMO the idea of a ! open modifier would provide a
nice perlish way to access this. On unix it could just cause an
immediate perl internals level unlink, and on Win32 and other OS'es
where this is not possible it would use whatever mechanism the OS
provides for self deleting files.

cheers,
yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #36766] perldoc pollutes TEMP

On 8/5/05, Randy W. Sims [EMAIL PROTECTED] wrote:
demerphq wrote:
On 8/3/05, Randy W. Sims [EMAIL PROTECTED] wrote:

Piotr Fusik (via RT) wrote:

# New Ticket Created by Piotr Fusik
# Please include the string: [perl #36766]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36766

This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.7.

It seems that perldoc creates temporary files in \WINDOWS\TEMP,
but doesn't delete them upon exit.

This is not a bug.

Actually it IS a bug. Even if its a known bug deliberately left in place.

Actually, it is not. It is explicitly planned coded behaviour. ;)

Ok, ok, its a bug^Wfeature. :-)

It may not be the preferred solution, but it is apparent that a choice
was made and that the code behaves as it was intended.

As Vadim says, its a design bug, not an implementation bug. But IMO
its still a bug. Or at the very least its a nasty kludge.

I don't recall the specific reason, but temp files
are kept for a period of time. I think it has something to do with the
file locking semantics of the temp files created under Windows such that
they can't be unlinked under certain conditions, but my memory is known
to be quite faulty and occasionally makes up stuff.

This only holds true for files opened using normal perl file opening
mechanisms as the unixy style file opens dont allow for Win32 users to
exploit Win32 specific mechanisms for achieving this.

use Win32API::File;

$hTemp= createFile( $ENV{Temp}/temp.$$, wn, ,
{ Attributes=hst, Flags=FILE_FLAG_DELETE_ON_CLOSE() } )
or die Can't create temporary file, temp.$$: $^E\n;

will create a file that is marked as temporary and which will be
automatically deleted when the handle is closed. Marking it as a
temporary file means that if at all possible the OS will keep the
entire file in cache and avoid writing it to disk, meaning that using
the file is more efficient.

Hmm, my previous explanation as to why temp files are not immediately
deleted may have been misleading (or just wrong).

You can't unlink an open file under normal cicrumstances. You can
open a file with the FILE_SHARE_DELETE which will allow a second
process to open the file with DELETE permissions, but i dont think the
file can actually be deleted until the deleting process is the only
one with a handle to the object. Although having said that the MSDN
docs do suggest that it is possible to delete an open object, I just
havent put together a test case that proves it, instead the test cases
I have tried suggest the opposite. Go figure. :-)

Relevent links:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createfile.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/creating_and_opening_files.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_security_and_access_rights.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/standard_access_rights.asp

It's more likely the external pager that doesn't properly release the
file. Again, this is
based on vague memories of this being discussed quite a while back, so I
may be in error on the specifics.

Although, I do believe the basic
problem is related to files being locked so that they cannot be
unlinked. Anyone who has had to spend any time on Windows has likely run
into those annoying files that cannot be deleted even though that file
is not currently open by any running application.

Are you sure the file isnt open by a running application? Every time
ive encountered this problem a search with tools from
sysyinternals.com shows that some application or another actually does
have the file open. More commonly however you see directories that
cant be deleted because they are the CWD of some running task, which
is much harder to track down.

Cheers,
Yves

--
perl -Mre=debug -e /just|another|perl|hacker/

Re: Fixing File::Temp for Win32 (was Re: [perl #36766] perldoc po llutes TEMP)

On 8/5/05, Konovalov, Vadim [EMAIL PROTECTED] wrote:
   However perl *does* have proper temp files inside core,
  here is an excerpt
   from win32/win32.c:
  
   DllExport int
   win32_tmpfd(void)
   {
   dTHX;
   char prefix[MAX_PATH+1];
   char filename[MAX_PATH+1];
   DWORD len = GetTempPath(MAX_PATH, prefix);
   if (len  len  MAX_PATH) {
   if (GetTempFileName(prefix, plx, 0, filename)) {
   HANDLE fh = CreateFile(filename,
  DELETE | GENERIC_READ |
  GENERIC_WRITE,
  0,
  NULL,
  CREATE_ALWAYS,
  FILE_ATTRIBUTE_NORMAL
  | FILE_FLAG_DELETE_ON_CLOSE,
  NULL);
  
   Especially FILE_FLAG_DELETE_ON_CLOSE
 
 
  Any idea how this can be utilized from the Perl side?
 
 I guess I should investigate deeper at the very first time.
 
 win32_tmpfd is used by win32_tmpfile which in turn used by either
 PerlIO_tmpfile or tmpfile and then by IO.xs.
 
 IMHO it is already in the core: see
   perldoc IO::File
 new_tmpfile should do what is needed to.
 
 And perldoc invented wrong wheel :)
 

Well, this makes File::Temp patchable without adding modules to the
core which is a good step. :-)

Also it suggests that there should be a non IO::File way to do it as
well, doesnt it? At the very least the comments by Nick Ing-Simmons in
Message-Id: [EMAIL PROTECTED] suggest
that IO::* shouldnt be the only way to do this. What do you think of
the ! open modifier idea ive proposed? Especially as the code youve
pointed at doesnt allow arbitrarily named files to be opened with
these flags. I wonder why the code doesnt use the
FILE_ATTRIBUTE_TEMPORARY flag nor the FILE_ATTRIBUTE_HIDDEN and
FILE_ATTRIBUTE_SYSTEM either... Surely that would be more efficient
and elegant?

yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Fixing File::Temp for Win32 (was Re: [perl #36766] perldoc po llutes TEMP)

On 8/5/05, Konovalov, Vadim [EMAIL PROTECTED] wrote:
   And perldoc invented wrong wheel :)
  
 
  Well, this makes File::Temp patchable without adding modules to the
  core which is a good step. :-)
 
 As I understood with some delays, there are intentions to remove perldoc's
 own logic with temporaries and use File::Temp ?
 In this case let me express my deepest thank and respect.

Well thats the mechanism Tim suggested and IMO it makes good sense.
 
 
  Also it suggests that there should be a non IO::File way to do it as
  well, doesnt it? At the very least the comments by Nick Ing-Simmons in
  Message-Id: [EMAIL PROTECTED] suggest
  that IO::* shouldnt be the only way to do this. What do you think of
  the ! open modifier idea ive proposed? Especially as the code youve
 
 I have nothing against it, I only afraid it will conflict with '!' inside
 normal file-names (which I use from time to time).
 May be PerlIO's layer (like with encodings, but for temporaries), will be
 safer for programmers?

Well i was thinking the special functionality would only occur with a 
three arg open. Or possibly if the ! preceded a . So:

open my $fh,!,$file or die Couldn't open temp file:$!;

or

open my $fh,!$file or die Couldn't open temp file:$!;

but

open my $fh,!$file or die ...

would not trigger the special behaviour. I guess this is something
that Larry would have to speak to as it would probably impact Perl6.
IMO it would be nice if Perl6 was a little less unix oriented in its
file handling so im hoping he likes the idea. :-)
 
  pointed at doesnt allow arbitrarily named files to be opened with
  these flags. I wonder why the code doesnt use the
  FILE_ATTRIBUTE_TEMPORARY flag nor the FILE_ATTRIBUTE_HIDDEN and
  FILE_ATTRIBUTE_SYSTEM either... Surely that would be more efficient
  and elegant?
 
 I think adding it portably (so no Win9X will broke) is a good thing.

Presumably this is possible. And actually, im fairly sure that F_A_S
and F_A_H are supported by 9x oses.

yves



-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: affect/effect (was perlfunc.pod grammar fixes)

2005-08-03 Thread demerphq

On 8/3/05, Joshua Juran [EMAIL PROTECTED] wrote:
 On Aug 2, 2005, at 4:18 AM, demerphq wrote:
 
  On 7/28/05, Joe McMahon [EMAIL PROTECTED] wrote:
 
  On Jul 28, 2005, at 12:49 AM, Piotr Fusik wrote:
 
   Note that a block by itself is semantically identical to a loop
  -that executes once.  Thus Clast can be used to effect an early
  +that executes once.  Thus Clast can be used to affect an early
   exit out of such a block.
 
  Perhaps this should use neither affect nor effect. If native
  english speakers are going to debate which is appropriate then non
  native speakers shouldnt have to deal with it at all.
 
  Change it to Thus Clast can be used to _cause_ an early (without
  emphasis) and the problem goes away. And IMO reads better anyway.
 
 How about Thus Clast can be used to exit out of such a block early.?
 
 I find 'effect' slightly more preferable than 'cause' -- it sounds
 weird to 'cause' something that's entirely under your control anyway.
 I don't cause a brushing of my teeth; I just brush them.  Furthermore,
 I find this use of 'effect' to be rather affected.  :-)

Hmm, good point. I wonder if perl documentation authors have a
tendency to avoid words that are also perl keywords in their
contributions? :-)

yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: affect/effect (was perlfunc.pod grammar fixes)

2005-08-02 Thread demerphq

On 7/28/05, Joe McMahon [EMAIL PROTECTED] wrote:
 
 On Jul 28, 2005, at 12:49 AM, Piotr Fusik wrote:
 
   Note that a block by itself is semantically identical to a loop
  -that executes once.  Thus Clast can be used to effect an early
  +that executes once.  Thus Clast can be used to affect an early
   exit out of such a block.
 
  effect is a noun.  affect is a verb so I think this change is correct.
 
  -You can effect a sleep of 250 milliseconds this way:
  +You can affect a sleep of 250 milliseconds this way:
 
  This is correct.
 
  Hmm...
 
 Both wrong, as Piotr says.  Effect means to cause to exist in both
 these usages; affect would mean to change the state of something
 already existing. So in the first case we want an early exit to happen
 that has not yet happened: effect. In the second case we want to make a
 250 ms wait happen: effect. If we wanted to change an existing 250 ms
 wait, then we would be affecting it.

Perhaps this should use neither affect nor effect. If native
english speakers are going to debate which is appropriate then non
native speakers shouldnt have to deal with it at all.

Change it to Thus Clast can be used to _cause_ an early (without
emphasis) and the problem goes away. And IMO reads better anyway.

yves
-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give masked warning

2005-07-20 Thread demerphq

On 7/14/05, Johan Vromans [EMAIL PROTECTED] wrote:
 Rick Delaney [EMAIL PROTECTED] writes:
 
  use strict;
  package Foo::Bar;
  our @ISA = qw(Foo);
 
  package Foo::Baz;
  our @ISA = qw(Foo);
 
 This is where we have use base for.

use base sucks. It uses horrible heuristics to do its thing and gets
things wrong disturbingly often. IMO its much preferable to avoid it.
As an example play around with it with multiple packages in a single
file, likewise play around with evaling packages into existance at run
time, and watch use base act like its been smoking crack.

 
-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32

2005-07-09 Thread demerphq

On 7/9/05, Ken Williams [EMAIL PROTECTED] wrote:
 
 On Jul 8, 2005, at 4:50 PM, yves orton via RT wrote:
 
  Sorry, i guess I didnt express myself properly.  You cant clean up a
  relative path properly without knowing where it is relative to.
  Consider the following path:
 
 ..\..\foo
 
  If we are in \bar then ..\..\foo is the same as  ..\foo and \foo but
  if we are in \bar\baz\bat then its not the same as either as it maps
  to \bar\foo.
 
 The current working directory is not considered in canonpath(), period.
   canonpath(../../foo) is ../../foo.

As I said before, the docs DONT specify what canonpath() is for very
well. All of this stuff is inferred or implied. Personally i dont feel
bad in coming up with a interpretation of what canonpath() is for that
differs from your own, or Schwerns, when the docs do not actually
explicitly say what it does.

One can infer almost any behaviour from cleans up the path. And IMO,
whether looking at cwd or not is included in does not look at the
filesystem is unclear.

Im happy with the behaviour you outline, and i think i like Schwern's
idea of a collapse path or whatever. But id like to see this stuff
spelled out in the File::Spec docs properly.

OTOH, i still think canonpath for absolute paths on Win32 should use
GetFullPathName().

yves
-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: File::Spec-collapse() proof of concept

2005-07-09 Thread demerphq

On 7/9/05, Michael G Schwern [EMAIL PROTECTED] wrote:
 I'm not wedded to the name, but attached is a proof-of-concept of a routine
 which collapses updirs.  This is a solution to the problem whether or not
 canonpath() should collapse them.  Let the user decide.
 
 0 ~$ perl -w ~/tmp/foo.plx '../../bar'
 ../../bar
 0 ~$ perl -w ~/tmp/foo.plx 'foo/../../bar'
 ../bar
 0 ~$ perl -w ~/tmp/foo.plx '../foo/../../bar'
 ../../bar
 0 ~$ perl -w ~/tmp/foo.plx '/../../../bar'
 /bar
 
 There are some problems in Win32 and they look like they're due to
 File::Spec bugs.
 
 0 ~$ perl -w ~/tmp/foo.plx 'C:\foo\..\..\..\bar' Win32
 C:bar
 
 This is because:
 
 0 ~$ perl -MFile::Spec::Win32 -wle 'print join \n, 
 File::Spec::Win32-catdir(, .., .., )'
 
 It should be the root dir as it is on Unix.
 
 0 ~$ perl -MFile::Spec::Unix -wle 'print join \n, 
 File::Spec::Unix-catdir(, .., .., )'
 /


This should support a $base arguement just as rel2abs does. And on
WIn32 it should use GetFullPathName().

speak to you all in a long while im off to Toronto for a month...

cheers,
yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32

2005-07-09 Thread demerphq

On 7/9/05, Glenn Linderman [EMAIL PROTECTED] wrote:
 On approximately 7/8/2005 2:07 PM, came the following characters from
 the keyboard of demerphq:
 
  On 7/8/05, Michael G Schwern [EMAIL PROTECTED] wrote:
 
 On Fri, Jul 08, 2005 at 03:50:49PM +0200, demerphq wrote:
 
 Im not sure if this is useful, but many of the things that File::Spec
 tries to do on win32 are actually supported directly by the Win32 API.
 IMO at least some of File::Spec's behaviour could take advantage of
 this API.
 
 Win32::GetFullPathName() is the one i have in mind when I say this.
 
 perl -e use Win32; print Win32::GetFullPathName(qq[foo\\..\\bar]);
 
 outputs CWD\bar.
 
 So if you strip off the CWD from the result of
 Win32::GetFullPathName() you get the OS'es solution of this problem,
 which should bypass all of these issues.
 
 Does it?  It still leaves us asking the question: can we assume foo\..\bar 
 ==
 bar on Windows?  Just because a system call does it that way doesn't mean
 its right.
 
 
  Well, i suppose you are correct. Im not entirely sure what scenario I
  should be testing here, but i beleive the problem you are thinking of
  is due to symlinks to a directory? If so then the win32 equivelent
  would be a junction I think and in that case yes, foo\..\bar == bar.
 
  D:\dev\junctjunction foo
 
  Junction v1.03 - Win2K junction creator and reparse point viewer
  Copyright (C) 2000-2002 Mark Russinovich
  Systems Internals - http://www.sysinternals.com
 
  D:\dev\junct\foo: JUNCTION
 Substitute Name: d:\dev\test
 
  D:\dev\junctecho Test1  foo\..\test.echo
 
  D:\dev\juncttype test.echo
  Test1
 
  D:\dev\junctcd ..
 
  D:\devecho test2  test\..\test.echo
 
  D:\devtype test.echo
  test2
 
 OK, you have just proven that the file is the same whether accessed by
 one name or the other.  Now that you have the junction set up, how about
 reporting on the results of:
 
 d:
 md \dev\junct\bar
 cd \dev\junct
 cd foo\..\bar
 cd ..
 cd foo
 cd ..
 cd \dev\test
 cd foo\..\bar
 cd ..
 cd foo
 cd ..
 
 showing all the prompts that display the current path name in the sequence?

im not sure if your script exploited the structure i set up properly or not.

I had d:\dev\junct\foo - d:\dev\test

so creating a directory in junct doesnt create it in test. Heres the
full output with me adding directories to resolve the cant find
directory errors. I ran the script you requested three times as
junct.bat.

D:\devjunction junct\foo

Junction v1.03 - Win2K junction creator and reparse point viewer
Copyright (C) 2000-2002 Mark Russinovich
Systems Internals - http://www.sysinternals.com

D:\dev\junct\foo: JUNCTION
   Substitute Name: d:\dev\test


D:\devjunct.bat

D:\devd:

D:\devmd \dev\junct\bar

D:\devcd \dev\junct

D:\dev\junctcd foo\..\bar

D:\dev\junct\barcd ..

D:\dev\junctcd foo

D:\dev\junct\foocd ..

D:\dev\junctcd \dev\test

D:\dev\testcd foo\..\bar
The system cannot find the path specified.

D:\dev\testcd ..

D:\devcd foo
The system cannot find the path specified.

D:\devcd ..

D:\cd dev\test

D:\dev\testdir
 Volume in drive D is Data
 Volume Serial Number is C836-51DB

 Directory of D:\dev\test

2005-07-08  16:24   DIR  .
2005-07-08  16:24   DIR  ..
2005-07-08  16:246 foo.txt
   1 File(s)  6 bytes
   2 Dir(s)  69,569,888,256 bytes free

D:\dev\testmd foo

D:\dev\testcd ..

D:\devjunct.bat

D:\devd:

D:\devmd \dev\junct\bar
A subdirectory or file \dev\junct\bar already exists.

D:\devcd \dev\junct

D:\dev\junctcd foo\..\bar

D:\dev\junct\barcd ..

D:\dev\junctcd foo

D:\dev\junct\foocd ..

D:\dev\junctcd \dev\test

D:\dev\testcd foo\..\bar
The system cannot find the path specified.

D:\dev\testcd ..

D:\devcd foo
The system cannot find the path specified.

D:\devcd ..

D:\cd dev\test

D:\dev\testdir
 Volume in drive D is Data
 Volume Serial Number is C836-51DB

 Directory of D:\dev\test

2005-07-09  08:35   DIR  .
2005-07-09  08:35   DIR  ..
2005-07-09  08:35   DIR  foo
2005-07-08  16:246 foo.txt
   1 File(s)  6 bytes
   3 Dir(s)  69,569,888,256 bytes free

D:\dev\testcd foo

D:\dev\test\foocd ..

D:\dev\testmd bar

D:\dev\testcd ..

D:\devjunct.bat

D:\devd:

D:\devmd \dev\junct\bar
A subdirectory or file \dev\junct\bar already exists.

D:\devcd \dev\junct

D:\dev\junctcd foo\..\bar

D:\dev\junct\barcd ..

D:\dev\junctcd foo

D:\dev\junct\foocd ..

D:\dev\junctcd \dev\test

D:\dev\testcd foo\..\bar

D:\dev\test\barcd ..

D:\dev\testcd foo

D:\dev\test\foocd ..

D:\dev\test



 -- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning

On 7/8/05, Dave Mitchell [EMAIL PROTECTED] wrote:
 On Tue, Jun 07, 2005 at 04:28:08PM -, Nicholas Clark wrote:
  ./perl -Ilib -we '$term = \xe9; $target = \xe9\x{100}; chop $target; 
  $target =~ /$term/i'
  Malformed UTF-8 character (unexpected non-continuation byte 0x00, 
  immediately after start byte 0xe9) in pattern match (m//) at -e line 1.
 
 
 it turns out perl is totally borked for
 
 $utf8 =~ /latin1/i
 and
 
 $latin1 =~ /$utf8/i
 
 unless all the chars happen to be  0x7f.

The case where the pattern is /(foo|bar)/ is handled by a totally
different codepath in blead, does it also fail there? I seem to recall
that I put in tests for this, but possibly im wrong. Im flying on
holiday in less than 24 hours and i doubt Ill be able to check until i
return at the end of the month.
 
cheers,
yves


-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning

On 7/8/05, Dave Mitchell [EMAIL PROTECTED] wrote:
 On Fri, Jul 08, 2005 at 09:24:42AM +0200, demerphq wrote:
   it turns out perl is totally borked for
  
   $utf8 =~ /latin1/i
   and
  
   $latin1 =~ /$utf8/i
  
   unless all the chars happen to be  0x7f.
 
  The case where the pattern is /(foo|bar)/ is handled by a totally
  different codepath in blead, does it also fail there? I seem to recall
  that I put in tests for this, but possibly im wrong. Im flying on
  holiday in less than 24 hours and i doubt Ill be able to check until i
  return at the end of the month.
 
 $ ./perl -Ilib -wle '$x=\xe9\x{100};chop$x; print 1 if $x=~/(abc|\xe9)/i'
 1
 
 $ ./perl -Ilib -wle '$x=\xe9\x{100};chop$x; print 1 if \xe9=~/(abc|$x)/i'
 Malformed UTF-8 character (unexpected non-continuation byte 0x00, 
immediately after start byte 0xe9) in pattern match (m//) at -e line 1.

Well, i guess half wrong is better than all wrong but that still
sucks. Maybe ill get some time to put together a patch on the plane.

thanks tho.

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32

On 7/6/05, Ken Williams [EMAIL PROTECTED] wrote:
 
 On Jul 6, 2005, at 4:00 PM, Dinger, Tom wrote:
 
  To be perfectly honest, I don't care which way it is fixed, as long
  as the
  result still points to the right file.
 
 Of course.  That's what I'm asking: is bar guaranteed on Windows to
 be the right file when the input is foo\\..\\bar?  On Unix, it's
 not.
 
 I've never disputed the bug.  The current behavior is obviously wrong.

Im not sure if this is useful, but many of the things that File::Spec
tries to do on win32 are actually supported directly by the Win32 API.
IMO at least some of File::Spec's behaviour could take advantage of
this API.

Win32::GetFullPathName() is the one i have in mind when I say this.

perl -e use Win32; print Win32::GetFullPathName(qq[foo\\..\\bar]);

outputs CWD\bar. 

So if you strip off the CWD from the result of
Win32::GetFullPathName() you get the OS'es solution of this problem,
which should bypass all of these issues. Ie, crudely:

use Win32;
use Cwd qw(cwd);

sub canonpath {
my $path=shift;

$ret=Win32::GetFullPathName($path);
if ($path!~/^\w:/) {
(my $cwd=cwd()./)=~s!/!\\!g;
while (substr($cwd,0,1) eq substr($ret,0,1)) {
substr($cwd,0,1,);
substr($ret,0,1,);
}
}
return $ret;
}


print canonpath(foo/../../../bar/baz);

BTW, i say crudely, because I dont think that canonpath is very well
defined. Is it a relative path or not? Should it function differently?

Likewise, File::Spec::rel2abs() should be rewritten to be a
passthrough to Win32::GetFullPathName().

Anyway, the point is that using Win32::GetFullPathName() is available
to resolve a bunch of these issues (at least as far as Win32 goes).

Yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning

On 7/8/05, Dave Mitchell [EMAIL PROTECTED] wrote:
 On Fri, Jul 08, 2005 at 09:24:42AM +0200, demerphq wrote:
   it turns out perl is totally borked for
  
   $utf8 =~ /latin1/i
   and
  
   $latin1 =~ /$utf8/i
  
   unless all the chars happen to be  0x7f.
 
  The case where the pattern is /(foo|bar)/ is handled by a totally
  different codepath in blead, does it also fail there? I seem to recall
  that I put in tests for this, but possibly im wrong. Im flying on
  holiday in less than 24 hours and i doubt Ill be able to check until i
  return at the end of the month.
 
 $ ./perl -Ilib -wle '$x=\xe9\x{100};chop$x; print 1 if $x=~/(abc|\xe9)/i'
 1
 
 $ ./perl -Ilib -wle '$x=\xe9\x{100};chop$x; print 1 if \xe9=~/(abc|$x)/i'
 Malformed UTF-8 character (unexpected non-continuation byte 0x00, immediately 
 after start byte 0xe9) in pattern match (m//) at -e line 1.
 

Attached patch fixes it in the TRIE(FL?)? code afaict. 

D:\dev\perl\liveperl -Ilib -wle $x=qq[\xe9\x{100}]; chop $x; print 1
if qq[\xe9]=~/(abc|$x)/i
1

D:\dev\perl\liveperl -Ilib -wle $x=qq[\xe9\x{100}]; chop $x; print 1
if $x=~/(abc|\xe9)/i
1

Yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/
--- regexec.c.bak	2005-07-08 17:02:45.171875000 +0200
+++ regexec.c	2005-07-08 17:03:02.15625 +0200
@@ -2612,7 +2612,7 @@
 
 		if ( base ) {
 
-			if ( do_utf8 || UTF ) {
+			if ( do_utf8 ) {
 			if ( foldlen0 ) {
 uvc = utf8n_to_uvuni( uscan, UTF8_MAXLEN, len, uniflags );
 foldlen -= len;
@@ -2678,7 +2678,7 @@
 
 		if ( base ) {
 
-			if ( do_utf8 || UTF ) {
+			if ( do_utf8 ) {
 			uvc = utf8n_to_uvuni( (U8*)uc, UTF8_MAXLEN, len, uniflags );
 			} else {
 			uvc = (U32)*uc;

Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32

On 7/8/05, Michael G Schwern [EMAIL PROTECTED] wrote:
 On Fri, Jul 08, 2005 at 03:50:49PM +0200, demerphq wrote:
  Im not sure if this is useful, but many of the things that File::Spec
  tries to do on win32 are actually supported directly by the Win32 API.
  IMO at least some of File::Spec's behaviour could take advantage of
  this API.
 
  Win32::GetFullPathName() is the one i have in mind when I say this.
 
  perl -e use Win32; print Win32::GetFullPathName(qq[foo\\..\\bar]);
 
  outputs CWD\bar.
 
  So if you strip off the CWD from the result of
  Win32::GetFullPathName() you get the OS'es solution of this problem,
  which should bypass all of these issues.
 
 Does it?  It still leaves us asking the question: can we assume foo\..\bar ==
 bar on Windows?  Just because a system call does it that way doesn't mean
 its right.

Well, i suppose you are correct. Im not entirely sure what scenario I
should be testing here, but i beleive the problem you are thinking of
is due to symlinks to a directory? If so then the win32 equivelent
would be a junction I think and in that case yes, foo\..\bar == bar.

D:\dev\junctjunction foo

Junction v1.03 - Win2K junction creator and reparse point viewer
Copyright (C) 2000-2002 Mark Russinovich
Systems Internals - http://www.sysinternals.com

D:\dev\junct\foo: JUNCTION
   Substitute Name: d:\dev\test

D:\dev\junctecho Test1  foo\..\test.echo

D:\dev\juncttype test.echo
Test1

D:\dev\junctcd ..

D:\devecho test2  test\..\test.echo

D:\devtype test.echo
test2
 
 Anyhow, should this discussion drag on any longer without resolution there's
 a simple yardstick to use:  Which retains the most information?  Not
 collapsing .. does.  So given that the current implementation is clearly
 wrong, and if we can't decide between the two right implementations, pick
 the one that's safest to at least give a correct answer.  Then we can
 discuss some more and maybe have switch to the other one.
 

Sure. My comment was mostly that by using the Win32 API's one can do
this type of stuff more reliably than with File::Spec. With the
emphasis intended to be more on this type of stuff than on the
particular problem that lead to this thread.

To be honest i would really like to see the expected behaviour of
canonpath when called on a relative path explicitly defined. IMO
canonpath should act more like rel2abs, insofar as it should support
an optional $base argument to use instead of CWD when trying to clean
up a relative path.


-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32

On 7/8/05, Michael G Schwern [EMAIL PROTECTED] wrote:
 On Fri, Jul 08, 2005 at 11:07:22PM +0200, demerphq wrote:
  should be testing here, but i beleive the problem you are thinking of
  is due to symlinks to a directory? If so then the win32 equivelent
  would be a junction I think and in that case yes, foo\..\bar == bar.
 
 I have the creeping feeling that there's an argument to be made here, but
 I never fully understood the symlinks vs .. cannonpath argument so I'll
 hope someone else jumps in and makes it.

Me too. Not being all that familiar with *nix file systems I made my
best stab at an answer as it seems to pertain to Win32. I think John
Peacock also said something to this effect.
 
  To be honest i would really like to see the expected behaviour of
  canonpath when called on a relative path explicitly defined. IMO
  canonpath should act more like rel2abs, insofar as it should support
  an optional $base argument to use instead of CWD when trying to clean
  up a relative path.
 
 canonpath() should never be inserting the CWD when cleaning up.  ./bar is
 the same as bar but $CWD/bar is not!  Its important that cannonical
 relative paths remain relative.

Sorry, i guess I didnt express myself properly.  You cant clean up a
relative path properly without knowing where it is relative to.
Consider the following path:

   ..\..\foo

If we are in \bar then ..\..\foo is the same as  ..\foo and \foo but
if we are in \bar\baz\bat then its not the same as either as it maps
to \bar\foo.

yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32

On 7/8/05, Glenn Linderman [EMAIL PROTECTED] wrote:
 On approximately 7/8/2005 1:53 PM, came the following characters from
 the keyboard of Michael G Schwern:
 
  On Fri, Jul 08, 2005 at 03:50:49PM +0200, demerphq wrote:
 
 Im not sure if this is useful, but many of the things that File::Spec
 tries to do on win32 are actually supported directly by the Win32 API.
 IMO at least some of File::Spec's behaviour could take advantage of
 this API.
 
 Win32::GetFullPathName() is the one i have in mind when I say this.
 
 perl -e use Win32; print Win32::GetFullPathName(qq[foo\\..\\bar]);
 
 outputs CWD\bar.
 
 So if you strip off the CWD from the result of
 Win32::GetFullPathName() you get the OS'es solution of this problem,
 which should bypass all of these issues.
 
 
  Does it?  It still leaves us asking the question: can we assume foo\..\bar 
  ==
  bar on Windows?  Just because a system call does it that way doesn't mean
  its right.
 
 In the presence of junction points, I think not.  The system call would
 have the opportunity to understand and check for the existance of
 junction points, but whether it does or not, is anyone's guess, without
 trying it.

Doesn't look like there is a problem with this. I guess .. is
resolved by the OS relative to ., and not a hard link to a specific
directory. (But that is pure speculation.)

D:\dev\junct\fooperl -MWin32 -eprint Win32::GetFullPathName('.');
D:\dev\junct\foo
D:\dev\junct\foocd ..\..\test

D:\dev\testperl -MWin32 -eprint Win32::GetFullPathName('.');
D:\dev\test
D:\dev\testcd ..

D:\devjunction junct\foo

Junction v1.03 - Win2K junction creator and reparse point viewer
Copyright (C) 2000-2002 Mark Russinovich
Systems Internals - http://www.sysinternals.com

D:\dev\junct\foo: JUNCTION
   Substitute Name: d:\dev\test

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [PATCH] Convert File::Basename tests to Test::More

2005-06-30 Thread demerphq

On 6/30/05, Michael G Schwern [EMAIL PROTECTED] wrote:
 Could have sworn I attached the tests.

Which time? :-)

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #36434] blead perl breask CPANPLUS-0.055 and other programs that push @ISA, PACKAGE

2005-06-30 Thread demerphq

On 6/30/05, David Dyck [EMAIL PROTECTED] wrote:
  The following 3 line test program results in the same error when pushing 
  __PACKAGE__
  onto @ISA:
 our @ISA = qw(a b);
 push @ISA, 'main';
 push @ISA, __PACKAGE__;
 
  Modification of a read-only value attempted at isabug.pl line 3.
 
 if I change the line
  push @ISA, __PACKAGE__;
 to
  push @ISA, __PACKAGE__.'';
 
 then the error message is also supressed!

Why would you do this anyway? What is the point of a package being ISA itself?

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #36417] IO::Handle::getline() doco should note an important difference from $io

2005-06-29 Thread demerphq

On 6/29/05, Michael G Schwern [EMAIL PROTECTED] wrote:
 On Tue, Jun 28, 2005 at 06:25:31PM -, Justin Mason wrote:
  However, there is one key difference: while ($io) and while
  ($io-getline) ha ve different behaviour.If the last line of an input 
  file
  contains 0 (with no trailing newline), while ($io) will read it and
  perform an iteration of the while loop, but while ($io-getline) will read
  it, consider it a false value, and instead break out of the while loop.
 
 Confirmed.  while(FH) must have some sort of special case to consider
 0 true to avoid this sort of gotcha.

while (FH) {

is documented to be equivelent to

while (defined($_=FH)) {

in perlvar I/O Operators.



-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Archive::Tar is now core

2005-06-21 Thread demerphq

On 6/21/05, Rafael Garcia-Suarez [EMAIL PROTECTED] wrote:
 I added Archive::Tar to the core, this being the last addition before
 CPANPLUS.

A::T doesnt seem too happy on Win32:

Failed Test   Stat Wstat Total Fail  Failed  List of Failed
---
../ext/threads/t/problems.t  5  1280140   0.00%  ??
../lib/Archive/Tar/t/02_methods.t   36  9216   501   36   7.19%  134-135 142-
 143 182-183
 190-191 250-
 251 258-259
 266-267 274-
 275 282-283
 340-341 348-
 349 356-357
 364-365 372-
 373 414-415
 422-423 462-
 463 470-471


-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Smoke [5.9.3] 24899 FAIL(F) MSWin32 WinXP/.Net SP1 (x86/1 cpu)

2005-06-20 Thread demerphq

On 6/20/05, Steve Hay [EMAIL PROTECTED] wrote:
 Nicholas Clark wrote:
(snip error result)
 I suspect that this may be me and it may be change 24896.
 
 
 I suspect not.  I think it is the same old intermittent failure that
 I've been having for a lng time now, e.g. the smokes at patchlevels
 24856, 24828, 24798, ... all show the same errors.
 
 The smoke log says
 
 ../ext/threads/t/problems...dubious
 Test returned status 5 (wstat 1280, 0x500)
 after all the subtests completed successfully
 
 and indeed whenever I've seen it when running the tests interactively it
 is always an access violation when exiting the script (after all tests OK).

I agree. I got this problem this morning and thats exactly what it was. 

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [PATCH @ 24819] Re: Change 24806: improve static build for win32/Makefile

2005-06-17 Thread demerphq

On 6/17/05, Steve Hay [EMAIL PROTECTED] wrote:
 Jan Dubois wrote:
 
 On Thu, 16 Jun 2005, Steve Hay wrote:
 
 
 Well, I'm really confused now.
 
 A simple test program shows that system(copy ...) does indeed work
 fine, even with tainting on and $ENV{PATH} cleared (as per op/taint.t).
 
 
 
 Really?  I think the clearing of $ENV{PATH} is the problem because Perl
 will use an unqualified cmd.exe /x/d/c or command.com /c to invoke
 the shell (it doesn't use $ENV{COMSPEC}.  So if you clear $ENV{PATH}
 it will not be able to find cmd.exe.
 
 Sounds sensible, however
 
 #!perl -T
 use strict;
 use warnings;
 $ENV{PATH} = '';
 system(copy C:\\Borland\\BCC55\\Bin\\cc3250mt.dll .)  die Error: $!;
 
 works perfectly, copying the DLL to the current directory!
 
 In fact, if I use system() to invoke a program that can only be found
 via the PATH, e.g. diff -v only works when C:\cygwin\bin is in my
 PATH, then I find that the system() call works fine even after I've
 cleared $ENV{PATH}!
 
 How can this be?
 
 And why doesn't it work in t/op/taint.t?

Thats weird. I get an error:

D:\dev\Stufftype copyx.pl
#!perl -T
use strict;
use warnings;
$ENV{PATH} = '';
my ($exe)=$^X=~/^(.*)$/s;
print Copying '$exe' to .\n;
system(copy $exe .)  die Error: $!;

D:\dev\Stuffperl -T copyx.pl
Copying 'D:\ASPerl\811\bin\perl.exe' to .
Can't spawn cmd.exe: No such file or directory at copyx.pl line 7.
Error: No such file or directory at copyx.pl line 7.

Jan mentioned that the code automatically uses the appropriate shell
in certain cases, but expects to be able to find the shell via the
path, but we could just as easily check the system registry for the
SystemRoot key/value and use that instead. IMO since it would be a
system registry setting it need not be treated as tainted, (although i
could see it argued the other way).



-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [PATCH @ 24819] Re: Change 24806: improve static build for win32/Makefile

2005-06-17 Thread demerphq

On 6/17/05, demerphq [EMAIL PROTECTED] wrote:

 print Copying '$exe' to .\n;
 system(copy $exe .)  die Error: $!;

Sigh. I guess $exe should be quoted. Although maybe not. I hate the
inconsistancies in argument parsing in cmd.exe.

system(qq[copy $exe .])  die Error: $!;

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [PATCH @ 24819] Re: Change 24806: improve static build for win32/Makefile

2005-06-17 Thread demerphq

On 6/17/05, Steve Hay [EMAIL PROTECTED] wrote:
 Ah, but I see you're using ActivePerl 811 (and I dare say Jan is too ;-)
 
 I'm using a Perl that I built myself.  If I try your program with AP811
 then I get the same error that you see.  Also, when testing t/op/taint.
 I was running a different Perl, which was built with out-of-the-box
 options, which are much closer to the ActivePerl configuration, hence
 the reason why that test script was not working for me either!
 
 So it must be something in my build of Perl, but what?!  My Perl works
 even with $ENV{COMSPEC} cleared.
 
 Here's my perl -V.  Basically, I've disabled
 USE_MULTI/USE_IMP_SYS/USE_ITHREADS and USE_LARGE_FILES, and enabled
 PERL_MALLOC/DEBUG_MSTATS.  I wonder which of those things is
 responsible, and why...

Im wondering what happens if spawn a shell with cmd /k and see what
the enviornment looks like, or maybe simpler just do system('set') I
have a feeling somehow the settings you are using are not propagating
changes to the enviornement. It would be interesting to know if that
were the case.

system(set path)  die Error: $!;

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [PATCH pod/perlfunc.pod pod/perlobj.pod pod/perltooc.pod] Recommend Against NIVERSAL:: Methods as Functions

2005-06-16 Thread demerphq

On 6/16/05, Mark Jason Dominus [EMAIL PROTECTED] wrote:
 yves:
   Using UNIVERSAL::isa() is IMO bad as its suseptible to
 
 my $obj=3Dbless [],'HASH';
 
  type nonsense.
 
 Perhaps, but it seems to me that someone doing that is doing it
 deliberately to try to deceive the UNIVERSAL::isa function.  In which
 case it is a feature, not a bug.

Well, IMO reftype() is superior as its faster and cant be fooled. But
only insofar as the question being asked is Is the underlying
reference to a legitimate hash.

But the other point, about overload is also important. If an object of
class Foo::Bar overloads hash dereferencing then it too probably
should be consider to be isa('HASH') but it isnt.

So theres three possible questions:

1. Is the object underneath the hood implemented with a given perl type
2. Is the object a member of the class TYPE or a class that inherits from it
3. Does the object provide an TYPE like interface.

The first one can only be reliably done with reftype. the second with
isa, the third with reftype and overload.

All im trying to say here is that the subject is not so simple as to
admit that isa is the recommended way to do this. IMO in fact isa is
NOT the recommended way to do this.

Although that still begs the question what this is. In the code that
chromatic removed IMO the question being asked is 3 which isnt
answered properly by isa() because it ignores classes that arenot
isa('HASH') but do overload hash dereferencing, and conversly can be
fooled by objects that are isa('HASH') but arent reftype() eq 'HASH'
and arent overloaded.

yves


-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Recent changes in blead-perl breaks Devel-Size-0.59 and Algorithm-Permute-0.06

2005-06-16 Thread demerphq

On 6/16/05, Nicholas Clark [EMAIL PROTECTED] wrote:
 Sorry for the delay in this answer

No problem.

 On Wed, Jun 01, 2005 at 06:54:30PM +0200, demerphq wrote:
  On 6/1/05, Nicholas Clark [EMAIL PROTECTED] wrote:
   It would be interesting if someone found some good way of benchmarking 
   perl,
   and compared current blead with released 5.9.2
 
  Is perlbench not the right way? What does good imply for you?
 
 perlbench seems to be remarkably good at showing no real difference in
 speed whatever changes it's being trialled with.
 
 I think that Jarkko noted that the size of things it manipulates are tiny
 compared with CPU caches, so it won't demonstrate any improved efficiency
 in cache usage.
 
 Also, it concentrates on its tests being as backwards compatible as possible,
 with most running on perl4, so we're not convinced that it's really testing
 constructions that are used these days
 
 It tests things in a tight loop, so it's testing execution time only. If we
 optimise the startup time of perl, it's not going to reward us with better
 numbers.
 
 IIRC it showed no change with the introduction of shared hash keys, or at
 least with the introduction of optimisations to take advantage of them,
 yet Nick I-S reported that some TK programs were 2% faster, something
 a reasonable benchmark should be capable of spotting.
 
 I guess it's still measuring package variables and procedural code, when
 far more of the world is using lexicals and objects these days.

So what you are saying in is that we aught to rewrite perlbench for
the 5.[689] world?

I think that could be an interesting project. I put together a
framework for cross testing different versions of the perl regex stuff
so maybe ill give this a go.  I guess ideally it would be a plug and
play scenario.

Also, would there be any disagreement that ditching normalization
logic is acceptable? IMO its just a waste of time if you are doing
wallclock comparisons of two perl executables on the same machine
under similar load (which I reckon most of us would be doing).

Yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Unexpected parsing of print statement... Is this correct behaviour?

Should this be perlbug'ed? It seems like the + operator is mistakenly
being taken for the unary plus and not the binary plus.

perl -Mwarnings -e my $x = 10; my $y = 20; print $x +$y;
print() on unopened filehandle 10 at -e line 1.

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Unexpected parsing of print statement... Is this correct behaviour?

On 6/15/05, H.Merijn Brand [EMAIL PROTECTED] wrote:
 On Wed, 15 Jun 2005 00:59:55 -0700, Michael G Schwern [EMAIL PROTECTED]
 wrote:
 
  On Wed, Jun 15, 2005 at 08:51:43AM +0200, demerphq wrote:
   Should this be perlbug'ed? It seems like the + operator is mistakenly
   being taken for the unary plus and not the binary plus.
  
   perl -Mwarnings -e my $x = 10; my $y = 20; print $x +$y;
   print() on unopened filehandle 10 at -e line 1.
 
  You can shave that down to just: print $x +$y
 
  $ bleadperl -MO=Deparse -e 'print $x +$y;'
  print $x $y;
  -e syntax OK
 
  $ bleadperl -we 'print $x +$y;'
  Name main::y used only once: possible typo at -e line 1.
  Name main::x used only once: possible typo at -e line 1.
  Can't use an undefined value as a symbol reference at -e line 1.
 
 It gets better:
 
 pc09:/home/merijn 102  perl -we'print$- +$='
 print() on unopened filehandle 0 at -e line 1.
 pc09:/home/merijn 103  perl -we'print$/ +$='
 print() on unopened filehandle
 pc09:/home/merijn 104  perl -we'print$, +$='
 Can't use an undefined value as a symbol reference at -e line 1.
 Exit 255
 pc09:/home/merijn 105 
 
 And probably a lot more :)

It seems like it only happens with + and -, somehow their precedence
is too low for the print statement. Although there is odd behaviour of
'/' but i suspect that is something totally different. Also note that
adding parens doesn't help.

perl -wemy ($x,$y)=(1,2); print $x +$y;
print() on unopened filehandle 1 at -e line 1.

perl -wemy ($x,$y)=(1,2); print $x /$y;
Search pattern not terminated at -e line 1.

perl -wemy ($x,$y)=(1,2); print $x -$y;
print() on unopened filehandle 1 at -e line 1.

perl -wemy ($x,$y)=(1,2); print $x *$y;
2
perl -wemy ($x,$y)=(1,2); print $x %$y;
1
perl -wemy ($x,$y)=(1,2); print $x $y;
0
perl -wemy ($x,$y)=(1,2); print $x |$y;
3
perl -wemy ($x,$y)=(1,2); print $x $y;
1
perl -wemy ($x,$y)=(1,2); print $x $y;

perl -wemy ($x,$y)=(1,2); print $x =$y;
2
perl -wemy ($x,$y)=(1,2); print($x +$y);
print() on unopened filehandle 1 at -e line 1.

perl -wemy ($x,$y)=(1,2); print($x -$y);
print() on unopened filehandle 1 at -e line 1.


The perldoc for this says 

print FILEHANDLE LIST
print LIST
print   Prints a string or a list of strings. Returns true if
successful. FILEHANDLE may be a scalar variable name, in which
case the variable contains the name of or a reference to the
filehandle, thus introducing one level of indirection. (NOTE: If
FILEHANDLE is a variable and the next token is a term, it may be
misinterpreted as an operator unless you interpose a + or put
parentheses around the arguments.) 

Maybe i don't understand the NOTE there properly, but it doesnt seem
to explain what is going on in this case.

Yves
ps: Im using the lexicals in there so as not to confuse the issue with
undef values and the like, but you are correct it applies to lexical
and non lexicals alike.


-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Unexpected parsing of print statement... Is this correct behaviour?

On 6/15/05, Rafael Garcia-Suarez [EMAIL PROTECTED] wrote:
 demerphq wrote:
  Although there is odd behaviour of
  '/' but i suspect that is something totally different. Also note that
  adding parens doesn't help.
 
 / is the beggining of a /.../ regexp. Note that // still parses as a
 binary operator here (not an empty pattern.)

Just to be clear the Also note that adding parens doesn't help.
referred to the $a +$b case, not the $a /$b case.

Yves



-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Unexpected parsing of print statement... Is this correct behaviour?

On 6/15/05, Tassilo von Parseval [EMAIL PROTECTED] wrote:
 so it's not that the current behaviour should be such a surprise to an
 experienced user. For me it's mostly an aesthetic question really. Do we
 want this couple:
 
 print $x +$y;   # means: $x + $y
 print { $x } +$y;
 
 or rather this one:
 
 print $x +$y;   # means: print { $x } +$y;
 print $x + $y;
 
 The second one is visually less offending. Futhermore, there is no
 style-guide I know of that suggests using a space before a binary
 operator but not after it. Perl should make such ugliness as hard to
 employ as possible.

I'm with Schwern. The first one is the only logical scenario. 

print $x +$y; # should mean $x + $y always
print $x $y; # should mean print { $x } $y

since the latter is legal and the recommended way to write to a
lexical filehandle making the former a synonym for it seriously
violates the principle of least surprise. Also taking this approach
the docs become correct again i think.

yves



-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Unexpected parsing of print statement... Is this correct behaviour?

On 6/15/05, Tassilo von Parseval [EMAIL PROTECTED] wrote:
 On Wed, Jun 15, 2005 at 01:30:12PM +0200 demerphq wrote:
 
  On 6/15/05, Tassilo von Parseval [EMAIL PROTECTED] wrote:
   so it's not that the current behaviour should be such a surprise to an
   experienced user. For me it's mostly an aesthetic question really. Do we
   want this couple:
  
   print $x +$y;   # means: $x + $y
   print { $x } +$y;
  
   or rather this one:
  
   print $x +$y;   # means: print { $x } +$y;
   print $x + $y;
  
   The second one is visually less offending. Futhermore, there is no
   style-guide I know of that suggests using a space before a binary
   operator but not after it. Perl should make such ugliness as hard to
   employ as possible.
 
  I'm with Schwern. The first one is the only logical scenario.
 
  print $x +$y; # should mean $x + $y always
  print $x $y; # should mean print { $x } $y
 
  since the latter is legal and the recommended way to write to a
  lexical filehandle making the former a synonym for it seriously
  violates the principle of least surprise. Also taking this approach
  the docs become correct again i think.
 
 They are still incomplete then. From 'perldoc -f print':
 
Note that if you're storing FILEHANDLES in an array or other
expression, you will have to use a block returning its value
instead:
 
print { $files[$i] } stuff\n;
print { $OK ? STDOUT : STDERR } stuff\n;
 
 Note how that implies that I can always use a simple scalar as
 filehandle without the need for a block.

Unless made explicit the implication you mean is not at all clear and obvious.
 
 Other than that, there is no logical scenario here. Unary plus and minus
 are legitimate operators in Perl. Assuming the user meant the binary
 counterparts is an entirely arbitrary decision. 

I don't agree at all. Having unary behaviour occur when binary
behaviour is a valid possibility is a bug. While it may be a bug we
have to accept I refuse to accept that this is an entirely arbitrary
decision. That flys in the face of hundreds of years of accepted
mathematical practice.

If we are going to accept this bug then we need specifically document
it as it totally breaks reasonable expectation. And the inconsistancy
in it is IMO a big problem. Why should a space determine whether an
operator is binary or unary? And why should it only do so when
indirect notation is involved?

yves



-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Unexpected parsing of print statement... Is this correct behaviour?

On 6/15/05, Rafael Garcia-Suarez [EMAIL PROTECTED] wrote:
 demerphq wrote:
  If we are going to accept this bug then we need specifically document
  it as it totally breaks reasonable expectation. And the inconsistancy
  in it is IMO a big problem. Why should a space determine whether an
  operator is binary or unary?
 
 Because the perl parser hasn't infinite lookahead. Look at toke.c, there
 are hundreds of heuristics like that hardcoded into perl, for the same
 reason : maximising DWIMmery. Not a bug.

Well IMO that answer only applies to Why is perl doing this it
doesnt answer the why should that be. AFAICT There is no good reason
why that should be. Its an implementation quirk, and a bug until its
documented, which afaict it isn't. At very least it isnt documented in
such a way that its clear what is going on.
 
yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [PATCH @ 24819] Re: Change 24806: improve static build for win32/Makefile

On 6/14/05, Steve Hay [EMAIL PROTECTED] wrote:
 demerphq wrote:
 Ok, fine. So we cant go that route. Howsabout a different mechansim.
 
 We can replace the usage of XCOPY with a batchfile that acts as a
 wrapper to OSize the command, ie here is xcopyit.bat that i just put
 together:
 
 [snip batch file with nice trick!]
 
 Note also the echo trick prevents the Does foo specify a file name or
 directory name on target
 
 I don't think that would be required in the Perl Makefiles because the
 XCOPY commands all have the /i switch, meaning such ambiguities are
 resolved as directories.

Except if there is only one file involved. I saw you actually reworked
the makefile some time back to avoid this problem so maybe there are
no further examples.

 
 and can also be used for Y/N questions and
 answers too
 
 :)  Well, that's the answer, then, isn't it?

Heh. Too concerned with the forest to notice that damn tree. :-)

 The following simple Makefile patch works nicely for me on WinXP:
 
  //depot/perl/win32/Makefile#272 - C:\p5p\bleadperl\win32\Makefile 
 @@ -551,8 +551,8 @@
  CFGH_TMPL  = config_H.vc
  !ENDIF
 
 -XCOPY  = xcopy /f /r /i /d
 -RCOPY  = xcopy /f /r /i /e /d
 +XCOPY  = echo A|xcopy /f /r /i /d
 +RCOPY  = echo A|xcopy /f /r /i /e /d
  NOOP   = @rem
  NULL   =
 
 (The A means all in the Yes/No/All question.)  Does this work for
 you?  Does it work on Win95?

AFAIK yes. Im still waiting for my friend with Win98 to tell me. 

 
 If the echo F| trick isnt needed it causes a superfluous The process
 tried to write to a nonexistant pipe
 
 When?  Where?  I don't see any such messages on WinXP.

I get them on NT 4 when i test moving multiples  files. But i like
your approach better actually.

The only problem with this is apparently localization issues. If you
aren't in an English locale then the letter may not be 'A'.

Cheers,
Yves


-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [PATCH pod/perlfunc.pod pod/perlobj.pod pod/perltooc.pod] Recommend Against NIVERSAL:: Methods as Functions

On 6/15/05, Mark Jason Dominus [EMAIL PROTECTED] wrote:
 
  The attached patch rephrases three pieces of Perl documentation which
  suggest that calling UNIVERSAL::isa() or UNIVERSAL::can() directly is a
  good idea.  The revised version explains why it's a bad idea and gives
  more correct recommendations.
 
 You seem to have removed all mentions of use of UNIVERSAL::isa($x,
 'HASH') without either introducing any equivalent replacement or
 indicating any valid reason why it would be a bad idea.
 
 This use of UNIVERSAL::isa is essentially orthogonal to the other
 uses; I think it makes sense to leave it in and document it separately.

Chromatic parenthetically mentioned the replacement for this usage
didn't he? I would have thought that Scalar::Util::reftype() is the
prefered way to do this. (1)

 Using UNIVERSAL::isa() is IMO bad as its suseptible to 

   my $obj=bless [],'HASH';

type nonsense. Having said that, neither reftype() nor
UNIVERSAL::isa() suffice when you consider that most times what you
want to know is whether the object is capable of being dereferenced as
a hash. To do that properly you need to use overload::Overloaded() in
combination with one of the other methods.

Maybe this subject deserves a bigger discussion in the docs?

yves

(1) IMO its a bummer that reftype returns undef for non references as
if it were Pl_sv_no you could say

  if (reftype($foo) eq 'HASH') { ... }

without dealing with warnings. As it is you have to say 

 if (ref $foo and reftype($foo) eq 'HASH') { ... }

which is a bit annoying.

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Anonymous, read-only repo access

On 6/13/05, Michael G Schwern [EMAIL PROTECTED] wrote:
 On Sun, Jun 12, 2005 at 11:42:01AM +0200, Tels wrote:
  Semi-stupid question. How do I get different patch-levels from blead? I
  know how to get the latest, but have no idea how  to checkout a certain
  patch number, or even how to find out which one I would need.
 
 I'm going to mumble something now about how it would be nice if folks
 could get read-access to the repository without having to ask for an
 account.  Sorta like every other Open Source project in the universe.
 
 perlhack states you cannot use the Perforce client... but doesn't say why.
 Its not a limitation of the Perforce Open Source license by my read.  [1]
 
   4D. Notwithstanding any other provision of this Agreement, it is the intent
   of the parties that an unlimited number of Read-Only Users be licensed
   to use the Program.
 
 Why don't we supply anonymous, read-only repository access and do away with
 the absurdity of splicing things together from patch files?
 
 
 [1]  http://www.perforce.com/perforce/contracts/open_source.pdf
 

I for one have wanted this access for a while but never said anything
because I figured it would have been on offer if it had been
available.

Being able to review change logs on various files would make certain
types of efforts much easier. For instance it would have been very
useful when i was working on the regex trie patch, and would be very
useful still for the phase 2 part of promoting TRIE regops to
Aho-Coarsick matchers. Understanding how the reganch stuff was added
would give me a lot of insight into how Illya and Larray and co
structured their optimization and boyer-moore matching code.

Thanks for bringing this up Michael, I appreciate it.

Cheers,
Yves


-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: improve static build for win32/Makefile

On 6/13/05, vadim [EMAIL PROTECTED] wrote:
  
   Probably better this way:
  
   --- perl/win32/Makefile.orig2005-06-12 03:22:35.0 -0700
   +++ perl/win32/Makefile 2005-06-12 12:42:16.12936 -0700
   @@ -696,7 +696,7 @@
!ENDIF
  
# specify static extensions here
   -STATIC_EXT = Cwd Compress/Zlib
   +STATIC_EXT =
  
   Why? I'm OK with that, but why?
 
  Because normally you wouldn't want anything built statically.
  It should show an example, though, so something like:
 
  #STATIC_EXT = Cwd Compress/Zlib
  STATIC_EXT =
 
  would be good.
 
 Indeed, better way is to have an example but empty string by default.
 
 Also, win32/Makefile and win32/makefile.mk differ by DYNAMIC_EXT
 macro.

Could that be because DYNAMIC_EXT macro is only used in the CE build?
I dont see a single reference to it in  the Makefile.mk except where
it is defined, and from what i can tell theres nothing that uses it
except in Makefile.ce

Note its defined totally differently in  config.[vb]c(?:64)?  and is
claculated dynamically in buildext.pl by FindExt.pm

Am i missing some way this macro is useful?

Yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Change 24806: improve static build for win32/Makefile

On 6/13/05, vadim [EMAIL PROTECTED] wrote:
  Change 24806 by [EMAIL PROTECTED] on 2005/06/12 09:54:07

   Subject: improve static build for win32/Makefile
   From: vadim [EMAIL PROTECTED]
   Date: Sun, 12 Jun 2005 14:09:11 -0400
   Message-Id: [EMAIL PROTECTED]

  I guess it serves me right for not being around at weekends, but I wish
  this hadn't been committed in my absence.  Did you try this on Win32
  before committing?

  I've long meant to have a look at a problem with the static build stuff
  in win32/makefile.mk but have never had time to get around to it.  The
  problem is that $(PERLDLL) depends on Extensions_static, which is a
  pseudo-target -- there is no file of that name -- hence make always
  considers it to be out-of-date.

  Now the win32/Makefile has the same problem :(

 Well, this is due to my limited understanding of nmake (and dmake).

 While trying to fix broken things (those STATIC_EXT and DYNAMIC_EXT are
 for years, and were not working, even related C code was broken) I
 introduced a problem.

 Could you please advice on a good way to fix?

 May be it is reasonable to create a real empty file with that name?

 Also, how it is possible there is no problem with pseudo-targer
 Entensions but there is a problem with Entensions_static

Timing. It happens at the wrong time.

Give me 10 minutes and ill post a patch that sorts things out. Im just
resynching as i forgot to copy the tree before I put together my
patch.

Yves 

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Threads.xs breaks [EMAIL PROTECTED]: 'PL_shared_hek_table' : undeclared identifier

I think something applied today (in the past hour or so) broke threads.xs

I rsynched this morning and there was no problem, i re-rsynched an
hour or so later and boom.

Yves

Making threads
nmake -nologo
cl -c-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32
-D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_C
ONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi
-DNDEBUG -O1-DVERSION=\1.06\  -DXS_VERSION=\
1.06\  -I..\..\lib\CORE   threads.c
threads.c
threads.xs(618) : error C2065: 'PL_shared_hek_table' : undeclared identifier
threads.xs(618) : warning C4047: '=' : 'int' differs in levels of
indirection from 'PTR_TBL_t *'
threads.xs(650) : warning C4047: 'function' : 'PTR_TBL_t *' differs in
levels of indirection from 'int'
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.
Unsuccessful make(threads): code=512 at buildext.pl line 142.
NMAKE : fatal error U1077: '..\miniperl.exe' : return code '0x2'
Stop.


-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Change 24806: improve static build for win32/Makefile

On 6/13/05, demerphq [EMAIL PROTECTED] wrote:
 On 6/13/05, vadim [EMAIL PROTECTED] wrote:
   Change 24806 by [EMAIL PROTECTED] on 2005/06/12 09:54:07

Subject: improve static build for win32/Makefile
From: vadim [EMAIL PROTECTED]
Date: Sun, 12 Jun 2005 14:09:11 -0400
Message-Id: [EMAIL PROTECTED]

   I guess it serves me right for not being around at weekends, but I wish
   this hadn't been committed in my absence.  Did you try this on Win32
   before committing?

   I've long meant to have a look at a problem with the static build stuff
   in win32/makefile.mk but have never had time to get around to it.  The
   problem is that $(PERLDLL) depends on Extensions_static, which is a
   pseudo-target -- there is no file of that name -- hence make always
   considers it to be out-of-date.

   Now the win32/Makefile has the same problem :(

  Well, this is due to my limited understanding of nmake (and dmake).

  While trying to fix broken things (those STATIC_EXT and DYNAMIC_EXT are
  for years, and were not working, even related C code was broken) I
  introduced a problem.

  Could you please advice on a good way to fix?

  May be it is reasonable to create a real empty file with that name?

  Also, how it is possible there is no problem with pseudo-targer
  Entensions but there is a problem with Entensions_static

 Timing. It happens at the wrong time. 

 Give me 10 minutes and ill post a patch that sorts things out. Im just
 resynching as i forgot to copy the tree before I put together my
 patch.

Double /grr as the rsynch seems to have introduced a seperate
unrelated problem, and the patch i thought would sort it all out
doesnt work as expected.

However, the attached patch will at least get the smokes running
properly by preventing the do you want to overwrite question in
xcopy.

Incidentally this change has been proposed before _several_ times
(adding /y to the xcopy) The reason it was rejected in the past is
that the /y isn't supported on Win9x/Me, but i think its safe to say
that nowadays there isnt anybody building perl on those OS'es, and
frankly if one does pop up they can remove the /y instead of forcing
everybody who DOES actively build perl on Win32 to add the /y
themselves. (I beleive there are several people build perl regularly
under Win2k and WinXP which does support the /y, why penalize them
when there isnt any sign of anybody building on those OS'es?)

Of course it doesnt resolve the problem that all of the extensions are
relinked, but that is just a PITA and not a showstopper like the xcopy
problem.

Cheers,
Yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

fix_static.patch
Description: Binary data

Re: [PATCH @ 24819] Re: Change 24806: improve static build for win32/Makefile

On 6/13/05, H.Merijn Brand [EMAIL PROTECTED] wrote:
 On Mon, 13 Jun 2005 15:41:41 -0400, vadim [EMAIL PROTECTED] wrote:
  I already have a patch.
  May be its not perfect.
 
 I'll leave it to Steve

Please could we not forget or overlook or otherwise warnock the issue
of the /y flag on XCOPY and other aspects of the Win32 makefiles that
are included only to be able to build on operating systems that MS no
longer supports and has sent out End Of Life notices on?

Does _anybody_ on this list build perl on pre win2k machines nowadays?

Yves



-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [PATCH @ 24819] Re: Change 24806: improve static build for win32/Makefile

On 6/13/05, Steve Hay [EMAIL PROTECTED] wrote:
 demerphq wrote:
 
 On 6/13/05, H.Merijn Brand [EMAIL PROTECTED] wrote:
 
 
 On Mon, 13 Jun 2005 15:41:41 -0400, vadim [EMAIL PROTECTED] wrote:
 
 
 I already have a patch.
 May be its not perfect.
 
 
 I'll leave it to Steve
 
 
 
 Please could we not forget or overlook or otherwise warnock the issue
 of the /y flag on XCOPY and other aspects of the Win32 makefiles that
 are included only to be able to build on operating systems that MS no
 longer supports and has sent out End Of Life notices on?
 
 Does _anybody_ on this list build perl on pre win2k machines nowadays?
 
 My own gut feeling is that building on Win9x/WinNT4 should still be
 supported.  If you drop support for building on old OS's then it's not
 long before you also start dropping support for building with old
 compilers, and even VC++ 6 is getting rather old now.  7 is out and 8 is
 nigh if not out already.  Before you know it, you won't be able to build
 Perl with VC++ 6.  That's already happened to Parrot (the last time I
 tried, at least) and it really p***ed me off.  I wouldn't want to see it
 happen to Perl too.
 
 IIRC, Greg Matheson was on this list fairly recently, building Perl on
 Win98.  Others may be doing likewise, but not even on this list.

Ok, fine. So we cant go that route. Howsabout a different mechansim.

We can replace the usage of XCOPY with a batchfile that acts as a
wrapper to OSize the command, ie here is xcopyit.bat that i just put
together:

@echo off
if %OS%== goto win95
ver | find Version 5 nul
if errorlevel 1 goto NO_Y
echo F|xcopy /y %*
goto END
:NO_Y
echo F|xcopy %* 
goto END
:WIN95
echo F|xcopy %1 %2 %3 %4 %5 %6 %7 %8 %9 
:END

We could even be cheeky and have the batch file rewrite itself with
the correct usage for the OS it is first run on, but i beleive the
above would resolve the outstanding issues with xcopy.

Note also the echo trick prevents the Does foo specify a file name or
directory name on target and can also be used for Y/N questions and
answers too, but its critical no space is in between the F and the
pipe symbol.

If the echo F| trick isnt needed it causes a superfluous The process
tried to write to a nonexistant pipe so its possible that we would
better to have several versions of the script for the different usage
requirements.

Cheers,
Yves



-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Some datapoints on hash performanc

2005-06-12 Thread demerphq

On 6/12/05, Tels [EMAIL PROTECTED] wrote:
 -BEGIN PGP SIGNED MESSAGE-
 
 Moin,
 
 On Sun, Jun 12, 2005 at 12:12:22AM +0200, David Landgren wrote:
  Executive summary: it looks like 5.8.7 is doing a better job than blead
  at the moment. I haven't looked closely at what I chose in the
  different  builds but I doubt anything is radically different: I tend
  to build  perls the same way (notably: using perl's malloc).
  If anyone has suggestions on how to tighten up the test environment I'm
  all ears.
 
 5.8.7 vs 5.9.3 is too broad.  If its just Nick's performance enhancements
 you want to test try the latest bleadperl vs the one just before Nick
 started playing around.  Then we can see the performance of Nick's
 patches, not the whole lump of 5.8.7 vs 5.9.3.
 
 Semi-stupid question. How do I get different patch-levels from blead? I
 know how to get the latest, but have no idea how  to checkout a certain
 patch number, or even how to find out which one I would need.

Just grab the 5.9.2 release from cpan. that should be a reasonable comparison.

yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: value stored in $1

2005-06-10 Thread demerphq

On 6/10/05, Nicholas Clark [EMAIL PROTECTED] wrote:
I believe that $1 etc are stored as byte offsets into
 this (copied) string.

This is correct. The OPEN/CLOSE handlers in regexec.c regmatch()
update the values of the @- and @+ arrays.

Yves


-- 
perl -Mre=debug -e /just|another|perl|hacker/

Making Pathtools compile properly on Win32 5.6.x, experiencing problems with tainting

2005-06-03 Thread demerphq

Hi,

Ive been trying to help Ken get the latest version of Pathtools
(Cwd.xs) to work properly on Win32 5.6.x. Overall this hasnt been much
of a problem, except that for the life of me I cant get Cwd.xs to
return tainted values.

The following code is an example of an XS routine that works fine in
5.8.x but not in 5.6 on win32. Any ideas would be really welcome. I
looked in the AS source bundle for 638 and it doesnt have any XS for
Cwd so at this point i have no idea what to do.

PS, as long as this is broken Pathtools cant be built on 5.6.x Win32,
which means that Module::Build can't be built on Win32 (as it depends
on having a later version of F::S available) which in turn means lots
of things cant be built on 5.6.x Win32...

Should I just make it ignore these tests on this OS/and Perl version?

Cheers,
Yves

void
abs_path(pathsv=Nullsv)
SV *pathsv
PROTOTYPE: DISABLE
PPCODE:
{
dXSTARG;
char *path;
char buf[MAXPATHLEN];

path = pathsv ? SvPV_nolen(pathsv) : (char *).;

if (bsd_realpath(path, buf)) {
sv_setpvn(TARG, buf, strlen(buf));
SvPOK_only(TARG);
SvTAINTED_on(TARG);
}
else
sv_setsv(TARG, PL_sv_undef);

XSprePUSH; PUSHTARG;
#ifndef INCOMPLETE_TAINTS
SvTAINTED_on(TARG);
#endif
}





-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Making Pathtools compile properly on Win32 5.6.x, experiencing problems with tainting

2005-06-03 Thread demerphq

On 6/3/05, Ken Williams [EMAIL PROTECTED] pointed out:
 If I understand the code correctly, Win32 never actually uses this
 abs_path() function anyway (it uses the built-in _NT_cwd() for cwd-ish
 functions and the pure-perl fast_abs_path() for abs_path-ish
 functions), so the only reason to have XS at all is for the
 recently-added getdcwd() function.

Doh. Doh. Doh.

Good catch.

 If I'm correct about all this, maybe we should instead concentrate on
 getting all of Cwd.xs but the getdcwd() code stripped out during the
 build on Win32.

Agreed. And making the perl routines return tainted data.

 p.s. I couldn't actually figure out where _NT_cwd() is defined, it
 doesn't seem to be either in the PathTools distribution or in the core.
 When it's not defined, the code falls back to using Win32::GetCwd().

Yep, or failing that (?!?) to using cd, which i suppose would have a
minor advantage of returning tainted data :-)

yves
-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [PATCH] Quotes fixed, see also perl #36079

2005-06-02 Thread demerphq

 2. Fix this quoting style in all non-generated other pods

The generators also should no longer do this right?

yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Should while ( $fh ) and while ( $fh ) do the same thing?

2005-06-02 Thread demerphq

If you answered yes like I did then youre in for a surprise.

I got bitten by this today and before I perlbug it I just want to
check if anybody thinks the differing behaviour of  $fh and  $fh 
is correct (first has no spaces inside the angle brackets second has
them before and after the $fh). It certainly wasnt what I expected.

I tried on 5.6.1 and 5.8.5 and both exhibit the same issue.

Yves



-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: Recent changes in blead-perl breaks Devel-Size-0.59 and Algorithm-Permute-0.06

2005-06-01 Thread demerphq

On 6/1/05, Nicholas Clark [EMAIL PROTECTED] wrote:
 It would be interesting if someone found some good way of benchmarking perl,
 and compared current blead with released 5.9.2

Is perlbench not the right way? What does good imply for you?

Also shouldn't Devel::Size count the memory allocated to regexps and
also to weakrefs?

yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [PATCH] ByteLoader.xs cleanup

On 5/31/05, Rafael Garcia-Suarez [EMAIL PROTECTED] wrote:
 Andy Lester wrote:
  - SvCUR_set (data-datasv, 0);
 }
  +  SvCUR_set(data-datasv, len);
 
 This seems suspicious to me.

Look at the logic:

   if (len) {
memmove (start, start + data-next_out, len + 1);
-   SvCUR_set (data-datasv, len);
   } else {
*start = '\0';  /* Avoid call to memmove. */
-   SvCUR_set (data-datasv, 0);
   }
+  SvCUR_set(data-datasv, len);


if len is true SvCUR_set to len,
if len is 0 SvCUR_Set to 0.

thus,

SvCUR_set to len always does the same thing.

Yves


-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #36050] weakrefs could use ptr_tables to avoid the current linear implementation

On 31 May 2005 14:11:03 -, via RT Nicholas Clark
[EMAIL PROTECTED] wrote:
 # New Ticket Created by  Nicholas Clark
 # Please include the string:  [perl #36050]
 # in the subject line of all future correspondence about this issue.
 # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36050 
 
 
 
 This is a bug report for perl from [EMAIL PROTECTED],
 generated with the help of perlbug 1.35 running under perl v5.9.3.
 
 
 -
 [Please enter your report here]
 
 Currently the weakref implementation uses AVs and a linear search.
 It should be possible to re-implenent it to use the ptr_table hashes used
 by the ithreads cloning code. This should make the backref lookup O(1)
 rather than O(n)

If this is changed please make it possible ensure it is still possible
to inspect and work with the content. For instance the latest version
of Data::Dump::Streamer uses the following code to ensure that weakref
structures are correctly dumped:

MAGIC *mg = NULL;   
if( SvMAGICAL(sv)   
 (mg = mg_find(sv, PERL_MAGIC_backref) )  
){  
AV *av = (AV *)mg-mg_obj;  
RETVAL += av_len(av)+1; 
}   

Incidentally with code like this in Storable the issue discussed some
time back of what items need to be tracked for possible multiple
instances becomes quite simple. If the SvREFCOUNT+WeakRefCount1 then
the item must be tracked as it potentially occurs twice in the data
structure being dumped.

yves
ps: if anybody on p5p cares, DDS can dump closures properly now. (with
a few modest caveats).
-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #36050] weakrefs could use ptr_tables to avoid the current linear implementation

On 5/31/05, Nicholas Clark [EMAIL PROTECTED] wrote:
 On Tue, May 31, 2005 at 04:20:40PM +0200, demerphq wrote:
  On 31 May 2005 14:11:03 -, via RT Nicholas Clark
  [EMAIL PROTECTED] wrote:
   # New Ticket Created by  Nicholas Clark
   # Please include the string:  [perl #36050]
   # in the subject line of all future correspondence about this issue.
   # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36050 
  
  
  
   This is a bug report for perl from [EMAIL PROTECTED],
   generated with the help of perlbug 1.35 running under perl v5.9.3.
  
  
   -
   [Please enter your report here]
  
   Currently the weakref implementation uses AVs and a linear search.
   It should be possible to re-implenent it to use the ptr_table hashes used
   by the ithreads cloning code. This should make the backref lookup O(1)
   rather than O(n)
 
  If this is changed please make it possible ensure it is still possible
  to inspect and work with the content. For instance the latest version
 
 Sure. Also, I can't see this sort of change being suitable for maint, given
 that there's more than one module on CPAN that expects the current weak
 reference implementation.

Cool, i look forward to yet another internals special case :-)

Cheers,
yves


-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: old value of $1

On 5/31/05, David Nicol [EMAIL PROTECTED] wrote:
 and that doc text from perlre (5.8.6) has a grammar bug in it as well
 (put 'it' after 'makes').
 
YS Yes.
 
  it shows how few people have actually read that note. :)
 
  uri
 
 I actually thought it was by design that way, as part of the
 internationalization
 of perl initiative, to in bring the word orders of the world, the
 documentation, into.
 
 With including unicode support along, unigrammar.

Yoda does tech-writing now or what?

:-)
-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #36020] Simple regexp causes segfault

2005-05-29 Thread demerphq

 The following two lines cause a segfault:
 
 
 $str = { . (0x00,  x 25600) . 0x00};
 $str =~ /^(0|0x00+|\{(0x00,\s*)*0x00\})$/;

Here is the debug output of a reduced version of this (x 2 in the code
above). If you remove the \s* and use a space instead the problem goes
away. From the output of the debug it looks like the eval stack isnt
getting popped. Every time the \s* pattern matches it pushes a new
eval scope that never gets freed which apparently leads to the the
segfault.

D:\dev\utilperl -Mre=debug C:\TMP\segfault.pl
Freeing REx: `,'
Compiling REx `^(0|0x00+|\{(0x00,\s*)*0x00\})$'
size 35 Got 284 bytes for offset annotations.
first at 2
   1: BOL(2)
   2: OPEN1(4)
   4:   BRANCH(7)
   5: EXACT 0(32)
   7:   BRANCH(13)
   8: EXACT 0x0(10)
  10: PLUS(32)
  11:   EXACT 0(0)
  13:   BRANCH(32)
  14: EXACT {(16)
  16: CURLYX[0] {0,32767}(28)
  18:   OPEN2(20)
  20: EXACT 0x00,(23)
  23: STAR(25)
  24:   SPACE(0)
  25:   CLOSE2(27)
  27:   WHILEM[1/1](0)
  28: NOTHING(29)
  29: EXACT 0x00}(32)
  32: CLOSE1(34)
  34: EOL(35)
  35: END(0)
floating `'$ at 1..2147483647 (checking floating) anchored(BOL) minlen 1
Offsets: [35]
1[1] 2[1] 0[0] 2[1] 3[1] 0[0] 4[1] 5[3] 0[0] 9[1] 8[1] 0[0]
10[1] 11[2] 0[0] 23[1] 0[0] 13[1] 0[0] 14[5] 0[0] 0[
0] 21[1] 19[2] 22[1] 0[0] 23[0] 23[0] 24[6] 0[0] 0[0] 30[1] 0[0] 31[1] 32[0]
Guessing start of match, REx `^(0|0x00+|\{(0x00,\s*)*0x00\})$' against
`{0x00, 0x00, 0x00}'...
Found floating substr `'$ at offset 18...
Guessed: match at offset 0
Matching REx `^(0|0x00+|\{(0x00,\s*)*0x00\})$' against `{0x00, 0x00, 0x00}'
  Setting an EVAL scope, savestack=3
   0  {0x00, 0x00,|  1:  BOL
   0  {0x00, 0x00,|  2:  OPEN1
   0  {0x00, 0x00,|  4:  BRANCH
  Setting an EVAL scope, savestack=13
   0  {0x00, 0x00,|  5:EXACT 0
  failed...
   0  {0x00, 0x00,|  8:EXACT 0x0
  failed...
   0  {0x00, 0x00,| 14:EXACT {
   1 { 0x00, 0x00,| 16:CURLYX[0] {0,32767}
   1 { 0x00, 0x00,| 27:  WHILEM[1/1]
0 out of 0..32767  cc=140fc1c
  Setting an EVAL scope, savestack=23
   1 { 0x00, 0x00,| 18:OPEN2
   1 { 0x00, 0x00,| 20:EXACT 0x00,
   6 0x00,  0x00, | 23:STAR
   SPACE can match 1 times out of 2147483647...
  Setting an EVAL scope, savestack=23
   7 x00,  0x00, 0| 25:  CLOSE2
   7 x00,  0x00, 0| 27:  WHILEM[1/1]
1 out of 0..32767  cc=140fc1c
  Setting an EVAL scope, savestack=37
   7 x00,  0x00, 0| 18:OPEN2
   7 x00,  0x00, 0| 20:EXACT 0x00,
  12  0x00,  0x00}| 23:STAR
   SPACE can match 1 times out of 2147483647...
  Setting an EVAL scope, savestack=37
  13  0x00,  0x00}| 25:  CLOSE2
  13  0x00,  0x00}| 27:  WHILEM[1/1]
2 out of 0..32767  cc=140fc1c
  Setting an EVAL scope, savestack=51
  13  0x00,  0x00}| 18:OPEN2
  13  0x00,  0x00}| 20:EXACT 0x00,
  failed...
 restoring \1 to -1(0)..-1
 restoring \2 to 7(7)..13
failed, try continuation...
  13  0x00,  0x00}| 28:NOTHING
  13  0x00,  0x00}| 29:EXACT 0x00}
  18  0x00, 0x00} | 32:CLOSE1
  18  0x00, 0x00} | 34:EOL
  18  0x00, 0x00} | 35:END
Match successful!
Freeing REx: `^(0|0x00+|\\{(0x00,\\s*)*0x00\\})$'


-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #35982] use of backslashed '-' following '$' within character class causes 'Use of uninitialized value in concatenation (.) or string' error under 'use warnings' pragma

On 26 May 2005 08:13:03 -, via RT fdhsbgeryft lkjhuibfmfsi
[EMAIL PROTECTED] wrote:
 # New Ticket Created by  fdhsbgeryft lkjhuibfmfsi
 # Please include the string:  [perl #35982]
 # in the subject line of all future correspondence about this issue.
 # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35982 
 
 
 This is a bug report for perl from
 [EMAIL PROTECTED],
 generated with the help of perlbug 1.35 running under
 perl v5.8.4.
 
 
 -
 [Please enter your report here]
 #case 1
 #no error if this is commented
 #-
 use warnings 'substr';
 #-
 
 #case 2
 #(different) error if this is uncommented
 #-
 #   use warnings
 #   no warnings 'substr'
 #
 my $path=random string;
 #'Use of uninitialized value in concatenation (.) or
 string' with $ sign
 $path=~/[CHARS$\-CHARS]/;
 #no error without it
 $path=~/[CHARS\-CHARS]/;
 
 the CHARS you choose, or the string you operate on,
 don't seem to matter.
 I have only been able to produce this error with a '$'
 sign within the character class just before a
 backslashed '-'
 However, I fear that this bug includes more than this
 special case
 The error seems to be within the 'substr' section of
 the 'use warnings' pragma, as explicitly enabling it
 causes the error to appear(see case 1)
 But oddly, the error changes(turns into 'Invalid []
 range S-C in regex;'), but does not dissapear when
 warnings are all enabled except 'substr', which is
 explicitely disabled(see case 2)
 I hope I have been specific enough for you to identify
 this bug with relative ease, I have never submitted a
 bug before and I'm not exactly a professional
 programmer
 This bug had caused me a few hours of pointless
 debugging because I hadn't expected to find a bug
 within a core library, guess you learn something new
 every day :).

Well alas its not a bug. :-)

$\ is a valid variable name (its the output record seperator defined
in perlvar).

Whats happening is that the $\ is being parsed as the variable $\
whose default value is undefined. You need to escape the dollar sign
itself to prevent this.

 On a side note, it was quite the adventure to get this
 bug report sent, since perlbug does not work on my
 win32 install. Therefore, forgive me in advance for
 the  wrong sending format and the advertisment tail
 yahoo slaps on the end of my mail even though it says
 not to add onto the bug report.
 peace out

I know the feeling. Switch to gmail. :-)



-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #35982] use of backslashed '-' following '$' within character class causes 'Use of uninitialized value in concatenation (.) or string' error under 'use warnings' pragma

On 5/26/05, demerphq [EMAIL PROTECTED] wrote:
 On 26 May 2005 08:13:03 -, via RT fdhsbgeryft lkjhuibfmfsi
 [EMAIL PROTECTED] wrote:
...
  I hope I have been specific enough for you to identify
  this bug with relative ease, I have never submitted a
  bug before and I'm not exactly a professional
  programmer

Try www.perlmonks.org next time you suspect you've found a bug. The
folks there can help you sort out if its a bug in your code or in the
core. :-) Plus they generally speaking are very helpful folks.


-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #35982] use of backslashed '-' following '$' within character class causes 'Use of uninitialized value in concatenation (.) or string' error under 'use warnings' pragma

On 5/26/05, Michael G Schwern [EMAIL PROTECTED] wrote:
 On Thu, May 26, 2005 at 02:59:04PM +0200, demerphq wrote:
  Try www.perlmonks.org next time you suspect you've found a bug. The
  folks there can help you sort out if its a bug in your code or in the
  core. :-) Plus they generally speaking are very helpful folks.
 
 No, please send suspected bugs here.  I'd rather we get a few non-bugs
 then lose real ones to misdiagnosis on Perlmonks.

You think that happens very much? Id be rather surprised if you can
show even a single example, and id be even more surprised if it were a
recent one. Considering the number of active p5p'ers that visit PM on
a regular basis I should be very surprised if it did. On the contrary
I suspect that PM has been the initial discussion forum for many a bug
finally reported through to RT.

Anyway, the fact is that this level of question would have been
resolved in a few seconds in the CB, so I dont think my advice was
that off.

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #35982] use of backslashed '-' following '$' within character class causes 'Use of uninitialized value in concatenation (.) or string' error under 'use warnings' pragma

On 5/26/05, Yitzchak Scott-Thoennes [EMAIL PROTECTED] wrote:
 On Thu, May 26, 2005 at 10:39:48PM +0200, demerphq wrote:
  On 5/26/05, Michael G Schwern [EMAIL PROTECTED] wrote:
   On Thu, May 26, 2005 at 02:59:04PM +0200, demerphq wrote:
Try www.perlmonks.org next time you suspect you've found a bug. The
folks there can help you sort out if its a bug in your code or in the
core. :-) Plus they generally speaking are very helpful folks.
  
   No, please send suspected bugs here.  I'd rather we get a few non-bugs
   then lose real ones to misdiagnosis on Perlmonks.
 
  You think that happens very much? Id be rather surprised if you can
  show even a single example, and id be even more surprised if it were a
  recent one. Considering the number of active p5p'ers that visit PM on
  a regular basis I should be very surprised if it did. On the contrary
  I suspect that PM has been the initial discussion forum for many a bug
  finally reported through to RT.
 
  Anyway, the fact is that this level of question would have been
  resolved in a few seconds in the CB, so I dont think my advice was
  that off.
 
 Certainly any amount of looking into a potential bug the reporter does
 is appreciated; but let's not give the impression that consulting
 anything other than the documentation is mandatory.
 

A little quote of the original post:

  I have never submitted a bug before and I'm not exactly a
professional programmer

My advice was to a specific newcomer not intended to be general advice. 

Although frankly recommending that newcomers visit forums like
perlmonks before they report bugs IN CORE probably is good advice. The
truth is its quite unlikely that a total newbie is going to find a bug
in Perl itself. The odds are almost completely in favour of them
misunderstanding some aspect of how Perl is supposed to work in the
first place.

Being told as much, and where to go for help can only assist them as
they wont have to (using the OP's exact words) caused me a few hours
of pointless debugging because I hadn't expected to find a bug within
a core library.

Well he was right not to expect to find a bug in the core before he
knew a lot more Perl than he does. Without comprehensive knowledge of
the documentation and a chunk of internals figuring out something like
this is hard. Asking a bunch of folks like those at PM is easy and
much less frustrating.

cheers,
yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

Re: [perl #35982] use of backslashed '-' following '$' within character class causes 'Use of uninitialized value in concatenation (.) or string' error under 'use warnings' pragma