Spoon August 2006

spoon@lists.squeakfoundation.org

3 participants
9 discussions

Spoon progress 22 August 2006: searching swapped-out methods for literals
by Craig Latta 23 Aug '06

23 Aug '06

Hi all-- Just a quick note about a fun hack. In my quest to remove all references to the system dictionary (after making each class responsible for its own name[1]), I remembered that many of the method dictionary values in the minimal memory are nil, due to the inert-method-discarding garbage collector[2]. That would make searching for references a bit tricky, since nil doesn't understand hasLiteral: and other messages that CompiledMethod implements for the benefit of the development tools. I changed Behavior>>whichSelectorsReferTo:special:byte: et al in the minimal memory so that when they encounter a nil where a method used to be, they use a proxy on the actual method back in the master memory. Now "references" works again on the minimal memory, complete with browsing source, without having to swap any methods back in. If you haven't been following these progress reports, then the above may make absolutely no sense, but I think there are at least a few of you out there. ;) The larger point is that I'm getting close to deleting SystemDictionary. thanks, -C [1] http://lists.squeakfoundation.org/pipermail/spoon/2006-July/000124.html [2] http://lists.squeakfoundation.org/pipermail/spoon/2006-April/000107.html -- Craig Latta http://netjam.org/resume

1 0

re: Distributed Objects?
by Craig Latta 19 Aug '06

19 Aug '06

> Craig Latta's project, Spoon, does (as far as I know) remote object > invocation. http://www.netjam.org/spoon. You get a tiny image for > free. That's right. Spoon's remote messaging system supports arbitrarily nested sends (local object A sends to remote object B which must send another message back to A before answering A's first message, etc.). It also supports messages whose parameters live on multiple different machines. Finally, the system works across multiple processes on the same or multiple machines, and the contexts of a single process can span machines (as can happen during remote debugging). In my use so far, it has provided a transparent illusion of a co-located set of objects across multiple machines. But I was hesitant to respond to Rich's original request, because Spoon isn't yet directly interoperable with mainstream Squeak releases (we're working on it). thanks, -C -- Craig Latta http://netjam.org/resume

1 0

re: Strange Process Question
by Craig Latta 17 Aug '06

17 Aug '06

Rich writes: > Can I suspend myProc and save it to disk (seperately from quitting and > saving the whole image)? Can I load it into different objects and > resume it? Can I sneaker net it to a different machine and load it in > a completely different copy of Squeak? Or will bad things happen? Okay, you all saw it coming, but I'll say it anyway. :) This is straightforward in Spoon, although a process is transferred directly from one running system to another (not to a distinct storage artifact first). The providing system can ensure that all the necessary objects Colin described are present in the target system, while actually transferring only those objects which are missing from the target system. Both systems have a clear notion of exactly which versions of all classes and methods are present. If the target system is extremely different from the providing system, then it's possible that a tremendous number of objects may need to be transferred. But I expect the typical case would be that the target system is a simple copy of the providing system before the process was started, so in most cases relatively few objects would need to be transferred. It's worth noting again that Spoon transfers all method literals perfectly, including shared ("pool") variables. This is something that is notoriously error-prone when the transfer medium is source code or static serialization (e.g., Squeak's ImageSegments or ReferenceStreams, VisualWorks' BOSS). And this is possible because the target system gets a say in what to transfer and how to transfer it, right while the transfer is taking place; the providing system doesn't have to decide all that by itself. Finally, one can distribute work amongst multiple systems at a finer grain than processes (namely, at the level of individual message-send). Cheap message-sends could remain local, while expensive ones happen remotely (e.g., on remote hardware sufficiently fast to amortize the network overhead, which would certainly be the case if the message-send runtime is on the order of three hours :). Everything is still happening in the same process as far as the local system is concerned, and you can still debug everything live from one place. -C -- Craig Latta http://netjam.org/resume

1 0

Some questions about Spoon
by stéphane ducasse 12 Aug '06

12 Aug '06

hi all I'm surprised not to see development discussion on this mailing-list except craig reports. Do you use another way of communicating? Then how do you share code and enh do you have a repository? Stef

3 9

re: Modularity again
by Craig Latta 10 Aug '06

10 Aug '06

Hi Dean-- > Since modularity and reuse are somewhat at odds with each other (much > like time and frequency, MIPS and memory usage, etc.) this raises the > question of what is a "good" balance between modularity and reuse? > > Also, what constitutes a "minimal" image? I think there are almost > as many answers to this as there are users of Squeak. > > Do most people really care about modularity, or do they just want > a way to get a small artifact (i.e. image) for distribution? > > I will stop before I get too far down another rat-hole. Thanks for spurring discussion! -C -- Craig Latta http://netjam.org/resume

1 0

fwd: Modularity again
by Craig Latta 10 Aug '06

10 Aug '06

Hi-- Oops, another thing I forgot to CC to this list (just a few minutes ago). The discussion started on squeak-dev, and the other respondents aren't CCing the Spoon list. I apologize for any confusion. -C *** -------- Original Message -------- Subject: re: Modularity again Date: Wed, 09 Aug 2006 15:28:16 -0700 From: Craig Latta <craig(a)netjam.org> Newsgroups: gmane.comp.lang.smalltalk.squeak.general References: <OFEBD9AE84.72F7EF46-ON852571C4.005E8A39-852571C4.005FC556(a)mitel.com> <44D8D872.7000608(a)gmx.de> <D2681BEB-8DB2-486F-8F9E-33F9AA816947(a)wiresong.ca> <44D92CD6.4090409(a)netjam.org> <E151FF61-E313-43AD-B8A5-06632541E68E(a)wiresong.ca> <44D98889.9040300(a)netjam.org> <44D99352.2000601(a)gmx.de> Hi Andreas-- > > I certainly agree that any successful modularization strategy > > includes ugly grunt work (I'm doing it too). But I think Andreas > > said more than that: that the fitness of Spoon's tools for this task > > can only be evaluated when the task is finished. If everyone held > > that view, then no one would use Spoon's tools for the task. It > > seems to imply that I, Craig, must disentangle the entire system > > before it's worth anyone else's while to use Spoon. I don't think > > this is true. > > And I don't think it's fair to accuse me of that. I'm not accusing you of anything, Andreas. :) I was telling my interpretation. I went on to mention that perhaps my interpretation was an exaggeration: > > Perhaps I exaggerate. Perhaps disentangling some subset of the > > system would be suitably compelling. At any rate, I continue making > > modules. *** > What I said is that "if [spoon is being followed as the *only* path], > I'd say that I'll answer that question once I've seen the first system > that has been built that way ;-) " - with an "if" at the beginning and > a smiley at the end. Right, I got all that the first time. I still take issue with it: I think it would be better to discuss the design ideas in the meantime, in addition to evaluating artifacts. > More specifically, what I'm saying is that we should base our judgment > of ideas on observable evidence rather than faith. In other words try > to be a bit scientific. Well, several of us in the Squeak community have experience with the implementation of the system, and there is a release of Spoon that implements the basis for what I'm talking about[1]. It seems to me that we are in a position to discuss the merits of the design ideas, so as to improve them. More importantly, we can decide how we want the system to work (what the "usage experience" should be), so that we have a basis for evaluating the results. I think of this as defining a vision and pursuing it. thanks, -C [1] http://ftp.squeak.org/Spoon/spoon1a12.zip *** -- Craig Latta http://netjam.org/resume

