Re: on the long term Configure system

2001-09-12 Thread Simon Cozens
On Tue, Sep 11, 2001 at 04:19:12PM +0300, Jarkko Hietaniemi wrote: P.S. Maybe the long term discussion should take place in perl6-build, to draw fire from the short term? Thanks for thinking about this; it'd probably be a good idea to move to perl6-build. Simon

Re: Parrot coredumps on Solaris 8

2001-09-12 Thread Simon Cozens
On Wed, Sep 12, 2001 at 12:11:35PM +0100, Philip Kendall wrote: test3.pbc is still segfaulting on me though. Yes, it is here too; I've sent some debugging info to Dan and he's having a look at it. I'm trying to take a look at it too. I suspect that CHUNK_BASE isn't doing what it should. Simon

Re: Parrot coredumps on Solaris 8

2001-09-12 Thread H . Merijn Brand
On Wed 12 Sep 2001 13:23, Nicholas Clark [EMAIL PROTECTED] wrote: Can we usefully smoke parrots yet? Or is this something that someone (Schwern?) is working on? [in that as all the world is not a vax^Wx86 it would be useful to smoke on obscure architectures that SIGBUS on unaligned integer

Parrot coredumps on Alpha (Was: Parrot coredumps on Solaris 8)

2001-09-12 Thread Philip Kendall
On Wed, Sep 12, 2001 at 02:54:49PM +0100, Philip Kendall wrote: On Wed, Sep 12, 2001 at 09:45:42AM -0400, Dan Sugalski wrote: At 02:40 PM 9/12/2001 +0100, Philip Kendall wrote: Now works on Solaris and i386, but segfaults at the GRAB_IV call in read_constants_table on my Alpha. Problems

Re: Parrot coredumps on Alpha (Was: Parrot coredumps on Solaris 8)

2001-09-12 Thread Philip Kendall
On Wed, Sep 12, 2001 at 07:21:06PM +0100, Philip Kendall wrote: [Coredumps on Alpha] Quick research reveals the obvious problem: even when IVs are 64 bit, assemble.pl is still 32 bit (as $pack_types{i} is the 32-bit type 'l'). Changing this over to 'q' means I get further, but it's still

[patch] First cut at TODO allow add I4, I4, 3 instead of add_i_ic...

2001-09-12 Thread Gregor N. Purdy
All -- Attached is a diff for assemble.pl that does a somewhat messy job of solving the problem posed in the TODO file. It does it by parsing the root of each opcode when parsing the opcode table and creating a hash with the opcode root and the formal argument types (qualifiers) so that, e.g.

Re: Parrot coredumps on Solaris 8

2001-09-12 Thread Dan Sugalski
At 12:18 PM 9/12/2001 +0100, Simon Cozens wrote: On Wed, Sep 12, 2001 at 12:11:35PM +0100, Philip Kendall wrote: test3.pbc is still segfaulting on me though. Yes, it is here too; I've sent some debugging info to Dan and he's having a look at it. I'm trying to take a look at it too. I suspect

print_n doesn't work?

2001-09-12 Thread Gibbs Tanton - tgibbs
I have done all the trancendental math functions...but I'm having a problem with print_n...I checked out a clean copy of parrot and ran the following program: set_n_nc N1, 1 print_n N1 end and nothing prints out... Can anyone else get this to print out anything...is it just me? Also,

jsr_ic ret support

2001-09-12 Thread Brian Wheeler
This diff adds jsr_ic and ret to the interpreter. I don't know if my way of returning is legal, and I know there's probably issues with 64 bit machines, but it works...and that's the important part :) Right now it only has a depth of 32 and no bounds checking, but its enough to get started.

RE: Parrot coredumps on Solaris 8

2001-09-12 Thread Hong Zhang
Now works on Solaris and i386, but segfaults at the GRAB_IV call in read_constants_table on my Alpha. Problems with the integer-pointer conversions in memory.c? (line 29 is giving me a warning). The line 29 is extremely wrong. It assigns IV to void* without casting. The alignment calculation

RE: print_n doesn't work?

2001-09-12 Thread Gibbs Tanton - tgibbs
Ah, apparently I selected long double for NV which doesn't work correctly...double works fine however. -Original Message- From: Gibbs Tanton - tgibbs To: '[EMAIL PROTECTED]' Sent: 9/12/2001 11:32 PM Subject: print_n doesn't work? I have done all the trancendental math functions...but

Purify Output

2001-09-12 Thread Josh Wilmes
I just ran purify against the current Parrot CVS as of today at 10 AM PDT. Here are the results: jwilmes@jwilmes-sun:/apps/users/jwilmes/devel/parrot$ ./test_prog test.pbc Purify instrumented test_prog (pid 2187 at Wed Sep 12 10:05:34 2001) * Purify 5.2 Solaris 2 (32-bit), Copyright

Re: Parrot coredumps on Alpha (Was: Parrot coredumps on Solaris 8)

2001-09-12 Thread Dan Sugalski
At 10:17 PM 9/12/2001 +0100, Philip Kendall wrote: On Wed, Sep 12, 2001 at 07:21:06PM +0100, Philip Kendall wrote: [Coredumps on Alpha] Quick research reveals the obvious problem: even when IVs are 64 bit, assemble.pl is still 32 bit (as $pack_types{i} is the 32-bit type 'l'). Changing

patches to assembler opcode_table

2001-09-12 Thread Brian Wheeler
The assembler patches: * handle blank lines containing a label * handle constants in decimal,octal, or hex. Opcode table patch (and basic_opcodes.ops): * adds and, or, not, xor, shl, and shr. Builds ok, but coredumps in the interpreter. Any hints on what I did

[new file] .cvsignore to ignore build products

2001-09-12 Thread Gregor N. Purdy
All -- The following .cvsignore file goes in the root parrot source code directory to ignore the build products. Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N.

RE: Parrot coredumps on Solaris 8

2001-09-12 Thread Dan Sugalski
At 09:57 AM 9/12/2001 -0700, Hong Zhang wrote: Now works on Solaris and i386, but segfaults at the GRAB_IV call in read_constants_table on my Alpha. Problems with the integer-pointer conversions in memory.c? (line 29 is giving me a warning). The line 29 is extremely wrong. It assigns IV to

[new file] t/.cvsignore to ignore 'make test' products

2001-09-12 Thread Gregor N. Purdy
All -- The attached t/.cvsignore file will cause cvs to ignore the products of 'make test'. Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy