Lots of warnings and errors (Win32)
>> parrot\mmd.c(32) : warning C4098: 'mmd_dispatch_pmc' : 'void' function returning a value void /* Shouldn't this be PMC * instead? */ mmd_dispatch_pmc(struct Parrot_Interp *interpreter, PMC *left, PMC *right, PMC *dest, INTVAL function) >> parrot\encoding.c(37) : warning C4090: 'function' : different 'const' Couldn't figure out the problem here.. >> float.c(196) : warning C4113: 'void (__cdecl *)(Parrot_Interp *,PMC *,PMC *,PMC*)' differs in parameter lists from 'is_equal_method_t' >> float.c(196) : warning C4133: 'initializing' : incompatible types - from 'void (__cdecl *)(Parrot_Interp *,PMC *,PMC *,PMC *)' to 'is_equal_method_t' >> float.c(200) : warning C4113: 'void (__cdecl *)(Parrot_Interp *,PMC *,PMC *,PMC*)' differs in parameter lists from 'cmp_method_t' >> float.c(200) : warning C4133: 'initializing' : incompatible types - from 'void (__cdecl *)(Parrot_Interp *,PMC *,PMC *,PMC *)' to 'cmp_method_t' Since this file is auto-generated, I was a bit unsure as to where the problem lies.. something to do with the first warning maybe? Got the same warnings in integer.c and mmd_default.c, as well. Looks like the source is mmd_default.pmc then. >> LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification Link warnings/errors make my brain hurt.. I'd love to submit a patch for at least one of these.. but I'm still working on figuring that out. As well, should I submit stuff like this somewhere else, not here?
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
Re: CVS checkout hints for the bandwidth-limited
At 8:54 PM +0200 9/26/03, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: cvs -z9 update cvs -z9 update -dP parrot to get rid of deleted files too. Which is a good point, and one I forgot. (Which is annoying, as it's how I update) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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 #24043] [PATCH] Getting ICU to build on OS X
At 9:29 AM + 9/26/03, Michael Scott (via RT) wrote: This patch gets ICU to build on Mac OS X. It works around a gcc -E -MMD bug. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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.
[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. # 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
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
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
CVS checkout hints for the bandwidth-limited
Just a reminder to everyone (especially now that we've updated ICU so there's a lot of data to sync with) you can tell CVS to use a compressed channel for its data. For mostly-text (like, say, ICU's source) this works pretty well. Just add the -zN flag to the CVS line, where N is a number between 1 and 9. (Higher means more compression, though that takes more CPU tume) For example, to update your local parrot version, just issue the command cvs -z9 update and let the data stream on down. This'll cut down on the amount of data that's transmitted by rather a lot (factor of two or three, IIRC) so if you're on dialup or slow DSL it'll make your life much nicer. Dan
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 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/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/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
[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
#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
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
Lightweight Languages 2003 Call for Presentations
Lightweight Languages Worshop 2003 (LL3) -- Saturday, November 8, 2003, MIT, Cambridge, MA http://ll3.ai.mit.edu/ mailto:[EMAIL PROTECTED] CALL FOR PRESENTATIONS LL3 will be an intense, exciting, one-day forum bringing together the best programming language implementors and researchers, from both academia and industry, to exchange ideas and information, to challenge one another, and to learn from one another. The workshop series focuses on programming languages, tools, and processes that are usable and useful. Lightweight languages have been an effective vehicle for introducing new features to mainstream programmers. We encourage presentations on topics of interest to the community of lightweight language users and designers. We prefer topics that will interest a broad audience. We do not require the presentation of novel research ideas. Proposal Abstracts -- Due Friday Oct. 17 We seek two to five page abstracts of talks to be given at the workshop. Talks will be 30 minutes long, including time for questions and answers. Presenters are not expected to submit papers, but slides will be published on the workshop web site. We will also consider proposals for talks of different lengths. Some suggested topics are: * Language design: New language features, type systems and other reasoning tools, critiques of existing languages. * Implementation techniques: Interpreters and virtual machines, optimizations, cross-language interactions. * From scripts to programs: Software engineering with lightweight and/or a mix of languages. How to (or not to!) scale from little scripts to large, complex applications. Application war stories. * From ivory tower to cubicle -- what language implementors need to know from academic programming languages research -- and back. * Lightweight pearls: Elegant and instructive examples of programs in lightweight languages. * Programming tools and development processes. Send submissions to: [EMAIL PROTECTED] We want presentations that will inspire, motivate, and educate. We want language implementors and researchers to leave the workshop fired up with ideas for future languages, features, and implementation tricks. We want language users to leave the workshop fired up with new ideas and new tools. In addition to submitted presentations, there will be two invited talks. After the workshop, there will be an evening social event and dinner. Dates: Tuesday, Oct. 17 -- submissions due by end of day. Tuesday, Oct. 24 -- notification of acceptance or rejection Saturday, Nov. 8 -- 9am-7pm, LL3! Program Committee: Ken Anderson, BBN (co-chair) Jeremy Hylton, Python Software Foundation (co-chair) Geoffrey Knauth, BAE Systems Shriram Krishnamurthi, Brown University Erik Meijer, Microsoft Research Dan Sugalski, Perl Foundation Greg Sullivan, MIT CSAIL
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: [perl #24030] [PATCH] hash.t fails on OS X
Jeff Clites <[EMAIL PROTECTED]> 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): Thanks for investigating it. > 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 :-) > JEff leo
Re: Pondering argument passing
On Fri, 26 Sep 2003, Leopold Toetsch wrote: > 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 C though, to more clearly discern it from C. Thanks. I admit I still have an urge towards a more compact notation--something like "set P[I4], P5"--but it's probably best to forbear. (Though I expect we'll end up wishing we did it differently later, in which case someone can write a Parrot macro assembler with a different syntax :) > .flatten_arg _AV_x is implemented too. Cool. More notes for the next draft of p6ee... Dan
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
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
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.
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: 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 C though, to more clearly discern it from C. .flatten_arg _AV_x is implemented too. Checking for overflow in the sub needs still to be done. > 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. # 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: 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
