Front page | perl.perl6.internals |
Postings from October 2002
Re: Looking for a Parrot contact person
Thread Previous
|
Thread Next
From:
Leopold Toetsch
Date:
October 26, 2002 12:28
Subject:
Re: Looking for a Parrot contact person
Message ID:
3DBAEBE2.3090003@toetsch.at
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
Thread Previous
|
Thread Next