Custom Search
|
Date: July 29, 2003
From: "Roberto Amorim" <wolfoxbr@xxxxxxxxxxx>
References:
<20030729094834.GA3626@xxxxxxx>
> I released Smalltalk 2.1a; among other changes the most relevant are: > > * beginnings of a security framework inspired by Java's > > * fixes to C call-outs; we use the same library as GNU gcj Congratulations, I'm sure it's another quality release. I'll try it at home as soon as I can (what can be tomorrow or in a few weeks, as Real Life (TM) wants...). > I also released the Gtk+ bindings for Smalltalk 2.1.4, which are a first > stab at merging the concepts at the base of Mike's bindings. They are > quite a big improvement on the pre-existing bindings, with features such > as: (...) > Reimplementations of Mike's example programs (and possibly reports for > any bug that emerges in the process) to use the GTK package are welcome! I'll take a look on it... > ps: my connectivity for the next month will be very sparse. Hope to see you soon. Let me know if you need something. Regards, Roberto
Date: July 29, 2003
From: Bonzini <bonzini@xxxxxxx>
I released Smalltalk 2.1a; among other changes the most relevant are:
* beginnings of a security framework inspired by Java's
* fixes to C call-outs; we use the same library as GNU gcj
It is available on
ftp://alpha.gnu.org/gnu/smalltalk/smalltalk-2.1a.tar.gz
and other GNU mirrors.
---
I also released the Gtk+ bindings for Smalltalk 2.1.4, which are a first
stab at merging the concepts at the base of Mike's bindings. They are
quite a big improvement on the pre-existing bindings, with features such
as:
* every GObject is always mapped to the same Smalltalk object
* if a function is declared as returning a GtkWidget * but actually
returns a GtkLabel *, the returned Smalltalk object will be a GtkLabel.
The same goes for objects passed to event handlers.
* many bug-fixes
* a few more example programs (including human vs. human TicTacToe :-)
* tighter integration with glib, using customized GClosures to invoke
Smalltalk methods.
These are available in Smalltalk 2.1a or as a patch from 2.1.4, at
ftp://alpha.gnu.org/gnu/smalltalk/smalltalk-2.1.4-gtk.diff.gz
Just configure without any extra option, and load package GTK.
As a remainder, Mike's bindings are available as
ftp://alpha.gnu.org/gnu/smalltalk/mike-anderson-gst-gtk-0.06.tar.gz
Reimplementations of Mike's example programs (and possibly reports for
any bug that emerges in the process) to use the GTK package are welcome!
Paolo
ps: my connectivity for the next month will be very sparse.
Date: July 22, 2003
From: "Paolo Bonzini" <bonzini@xxxxxxx>
References:
<20030722083419.62584.qmail@xxxxxxxxxxxxxxxxxxxxxxx>
> Well, you could always implement a tree in Tk - I'm > sure somebody has ;). Yes, but not as full of features as Gtk's. > Is is so bad to have a widget that is not (yet) > implemented for one of the underlying toolkits, > though? It's not as if tree views are indispensible in > UI design. Well, they do help in a class browser :-) > Well, the point of MBox was that I couldn't get > BContainer to work properly. In fact, a lot of this > discussion would be moot if the you could get the > packer to work - then you could support both geometry > management schemes natively under both toolkits. BContainer is a hack. Hopefully after Gtk bindings are written it will be more usable. Wasn't the packer removed in 2.0? > Incidentally, which version of Gtk are you using? I am using 2.2.0. > Only because that type of layout is so strongly > discouraged in Gtk, so it seems kind of ugly to force > all windows to include one in our Gtk bindings. This is not completely true (GtkFixed is discouraged, but you have GtkTable and a placer geometry manager is not much different). The abundance of geometry managers is a good reason (but they are windowless so they only consume 200 or so bytes per window, I think). > GtkWindow > \_GtkVBox > |_GtkPlacer > |_GtkVBox > |_ ... all the other widgets ... This can be avoided by reparenting the placer under the VBox when the menu is created. > > mourn > > | save | > > save := gtk. > > gtk := key := nil. > > gtk unref > > You mean save unref in the last line, presumably. Of course. > I think this boils down to leaving them alone, and > letting the Smalltalk garbage collector take care of > it. Perhaps that's best. Yes, that's it. You actually can use the standard finalization scheme in GNU Smalltalk. I have it implemented for objects that are passed through closures, but not for objects that are returned with #new; I am going to download the Python bindings now. I suspect that it will help to do some VM work to allow customization of the way return values are passed back from C to Smalltalk. > Do we need to prevent unwary users from inadvertently > calling destroy on their widgets? Just give them enough rope to shoot themselves on their feet, and remember not to unref the object when the CObject is finalized. > Slightly unrelated question: will a CObject be cleaned > up if its underlying C structure is freed? Presumably > not. Nope, you have a dangling pointer. > What is going to happen to all the GtkObjects when the > image is restarted? They're all CObjects, but they > won't be valid Gtk widgets. Is that going to require > rebuilding all of the windows from scratch? Yes, of course, like with standard Blox. Paolo
Date: July 22, 2003
From: MSA or SJF <msasjf@xxxxxxxxxxx>
In-reply-to:
<002801c34f91$6a006990$4011623e@philo
>
References:
<002801c34f91$6a006990$4011623e@philo
>
--- Paolo Bonzini <bonzini@xxxxxxx> wrote:
> > I suppose my preferred approach would be to double
> up the widgets, and
> > provide a BTree as well.
>
> Yes, mine too. (but this also implies kissing Tk
> goodbye).
Well, you could always implement a tree in Tk - I'm
sure somebody has ;).
Is is so bad to have a widget that is not (yet)
implemented for one of the underlying toolkits,
though? It's not as if tree views are indispensible in
UI design.
> > I'm not entirely against RSG - there are some
> tricks it can do that
> > boxes can't, and vice-versa. To each his own. It's
> simple enough to
> > implement a rubber-sheet widget using GtkLayout, I
> should think. Are you
> > suggesting emulating Gtk's geometry management
> when using Gtk as the
> > underlying widget set, though? That doesn't make
> sense to me.
>
> I did write a simple GtkPlacer geometry manager
> based on the GtkFixed but
> with RSG. I am suggesting emulating Tk's geometry
> management with a custom
> geometry manager, when using Gtk as the underlying
> widget set. Then one can
> either use your MBox to re-emulate Gtk's geometry
> management (does not make
> much sense but it is cross-platform) or use
> BContainer which will use Gtk's
> boxes.
Well, the point of MBox was that I couldn't get
BContainer to work properly. In fact, a lot of this
discussion would be moot if the you could get the
packer to work - then you could support both geometry
management schemes natively under both toolkits.
Incidentally, which version of Gtk are you using?
> > If you go the Tk route, then you'll
> > be automatically adding a GtkLayout at the top
> level of every window,
> > which you might not think was so bad (I would, but
> that's beside the
> > point), but you're then going to have to
> incorporate menus into that
> > scheme.
>
> Yes, you would have
>
> GtkWindow
> \_GtkVBox
> |_GtkMenu (or whatever it is called)
> |_GtkPlacer
> |_ ... all the other widgets ...
>
> It would work but it is a bit messy. I have zero
> experience with Gtk, so
> why would you consider adding a GtkPlacer in every
> place so bad?
Only because that type of layout is so strongly
discouraged in Gtk, so it seems kind of ugly to force
all windows to include one in our Gtk bindings.
That's a relatively trivial point. From a technical
point of view, if you were going to use the Gtk
scheme, then you would most likely have:
GtkWindow
\_GtkVBox
|_GtkMenuBar
|_GtkPlacer
|_GtkBox
|_ ... all the other widgets ...
Which means that you have one redundant widget, and
two if the Box is a VBox. Well, I have a colleague who
constantly argues that this sort of thing is
inconsequential, but I also know that we've hit the
GDI resource limits under Windows, on account of using
too many window handles. Adding two extra widgets on
each window isn't going to threaten resources much - I
just have an aversion to it now. For a window without
a menu, I would *definitely* want to avoid this kind
of nastiness:
GtkWindow
\_GtkVBox
|_GtkPlacer
|_GtkVBox
|_ ... all the other widgets ...
> > This is all personal taste, of course, but then,
> personal taste was what
> > drove me to look at the Gtk bindings rather than
> using the existing Tk
> > ones in the first place...
>
> For me it was user's taste, not developer's taste.
> Of course other's
> mileages may vary.
Ah, well, yes, but I spend much of my time doing
application programming, so really, I am more of a
user than a developer in this case :-)
> > The concern is memory (de-)allocation. I'm not
> actually sure if this is
> > a real problem in practice, but if a widget is
> freed, either you allow
> > Gtk to free all its children, and have some
> notification back to
> > Smalltalk, or you'd have to implement freeing them
> in Smalltalk.
> > Obviously, there is also the choice of simply
> leaving them alone, but it
> > seems to be a waste when there's quite a nice
> ref-counting scheme in
> > Gtk. Also, if you _ref the widget from Smalltalk,
> there's presumably a
> > possibility that Gtk will garbage collect it in
> the meantime. Actually,
> > that's a problem with an asynchronous event loop
> anyway, isn't it?
>
> The idea would be to have a GtkHandle object that is
> an ephemeron. It will
> also point to itself in the first field, like
>
> gtkObject: gtkObj
> key := self.
> gtk := gtkObj.
> gtk ref.
> gtk sink
>
> Then you receive a #mourn message in the GtkHandle
> when the first field
> (i.e. the handle itself) is not referenced anymore
> in the image: now do
>
> mourn
> | save |
> save := gtk.
> gtk := key := nil.
> gtk unref
You mean save unref in the last line, presumably. I
think this boils down to leaving them alone, and
letting the Smalltalk garbage collector take care of
it. Perhaps that's best.
Do we need to prevent unwary users from inadvertently
calling destroy on their widgets?
Slightly unrelated question: will a CObject be cleaned
up if its underlying C structure is freed? Presumably
not.
What is going to happen to all the GtkObjects when the
image is restarted? They're all CObjects, but they
won't be valid Gtk widgets. Is that going to require
rebuilding all of the windows from scratch?
> Let's just try to converge. Sooner or later it will
> be easier to merge.
I'm all for that.
Sadly, I'm back at work (running late as I type), and
once again, there's precious little time to hack.
> Here is the update on the blox-gtk directory.
Thanks.
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Date: July 21, 2003
From: "Paolo Bonzini" <bonzini@xxxxxxx>
References:
<1058738665.3213.1.camel@xxxxxxxxxxxxxxxxxxxx>
> I suppose my preferred approach would be to double up the widgets, and
> provide a BTree as well.
Yes, mine too. (but this also implies kissing Tk goodbye).
> I'm not entirely against RSG - there are some tricks it can do that
> boxes can't, and vice-versa. To each his own. It's simple enough to
> implement a rubber-sheet widget using GtkLayout, I should think. Are you
> suggesting emulating Gtk's geometry management when using Gtk as the
> underlying widget set, though? That doesn't make sense to me.
I did write a simple GtkPlacer geometry manager based on the GtkFixed but
with RSG. I am suggesting emulating Tk's geometry management with a custom
geometry manager, when using Gtk as the underlying widget set. Then one can
either use your MBox to re-emulate Gtk's geometry management (does not make
much sense but it is cross-platform) or use BContainer which will use Gtk's
boxes.
> If you go the Tk route, then you'll
> be automatically adding a GtkLayout at the top level of every window,
> which you might not think was so bad (I would, but that's beside the
> point), but you're then going to have to incorporate menus into that
> scheme.
Yes, you would have
GtkWindow
\_GtkVBox
|_GtkMenu (or whatever it is called)
|_GtkPlacer
|_ ... all the other widgets ...
It would work but it is a bit messy. I have zero experience with Gtk, so
why would you consider adding a GtkPlacer in every place so bad?
> BContainer itself is something of a make-it-fit solution.
Yes, it is.
> This is all personal taste, of course, but then, personal taste was what
> drove me to look at the Gtk bindings rather than using the existing Tk
> ones in the first place...
For me it was user's taste, not developer's taste. Of course other's
mileages may vary.
> Can we provide pure-Gtk bindings as well as Blox-Gtk bindings in a
> reasonably elegant fashion?
>
> Yes, based on 2.4.6. It's an ARM processor, although off-hand, I can't
> tell you the exact flavour - there is a tool-chain for it already, with
> gcc version 2.95.2 (which might be the source of some of my trouble - I
> seem to remember there were issues with older versions of gcc before).
> At the moment, it's complaining about missing alloc.h, if that sounds
> familiar to you.
More likely.
> I can't actually work out whether it should be looking
> for it, though.
In libgst!
> I hadn't thought of making the Namespace a pool dictionary. Can you do
> that? I was trying to work out how pool dictionaries work just a few
> days ago. Can you make any Dictionary a pool dictionary, or does it have
> to be a specific type?
Yes, you can. A pool dictionary is the place for imports.
> The concern is memory (de-)allocation. I'm not actually sure if this is
> a real problem in practice, but if a widget is freed, either you allow
> Gtk to free all its children, and have some notification back to
> Smalltalk, or you'd have to implement freeing them in Smalltalk.
> Obviously, there is also the choice of simply leaving them alone, but it
> seems to be a waste when there's quite a nice ref-counting scheme in
> Gtk. Also, if you _ref the widget from Smalltalk, there's presumably a
> possibility that Gtk will garbage collect it in the meantime. Actually,
> that's a problem with an asynchronous event loop anyway, isn't it?
The idea would be to have a GtkHandle object that is an ephemeron. It will
also point to itself in the first field, like
gtkObject: gtkObj
key := self.
gtk := gtkObj.
gtk ref.
gtk sink
Then you receive a #mourn message in the GtkHandle when the first field
(i.e. the handle itself) is not referenced anymore in the image: now do
mourn
| save |
save := gtk.
gtk := key := nil.
gtk unref
You will also need to ref/unref the object in the closure invocation
functions. That means before Smalltalk is invoked. I need to check out
whether Gtk does that in g_value_get_object or whatever it is called.
> The reservation is the number of bindings that are generated.
I know this. But in the future there might be image packing through
elimination of unused selectors.
> Paolo, I've wasted far too much time thinking about this. If you want to
> convert anything to use the other bindings, you're more than welcome.
> For my part, I think I'm probably going to continue along the same lines
> for a while, although I'm certainly going to take some of that work on
> board - the signals / closures at the very least.
Let's just try to converge. Sooner or later it will be easier to merge.
Here is the update on the blox-gtk directory.
Paolo
blox-gtk-update.tar.gz
Description: GNU Zip compressed data
_______________________________________________ help-smalltalk mailing list help-smalltalk@xxxxxxx http://mail.gnu.org/mailman/listinfo/help-smalltalk
Date: July 21, 2003
From: Nicolas Pelletier <nicolasp@xxxxxxxxxxxxxxxxxx>
Hello,
I am building gst with a traditional interpreter and the new
generational GC on sparc-solaris2.6:
./configure --prefix=/home/nicolasp/local --with-gmp=/home/nicolasp/local/lib
--with-readline=/home/nicolasp/local/lib
Compilation is ok, the generated gst runs, but not in all cases. gmake
check hangs when running SUnit tests. All I see is:
gmake[2]: Entering directory `/var/tmp/smalltalk-2.1.4/tests'
builddir=`pwd`; cd . && \
SMALLTALK_IMAGE=$builddir SMALLTALK_KERNEL=../kernel \
$builddir/../gst -QSsi AnsiLoad.st
Loading package SUnit
There is no response to ctrl-c or ctrl-d, the process has to be killed
directly or suspended before it can be killed. Using PackageLoader
fileInPackage: #SUnit from a running gst does the same.
Furthermore, I get:
nicolasp[232]> ../gst
GNU Smalltalk ready
st> FileStream fileIn: 'SUnitPreload.st' !
FileStream
st> FileStream fileIn: 'SUnit.st' !
FileStream
st> FileStream fileIn: 'SUnitScript.st' !
"Scavenging... 66% reclaimed, done"
"Scavenging... 43% reclaimed, done"
TestSuitesScriptTest->10 run, 7 passed, 0 failed, 3 errors
FileStream
But in that case, gst continues to work. The percentages reported by
the scavenger are higher than what was reported by the GC in gst 2.0.x
(43% on the second scavenging seems high to me). The tests that are
failing are:
testCompoundScript
testHierarchyScript
testSimpleScript
All these fail at their first assert: self assert: allTestCaseClasses
size = 1 (or 2 for testCompoundScript).
Where should I look further to narrow this down ?
--
Nicolas
Date: July 20, 2003
From: "Paolo Bonzini" <bonzini@xxxxxxx>
References:
<20030718233217.GH17862@xxxxxxxxxx>
Thanks, Paolo
Date: July 18, 2003
From: Brett Cundal <bcundal@xxxxxxxxxx>
Very minor bug breaks printOn:
--- gnu-smalltalk/net/NetServer.st 2003-07-16 09:01:22.000000000
-0700
+++ NetServer.st 2003-07-18 16:26:42.000000000 -0700
@@ -82,7 +82,7 @@
printOn: aStream
aStream print: self class; nextPut: $:.
- self isServing ifFalse: [ ^aStream nextPutAll: 'idle' ].
+ self isRunning ifFalse: [ ^aStream nextPutAll: 'idle' ].
aStream print: self socket port
! !
-- Brett
pgpxr9xfMtltx.pgp
Description: PGP signature
_______________________________________________ help-smalltalk mailing list help-smalltalk@xxxxxxx http://mail.gnu.org/mailman/listinfo/help-smalltalk
Date: July 16, 2003
From: "Paolo Bonzini" <bonzini@xxxxxxx>
----- Original Message ----- From: <noreply@xxxxxxxxxxxxx> To: <noreply@xxxxxxxxxxxxx> Sent: Wednesday, July 16, 2003 4:28 PM Subject: [fmII] GNU Smalltalk 2.1.4 released (Stable branch) > This email is to inform you about the release of version '2.1.4' of 'GNU > Smalltalk' through freshmeat.net. All URLs and other useful information > can be found at > > http://freshmeat.net/projects/gnusmalltalk/ > > The changes in this release are as follows: > Several garbage collection bugfixes were made, mostly involving very > large objects. A few performance enhancements were made in the base > classes. > > Project description: > GNU Smalltalk is a free implementation of the Smalltalk-80 language. > > If you would like to cancel subscription to releases of this project, > login to freshmeat.net and choose 'home' from the personal menubar at the > top of the page. You'll be presented with a list of projects you're > subscribed to in the right column, which you may cancel by highlighting > the project in question and clicking the 'delete' button. > > Sincerely, > freshmeat.net > > ____________________________| Advertising |____________________________ > Why Linux? Because it costs less. > > Now, thanks to Oracle's work with Linux partners, along with Oracle's > advanced clustering technology Linux is ready for the enterprise. Arm > yourself with a solid implementation plan-and charter a managed deployment > for Linux. Click for a free Forrester Research report and guide to > creating a Linux playbook. > > > > http://ad.doubleclick.net/clk;5837541;8091587;w?http://www.oracle.com/go/?&S rc=1764460&Act=14 > > ____________________________| Advertising |____________________________ > > > >
Date: July 14, 2003
From: "Roberto Amorim" <wolfoxbr@xxxxxxxxxxx>
References:
<1058203469.2349.24.camel@xxxxxxxxxxxxxxxxxxxx>
This is fantastic news. I thought more than once about doing it myself, but I realized that my knowledge of GTK+ is far from what it takes to do such work, and thus found myself wondering when (and even if) such a thing would appear. And then I read this. :-) I'll take a good look on your work ASAP, and I'm sure almost everyone else on this list will. Meanwhile, *do* get some rest. I'm sure you deserve it. :-) Best regards, and many thanks, Roberto > Ladies and Gentlemen, > > I've been working on my set of Gtk bindings, and they are now in a > fairly functional state (ie. you can use them to build and run > functional windows). > > Implementing any 'regular' widgets I've missed takes minimal work. > Trees/lists and text buffers require many extra C bindings, and there > are probably many useful ones not implemented yet (although basic > functionality is there - see the tests/examples). > > This isn't built on the existing Gtk bindings, but that is not in any > way a criticism of them - it's simply that I didn't have the knowledge > to work on them (since it involved much automaking, sedding, etc.), > whereas I could write new bindings from scratch. > > Available from http://www.gingerbread.plus.com/downloads. > > All suggestions and criticism, short of personal attacks, gratefully > received. Actually, if anyone can suggest an approach for writing unit > tests for this type of work, I'd be very interested. > > Mike > > P.S. I am, of course, going away now for a few days. I'll be back in > touch at the weekend.
Date: July 14, 2003
From: "Roberto Amorim" <wolfoxbr@xxxxxxxxxxx>
References:
<1058203469.2349.24.camel@xxxxxxxxxxxxxxxxxxxx>
This is fantastic news. I thought more than once about doing it myself, but I realized that my knowledge of GTK+ is far from what it takes to do such work, and thus found myself wondering when (and even if) such a thing would appear. And then I read this. :-) I'll take a good look on your work ASAP, and I'm sure almost everyone else on this list will. Meanwhile, *do* get some rest. I'm sure you deserve it. :-) Best regards, and many thanks, Roberto > Ladies and Gentlemen, > > I've been working on my set of Gtk bindings, and they are now in a > fairly functional state (ie. you can use them to build and run > functional windows). > > Implementing any 'regular' widgets I've missed takes minimal work. > Trees/lists and text buffers require many extra C bindings, and there > are probably many useful ones not implemented yet (although basic > functionality is there - see the tests/examples). > > This isn't built on the existing Gtk bindings, but that is not in any > way a criticism of them - it's simply that I didn't have the knowledge > to work on them (since it involved much automaking, sedding, etc.), > whereas I could write new bindings from scratch. > > Available from http://www.gingerbread.plus.com/downloads. > > All suggestions and criticism, short of personal attacks, gratefully > received. Actually, if anyone can suggest an approach for writing unit > tests for this type of work, I'd be very interested. > > Mike > > P.S. I am, of course, going away now for a few days. I'll be back in > touch at the weekend.
Date: July 14, 2003
From: Mike Anderson <msasjf@xxxxxxxxxxx>
Ladies and Gentlemen, I've been working on my set of Gtk bindings, and they are now in a fairly functional state (ie. you can use them to build and run functional windows). Implementing any 'regular' widgets I've missed takes minimal work. Trees/lists and text buffers require many extra C bindings, and there are probably many useful ones not implemented yet (although basic functionality is there - see the tests/examples). This isn't built on the existing Gtk bindings, but that is not in any way a criticism of them - it's simply that I didn't have the knowledge to work on them (since it involved much automaking, sedding, etc.), whereas I could write new bindings from scratch. Available from http://www.gingerbread.plus.com/downloads. All suggestions and criticism, short of personal attacks, gratefully received. Actually, if anyone can suggest an approach for writing unit tests for this type of work, I'd be very interested. Mike P.S. I am, of course, going away now for a few days. I'll be back in touch at the weekend.
Date: July 02, 2003
From: "Bonzini" <bonzini@xxxxxxx>
> Now... where's everyone? I'm very busy, it's enough I found the time to upload it :-) Paolo
Date: July 01, 2003
From: "Roberto A." <wolfoxbr@xxxxxxxxxxx>
I guess everyone noticed, and I expected some announcement here, but as I saw nothing this far... GNU Smalltalk 2.1.3 is available, and with lots of improvements. Now... where's everyone? Cheers, Roberto