Goran : Very cool! Just a suggestion:
If you're going to play with something like that, why not do it with this?
Then us mac people could play too.
-----Original Message----- From: goran.krampe@bluefish.se [mailto:goran.krampe@bluefish.se] Sent: Thursday, February 05, 2004 4:48 AM To: squeak-dev@lists.squeakfoundation.org Subject: Gtk2 coming to Squeak...
Howdy people!
Had a bunch of hours yesterday when I wanted to do something fun. So I made my first little pluign in Win32. Just that little thing was fun!
And then I boldly proceeded to download Gtk2 for Win32, libglade, libxml2 and tons of other stuff. After fighting hard with the linker and messing around with Andreas Makefile a bit, searching the web for info yaddayadda - I finally ended up here:
http://anakin.bluefish.se/gohu/25
It is just a teaser of course - you can't really *do* anything yet. But it is a start.
Cheers, Goran
On Feb 5, 2004, at 8:12 AM, Blanchard, Todd wrote:
Goran : Very cool! Just a suggestion:
If you're going to play with something like that, why not do it with this?
Then us mac people could play too.
Well, us mac folk can sorta play with gtk - there is gtk-osx.sourceforge.net which I just tried out, and although it's slow, ugly, and unstable, it does bring up windows and buttons and such.
I noticed recently that Tcl/Tk for the mac works extremely well, using real native widgets. That might turn out to be easier to bind to than WxWindows, since I don't know how much trouble it would be to do a C++ plugin.
But, really, we should just do a decent ObjC bridge one of these days...
On Thu, 5 Feb 2004, Avi Bryant wrote:
But, really, we should just do a decent ObjC bridge one of these days...
That would seem very reasonable... I always thought Objective C message sends looked really weird, until I seriously investigated Smalltalk and realized that Obj-C was trying to emulate Smalltalk-style message sends. I also like the Obj-C's "id" thing.
I find it sad that C++ has come to dominate, when Objective-C isn't much used beyond the NextStep/MacOS world.
- Aaron
-----------------------------------------------------------------------------
Dr. Aaron Lanterman, Asst. Prof. Voice: 404-385-2548 School of Electrical and Comp. Eng. Fax: 404-894-8363 Georgia Institute of Technology E-mail: lanterma@ece.gatech.edu Mail Code 0250 Web: users.ece.gatech.edu/~lanterma Atlanta, GA 30332 Office: GCATT 334B
On 5 Feb 2004, at 19:38, Avi Bryant wrote:
But, really, we should just do a decent ObjC bridge one of these days...
If there is actual interest, I'd be happy to restart work on that...
What do you find indecent about the current one?
It really isn't all that pretty, but tends to do everything you can easily do without overcoming Squeak's not being re-entrant.
Cheers,
Marcel
On Feb 5, 2004, at 3:43 PM, Marcel Weiher wrote:
On 5 Feb 2004, at 19:38, Avi Bryant wrote:
But, really, we should just do a decent ObjC bridge one of these days...
If there is actual interest, I'd be happy to restart work on that...
What do you find indecent about the current one?
It really isn't all that pretty, but tends to do everything you can easily do without overcoming Squeak's not being re-entrant.
I'm definitely interested... in fact I'm sitting here right now with VMMaker open thinking about starting to work on one. The main things I don't like about the current one: - it doesn't seem to work with recent VMs. This is probably easily fixed, but it would be a good start to have a prebuilt 3.6 VM with a working ObjectiveCPlugin. - it doesn't allow message sends from ObjC to Squeak objects. This is what you're talking about with "not re-entrant", but to me that's a very necessary part (the only point to me of an ObjC bridge is to build Cocoa UIs, and that requires being able to get callbacks and delegation messages AFAIK). This will require some thread and semaphore stuff, but it's certainly doable.
Also nice would be compatibility methods for easy bridging between String/NSString, Array/NSArray, OrderedCollection/NSMutableArray, Dictionary/NSMutableDictionary, etc.
Cheers, Avi
On 5 Feb 2004, at 23:55, Avi Bryant wrote:
On Feb 5, 2004, at 3:43 PM, Marcel Weiher wrote:
On 5 Feb 2004, at 19:38, Avi Bryant wrote:
But, really, we should just do a decent ObjC bridge one of these days...
If there is actual interest, I'd be happy to restart work on that...
What do you find indecent about the current one?
It really isn't all that pretty, but tends to do everything you can easily do without overcoming Squeak's not being re-entrant.
I'm definitely interested... in fact I'm sitting here right now with VMMaker open thinking about starting to work on one. The main things I don't like about the current one:
- it doesn't seem to work with recent VMs. This is probably easily
fixed, but it would be a good start to have a prebuilt 3.6 VM with a working ObjectiveCPlugin.
OK, interest in CocoaSqueak seemed to have pretty much evaporated, so there didn't seem much point in making new releases, especially as I've also been very busy with a new job and my move to London..
- it doesn't allow message sends from ObjC to Squeak objects. This is
what you're talking about with "not re-entrant", but to me that's a very necessary part (the only point to me of an ObjC bridge is to build Cocoa UIs, and that requires being able to get callbacks and delegation messages AFAIK).
Yup, precisely. Well, I can also see other uses, but that's a major part of it.
This will require some thread and semaphore stuff, but it's certainly doable.
Yes, that is also the way I had seen:
- have (at least) two threads. - when Squeak calls out - save the message parameters - pass on to second thread that sends the Objective-C message - return into Squeak - suspend the Squeak-internal process making the call (on a semaphore) - when the Objective-C message returns, that thread signals the semaphore - the Squeak process awakes and picks up the result
- for call-in to squeak, either -(ab-)use the even mechanism - or use a separate semaphore and pick up the necessary arguments, dispatch, return etc.
The proxies representing Squeak objects on the Objective-C side have to refer to them via the (an?) external object table, in order to properly handle object-pointers moving around during GC.
Of course, Andreas has raised an intriguing possibility of doing this without separate threads.
Also nice would be compatibility methods for easy bridging between String/NSString, Array/NSArray, OrderedCollection/NSMutableArray, Dictionary/NSMutableDictionary, etc.
Yes, and what would be really nice if the runtimes could just integrate...
Cheers,
Marcel
On Feb 6, 2004, at 12:26 AM, Marcel Weiher wrote:
OK, interest in CocoaSqueak seemed to have pretty much evaporated, so there didn't seem much point in making new releases, especially as I've also been very busy with a new job and my move to London..
Why can't the ObjC plugin (be made to) work with the unix VM?
Yes, that is also the way I had seen:
- have (at least) two threads.
- when Squeak calls out
- save the message parameters
- pass on to second thread that sends the Objective-C message
- return into Squeak
- suspend the Squeak-internal process making the call (on a
semaphore) - when the Objective-C message returns, that thread signals the semaphore - the Squeak process awakes and picks up the result
- for call-in to squeak, either -(ab-)use the even mechanism - or use a separate semaphore and pick up the necessary
arguments, dispatch, return etc.
Yup.
The proxies representing Squeak objects on the Objective-C side have to refer to them via the (an?) external object table, in order to properly handle object-pointers moving around during GC.
Hm, hadn't thought about that part. Good point.
Also nice would be compatibility methods for easy bridging between String/NSString, Array/NSArray, OrderedCollection/NSMutableArray, Dictionary/NSMutableDictionary, etc.
Yes, and what would be really nice if the runtimes could just integrate...
Well, yes and no. I need continuations, so having Squeak use the C stack would be a no-go...
Avi
On 6 Feb 2004, at 08:56, Avi Bryant wrote:
On Feb 6, 2004, at 12:26 AM, Marcel Weiher wrote:
OK, interest in CocoaSqueak seemed to have pretty much evaporated, so there didn't seem much point in making new releases, especially as I've also been very busy with a new job and my move to London..
Why can't the ObjC plugin (be made to) work with the unix VM?
Why should it? But more seriously, CocoaSqueak has the distinct advantage of actually being integrated with Cocoa, running a normal Cocoa event loop from a normal NSApplication, has normal NSViews etc. Grafting that onto the Unix VM, which has quite different notions of interaction, seems rather tricky to me. I also recall Ian mentioning having tried something with Objective-C and it not working. I presume he lost interest after that, but haven't kept track.
Yes, that is also the way I had seen:
- have (at least) two threads.
- when Squeak calls out
- save the message parameters
- pass on to second thread that sends the Objective-C message
- return into Squeak
- suspend the Squeak-internal process making the call (on a
semaphore) - when the Objective-C message returns, that thread signals the semaphore - the Squeak process awakes and picks up the result
- for call-in to squeak, either -(ab-)use the even mechanism - or use a separate semaphore and pick up the necessary
arguments, dispatch, return etc.
Yup.
The proxies representing Squeak objects on the Objective-C side have to refer to them via the (an?) external object table, in order to properly handle object-pointers moving around during GC.
Hm, hadn't thought about that part. Good point.
OK, so let's do it! Getting a 3.6 CocoaSqueak built shouldn't be too much of a problem, and developing the bridge can actually proceed in parallel.
Cheers,
Marcel (off to work)
On Feb 6, 2004, at 1:25 AM, Marcel Weiher wrote:
Why should it?
Because maintaining two VMs for Mac OS X is enough duplicated effort already. Maintaining three is just silly. And the unix VM, AFAICT, does have a normal NSApplication event loop. Perhaps you haven't looked at it recently?
But it's not a big deal. If it's easier to build a 3.6 CocoaSqueak VM than an ObjC-enabled unix VM, fine by me.
OK, so let's do it! Getting a 3.6 CocoaSqueak built shouldn't be too much of a problem, and developing the bridge can actually proceed in parallel.
Where can I download a CocoaSqueak of any version with an ObjectiveCPlugin? 3.2.4 doesn't seem to have it.
On 6 Feb 2004, at 09:41, Avi Bryant wrote:
Because maintaining two VMs for Mac OS X is enough duplicated effort already. Maintaining three is just silly.
Yes, the last time I discussed this with Ian he essentially said he didn't care because he was only doing it for the learning experience anyhow.
And the unix VM, AFAICT, does have a normal NSApplication event loop. Perhaps you haven't looked at it recently?
No I haven't, and yes it does. Nice. Will have to take a look at the entire thing.
But it's not a big deal. If it's easier to build a 3.6 CocoaSqueak VM than an ObjC-enabled unix VM, fine by me.
Nope, that should do just fine.
Cheers,
Marcel
I should add that a spent a few days last fall and did an audit of the unix VM versus carbon mac VM to identify the differences, and turned that report over to Ian for comment.
The carbon VM won't disappear because it's a code base for classic mac, and provides the same classic to os-x platform usability.
Hopefully, based on many hours we can merge or create the lacking mac functionality (ie aliases) into the unix VM. Things like the OS process plugin are hard to do in carbon vm because it's HFS file named base, and all that unix stuff is unix file named based.
Then perhaps we could rip the os-x specific stuff out of the classic mac vm source code I'd guess.
Even as a 'to do' item is to document the VM to smalltalk interface and ensure all popular VM do in fact match api and result expectations. A compliance document comes to mind, anyone interested? All the source code should be accessible, all one needs to do is a lot of reading and consolidating the information into some sort of readable document.
On Feb 6, 2004, at 6:04 AM, Marcel Weiher wrote:
On 6 Feb 2004, at 09:41, Avi Bryant wrote:
Because maintaining two VMs for Mac OS X is enough duplicated effort already. Maintaining three is just silly.
Yes, the last time I discussed this with Ian he essentially said he didn't care because he was only doing it for the learning experience anyhow.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On Feb 6, 2004, at 7:36 PM, John M McIntosh wrote:
Even as a 'to do' item is to document the VM to smalltalk interface and ensure all popular VM do in fact match api and result expectations. A compliance document comes to mind, anyone interested? All the source code should be accessible, all one needs to do is a lot of reading and consolidating the information into some sort of readable document.
I've thought of this many times but (obviously) never got to it. I was considering a 'nullplatform' source tree with all the platform functions empty but heavily commented. Actually, some of the functions could have a fair bit of skeleton code as part of the explanation; for example the ioRelinquishProcessor code could have the lines relating to working out how long the delay might be to take into account any pending Delay etc. That's platform neutral and not necessarily obvious at first.
tim
It really isn't all that pretty, but tends to do everything you can easily do without overcoming Squeak's not being re-entrant.
Actually, it's not all that hard to support callbacks. Back, when I wrote the FFI I considered supporting callbacks but the major reason against it was not the complexity but time constraints (the project we were working on really needed it). If you wanted to do callbacks all you need to keep in mind that the only, the exclusive place where a regular (not interrupt) callback can occur is during a primitive call (obviously - all other methods only run bytecodes and send further messages). Because of this, the entire internal interpreter state is perfectly externalized so that it is quite doable do simply "call back" into interpret(). So what you'd have to do is essentially:
- define a number of callback stubs (could be a fixed number) which - remember the stack pointer for later use (to get the arguments) - mark itself as the "top-most C frame" being used - signal the callback semaphore associated with the stub - mark the execution point by a setjmp() - call interpret() - (after return through longjmp()) restore the prior top-most C frame - returns to caller
- define the "return from callback" primitive so that it - horribly barfs if it's not the top-most callback (this would mean you try to return through another C stack frame) - simply leaves interpret() by a longjmp to the callback stub
This should work just nicely - a bit of trickery is certainly needed but not very much. Then, on the Squeak side what you do is:
- provide a Squeak process for each callback which - requests a new callback stub - sits waiting on the callback semaphore - when it wakes up requests the stack pointer - unpacks the arguments from the stack (via a few FFI primitives) - runs the associate callback block - returns via return from callback primitive
That's about it. If you want to get fancy you can add some stuff in the Squeak process that serializes the returns appropriately so that callbacks invoked from different processes work appropriately. But really, supporting callbacks isn't all THAT hard ;-)
Cheers, - Andreas
Hi guys!
"Andreas Raab" andreas.raab@gmx.de wrote:
It really isn't all that pretty, but tends to do everything you can easily do without overcoming Squeak's not being re-entrant.
Actually, it's not all that hard to support callbacks.
[SNIP of technical description that mostly flew over my head]
That's about it. If you want to get fancy you can add some stuff in the Squeak process that serializes the returns appropriately so that callbacks invoked from different processes work appropriately. But really, supporting callbacks isn't all THAT hard ;-)
:) Well, since I only understood half of what you wrote... :)
But anyway, for my little GtkPlugin I am sticking to STTCPW for now. So I will simply look at the other plugins and use some Semaphore etc to do the "callbacks".
Btw, I also actually managed to drive the Gtk loop from within Squeak! So no need to spawn a thread in the plugin just yet. Currently a background Process in Squeak that calls the GtkPlugin every 10ms (or whatever) seems to work good enough to move on.
Next step is of course the callback/signal/event-stuff. I have a plan, but will need to look into more pluginish stuff before getting something that works. Need to figure out how to handle the Gtkish C structs like the GdkEvent, GtkWidget etc. IIRC Andreas has whipped up some classes for those kind of things... ExternalStructure I guess.
Cheers,
- Andreas
regards, Göran
"Blanchard, Todd" todd.blanchard@cendant.com wrote:
Goran : Very cool! Just a suggestion:
If you're going to play with something like that, why not do it with this?
Then us mac people could play too.
I know about wxWindows and many other alternatives too. I took Gtk for several reasons:
1. It is C-focused. So are Squeak plugins and the make structure etc in Squeak. AFAIK wxWin is C++, not sure if I want to go there... :)
2. I have heard here and there that wx is slow and also suffers a bit from the LCD problems (is that the right name? Least Common Denominator?). But that is just hearsay. Not sure about how wx evolves nowadays, is it live and kicking like Gtk?
3. I like Gtk. :) It looks very nice, seems to have a lot of momentum and is AFAIK very themeable.
4. The license, LGPL.
5. Gtk is getting more and more portable.
And last but not least - if we get this to work properly - there is nothing stopping us from trying other kits too like wx. Quite a few problems should be common in all this.
regards, Göran
On Fri, 6 Feb 2004 goran.krampe@bluefish.se wrote:
"Blanchard, Todd" todd.blanchard@cendant.com wrote:
If you're going to play with something like that, why not do it with this?
Then us mac people could play too.
Mac folks can use GTK+, at least on OS X. Of course, it isn't completely finished, but it doesn't require X11. But it does run CinePaint (nee Film Gimp), though in an alpha state.
http://gtk-osx.sourceforge.net/
Sure, it doesn't look like a native Mac app, but it's better than nothing. I too would rather have someone use an API that looked native, but at the same time, I'd much rather have GTK+ rather than nothing. I'm not doing the work, and if Goran chooses to bestow upon us something fun and potentially useful, I'm not going to complain.
- It is C-focused. So are Squeak plugins and the make structure etc in
Squeak. AFAIK wxWin is C++, not sure if I want to go there... :)
There is some sort of C API for wxWindows. That, or one is generated by SWIG. A number of languages which only have a C interface have wxWindows libraries; DrScheme/MzScheme and Python come to mind. But then again, AFAIK, SWIG doesn't support Squeak, or else wxWindows would be a snap- but then again, so would GTK+ most likely.
- I have heard here and there that wx is slow and also suffers a bit
from the LCD problems (is that the right name? Least Common Denominator?). But that is just hearsay. Not sure about how wx evolves nowadays, is it live and kicking like Gtk?
GTK+ is used by more people, so not surprisingly, I'd say GTK+ is more alive in some ways. But otherwise, wxWindows is used plenty of places and is an active project.
What do you mean by LCD problems? Rather, what kinds of problems?
- I like Gtk. :) It looks very nice, seems to have a lot of momentum
and is AFAIK very themeable.
If you like the look of GTK+, you're in luck. wxWindows- on Unix and Linux- uses GTK+ as its widget set. If you support wxWindows, you support GTK+.
But then again, if the reason you like GTK+ is not the looks of it but rather the way you code it, or maybe you like the hierarchy or some other GTK+ specific idiosyncrasy then I have no answer for you.
- Gtk is getting more and more portable.
But it retains its look. Though, that doesn't really matter to anyone but Mac OS X people, and a tiny bit to Windows folks. Sure, you could use a wanna-be Aqua theme for GTK+, but IMHO, those just look like crap. One is better off using a standard BlueCurve or Motif-ish theme- at least it looks decent.
Regards, Aaron
-- "the end of the human race will be that it will eventually die of civilization. " :: r. w. emerson
Aaron J Reichow squeak-dev@lists.squeakfoundation.org said:
[...], SWIG doesn't support Squeak
Wouldn't that be a grand idea? Haven't looked at SWIG for ages, but this certainly would be doable and SWIG support that generates Squeak plugins plus some simple Smalltalk glue code would give us a lot of leverage, apart from UI's...
Hi Aaron and all!
Aaron J Reichow reic0024@d.umn.edu wrote:
On Fri, 6 Feb 2004 goran.krampe@bluefish.se wrote:
"Blanchard, Todd" todd.blanchard@cendant.com wrote:
If you're going to play with something like that, why not do it with this?
Then us mac people could play too.
Mac folks can use GTK+, at least on OS X. Of course, it isn't completely finished, but it doesn't require X11. But it does run CinePaint (nee Film Gimp), though in an alpha state.
http://gtk-osx.sourceforge.net/
Sure, it doesn't look like a native Mac app, but it's better than nothing. I too would rather have someone use an API that looked native, but at the same time, I'd much rather have GTK+ rather than nothing. I'm not doing the work, and if Goran chooses to bestow upon us something fun and potentially useful, I'm not going to complain.
:)
- It is C-focused. So are Squeak plugins and the make structure etc in
Squeak. AFAIK wxWin is C++, not sure if I want to go there... :)
There is some sort of C API for wxWindows. That, or one is generated by SWIG. A number of languages which only have a C interface have wxWindows libraries; DrScheme/MzScheme and Python come to mind. But then again, AFAIK, SWIG doesn't support Squeak, or else wxWindows would be a snap- but then again, so would GTK+ most likely.
Let me be frank: My C and C++ is pretty rusty. Combined with trying to figure out low level integration issues in making Squeak plugins - it is pushing my limits. I am no Andreas or Ian. :)
BUT... if you or someone else steps up to the plate and figure out how to Swig wxWindows so that we can use it through C - then perhaps it could be an interesting venue too.
But as long as noone steps up - I will instead focus on what I can handle: Gtk2, since it seems pretty "simple" in comparison.
- I have heard here and there that wx is slow and also suffers a bit
from the LCD problems (is that the right name? Least Common Denominator?). But that is just hearsay. Not sure about how wx evolves nowadays, is it live and kicking like Gtk?
GTK+ is used by more people, so not surprisingly, I'd say GTK+ is more alive in some ways. But otherwise, wxWindows is used plenty of places and is an active project.
I looked it over yesterday and yes, it looks pretty alive. I have looked at it from time to time to see where it is going.
What do you mean by LCD problems? Rather, what kinds of problems?
Well, the fact that mapping onto other backend kits may make the framework only offerint stuff that is available on all platforms. But I read about it and it seems wx has tried to avoid that.
- I like Gtk. :) It looks very nice, seems to have a lot of momentum
and is AFAIK very themeable.
If you like the look of GTK+, you're in luck. wxWindows- on Unix and Linux- uses GTK+ as its widget set. If you support wxWindows, you support GTK+.
But then again, if the reason you like GTK+ is not the looks of it but rather the way you code it, or maybe you like the hierarchy or some other GTK+ specific idiosyncrasy then I have no answer for you.
My reasons for going with Gtk2 are multiple. It seems very alive, has very good functionality, and is getting more and more cross-platform. It is also C-based - a very big advantage. And it is free.
regards, Göran
On Feb 8, 2004, at 1:34 PM, goran.krampe@bluefish.se wrote:
Aaron J Reichow reic0024@d.umn.edu wrote:
On Fri, 6 Feb 2004 goran.krampe@bluefish.se wrote:
"Blanchard, Todd" todd.blanchard@cendant.com wrote:
If you're going to play with something like that, why not do it with this?
Then us mac people could play too.
Mac folks can use GTK+, at least on OS X. Of course, it isn't completely finished, but it doesn't require X11. But it does run CinePaint (nee Film Gimp), though in an alpha state.
http://gtk-osx.sourceforge.net/
Sure, it doesn't look like a native Mac app, but it's better than nothing. I too would rather have someone use an API that looked native, but at the same time, I'd much rather have GTK+ rather than nothing. I'm not doing the work, and if Goran chooses to bestow upon us something fun and potentially useful, I'm not going to complain.
And, for that matter, the stock GTK distribution works fine with Apple's X11 server. I use it to run GIMP with no problems at all.
Colin
squeak-dev@lists.squeakfoundation.org
-
Aaron J Reichow -
Aaron Lanterman -
Andreas Raab -
Avi Bryant -
Blanchard, Todd -
Cees de Groot -
Colin Putney -
goran.krampe＠bluefish.se -
John M McIntosh -
Marcel Weiher -
Timothy Rowledge