[Pharo-project] Discussion summary and milestones
Hi all we got an extremely positive ESUG. Thanks all of you for your great software: Thanks Gary it was great to see you. Now I would like to summarize some of the discussions we got. For milestone1 ----------------- - we will integrate the Polymorph package of gary. This means we may try to remove some old morphic and integrate really gary's work. Now this task could be continued further in milestone 2. - gary could you send around (not only to adrian) the etoy removal so that we do it? - Marcus plans to integrate the stack interpreter made by eliot so that we will get fullclosures. - We will integrate the freetype plugging (we will need some VM guys probably). - We want to have a one click image! - internally we will work on a core and set of package but publicly we would like to avoid to have a distribution that is not tested/used. For the dev image we would like to only have a set of selected packages, so the idea is that damien will collect the key package that would go in the dev version. (which may be the one click image). We really want to have package without overrides. - We would like to push the idea of a package manifesto. For milestone 2 ------------------- - GTK binding - the newcompiler will replace the old one - marcus is really interested in COG and helping there. I will try to help and learn from mathieu. - popUp plague -> notification mechanism (check the OBNotification hierarchy). We need to push infrastructural work so that everything benefit of it. There are certainly point I forgot to mention but the future is full of new perspectives. Stef
Hi Stef, Thanks for the list, its nice to see all the progress and plans! I have a couple of questions:
- we will integrate the Polymorph package of gary. This means we may try to remove some old morphic and integrate really gary's work. Now this task could be continued further in milestone 2.
Sounds good, but what is Polymorph?
- gary could you send around (not only to adrian) the etoy removal so that we do it?
If Gary sent it to me, I must have missed this mail. So please resend it.
- We will integrate the freetype plugging (we will need some VM guys probably).
This would be great, but I wonder whether we will really be able to convince enough VM-skilled people to build and maintain the VMs? I think we would need at least Windows, Linux, and Intel Mac (maybe also PowerPC) versions that include the FT2Plugin and the modified BitBlt Plugin. Maybe it would be easier to convince the guys maintaining the Squeak VM to integrate it so that we do not have to fork the VM as well.
- We want to have a one click image!
yes, that's an important one! [....] Cheers, Adrian
On 30.08.2008, at 13:05, Adrian Lienhard wrote:
Hi Stef,
Thanks for the list, its nice to see all the progress and plans! I have a couple of questions:
- we will integrate the Polymorph package of gary. This means we may try to remove some old morphic and integrate really gary's work. Now this task could be continued further in milestone 2.
Sounds good, but what is Polymorph?
The name used to be "look-enancements". Very impressive... (I guess everyone is using that since months... I did not know it)
- gary could you send around (not only to adrian) the etoy removal so that we do it?
If Gary sent it to me, I must have missed this mail. So please resend it.
- We will integrate the freetype plugging (we will need some VM guys probably).
This would be great, but I wonder whether we will really be able to convince enough VM-skilled people to build and maintain the VMs? I think we would need at least Windows, Linux, and Intel Mac (maybe also PowerPC) versions that include the FT2Plugin and the modified BitBlt Plugin. Maybe it would be easier to convince the guys maintaining the Squeak VM to integrate it so that we do not have to fork the VM as well.
Yes, we need to find a solution. But for Squeak, I have the fear that it will be a discussion that ends in why it's better to not do anything at all. Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
On 30.08.2008, at 12:35, Stéphane Ducasse wrote:
Hi all
we got an extremely positive ESUG. Thanks all of you for your great software: Thanks Gary it was great to see you. Now I would like to summarize some of the discussions we got.
For milestone1 -----------------
- we will integrate the Polymorph package of gary. This means we may try to remove some old morphic and integrate really gary's work. Now this task could be continued further in milestone 2.
- gary could you send around (not only to adrian) the etoy removal so that we do it?
- Marcus plans to integrate the stack interpreter made by eliot so that we will get fullclosures.
The stack interpreter and closures are two distinct things: closures are one things (some primitives, some compiler changes). This we should integrate ASAP (then we can port the newcompiler to emit this closure code). So Closures is in milestone 1, definitely. The stack-stuff is an interpreter that uses the C-Stack. This is not yet released (10-20% faster the current vm). It will be released soon, thus it likely can be in milestone 1, too.
For milestone 2 ------------------- - GTK binding
Optional or replacing morphic? Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
2008/8/30 Stéphane Ducasse <stephane.ducasse@inria.fr>:
- internally we will work on a core and set of package but publicly we would like to avoid to have a distribution that is not tested/used.
I have started using pharo for iStoa.net, and I have a long list of dependency: Morph (I want to use Gary stuff also), Magma, Seaside. I can definitely give feed back Hilaire
2008/8/30 Marcus Denker <denker@iam.unibe.ch>:
For milestone 2 ------------------- - GTK binding
Optional or replacing morphic?
Don't run too fast to kill Morphic. There are a lot of value in Morphic and GTK+ is not a replacement for it, more an alternative for different purpose. Sure it need clean up. Hilaire
2008/8/30 Hilaire Fernandes <hilaire@ofset.org>:
2008/8/30 Marcus Denker <denker@iam.unibe.ch>:
For milestone 2 ------------------- - GTK binding
Optional or replacing morphic?
Don't run too fast to kill Morphic. There are a lot of value in Morphic and GTK+ is not a replacement for it, more an alternative for different purpose.
And with the work of Gary, Morphs are looking much better ;-) GTK is great have to better acceptance by non-smalltalkers but it's a bit premature to switch to GTK. -- Serge Stinckwich Smalltalkers do: [:it | All with: Class, (And love: it)] http://blog.doesnotunderstand.org/
On 30 Aug 2008, at 18:35, Serge Stinckwich wrote:
2008/8/30 Hilaire Fernandes <hilaire@ofset.org>:
2008/8/30 Marcus Denker <denker@iam.unibe.ch>:
For milestone 2 ------------------- - GTK binding
Optional or replacing morphic?
Don't run too fast to kill Morphic. There are a lot of value in Morphic and GTK+ is not a replacement for it, more an alternative for different purpose.
And with the work of Gary, Morphs are looking much better ;-) GTK is great have to better acceptance by non-smalltalkers but it's a bit premature to switch to GTK.
I have discussed with Gary and may be he will port the Squeak canvas to support the cairo canvas so it will be possible to have Gtk and Morphs Gwenael Casaccio
The stack interpreter and closures are two distinct things: closures are one things (some primitives, some compiler changes). This we should integrate ASAP (then we can port the newcompiler to emit this closure code). So Closures is in milestone 1, definitely.
The stack-stuff is an interpreter that uses the C-Stack. This is not yet released (10-20% faster the current vm). It will be released soon, thus it likely can be in milestone 1, too.
Ok I was confused.
For milestone 2 ------------------- - GTK binding
Optional or replacing morphic?
I do not think that it is resonnable to replace morphic. because morphic (a clean version is still important for lot of people). Stef
yes this was the idea On Aug 30, 2008, at 5:27 PM, Hilaire Fernandes wrote:
2008/8/30 Marcus Denker <denker@iam.unibe.ch>:
For milestone 2 ------------------- - GTK binding
Optional or replacing morphic?
Don't run too fast to kill Morphic. There are a lot of value in Morphic and GTK+ is not a replacement for it, more an alternative for different purpose. Sure it need clean up.
Hilaire
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The stack interpreter and closures are two distinct things: closures are one things (some primitives, some compiler changes). This we should integrate ASAP (then we can port the newcompiler to emit this closure code). So Closures is in milestone 1, definitely.
It means that we should then produce our own VMs I imagine. So what are the plans there? - how do we generate them? Mathieu can build the mac one, bryce can you build a linux one? - how do we keep the files (do we have to have our own svn)? May be we should do a call, stating that we would like to integrate the primitives and closure code into squeak but need vms support. Stef
Stéphane Ducasse writes:
The stack interpreter and closures are two distinct things: closures are one things (some primitives, some compiler changes). This we should integrate ASAP (then we can port the newcompiler to emit this closure code). So Closures is in milestone 1, definitely.
It means that we should then produce our own VMs I imagine. So what are the plans there? - how do we generate them? Mathieu can build the mac one, bryce can you build a linux one?
I can build the Linux one. Though, if I'm to keep doing it for more than just one or two, I'd like to use the same VM as Exupery does. That may pose some problems with Eliot's stack work. The stack work would require a large amount of rework in Exupery to make it compatible, basically the same work Eliot did on the VM but redone inside Exupery. Given the gains advertised the stack work isn't worthwhile stopping Exupery 1.0 development to support. The closures work should be easier, just a few bytecodes, basically the same as adding proper support for the closure compiler. Though I'm not sure what the benefits of Eliot's work over the closure compiler are if you're going to use the NewCompiler.
- how do we keep the files (do we have to have our own svn)?
May be we should do a call, stating that we would like to integrate the primitives and closure code into squeak but need vms support.
Bryce
I can build the macintosh one, also I need to see about building it on the iPhone. Does someone have a worksheet that indicates how you go from the standard VMMaker build to produce the closure aware VM? I would think there should be a wiki or something somewhere explaining? The freetype plugin and bitblt plugin I have been building for Sophie, the freetype plugin is the most complex to build since it requires two 10.3.x machines (powerpc, and macintel), in order to build a pre 10.5 aware universal binary, it gets built rarely because of that complexity On Aug 31, 2008, at 8:13 AM, Stéphane Ducasse wrote:
The stack interpreter and closures are two distinct things: closures are one things (some primitives, some compiler changes). This we should integrate ASAP (then we can port the newcompiler to emit this closure code). So Closures is in milestone 1, definitely.
It means that we should then produce our own VMs I imagine. So what are the plans there? - how do we generate them? Mathieu can build the mac one, bryce can you build a linux one? - how do we keep the files (do we have to have our own svn)?
May be we should do a call, stating that we would like to integrate the primitives and closure code into squeak but need vms support.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Stéphane Ducasse wrote:
It means that we should then produce our own VMs I imagine. So what are the plans there?
Knowing that I'm touching flame bait here, but how is the general consensus on continuing to use VMMaker and Slang for generating VMs? Alternatives could be pure C code and/or code management using Git. Michael
Michael This is not a question for us. Let us face it seriously we are not expert on VM building for the moment. Now we may start to build them. And yes using git would be a good idea. Stef On Aug 31, 2008, at 10:54 PM, Michael Rueger wrote:
Stéphane Ducasse wrote:
It means that we should then produce our own VMs I imagine. So what are the plans there?
Knowing that I'm touching flame bait here, but how is the general consensus on continuing to use VMMaker and Slang for generating VMs? Alternatives could be pure C code and/or code management using Git.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Just about catching up with work emails etc... Great to see you at ESUG, a most excellent event! I'll post the EToys removals package (more for reference, has #toRemove stubs and changed methods) once I've reviewed the changes (over 600 changed/removed methods). I'm sure I've missed a couple ;-) Should be able to do that tomorrow and rename the Pinesoft-Widgets to Polymorph. Would be nice to replace the Balloon engine with Cario sometime... Regards, Gary. ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, August 30, 2008 11:35 AM Subject: [Pharo-project] Discussion summary and milestones
Hi all
we got an extremely positive ESUG. Thanks all of you for your great software: Thanks Gary it was great to see you. Now I would like to summarize some of the discussions we got.
For milestone1 -----------------
- we will integrate the Polymorph package of gary. This means we may try to remove some old morphic and integrate really gary's work. Now this task could be continued further in milestone 2.
- gary could you send around (not only to adrian) the etoy removal so that we do it?
- Marcus plans to integrate the stack interpreter made by eliot so that we will get fullclosures.
- We will integrate the freetype plugging (we will need some VM guys probably).
- We want to have a one click image!
- internally we will work on a core and set of package but publicly we would like to avoid to have a distribution that is not tested/used.
For the dev image we would like to only have a set of selected packages, so the idea is that damien will collect the key package that would go in the dev version. (which may be the one click image). We really want to have package without overrides.
- We would like to push the idea of a package manifesto.
For milestone 2 ------------------- - GTK binding
- the newcompiler will replace the old one
- marcus is really interested in COG and helping there. I will try to help and learn from mathieu.
- popUp plague -> notification mechanism (check the OBNotification hierarchy). We need to push infrastructural work so that everything benefit of it.
There are certainly point I forgot to mention but the future is full of new perspectives.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Sounds good, I'll take a more recent look at Rome again. Last time I looked it was a little raw, guess things have moved on for the better now! ----- Original Message ----- From: "Michael Rueger" <m.rueger@acm.org> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <pharo-project@lists.gforge.inria.fr> Sent: Monday, September 01, 2008 1:23 PM Subject: Re: [Pharo-project] Discussion summary and milestones
Gary Chambers wrote:
Would be nice to replace the Balloon engine with Cario sometime...
Did you take a look at the Rome stuff? It has a Cairo and a Balloon subclass, so you can switch the rendering backend without affecting the API.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sep 1, 2008, at 2:05 PM, Gary Chambers wrote:
Just about catching up with work emails etc...
Great to see you at ESUG, a most excellent event!
I'll post the EToys removals package (more for reference, has #toRemove stubs and changed methods) once I've reviewed the changes (over 600 changed/removed methods). I'm sure I've missed a couple ;-)
:)
Should be able to do that tomorrow and rename the Pinesoft-Widgets to Polymorph. Would be nice to replace the Balloon engine with Cario sometime...
:) I think that we should look at Sophie because there is a romeCanvas that does that if I'm correct.
Regards, Gary.
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr
To: "An open mailing list to discuss any topics related to an open- sourceSmalltalk" <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, August 30, 2008 11:35 AM Subject: [Pharo-project] Discussion summary and milestones
Hi all
we got an extremely positive ESUG. Thanks all of you for your great software: Thanks Gary it was great to see you. Now I would like to summarize some of the discussions we got.
For milestone1 -----------------
- we will integrate the Polymorph package of gary. This means we may try to remove some old morphic and integrate really gary's work. Now this task could be continued further in milestone 2.
- gary could you send around (not only to adrian) the etoy removal so that we do it?
- Marcus plans to integrate the stack interpreter made by eliot so that we will get fullclosures.
- We will integrate the freetype plugging (we will need some VM guys probably).
- We want to have a one click image!
- internally we will work on a core and set of package but publicly we would like to avoid to have a distribution that is not tested/used.
For the dev image we would like to only have a set of selected packages, so the idea is that damien will collect the key package that would go in the dev version. (which may be the one click image). We really want to have package without overrides.
- We would like to push the idea of a package manifesto.
For milestone 2 ------------------- - GTK binding
- the newcompiler will replace the old one
- marcus is really interested in COG and helping there. I will try to help and learn from mathieu.
- popUp plague -> notification mechanism (check the OBNotification hierarchy). We need to push infrastructural work so that everything benefit of it.
There are certainly point I forgot to mention but the future is full of new perspectives.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 2008-09-01 at 08:07 +0200, Stéphane Ducasse wrote:
Michael This is not a question for us. Let us face it seriously we are not expert on VM building
That is right. So this is a problem changing the code and maintaining our own vm. It's too much work without the necessary expertise. But on the other side the combination of vmmaker/slang/c does also not attract anyone to get into the vm stuff. So we would be bound to that a long time. Wouldn't Spy (http://pypysqueak.blogspot.com/) be a benefit in the long run. I'm very interested in vm stuff (at the moment just reading). For me it is much more attractive approach I would try to dive into. My opinion is that it is more flexible and opens worlds like LLVM (http://llvm.org/) and friends for us. What do you think?
for the moment. Now we may start to build them. And yes using git would be a good idea. Stef
A lot of people are using git these days. So this must have something good. Norbert
On Aug 31, 2008, at 10:54 PM, Michael Rueger wrote:
Stéphane Ducasse wrote:
It means that we should then produce our own VMs I imagine. So what are the plans there?
Knowing that I'm touching flame bait here, but how is the general consensus on continuing to use VMMaker and Slang for generating VMs? Alternatives could be pure C code and/or code management using Git.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 12.09.2008, at 16:00, Norbert Hartl wrote:
On Mon, 2008-09-01 at 08:07 +0200, Stéphane Ducasse wrote:
Michael This is not a question for us. Let us face it seriously we are not expert on VM building
That is right. So this is a problem changing the code and maintaining our own vm. It's too much work without the necessary expertise. But on the other side the combination of vmmaker/slang/c does also not attract anyone to get into the vm stuff. So we would be bound to that a long time.
Wouldn't Spy (http://pypysqueak.blogspot.com/) be a benefit in the long run. I'm very interested in vm stuff (at the moment just reading). For me it is much more attractive approach I would try to dive into. My opinion is that it is more flexible and opens worlds like LLVM (http://llvm.org/) and friends for us. What do you think?
The Squeak-in-python was an experiment. It it not really realistic to think that the result will be a replacement for the current vm anytime soon. Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
participants (11)
-
Adrian Lienhard -
bryce＠kampjes.demon.co.uk -
Gary Chambers -
Gwenael Casaccio -
Hilaire Fernandes -
John M McIntosh -
Marcus Denker -
Michael Rueger -
Norbert Hartl -
Serge Stinckwich -
Stéphane Ducasse