Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

TREE IS FEATURE FROZEN (2003-Sep-14)

5 views
Skip to first unread message

Steve Fink

unread,
Sep 14, 2003, 11:47:14 PM9/14/03
to perl6-i...@perl.org
Time to clean up! How are Windows builds doing these days? Looking at
the tinderbox, it looks like we've got a Debian PPC, a FreeBSD, and an
x86 Linux, but nothing "interesting". And all broken by some jerk who
didn't update the MANIFEST.

Oh, wait. That was me.

By the way, Dan convinced me that this will be 0.0.11. No objects, and
the current state of exceptions is much too tentative.

Suggestions for code names? Speak now, or forever hold your gag
reflex: "hairy tulip" is still the front runner.

I also notice that 'make languages' is quite broken. First breakage is
in Jako. I haven't looked, but from the error, it's probably spewing
stuff outside of a subroutine.

Steve Fink

unread,
Sep 15, 2003, 3:23:13 AM9/15/03
to Steve Fink, perl6-i...@perl.org, br...@brentdax.com
A couple of other things came to mind. Here's my current view of the
laundry list. Additions welcome.

1. languages/imcc move. Last I heard, this was blocked on Dan & Leo
coming to an agreement over where it, and the rest of the source code,
should go.

2. typedef struct Parrot_Interp stuff. Brent, you're the man -- do you
still need some agreement on conventions before you rename our world?

3. 'make languages' and 'make languages-test'. It would be nice to get
these working and including more of the subdirectories. I did my part in
languages/regex today. I'm also about to add a whole bunch of other
languages to the makefile.

4. Win32. I don't know that it's broken, but I'm assuming it is on
general principle.

Also, what's the state of the nci tests? Is there any hope for them
under different OSes? t/pmc/n.t is failing for me right now, but that's
probably because I have an ancient libnci.so that happens to be lying
around. Is everyone else just skipping this test?


Leopold Toetsch

unread,
Sep 15, 2003, 4:22:21 AM9/15/03
to Steve Fink, perl6-i...@perl.org
Steve Fink <st...@fink.com> wrote:

> 1. languages/imcc move. Last I heard, this was blocked on Dan & Leo
> coming to an agreement over where it, and the rest of the source code,
> should go.

Robert said:
"We should probably wait until after 0.0.11 for this, to minimize
disruption."
I'm fine with postponing the move, as long as then the move is into a
separate directory :)

> 3. 'make languages' and 'make languages-test'. It would be nice to get
> these working and including more of the subdirectories. I did my part in
> languages/regex today. I'm also about to add a whole bunch of other
> languages to the makefile.

All languages SHOULD [1] have a "make test" Makefile target.

> Also, what's the state of the nci tests? Is there any hope for them
> under different OSes?

Non operating specific extension like libnci should IMHO have better
support in the C<loadlib> opcode. The file extensions (.so, .dll...)
could be handled in the platform code. Windows AFAIK needs an export.def
file. This could be autogenerated from the source (PARROT_DLL_EXPORT or
such) by a small utility.

> ... t/pmc/n.t is failing for me right now, but that's


> probably because I have an ancient libnci.so that happens to be lying
> around. Is everyone else just skipping this test?

I'm always running nci.t.

[1] rfc2119

leo

Vladimir Lipskiy

unread,
Sep 15, 2003, 7:43:46 AM9/15/03
to Steve Fink, perl6-i...@perl.org, br...@brentdax.com
> 4. Win32. I don't know that it's broken, but I'm assuming it is on
> general principle.

D:\build\parrot>perl Configure.pl

[snip]

Probing for C headers...done.
Determining some sizes...Linker failed (see test.ldo) at
lib/Parrot/Configure/St
ep.pm line 170.

The code

# 'link' needs to be link.exe, not cl.exe.
# This makes 'link' and 'ld' the same.
Configure::Data->set('link', Configure::Data->get('ld'));

in config\init\hints\mswin32.pl sets link to a ''", since

D:\>perl -V:ld
ld='';

D:\>

I already reported about that problem a while ago and nobody
responded to it.

This patch


