What I'd like is for folks to take the next day or three to think of
the things that they need parrot to do that aren't working or
designed yet, and throw them at the list. (Try against the latest
CVS, just to make sure that it's not gotten done when you weren't
looking) In the mean time I'll work on my list, and we'll get a Big
List 'O Things, throw them into RT, and start digging through them.
This doesn't have to be all big subsystem things--stuff like "get
PDD6 and reality sync'd up" is a perfectly fine ToDo thing.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Object support ! ...
Gopal
--
The difference between insanity and genius is measured by success
This is possibly a big stuff wish list. I'm not sure how many are on the "maybe
never" list.
Apart from the obvious ("moon on a stick", "a pony", "Quantum Larry (writing
the apocolypses in parallel universes in constant time)") I'd like
Exceptions that can be thrown from C
Regression tests for all the ops (even if not all the cases within them)
Regression tests that cause 100% code coverage (that's probably impossible to
ever get to, but it's a number to aim at)
A unified parrot bytecode generation library (probably in C, but with a perl
interface)
The assembler, IMCC and anything else all using the unified bytecode generation
library
No C compiler warnings on a single platform
No C compiler warnings on any platform
ppc linux to pass (copying varargs issue; probably not hard)
JIT to be aware of different sized integers, floats
computed goto core to compile with less resources
all the little languages that have test suites to be built and run as part of
the tinderbox (with a target in the standard makefile to do this)
JIT to be run as part of the tinderbox (I don't think it is currently)
Fleshing out what parrot IO should do. Particularly how it relates to async IO,
event loops, and the perl5.8 IO layer system
A Java bytecode to parrot bytecode translator
Loading dynamic opcode libraries
Foreign opcode translation (at load time or runtime)
A z-code interpreter (based on the two previous items)
Implementation of an existing general purpose scripting language on parrot
(such as Python or Ruby)
I may have forgotten some things :-)
Nicholas Clark
--
INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
> A Java bytecode to parrot bytecode translator
Oh... the horror ... ! ... I wrote the entire JVM loading features
of JILC (now in jilc.sf.net, because the savannah project got removed
from inactivity).. I'm not working on or doing anything similar like the
JILC (more due to being unmentioned on their website, than boredom) .
Having said all that ... It would be good to wait for the Object stuff
to start working before starting with something like this ... I'd think
that having 32 Object registers (or are they going to be special PMCs ?),
and the spillover tactics of imcc can take you there ...
The question here, why would you need it ? ... (other than running Swing).
A real Java compiler is more flexible and a better tool when it comes to
optimized codegeneration ...
Life was too simple when
iload_0
iload_1 became $I0=LOCVAR_I0 + LOCVAR_I1;
iadd
Let's move on a bit before planning this out ... (thankfully mapping 256
opcodes to a sparse set of 4 G opcodes is comparitively easier)...
> What I'd like is for folks to take the next day or three to think of the
> things that they need parrot to do that aren't working or designed yet,
> and throw them at the list.
TODO:
- badly needed: line numbers in packfile (implying PBC extensions)
- run through KNOWN_ISSUES (which I updated not too long ago) and
make this file as short as before my update ;-)
- DOD with optimized parrot compile (mark processor regs) on $arch?
- Design documents e.g. vtable var/value split
I would like to have a docs/architectures.pod with all pecularities of
all todo supported $arch's. Same would be fine for C-compilers.
Enough for now,
leo
> TODO:
> - badly needed: line numbers in packfile (implying PBC extensions)
I have some toughts about PBC file extensions and some half working
code. Unfortunaltly my day time job consumes an enormous amount of
time at the moment. Lets see what i can to this evening.
bye
b.
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
> Leopold Toetsch <l...@toetsch.at> writes:
>
>
>>TODO:
>>- badly needed: line numbers in packfile (implying PBC extensions)
>>
>
> I have some toughts about PBC file extensions and some half working
> code. Unfortunaltly my day time job consumes an enormous amount of
> time at the moment. Lets see what i can to this evening.
No need to get it running today - tomorrow is early enough ;-)
Thanks, would be greate.
> bye
> b.
leo
> This is possibly a big stuff wish list. I'm not sure how many are on the "maybe
> never" list.
I'm a bear of very little brain, errr, a man of few wishes. I wish for:
o objects
o a "make install" which does something sensible
Leon
--
Leon Brocard.............................http://www.astray.com/
scribot.................................http://www.scribot.com/
... You're in a maze of twisty little Java VMs, all different