Release 0.1.2 ?
Will Coleda
According to this (which in turn was based on Leo's email to the list), we
were shooting for a release on Monday.
Having just gotten OS X tests passing again, I can now think about
integrating Dan's string branch into main. I should be able to get this done
over the weekend. I have an email out to Dan about what to do following the
grunt work here...
Leo, I know you've checked in new GC code, but it's not enabled by default,
correct?
Also, what about the design-related issues you mentioned (I threw in items
on that ticket that had already been opened, but I think they're all still
open) ?
Finally, do you have any plans for what's next (0.1.3) and when you'd like
to see that cut? I'd like to start planning a few point releases out so we
can start getting a long term implementation plan written out.
Leopold Toetsch
> According to this (which in turn was based on Leo's email to the list), we
> were shooting for a release on Monday.
Well, not exactly. I'm on the German Perl Workshop next week. Release
will be after that.
> Having just gotten OS X tests passing again, I can now think about
> integrating Dan's string branch into main. I should be able to get this done
> over the weekend. I have an email out to Dan about what to do following the
> grunt work here...
Great, thanks.
> Leo, I know you've checked in new GC code, but it's not enabled by default,
> correct?
Yes. It has still too many bugs to enable it by default. But it's in so
folks can have a look at it.
> Also, what about the design-related issues you mentioned
Docu patches are mostly welcome. The current state is still not fully
covered.
> Finally, do you have any plans for what's next (0.1.3) and when you'd like
> to see that cut? I'd like to start planning a few point releases out so we
> can start getting a long term implementation plan written out.
I'm currently writing a rather largish document. It compares target
language implementations (mainly CPython, Perl5, Ruby) by features WRT
parrot under special consideration of interoperbility.
E.g. what happens (or should happen) in Parrot with a source line:
a = b + 2 # $a = $b + 2
The side-effect will be a big TODO list, which just needs some ordering
by priority ;)
leo
Leopold Toetsch
..., 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
William Coleda
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
> 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
Will Coleda
> William Coleda <wi...@coleda.com> 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.