Merge with Panda Smalltalk

[Luca Bruno]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

As said above, you can read the code here: http://repo.or.cz/w/syx.git?a=tree;h=refs/heads/panda;hb=panda

What do you think about?

Bye.

- --
http://syx.googlecode.com - Smalltalk YX
http://lethalman.blogspot.com - Thoughts about computer technologies
http://www.ammazzatecitutti.org - Ammazzateci tutti
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIa41Jw9Qj+8Kak3ERAsYgAJ9t4nQMRMXMS4L1bUqxlsA0dvKcfgCeLjRc
XqJ0HqG+KDtRb6uNIV53wTM=
=8vKv
-----END PGP SIGNATURE-----

[Lethalman]

The Panda Smalltalk author has decided to abort the merge.
Syx will keep the merged code.

Thanks to Vincent and everyone for the support.

This doesn't mean the project is discontinued, everything has just
returned back as before.

Any comments?

[Michael Heinrich]

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!

Michael

[Luca Bruno]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 8 Jul 2008 13:59:11 -0700
"Michael Heinrich" <mjhei...@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...@gmail.com

Thanks Michael :)

- --
http://syx.googlecode.com - Smalltalk YX
http://lethalman.blogspot.com - Thoughts about computer technologies
http://www.ammazzatecitutti.org - Ammazzateci tutti
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkh0OlQACgkQw9Qj+8Kak3EMTwCfWk0g9YNcCn+akACldUMO5mgO
1iwAn3P8KL572+H3vYV0XB/9ve7n1O1V
=yRwt
-----END PGP SIGNATURE-----

[ZuLuuuuuu]

Hello,

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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 8 Jul 2008 13:59:11 -0700
>

> "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
>
> Thanks Michael :)
>
> - --http://syx.googlecode.com- Smalltalk YXhttp://lethalman.blogspot.com- Thoughts about computer technologieshttp://www.ammazzatecitutti.org- Ammazzateci tutti

[Luca Bruno]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Hello,
>
> 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.).

- --
http://syx.googlecode.com - Smalltalk YX
http://lethalman.blogspot.com - Thoughts about computer technologies

http://www.ammazzatecitutti.org - Ammazzateci tutti

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkh64fEACgkQw9Qj+8Kak3FR0gCfcCcZLEpwH/caDXNgDPJOMuh9
8NIAn1FelTJJBCYFSPD5a9K4O5QpIB7k
=+JNW
-----END PGP SIGNATURE-----

[Paolo Bonzini]

> 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.

Paolo

[Luca Bruno]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 8 Aug 2008 07:59:37 -0700 (PDT)
Paolo Bonzini <bon...@gnu.org> wrote:

Hi Paolo, I'm very glad you replied to this mail.

>
> 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?

- --
http://syx.googlecode.com - Smalltalk YX
http://lethalman.blogspot.com - Thoughts about computer technologies
http://www.ammazzatecitutti.org - Ammazzateci tutti
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkicZg8ACgkQw9Qj+8Kak3F4ugCff9LO4kaxzC1pA2fd08nOM9i1
uEQAn2tiymqpztNJWpppBoDHYvI0jlYd
=IPBm
-----END PGP SIGNATURE-----

[Paolo Bonzini]

> > 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

[Luca Bruno]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 8 Aug 2008 09:13:03 -0700 (PDT)
Paolo Bonzini <bon...@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. :-)
>

I meant such API: http://code.google.com/p/syx/wiki/ExampleEmbeddingLua

> GNU Smalltalk used to; I removed that support after MinGW came out,
> because it was slower by ~20%.

Ah indeed, why not supporting both?

> 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.
>

Maybe I've never asked you such a question: why GPL instead of LGPL for the VM if you consider it an obstacle?

- --
http://syx.googlecode.com - Smalltalk YX
http://lethalman.blogspot.com - Thoughts about computer technologies
http://www.ammazzatecitutti.org - Ammazzateci tutti
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkiceAkACgkQw9Qj+8Kak3E1XwCfZEVnDJXn1AfMXGBPmxJ0mOsQ
XYcAn1n/PHSC/89lts+d1bwDbXG5sL6j
=8OCs
-----END PGP SIGNATURE-----

[Paolo Bonzini]

> The second part of the comment was the important one.
> The layer must be around MVC, not GUI toolkits.

Yes, then ditch Blox which wraps GUI toolkits. You want something
like OmniBrowser.

> I meant such API:http://code.google.com/p/syx/wiki/ExampleEmbeddingLua

Yes, you can do that in GNU Smalltalk too.

http://gnu.cofman.dk/software/smalltalk/gst-manual/gst_18.html#SEC35

> > GNU Smalltalk used to; I removed that support after MinGW came out,
> > because it was slower by ~20%.
>
> Ah indeed, why not supporting both?

Nowadays the VM code is automatically generated. When I wrote the
generator, I only supported the fastest version. It would take a
couple of hours to add back the other style.

> Maybe I've never asked you such a question: why GPL instead of LGPL for the VM if you consider it an obstacle?

For embeddability it is an obstacle; for plugins and for scripting it
is an advantage because it "forces" bindings (to OpenGL, SQLite,
whatever) to be GPL. (Besides that, I am not the copyright holder for
GNU Smalltalk, so I cannot changes licenses like snapping fingers :-)

Paolo

[vgeddes]

Hi,

I was thinking... (along the same lines as Paolo)

Why don't the three of us all support each other in creating a GNOME/
GTK+ IDE and community class library? I think it would be a great
folly for each of us to re-invent the wheel.

I think its quite clear (to me at least) that merging VM code is not
going to happen. I am very attached to Panda, and Luca to Syx. So lets
at least rectify the situation above the VM level. I think this is
very doable, in the current technical and legal climate.

I suggest creating a "GNOME Smalltalk" commons project which will
consist of bindings for the entire GNOME stack, as well as a fancy
development environment. We could put all sorts of other goodies in
this project as well. The bindings FFI/API should more or less follow
the GST's implementation (as it is the most advanced). The code would
be kept in a neutral repository, under a license suitable to all three
parties. I hope GST's copyright assignment still allows for retaining
copyright for use in non-GST contexts. The code could possibly be
licensed under the LGPL to allow crossbreeding with the strong GST
libraries.

There is this new tool in GNOME called gobject-introspection. Its
primary aim is help create language bindings. For a long time in
GNOME, language bindings were third-class citizens, as it was very
hard and tedious to wrap GObjects. However, gobject-introspection
makes things easier by allowing runtime introspection of GObjects,
amongst other things. For instance, Colin Walters did a cool hack in
which he generated GTK+ Java bindings at *run-time* using gobject-
introspection (http://cgwalters.livejournal.com/19537.html).

For GNOME Smalltalk to work, we will need to agree on the subset of
our class libraries that need to be compatible with each other. I
don't think this should be too hard.

As I mentioned to Paolo, I am very interested in Vassili Bykov's
Hopscotch IDE (http://gbracha.blogspot.com/). From what I have read of
it, their rationale and usability principles seem to be very sound.
With that in mind, I am certainly not keen on doing a straight port of
the Squeak browsers to GTK+. I get irritated by the modality of the
Squeak class browser. For instance, If I am editing a method, and want
to quickly view another method, I have to cancel editing. Only being
able to view one method at a time is also restrictive. Someone very
aptly called it a "pinhole" style of browsing.

PS: I called this hypothetical project "GNOME Smalltalk", but we can
improve on the name if needed.

Cheers,
Vincent