Parrot 0.1.0 -- what's left?
Steve Fink
recently, I'd say it's about time to cut another release. What else
would people like to slip in? This is not a freeze announcement yet --
I want to know what people think of the state of things they're
working on first.
As for the version number -- Dan, if it's ok with you, I'd like to
call this 0.1. Leo's got some form of exceptions in, which was the
stated gate to 0.1, and with the EXEC stuff and a real live Python
port, it seems to me that it's more than earned the name.
Luke Palmer
I'd like to see the object stuff finished up. But, I don't really know
what's planned, so I don't know how big a statement this is.
Exceptions, objects, exec core -- sounds like 0.1 to me.
Luke
Leopold Toetsch
> I want to know what people think of the state of things they're
> working on first.
PCC is still missing the return convention stuff (and unifying call and
return convention)
PackFile is in flux, but this need a lot more anyway.
> As for the version number -- Dan, if it's ok with you, I'd like to
> call this 0.1. Leo's got some form of exceptions in, which was the
> stated gate to 0.1, and with the EXEC stuff and a real live Python
> port, it seems to me that it's more than earned the name.
0.1.0 sounds right for me.
leo
Benjamin Goldberg
Here's some suggestions, not for 0.1, but for 0.2 :)
Finish objects. Add a vtable isa method?
Document somewhere the difference between set_pmc and clone. (Leo says
that it's shallow vs deep copy. Ok, but which is which? :))
Allow .macro in imcc, for when we're parsing pir code.
Macro-ize the stub functions in default.pmc, so that throwing an
exception takes one line of C code.
Profiling and coverage tools.
Get more functions which explicitly declare "ParrotInterpreter *
interpreter" to use the INTERP macro.
Recategorize various set/assign/clone ops to alias/mutate/create.
A new macro, INTERP_as_arg (or INTERPa, or...) which would currently
just be defined as "interpreter", and gradually change calls to
functions which take an interpreter as thier first argument to use this
macro. This way, if in the future, we want to change the "INTERP" macro
to be "ParrotInterpreter * interpreter, struct gc_frame * frame", we can
prevent most breakage simply be changing INTERPa to "interpreter,
frame".
String stuff. (See my other post).
Allow imcc to generate C code (a la pbc2c.pl, but one subroutine at a
time, so as not to overload gcc/whatever's optomizer.)
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Leopold Toetsch
> Allow .macro in imcc, for when we're parsing pir code.
This is already enabled.
> Macro-ize the stub functions in default.pmc, so that throwing an
> exception takes one line of C code.
Yep. And autogenerate these from vtable.tbl if default.pmc has no
implementation. This makes it easy to add or remove vtable methods.
> Get more functions which explicitly declare "ParrotInterpreter *
> interpreter" to use the INTERP macro.
Some unification would be fine, yes. And:
s/ParrotInterpreter/ParrotInterp/
> Allow imcc to generate C code (a la pbc2c.pl, but one subroutine at a
> time, so as not to overload gcc/whatever's optomizer.)
That's mainly 2 things: 1) include the opcode bodies in op_lib. 2)
Replace encoded operands with the actual things. Having e.g. C<pcre> in
the core would probably simplify this kind of string fiddling a lot.
leo