1 0

fwd: Flow 3a release progress update
by Craig Latta 09 Aug '06

09 Aug '06

Hi all-- I should have forwarded this at the time, since Spoon uses Flow (at least until unloaded). Sorry... Brenda, please CC the Spoon list on future progress reports (it occurs to me now that it'd be a good idea). Thanks! -C -------- Original Message -------- Subject: [Flow] Flow 3a release progress update Date: Tue, 11 Jul 2006 23:47:07 -0700 From: Brenda <asparagi(a)hhhh.org> To: flow(a)lists.squeakfoundation.org, io(a)lists.squeakfoundation.org As I think a few of you know, I am putting together a new release of Flow based on Craig's current code. Craig is still Flow's owner; I am mostly providing release management assistance. Craig did some significant refactoring (go, Craig!) since Flow 2a, so we will be calling this Flow 3a. It is planned to work on Squeak 3.2, 3.6, 3.7, 3.8 and 3.9. All class names will begin with Flow, to eliminate naming conflicts with the stock networking library. One of the many reasons you want it (truly, madly, deeply) is that it is a prerequisite for Squeak images exchanging messages with Spoon images. I don't know when the new package will be available, but I will send status updates here (the Flow and IO mailing lists) after I make more progress. Current status is that I have Craig's latest Squeak bits. I found all the classes that will go into the Flow 3a release, and put them in appropriate categories. They are mostly renamed to their new names. I will send a class hierarchy diagram with the new names shortly after I finish renaming. In addition, I am combining parts of my URI implementation (which will be included in Flow 3a in lieu of the *Locator classes) with Craig's SocketAddress class. These things are the only refactoring I am planning to do before release -- the intention is to release as quickly as possible. After the steps in the above paragraph are done, Craig & I will both do some testing to confirm I didn't break anything. It is possible that the easiest way to do this will be to write a test suite, but I'm not making any commitments on this point yet. Plenty to do left after that.. Brenda _______________________________________________ Flow mailing list Flow(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/flow -- Craig Latta http://netjam.org/resume

1 0

re: Modularity again
by Craig Latta 09 Aug '06

09 Aug '06

Hi Colin-- > Yes, [Spoon] provides tools that might help with [disentangling system > components]. Yes, it provides tools for dealing with modules once they > have been separated from the mess. These are excellent things. Indeed, so I thought the assertion is Spoon "does nothing to make the system more modular" was clearly wrong. > So far, though, nobody has used those tools to do any untangling. For what it's worth, I have, and am currently. I'm untangling the system dictionary from the rest of the system, and doing the same for the graphics subsystem (Display, etc.). > Note also that Dean's proposed path, which I've quoted above, doesn't > involve any rewriting or refactoring, only unloading. Clearly; and I, in turn, as the designer of Spoon, was motivated to elaborate from my point of view. > So I think Andreas is right. A modularization strategy that involves > Spoon is a fine idea, as long as it also includes the kind of ugly > grunt work that Andreas, Pavel, Edgar and others have been doing to > disentangle the mess. I certainly agree that any successful modularization strategy includes ugly grunt work (I'm doing it too). But I think Andreas said more than that: that the fitness of Spoon's tools for this task can only be evaluated when the task is finished. If everyone held that view, then no one would use Spoon's tools for the task. It seems to imply that I, Craig, must disentangle the entire system before it's worth anyone else's while to use Spoon. I don't think this is true. (Perhaps I exaggerate. Perhaps disentangling some subset of the system would be suitably compelling. At any rate, I continue making modules.) -C -- Craig Latta http://netjam.org/resume

1 0

re: Modularity again
by Craig Latta 09 Aug '06

09 Aug '06

Hi all-- On the squeak-dev list, Dean writes: > Regarding modularity, wasn't there an Idea that future work would be > based on Craig's Spoon work? That at least offers a repeatable > process: > > 1) Start with a "full" image version X.Y-Z, execute some method(s) > designed to exercize the desired funcionality to imprint a new > "minimal" image > > 2) Save the minimal image and give it a name/version. It seems that > S-unit tests of some sort would provide the basis for the method to > imprint the desired functionality. > > Is there any reason why this isn't a good path to follow? Andreas responds: > As the *only* path? Or as part of an overall strategy? If the first, > I'd say that I'll answer that question once I've seen the first system > that has been built that way ;-) ["once bitten, twice shy"] As part of > an overall strategy it's perfectly fine - there are various > interesting ideas in Spoon which can be helpful in many different > contexts. Colin responds: > I'll echo this opinion. Spoon does nothing to make the system more > modular. I assume you mean that Spoon provides no tools for untangling the current mess of behavior. That's not true. Spoon provides the ability to "imprint"[1, 2] methods from one system, as they are run, into another system (leaving all other behavior behind). When driven by unit tests, this establishes a useful starting point for more detailed refactoring. I think this is what Dean was citing. I don't think it's fair to call this mere "unloading". (In fact, I have a far more aggressive technology for that[3].) I agree that this leaves a great deal of manual and careful work for humans (preferably the original authors of each component). It is indeed hard and unglamorous work. (It is also work that I will do myself if necessary, if no one else has done it by the time it becomes my top priority.) But I'd like to point out that (in my opinion) Spoon is the best place to record the results, and does a great deal to keep the system modular once the knots have been undone. Spoon provides a module system, "Naiad" ("Name And Identity Are Distinct") with which one may clearly establish dependencies, authorship, and many other aspects of related behavior. Modules are a fundamental part of Spoon's support for software delivery. For more details (such as they are currently), please see the Spoon mailing list archives[4]. Please also see the sample module catalog[5], although it's still a work in progress (as are Naiad and Spoon themselves). I mentioned all of these things here previously. Without a solution for the modularity problem, I wouldn't have bothered with Spoon at all. Producing smaller systems is a nice side-effect, but the primary goal of Spoon is to make Smalltalk easier to learn. In my opinion, the largest obstacle for learning Smalltalk, throughout its entire existence, has been the system's poor organization (it has some, but not nearly enough). > Spoon is a good tool, but it's not "the answer." For what it's worth, in my refactoring work so far (mostly on Augment) imprinting from tests cuts refactoring time by about half. I also think we could go much further along these lines. Finally, I'd like to reiterate how unfortunate it is that we seem unable to discuss the merits of a design before the implementation is finished. I think this leads to comments such as "X is not the answer". We should be discussing what's missing, and how a design might be improved. As it is, one is simply left with the impression that a design lacks potential. I think Spoon may very well become "the answer" for this domain. I appreciate that we'll get bitten along the way, but I think demanding a finished system before evaluating the ideas or imagining how it might work is a bad way to go. thanks, -C [1] http://lists.squeakfoundation.org/pipermail/spoon/2004-October/000061.html [2] http://lists.squeakfoundation.org/pipermail/spoon/2006-May/000112.html [3] http://lists.squeakfoundation.org/pipermail/spoon/2006-April/000107.html [4] http://lists.squeakfoundation.org/pipermail/spoon [5] http://netjam.org/spoon/modules -- Craig Latta http://netjam.org/resume

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Spoon August 2006