PERL PERL6 INTERNALS 11 RE RELEASE 0 1 2
Date: Tue, 22 Feb 2005 22:35:14 -0500

Subject: Re: Release 0.1.2 ?
From: will@no-spam (William Coleda)

After some distractions I got back to this today.

After doing the merge and resolving all the conflicts (of which there really weren't that many), I get it to build, and then get a:


0x0002c3b0 in string_index (interpreter=0xd001a0, s=0x3002fd8, idx=0) at src/string.c:747

747 return (INTVAL)CHARSET_GET_CODEPOINT(interpreter, s, idx);

Even with an invocation of "./parrot" (no args).

I'll keep poking at it. Looks like a bootstrapping problem on string initialization.


Leopold Toetsch wrote:

> Will Coleda wrote:
> ..., I can now think about >
>> integrating Dan's string branch into main. I should be able to get this done over the weekend.
>
>
>
> How does it look like?
>
> leo >
>
>


Subject: Re: Release 0.1.2 ?
Date: Wed, 23 Feb 2005 09:37:15 +0100

From: lt@no-spam (Leopold Toetsch)
William Coleda <will@no-spam> wrote:
> After some distractions I got back to this today.

> After doing the merge and resolving all the conflicts (of which there > really weren't that many), I get it to build, and then get a:

Great. So 0.1.2 will be delayed until its in?

> I'll keep poking at it. Looks like a bootstrapping problem on string > initialization.

Are the encoding_init() / chartype_init() lines enabled in string.c:string_init()?

leo

Subject: Re: Release 0.1.2 ?
Date: Wed, 23 Feb 2005 10:49:55 -0500

From: will@no-spam (Will Coleda)
Leopold Toetsch writes:
> William Coleda <will@no-spam> wrote:
>> After some distractions I got back to this today.
> >> After doing the merge and resolving all the conflicts (of which there >> really weren't that many), I get it to build, and then get a:
> > Great. So 0.1.2 will be delayed until its in?

You're the the pumpking - that's your call, not mine.
>> I'll keep poking at it. Looks like a bootstrapping problem on string >> initialization.
> > Are the encoding_init() / chartype_init() lines enabled in > string.c:string_init()? > > leo
No, they weren't. Of course, if I enable them, I get "undefined symbols" during the link phase... a grep through the source doesn't seem to have them defined anywhere. (in the main branch or the integration I'm trying).
Not that it should matter. the backtrace from gdb shows the error occuring earlier in string_init than the encoding_init line. The problem is in the prefix=Parrot_get_runtime_prefix line... which eventually tries to call CHARSET_GET_CODEPOINT on a string with what seems to be a null encoding.
Regards.