Re: Languages in the core source tree?
[EMAIL PROTECTED] (Michael G Schwern) writes: [...] > However, the author(s) of each individual interpreter should be > responsible for their own language. Basically, a mini-pumpinking. oh, just to make it clear: Our CVS setup supports just giving someone access to certain directories within a cvs module. -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Languages in the core source tree?
[EMAIL PROTECTED] (Dan Sugalski) writes: > At 07:15 AM 10/22/2001 -0700, Wizard wrote: > > > 1) Do we put them all in the parrot CVS tree > > > >I think it would be good for the languages to be in tree, but I would like > >to have it under a different mechanism for cvs checkout. In other words, the > >default cvs checkout of parrot does NOT check out the languages tree, but a > >separate checkout is required for the languages. > > I'll ask Ask and see what we can do for that. one way to do that would be to make a parrot-languages module and put them in there. Then we can have a 'parrot-full' module that will checkout parrot/ and parrot-languages into parrot/languages/ It can probably be done in two billion other ways, of which some might fit better. But it's 6.20am and my brain's associative search system is only processing about 0.14 ideas per minute. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Languages in the core source tree?
On Sun, Oct 21, 2001 at 12:45:14PM -0400, Dan Sugalski wrote: > Okay, we've now got minimal: > > *) Parrot assembly > *) Perl > *) Python > *) JVM > *) Scheme > *) Jako > *) Ruby? (Do we? I can't remember for sure) > > support for Parrot. This is a cool thing, but it brings up the questions: > > 1) Do we put them all in the parrot CVS tree Yes, most definitely yes. > 2) Do we require them to meet the same levels of quality as the core > interpreter? Sort of. Those little languages represent the closest thing to a practical application we have for Parrot at the moment. More importantly, you don't have to be an assembly programmer to use them. As each new feature of Parrot is added, the little languages quickly make use of them. If they're widely distributed (ie. with Parrot) people can quickly make use of the little languages, seeing just how much they can get away with in such a small space. So Parrot and the interpreters will grow in parallel. This means more people beating on Parrot sooner and with more and more varied sticks. However, the author(s) of each individual interpreter should be responsible for their own language. Basically, a mini-pumpinking. This means they *do* have to stand up to the same standards as Parrot because, essentially, they're acting as very practical test cases. If the mini-Scheme interpreter works on Linux but not on VMS, then it's likely exposed a bug inside Parrot. Whether or not a release should be held up because a given language is broken is up to Simon. So yes, put them in the default Parrot tree. Later on when they've matured they can branch off into seperate projects and go their own way. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Nature is pissed. http://www.unamerican.com/
RE: Languages in the core source tree?
At 07:15 AM 10/22/2001 -0700, Wizard wrote: > > 1) Do we put them all in the parrot CVS tree > >I think it would be good for the languages to be in tree, but I would like >to have it under a different mechanism for cvs checkout. In other words, the >default cvs checkout of parrot does NOT check out the languages tree, but a >separate checkout is required for the languages. I'll ask Ask and see what we can do for that. > > 2) Do we require them to meet the same levels of quality as the core > > interpreter? >At some point they should need to meet same criteria as the parrot. Right >now, I think the priority is parrot and should remain such. I think the >language implementations are just an experiment, and should not be held to >the same criteria (that should be stated somewhere). However, at some >predetermined point, some resources should be redirected to testing and >refining all of the subtrees (including docs). Yeah, I think you're right here. It'll be one thing when we have fully-working ports of other languages to Parrot but for now most of these should be considered interesting tangents. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Languages in the core source tree?
> 1) Do we put them all in the parrot CVS tree I think it would be good for the languages to be in tree, but I would like to have it under a different mechanism for cvs checkout. In other words, the default cvs checkout of parrot does NOT check out the languages tree, but a separate checkout is required for the languages. > 2) Do we require them to meet the same levels of quality as the core > interpreter? At some point they should need to meet same criteria as the parrot. Right now, I think the priority is parrot and should remain such. I think the language implementations are just an experiment, and should not be held to the same criteria (that should be stated somewhere). However, at some predetermined point, some resources should be redirected to testing and refining all of the subtrees (including docs). Grant M.
Languages in the core source tree?
Okay, we've now got minimal: *) Parrot assembly *) Perl *) Python *) JVM *) Scheme *) Jako *) Ruby? (Do we? I can't remember for sure) support for Parrot. This is a cool thing, but it brings up the questions: 1) Do we put them all in the parrot CVS tree 2) Do we require them to meet the same levels of quality as the core interpreter? For the first, I don't mind (I think it's kinda cool, actually) but I worry about the possibility that things will get out of sync or fall unsupported. I do *not* want us to feel that we can't ship, say, Parrot 0.09 because it the Scheme compiler's not working. (For reasons unrelated to parrot, at least... :) For the second, I really do feel that if it's in the source tree it should be subject to the same requirements on patches and submissions that the rest of Parrot is. (And we're working on getting that together a set of guidelines) That means no non-working code, good tests, and sufficient documentation on things. I'd be happy if the parrot kit could either ship with compiler modules & runtime support for lots of non-perl languages or, at the very least, the non-perl languages could each have a single install kit that could be layered on top of parrot. (Of course, the potential for "Well, to install that module requires installing the Ruby, Scheme, and INTERCAL runtimes" coming up, but I'm OK with that...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
