Re: setline?
Michal Wallace [EMAIL PROTECTED] wrote: Sorry, I've been following this list with one eye tied behind my back... What happened to setline? Should I emit something else instead? Both Csetline and Csetfile are parsed and swallowed in the lexer. The data will finally end in an HLL debug PBC segment. Sincerely, Michal J Wallace leo
Re: Loading up bytecode segments
Dan Sugalski [EMAIL PROTECTED] wrote: On Wed, 24 Sep 2003, Leopold Toetsch wrote: .pcc_sub symbols automatically get entered into the global stash. We need to get some of this moved down into the base assembler as well. Done. $ perldoc /docs/pmc/sub.pod Dan leo
[perl #24043] [PATCH] Getting ICU to build on OS X
# New Ticket Created by Michael Scott # Please include the string: [perl #24043] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24043 This patch gets ICU to build on Mac OS X. It works around a gcc -E -MMD bug. -- attachment 1 -- url: http://rt.perl.org/rt2/attach/65328/48724/2c2ce5/mh-darwin.patch mh-darwin.patch Description: mh-darwin.patch
Re: Pondering argument passing
Dan Sugalski [EMAIL PROTECTED] wrote: [ splatted function args ] ... For this, I think we're going to need a setp Ix, Py op which does indirect register addressing. Done. I named it Csetp_ind though, to more clearly discern it from Cset. .flatten_arg _AV_x is implemented too. Checking for overflow in the sub needs still to be done. Dan leo
Re: [perl #24030] [PATCH] hash.t fails on OS X
On Friday, Sep 26, 2003, at 13:04 Europe/Berlin, Jeff Clites wrote:
I did a bit more digging on this test failure, and I think it's an
infant mortality case--it looks like creating the large string might
be triggering a DOD run which is freeing the hash. Just dumping the
hash before and after creating the string demonstrates (by crashing
during the second dump):
big = calloc(BIGLEN, sizeof(char));
big = memset(big, 'x', BIGLEN - 1);
new_hash(interpreter, hash);
dump_hash(interpreter, hash);
key = string_from_cstring(interpreter, big, NULL);
dump_hash(interpreter, hash);
Output:
Hashtable[0/16] Bucket 16: type(0) - type(0) - type(0) - type(0)
- type(0) - type(0) - type(0) - type(0) - type(0) - type(0) -
type(0) - type(0)
Hashtable[0/16] Bucket 16: type(524288) - Segmentation fault
If I allocate the string before creating the hash, the test passes.
hash_t.patch
Description: Binary data
What's the preferred way to prevent this in tests? I know there are
various approaches possible, but I don't know if there is a consensus
for how to deal with this in test cases--disabling DOD works but seems
a bit heavy handed.
This reminds me of those help-yourself hotel breakfasts where overeager
staff whisk your cup away as soon as they see it empty. If you're
planning on having seconds and want to keep the same cup, then you've
got to keep your eye on it.
Disabling empty cup collection - i.e. a big sign saying Don't take my
cup! - may seem a bit heavy handed, but it does have the advantage of
being explicit.
JEff
On Thursday, September 25, 2003, at 09:23 AM, Jeff Clites wrote:
Hi:
In case it helps, it looks like it's crashing at string.c:552,
because it's trying to call src-encoding-decode() but src-encoding
is NULL.
(gdb) f 0
#0 0x6104 in string_transcode (interpreter=0x616400,
src=0x623440, encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at
string.c:552
552 UINTVAL c = src-encoding-decode(srcstart);
(gdb) l
547 srcend = srcstart + src-bufused;
548 deststart = dest-strstart;
549 destend = deststart;
550
551 while (srcstart srcend) {
552 UINTVAL c = src-encoding-decode(srcstart);
553
554 if (transcoder1)
555 c = transcoder1(src-type, dest-type, c);
556 if (transcoder2)
(gdb) p encoding
$1 = (const struct parrot_encoding_t *) 0x19e43c
(gdb) p src
$2 = (struct parrot_string_t *) 0x623440
(gdb) p src-encoding
$3 = (const struct parrot_encoding_t *) 0x0
Here's another backtrace, with a little more info:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x6104 in string_transcode (interpreter=0x616400, src=0x623440,
encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at string.c:552
552 UINTVAL c = src-encoding-decode(srcstart);
(gdb) bt
#0 0x6104 in string_transcode (interpreter=0x616400,
src=0x623440, encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at
string.c:552
#1 0x6fbc in string_compare (interpreter=0x616400, s1=0x625cd8,
s2=0x623440) at string.c:949
#2 0x45b0 in find_bucket (interpreter=0x616400, hash=0x6223e0,
head=0, key=0x6816b0) at hash.c:281
#3 0x4a4c in hash_put (interpreter=0x616400, hash=0x6223e0,
key=0x6816b0, value=0xbb50) at hash.c:406
#4 0x2b5c in main (argc=1, argv=0xbc2c) at CrashingTest.c:36
#5 0x27f8 in _start (argc=1, argv=0xbc2c, envp=0xbc34)
at /SourceCache/Csu/Csu-45/crt.c:267
#6 0x2678 in start ()
JEff
On Thursday, September 25, 2003, at 08:22 AM, Michael Scott wrote:
On Thursday, Sep 25, 2003, at 16:06 Europe/Berlin, Michael Scott
wrote:
On Thursday, Sep 25, 2003, at 13:20 Europe/Berlin, Leopold Toetsch
wrote:
Michael Scott [EMAIL PROTECTED] wrote:
t/src/hash.t
test 7 fails on Mac OS X 10.2.6 (gcc 3.3) because BIGLEN is too
big:
9.
100_000 chars for the key doesn't seem to be very big.
Wher does it fail?
Can you debug/back-trace it?
(gdb) r
Starting program: /Users/mike/Developer/Parrot/Tests/mem_test
Reading symbols for shared libraries . done
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x5f30 in string_transcode ()
(gdb) bt
#0 0x5f30 in string_transcode ()
#1 0x6de8 in string_compare ()
#2 0x43e4 in find_bucket ()
#3 0x4880 in hash_put ()
#4 0x2998 in main ()
#5 0x25a4 in _start (argc=1, argv=0xbdd4, envp=0xbddc)
at /SourceCache/Csu/Csu-45/crt.c:267
#6 0x2424 in start ()
And just as I was going to get started on t/src/string.t too.
I'm running tests on string_compare and string_transcode with
999 byte strings without complaint.
I've made it a bit smaller: 65536.
This begs the questions:
What is the maximum hash key size?
What is the largest STRING?
There are no limits except those imposed by UINTVAL (2^32-1) AFAIK.
Mike
leo
Re: [perl #24030] [PATCH] hash.t fails on OS X
On Fri, 26 Sep 2003, Leopold Toetsch wrote: Jeff Clites [EMAIL PROTECTED] wrote: What's the preferred way to prevent this in tests? I have put now the test in its own sub. So it should be sure that interpreter-lo_var_ptr (the stack limit for trace_system_stack) is above the auto _hash variable. Another possibility is to use the scheme I implemented in t/src/basic_3. This needs some polishing thow - but it works :-) We might need to shift to this scheme--whatever went in to fix the test caused it to fail on all the tinderboxes this morning. Tinders, for the curious, are at http://tinderbox.perl.org/tinderbox/bdshowbuild.cgi?tree=parrot and we've finally got a reasonably reliable mix of systems running the code. (Though I don't, as yet, have a native Windows w/VS/.NET building parrot right, just the cygwin version) Dan
Re: cvs commit: parrot/t/src basic.t
On 26 Sep 2003, Leopold Toetsch wrote: Index: interpreter.h +typedef opcode_t *(*native_func_t)(struct Parrot_Interp * interpreter, + opcode_t * cur_opcode, + opcode_t * start_code); + This bit's made gcc a very unhappy piece of software... Dan
[PATCH] C code test header
Given Leo's new scheme for C code tests, I suggest that we add a header
to be included in the test, and modify Parrot::Test so that it knows to
add the header's location to the command.
This patch puts the header in parrot/t/c_test_header.h.
The correct scheme for a C test can now be:
c_output_is('CODE', 'OUTPUT', C code test);
#include c_test_header.h
int do_test(Interp *interpreter)
{
...
}
CODE
...
OUTPUT
c_test_header.h
Description: application/applefile
#include stdio.h
#include parrot/parrot.h
#include parrot/embed.h
int do_test(Interp *interpreter);
int main(int argc, char* argv[]) {
Interp* interpreter;
interpreter = Parrot_new();
if ( interpreter == NULL ) return 1;
interpreter-lo_var_ptr = interpreter;
Parrot_init(interpreter);
return do_test(interpreter);
}
Test.pm
Description: application/text
Re: cvs commit: parrot/t/src basic.t
Dan Sugalski [EMAIL PROTECTED] wrote: On 26 Sep 2003, Leopold Toetsch wrote: Index: interpreter.h +typedef opcode_t *(*native_func_t)(struct Parrot_Interp * interpreter, + opcode_t * cur_opcode, + opcode_t * start_code); + This bit's made gcc a very unhappy piece of software... Dunno why, mine is happy. Anyway I have moved include config.h into interpreter. Hope that helps. Dan leo
Re: cvs commit: parrot/t/src basic.t
On Fri, 26 Sep 2003, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: On 26 Sep 2003, Leopold Toetsch wrote: Index: interpreter.h +typedef opcode_t *(*native_func_t)(struct Parrot_Interp * interpreter, + opcode_t * cur_opcode, + opcode_t * start_code); + This bit's made gcc a very unhappy piece of software... Dunno why, mine is happy. Anyway I have moved include config.h into interpreter. Hope that helps. A the point that this typedef was in, opcode_t hadn't been defined. I moved it, and installed an alternate version for non-core enbed includes, though I'm not sure that's the right thing to do. (I'm not sure Parrot_run_native should be in the embedding interface mainly) Anyway, current CVS builds and tests OK again. Dan
Re: cvs commit: parrot pmc.c
Dan Sugalski [EMAIL PROTECTED] wrote: More MMD default functions, and make things compile properly [ snip ] +INTVAL cmp_val; ... until gcc (3) gets hit by this :-) leo
Re: cvs commit: parrot pmc.c
On Fri, 26 Sep 2003, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: More MMD default functions, and make things compile properly [ snip ] +INTVAL cmp_val; ... until gcc (3) gets hit by this :-) Ah, damn excessively permissive compilers... fixed. :) Dan
Re: cvs commit: parrot/t/src basic.t
Dan Sugalski [EMAIL PROTECTED] wrote: A the point that this typedef was in, opcode_t hadn't been defined. Yes. But what makes me wonder is, why my gcc 2.95.2 compiled that alltogether. Maybe ccache messed it up. ... I moved it, and installed an alternate version for non-core enbed includes, Thanks. I wanted to do a similar change, but you were faster :) though I'm not sure that's the right thing to do. (I'm not sure Parrot_run_native should be in the embedding interface mainly) I don't know either. But these src tests are currently using embed.h and they are embedding parrot, so it seemed natural to me, to include Parrot_runt_native() in the embedding interface. This functions should be a clean way to run a C function at the same level as its done from the run loop level. Dan leo
Re: CVS checkout hints for the bandwidth-limited
Dan Sugalski [EMAIL PROTECTED] wrote:
cvs -z9 update
cvs -z9 update -dP parrot
to get rid of deleted files too. Filtering the output through a small
script, that just does something like:
if ($_ !~ /^cvs server: Updating/) {
print $_;
}
helps to unclutter update results.
... so if
you're on dialup or slow DSL
Hah. I really wished to have some slow DSL. I'm living here at the
countryside far? away from civilization, where these telco NULs say
that's not possible/worth to offer some fatter lines then ISDN (that's
64 Kbit).
Dan
leo
[perl #24053] [PATCH] pmc2c.pl problem with compiling a dynclass
# New Ticket Created by James Rouzier # Please include the string: [perl #24053] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24053 When you run pmc2c.pl on a class that is a dynpmc the resulting c code will not compile because of incompatable type assignment. The problem was a dereference of the Parrot_base_vtables[info-class_enum] when being assigned to info-base_vtable[info-class_enum] I removed the * and it compiles and runs fine. -- James Jude Rouzier [EMAIL PROTECTED] http://theotherside.com/ -- -- attachment 1 -- url: http://rt.perl.org/rt2/attach/65363/48757/3be208/pmc2c.patch Index: pmc2c.pl === RCS file: /cvs/public/parrot/classes/pmc2c.pl,v retrieving revision 1.43 diff -u -r1.43 pmc2c.pl --- pmc2c.pl23 Sep 2003 10:50:27 - 1.43 +++ pmc2c.pl26 Sep 2003 22:53:47 - @@ -850,7 +850,7 @@ info-class_enum; /* copy vtable back to caller */ info-base_vtable[info-class_enum] = - *Parrot_base_vtables[info-class_enum]; + Parrot_base_vtables[info-class_enum]; } return ok; case DYNEXT_INIT_PMC:
Re: CVS checkout hints for the bandwidth-limited
On Sep-26, Leopold Toetsch wrote:
Filtering the output through a small
script, that just does something like:
if ($_ !~ /^cvs server: Updating/) {
print $_;
}
helps to unclutter update results.
cvs -q will suppress those lines for you.
Re: cvs commit: parrot/t/src basic.t
At 8:42 PM +0200 9/26/03, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: A the point that this typedef was in, opcode_t hadn't been defined. Yes. But what makes me wonder is, why my gcc 2.95.2 compiled that alltogether. Maybe ccache messed it up. It's GCC. I expect it to behave oddly, and differently depending on version. :) though I'm not sure that's the right thing to do. (I'm not sure Parrot_run_native should be in the embedding interface mainly) I don't know either. But these src tests are currently using embed.h and they are embedding parrot, so it seemed natural to me, to include Parrot_runt_native() in the embedding interface. This functions should be a clean way to run a C function at the same level as its done from the run loop level. It's a good place for now. I'm not sure it's a good long-term place, but we'll worry about that later. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #24053] [PATCH] pmc2c.pl problem with compiling a dynclass
At 11:30 PM + 9/26/03, James Rouzier (via RT) wrote: When you run pmc2c.pl on a class that is a dynpmc the resulting c code will not compile because of incompatable type assignment. The problem was a dereference of the Parrot_base_vtables[info-class_enum] when being assigned to info-base_vtable[info-class_enum] I removed the * and it compiles and runs fine. Applied, thanks. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
