I just took the time and looked through the failing tinderboxens:
- sprite and ariete:
They have an old dynoplibs/Makefile lying around, which leads to a
failing MANIFEST check.
Solution: just remove dynoplibs/Makefile.
- adrastea
Conflict in MANIFEST,
which lets Configure.pl fail, and the Makefiles are not regenerated.
Solution: Remove conflicts in MANIFEST
- Irresolute (FreeBSD)
Configure is failing:
Determining some sizes...Linker failed (see test.ldo) at lib/Parrot/Configure/Step.pm line 181.
Question: what says test.ldo
- Irresolute (Windows)
Fails in compiling jit_cpu.c: with
d:\cvsprojects\parrot\src\jit_cpu.c(95) : error C2065: 'RTYPE_COM' :undeclared identifier
hidden a huge bunch of warnings.
Does JIT work on windows?
Maybe it works if configured with --jitcapable=0
BTW: It does make but nmake test and make seems to fail right away.
- actinium
This is a harder error:
# Failed to build 't/src/extend_1.o': "./include/parrot/extend.h", line 76.23: 1506-120 (S) Function cannot return a const qualified type.
# "./include/parrot/extend.h", line 78.23: 1506-120 (S) Function cannot return a const qualified type.
# Failed test (t/src/extend.t at line 7)
The offending code section is:
const Parrot_CharType Parrot_find_chartype(Parrot_INTERP, char*);
Parrot_Language Parrot_find_language(Parrot_INTERP, char*);
const Parrot_Encoding Parrot_find_encoding(Parrot_INTERP, char*);
It seems like AIX does not like functions returning a const variable
even though its a void *.
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
> Hi,
>
> I just took the time and looked through the failing tinderboxens:
> - sprite and ariete:
I've cleaned out the sprite tinder directories, so we'll see what happens.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
> - Irresolute (Windows)
> Fails in compiling jit_cpu.c: with
> d:\cvsprojects\parrot\src\jit_cpu.c(95) : error C2065: 'RTYPE_COM'
:undeclared identifier
> hidden a huge bunch of warnings.
> Does JIT work on windows?
> Maybe it works if configured with --jitcapable=0
> BTW: It does make but nmake test and make seems to fail right away.
Just checked into all of this and no, things are not at all good on Win32 -
warnings galore. It does work with --jitcapable=0, but it used to work
without that. How long it's been broken I can't say - I have just started
uni, and haven't had as much time as I would have liked to follow things on
parrot. The errors making JIT fails with include:-
jit_cpu.c(95) : error C2065: 'RTYPE_COM' : undeclared identifier
jit_cpu.c(149) : error C2065: 'EXEC_CALLDISP' : undeclared identifier
The warnings mostly all take this kinda form:-
jit_cpu.c(318) : warning C4305: '=' : truncation from 'const long ' to 'char
'
jit_cpu.c(319) : warning C4305: '=' : truncation from 'const int ' to 'char
'
There are also various other warnings of a similar nature in non-JIT stuff
(but not so many) and a few "unreferenced local variable" warnings.
As for tests:-
Failed Test Stat Wstat Total Fail Failed List of Failed
----------------------------------------------------------------------------
---
t\src\extend.t 1 256 12 1 8.33% 11
t\src\io.t 2 512 16 2 12.50% 9-10
3 subtests skipped.
Failed 2/9 test scripts, 77.78% okay. 3/59 subtests failed, 94.92% okay.
NMAKE : fatal error U1077: 'F:\Perl\bin\perl.exe' : return code '0xff'
Stop.
Here's one of them:-
t\src\extend......NOK 11# got: 'in sub1
# hello in sub2
# back
# back
# '
# expected: 'in sub1
# back
# hello in sub2
# back
# '
And the others:-
t\src\io..........NOK 9# Failed test (t\src\io.t at line 242)
# got: '"temp.file" ">" should have opened
# "temp.file" ">>" should have opened
# "temp.file" "+<" should have opened
# "temp.file" "+>" should have opened
# "does_not_exist" ">>" should have opened
# "does_not_exist" "+<" should have opened
# "does_not_exist" "+>" should have opened
# done
# '
# expected: 'done
# '
# Failed test (t\src\io.t at line 293)
t\src\io..........NOK 10# got: 'should have read "." not ".?2"done
# '
# expected: 'done
# '
If anyone wants to see all the errors, let me know. It's kinda long so I
didn't wanna send it straight to the list.
Hope this helps,
Jonathan
> jit_cpu.c(95) : error C2065: 'RTYPE_COM' : undeclared identifier
Albeit the line number isn't really usefull here, this error could be in
the jit_emit_end opcode, I've separated exec/jit cases, which might
help.
leo
> I supplied a fix for this; see RT ticket #24247 for a full explanation =
> of the general problem.
Applied, thanks,
leo
Linker failed have a place only for FreeBSD 4.x, over pthreads.
I will do patch for config/init/hints/freebsd.pl.
But is trifle, it is important what testing sys/socket.h for FreeBSD failed.
See RT ticket #24329.
Nick.
Irresolute seems to work now. What have you done? I see
include/parrot/parrot.h modified in your cvs checkout.
Commenting to #24329:
There is currently now way to test for headers on only one platform,
but sys/types.h is general enough to get tested. In fact the test is
already done in perl and we use these by default.
> "Nick Kostirya" <ni...@han.kherson.ua> writes:
>
> > > - Irresolute (FreeBSD)
> > > Configure is failing:
> > > Determining some sizes...Linker failed (see test.ldo) at
> > lib/Parrot/Configure/Step.pm line 181.
> > > Question: what says test.ldo
> >
> > Linker failed have a place only for FreeBSD 4.x, over pthreads.
> > I will do patch for config/init/hints/freebsd.pl.
> >
> > But is trifle, it is important what testing sys/socket.h for FreeBSD
failed.
> > See RT ticket #24329.
>
> Irresolute seems to work now. What have you done? I see
> include/parrot/parrot.h modified in your cvs checkout.
1. I included <sys/types.h> and <sys/socket.h> manually before include
<netinet/in.h>.
2. for linking with pthreads I use -pthread flag instead of -lpthreads, as
I have FreeBSD 4.8 , but not FreeBSD 5.x
I've committed a change for extend_11 (I did print to stdout, which
might be out of sync with the rest goin' to stderr).
> t\src\extend......NOK 11# got: 'in sub1
> # hello in sub2
> # back
> # back
Yep. That must have it been.
> t\src\io..........NOK 9# Failed test (t\src\io.t at line 242)
> # got: '"temp.file" ">" should have opened
> # "temp.file" ">>" should have opened
io_win32 seems to lack append mode and such.
> # Failed test (t\src\io.t at line 293)
> t\src\io..........NOK 10# got: 'should have read "." not ".?2"done
Could be a line-ending thingy \r\n vs \n
> Jonathan
leo
> Jonathan Worthington <jona...@jwcs.net> wrote:
> > Failed Test Stat Wstat Total Fail Failed List of Failed
>
> --------------------------------------------------------------------------
--
> > ---
> > t\src\extend.t 1 256 12 1 8.33% 11
>
> I've committed a change for extend_11 (I did print to stdout, which
> might be out of sync with the rest goin' to stderr).
>
> > t\src\extend......NOK 11# got: 'in sub1
> > # hello in sub2
> > # back
> > # back
>
> Yep. That must have it been.
'fraid it wasn't. Still fails in the same way. Sorry.
> > t\src\io..........NOK 9# Failed test (t\src\io.t at line 242)
> > # got: '"temp.file" ">" should have opened
> > # "temp.file" ">>" should have opened
>
> io_win32 seems to lack append mode and such.
I'll take a peek and if you're really lucky I might even figure out how to
patch it. ;-)
> > # Failed test (t\src\io.t at line 293)
> > t\src\io..........NOK 10# got: 'should have read "." not
".?2"done
>
> Could be a line-ending thingy \r\n vs \n
Maybe, I'll take a look to see if I can make sense of it.
Jonathan
Checked in another change, Win32 seems to buffer stderr too, added
a fflush(stderr).
> Jonathan
leo
With these changes, the tinder stuff's working again on Win32. Oni, in the
tinderbox, is a cygwin build of perl on WInXP.
(http://tinderbox.perl.org/tinderbox/bdshowbuild.cgi?tree=parrot)
t/op/number_10.t seems to be failing because of -0 from C<mod>.
Any hints what to do WRT such behavior?
leo
Its an issue with our (IBM's) compiler. It comes from
0.0-0.0*0.0 as a result of the mod test if I recall.
I dug into the powerpc instructions once and figured it out,
but have forgotten the whole issue now.
It is arguably correct, depending on who you ask, except
every other mainstream compiler disagrees, so go figure.
-Melvin
> At 06:40 PM 10/29/2003 +0100, Leopold Toetsch wrote:
> >Adam Thomason <thom...@xencor.com> wrote:
> > > The other problematic test is ye =
> > > olde -0 error,
> Its an issue with our (IBM's) compiler. It comes from
> 0.0-0.0*0.0 as a result of the mod test if I recall.
> It is arguably correct, depending on who you ask, except
> every other mainstream compiler disagrees, so go figure.
A quick grep on the perl5 sources for 'negative zero' gets a fair number
of hits mentioning AIX, Digital Unix, and OpenBSD. sv.c contains some
legacy 'FIXNEGATIVEZERO' code as well. In short, it's probably best to
assume that some compilers will give us a negative zero sometimes.
Whether the parrot virtual machine should or should not hide that detail
is a good question -- probably equivalent to whether parrot should spell
infinity "Inf" or "inf" or not care (and similarly for "nan" and "NaN").
--
Andy Dougherty doug...@lafayette.edu
> A quick grep on the perl5 sources for 'negative zero' gets a fair number
> of hits mentioning AIX, Digital Unix, and OpenBSD. sv.c contains some
> legacy 'FIXNEGATIVEZERO' code as well.
... which seems not to be defined nor mentioned anywhere.
> ... In short, it's probably best to
> assume that some compilers will give us a negative zero sometimes.
> Whether the parrot virtual machine should or should not hide that detail
> is a good question
Its coloring tinderboxen for no good reason. If something really got
wrong its hidden. So IMHO we should either change the test or have a
configure option and convert "-0.0*" to "0".
> ... -- probably equivalent to whether parrot should spell
> infinity "Inf" or "inf" or not care (and similarly for "nan" and "NaN").
Yep.
leo