From: Philip Metz [mailto:metzp@interlog.com] Pardon my ignorance, but how is it possible to access an object *after* it has been GCd?
It isn't. The object is asked for its executor - the thing that deals with cleaning up after its death. The executor typically maintains a copy of sufficient of the object's state to be able to do the cleanup.
- Peter
On Wednesday, October 23, 2002, at 05:31 AM, Peter Crowther wrote:
From: Philip Metz [mailto:metzp@interlog.com] Pardon my ignorance, but how is it possible to access an object *after* it has been GCd?
It isn't. The object is asked for its executor - the thing that deals with cleaning up after its death. The executor typically maintains a copy of sufficient of the object's state to be able to do the cleanup.
- Peter
I'll point out some smalltalk implementations ask the executor what to do and give it reference to the 'dead' object as part of the finalization process. The executor can then decide to 'resurrect' the 'dead' object by making a reference to it again. Tho somehow my head hurts when asked to justify this action and the business model that would require you to do it.
I'll also mention in many years of being asked 'why questions' about finalization issues I aways say the weak object will go away some day in some fast to slow serialized/parallel way depending on the smalltalk implementation and smalltalk version. If you're assuming it does 100 per second every 1/2 second or so, or something of that nature you are in trouble, it's lazy and some flavors you might need to kick.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Are we forking without actually realizing --or admitting to ourselves-- that we are forking?
We seem to have active and ongoing development along one (non-module based) line against a previous Golden release version (3.2), and active and ongoing development against another (module-based) line -- our present test pilot alpha. As understood, the prevalent reason why this is so derives in large part from the fact that it is intractable to use earlier changesets with our module-based test pilot image. This is not a problem that is going to go away.
We are not very close to a new golden release, and the longer we have parallel changeset developments, the harder and harder it will be to merge these into a consistent whole. Many of us would like to do ongoing development that is unrelated to and does not depend upon the modules, and are uncertain how (singly or dually), and even whether, to distribute our code until all is well and settled in this awkward and odd arena.
For my part, I am uncertain what images I should be working with, and how many different versions (and upgrade levels) I should keep around. And I'm a fairly seasoned Squeaker.
Does anybody have a plan on this point? Is it going to be possible to reconcile these worlds safely? If not, shouldn't we just declare the fork a fork, or either adopt the new and dump the old, or dump the new in favor of another?
My concern is that if we all sit on the fence too long, it will be too late.
I could well be all wet. (I hope so.) In the meanwhile, it seems like a very uncomfortable question.
Hi Andrew--
FWIW (again :)... I've felt fine developing for the latest final system (3.2), since it seems like that's what most newcomers will try first. Doing integration with any non-modular image is usually non-trivial anyway, so I'm not too concerned about the next time I have to do it (with the eventual 3.3 final or 4.0 final, for example). In contrast, having to regress to a non-modular system once I'd gotten everything working in a finalized modular system would probably be a drag.
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]
"Andrew C. Greenberg" werdna@mucow.com wrote...
Are we forking without actually realizing --or admitting to ourselves-- that we are forking?
Hi, Andrew (and all) -
This is a very good question. To me the only truly uncomfortable part is the lack of clarity on the issue, for which I am willing to take part of the blame. As soon as we have clarity, I am confident that we can forge a reasonable strategy for getting the most out of our efforts as we have in the past.
I'm not an astrologer, but I'm amused to receive your message no more than three hours after I sent very nearly the same message to what you might call SqC++, in other words SqC as it has evolved over the last year.
Of course this is an issue that affects the whole Squeak community and, as such, the resolution should come from the community as a whole, not just us. What I would like to contribute at this point is a nice clear statement about where SqC is headed and how it could dovetail with the other needs and enthusiasms of the community in general, but I can't.
What I can tell you is that we are right now addressing essentially the same question among ourselves, and that we have set a date for its resolution. In less than two weeks at least 3 of us (and maybe you, too, Andrew?) will be together at the Hackers Conference, and I hereby commit to report whatever clarity we can achieve regarding both technical direction and community participation from this corner.
- Dan
Dan Ingalls Dan@SqueakLand.org is claimed by the authorities to have written:
In less than two weeks at least 3 of us (and maybe you, too, Andrew?) will be together at the Hackers Conference, and I hereby commit to report whatever clarity we can achieve regarding both technical direction and community participation from this corner.
Unfortunately I _won't_ be able to make it this year :-( You'd get a much better size audience at oopsla, which I will.
tim
Dan Ingalls Dan@SqueakLand.org is claimed by the authorities to have written:
In less than two weeks at least 3 of us (and maybe you, too, Andrew?) will be together at the Hackers Conference, and I hereby commit to report whatever clarity we can achieve regarding both technical direction and community participation from this corner.
and Tim Rowledge tim@sumeru.stanford.edu responded...
Unfortunately I _won't_ be able to make it this year :-( You'd get a much better size audience at oopsla, which I will.
I didn't mean to imply a Squeak-wide forum. This is just a chance for three different parts of SqC to get together (we're normally spread all over) to formulate some internal plans. After that, we can at least be clear about where we are headed, to the extent that may catalyze other strategies among the Squeak community at large.
- Dan
Hi all!
At several points in the ongoing threads that touch upon this problem we (or at least I) have asked for some input from SqC and Andreas has at least posted his thoughts. I have been missing thoughts from you Dan and others too, not only from SqC.
The problem is a bit of leadership here - SqF hasn't grown strong yet and SqC has been pretty silent for quite a long time. That might of course be intentional to see if the rest of us can find a structure where SqC isn't leading. :-)
But IMHO it would still have been interesting to hear your thoughts...
It looks to me that DVS and SqueakMap (and the new .sar format etc) is getting awfully close (well, DVS is more than close) to start taking on responsibilities that Modules in 3.3a has. And these components are getting more and more developer mindshare which means a lot.
I have even at one or two occasions tried to present different roads where one of the roads is to freeze 3.3a, bring all the goodies back over ontop of 3.2 but leave Modules and then go from there. Why? Well, obviously Modules (as in Henrik's code) has some problems - the technical ones are of course debatable, but the these facts are hard to deny:
1. Noone seems to fully understand and be able to work with the code except for Henrik. Daniel and Andreas have done valiant efforts. (This does not imply that the code is bad, I am just looking at people here)
2. Henrik has stepped down, and I don't blaim him. But it still means that questions on design and code goes unanswered.
3. People react negatively when they realize that they can't "live" in 3.3a to do their work. In earlier alphas this has been no problem - it has been remarkably stable. But this time it is not and really important things have been changed and are not functional. We knew this would happen, - I even remember saying "Now all hell will break loose..." at the last OOPSLA when Modules hit the update stream. But I still hoped that it would be a positive thing in the end when the dust settled down.
...but why am I blabbering, I don't think anyone listens much to me anyway. (sudden strike of insight)
regards, Göran
On Thu, Oct 24, 2002 at 09:08:11AM +0100, goran.hultgren@bluefish.se wrote:
...but why am I blabbering, I don't think anyone listens much to me anyway. (sudden strike of insight)
I think you are doing a good job of facilitating an important discussion. I'm listening but not talking. Please continue :)
Dave
Hi all!
"David T. Lewis" lewis@mail.msen.com wrote:
On Thu, Oct 24, 2002 at 09:08:11AM +0100, goran.hultgren@bluefish.se wrote:
...but why am I blabbering, I don't think anyone listens much to me anyway. (sudden strike of insight)
I think you are doing a good job of facilitating an important discussion. I'm listening but not talking. Please continue :)
Thanks David. I will try to hold my tongue though so that other people can have their saying in the matter.
So... have you tried SqueakMap RC1? ;-)
regards, Göran
On Thu, Oct 24, 2002 at 11:33:40AM +0100, goran.hultgren@bluefish.se wrote:
So... have you tried SqueakMap RC1? ;-)
I will do so soon, hopefully this weekend if I have some free time. It looks very useful based on your web pages, and I like the keep-it-simple approach.
Dave
Hi David and all!
"David T. Lewis" lewis@mail.msen.com wrote:
On Thu, Oct 24, 2002 at 11:33:40AM +0100, goran.hultgren@bluefish.se wrote:
So... have you tried SqueakMap RC1? ;-)
I will do so soon, hopefully this weekend if I have some free time. It looks very useful based on your web pages, and I like the keep-it-simple approach. Dave
Thank you for the kind words.
And now it's not only me moving SqueakMap forward, I have gotten company by Daniel and Ned which makes it all much more promising! Developer mindshare is very important - a lesson learned over and over in the OpenSource world...
SqueakMap sofar has been designed and implemented with simplicity in mind, there are numerous examples:
1. Registering a package is done using ONE web form submit. Nothing else. For this reason I avoided creating "accounts" in SqueakMap because then you would have to register as a user first which would make the threshold higher.
2. The distribution mechanism is based on a simple transaction count scheme. Simple but effective - and we can actually make it much more efficient - but I haven't bothered yet. Currently every small change in a registration will save the whole registration as a new transaction. We could instead save only the changed fields.
3. The choice of storing the passwords as SHA hashes inside the map means that a client map can be identical to the server map. This is also the reason why SqueakMap can't tell you what your password is - it simply doesn't know.
And now seeing that this little baby is really starting to fly I have also realized that:
- Much of the success with SM has to do with it being "backwards compatible". It offers new mechanisms without shutting the door in your face if you don't use the super-mega-new-special-format. - It only tackles a part of the problem: The catalog of packages. It doesn't and will not (as long as I have some leverage) try to tackle namespaces, source code management or module analysis.
To be fair though it *has* established a namespace for packages - each package is required to have a unique name. But the name is allowed to change - the package has a UUID.
And it *has* code for installing packages in different formats - so in this respect it covers both package installation ("dpkg/rpm" in the Linux world) as well as package cataloguing ("apt-get/urpmi" in the Linux world). But on the other hand, the installers are "pluggable" so if anyone here has a package format you like for Squeak code that isn't supported yet - help out and add a subclass of SMInstaller. :-)
For example, one of the most important formats isn't implemented yet - the .pr format (Project). This is also because I wasn't sure it should be considered a "code package format". Perhaps it is more of an "attachment" thing for packages?
Enough blabbering, regards Göran
PS. Yes, we need to fill the page on minnow about SM... Perhaps someone could help out writing a good introduction? DS
Hi dan and others,
I just want to say two words about forking.
I think that the big bang approach we all dreamed a year ago (especially me) failed for various reasons (mainly not enough resources allocated, a complex model and having an existing image). Apparently incremental process is the way to go in such a situation. We learned it.
Now what is the most important is not to have model x or y but that people realized that we could really have a mini-image and a build process. That images are good for developing and feeling like home but that clever changeset are needed. I think that as soon as we will have a good working system it will improve gradually, I'm sure that once the basic issues of packaging modules will be resolved (there are already), dependency analysis and management, new architecture (such as the already working file list in 3.3 or the dynamic menu proposed by daniel) will arrive as well as versioning and eventually namespaces.
I still dream about ScrSqueak, SqEtoy and all the other ones we could have build on a mini-core and a building system. I think that the effort of daniel, Avi and goran are driven by concrete problems and this is good. They should continue.
Stef
stop talking and latexing again and again.....
Hi Gang,
About 18 months ago, I pointed out to this list that modules, or components, are a complex and very difficult problem. I was ignored. Recently, a number of folks on this list have come to the hot conclusion that modules, or components, are a complex and very difficult problem. What a surprise. So, just this once, I'm going to say, "I told you so." :-)
Before anyone gets serious about modules, or components, they must deal with issues of architecture and interfaces before they get down into the design and implementation details of modularity, namespaces, interdependencies, et al. While there have been a few references to "architecture" and "interfaces" on the list over the past 18 months, the focus has been on design and implementation, which puts the cart squarely before the horse.
Having said all of this, where do we go from here? I have a few suggestions:
1. Squeak 3.3 is a dead duck which should be set aside as: (1) a source of ideas for any future work on modules, (2) a monument to ambition over common sense engineering, and/or (3) a mechanism for torturing graduate students (re: thesis advisor to PhD candidate says, "Here. Take this code and make it work".)
2. Squeak 3.3 should be salvaged for anything that can be backported to 3.2. Some of this has already happened.
3. Continue the Squeak development stream starting with Squeak3.2-4956, which appears to be the last "stable" version. Add the Squeak Map and related stuff (Vainsencher, et al). Add the VI4 stuff (Hannan, et al). Package the results of all this as Squeak 4.0 and declare victory.
4. Squeak 4.0 should become the Squeak upper bound while Squeak 2.8, or Stable Squeak, should become the Squeak lower bound. Somewhere between the upper bound and the lower bound, define a Squeak Base Platform (SBP). The SBP becomes a thoroughly debugged and documented platform from which the fans of modules can work as well as a platform for other folks who might want to use Squeak for something useful. We can have lots of fun fighting over where to draw the SBP baseline.
I am serious about this. Squeak 2.8 is more than enough for me to handle. Squeak 3.2 is about three (3) times the size of Squeak 2.8. Whatever happened to that "exquisite personal computing environment that one person can comprehend"? With or without modules, nobody is capable of fighting their way through hundreds of thousands of lines of code. Apparently, this fact has torpedoed the various module efforts to date.
Well, this is more than enough for now.
Cheers, Roger.....
John M McIntosh johnmci@smalltalkconsulting.com wrote:
I'll point out some smalltalk implementations ask the executor what to do and give it reference to the 'dead' object as part of the finalization process. The executor can then decide to 'resurrect' the 'dead' object by making a reference to it again. Tho somehow my head hurts when asked to justify this action and the business model that would require you to do it.
I don't know a reason, either, but note that it's a lot of trouble to *stop* people from ressurecting things! Also, it's not hard to just mark objects with a "finalized" flag; if an object has already been fianlized, then you deallocate it instead of running the finalizer. (Assuming that you don't want to re-finalize ressurected objects at their second death. This seems fine -- again, this is goofy code we are talking about!)
These problems are avoided in Squeak, because Andreas set it up to run the executor only when the object is *really* dead.
Lex
squeak-dev@lists.squeakfoundation.org
-
Andrew C. Greenberg -
Craig Latta -
Dan Ingalls -
David T. Lewis -
goran.hultgren＠bluefish.se -
John M McIntosh -
Lex Spoon -
Peter Crowther -
Roger Vossler -
Stephane Ducasse -
Tim Rowledge