Gopal V wrote:
Hi All,
We've been thinking long and hard about Parrot and found that
the spec viz packfile versions , code segmentations, opcodes and virtually everything is changing minute to minute ...
No specs are changing currently, but there is some discussion, how to continue, how to go on - yes. Opcodes are evolving on demand but changes are - with very limited exceptions - upwards compatible.
The changes are 99.9% internal - all (parrot + perl6) tests are running during these changes.
This is of course my POV, parrot tree wise.
So we think it might do good to have a Parrot-dev'r do the
co-ordination duties . What I had in mind was a guy who said to us
"hey folks, the packfile has changed .. refer pod" whenever some
serious change happened.
The problem seems to be, that we (I) don't know, what changes do actually break e.g. C#, but are totally ok for us, because they are termed "internal".
I didn't have a look at C# or other projects which might use parrot till now but if downloading/compiling is cheap (payed ISDN-line related) and there is a test suite, I can include these tests prior to committing non bugfixe like changes.
... As well as review the opcodes needed for C# like some sort of i2f or something and report an RFC for that..
I think Dan is the coordinator here. Though if you can spec your needs towards opcodes or other issues, more people could consider, how to efficiently implement these.
I would like to know if anyone would like to ensure that the
two projects remain in constant communication about standards,
specs and stuff...
As _currently_ I seem to be the one, doing ~80% changes in CVS, I probably should take that part - though I really don't know the demands of your project. I did read the chat summary. I know there should be some more non-PMC scalar data types, you need more packfile sections - but that's currently almost all I know.
So, IMHO a list of features, you'll need for your current dev paths
would be fine. We could coordinate e.g. perl6 feature wishes and C#
demands and lay out next major steps, that will be implemented.
This is a good thing IMHO, because parrot will work for different HLs in an optimized way.
As you seem to use imcc now as the target assemble language, any
thoughts towards this are welcome too.
Also to finish up with a question, how is the perl6 compiler built ?. A brief look at Tree.pm left me wondering ... it looks almost like a manual version of treecc code ,with all the sub's representing operations::names...(just comparing to cscc design, so that we can keep track of changes to both easily....).
I did download treecc and I had a brief look at it. Yes - it looks like this is the tool perl6 might need, for going to be native C compiled. Current thoughts AFAIK are towards a self bootstrapping miniparrot, compiling the perl written perl6 compiler - but as said AFAIK and far future still ... print eval(all(@future_dev_paths)) ~ NL;
Cheers, Gopal
leo
