On Sat, 16 Apr 2005, Sam Ruby wrote:
[I hope you don't mind me putting this back on the list - I would prefer that everybody who is interested can follow along and/or participate]
Kevin Tew wrote:
Sam Ruby wrote:
Hey guys,
I didn't see this until just now.
Kevin Tew wrote:
Sam,
Just wondering what the status is on python/parrot/pirate/pyrate.
These both look outdated. http://www.intertwingly.net/stories/2004/10/05/pyrate.zip http://pirate.versionhost.com/viewcvs.cgi/pirate/
I haven't looked at it for a few months now. I do plan to revisit it enough to get the Pie-thon tests completed by the time of OSCON (in August).
Sam, are you still interested in this?
I had better be:
http://conferences.oreillynet.com/cs/os2005/view/e_sess/6833
So why won't Michal Wallace sign over the copyright?Is there a up to date cvs repo?
http://pirate.tangentcode.com/
Can we get this code checked into the parrot svn repo?
Unfortunately, no. Much of this code is copyright Michal Wallace.
The good news is that the "good stuff" is in the parrot repo already. What is left - a simple translator - can and should, IMHO, be recoded into Perl6 once enough of that is running.
- Sam Ruby
I talked to Michal briefly about this a while back. My impression was that he wanted to sign over the copyright to the Python foundation. Which makes a bit of sense -
Pirate is based on code created by Andrew Kuchling and the copyright on that work already belongs to the Python foundation.
Mostly I think pirate is just a different project from parrot and I don't want to hand over control of which patches to apply, etc. So far, I've never rejected a patch or turned down anyone for cvs access, but I'd like to reserve the right. (Also, Dan and the parrot team had other ideas about how to implement python.)
the goal of having everything run on a single runtime does not necessarily imply that everything has to be owned by a single organization and put into a single repository.
Yes. That was the other main idea. I was hoping that we could leverage the objects that the python team had already created.
Do PMC's still have to be compiled inside the parrot source tree? To me, the problem is that the PMC's are in the parrot tree, not that the compiler isn't in there with it.
Parrot (including the build system) is a moving target. Long term, the answer is no. Short term, the answer is yes.
My own opinions is that Michal thinks too much. ;-)
This is almost certainly true. :)
My impression is that everybody here is reasonable, and if it made sense for further development to be transferred to another organization, then some reasonable arrangement would be made.
I hope this is true, too. :)
Also, I believe that much of the initial work is throwaway work anyway. Build one to throw away, and all that.
I've never really bought that logic. :) It works, and (especially after your last batch of refactorings) the code is pretty clean. I would like to see the emitter code separated out into a builder object though.
Cool I did notice all the python pmcs. By translator I assume you mean a interpreter/compiler to parrot byte code.
At the moment, it is to Python to IMC, but eventually going directly to bytecode would be a good idea.
That's fine with me, as long as parrots imc compiler does the work. :)
Why would you do it in Perl6, why not self hosted in python?
Self hosted in Python is a good idea, once it can be bootstrapped.
I'm not sure what Kevin meant by self hosted but I've been
thinking about this lately, and what we can do today is creating a back-end for the compiler that emits simplified
python code in a way that would give us things like continuations (though with some loss of speed) without the need to duplicate the python library.
Overview of the current process:
1) Leverage python's "compiler" class to convert source to AST 2) Pirate converts AST to IMC 3) Parrot converts IMC to bytecode
I'm thinking of toying around with python and just want to leverage all the previous work.
Excellent. In the meantime, if you are interested in getting commit access to the Pirate repository, I'm confident that that can be arranged.
Sure. Kevin, if you're still interested let me know.
My feeling, for what it is worth, the translator is known to be a solvable problem. Determining the proper mapping of Python semantics to Parrot is the research problem. The overwhelming majority of that work is in getting the PMCs right. Not having to worry about the syntax of python or the conversion to bytecodes allows one to focus on just that aspect of the problem.
You're absolutely right.
I finally had a chance to look into what you've done, both in the compiler and on the PMC: I'm impressed.
To me the main concern is making the PMC's compatable (or at least similar to) python's C API. This is why I originally suggested wrapping the python library. I would like to be able to run things like pygame, numeric, wxpython, and extensions written with pyrex.
I agree with your point about optimizing the objects for parrot. I just still wish we had a generic catch-all wrapper for anything we haven't hand-coded yet.
Looks like I'll start with a translator and some new test cases so they can be contributed copyright free.
Kevin: did you actually do this? There would certainly be a copyright on your contribution, it would just be owned by the perl group instead of the python group. Is that your only reason for wanting to redo all our work? If possible, I'd much rather have you on the pirate team. Can we discuss this?
There also are a fair amount of python test cases in the parrot repository. parrot/languages/python/*/*.t and t/dynclass/python/*.t.
When I last looked, these were not complete. Undoubtably, there is likely to be some minor regressions as I have not kept up with the latest Parrot changes. If past history is any guide, this is not much of a problem.
I ran the tests off the latest parrot from subversion. Only three tests are failing, and they all seem to involve booleans:
set_bool() not implemented in class 'PyBoolean'
That should be easy enough to fix.
Everything else works great.
Cool!
- Sam Ruby
