[PATCH fresh_perl.t] Being more careful about newlines
Removing the auto-newline appending in fresh_perl_is() exposed some newline
sloppiness in t/run/fresh_perl.t.
* When switches were stripped from test code a blank line was left.
This confused attempts by fresh_perl to display the first line of the
program as a default name.
* Some programs have no expected output, we only care that they don't
segfault. These would warn as the expected output was undef.
* Tests with no switches generated undef warnings.
* Separating the test into the program and the expected part stripped
the trailing newline off the program causing a test to fail which
ended in a here-doc separator.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Reality is that which, when you stop believing in it, doesn't go away.
-- Phillip K. Dick
--- run/fresh_perl.t2005/07/22 19:39:34 1.1
+++ run/fresh_perl.t2005/07/22 19:47:35
@@ -35,11 +35,13 @@
my($raw_prog, $name) = @$prog;
my $switch;
-if ($raw_prog =~ s/^\s*(-\w.*)//){
+if ($raw_prog =~ s/^\s*(-\w.*)\n//){
$switch = $1;
}
my($prog,$expected) = split(/\nEXPECT\n/, $raw_prog);
+$prog .= "\n";
+$expected = '' unless defined $expected;
if ($prog =~ /^\# SKIP: (.+)/m) {
if (eval $1) {
@@ -50,7 +52,7 @@
$expected =~ s/\n+$//;
-fresh_perl_is($prog, $expected, { switches => [$switch] }, $name);
+fresh_perl_is($prog, $expected, { switches => [$switch || ''] }, $name);
}
__END__
@@ -383,7 +385,7 @@
-w
sub testme { my $a = "test"; { local $a = "new test"; print $a }}
EXPECT
-Can't localize lexical variable $a at - line 2.
+Can't localize lexical variable $a at - line 1.
package X;
sub ascalar { my $r; bless \$r }
@@ -510,7 +512,7 @@
if ($x == 0) { print "" } else { print $x }
}
EXPECT
-Use of uninitialized value $x in numeric eq (==) at - line 4.
+Use of uninitialized value $x in numeric eq (==) at - line 3.
$x = sub {};
foo();
@@ -651,8 +653,9 @@
close STDERR; die;
EXPECT
+# core dump in 2716.007
-w
-"x" =~ /(\G?x)?/; # core dump in 2716.007
+"x" =~ /(\G?x)?/;
# Bug 20010515.004
my @h = 1 .. 10;
Re: [perl #36622] y/// at end of file
On Thu, Jul 21, 2005 at 11:45:30AM -0700, Piotr Fusik wrote:
> Among perl golf players, it is widely known that perl doesn't like
> y/// at the very end of a file. So, we put an extra space or newline
> just to make perl happy. Fortunately trailing whitespace doesn't
> count to the score. :-)
First let me say how bonkers I went to get either vim or emacs to stop
putting a newline on the end of a file. For those emacs out there
the variable is require-final-newline, set it to nil. Unfortunately all
sorts of modes seem to think they know better and set it to true so even if
you shut it off in your confir you often have to manually set it off.
> If you forget to add something after y///, the error messages are very
> misleading. For example, this program:
>
> #!/usr/bin/perl -0
> INIT{$A{$a}=1while$a=pop}1while"@A{/[a-z]+/ig}"=~/\B/&&y/B-ZA-Gb-za/B-ZA
> b-za/
>
> when syntax-checked by perl -c gives the following error message:
> Unrecognized character \x81 at deroter.pl line 2.
>
> (do you see any \x81 here?)
Bleadperl appears to have this fixed. A test is attached. Ironically
the fresh_perl test function would always append a newline to the code
being tested. I've whacked that out, it was a hold over from the original
code in t/run/kill_perl.t.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Ahh email, my old friend. Do you know that revenge is a dish that is best
served cold? And it is very cold on the Internet!
--- t/test.pl 2005/07/22 18:43:05 1.1
+++ t/test.pl 2005/07/22 18:43:09
@@ -579,7 +579,7 @@
{if (-e _ and -f _)}
}
-print TEST $prog, "\n";
+print TEST $prog;
close TEST or die "Cannot close $tmpfile: $!";
my $results = runperl(%$runperl_args);
--- t/op/tr.t 2005/07/22 18:37:29 1.1
+++ t/op/tr.t 2005/07/22 18:42:16
@@ -6,7 +6,7 @@
require './test.pl';
}
-plan tests => 99;
+plan tests => 100;
my $Is_EBCDIC = (ord('i') == 0x89 & ord('J') == 0xd1);
@@ -383,3 +383,7 @@
$x = \"foo";
is( $x =~ tr/A/A/, 2, 'non-modifying tr/// on a scalar ref' );
is( ref $x, 'SCALAR', "doesn't stringify its argument" );
+
+# rt.perl.org 36622. Perl didn't like a y/// at end of file. No trailing
+# newline allowed.
+fresh_perl_is(q[$_ = "foo"; y/A-Z/a-z/], '');
[perl #36621] /\pL/ breaks -0
> [EMAIL PROTECTED] - Thu Jul 21 10:31:16 2005]: > > While playing perlgolf I noticed a strange thing: > > perl -0e "print while $_=pop||<>,/\pL/" foo > > This first prints "foo" (that's okay). But then if you type "bar", > it immediately outputs "bar". It shouldn't do so, because <> should > read until "\0" (notice the -0 option), not until "\n". > Just try /\w/ instead of /\pL/. Confirmed a bug in 5.8.0. Confirmed fixed in 5.8.6 and bleadperl. Thank you for your bug reports but please try a newer verison of Perl before reporting bugs.
[PATCH ext/POSIX/POSIX.pod] POSIX::SigAction
The documentation said the first argument of the constructor needs to be the fully qualified name, but the example uses a reference to the handler, not the name. And since using a reference seems to work as well, this patch documents it. Abigail --- ext/POSIX/POSIX.pod.origSat Feb 5 17:56:13 2005 +++ ext/POSIX/POSIX.pod Sat Jul 23 02:35:11 2005 @@ -1635,13 +1635,14 @@ Creates a new C object which corresponds to the C C. This object will be destroyed automatically when it is -no longer needed. The first parameter is the fully-qualified name of a sub -which is a signal-handler. The second parameter is a C -object, it defaults to the empty set. The third parameter contains the -C, it defaults to 0. +no longer needed. The first parameter is either the fully-qualified name +of a sub which is a signal-handler, or a reference to it. The second parameter +is a C object, it defaults to the empty set. The third +parameter contains the C, it defaults to 0. $sigset = POSIX::SigSet->new(SIGINT, SIGQUIT); - $sigaction = POSIX::SigAction->new( \&main::handler, $sigset, &POSIX::SA_NOCLDSTOP ); + $sigaction = POSIX::SigAction->new( \&main::handler, +$sigset, &POSIX::SA_NOCLDSTOP ); This C object is intended for use with the C function. pgpaPPq94VlxU.pgp Description: PGP signature
[PATCH ext/POSIX/POSIX.xs] Whitespace
Some lines were outdented by one space. This patch fixes it. Abigail --- ext/POSIX/POSIX.xs.orig Tue Aug 10 09:18:41 2004 +++ ext/POSIX/POSIX.xs Sat Jul 23 02:29:51 2005 @@ -1373,8 +1373,8 @@ * essentially meaningless anyway. */ RETVAL = sigaction(sig, & act, (struct sigaction *)0); - if(RETVAL == -1) - XSRETURN_UNDEF; +if(RETVAL == -1) +XSRETURN_UNDEF; } LEAVE; pgpYdrSqROwiY.pgp Description: PGP signature
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
On Thu, 21 Jul 2005 00:14:51 -0700, Michael G Schwern wrote:
>
> Its gotta be something about _default_inc(). Nothing looks wrong from
> here. My only guess is that local $ENV{PERL5LIB} is ineffective. That
> would account for the alternation.
It's not just the local scoping. There is something
seriously unexpected with environment variables, perl
and cygwin.
- th4.pl
#!/usr/bin/perl
use strict;
use warnings;
$ENV{SHOULD_NEVER_BE_SEEN} = "hello world";
delete($ENV{SHOULD_NEVER_BE_SEEN});
system("printenv | grep SHOULD_NEVER_BE_SEEN");
On UNIX systems that script properly prints nothing. Not so
on my cygwin (on top of XP) system:
cygwin% perl ~/th4.pl
SHOULD_NEVER_BE_SEEN=hello world
It seems to imply that the results of unsetenv(3) are not
persistent across an exec(2).
Root cause aside, you nailed it with your suggestion.
>
>
> And then try changing "local $ENV{PERL5LIB}" to "local $ENV{PERL5LIB} = ''".
Explicitly setting $ENV{PERL5LIB} to '' before calling `perl ...`
in _default_inc() fixed the problem for me.
Scott
Re: [perl #36634] Taking last element of an empty slice by putting it in scalar context. 5.8.2
On Fri, Jul 22, 2005 at 07:04:52PM -0400, Joshua Juran wrote: > in v5.8.1-RC3 built for darwin-thread-multi-2level (with 1 registered > patch), and > > a=7 > b=UNDEFINED > b=UNDEFINED > b=UNDEFINED > b=UNDEFINED > > in v5.8.7 built for i386-linux-thread-multi. In other words, it > appears to have been fixed. It seems to have been fixed between 5.8.5 and 5.8.6. Which I guess is fortunate, because it would mean that upgrading to OS X 10.4 will solve the problem with "/usr/bin/perl", if you're not in a position to install your own perl in /usr/local Nicholas Clark
Re: [perl #36634] Taking last element of an empty slice by putting it in scalar context. 5.8.2
On Jul 22, 2005, at 11:57 AM, [EMAIL PROTECTED] (via RT) wrote: # New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #36634] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36634 > This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.34 running under perl v5.8.1. - I have problems taking the last element of an empty slice by putting the slice in an integer context: my @a=(11,22,33); my $a = @a[()]; Not only is the result sensitive to type of block it's in, but in some situations it can have bizarre side effects that suggest a bug to me. I've seen the problem as late as 5.8.2, the most recent version I use. See below. I get a=7 b=UNDEFINED b=1 b=44 b=55 in v5.8.1-RC3 built for darwin-thread-multi-2level (with 1 registered patch), and a=7 b=UNDEFINED b=UNDEFINED b=UNDEFINED b=UNDEFINED in v5.8.7 built for i386-linux-thread-multi. In other words, it appears to have been fixed. Josh
Re: [perl #36616] bug or feature? foreach (sort @array) {y/a-z/A-Z/;} # @array modified!
Shiping Zhang wrote:
Shiping Zhang wrote:
The described behavior changes whether "sort @arr" goes directly in
'for' or you assign it first to an array variable.
@arr = ('one', 'two', 'three', 'four');
y/a-z/A-Z/ foreach sort @arr;
print "\na: @arr\n"
prints "a: ONE TWO THREE FOUR" and
@arr = ('one', 'two', 'three', 'four');
@s = sort @arr;
y/a-z/A-Z/ foreach @s;
print "\na: @arr\n"
prints "a: one two three four". This has to do with copy-on-assign?
>>That seems like a (subtle) feature. Otherwise, it is a very old bug:
>>the same behavior with 5.8.6, 5.6.1, and 5.005_03.
>>
If it's a feature, then it's not documented at all. Larry's Perl books do not
mention it, the sort man page from perldoc does not mention it, and the manual
page from www.perl.org does not mention it. And this feature is against
intuition and I would consider it more a bug than a feature (what use it has?).
I think other people wouldn't expect @array to be changed in the code above.
(New Perl programers may be surprised to know that foreach works on an alias,
but it's well documented (and warned) and such feature is at least useful under
some circumstances.) Conceptually, sort should return a true copy (sorted of
course) of its arguement and I think it is how people would understand it.
(How sort is implemented is a different matter. I guess sort is working on a
list of pointers to the elements of the original list and, in foreach context,
just returns a pointer to the list of pointers instead of making an anonymous
copy of the sort list.)
it's documented under perldoc perltrap as a discontinuance between perl4
and perl5 so it's been around for quite a while.
it's also documented under perldoc perlsyn:
"If any element of LIST is an lvalue, you can modify it by modifying VAR
inside the loop. Conversely, if any element of LIST is NOT an lvalue,
any attempt to modify that element will fail. In other words, the
"foreach" loop index variable is an implicit alias for each item in the
list that you're looping over."
it's ALSO mentioned in perlfaq4: perldoc -q "strip blank space"
> By "not documented', I was refering to what is supposed to be returned by
> sort. To a Perl programer, should what's returned by sort be considered a
> 'true' copy of a original list (albeit sorted) which can be worked on without
> affecting the original list under any circumstances? As far as I see it, in
> the code of 'foreach (sort @array){}', foreach is stepping through a sorted
> copy returned by sort at the time sort has already finished and @array
> forgotten. So I wouldn't expect @array to be changed. The current behavior is
> a bad behavior to say the least. I would be very surprised if Larry would
> design the code to behave in such a way. ;-)
I'm not so sure about that..
sort @a is just @a sorted. if I wanted a sorted copy of @a I'd do it implicitly:
@b = sort @a , as in foreach (my @b = sort @a) {}. As someone else pointed out,
sort is similar to grep in this respect.
When I first looked at this question, I thoroughly discounted sort as being
'part of the problem', and looked straight to the aliasing behaviour of foreach,
since you're merely receiving @a back, just sorted first.
if I wanted a copy of @a I'd ask for it. Perhaps this needs to be documented
better in the above three perldocs but I don't see it as a bug whatsoever. It
(foreach) is doing exactly what I'd have expected of it, myself, sorted/grepped
or not...
[perl #36634] Taking last element of an empty slice by putting it in scalar context. 5.8.2
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #36634]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36634 >
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.34 running under perl v5.8.1.
-
I have problems taking the last element of an empty slice by putting the slice
in an integer context:
my @a=(11,22,33);
my $a = @a[()];
Not only is the result sensitive to type of block it's in,
but in some situations it can have bizarre side effects that
suggest a bug to me. I've seen the problem as late as 5.8.2, the
most recent version I use. See below.
John
$ perl -v
This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level
-A demonstration script
#! /usr/bin/perl
# inconsistency bug when you evaluate the slice @array[()] in a scalar context
use strict;
use warnings;
my @a = (6,7,8);
my @c = (44);
#Normal: non-empty slice:
my $a = @a[(2,1)];
$a = "UNDEFINED" unless defined $a;
print "a=$a\n";
#No loop:
my $b = @a[()];
$b = "UNDEFINED" unless defined $b;
print "b=$b\n";
foreach (@c) {
my $b = @a[()];
$b = "UNDEFINED" unless defined $b;
print "b=$b\n";
};
map {
my $b = @a[()];
$b = "UNDEFINED" unless defined $b;
print "b=$b\n";
} @c;
# Assigns $_ within the map statement
map {
$_ = 55;
my $b = @a[()];
$b = "UNDEFINED" unless defined $b;
print "b=$b\n";
} @c;
__END__
-
---
Flags:
category=core
severity=medium
---
Site configuration information for perl v5.8.1:
Configured by root at Fri Sep 12 19:46:46 PDT 2003.
Summary of my perl5 (revision 5.0 version 8 subversion 1 RC3) configuration:
Platform:
osname=darwin, osvers=7.0, archname=darwin-thread-multi-2level
uname='darwin hampsten 7.0 darwin kernel version 6.0: fri jul 25 16:58:41
pdt 2003; root:xnu-344.frankd.rootsxnu-344.frankd~objrelease_ppc power
macintosh powerpc '
config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe
-Dldflags=-Dman3ext=3pm -Duseithreads -Duseshrplib'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-g -pipe -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp
-fno-strict-aliasing -I/usr/local/include',
optimize='-Os',
cppflags='-no-cpp-precomp -g -pipe -pipe -fno-common -DPERL_DARWIN
-no-cpp-precomp -fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build 1495)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags ='-L/usr/local/lib'
libpth=/usr/local/lib /usr/lib
libs=-ldbm -ldl -lm -lc
perllibs=-ldl -lm -lc
libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-bundle -undefined dynamic_lookup
-L/usr/local/lib'
Locally applied patches:
RC3
---
@INC for perl v5.8.1:
/sw/lib/perl5
/sw/lib/perl5/darwin
/System/Library/Perl/5.8.1/darwin-thread-multi-2level
/System/Library/Perl/5.8.1
/Library/Perl/5.8.1/darwin-thread-multi-2level
/Library/Perl/5.8.1
/Library/Perl
/Network/Library/Perl/5.8.1/darwin-thread-multi-2level
/Network/Library/Perl/5.8.1
/Network/Library/Perl
.
---
Environment for perl v5.8.1:
DYLD_LIBRARY_PATH (unset)
HOME=/Users/cornell
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/Users/cornell/bin:/usr/local/bin:/usr/X11R6/bin
PERL5LIB=/sw/lib/perl5:/sw/lib/perl5/darwin
PERL_BADLANG (unset)
SHELL=/bin/bash
Smoke [5.9.3] 25210 FAIL(c) openbsd 3.7 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25210
mccoy.peters.homeunix.org: Intel Pentium III ("GenuineIntel" 686-class, 512KB
L2 cache) (548 MHz) (i386/1 cpu)
onopenbsd - 3.7
using cc version 3.3.5 (propolice)
smoketime 10 hours 14 minutes (average 38 minutes 23 seconds)
Summary: FAIL(c)
O = OK F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during: - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep
25210 Configuration (common) none
--- -
O O O O
O O O O -Duse64bitint
c - c - -Duselongdouble
c - c - -Dusemorebits
O O O O -Duseithreads
O O O O -Duseithreads -Duse64bitint
c - c - -Duseithreads -Duselongdouble
c - c - -Duseithreads -Dusemorebits
| | | +- PERLIO = perlio -DDEBUGGING
| | +--- PERLIO = stdio -DDEBUGGING
| +- PERLIO = perlio
+--- PERLIO = stdio
Compiler messages(gcc):
/tmp//ccE20355.o(.text+0x3e): In function `main':
/tmp//ccA15388.o(.text+0x5d): In function `main':
/tmp//cca30098.o(.text+0xde): In function `main':
op.c: In function `Perl_newCONSTSUB':
op.c:4609: warning: null argument where non-null required (arg 1)
opmini.c: In function `Perl_newCONSTSUB':
opmini.c:4609: warning: null argument where non-null required (arg 1)
libperl.a(perlio.o)(.text+0x4ed8): In function `PerlIO_vsprintf':
opmini.o(.text+0x316): In function `Perl_allocmy':
libperl.a(toke.o)(.text+0x722c): In function `Perl_yylex':
libperl.a(op.o)(.text+0x316): In function `Perl_allocmy':
lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o)(.text+0x23e): In function
`XS_DynaLoader_dl_load_file':
util.o(.text+0x1f3): In function `savestr':
str.o(.text+0x5d): In function `str_2ptr':
byterun.c: In function `byterun':
byterun.c:893: warning: comparison is always false due to limited range of data
type
POSIX.xs: In function `XS_POSIX_sigaction':
POSIX.xs:1348: warning: comparison of distinct pointer types lacks a cast
POSIX.xs:1357: warning: assignment from incompatible pointer type
TSTENV = stdio ../libperl.a(perlio.o)(.text+0x4ed8): In function
`PerlIO_vsprintf':
../libperl.a(op.o)(.text+0x316): In function `Perl_allocmy':
../libperl.a(toke.o)(.text+0x722c): In function `Perl_yylex':
TSTENV = perlio ../libperl.a(perlio.o)(.text+0x4ed8): In function
`PerlIO_vsprintf':
/tmp//ccn26588.o(.text+0x3e): In function `main':
/tmp//ccq29660.o(.text+0x5d): In function `main':
/tmp//ccs26207.o(.text+0xde): In function `main':
libperl.a(perlio.o)(.text+0x4f98): In function `PerlIO_vsprintf':
libperl.a(toke.o)(.text+0x7f30): In function `Perl_yylex':
lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o)(.text+0x326): In function
`XS_DynaLoader_dl_load_file':
util.o(.text+0x2c3): In function `savestr':
str.o(.text+0x81): In function `str_2ptr':
TSTENV = stdio ../libperl.a(perlio.o)(.text+0x4f98): In function
`PerlIO_vsprintf':
../libperl.a(toke.o)(.text+0x7f30): In function `Perl_yylex':
TSTENV = perlio ../libperl.a(perlio.o)(.text+0x4f98): In function
`PerlIO_vsprintf':
/tmp//ccxw2388.o(.text+0x3e): In function `main':
/tmp//ccC10770.o(.text+0x5d): In function `main':
/tmp//ccJ21957.o(.text+0xde): In function `main':
mg.c: In function `Perl_magic_killbackrefs':
mg.c:2072: warning: long long unsigned int format, different type arg (arg 2)
libperl.a(perlio.o)(.text+0x52f4): In function `PerlIO_vsprintf':
libperl.a(toke.o)(.text+0x7330): In function `Perl_yylex':
TSTENV = stdio ../libperl.a(perlio.o)(.text+0x52f4): In function
`PerlIO_vsprintf':
../libperl.a(toke.o)(.text+0x7330): In function `Perl_yylex':
TSTENV = perlio ../libperl.a(perlio.o)(.text+0x52f4): In function
`PerlIO_vsprintf':
/tmp//ccd20812.o(.text+0x3e): In function `main':
/tmp//ccJA2387.o(.text+0x5d): In function `main':
/tmp//ccfP4477.o(.text+0xde): In function `main':
libperl.a(perlio.o)(.text+0x53b4): In function `PerlIO_vsprintf':
libperl.a(toke.o)(.text+0x8030): In function `Perl_yylex':
lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o)(.text+0x32a): In function
`XS_DynaLoader_dl_load_file':
TSTENV = stdio ../libperl.a(perlio.o)(.text+0x53b4): In function
`PerlIO_vsprintf':
../libperl.a(toke.o)(.text+0x8030): In function `Perl_yylex':
TSTENV = perlio ../libperl.a(perlio.o)(.text+0x53b4): In function
`PerlIO_vsprintf':
/tmp//ccN21643.o(.text+0x3e): In function `main':
/tmp//ccb23575.o(.text+0x5d): In function `main':
/tmp//ccsk5185.o(.text+0xde): In function `main':
/tmp//ccw29696.o(.text+0x3e): In function `main':
/tmp//ccH15022.o(.text+0x5d): In function `main':
/tmp//ccK24599.o(.text+0xde): In function `main':
/tmp//cch12075.o(.text+0x3e): In function `main':
/tmp//cci22034.o(.text+0x5d): In function `main':
/tmp//ccfT3766.o(.text+0xde): In function `main':
/tmp//ccp13830.o(.text+0x3e): In function `main':
/tmp//ccX31481.o(.text+0x5d): In function `main':
/tmp//cc
Re: Schizophrenic miniperl
Steve Hay wrote: > > The reason is that miniperl was built without ithreads (hence it is > correctly not in "Compile-time options"), but perl was built with > ithreads, so lib/Config_heavy.pl contains useithreads='define', which > miniperl uses too! Looking at the makefiles, I see that this can happen on windows, but not on unix where a libperl.a is built and used for linking miniperl and perl. So maybe you could compile a perl.c with a cpp symbol definition by tweaking the win32 makefile. But anyway this seems to me to be a lot of effort for not a big result.
Re: [perl #36616] bug or feature? foreach (sort @array) {y/a-z/A-Z/;} # @array modified!
> From [EMAIL PROTECTED] Thu Jul 21 20:36:57 2005
> Subject: Re: [perl #36616] bug or feature? foreach (sort @array)
> {y/a-z/A-Z/;} # @array modified!
> From: "Dave Mitchell via RT" <[EMAIL PROTECTED]>
> RT-Ticket: perl #36616
> Managed-by: RT 3.0.11 (http://www.bestpractical.com/rt/)
> RT-Originator: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Date: Thu, 21 Jul 2005 13:34:26 -0700
>
> [...]
>
> I don't think its a bug so much as undocumented behaviour. "fixing" it
> would involve doing a whole bunch of unneccessary copying in sort and
> grep.
I think you only need to do copying at the end of sort, just treat it
like foreach (my @anonymous = sort @old). After all, @new = sort @old is
what people usually do anyway (or at least such usage should be expected
to be common practice).
This communication is for use by the intended recipient and contains
information that may be privileged, confidential or copyrighted under
applicable law. If you are not the intended recipient, you are hereby
formally notified that any use, copying or distribution of this e-mail,
in whole or in part, is strictly prohibited. Please notify the sender
by return e-mail and delete this e-mail from your system. Unless
explicitly and conspicuously designated as "E-Contract Intended",
this e-mail does not constitute a contract offer, a contract amendment,
or an acceptance of a contract offer. This e-mail does not constitute
a consent to the use of sender's contact information for direct marketing
purposes or for transfers of data to third parties.
Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean
http://www.DuPont.com/corp/email_disclaimer.html
Re: [perl #36616] bug or feature? foreach (sort @array) {y/a-z/A-Z/;} # @array modified!
By "not documented', I was refering to what is supposed to be returned by sort.
To a Perl programer, should what's returned by sort be considered a 'true' copy
of a original list (albeit sorted) which can be worked on without affecting the
original list under any circumstances? As far as I see it, in the code
of 'foreach (sort @array){}', foreach is stepping through a sorted copy
returned by sort at the time sort has already finished and @array forgotten.
So I wouldn't expect @array to be changed. The current behavior is a bad
behavior to say the least. I would be very surprised if Larry would design
the code to behave in such a way. ;-)
> From [EMAIL PROTECTED] Fri Jul 22 09:07:30 2005
> Subject: Re: [perl #36616] bug or feature? foreach (sort @array)
> {y/a-z/A-Z/;} # @array modified!
> From: "Scott R. Godin via RT" <[EMAIL PROTECTED]>
> X-RT-Loop-Prevention: perl
> RT-Ticket: perl #36616
> Managed-by: RT 3.0.11 (http://www.bestpractical.com/rt/)
> RT-Originator: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> X-RT-Original-Encoding: utf-8
> Date: Fri, 22 Jul 2005 06:05:23 -0700
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
>
> Shiping Zhang wrote:
>
> >>The described behavior changes whether "sort @arr" goes directly in
> >>'for' or you assign it first to an array variable.
> >>
> >> @arr = ('one', 'two', 'three', 'four');
> >> y/a-z/A-Z/ foreach sort @arr;
> >> print "\na: @arr\n"
> >>
> >>prints "a: ONE TWO THREE FOUR" and
> >>
> >> @arr = ('one', 'two', 'three', 'four');
> >> @s = sort @arr;
> >> y/a-z/A-Z/ foreach @s;
> >> print "\na: @arr\n"
> >>
> >>prints "a: one two three four". This has to do with copy-on-assign?
> >>
> >>That seems like a (subtle) feature. Otherwise, it is a very old bug:
> >>the same behavior with 5.8.6, 5.6.1, and 5.005_03.
> >>
>
> > If it's a feature, then it's not documented at all. Larry's Perl books do
> > not
> > mention it, the sort man page from perldoc does not mention it, and the
> > manual
> > page from www.perl.org does not mention it. And this feature is against
> > intuition and I would consider it more a bug than a feature (what use it
> > has?).
> > I think other people wouldn't expect @array to be changed in the code above.
> > (New Perl programers may be surprised to know that foreach works on an
> > alias,
> > but it's well documented (and warned) and such feature is at least useful
> > under
> > some circumstances.) Conceptually, sort should return a true copy (sorted
> > of
> > course) of its arguement and I think it is how people would understand it.
> > (How sort is implemented is a different matter. I guess sort is working on a
> > list of pointers to the elements of the original list and, in foreach
> > context,
> > just returns a pointer to the list of pointers instead of making an
> > anonymous
> > copy of the sort list.)
> >
>
> it's documented under perldoc perltrap as a discontinuance between perl4
> and perl5 so it's been around for quite a while.
>
> it's also documented under perldoc perlsyn:
>
> "If any element of LIST is an lvalue, you can modify it by modifying VAR
> inside the loop. Conversely, if any element of LIST is NOT an lvalue,
> any attempt to modify that element will fail. In other words, the
> "foreach" loop index variable is an implicit alias for each item in the
> list that you're looping over."
>
> it's ALSO mentioned in perlfaq4: perldoc -q "strip blank space"
>
This communication is for use by the intended recipient and contains
information that may be privileged, confidential or copyrighted under
applicable law. If you are not the intended recipient, you are hereby
formally notified that any use, copying or distribution of this e-mail,
in whole or in part, is strictly prohibited. Please notify the sender
by return e-mail and delete this e-mail from your system. Unless
explicitly and conspicuously designated as "E-Contract Intended",
this e-mail does not constitute a contract offer, a contract amendment,
or an acceptance of a contract offer. This e-mail does not constitute
a consent to the use of sender's contact information for direct marketing
purposes or for transfers of data to third parties.
Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean
http://www.DuPont.com/corp/email_disclaimer.html
[perl #36630] open <&=fd does not work like fdopen
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #36630] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36630 > This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.35 running under perl v5.8.6. - [Please enter your report here] First of all, I am trying to translate a file descriptor into a perl filehandle (actually in an XS module), which turned out to be a surprisingly difficult problem (for me, at least :). This is what I came up with: open $fh, "+<&=$fd" or return undef; Anyways. When perl filehandles go out of scope, perl implicitly calls close(). This does not happen, however, with the <&= open mode, which is documented as: If you specify ’<&=X’, where "X" is a file descriptor number or a filehandle, then Perl will do an equivalent of C’s "fdopen" of that file descriptor (and not call dup(2)); this is more parsimonious of file descriptors. However, fdopen is documented (on GNU/Linux) as closing the fd when the associated stream is closed, and this seems to be the way fdopen usually acts on unix-like systems. This does not happen in perl in the above example, instead, the fd is leaked and never being closed. The workaround is easy: use "+<&$fd" and close the fd, at the cost of an extra dup (and in my case the cost of not being able to create a unique filehandle symbol as I don't know the fd). I think this is likely to be a doc bug, as changing existing behaviour of <&= is not likely to be useful. Could also be a perlio problem, though. In any case, documentation is not aligned with actual implementation. Greetings, Marc [Please do not change anything below this line] - --- Flags: category=core severity=low --- Site configuration information for perl v5.8.6: Configured by Marc Lehmann at Tue Nov 30 00:54:44 CET 2004. Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Platform: osname=linux, osvers=2.6.10-rc1, archname=amd64-linux uname='linux cerebro 2.6.10-rc1 #1 smp mon nov 22 05:47:21 cet 2004 x86_64 gnulinux ' config_args='-Duselargefiles -Dxuse64bitint -Uxuse64bitall -Dusemymalloc=y -Dcc=gcc-3.4 -Dccflags=-ggdb -Dcppflags=-D_GNU_SOURCE -I/opt/include -Doptimize=-O4 -march=opteron -mtune=opteron -funroll-loops -fno-strict-aliasing -Dcccdlflags=-fPIC -Dldflags=-L/opt/perl/lib -L/opt/lib -Dlibs=-ldl -lm -lcrypt -Darchname=amd64-linux -Dprefix=/opt/perl -Dprivlib=/opt/perl/lib/perl5 -Darchlib=/opt/perl/lib/perl5 -Dvendorprefix=/opt/perl -Dvendorlib=/opt/perl/lib/perl5 -Dvendorarch=/opt/perl/lib/perl5 -Dsiteprefix=/opt/perl -Dsitelib=/opt/perl/lib/perl5 -Dsitearch=/opt/perl/lib/perl5 -Dsitebin=/opt/perl/bin -Dman1dir=/opt/perl/man/man1 -Dman3dir=/opt/perl/man/man3 -Dsiteman1dir=/opt/perl/man/man1 -Dsiteman3dir=/opt/perl/man/man3 -Dman1ext=1 -Dman3ext=3 -Dpager=/usr/bin/less -Uafs -Uusesfio -Uusenm -Uuseshrplib -Dd_dosuid -Dusethreads=undef -Duse5005threads=undef -Duseithreads=undef -Dusemultiplicity=undef [EMAIL PROTECTED] [EMAIL PROTECTED] -Dcf_by=Marc Lehmann -Dlocincpth=/opt/perl/include /opt/include -Dmyhostname=localhost -Dmultiarch=undef -Dbin=/opt/perl/bin -des' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='gcc-3.4', ccflags ='-ggdb -fno-strict-aliasing -pipe -I/opt/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O4 -march=opteron -mtune=opteron -funroll-loops -fno-strict-aliasing', cppflags='-D_GNU_SOURCE -I/opt/include -ggdb -fno-strict-aliasing -pipe -I/opt/include' ccversion='', gccversion='3.4.2 (Debian 3.4.2-3)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc-3.4', ldflags ='-L/opt/perl/lib -L/opt/lib -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-ldl -lm -lcrypt perllibs=-ldl -lm -lcrypt libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -L/opt/perl/lib -L/opt/lib -L/usr/local/lib' Locally applied patches: --- @INC for perl v5.8.6: /root/src/sex /opt/perl/lib/perl5 /opt/perl/lib/perl5 /opt/perl/lib/perl5 /opt/perl/lib/perl5
Re: [perl #36616] bug or feature? foreach (sort @array) {y/a-z/A-Z/;} # @array modified!
Shiping Zhang wrote:
The described behavior changes whether "sort @arr" goes directly in
'for' or you assign it first to an array variable.
@arr = ('one', 'two', 'three', 'four');
y/a-z/A-Z/ foreach sort @arr;
print "\na: @arr\n"
prints "a: ONE TWO THREE FOUR" and
@arr = ('one', 'two', 'three', 'four');
@s = sort @arr;
y/a-z/A-Z/ foreach @s;
print "\na: @arr\n"
prints "a: one two three four". This has to do with copy-on-assign?
>>That seems like a (subtle) feature. Otherwise, it is a very old bug:
>>the same behavior with 5.8.6, 5.6.1, and 5.005_03.
>>
If it's a feature, then it's not documented at all. Larry's Perl books do not
mention it, the sort man page from perldoc does not mention it, and the manual
page from www.perl.org does not mention it. And this feature is against
intuition and I would consider it more a bug than a feature (what use it has?).
I think other people wouldn't expect @array to be changed in the code above.
(New Perl programers may be surprised to know that foreach works on an alias,
but it's well documented (and warned) and such feature is at least useful under
some circumstances.) Conceptually, sort should return a true copy (sorted of
course) of its arguement and I think it is how people would understand it.
(How sort is implemented is a different matter. I guess sort is working on a
list of pointers to the elements of the original list and, in foreach context,
just returns a pointer to the list of pointers instead of making an anonymous
copy of the sort list.)
it's documented under perldoc perltrap as a discontinuance between perl4
and perl5 so it's been around for quite a while.
it's also documented under perldoc perlsyn:
"If any element of LIST is an lvalue, you can modify it by modifying VAR
inside the loop. Conversely, if any element of LIST is NOT an lvalue,
any attempt to modify that element will fail. In other words, the
"foreach" loop index variable is an implicit alias for each item in the
list that you're looping over."
it's ALSO mentioned in perlfaq4: perldoc -q "strip blank space"
Re: [perl #36612] [PATCH] Misleading shift docs about @ARGV
Michael G Schwern (via RT) wrote: > > I think its more correct to say Yes. Thanks, applied as #25213.
Building with a precompiled header
Hello, I'm trying to build perl (5.6.1) with a precompiled header. The problem I'm having is that a precompiled header assumes a static header context for all source files, whereas the perl source files 'customize' the headers by defining relevant macros prior to including them. I was able to work around the PERL_IN_foo_C differences by defining PERL_DECL_PROT. I also added "#define PERLIO_NOT_STDIO 0" to avoid a macro redefinition in perlio.c.But linking failed because the interpreter globals were all undefined. Precompiling the header results in MUCH faster compiling -- by at least a factor of ten with Metrowerks CodeWarrior. But supporting it requires that headers depend only on the headers they include, not on the files including them (except for the precompiled header itself). Please let me know how I can help make this work. Josh -- Joshua Juran Metamage Software Creations - Mac Software and Consulting http://www.metamage.com/ * Creation at the highest state of the art *
Re: Current state
On Fri, 22 Jul 2005 12:06:00 +0200, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote: > On Fri, 22 Jul 2005 11:56:39 +0200, Rafael Garcia-Suarez <[EMAIL PROTECTED]> > wrote: > > Right. But don't forget VMS.. > > At the moment of writing I was under the assumption that VMS was still > healthy. > > I have to look at 10.20, since it's not quite happy with the current signals Compiler messages(hpux): cc: "POSIX.xs", line 1348: warning 605: Illegal pointer combination for ==. cc: "POSIX.xs", line 1356: warning 604: Pointers are not assignment-compatible. cc: "try.c", line 53: error 1529: Cannot select field of non-structure. cc: "try.c", line 53: error 1549: Modifiable lvalue required for assignment operator. cc: "try.c", line 56: warning 604: Pointers are not assignment-compatible. cc: "try.c", line 56: warning 563: Argument #2 is not the correct type. cc: "try.c", line 57: error 1529: Cannot select field of non-structure. cc: "try.c", line 57: error 1566: Test expression in for must be scalar. cc: "pp_sys.c", line 1931: warning 611: Qualifiers are not assignment-compatible. cc: "pp_sys.c", line 1931: warning 563: Argument #2 is not the correct type. cc: "POSIX.xs", line 1743: warning 527: Integral value implicitly converted to pointer in assignment. cc: "POSIX.c", line 3501: warning 527: Integral value implicitly converted to pointer in assignment. Should give me something to go for :) -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11, AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org reports to: [EMAIL PROTECTED],perl-qa@perl.org
Smoke [5.9.3] 25210 FAIL(F) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25210 fixit.xs4all.nl: Pentium II (i386/1 cpu) onbsd/os - 4.1 using cc version egcs-2.91.66 19990314 (egcs-1.1.2 release) smoketime 3 hours 54 minutes (average 1 hour 57 minutes) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25210 Configuration (common) none --- - F F - - -Duse64bitint O O - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] -Duse64bitint ../t/op/int.t...FAILED 11 -- Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503 (Reporter v0.019 / Smoker v0.023)
Schizophrenic miniperl
Following recent changes to the Win32 canned configs and makedef.pl, I find that after building an out-of-the-box perl (with ithreads et al) miniperl -V is rather confused: C:\p5p\bleadperl>.\miniperl -V Summary of my perl5 (revision 5 version 9 subversion 3) configuration: Platform: osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=define useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef [...] Characteristics of this binary (from libperl): Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP Notice that the "Compile-time options" doesn't include USE_ITHREADS, but the "Platform" section says "useithreads=define". The reason is that miniperl was built without ithreads (hence it is correctly not in "Compile-time options"), but perl was built with ithreads, so lib/Config_heavy.pl contains useithreads='define', which miniperl uses too! I suggested previously that much of the "Platform" section could now be dropped since it is mostly contained in "Compile-time options" now anyway (http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2005-07/msg00624.html). Another possibility is perhaps for miniperl to not print Config::myconfig() (if perl.c knows that it is in miniperl). I guess the output of things like ".\miniperl -V:useithreads" would still be wrong, though. Sigh... Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
[perl #36622] y/// at end of file
# New Ticket Created by "Piotr Fusik"
# Please include the string: [perl #36622]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36622 >
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.34 running under perl v5.8.0.
-
Among perl golf players, it is widely known that perl doesn't like
y/// at the very end of a file. So, we put an extra space or newline
just to make perl happy. Fortunately trailing whitespace doesn't
count to the score. :-)
If you forget to add something after y///, the error messages are very
misleading. For example, this program:
#!/usr/bin/perl -0
INIT{$A{$a}=1while$a=pop}1while"@A{/[a-z]+/ig}"=~/\B/&&y/B-ZA-Gb-za/B-ZA
b-za/
when syntax-checked by perl -c gives the following error message:
Unrecognized character \x81 at deroter.pl line 2.
(do you see any \x81 here?)
I think this should be finally resolved, because it can even crash perl:
#!/usr/bin/perl -0
INIT{%A=map{pop,[EMAIL PROTECTED]"@A{/\pL+/g}"=~/\B/&&y/B-ZA-Gb-za/A-z/
when syntax-checked gives a page fault.
It's the same on perl 5.8.0 and 5.8.6.
This report is for 5.8.0, because I have only an executable of 5.8.6.
-
---
Flags:
category=core
severity=medium
---
Site configuration information for perl v5.8.0:
Configured by ActiveState at Mon Mar 31 00:45:28 2003.
Summary of my perl5 (revision 5 version 8 subversion 0) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cl', ccflags
='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -D
HAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLI
O -DPERL_MSVCRT_READFIX',
optimize='-MD -Zi -DNDEBUG -O1',
cppflags='-DWIN32'
ccversion='', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags
'-nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C:\j\Perl\lib\CORE
" -machine:x86'
libpth="D:\Program Files\Microsoft.NET\FrameworkSDK\Lib\"
"D:\Program Files\Microsoft.Net\Odbc.Net\" "C:\j\Perl\lib\CORE"
libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib
odbc32.lib odbccp32.lib msvcrt.lib
perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib
version.lib odbc32.lib odbccp32.lib msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
gnulibc_version='undef'
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ',
lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C:\
j\Perl\lib\CORE" -machine:x86'
Locally applied patches:
ACTIVEPERL_LOCAL_PATCHES_ENTRY
---
@INC for perl v5.8.0:
C:/j/Perl/lib
C:/j/Perl/site/lib
.
---
Environment for perl v5.8.0:
HOME (unset)
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\U;C:\JAVA\JDK\BIN;C:\C\DJGPP\BIN;C
:\J\PERL\BIN;C:\J\MYSQL\BIN;C:\U\TEXMF\MAIN\MIKTEX\BIN;C:\U\GS\GS8.11\BI
N;C:\C\CYGWIN\BIN;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\U\ANT\BIN
PERL_BADLANG (unset)
SHELL (unset)
Re: Current state
On Fri, 22 Jul 2005 11:56:39 +0200, Rafael Garcia-Suarez <[EMAIL PROTECTED]> wrote: > H.Merijn Brand wrote: > > I've applied Jarkko's `fix' for POSIX machines not being POSIX after all > > on signals, and I have extended Steve Hay's patch 25209: > > > > 25210 made all tests on AIX 5.2.0.0 pass. > > > > IMHO, we're *very* close to a possible snapshot. If we can make cygwin and > > win32 happy again, as they were about two weeks ago, a new snapshot might > > encourage people to do even more testing. > > Right. But don't forget VMS.. At the moment of writing I was under the assumption that VMS was still healthy. I have to look at 10.20, since it's not quite happy with the current signals -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11, AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org reports to: [EMAIL PROTECTED],perl-qa@perl.org
Re: Current state
H.Merijn Brand wrote: > I've applied Jarkko's `fix' for POSIX machines not being POSIX after all on > signals, and I have extended Steve Hay's patch 25209: > > Change 25210 on 2005/07/21 by [EMAIL PROTECTED] 'I *DO* have AIX, and > extending ' > Change 25209 on 2005/07/21 by [EMAIL PROTECTED] 'Make makedef.pl read > "miniperl ' > Change 25208 on 2005/07/21 by [EMAIL PROTECTED] 'Make the canned config.h > files ' > Change 25207 on 2005/07/21 by [EMAIL PROTECTED] 'Subject: [PATCH] Re: [PATCH] > su' > Change 25206 on 2005/07/21 by [EMAIL PROTECTED] 'Rearrange win32/config_H.* > to m' > Change 25205 on 2005/07/21 by [EMAIL PROTECTED] 'Subject: [PATCH [EMAIL > PROTECTED] Com' > Change 25204 on 2005/07/20 by [EMAIL PROTECTED] 'Remove :base_io from the set > of' > Change 25203 on 2005/07/20 by [EMAIL PROTECTED] 'Fix definition of > Perl_sighandl' > > 25210 made all tests on AIX 5.2.0.0 pass. > > IMHO, we're *very* close to a possible snapshot. If we can make cygwin and > win32 happy again, as they were about two weeks ago, a new snapshot might > encourage people to do even more testing. Right. But don't forget VMS..
Re: Porting perl to (traditional) Mac OS via Genie
I would like to add my work to the core (when it's ready) as a new platform. Unless anyone objects, the platform name is 'Lamp', unix-name 'lamp', custom header 'lampish.h', and preprocessor macro MACOS_LAMP. On Jul 19, 2005, at 11:31 AM, Joshua Juran wrote: On Jul 19, 2005, at 5:43 AM, Dominic Dunlop wrote: Good to hear. You don't say whether this is PPC or 68k Mac OS. I guess the former, though the FAQs on your site make me wonder. Genie requires CFM... Genie's sockets support requires Open Transport ... I forgot to mention -- Genie builds and runs both as Carbon and classic. I typically develop in OS X using Carbon, running either natively or in Classic. MachTen was delivered with gcc, so I didn't use MPW or CodeWarrior in porting perl. If you search in old perl5- porters archives, you'll find mail about various issues I tripped over, including malloc() (once tweaked to work, Perl's own malloc was much faster than Mac OS' own); and fork() (MachTen, thanks to deep and probably dark magic, has both fork() and vfork(), but the latter is MUCH faster, as Mac OS does not support Copy on Write). You'll also find clues in hints/machten.sh. Mac OS doesn't have a malloc(), per se. It has NewPtr(), which is a dreadfully bad substitute, and the standard C library has one. I don't know how MSL's malloc() compares to MPW's. One of the problems is returning twice. Matthias got the idea to provide vfork() as a macro that calls setjmp(), which he implemented in his Natty project.[2] I opted against this for now, since what you'd have to do with the return value of setjmp() to implement proper vfork() semantics and what the standard says you're allowed to do with it are not compatible. AFAICT you're not even allowed to assign the return value to a variable. It might work anyway, but I didn't wish to go there. My interim solution requires as a compromise that code be written thus: [snip] The trick here is that for a Genie plugin, vfork() saves the caller's process context and returns the child pid (once), is_child_pid() is the identity function (always true for a pid), and either execve() (unless it fails) or _exit() restores the original process context AND RETURNS. (Unless you call without forking, in which case it terminates the caller's thread.) Hey -- it works, doesn't it? For trivial uses, yes, but perl's code is rather more involved. I revisited Matthias' Natty project -- he writes: #define vfork() setjmp( *NattyVFork() ) NattyVFork() dynamically allocates and returns a jmp_buf* which is dereferenced and passed to setjmp(). One problem with this is that there's no way to return -1 on failure. I did this: #define vfork() ( SpawnVFork() ? -1 : setjmp(gVfork_jmp_buf) ) SpawnVFork() does almost the same thing that my old vfork() did, but returns 0 on success. Genie programs have private globals, so we can use a global for the jmp_buf. Execve() and _exit() save getpid(), call their respective kernel routines, and (for execve(), if successful) longjmp() with the saved pid. The standard library makes very weak guarantees about setjmp(), but fortunately Metrowerks delivers what we need. We now have a working 'system' operator. Josh -- Joshua Juran Metamage Software Creations - Mac Software and Consulting http://www.metamage.com/ * Creation at the highest state of the art *
