Re: Looking for a Parrot contact person

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

• Looking for a Parrot contact person by Gopal V
• Re: Looking for a Parrot contact person by Leopold Toetsch
• Re: Looking for a Parrot contact person by Gopal V
• Re: Looking for a Parrot contact person by Leopold Toetsch