--- parrot/config/init/hints/mswin32.pl 2003-08-20 13:34:27.000000000 +0300
+++ build/parrot/config/init/hints/mswin32.pl 2003-09-15 13:55:22.000000000
+0300
@@ -53,7 +53,8 @@
);
# 'link' needs to be link.exe, not cl.exe.
# This makes 'link' and 'ld' the same.
- Configure::Data->set('link', Configure::Data->get('ld'));
+ Configure::Data->set('link',
+ Configure::Data->get('ld') ? Configure::Data->get('ld') :
'link');
}
if( $is_bcc ) {
Configure::Data->set(


would be okay.

Next.

[snip]

Generating feature.h...done.
Writing Parrot::Config module...done.
Generating Makefiles...value for 'ccwarn' in config/gen/makefiles/root.in is
und
ef at lib/Parrot/Configure/Step.pm line 145, <IN> line 134.
value for 'ccwarn' in config/gen/makefiles/classes.in is undef at
lib/Parrot/Con
figure/Step.pm line 145, <IN> line 14.
value for 'ccwarn' in config/gen/makefiles/imcc.in is undef at
lib/Parrot/Config
ure/Step.pm line 145, <IN> line 26.
done.


D:\build\parrot>nmake

[snip]

io/io_win32.c
io_win32.c
io/io_win32.c(212) : error C2371: 'PIO_win32_flush' : redefinition;
different ba
sic types
io/io_win32.c(49) : see declaration of 'PIO_win32_flush'
NMAKE : fatal error U1077:
'D:\Perl\5.6.1\bin\MSWin32-x86-multi-thread\perl.exe'
: return code '0x2'
Stop.

Seems like Juergen did apply only one of two patches which I proposed on
06.09.2003
See Re: Win32 Build Issues (was Re: Linking pdump and dissassemble)
06.09.2003 4:40

And finally,

D:\build\parrot>nmake test

[snip]

t/pmc/intlist..........ok
t/pmc/io...............NOK 3# Failed test (t/pmc/io.t at line 38)
# got: 'fdopen failed
# '
# expected: 'ok
# '
t/pmc/io...............NOK 4# Failed test (t/pmc/io.t at line 52)
# got: 'fdopen failed
# '
# expected: 'ok
# '
t/pmc/io...............ok 19/19# Looks like you failed 2 tests of 19.
t/pmc/io...............dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 3-4
Failed 2/19 tests, 89.47% okay (less 1 skipped test: 16 okay,
84.21%)
t/pmc/iter.............ok

[snip]

t/pmc/timer............ok
t/native_pbc/number....ok
3/3 skipped: core ops changes
Failed Test Stat Wstat Total Fail Failed List of Failed
----------------------------------------------------------------------------
---
t/pmc/io.t 2 512 19 2 10.53% 3-4
23 subtests skipped.
Failed 1/57 test scripts, 98.25% okay. 2/897 subtests failed, 99.78% okay.
NMAKE : fatal error U1077:
'D:\Perl\5.6.1\bin\MSWin32-x86-multi-thread\perl.exe'
: return code '0xff'
Stop.

So we have only 2 test failing on Windows. Those failings are concerned with
the erroneous implementation of fdopen and Juergen will fix that in a while.
See
Sent: Friday, September 05, 2003 6:24 PM
Subject: [RfC] Semantics of fdopen.

Matt

unread,
Sep 15, 2003, 9:29:19 AM9/15/03
to
st...@fink.com (Steve Fink) wrote in message news:<20030915034714.GA13768@foxglove>...

> Time to clean up! How are Windows builds doing these days? Looking at
> the tinderbox, it looks like we've got a Debian PPC, a FreeBSD, and an
> x86 Linux, but nothing "interesting". And all broken by some jerk who
> didn't update the MANIFEST.

Windows here.

Failed Test Status Wstat Total Fail Failed List of Failed
--------------------------------------------------------------------------

t/pmc/io.t 2 512 19 2 10.53% 3-4
t/src/manifest.t 1 256 4 1 25.00% 4
21 subtests skipped.
Failed 2/57 test scripts, 96.49% okay. 3/897 subtests failed, 99.67%
okay.

Dunno why the manifest fails, it scrolls by too fast.. but for io:

t/pmc/io............NOK 3# Failed test (t/pmc/io.t at line 38)


# got: 'fdopen failed
# '
# expected: 'ok
# '

t/pmc/io............NOK 4# Failed test (t/pmc/io.t at line 52)


# got: 'fdopen failed
# '
# expected: 'ok
# '

My assumption is that because windows does have have file descriptors,
it fails. Makes sense, huh? But surely I'm not the first person to
run the tests on windows. Hasn't this test failed for anyone else on
windows? Isn't there any sort of check to see if the current machine
is windows, and to skip this test? Is there a way to do so?

Dan Sugalski

unread,
Sep 15, 2003, 9:54:11 AM9/15/03
to Steve Fink, perl6-i...@perl.org
On Sun, 14 Sep 2003, Steve Fink wrote:

> Time to clean up! How are Windows builds doing these days? Looking at
> the tinderbox, it looks like we've got a Debian PPC, a FreeBSD, and an
> x86 Linux, but nothing "interesting". And all broken by some jerk who
> didn't update the MANIFEST.

I'll kick glastig again, so there's an OS X box in the mix, and I should
have a JIT and non-JIT x86 Linux set added in the next day or so. Hardware
ghods willing (read "Don't count on it") I'll have the TPF WinXP build
system going with at least cygwin and VS/.NET tinders. Cygwin, in my last
attempt, failed some tests, but since the machine I did it on is both
inaccessible and in several pieces I don't have details. (Sorry)

Dan

Brent Dax

unread,
Sep 16, 2003, 2:35:02 AM9/16/03
to Steve Fink, perl6-i...@perl.org
Steve Fink:
# On Sep-15, Brent Dax wrote:
# > Steve Fink:
# > # 2. typedef struct Parrot_Interp stuff. Brent, you're the man -- do
you
# > # still need some agreement on conventions before you rename our
world?
# >
# > You mean we might actually (gasp!) get this done? Horrors!
#
# Huh? No, I just like to bring it up once in a while because I really
# think it ought to be done. I'm sure it will get lost in the confusion
# again.

Certainly. But it's nice to know that you're thinking about it. :^)

# > Anyway, I think we'll do Interp * for the internals and
Parrot_Interp
# > for the external interfaces--any objections to this scheme?
#
# Fine with me, but you should still get the typedef'ing a pointer past
# the gang at large.

Argh! Second time in less than a week that I hit the wrong reply
button.

OK, this'll go to the list--that's why I'm not cutting anything out.

# > I'll find some time to hack on this later today.
#
# Do days start at 12:00am for you, or whenever you wake up? :-)

Usually whenever I wake up. Unfortunately, I never found that time--I'm
preparing a college application right now, so things are a bit hectic
here. And the fact that it's not actually compiling on Win32 doesn't
help much. I'll get to it when I can.

# > # 4. Win32. I don't know that it's broken, but I'm assuming it is on
# > # general principle.
# >
# > Here's a weird one right off the bat:
#
# Ugh. I really need to figure out how to get hold of a true Win32 setup
# so I can actually contribute an informed opinion on these things...

I already patched that thing with the 1s--committed it at 9:30am PDT.
The I/O thing is still an issue, but apparently it just involves a patch
that Jurgen needs to apply.

--Brent Dax <br...@brentdax.com>
Perl and Parrot hacker

"Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna
set myself on fire to prove it."

Juergen Boemmels

unread,
Sep 17, 2003, 10:39:49 AM9/17/03
to Perl6 Internals
"Vladimir Lipskiy" <fors...@kaluga.ru> writes:

> Seems like Juergen did apply only one of two patches which I proposed on
> 06.09.2003
> See Re: Win32 Build Issues (was Re: Linking pdump and dissassemble)
> 06.09.2003 4:40

Ooops. These were two independend patches with the same name.
Thanks applied.

> So we have only 2 test failing on Windows. Those failings are concerned with
> the erroneous implementation of fdopen and Juergen will fix that in a while.
> See
> Sent: Friday, September 05, 2003 6:24 PM
> Subject: [RfC] Semantics of fdopen.

I'm working on that, but had several days without a computer at
all.

bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47

Juergen Boemmels

unread,
Sep 17, 2003, 4:11:15 PM9/17/03
to l...@toetsch.at, Steve Fink, perl6-i...@perl.org
Leopold Toetsch <l...@toetsch.at> writes:

> > ... t/pmc/n.t is failing for me right now, but that's
> > probably because I have an ancient libnci.so that happens to be lying
> > around. Is everyone else just skipping this test?
>
> I'm always running nci.t.

How do you do that?
On a clean checkout of parrot i get :
t/pmc/nci...........i386 JIT CPU
.so SO extension
t/pmc/nci...........ok, 10/10 skipped: needs jit/i386 and libnci.so

$ make libnci.so
make: *** No rule to make target `libnci.so'. Stop.

$ touch libnci.so
$ perl -Ilib t/pmc/nci.t
1..10
i386 JIT CPU
.so SO extension
Quit

All tinderboxens say the same:
10/10 skipped: needs jit/i386 and libnci.so

confused
boemmels

Leopold Toetsch

unread,
Sep 18, 2003, 2:41:08 AM9/18/03
to Juergen Boemmels, perl6-i...@perl.org
Juergen Boemmels <boem...@physik.uni-kl.de> wrote:
> Leopold Toetsch <l...@toetsch.at> writes:

>> I'm always running nci.t.

> How do you do that?

$ head -5 nci_test.c
#include <stdio.h>
/*
* cc -shared -fpic nci_test.c -o libnci.so -g
* export LD_LIBRARY_PATH=.
*/

> $ make libnci.so
> make: *** No rule to make target `libnci.so'. Stop.

When I wrote these tests, I did submit a patch to include building
libnci.so in the test target. But as its still OS dependend it got never
applied.

> boemmels

leo

0 new messages