Hi everyone,
Please tell us where you're from, what languages you like, what platforms you work with or can test with, and how much you think you'd be able to help.
To get started, read here:
http://confluence.immuexa.com/display/sq/Development
-------------------- m2f --------------------
(from forum) http://squeakland.org/forums/viewtopic.php?p=9503#9503
-------------------- m2f --------------------
Hello everyone, I'm a software developer and Lotus expatriate who worked on several of the administration features in Notes and Domino R5. I left Lotus in 1998 to start Immuexa Corporation, makers of custom-built software and websites. We made the new squeakland.org website for Viewpoints.
In 2007, I founded Waveplace Foundation, an organization that raises money to purchase laptops for children, creates Etoys training materials, and inspires teachers to use computers in new ways.
Since January, I've been heading up the effort to create Squeakland Foundation, with the generous support and guidance of Viewpoints Research.
-------------------- m2f --------------------
(from forum) http://squeakland.org/forums/viewtopic.php?p=9504#9504
-------------------- m2f --------------------
On Fri, Jul 10, 2009 at 8:36 AM, teefaletoys-dev-forum@squeakland.org wrote:
Hi everyone,
Please tell us where you're from, what languages you like, what platforms you work with or can test with, and how much you think you'd be able to help.
o Cupertino, in Silicon Valley
o APL, LISP/Scheme, FORTH, Python, Befunge :), Unlambda :) :), Smalltalk...
o I can run Linux images in Virtualbox, and I have a spare Mac.
o Alan and I are trying to get a Free Digital Learning Materials project going. I am creating math lessons in Turtle Art right now, and will move some of them into Smalltalk. I am recruiting others to do more such work. At some point, we will build Smalltalk tools for building DLMs and lesson plans.
o I am also talking with Allison Randal, head of the Parrot project, about various projects. She told me that she would love to have a Squeak for Parrot. (Right now, they only have their toy language Squaak. No relation. ^_^). This means compiling the Smalltalk VM for Parrot. But that means getting a C compiler to generate Parrot assembler. I don't know how far along that project is.
http://www.parrot.org/languages # c99 — An implementation of C programming language, C99 dialect https://trac.parrot.org/languages/browser/c99/trunk
After we have a functioning version, we should investigate whether any Smalltalk VM features can be replaced by or integrated with Parrot features. Parrot provides garbage collection, concurrency, hooks for an object class system, and an assortment of other high-level features, and is intended to allow dynamic languages to run unchanged on more than 200 hardware/OS combinations.
To get started, read here:
Edward,
Sorry for replying to an introduction email but...
At Fri, 10 Jul 2009 11:34:33 -0700, Edward Cherlin wrote:
o I am also talking with Allison Randal, head of the Parrot project, about various projects. She told me that she would love to have a Squeak for Parrot. (Right now, they only have their toy language Squaak. No relation. ^_^). This means compiling the Smalltalk VM for Parrot. But that means getting a C compiler to generate Parrot assembler. I don't know how far along that project is.
Hmm... Why not compile Smalltalk to Parrot bytecode?
But, however, the real strength of Squeak for us has been that the same program runs pixel-identically on various platforms; so that a developer who doesn't want to deal with Linux or Sugar can have reasonable assumptions of his program when developing on other platforms.
This is because Squeak VM provides all graphics and user input and socket and etc (in addition to garbage collection, concurrency, a meta system). (Yeah, a virtual machine should be a machine just happens to be a virtual one; so not just instruction emulation, it should provide such things).
Parrot doesn't offer such abstraction, as far as I can tell. If we are to provide a such layer, we need to write platform specific implementations for these features (as Squeak VM does) and that would mean that we need to re-do whole a lot of work just to be at the same place.
If this was about implementing the Squeak VM on Flash, that would have made more sense.
After we have a functioning version, we should investigate whether any Smalltalk VM features can be replaced by or integrated with Parrot features. Parrot provides garbage collection, concurrency, hooks for an object class system, and an assortment of other high-level features, and is intended to allow dynamic languages to run unchanged on more than 200 hardware/OS combinations.
Wow. Is there the list of these 200 combinations? I'd be happy to be surprised, but I have a feeling that Squeak VM has a bigger list...
-- Yoshiki
On Sat, Jul 11, 2009 at 11:03 PM, Yoshiki Ohshimayoshiki@vpri.org wrote:
Edward,
Sorry for replying to an introduction email but...
No, I meant for people to comment.
At Fri, 10 Jul 2009 11:34:33 -0700, Edward Cherlin wrote:
o I am also talking with Allison Randal, head of the Parrot project, about various projects. She told me that she would love to have a Squeak for Parrot. (Right now, they only have their toy language Squaak. No relation. ^_^). This means compiling the Smalltalk VM for Parrot. But that means getting a C compiler to generate Parrot assembler. I don't know how far along that project is.
Hmm... Why not compile Smalltalk to Parrot bytecode?
Is there a difference? Actually, I may be wrong. It may be that the C compiler will generate PIR, Pirate Intermediate Representation. But that doesn't matter, since it all ends up as byte code.
If you think it would work better to have Smalltalk translate the Smalltalk VM to PIR rather than to C, that's fine, too. But the PIR compiler includes register optimization, which I don't think you want to rewrite.
But, however, the real strength of Squeak for us has been that the same program runs pixel-identically on various platforms; so that a developer who doesn't want to deal with Linux or Sugar can have reasonable assumptions of his program when developing on other platforms.
Fine. That's what I meant for you to do. Compile the existing C version of the VM, just as for any other processor.
This is because Squeak VM provides all graphics and user input and socket and etc (in addition to garbage collection, concurrency, a meta system). (Yeah, a virtual machine should be a machine just happens to be a virtual one; so not just instruction emulation, it should provide such things).
Parrot doesn't offer such abstraction, as far as I can tell. If we are to provide a such layer, we need to write platform specific implementations for these features (as Squeak VM does) and that would mean that we need to re-do whole a lot of work just to be at the same place.
You are getting ahead of yourself. I said to compile the existing VM. Reimplementing is below, and only if it turns out to make sense.
If this was about implementing the Squeak VM on Flash, that would have made more sense.
After we have a functioning version, we should investigate whether any Smalltalk VM features can be replaced by or integrated with Parrot features. Parrot provides garbage collection, concurrency, hooks for an object class system, and an assortment of other high-level features,
OK, here is where we can consider a rewrite.
and is intended to allow dynamic languages to run unchanged on more than 200 hardware/OS combinations.
Wow. Is there the list of these 200 combinations? I'd be happy to be surprised, but I have a feeling that Squeak VM has a bigger list...
Intended, Yoshiki, not implemented. Current targets are Linux x86 and ARM, Mac x86 and ppc, and Windows x86. Others will be done by whoever wants them badly enough.
The question is not whose is bigger. The question is whether it is worthwhile having an environment in which multiple dynamic languages with or without object class systems can interoperate safely.
-- Yoshiki
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
At Sat, 11 Jul 2009 23:47:26 -0700, Edward Cherlin wrote:
On Sat, Jul 11, 2009 at 11:03 PM, Yoshiki Ohshimayoshiki@vpri.org wrote:
Edward,
Sorry for replying to an introduction email but...
No, I meant for people to comment.
At Fri, 10 Jul 2009 11:34:33 -0700, Edward Cherlin wrote:
o I am also talking with Allison Randal, head of the Parrot project, about various projects. She told me that she would love to have a Squeak for Parrot. (Right now, they only have their toy language Squaak. No relation. ^_^). This means compiling the Smalltalk VM for Parrot. But that means getting a C compiler to generate Parrot assembler. I don't know how far along that project is.
Hmm... Why not compile Smalltalk to Parrot bytecode?
Is there a difference? Actually, I may be wrong. It may be that the C compiler will generate PIR, Pirate Intermediate Representation. But that doesn't matter, since it all ends up as byte code.
If you think it would work better to have Smalltalk translate the Smalltalk VM to PIR rather than to C, that's fine, too. But the PIR compiler includes register optimization, which I don't think you want to rewrite.
The difference I have in my mind is whether there would be two interpretation layer or one interpretation layer.
Now, I wonder if you use "Smalltalk VM" in a different sense. I wasn't saying what the compilation target should be. Sure, it can be to PIR or bytecode. What I was saying was what to compile; it should be user Smalltalk code and not the VM. You may be referring to the fact that the Squeak VM is written in Squeak; but it goes through the C compiler and produces somewhat the similar layer to Parrot. I don't think we gain something if we layer them.
But, however, the real strength of Squeak for us has been that the same program runs pixel-identically on various platforms; so that a developer who doesn't want to deal with Linux or Sugar can have reasonable assumptions of his program when developing on other platforms.
Fine. That's what I meant for you to do. Compile the existing C version of the VM, just as for any other processor.
Sure. I think I have done fair share of it^^;
This is because Squeak VM provides all graphics and user input and socket and etc (in addition to garbage collection, concurrency, a meta system). (Yeah, a virtual machine should be a machine just happens to be a virtual one; so not just instruction emulation, it should provide such things).
Parrot doesn't offer such abstraction, as far as I can tell. If we are to provide a such layer, we need to write platform specific implementations for these features (as Squeak VM does) and that would mean that we need to re-do whole a lot of work just to be at the same place.
You are getting ahead of yourself. I said to compile the existing VM. Reimplementing is below, and only if it turns out to make sense.
The code for existing VM includes the platforms specific code, for graphics and event handling, etc. You just need them to run Squeak.
If this was about implementing the Squeak VM on Flash, that would have made more sense.
I think this should be reiterate, if Parrot is taking seriously.
and is intended to allow dynamic languages to run unchanged on more than 200 hardware/OS combinations.
Wow. Is there the list of these 200 combinations? I'd be happy to be surprised, but I have a feeling that Squeak VM has a bigger list...
Intended, Yoshiki, not implemented. Current targets are Linux x86 and ARM, Mac x86 and ppc, and Windows x86. Others will be done by whoever wants them badly enough.
The question is not whose is bigger.
Sure, then why did you bring up an arbitrary number like 200?
The question is whether it is worthwhile having an environment in which multiple dynamic languages with or without object class systems can interoperate safely.
Yes, but Squeak VM on-top-of Parrot VM doesn't gain much, we wouldn't even get the interoperability. If we make a Squeak object be a Parrot object by compiling Squeak user code to Parrot code, we could gain inter-language interoperation. If we compile Squeak VM to ActionScript, we lose performance but gain virtually zero install platform in browsers. If we re do the entire system from Scratch, the code should be abstract enough so that it can be mapped to Parrot.
So, I think *if* we do something with Parrot, it should be a new implementation, and not take existing pile of fragilely built, Squeak specific implementation.
-- Yoshiki
Hmm.... seems like rewriting the subject isn't enough for the forum to start a new topic:
http://forums.squeakland.org/viewtopic.php?t=4207
Trying now, completely rewriting the subject (no RE, etc)
-- Timothy Falconer Squeakland Foundation http://squeakland.org 610-797-3100
On Jul 12, 2009, at 11:25 AM, Yoshiki Ohshima wrote:
At Sat, 11 Jul 2009 23:47:26 -0700, Edward Cherlin wrote:
On Sat, Jul 11, 2009 at 11:03 PM, Yoshiki Ohshimayoshiki@vpri.org wrote:
Edward,
Sorry for replying to an introduction email but...
Nope ... it always remembers what you're responding to, even if you change the subject.
Oh well, so much for the introduction topic :)
Tim
-- Timothy Falconer Squeakland Foundation http://squeakland.org 610-797-3100
On Jul 14, 2009, at 9:08 PM, Timothy Falconer wrote:
Hmm.... seems like rewriting the subject isn't enough for the forum to start a new topic:
http://forums.squeakland.org/viewtopic.php?t=4207
Trying now, completely rewriting the subject (no RE, etc)
-- Timothy Falconer Squeakland Foundation http://squeakland.org 610-797-3100
On Jul 12, 2009, at 11:25 AM, Yoshiki Ohshima wrote:
At Sat, 11 Jul 2009 23:47:26 -0700, Edward Cherlin wrote:
On Sat, Jul 11, 2009 at 11:03 PM, Yoshiki Ohshimayoshiki@vpri.org wrote:
Edward,
Sorry for replying to an introduction email but...
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On July 10, 2009, teefal wrote:
Hi everyone,
Please tell us where you're from, what languages you like, what platforms you work with or can test with, and how much you think you'd be able to help.
Hi,
My name is Milan Zimmermann. I have used Etoys for many years, (altough not nearly as much as I would like to). My education is in Physics and Math, with initial brief work in Physics, I develop and design software, recently (such as in the last 11 years) mostly in Java, some Smalltalk(Squeak), but also C, C++ and marginally Python and Scheme. I do some of my work related presentations and designs in Etoys. Occasionally, some Etoys indoctrination of my coworkers :) . I like to experiment with Operating Systems, mostly as a user (BSD, Minix), for day to day operations of my business and life, OpenSUSE.
As much as time allows, I will try to help with Etoys testing, development and grass root marketing.
Milan
PS: Some notes on Etoys development:
http://confluence.immuexa.com/display/sq/Starting+with+Etoys+Development+-+A...
To get started, read here:
http://confluence.immuexa.com/display/sq/Development
-------------------- m2f --------------------
(from forum) http://squeakland.org/forums/viewtopic.php?p=9503#9503
-------------------- m2f --------------------
etoys-dev@lists.squeakfoundation.org
-
Edward Cherlin -
Milan Zimmermann -
teefal -
Timothy Falconer -
Yoshiki Ohshima