Re: [MacPerl-Porters] MacPerl 5.8 TODO
At 16:12 Uhr -0400 31.05.2002, Chris Nandor wrote:
At 14:22 +0200 2002.05.31, Thomas Wegner wrote:
I've just run Spec.t (I've moved it to perl/t/, before I executed it), and
all (1..369) tests are ok. Which tests are failing for you?
not ok 285 # Mac-catdir('', '::'): got ':', expected ''
not ok 320 # Mac-catdir('','::','d1','d2'): got ':d1:d2:', expected 'd1:d2:'
I am going to look into it momentarily, but any input you have is welcome.
Not sure whether or not you have solved this in the meantime, just in case
not ...
test 285 should give $root, i.e. File::Spec-rootdir (startup volume)
test 320 should give ${root}d1:d2:
Looks as if $root is not set properly, but in this case, other tests should
fail too. I'm clueless (since I cannot repeat it). If necessary, I'll look into
it again when MacPerl 5.8.0 has arrived.
Best regards,
--Thomas
Re: [MacPerl-Porters] MacPerl 5.8 TODO
At 13:00 +0200 2002.06.01, Thomas Wegner wrote:
Not sure whether or not you have solved this in the meantime, just in case
not ...
test 285 should give $root, i.e. File::Spec-rootdir (startup volume)
test 320 should give ${root}d1:d2:
Looks as if $root is not set properly, but in this case, other tests should
fail too. I'm clueless (since I cannot repeat it). If necessary, I'll look
into
it again when MacPerl 5.8.0 has arrived.
Yeah, I discovered that the problem was merely that @INC did not include
::lib:MacPPC: when File::Spec was loaded, so I moved the push @INC line to
the BEGIN block, and it solved the problem. All tests are passing now
except:
* ExtUtils (most of it needs porting)
* h2ph/h2xs (need porting)
* Devel::DProf (needs porting)
* s2p (two tests fail unexpectedly)
* Time::HiRes (problems with alarm)
* die_exit (broken $? values in MacPerl, also problem elsewhere in tests)
* warnings (sysopen doesn't warn on reading from file opened for WRONLY)
* sprintf (%g formats somewhat broken in sfio)
* taint.t (no warning for taint when opening O_RDWR)
So we're looking good. The last four I am ignoring for now, as they are
longstanding issues in GUSI or SFIO that I can't easily tackle. The first
five there would be nice to have fixed at some point, but aside from
Time::HiRes (which I am going to work on soonish) are relatively low
priority.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: [MacPerl-Porters] MacPerl 5.8 TODO
I'm sorry but I think the proposed INC et al changes look much too scary to go into 5.8.0. Maybe they can go into MacPerl 5.8.0 (which will happen somewhere between mainline 5.8.0 and mainline 5.8.1, I guess.) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: [MacPerl-Porters] MacPerl 5.8 TODO
At 17:46 +0300 2002.05.31, Jarkko Hietaniemi wrote: I'm sorry but I think the proposed @INC et al changes look much too scary to go into 5.8.0. Maybe they can go into MacPerl 5.8.0 (which will happen somewhere between mainline 5.8.0 and mainline 5.8.1, I guess.) Would you mind putting in Mac-specific if/else's? Then it won't affect anyone else, but it should solve our problems (see my followup in a moment). -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: [MacPerl-Porters] MacPerl 5.8 TODO
On Fri, May 31, 2002 at 10:54:44AM -0400, Chris Nandor wrote: At 17:46 +0300 2002.05.31, Jarkko Hietaniemi wrote: I'm sorry but I think the proposed @INC et al changes look much too scary to go into 5.8.0. Maybe they can go into MacPerl 5.8.0 (which will happen somewhere between mainline 5.8.0 and mainline 5.8.1, I guess.) Would you mind putting in Mac-specific if/else's? Then it won't affect anyone else, but it should solve our problems (see my followup in a moment). That would work for now, yes. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/ -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: [MacPerl-Porters] MacPerl 5.8 TODO
At 13:46 +0200 2002.05.31, Thomas Wegner wrote:
Just one thing: Most of the tests, including the ExtUtils:: tests,
still assume to be in the perl/t/ directory, at least that's what
it looks like. This makes fixing @INC issues a real pain in the
rear (ahem...), to be honest. And some tests just don't run,
because they are deeper in the directory tree as expected, i.e.
@INC = '../lib'; doesn't work. So why have these test been
moved into lib/? Or did I miss something?
I am running the tests from perl/t/. My current test script sent
separately in off-list mail. Every uncommented test is working (or is
mostly working, or is noted in the comments at the end to fail). I think I
have only 8 tests failing that are uncommented, and 5 of those are expected
to.
Essentially, the tests run as:
:perl -I::lib ::lib:ExtUtils:...
so we stay in the same place.
Maybe I will get to the ExtUtils tests tomorrow. It's kinda ugly in there,
Yep, more than ugly. 00setup_dummy.t drives me crazy :-).
I got that one taken care of, yeah, it was hairy. Patch will be on
perl5-changes-mac this morning.
Correct me if I'm wrong: According to lib.pm's pod, paths are added (not
replaced) to the front of @INC. Thus, tests 2 3 expect @INC to be
('stuff/moo/MacPPC', 'stuff/moo', '../lib') ,
if we were on Unix, right?
Aha, I think you're onto it. This is what sleep deprivation does to me. :)
If you agree, and Jarkko agrees, I suggest that lib.pm no longer uses Unix
paths only (if possible). Although MacPerl tolerates Unix paths to some
degree, we cannot translate Mac OS native paths to Unix paths in all cases
(and e.g. a -d 'stuff/moo/MacPPC', which is done internally, will always
fail).
Note recent patch to perl.c does this:
:perl -I'../lib' -le 'print @INC'
::lib:MacPPC: ::lib:
However, that only works for stuff in @INC already, or added to @INC via
-I. We could fix lib.pm to do this, as you did, but my question is:
Should we preserve the Unix style of the @INC element?
That is, should the above output be as it is, or should it be
../lib/MacPPC ../lib ? I am unsure. I think this is reasonable, and if
so, then we should do the same thing in lib.pm. We just need to run
Mac::FileSpec::Unixish::nativize.
my $Mac_FS;
if ($^O eq 'MacOS') {
$Mac_FS = eval { require Mac::FileSpec::Unixish };
}
#...
if ($Mac_FS) {
$_ = Mac::FileSpec::Unixish::nativize($_);
}
From then on, treat it as a Mac path.
Jarkko, do you think this is reasonable, not just for 5.8.0 (the catdir
stuff could all be put in if ($^O eq 'MacOS') for now), but in general?
That it is reasonable to fudge values in @INC to be Mac-style if Unix-style
are passed?
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: [MacPerl-Porters] MacPerl 5.8 TODO
From then on, treat it as a Mac path. Jarkko, do you think this is reasonable, not just for 5.8.0 (the catdir Aaargh, don't ask me about anything beyond 5.8.0 right now :-) All I can say is the obey the First Rule: do no harm. stuff could all be put in if ($^O eq 'MacOS') for now), but in general? That it is reasonable to fudge values in @INC to be Mac-style if Unix-style are passed? -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/ -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: [MacPerl-Porters] MacPerl 5.8 TODO
At 18:11 +0300 2002.05.31, Jarkko Hietaniemi wrote: From then on, treat it as a Mac path. Jarkko, do you think this is reasonable, not just for 5.8.0 (the catdir Aaargh, don't ask me about anything beyond 5.8.0 right now :-) All I can say is the obey the First Rule: do no harm. Yes, I just wonder if munging @INC elements to be platform-specific would cause harm. I don't think it would, but am unsure. Then again, this would only affect Mac OS, so worst-case is that it breaks Mac OS. :) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: [MacPerl-Porters] MacPerl 5.8 TODO
At 14:22 +0200 2002.05.31, Thomas Wegner wrote:
I've just run Spec.t (I've moved it to perl/t/, before I executed it), and
all (1..369) tests are ok. Which tests are failing for you?
not ok 285 # Mac-catdir('', '::'): got ':', expected ''
not ok 320 # Mac-catdir('','::','d1','d2'): got ':d1:d2:', expected 'd1:d2:'
I am going to look into it momentarily, but any input you have is welcome.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: [MacPerl-Porters] MacPerl 5.8 TODO
At 13:25 Uhr -0400 29.05.2002, Chris Nandor wrote:
At 20:20 +0300 2002.05.29, Jarkko Hietaniemi wrote:
Since we don't have $ENV{PERL_CORE} in MacPerl, I'm not sure what to do.
CGI/t/carp.t runs with the MacPerl tool, but when run with the app, test
You should think of something :-) since many 5.8 tests assume
$ENV{PERL_CORE}, they simply won't work right without.
I started setting PERL_CORE in the test suite this week. You can just do
set -e PERL_CORE 1. I am also setting this as a parameter for Makefile.PL
for building extensions.
Shouldn't that be added (by default) to the list of environment variables in
the MacPerl app and to the MPW startup script for the MacPerl tool?
Best regards,
--Thomas
Re: [MacPerl-Porters] MacPerl 5.8 TODO
At 10:51 +0200 2002.05.30, Thomas Wegner wrote: Shouldn't that be added (by default) to the list of environment variables in the MacPerl app and to the MPW startup script for the MacPerl tool? No, PERL_CORE should only be true if you are building Perl, if I understand correctly. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: [MacPerl-Porters] MacPerl 5.8 TODO
On Thu, May 30, 2002 at 04:37:10PM +0300, Jarkko Hietaniemi wrote: On Thu, May 30, 2002 at 08:27:27AM -0400, Chris Nandor wrote: At 10:51 +0200 2002.05.30, Thomas Wegner wrote: Shouldn't that be added (by default) to the list of environment variables in the MacPerl app and to the MPW startup script for the MacPerl tool? No, PERL_CORE should only be true if you are building Perl, if I understand correctly. Yup. when building *and* when running the tests. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: [MacPerl-Porters] MacPerl 5.8 TODO
At 18:51 +0200 2002.05.30, Thomas Wegner wrote: * Tested through E* so far, except CPAN/t Does that include the ExtUtils:: tests? Several are failing for me. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: [MacPerl-Porters] MacPerl 5.8 TODO
At 18:51 +0200 2002.05.30, Thomas Wegner wrote: * CGI/carp.t [open] -- not ok 28 with MP app, ok with tool This one just gets a line number wrong, because the beginning of the file is: # -*- Mode: cperl; coding: utf-8; cperl-indent-level: 2 -*- #!/usr/local/bin/perl -w And then gives this error: not ok 28 - warningsToBrowser() on # Failed test (Bird:tmp:perl:lib:CGI:t:carp.t at line 179) # got: '!-- warning: There is a problem at Bird:tmp:perl:lib:CGI:t:carp.t line 105. -- # ' # expected: '!-- warning: There is a problem at Bird:tmp:perl:lib:CGI:t:carp.t line 106. -- # ' Is it worth fixing? Probably. Maybe I'll file a bug report, but I'll declare the test a pass. * CPAN tests [open] * Devel/SelfStubber.t [open] -- makes system() calls, fails badly * English.t [open] -- not ok 48, see note below Fixed. The test -- open on an empty string -- was resulting in MacPerl setting $! to Invalid argument, so I made it try to open a non-empty string instead, and it passed. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: [MacPerl-Porters] MacPerl 5.8 TODO
Since we don't have $ENV{PERL_CORE} in MacPerl, I'm not sure what to do.
CGI/t/carp.t runs with the MacPerl tool, but when run with the app, test
You should think of something :-) since many 5.8 tests assume
$ENV{PERL_CORE}, they simply won't work right without.
*** Digest::MD5
The version in the Makefile (2.16) doesn't match MD5.pm's version
2.20. Hence, loading will fail with:
# Digest::MD5 object version 2.16 does not match bootstrap parameter 2.20.
Where is the 2.16 in the Makefile coming from? It should be coming
from MD5.pm.
Best regards,
--Thomas
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: [MacPerl-Porters] MacPerl 5.8 TODO
At 20:20 +0300 2002.05.29, Jarkko Hietaniemi wrote:
Since we don't have $ENV{PERL_CORE} in MacPerl, I'm not sure what to do.
CGI/t/carp.t runs with the MacPerl tool, but when run with the app, test
You should think of something :-) since many 5.8 tests assume
$ENV{PERL_CORE}, they simply won't work right without.
I started setting PERL_CORE in the test suite this week. You can just do
set -e PERL_CORE 1. I am also setting this as a parameter for Makefile.PL
for building extensions.
*** Digest::MD5
The version in the Makefile (2.16) doesn't match MD5.pm's version
2.20. Hence, loading will fail with:
# Digest::MD5 object version 2.16 does not match bootstrap parameter 2.20.
Where is the 2.16 in the Makefile coming from? It should be coming
from MD5.pm.
Fixed that one last night. That's just my carelessness. The Makefile
requires an optimization flag and I had trouble getting it to be produced
properly in the Makefile, so I just include an existing one and copy it
over, and neglected to bump the version in it when Digest::MD5 was updated.
Really, I should find a way to have the Makefile produced properly, instead
of manually bumping the version, but it seems more trouble than it is
worth, in light of other things that need to get done. :-)
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
