Hello,
yesterday a person told me he was creating a Smalltalk VM. I then was both surprisingly interested and sad.
Interested because a merge could be done to complete each other.
Sad because if the merge won't be done, one of the two projects will die and will be yet another break in the Smalltalk community.
I can't link you currently to Panda Smalltalk, but the whole code is available on the Syx git repository.
No propaganda has been done for it though it became a really strong project. It has been started in Novemember.
Finally after we talked about our two implementations, we decided to merge because we have right the same vision for all.
I'm very excited of this, also because Panda Smalltalk has been much inspired by Syx. I'm very glad of this!
Let's see what Syx mainly will gain from Panda:
- - Change fixed object size to variable object size
- - Mature memory management
- - Variable-length bytecodes
- - Abstract Syntax Tree
- - Direct-threaded interpreter with computed goto
- - Unicode
- - Much more
What Panda will gain:
- - One Process per stack
- - A good console
- - The scheduler
- - More portability
- - The image
- - Plugins
- - SCons build system
- - Smalltalk code
- - A compiler abstraction that's more suitable for different implementations, such as JIT
- - Glib + GNU coding style
In other words, new VM features and vision will be merged within an already portable working environment.
And also one more developer.
The final choice was which name, which hosting and which VCS to use.
Everything has gone to Syx, because of its community, the known project name and the reliable git hosting service.
"Michael Heinrich" <mjheinr...@gmail.com> wrote:
> Is there a reason why the merge was aborted?
> I wanted to know more about Panda as it seemed to be of some interest, but I
> will stick with Syx.
> Thanks Luca!
Vincent Geddes (the author) wanted all the control over its smalltalk implementation
and give more focus to creating a GNOME IDE.
Though Syx has also the purpose of creating an IDE in GTK and add support for Gnome.
He has just changed idea.
Contact him for more informations: vincent.ged...@gmail.com
What about GNU Smalltalk? Its one of the most mature Smalltalk
implementations. Merging of the two project would make the work easier
for both maintainers, result a more active community and fasten the
Smalltalk release cycle. Did you ever speak to Paolo Bonzini, GNU
Smalltalk maintainer, who is also an Italian :)
On Jul 9, 7:11 am, Luca Bruno <lethalma...@gmail.com> wrote:
> "Michael Heinrich" <mjheinr...@gmail.com> wrote:
> > Is there a reason why the merge was aborted?
> > I wanted to know more about Panda as it seemed to be of some interest, but I
> > will stick with Syx.
> > Thanks Luca!
> Vincent Geddes (the author) wanted all the control over its smalltalk implementation
> and give more focus to creating a GNOME IDE.
> Though Syx has also the purpose of creating an IDE in GTK and add support for Gnome.
> He has just changed idea.
> Contact him for more informations: vincent.ged...@gmail.com
> What about GNU Smalltalk? Its one of the most mature Smalltalk
> implementations. Merging of the two project would make the work easier
> for both maintainers, result a more active community and fasten the
> Smalltalk release cycle. Did you ever speak to Paolo Bonzini, GNU
> Smalltalk maintainer, who is also an Italian :)
Yes we know each other with Bonzini :)
I've always thought about GNU smalltalk but there many aspects
if it that I don't like it. Starting from the license, ending to
the little bits of stability (that they have been improved for sure in later releases),
and the new syntax they've chosen.
I don't want to say many other aspects, they are personal (such as coding style,
embedding support, etc.).
> I've always thought about GNU smalltalk but there many aspects
> if it that I don't like it.
I hope that this can be reconciled one day. I still hope that one day
Luca will do a Summer of Code project on GNU Smalltalk. :-) I sure
would love to mentor him -- if there is still anything I could teach
him!
Syx's VM is great, and I was positively surprised of what Luca
achieved in 1-2 years. On the other hand, GNU Smalltalk's class
library is way more developed (it includes database access, virtual
file systems, a packaging system, streams, SUnit, Unicode, and so on).
GTK is more developed and surely more stable in Syx than in GNU
Smalltalk, also because Luca is more expert than me in that area.
> the little bits of stability (that they have been improved for sure in later releases),
I think they are. While developing 3.1 the VM barely had crashes,
except for new features of course. Otherwise, http://smalltalk.gnu.org/issues is your and my friend!
> I don't want to say many other aspects, they are personal (such as coding style,
> embedding support, etc.).
Regarding embedding support, you might consider the VM license to be
an insurmountable obstacle and it probably is. Still, I should point
out GNU Smalltalk is actually more liberal than most people think
*except for the VM* (but that's for a reason actually). I'm sad to
hear that licensing is one of the reasons why Luca stopped considering
GNU Smalltalk, and I hope that the pleasure of hacking with his own VM
was a more pressing reason!
Anyway, embedding support is improving with every release. GNU
Smalltalk 3.0 was the first release where the installation *is*
actually using a shared library to provide multiple executables
embedding the VM (one for the REPL, one for the tools such as gst-
sunit or gst-package). It would be great to support the same APIs in
Syx and in GNU Smalltalk, even if the plug-ins would of course not be
ABI-compatible. (In saying this, I must also say that I know that GNU
Smalltalk would benefit more because Syx is MIT-licensed).
That said, I think it would be great if the Syx and GNU Smalltalk
*communities* merged. There is definitely a big intersection in the
focus of the two projects.
GNU Smalltalk would benefit from a larger user base and from more
attention on embedding and on the GUI; Syx instead would probably
benefit from implementing class libraries compatible with GNU
Smalltalk's (though not all of them are perfect of course!!!).
A last word on the licensing. I can understand that if some user was
tinkering both with GNU Smalltalk and with Syx, someone else could be
worried about copyright problems. However, the rules are very simple,
because the FSF's policy about this is clear: you should respect
copyright, but don't refrain from enjoying the benefits of free
software. If you see a feature in GNU Smalltalk that you'd like to
have in Syx, you *will* have to rewrite it in order to license it as
MIT; but *do* look at GNU Smalltalk's source code to understand the
interface or the subtleties of the implementation, or to test your
implementation (many GNU Smalltalk packages come with SUnit
testsuites). Nobody wants anyone not to enjoy the freedom of learning
from free software.
> I hope that this can be reconciled one day. I still hope that one day
> Luca will do a Summer of Code project on GNU Smalltalk. :-) I sure
> would love to mentor him -- if there is still anything I could teach
> him!
> Syx's VM is great, and I was positively surprised of what Luca
> achieved in 1-2 years. On the other hand, GNU Smalltalk's class
> library is way more developed (it includes database access, virtual
> file systems, a packaging system, streams, SUnit, Unicode, and so on).
Thanks very much. I would say the standard library is harder to write than the VM, it needs yet more thoughts about the structure and the organization of the code, though there's a standard.
On the other hand, you're much stronger than me on memory management and algorithms ;).
> GTK is more developed and surely more stable in Syx than in GNU
> Smalltalk, also because Luca is more expert than me in that area.
Thanks, I think the most important issue in GST is having Blox. This is one of the main reasons I don't like GST in its environment.
Instead I like the Squeak environment. It has an abstract MVC around browsers, but doesn't abstract the GUI. So you can write the environment in any GUI toolkit you want, but you have still the full power of the toolkit.
> > the little bits of stability (that they have been improved for sure in later releases),
> I think they are. While developing 3.1 the VM barely had crashes,
> except for new features of course. Otherwise, http://smalltalk.gnu.org/issues > is your and my friend!
You did a great job in that.
> > I don't want to say many other aspects, they are personal (such as coding style,
> > embedding support, etc.).
> Regarding embedding support, you might consider the VM license to be
> an insurmountable obstacle and it probably is. Still, I should point
> out GNU Smalltalk is actually more liberal than most people think
> *except for the VM* (but that's for a reason actually).
Look at the mailing list, you can see people interested on Syx portability and embedding. This is the strongest feature of Syx and thing I'm mostly interested in.
The code is such portable that you can run it everywhere.
> I'm sad to
> hear that licensing is one of the reasons why Luca stopped considering
> GNU Smalltalk, and I hope that the pleasure of hacking with his own VM
> was a more pressing reason!
Yes me too.
> Anyway, embedding support is improving with every release. GNU
> Smalltalk 3.0 was the first release where the installation *is*
> actually using a shared library to provide multiple executables
> embedding the VM (one for the REPL, one for the tools such as gst-
> sunit or gst-package). It would be great to support the same APIs in
> Syx and in GNU Smalltalk, even if the plug-ins would of course not be
> ABI-compatible. (In saying this, I must also say that I know that GNU
> Smalltalk would benefit more because Syx is MIT-licensed).
Here the whole VM comes out in different faces. The plugins API is a direct consequence of the VM design, while GST should put a layer through to achieve the current Syx embeddability.
Syx can compile on Visual C++, this is a great achievement and pushes Syx out of the linux box so much.
> That said, I think it would be great if the Syx and GNU Smalltalk
> *communities* merged. There is definitely a big intersection in the
> focus of the two projects.
Only communities? I don't know what you think, but I'd like to merge a day if you agree with Syx purposes (this means a huge refactoring in GST you know :P)
Please read the Panda merge failure in the mailing list.
> GNU Smalltalk would benefit from a larger user base and from more
> attention on embedding and on the GUI; Syx instead would probably
> benefit from implementing class libraries compatible with GNU
> Smalltalk's (though not all of them are perfect of course!!!).
> A last word on the licensing. I can understand that if some user was
> tinkering both with GNU Smalltalk and with Syx, someone else could be
> worried about copyright problems. However, the rules are very simple,
> because the FSF's policy about this is clear: you should respect
> copyright, but don't refrain from enjoying the benefits of free
> software. If you see a feature in GNU Smalltalk that you'd like to
> have in Syx, you *will* have to rewrite it in order to license it as
> MIT; but *do* look at GNU Smalltalk's source code to understand the
> interface or the subtleties of the implementation, or to test your
> implementation (many GNU Smalltalk packages come with SUnit
> testsuites). Nobody wants anyone not to enjoy the freedom of learning
> from free software.
> Paolo
What if an enterprise application will embed and modify GST without neither any credits nor conctacting you?
> > GTK is more developed and surely more stable in Syx than in GNU
> > Smalltalk, also because Luca is more expert than me in that area.
> Thanks, I think the most important issue in GST is having Blox.
Then let's ditch it. Of course only when there's something better --
but I'm open to everything, including ditching Blox.
> Here the whole VM comes out in different faces. The plugins API is a direct
> consequence of the VM design, while GST should put a layer through to
> achieve the current Syx embeddability.
I don't follow. GNU Smalltalk also has a plugin API, it is invoked
every time you do
PackageLoader fileInPackage: 'Sockets'
or
PackageLoader fileInPackage: 'OpenGL'
for example. Instead, I interpret embeddability as "putting the whole
VM inside something else"; in my case the two "something elses" only
differ in how they interpret the command line, but it's a start. :-)
> Syx can compile on Visual C++, this is a great achievement
> and pushes Syx out of the linux box so much.
GNU Smalltalk used to; I removed that support after MinGW came out,
because it was slower by ~20%.
> > That said, I think it would be great if the Syx and GNU Smalltalk
> > *communities* merged. There is definitely a big intersection in the
> > focus of the two projects.
> Only communities? I don't know what you think, but I'd like to merge
> a day if you agree with Syx purposes (this means a huge refactoring in GST you know :P)
Let's start with the communities. :-)
> Please read the Panda merge failure in the mailing list.
I read about it, and that's why I proposed to start with the
communities. :-)
> > A last word on the licensing. I can understand that if some user was
> > tinkering both with GNU Smalltalk and with Syx, someone else could be
> > worried about copyright problems.
> What if an enterprise application will embed and modify GST without neither any credits nor conctacting you?
I already answered -- "you might consider the VM license to be an
insurmountable obstacle and it probably is." But I think that the
most benefit of merging the communities is the Smalltalk parts, not
the VM.
My remark was more about "what happens if user A implements a feature
in Syx after seeing it in GNU Smalltalk" - as a possible consequence
of merging the communities.
Paolo Bonzini <bonz...@gnu.org> wrote:
> Then let's ditch it. Of course only when there's something better --
> but I'm open to everything, including ditching Blox.
The second part of the comment was the important one.
The layer must be around MVC, not GUI toolkits.
> I don't follow. GNU Smalltalk also has a plugin API, it is invoked
> every time you do
> PackageLoader fileInPackage: 'Sockets'
> or
> PackageLoader fileInPackage: 'OpenGL'
> for example. Instead, I interpret embeddability as "putting the whole
> VM inside something else"; in my case the two "something elses" only
> differ in how they interpret the command line, but it's a start. :-)
> > Please read the Panda merge failure in the mailing list.
> I read about it, and that's why I proposed to start with the
> communities. :-)
> > > A last word on the licensing. I can understand that if some user was
> > > tinkering both with GNU Smalltalk and with Syx, someone else could be
> > > worried about copyright problems.
> > What if an enterprise application will embed and modify GST without neither any credits nor conctacting you?
> I already answered -- "you might consider the VM license to be an
> insurmountable obstacle and it probably is." But I think that the
> most benefit of merging the communities is the Smalltalk parts, not
> the VM.
> My remark was more about "what happens if user A implements a feature
> in Syx after seeing it in GNU Smalltalk" - as a possible consequence
> of merging the communities.
Maybe I've never asked you such a question: why GPL instead of LGPL for the VM if you consider it an obstacle?
