GNOME Smalltalk?

[Paolo Bonzini]

Sorry syx people for the double post, I wanted to include help-smalltalk.

Vincent Geddes <vincent...@gmail.com> wrote:

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

Paolo

[Luca Bruno]

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

It's a folly to have 3 VM first of all.
For what concerns sharing the Smalltalk code try solving these problems:
1) Syx and Panda have no clue (not yet) of what a pollDictionary, a namespace,
security policies, syntax, packages and concurrency are
2) Since the VM is different, some of the choices in the smalltalk code could bring problem for scaling and performances
3) The packaging system is different (that both Syx and Panda haven't) and the syntax is different, unless we use the standard inter-exchange format, but I won't develop any such big product with such format, and therefore VCS issues begin

Then for GNOME Smalltalk, in the far future (at least for Syx):
1) I'd make a GSIDE (GTK+ Smalltalk IDE) then add features for GNOME when you're on GNOME, as you all know I'm very careful about portability.
2) We shouldn't inherit from Squeak, I don't like it too, I mean we must create an MVC abstraction layer (or at least on Syx).

In other words, _Syx CAN'T_ collaborate in such project right now. It will take a long time before the 2.0 version (full standard supported as for roadmap).

I do agree it's a good idea, good luck Panda and GST :) Syx will join later.

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

iEYEARECAAYFAkid+K0ACgkQw9Qj+8Kak3EFrwCeMrmlpHBLqPbL3JYZ4dj047ds
10MAn0LW91W7zZgtosBNpQb0xgjATd/G
=qWeU
-----END PGP SIGNATURE-----

[vgeddes]

On Aug 9, 10:06 pm, Luca Bruno <lethalma...@gmail.com> wrote:
>
> It's a folly to have 3 VM first of all.

Well, yes, I suppose. However, I think this is the particular fate
that Smalltalk has bestowed on us. Its relatively easy to write a
simple Smalltalk VM (compared to Java), and VM developers (like me)
can have endless fun while doing so. This is precisely the same reason
there are a glut of Scheme VMs, while there are relatively few Java
VMs.

Still, if there is standardisation at the Kernel and Class library
level, then there really shouldn't be a problem having multiple VMs.
My only worry about standardisation is that it may prevent moving past
outdated Blue-Book designs.

> For what concerns sharing the Smalltalk code try solving these problems:
> 1) Syx and Panda have no clue (not yet) of what a pollDictionary, a namespace,
> security policies, syntax, packages and concurrency are
> 2) Since the VM is different, some of the choices in the smalltalk code could bring problem for scaling and performances
> 3) The packaging system is different (that both Syx and Panda haven't) and the syntax is different, unless we use the standard inter-exchange format, but I won't develop any such big product with such format, and therefore VCS issues begin

Yes, these are issues, but they are not insurmountable. We all want
the best namespace and packaging technology, and so on. File-out
syntax is just a means to end. Once we have IDE running, file-outs
will be used infrequently.

This isn't particularly relevant, but I don't think Smalltalk and
language-level security would mix well. Usability and security are
inversely proportional. In Smalltalk, there are just too many points
where untrusted code can bring down or take control of a VM. If we
wanted to really make Smalltalk bullet-proof we would have to
transform it into, well ... Newspeak (and thats another story
entirely).

>
> Then for GNOME Smalltalk, in the far future (at least for Syx):
> 1) I'd make a GSIDE (GTK+ Smalltalk IDE) then add features for GNOME when you're on GNOME, as you all know I'm very careful about portability.
> 2) We shouldn't inherit from Squeak, I don't like it too, I mean we must create an MVC abstraction layer (or at least on Syx).
>
> In other words, _Syx CAN'T_ collaborate in such project right now. It will take a long time before the 2.0 version (full standard supported as for roadmap).
>
> I do agree it's a good idea, good luck Panda and GST :) Syx will join later.
>

I understand. However, for the time being, I do think its important to
collaborate at least on a class library, packaging and namespace
system. These are prerequisites for a successful IDE project.

Vincent

[Paolo Bonzini]

> Still, if there is standardisation at the Kernel and Class library
> level, then there really shouldn't be a problem having multiple VMs.

Fully agreed.

> > 1) Syx and Panda have no clue (not yet) of what a pollDictionary, a namespace,
> > security policies, syntax, packages and concurrency are

GNU Smalltalk supports the fileout syntax, we can use it. Packages
and namespaces are not necessary features for this project (namespaces
are visible in a GUI, but building a good GUI framework like
OmniBrowser but for Hopscotch-like GUIs is what this project could be
about). Security policies are not functional right now, they are
there only because they were part of my master thesis.

> > 2) Since the VM is different, some of the choices in the smalltalk code could bring problem for
> > scaling and performances

This has not been a problem for Seaside, which has much heavier
requirements on scaling.

> > Then for GNOME Smalltalk, in the far future (at least for Syx):
> > 1) I'd make a GSIDE (GTK+ Smalltalk IDE) then add features for GNOME when you're on
> > GNOME, as you all know I'm very careful about portability.

Yeah, GNOME is just a desktop environment. I'm sure that 99% of the
features would only need GTK+.

Paolo

[Luca Bruno]

In data 11 agosto 2008 alle ore 10:15:34, Paolo Bonzini <bon...@gnu.org>
ha scritto:

Ok,
Vincent I'm wondering it gobject-introspection is alredy working, or we
should wait for it.
Anyway I like having expressive methods in the wrapper. For example the
attach for the table, I've done it in SqueakGtk using Points. Would
gobject-introspection be good for this kind of job?

--

http://lethalman.blogspot.com - Thoughts about computer technologies

http://code.google.com/p/syx - A new Smalltalk implementation
http://www.ammazzatecitutti.org - E adesso ammazzateci tutti

[vgeddes]

On Aug 11, 10:56 am, "Luca Bruno" <lethalma...@gmail.com> wrote:
> Ok,
> Vincent I'm wondering it gobject-introspection is alredy working, or we  
> should wait for it.
> Anyway I like having expressive methods in the wrapper. For example the  
> attach for the table, I've done it in SqueakGtk using Points. Would  
> gobject-introspection be good for this kind of job?
>

I think we have to wait for it. It isn't 100% finished yet. I don't
mind waiting though.

Honestly, I haven't really looked deeply at gobject-introspection
myself. But I have heard a lot of good things about it. There are
certainly some very clever people working on it as well.

We would still have to write the mapping transformation that takes the
GTK+ API information generated by gobject-introspection and converts
it into binding code. The trick would be in ensuring that the mapping
transformation produces good-quality Smalltalk-aware APIs (as you
suggest with tables and Points).

Note, I have never written a Gtk+ binding, so you probably know more
than me about this topic :)