[CVS ci] PLATFORMS
Please help me fill out the blanks by sending or committing patches. Please make sure to have the latest and best Parrot from CVS. Thanks, leo
Re: JIT branches under the Sun
Stephane Peiry wrote: Looking at it makes it pretty clear why it loops forever (mainly it jumps back to a load, loading always the same value). Yep. That's a bit complicated. The jit code tries to avoid loading/storing the same register from/to memory. This is achieved by remembering the size of the register loads (load_size) and setting fixup-skip accordingly. When now a branch goes to the same section (a backward branch like in mops.pasm), then the load should be skipped. jit/i386/jit_emit.h implements all the necessary bits. s. jit_emit_jcc, fixup-skip and load_size. . Stephane leo
Re: [PATCH] library/dumper.imc: self-referential data structures
Jens Rieks [EMAIL PROTECTED] wrote: again, here is a new patch for libraray/dumper.pmc. Thanks, applied. leo
[BUG] parrot bytecode (header?) problems in tru64/alpha
I tried parrot in tru64/alpha after quite a while and it seems that something has gone rotten with the bytecode. The t/native_pbc/integer.t and the t/native_pbc/number.t both fail: t/native_pbc/integer# Failed test (t/native_pbc/integer.t at line 35) # got: 'PackFile_unpack: Not a Parrot PackFile! # Magic number was [4c520050] not [13155a1] # Parrot VM: Can't unpack packfile t/native_pbc/integer_1.pbc. # error:imcc:main: Packfile loading failed # ' # expected: '270544960' # './parrot t/native_pbc/integer_1.pbc' failed with exit code 1 t/native_pbc/integerNOK 1# Looks like you failed 1 tests of 1. t/native_pbc/integerdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/1 tests, 0.00% okay Failed TestStat Wstat Total Fail Failed List of Failed --- t/native_pbc/integer.t1 256 11 100.00% 1 t/native_pbc/number# Failed test (t/native_pbc/number.t at line 42) # got: 'PackFile_unpack: Not a Parrot PackFile! # Magic number was [4c520050] not [13155a1] # Parrot VM: Can't unpack packfile t/native_pbc/number_1.pbc. # error:imcc:main: Packfile loading failed # ' # expected: '1.00 # 4.00 # 16.00 # 64.00 # 256.00 # 1024.00 # 4096.00 # 16384.00 # 65536.00 # 262144.00 # 1048576.00 # 4194304.00 # 16777216.00 # 67108864.00 # 268435456.00 # 1073741824.00 # 4294967296.00 # 17179869184.00 # 68719476736.00 # 274877906944.00 # 1099511627776.00 # 4398046511104.00 # 17592186044416.00 # 70368744177664.00 # 281474976710656.00 # 1125899906842620.00 # ' # './parrot t/native_pbc/number_1.pbc' failed with exit code 1 # Failed test (t/native_pbc/number.t at line 85) # got: 'PackFile_unpack: Not a Parrot PackFile! # Magic number was [4c520050] not [13155a1] # Parrot VM: Can't unpack packfile t/native_pbc/number_2.pbc. # error:imcc:main: Packfile loading failed Here are the first eight lines of hexdumps of t/native_pbc/integer_1.pbc 04 00 00 0d 04 00 ac 1d a0 e1 c0 b8 70 2a 58 a0 p*X. a1 55 31 01 4c 52 45 50 01 00 00 00 00 00 00 00 .U1.LREP 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0... 03 00 00 00 04 00 00 00 42 59 54 45 43 4f 44 45 BYTECODE 5f 2d 00 00 20 00 00 00 08 00 00 00 02 00 00 00 _-.. ... 46 49 58 55 50 5f 2d 00 28 00 00 00 08 00 00 00 FIXUP_-.(... 03 00 00 00 43 4f 4e 53 54 41 4e 54 5f 2d 00 00 CONSTANT_-.. 30 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 0... and t/native_pbc/number_1.pbc 04 00 00 0d 04 00 ac 1d a0 e1 c0 b8 70 2a 58 a0 p*X. a1 55 31 01 4c 52 45 50 01 00 00 00 00 00 00 00 .U1.LREP 44 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 D... 03 00 00 00 04 00 00 00 42 59 54 45 43 4f 44 45 BYTECODE 5f 74 2f 6f 70 2f 6e 75 6d 62 65 72 5f 31 2e 70 _t/op/number_1.p 61 73 6d 00 2c 00 00 00 bc 00 00 00 02 00 00 00 asm.,... 46 49 58 55 50 5f 74 2f 6f 70 2f 6e 75 6d 62 65 FIXUP_t/op/numbe 72 5f 31 2e 70 61 73 6d 00 00 00 00 e8 00 00 00 r_1.pasm myconfig: Summary of my parrot 0.0.13 configuration: configdate='Mon Feb 23 11:47:59 2004' Platform: osname=dec_osf, archname=alpha-dec_osf jitcapable=1, jitarchname=alpha-dec_osf, jitosname=DEC_OSF, jitcpuarch=alpha execcapable=0 perl=/u/vieraat/vieraat/jhi/Perl/Platform/OSF1/bin/perl Compiler: cc='cc', ccflags='-std -D_INTRINSICS -fprm d -ieee -I/p/include -DLANGUAGE_C -pthread', Linker and Libraries: ld='ld', ldflags=' -L/p/lib', cc_ldflags='', libs='-lm -lutil -lpthread' Dynamic Linking: so='.so', ld_shared='-shared -expect_unresolved * -O4 -msym -std -s -L/p/lib', ld_shared_flags='' Types: iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8, ptrsize=8, ptr_alignment=4 byteorder=12345678, nv=double, numvalsize=8, doublesize=8 My longsize would be 8. Note: if you have Tru64 you will need the attached (and submitted privately to Leo) config/init/hints/dec_osf.pl to get things to compile. -- Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen dec_osf.pl Description: Perl program
Re: [BUG] parrot bytecode (header?) problems in tru64/alpha
Jarkko Hietaniemi [EMAIL PROTECTED] wrote: I tried parrot in tru64/alpha after quite a while and it seems that something has gone rotten with the bytecode. The t/native_pbc/integer.t and the t/native_pbc/number.t both fail: t/native_pbc/integer# Failed test (t/native_pbc/integer.t at line 35) # got: 'PackFile_unpack: Not a Parrot PackFile! # Magic number was [4c520050] not [13155a1] Its obviously somewhere beyond the MAGIC (4c52 could be part of OPCODE_TYPE_PERL). I've committed a small change, that *could* correct the problem. leo
Objects and time
Okay, I've just trodden on one of the nasty bits of objects, proper ordering of classes for initialization and destruction in the face of multiple inheritance. I'm doing the only sensible thing at the moment--I'm actively ignoring it. I've burned a few hours chasing down this rathole. So, the question--shall we do objects and maybe miss the Feb 29th release, or do the Feb 29th release and do objects for the next release? As I think I'm only a little while off (maybe a day or so) from getting it working, I'm tempted to take a miss on the nice date in favor of a release with Good Stuff in it, but I'm flexible there. Time to weigh in on it, though in this case the decision's up to the Release Manager, so direct your on-list arguments to Leo. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Objects and time
Dan Sugalski sent the following bits through the ether: So, the question--shall we do objects and maybe miss the Feb 29th release, or do the Feb 29th release and do objects for the next release? Objects please! Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... That's Ren and Stimpy - they're way existential
Re: Objects and time
At 10:29 AM 2/23/2004 -0500, Dan Sugalski wrote: So, the question--shall we do objects and maybe miss the Feb 29th release, or do the Feb 29th release and do objects for the next release? As I think I'm only a little while off (maybe a day or so) from getting it working, I'm tempted to take a miss on the nice date in favor of a release with Good Stuff in it, but I'm flexible there. Nice dates are amusing, but of no real use. I say postpone the release. -Melvin
Re: Objects and time
Dan Sugalski [EMAIL PROTECTED] wrote: So, the question--shall we do objects and maybe miss the Feb 29th release, or do the Feb 29th release and do objects for the next release? As I think I'm only a little while off (maybe a day or so) from getting it working, Don't post intermediate state, hack objects together ;) Objects are missing since a long time and are announced still longer. So if possible anyhow, please try to get it running. WRT feature freeze: I'd say: Starting from Tue, 24th 8.00 GMT no more feature patches *should* go in, *except* objects. leo
Re: Objects and time
At 05:09 PM 2/23/2004 +0100, Leopold Toetsch wrote: WRT feature freeze: I'd say: Starting from Tue, 24th 8.00 GMT no more feature patches *should* go in, *except* objects. Basically that means: everyone will get really quiet and we will all watch Dan. :) -Melvin
Object notes
As I wait for an interim setup to build... Here's the lowdown on what we're going to get with object: 1) Multiple Inheritance 2) Attributes 3) Object instantiation 4) Method calls Woo. What we won't get is: 1) Adding parents to a class that's been subclassed or instantiated 2) Adding attributes to a class that's been subclassed or instantiated 3) Method redistpatch 4) Fancy namespace lookups So you can create classes with multiple parents and multiple attributes, instantiate objects, call methods on the objects, and twiddle the objects attributes. If the parents of Foo are Bar, Baz, and Some::Other::Thing then we'll search those in order, treating the colons as, well, colons, rather than namespace separators. That means no hierarchical namespaces. Yet. Adding methods to a class means sticking a PMC for the named method in the class namespace. So this: ns = global Some::Other::Thing ns['bar'] = SomeMethodPMC is how to add the method 'bar' to the namespace Some::Other::Thing. This will change, and may well not have to be done if the namespace stuff we were asking about earlier is actually in, but I'm not sure yet. I expect I'll find out soon. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
MANIFEST updates?
Hoping to help fill out some blanks in the PLATFORM file, I updated (via rsync) my parrot files and stumbled across the following MANIFEST problems: Checking MANIFEST... No such file: imcc/imclexer.c No such file: imcc/imcparser.c No such file: imcc/imcparser.h No such file: languages/cola/lexer.c No such file: languages/cola/parser.c No such file: languages/cola/parser.h Did I just update at an unlucky time and catch something in flux? -- Andy Dougherty [EMAIL PROTECTED]
Re: Objects and time
On Mon, 23 Feb 2004, Melvin Smith wrote: At 05:09 PM 2/23/2004 +0100, Leopold Toetsch wrote: WRT feature freeze: I'd say: Starting from Tue, 24th 8.00 GMT no more feature patches *should* go in, *except* objects. Basically that means: everyone will get really quiet and we will all watch Dan. :) Alternatively: everybody will spend their time writing tests and documentation... (Well, OK, probably not, but I'm hopelessly optimistic). Simon
Re: Objects and time
- Original Message - From: Dan Sugalski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 23, 2004 3:29 PM Subject: Objects and time Okay, I've just trodden on one of the nasty bits of objects, proper ordering of classes for initialization and destruction in the face of multiple inheritance. I'm doing the only sensible thing at the moment--I'm actively ignoring it. I've burned a few hours chasing down this rathole. So, the question--shall we do objects and maybe miss the Feb 29th release, or do the Feb 29th release and do objects for the next release? As I think I'm only a little while off (maybe a day or so) from getting it working, I'm tempted to take a miss on the nice date in favor of a release with Good Stuff in it, but I'm flexible there. Time to weigh in on it, though in this case the decision's up to the Release Manager, so direct your on-list arguments to Leo. :) Maybe we should go for a Feb 29th release, and then do objects for the next release and call that 0.1. If 0.1 is going to be a milestone of sorts, I feel the object stuff going in should be well documented and have tests and examples. It'd also be good to have feedback from the various platforms we'd like them to work on, and some time for people to toy with them a little to spot any little quirks. If there's a push to get a release done, I fear that may not happen. Of course, there may be no push to do a release, in which case I don't object to holding off until it's really ready. Jonathan
Re: [CVS ci] PLATFORMS
On Mon, 2004-02-23 at 01:30, Leopold Toetsch wrote: Please help me fill out the blanks by sending or committing patches. Please make sure to have the latest and best Parrot from CVS. I have a platform not listed. Where should I look for the appropriate information? -- c
Tetris (was: Objects and time)
Hi, Am Montag, 23. Februar 2004 17:09 schrieb Leopold Toetsch: WRT feature freeze: I'd say: Starting from Tue, 24th 8.00 GMT no more feature patches *should* go in, *except* objects. can/should go the tetris example go in? I'am writing documentation at the moment. Converting the example to use parrot objects is my next plan. leo jens
Re: [CVS ci] PLATFORMS
Leo, [did try to send off list, but it bounced] Please help me fill out the blanks by sending or committing patches. Please make sure to have the latest and best Parrot from CVS. Earlier today you popped a new file in CVS called PLATFORMS. Unfortunately, there is also a directory there called platforms. Win32 (and other platforms) aren't case sensitive; needless to say, my CVS client was more than slightly confused. ;) As the platforms directory seems pretty redundant, I'd say pull that and keep the file. Platforms stuff seems to be put in config now. Or maybe it has a secret future usage that I don't know about (it was empty as I remember). Thanks, Jonathan
Re: MANIFEST updates?
Andrew Dougherty [EMAIL PROTECTED] wrote: No such file: imcc/imclexer.c No such file: imcc/imcparser.c No such file: imcc/imcparser.h No such file: languages/cola/lexer.c No such file: languages/cola/parser.c No such file: languages/cola/parser.h These files are in MANIFEST and in the tree, *but* also in .cvsignore. AFAIK they shouldn't be in .cvsignore. leo
Re: [PATCH] Re: [perl #25239] Platform-specific files not granular enough
- Original Message - From: Leopold Toetsch [EMAIL PROTECTED] To: Jonathan Worthington [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, February 21, 2004 11:51 AM Subject: Re: [PATCH] Re: [perl #25239] Platform-specific files not granular enough Jonathan Worthington [EMAIL PROTECTED] wrote: I've attached a patch which causes stuff in begin.c to be put before the #include parrot/parrot.h line, which fixes up this problem. I don't know if it's the right thing to do, but it's the best one I could think of. Applied. Please create the empty signal.h too Done. ... - BTW, how should I have gone about including that in my patch (e.g. what's the flag for cvs diff)? $ diff -u /dev/null the_file # could be NUL: on Win32 Or touch(1) the file in the unmodified tree, i.e. create an empty one. D'oh. I forgot I'd had to create an empty signal.c to fix things up on Win32 (signal.h alone wasn't enough). I've attached a patch to add it. Sorry 'bout that, Jonathan signal.c.patch Description: Binary data
[perl #27015] [PATCH classes/parrotobject.pmc] Include Invalid Attribute Name in Exception
# New Ticket Created by chromatic # Please include the string: [perl #27015] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27015 Hi there, This patch made it slightly easier for me to debug errors in my code. It may require tweaking to remove the newline, but these exceptions print much more prettily with it. Enjoy, -- c Index: classes/parrotobject.pmc === RCS file: /cvs/public/parrot/classes/parrotobject.pmc,v retrieving revision 1.17 diff -u -u -r1.17 parrotobject.pmc --- classes/parrotobject.pmc 18 Feb 2004 01:12:53 - 1.17 +++ classes/parrotobject.pmc 22 Feb 2004 07:31:54 - @@ -175,7 +175,8 @@ POD_CLASS); INTVAL idx = VTABLE_get_integer_keyed_str(interpreter, class, attr); if (idx 0) -internal_exception(1, No such attribute); +internal_exception(1, No such attribute: %s\n, +string_to_cstring( interpreter, attr )); return SELF.get_integer_keyed_int(idx); } @@ -228,7 +229,8 @@ POD_CLASS); INTVAL idx = VTABLE_get_integer_keyed_str(interpreter, class, attr); if (idx 0) -internal_exception(1, No such attribute); +internal_exception(1, No such attribute: %s\n, +string_to_cstring( interpreter, attr )); SELF.set_integer_keyed_int(idx, value); } @@ -282,7 +284,8 @@ POD_CLASS); INTVAL idx = VTABLE_get_integer_keyed_str(interpreter, class, attr); if (idx 0) -internal_exception(1, No such attribute); +internal_exception(1, No such attribute: %s\n, +string_to_cstring( interpreter, attr )); return SELF.get_number_keyed_int(idx); } @@ -335,7 +338,8 @@ POD_CLASS); INTVAL idx = VTABLE_get_integer_keyed_str(interpreter, class, attr); if (idx 0) -internal_exception(1, No such attribute); +internal_exception(1, No such attribute: %s\n, +string_to_cstring( interpreter, attr )); SELF.set_number_keyed_int(idx, value); } @@ -388,7 +392,8 @@ POD_CLASS); INTVAL idx = VTABLE_get_integer_keyed_str(interpreter, class, attr); if (idx 0) -internal_exception(1, No such attribute); +internal_exception(1, No such attribute: %s\n, +string_to_cstring( interpreter, attr )); return SELF.get_string_keyed_int(idx); } @@ -441,7 +446,8 @@ POD_CLASS); INTVAL idx = VTABLE_get_integer_keyed_str(interpreter, class, attr); if (idx 0) -internal_exception(1, No such attribute); +internal_exception(1, No such attribute: %s\n, +string_to_cstring( interpreter, attr )); SELF.set_string_keyed_int(idx, value); } @@ -494,7 +500,8 @@ POD_CLASS); INTVAL idx = VTABLE_get_integer_keyed_str(interpreter, class, attr); if (idx 0) -internal_exception(1, No such attribute); +internal_exception(1, No such attribute: %s\n, +string_to_cstring( interpreter, attr )); return SELF.get_pmc_keyed_int(idx); } @@ -547,7 +554,8 @@ POD_CLASS); INTVAL idx = VTABLE_get_integer_keyed_str(interpreter, class, attr); if (idx 0) -internal_exception(1, No such attribute); +internal_exception(1, No such attribute: %s\n, +string_to_cstring( interpreter, attr )); SELF.set_pmc_keyed_int(idx, value); }
[perl #27003] bytecode (header?) problem in tru64/alpha
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #27003] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27003 From a freshly rsynced copy in tru64/alpha (*): $ ./parrot t/native_pbc/integer_1.pbc PackFile_unpack: Not a Parrot PackFile! Parrot VM: Can't unpack packfile t/native_pbc/integer_1.pbc. error:imcc:main: Packfile loading failed The same happens with the number_?.pbc. This is first few lines of hexdump from the integer_1.pbc: 04 00 00 0d 04 00 ac 1d a0 e1 c0 b8 70 2a 58 a0 p*X. a1 55 31 01 4c 52 45 50 01 00 00 00 00 00 00 00 .U1.LREP 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0... 03 00 00 00 04 00 00 00 42 59 54 45 43 4f 44 45 BYTECODE 5f 2d 00 00 20 00 00 00 08 00 00 00 02 00 00 00 _-.. ... 46 49 58 55 50 5f 2d 00 28 00 00 00 08 00 00 00 FIXUP_-.(... 03 00 00 00 43 4f 4e 53 54 41 4e 54 5f 2d 00 00 CONSTANT_-.. and here is myconfig: Summary of my parrot 0.0.13 configuration: configdate='Sun Feb 22 19:50:26 2004' Platform: osname=dec_osf, archname=alpha-dec_osf jitcapable=1, jitarchname=alpha-dec_osf, jitosname=DEC_OSF, jitcpuarch=alpha execcapable=0 perl=/u/vieraat/vieraat/jhi/Perl/Platform/OSF1/bin/perl Compiler: cc='cc', ccflags='-std -D_INTRINSICS -fprm d -ieee -I/p/include -DLANGUAGE_C', Linker and Libraries: ld='ld', ldflags=' -L/p/lib', cc_ldflags='', libs='-lm -lutil' Dynamic Linking: so='.so', ld_shared='-shared -expect_unresolved * -O4 -msym -std -s -L/p/lib', ld_shared_flags='' Types: iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8, ptrsize=8, ptr_alignment=4 byteorder=12345678, nv=double, numvalsize=8, doublesize=8 My longsize is 8, in case that matters. My experience with debugging Parrot is very close to zero so I can't give off-hand much more information than this. (*) To get parrot to compile at all in Tru64, one needs to also remove the struct timespec (re)definition in include/parrot/thread.h (Leo is working on a real probe for the struct). -- Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
Re: [perl #27015] [PATCH classes/parrotobject.pmc] Include Invalid Attribute Name in Exception
At 11:40 AM -0800 2/23/04, chromatic (via RT) wrote: # New Ticket Created by chromatic Hi there, This patch made it slightly easier for me to debug errors in my code. It may require tweaking to remove the newline, but these exceptions print much more prettily with it. Applied, thanks. (Though I'm curious as to how you're getting objects :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH classes/parrotobject.pmc] Include Invalid Attribute Name in Exception
On Mon, 2004-02-23 at 11:50, Dan Sugalski wrote: At 11:40 AM -0800 2/23/04, chromatic (via RT) wrote: This patch made it slightly easier for me to debug errors in my code. It may require tweaking to remove the newline, but these exceptions print much more prettily with it. Applied, thanks. (Though I'm curious as to how you're getting objects :) Not well -- see library/sdl_image.imc. -- c
Re: PDD status
On Sat, 21 Feb 2004, Michael Scott wrote: All that metadata up front in the PDDs is a bit off-putting. I'm thinking of going through all of them and putting it at the end. Any objections? Well, I've just committed the version I posted pretty much as-is, but feel free to make any changes to the layout you think are appropriate. Simon PS Bryan: I've put my name on this as maintainer for now; I hope that's OK.
Re: MANIFEST updates?
On Mon, 23 Feb 2004, Leopold Toetsch wrote: Andrew Dougherty [EMAIL PROTECTED] wrote: No such file: imcc/imclexer.c No such file: imcc/imcparser.c No such file: imcc/imcparser.h No such file: languages/cola/lexer.c No such file: languages/cola/parser.c No such file: languages/cola/parser.h These files are in MANIFEST and in the tree, *but* also in .cvsignore. AFAIK they shouldn't be in .cvsignore. Ah, that would explain it. I updated with rsync --cvs-exclude so rsync excluded the files. Thanks. I suspect you're right, but I won't presume to touch the .cvsignore file myself. Meanwhile, I now know an obvious workaround. -- Andy Dougherty [EMAIL PROTECTED]
[perl #26911] Failing tests on Linux/x86
I sent this a few days ago, but RT doesn't seem to have forwarded it to the list for some reason. Simon -- Forwarded message -- Date: Thu, 19 Feb 2004 15:21:19 -0500 (EST) From: Simon Glover [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Failing tests on Linux/x86 I'm seeing a bunch of tests failing on my dual-processor x86; specifically, I get failures in: t/op/calling,1-2 t/op/lexicals, 3-6 t/op/stacks, 23, 51, 53 t/pmc/array, 6-11 t/pmc/coroutine, 2 t/pmc/dumper,1-5 and then it hangs indefinitely in test 6 in dumper.t The problem appears to be GC related; if I change the line: $args .= ' --gc-debug'if $gc_debug; in t/harness to: $args .= ' --gc-debug'unless $gc_debug; (i.e. I switch gc-debug off), then I only get two failures: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/pmc/timer.t1 256 71 14.29% 2 t/src/hash.t 1 256101 10.00% 6 Since we're not seeing any of these failures in the tinderbox machines, I suspect that the problem is something specific to my setup. I've attached my myconfig file below, as well as the output from perl -V I'm afraid that I don't have a clear idea of when things first started failing, since this is the first time that I've run the test suite for quite some time. Simon -- Summary of my parrot 0.0.13 configuration: configdate='Thu Feb 19 15:03:38 2004' Platform: osname=linux, archname=i686-linux-ld jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/home/scog/local/bin/perl Compiler: cc='gcc', ccflags=' -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread' Dynamic Linking: so='.so', ld_shared='-shared -L/usr/local/lib', ld_shared_flags='' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=4 byteorder=1234, nv=long double, numvalsize=12, doublesize=8 - Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.9-31smp, archname=i686-linux-ld uname='linux nevis 2.4.9-31smp #1 smp tue feb 26 06:55:00 est 2002 i686 unknown ' config_args='' 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=undef use64bitall=undef uselongdouble=define usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2', cppflags='-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.1 2.96-98)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='long double', nvsize=12, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.2.4' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LONG_DOUBLE USE_LARGE_FILES Built under linux Compiled at Aug 3 2002 16:34:41 %ENV: PERL5LIB=/home/scog/local/lib/site_perl/5.8.0 @INC: /home/scog/local/lib/site_perl/5.8.0 /home/scog/local/lib/perl5/5.8.0/i686-linux-ld /home/scog/local/lib/perl5/5.8.0 /home/scog/local/lib/perl5/site_perl/5.8.0/i686-linux-ld /home/scog/local/lib/perl5/site_perl/5.8.0 /home/scog/local/lib/perl5/site_perl .
Re: PDD 11 -- extensions
On Sat, 21 Feb 2004, Mattia Barbon wrote: Il Fri, 20 Feb 2004 16:12:40 -0500 (EST) Simon Glover [EMAIL PROTECTED] ha scritto: Here's a first draft of PDD 11. It's based on a combination of the existing extend.pod and the comments in extend.c, with additional text by yours truly. It should provide a minimal level of documentation for all of the functions currently implemented in extend.c, but it doesn't discuss future additions to the API (other than warning people that there will be some). it was agreed that extension API should use the same names as the rest of Parrot (i.e.: Parrot_String instead of Parrot_STRING, etc.). A patch was submitted but not applied. The rest looks OK. I found the patch (#24817), but it doesn't look like there was agreement on whether or not it should go in, so I'm going to stick with the old names for now. However, a definitive decision from Dan or Leo would be nice. Simon
Re: JIT branches under the Sun
On Mon, Feb 23, 2004 at 11:07:48AM +0100, Leopold Toetsch wrote: Yep. That's a bit complicated. The jit code tries to avoid loading/storing the same register from/to memory. Actually on this, while looking at what jit on i386 would give for this particular loop, just noticed it does quite a lot of these store/loads to memory who are, afaik, useless? (althaugh as I understand they are needed for the general case) 0x0829c5ed jit_func+53: mov$0x2,%ebx 0x0829c5f2 jit_func+58: mov%esi,%esi 0x0829c5f4 jit_func+60: mov%ebx,0x8278c74 0x0829c5fa jit_func+66: mov0x8278c74,%ebx 0x0829c600 jit_func+72: sub$0x1,%ebx 0x0829c606 jit_func+78: test %ebx,%ebx 0x0829c608 jit_func+80: jne0x829c600 jit_func+72 (up here we could just skeep 58 to 66) jit/i386/jit_emit.h implements all the necessary bits. s. jit_emit_jcc, fixup-skip and load_size. Thanks.. was going round in loops ;) I'll go on it as time permits. leo Stéphane
Re: [CVS ci] PLATFORMS
Chromatic [EMAIL PROTECTED] wrote: On Mon, 2004-02-23 at 01:30, Leopold Toetsch wrote: Please help me fill out the blanks by sending or committing patches. Please make sure to have the latest and best Parrot from CVS. I have a platform not listed. Then lets add it. The list is for sure not complete. ... Where should I look for the appropriate information? Create a platform name similar to existing ones. F./myconfig and the output from Configure.pl + test results/skips should provide the information to fill the line :) -- c leo
Re: Tetris
Jens Rieks [EMAIL PROTECTED] wrote: Hi, Am Montag, 23. Februar 2004 17:09 schrieb Leopold Toetsch: WRT feature freeze: I'd say: Starting from Tue, 24th 8.00 GMT no more feature patches *should* go in, *except* objects. can/should go the tetris example go in? If its running yes. I've to admit that I didn't test it. And examples aren't that critical. They aren't really features :) I'am writing documentation at the moment. Converting the example to use parrot objects is my next plan. Great. jens leo
Re: [CVS ci] PLATFORMS
Jonathan Worthington [EMAIL PROTECTED] wrote: Leo, [did try to send off list, but it bounced] Please help me fill out the blanks by sending or committing patches. Please make sure to have the latest and best Parrot from CVS. Earlier today you popped a new file in CVS called PLATFORMS. Unfortunately, there is also a directory there called platforms. I don't have a directory named platforms in parrot root. You seem to be missing the -P switch to cvs update. $ find . -name platforms $ find . -iname platforms ./PLATFORMS Jonathan leo
Re: Tetris
On Mon, Feb 23, 2004 at 08:03:02PM +0100, Leopold Toetsch wrote: Jens Rieks [EMAIL PROTECTED] wrote: Hi, Am Montag, 23. Februar 2004 17:09 schrieb Leopold Toetsch: WRT feature freeze: I'd say: Starting from Tue, 24th 8.00 GMT no more feature patches *should* go in, *except* objects. can/should go the tetris example go in? If its running yes. I've to admit that I didn't test it. And examples aren't that critical. They aren't really features :) If you squint a little you could pretend they're tests :) Tim.
Re: [perl #26911] Failing tests on Linux/x86
Simon Glover [EMAIL PROTECTED] wrote: I sent this a few days ago, but RT doesn't seem to have forwarded it to the list for some reason. Can you cvs update and try again please. GC related bugs should be fixed now. Simon Thanks, leo
Re: JIT branches under the Sun
Stephane Peiry [EMAIL PROTECTED] wrote: On Mon, Feb 23, 2004 at 11:07:48AM +0100, Leopold Toetsch wrote: Yep. That's a bit complicated. The jit code tries to avoid loading/storing the same register from/to memory. Actually on this, while looking at what jit on i386 would give for this particular loop, just noticed it does quite a lot of these store/loads to memory who are, afaik, useless? (althaugh as I understand they are needed for the general case) Yes. The problem are of course branches and branch targets. Before a branch there is a store and on a branch target is a load (the register assignment CPU-reg - Parrot-reg can and will differ in different basic blocks). So there may be unneeded store/load sequences. I tried (with some success) to avoid such sequences with imcc/jit.c, but that is currently unusable due to register renumbering with PCC. 0x0829c5ed jit_func+53: mov$0x2,%ebx 0x0829c5f2 jit_func+58: mov%esi,%esi 0x0829c5f4 jit_func+60: mov%ebx,0x8278c74 0x0829c5fa jit_func+66: mov0x8278c74,%ebx 0x0829c600 jit_func+72: sub$0x1,%ebx 0x0829c606 jit_func+78: test %ebx,%ebx 0x0829c608 jit_func+80: jne0x829c600 jit_func+72 (up here we could just skeep 58 to 66) No. mov %esi, %esi is a nop to align the branch target. And the load on the branch target can't be omitted either (or only if you know that the only brach comes from a place, where registers match. But - the loop itself doesn't do any load/stores so that's fine. Stéphane leo
Re: [CVS ci] PLATFORMS
I have this problem too. cvs [update aborted]: could not chdir to platforms: Not a directory Same problem even if I do a new check out. cvs [checkout aborted]: could not chdir to parrot/platforms: Not a directory There is no local platforms directory, yet CVS wants to go to it, so I assume the problem is coming from the server end. There is still a platforms directory on the server. http://cvs.perl.org/cvsweb/parrot/platforms/ Mike On 23 Feb 2004, at 19:56, Leopold Toetsch wrote: Jonathan Worthington [EMAIL PROTECTED] wrote: Leo, [did try to send off list, but it bounced] Please help me fill out the blanks by sending or committing patches. Please make sure to have the latest and best Parrot from CVS. Earlier today you popped a new file in CVS called PLATFORMS. Unfortunately, there is also a directory there called platforms. I don't have a directory named platforms in parrot root. You seem to be missing the -P switch to cvs update. $ find . -name platforms $ find . -iname platforms ./PLATFORMS Jonathan leo
[perl #27026] [PATCH] Native exec doc
# New Ticket Created by Adam Thomason # Please include the string: [perl #27026] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27026 Attached patch adds user documentation for the native object execution mechanism and fixes up associated bits of the Makefile. There might be minor errors since I'm not very familiar with the internals, so anyone who is may want to make corrections. -- Adam Thomason thomason at xencor.com native_exec.patch Description: Binary data
Re: [perl #26911] Failing tests on Linux/x86
On Mon, 23 Feb 2004, Leopold Toetsch wrote: Simon Glover [EMAIL PROTECTED] wrote: I sent this a few days ago, but RT doesn't seem to have forwarded it to the list for some reason. Can you cvs update and try again please. GC related bugs should be fixed now. I'm still getting the same failures with a fresh checkout. Simon
Re: Objects and time
Leon Brocard wrote: Dan Sugalski sent the following bits through the ether: Objects please! I would second that. I would prefer a cool release to a cool date ;-) Harry Jackson
Re: [perl #25960] [PATCH] COWed stack bug (was IMCC - PerlArray getting trounced)
Leopold Toetsch writes:
Matt Fowles [EMAIL PROTECTED] wrote:
This patch make the problem case submitted by Jeff Clites work. All
tests pass, and his sample has been added to the tests.
struct RegisterChunkBuf* top = stack-top;
if (top-used 1) {
+top-used--;
Thanks for the patch *but*:
That's changing the COWed copy. It does the right thing for the test
case but is still wrong.
As already stated:
- COWed buffers need distinct buffer headers pointing to the same
buffer memory
- unCOWing (regstack_copy_chunk) allocates new buffer memory and
resets the COW flag
I headed in to fix this when I saw some new stuff in there. Has this
been fixed?
Luke
This week's summary delayed
I'm afraid that this week's summary won't be posted until at least Wednesday. Sorry.
Re: [CVS ci] PLATFORMS
my .cvsrc has update -dP, and I still get the same problem with the platforms directory. (OS X) On Monday, February 23, 2004, at 04:50 PM, Michael Scott wrote: I have this problem too. cvs [update aborted]: could not chdir to platforms: Not a directory Same problem even if I do a new check out. cvs [checkout aborted]: could not chdir to parrot/platforms: Not a directory There is no local platforms directory, yet CVS wants to go to it, so I assume the problem is coming from the server end. There is still a platforms directory on the server. http://cvs.perl.org/cvsweb/parrot/platforms/ Mike On 23 Feb 2004, at 19:56, Leopold Toetsch wrote: Jonathan Worthington [EMAIL PROTECTED] wrote: Leo, [did try to send off list, but it bounced] Please help me fill out the blanks by sending or committing patches. Please make sure to have the latest and best Parrot from CVS. Earlier today you popped a new file in CVS called PLATFORMS. Unfortunately, there is also a directory there called platforms. I don't have a directory named platforms in parrot root. You seem to be missing the -P switch to cvs update. $ find . -name platforms $ find . -iname platforms ./PLATFORMS Jonathan leo -- Will Coke Coledawill at coleda dot com
Re: [CVS ci] PLATFORMS
On Mon, 2004-02-23 at 11:00, Leopold Toetsch wrote: ... Where should I look for the appropriate information? Create a platform name similar to existing ones. F./myconfig and the output from Configure.pl + test results/skips should provide the information to fill the line :) I think this is right. I don't see anything which indicates CGoto support, and I'm guessing at thread and signal support since two of the tests ran in each, though the others all skipped. Linux x86 with gcc-3.3.2 also seems to work correctly. -- c Index: PLATFORMS === RCS file: /cvs/public/parrot/PLATFORMS,v retrieving revision 1.2 diff -u -u -r1.2 PLATFORMS --- PLATFORMS 23 Feb 2004 11:43:08 - 1.2 +++ PLATFORMS 24 Feb 2004 01:32:02 - @@ -10,6 +10,7 @@ hpux ?-ia64 irix6.5 Y Y Y/2 +linux-ppc-gcc3.2.3 YY Y Y Y Y linux-x86-gcc2.92.2YYY Y Y Y Y linux-x86-gcc3.3.3 YYY Y Y Y Y linux-x64
