Squeak-dev March 2000

squeak-dev@lists.squeakfoundation.org

131 participants
580 discussions

RE: {UPDATES] Re: [BUG] 2.8a -- Hand Morph problem?
by Norton, Chris 01 Apr '00

01 Apr '00

Thanks for the quick Saturday fix Dan! ---==> Chris > -----Original Message----- > From: Dan Ingalls [SMTP:Dan.Ingalls@disney.com] > Sent: Saturday, March 25, 2000 1:28 PM > <snip> > Yes this was a problem, and I have just added another update -- my chance > to pay Andreas back for his help last night. > > There's the scoop: > > 1973ColorCacheFix -- Dan Ingalls -- 25 March 2000 > The method balancedPatternForDepth: was leaving colors with cachedDepth > defined but cachedBitPattern == nil, a violation of the cache conditions. > > Update again if you updated before this came out. > > - Dan >

2 1

Re: [Q] executing SOME compiledMethod (classless)
by Henrik Gedenryd 31 Mar '00

31 Mar '00

Peter Novak wrote: > We are working on > prototypes in Squeak. Great, finally someone's doing this. Let's hope you actually finish it. This is such a commendable effort that I think if you just succeed to convince us all that you're serious enough :) , you'll garner a good deal of support and interest from others--in part I am thinking of myself here; please tell us more about the whats and whys of your project! Regarding your question of classless methods, which now turns out to be the question of classless objects in general I suppose. (Forgive me if my answers are on the wrong level--I don't know how much you already know about these issues.) > We need something like executing SOME byteCode without having it installed in > any class. One quick and dirty approach used in Smalltalk is to use Behaviors directly, instead of full-blown classes. But this does give you an extra Behavior object per object. It will get you part of the way however. There is a somewhat niftier approach too: If you make the prototype (classless object) inherit from Behavior (hey--it has to have a class in the object header), then you can install the method directly into the object itself. I think there are some VM dependencies that tie methods to Behavior, but for the final answer you should consult Yoda himself. I may be wrong here, I don't know the primitives well enough, but you may not even need to install the CompiledMethod into a method dictionary. (Err, and welcome to the world of Behavior, ClassDescription, Metaclass, and friends--the dark side of the image.) Referring to what Bob said, you'd have self point to this object as well. I feel like I'm repeating myself from previous posts now, but this is not the lion's share of the work, as one would think. Wait till you try to use the browser together with your new scheme... The following sentence rang a bell: > We want to have in our prototype based system as few bindings to Smalltalk > class system as it will be possible. The browser code and logic is very hard-wired to the current class system and inheritance scheme. But to approach a more final answer to your question about prototypes & methods, you must consider how inheritance (or what you choose to call it--delegation etc.) should work with your prototypes. That is the real issue. The present hard connection between method execution and classes (or behaviors really) is a consequence of the current inheritance system. If you haven't already thought about this, I suggest that you study the Self approach, and it would be great if you adopted that approach too. It would spare you from doing the same thiking all over again. Henrik

2 1

Re: Musings on Identity
by Stephan Rudlof 31 Mar '00

31 Mar '00

Paul McDonough wrote: > > In the course of the abandoned Jigsaw project, ParcPlace-Digitalk's team > implemented a very similar interface/implementation split in the Collection > classes. Although the project was dumped, Why? Stephan > that part of it was (if memory > serves) complete and in use internally. Presumably, the code still belongs > to one or more of: Cincom, SEAGULL, ObjectShare, StarBase. As far as I > know, nobody's using it and it's just sitting on some server somewhere. > Perhaps the owning company (my guess would be Cincom?) could be convinced to > toss at least that slice of Jigsaw out as open source and let the world have > its way with it ... ? -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

1 0

Re: [Q] executing SOME compiledMethod (classless)
by Stephan Rudlof 31 Mar '00

31 Mar '00

I wrote: > > The receiver of a message like > perform:withArguments: > is necessary just to find the corresponding CompiledMethod in its class > or superclass. For executing a CompiledMethod which doesn't refer to the > class where it belongs to, we don't need this class. > > So we don't need a receiver to execute *such* a compiledMethod! > > But if it accesses e.g. inst vars of an object instance of some class > where it has been compiled in, then we are not able to use it senseful > with other receivers not being instances of this class. It would be a problem already, if there is just a ^self inside the compiled method... (this refers to a receiver) Stephan -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

1 0

Re: EPS from Squeak
by Marcel Weiher 31 Mar '00

31 Mar '00

> From: Marcel Weiher <marcel(a)metaobject.com> > > From: Stephane Ducasse <ducasse(a)iam.unibe.ch> > > > > For that, I would like to extract piece of Squeak environmnent as EPS > > I saw that I can ask a morph to print itself in PS (cool). > > A typical morph will save itself as an EPS, ready for inclusion > (although it does include a showpage command and a little positioning > magic so it will typically print OK by itself as well). I should have included that BookMorphs are currently the only "non-typical" morphs that don't write themselves as EPS. Instead, they generate multi-page Postscript files that include all their pages, but *only* if they are the "top-level" morph that is being printed. If a BookMorph is encountered as content of another morph that is generating EPS, only the currently visible page will be included in the output. Marcel

1 0

Re: EPS from Squeak
by Marcel Weiher 31 Mar '00

31 Mar '00

> From: Stephane Ducasse <ducasse(a)iam.unibe.ch> > > For that, I would like to extract piece of Squeak environmnent as EPS > I saw that I can ask a morph to print itself in PS (cool). A typical morph will save itself as an EPS, ready for inclusion (although it does include a showpage command and a little positioning magic so it will typically print OK by itself as well). > Now I would like to be able to select a part of the environment > and save it as EPS, is there something already in Squeak for that. Not really. You could just save the entire world and then clip the parts you really want. What might work is a "print"-morph that displays a rectangular section of the world, similar to the zoom thingy, but drawing using morphic instead of pixel-pushing. Printing that morph would then get you what you want. Extending that slightly could then give you scaling, n-up printing etc. Marcel

1 0

EPS from Squeak
by Stephane Ducasse 31 Mar '00

31 Mar '00

Hi I'm writing a small booklet that explain to kids our turtle environment and explian also some programming concepts. Previously I was using Word but I'm really fed up about that and started to use LaTeX. ( I hate it less than Word and Framemaker but still ;)). For that, I would like to extract piece of Squeak environmnent as EPS I saw that I can ask a morph to print itself in PS (cool). Now I would like to be able to select a part of the environment and save it as EPS, is there something already in Squeak for that. In particular what does the copy postccript menu? Then I would like to know if the trails made by the player can be saved as eps? For the moment I'm extracting a pict file converting it to eps, so this is ok one solution would that I produce directly latex for the figures the turtle does. Any suggestions are welcome Stef By the way the pdf of the lectures are available: http://www.iam.unibe.ch/~ducasse/WebPages/Teaching.html#turtle Stephane DUCASSE (ducasse(a)iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes University of Bern, Institut fuer informatik and Mathematik IAM-SCG, 10 neubruckstrasse, CH-3012 Bern, Switzerland.

3 2

Re: Musings on Identity
by Dan Ingalls 31 Mar '00

31 Mar '00

><fontfamily><param>Monaco</param>Some ideas for Squeak 3 >:-)</fontfamily> <fontfamily><param>Monaco</param> >Currently the object header contains a 12 bit field for an identity >hash. This is too little and too much at the same time: it takes >valuable space in the object header and it is insufficient for large >IdentitySets or -Dictionaries. > >Therefore how about ditching this field alltogether and >reimplementing IdentitySets as arrays sorted by oop ? > >Lookup should be reasonably fast using binary search. >Since the garbage collector only shifts objects but does not shuffle >them, the sort order would not be affected by compaction. >Become operations would necessitate resorting of affected sets >however. >IdentityDictionaries could be built using parallel arrays for keys >and values. >Insertion and deletion might become slow for very large sets. If this >really becomes an issue those sets could be split into a sorted array >of subsets with a two stage lookup. > >Has this been done before ? >Any flaws in the resoning ?</fontfamily> Georg - People have ditched the hash field, and then constituted it lazily on demand for such objects that need an identityHash, either in an alternate header format, or in a look-aside cache. Both of these schemes add complexity, but they also do the job right. Right now in Squeak, when hashing fails to discriminate, we use linear search, which leads to an access time proportional to N//4096. So binary search would be an improvement for tables larger than about 64K entries, and it would be about 10 times better for sets with a million entries. I had essentially the same idea as you are proposing a couple of years ago. At that time I needed an identityDictionary of potentially all objects in the system for the SystemTracer. Fortunately, the need is usually only for a relatively small portion of the objects (pointer objects for which not all the internal references have yet been written out). You can see that I bailed out and hacked a linear secondary probe with usage-based promotion for this requirement, instead of discarding indentity hashes as you propose. When I first thought of doing what you propose, I thought it would be too ugly because it would require exposing oops, and all sorts of things could go wrong because oops change over time. For instance, what if you hit a gc partway through comparing the oops of two elements? You would have to make sure you asked for their oops at "the same time"; from then on things should be OK because garbage collection preserves the order of objects in the system. This last point led me to the realization that you could do adopt this approach AND do it all safely in Squeak IF the primitive capability were packaged in the form of a comparison primitive <<ProtoObject> identityPrecedes: otherObject <<primitive: NNN> self primitiveFailed You are right that such IdentitySets would be invalidated by become:, but this is true now for forwardBecome which can change the hash associated with a reference (we made symmetric become preserve the hash associated with references). Two more things to consider... * What other use do you have for the hash bits in the header? * Would you care as much if we did away with the compact class field and extended the number of bits in the identityhash from 12 to 17? This would move the crossover point above from 64K to 2 million entries. One proposal would be to at least implement the comparison primitive above. Then anyone who really cared could build their own GiantIdentitySet with log N performance. One could even get log (N//4096) by using a two-level structure with hashing in the first level and sorting in the second. - Dan

1 0

Re: Musings on Identity (hashing tricks)
by Allen Wirfs-Brock 31 Mar '00

31 Mar '00

"lazy hash fields" is a way to get a larger range of identify hash values without significantly increasing the average object size. We have successfully used all of the techniques described below in various implementations. Basic idea: Asume that the identify hash is not actually accessed for most objects. So, use a extra object slot to hold the hash value but only allocate this slot when and if the hash value is actually accessed. Exploit the fact that the garbage collector moves objects to simplify dynamically adding the hash slot. Details: Allocate two bits (the hash tag) in the header with the following interpretation: 0 hash value has not been accessed, no hash value assigned. 1 hash value has been accessed, hash field not yet allocated 2 hash value has been accessed and the hash field has been added 3 unused, reserved, special, etc. Most objects are initially allocated with a hash tag of 0. The first time an attempt is made to access the hash value of such an object, its hash tag is set to 1 and a hash value is assigned. The value must be assigned in such a way that it can be regenerated or retrieve on subsequent accesses. There are at least two possible ways to do this: a) use some function on the current address of the object as its hash value; b) assign an random value as the hash value and store that value in a "look-aside" table, keyed by the object's current address. (using the address as the value is simpler but may not provide a very good distribution of hash values) When the hash value is accessed for an object whose hash tag is 1, the current address of the object is used to either recompute its hash function or to access the look-aside table, as appropriate to the implementation. When the garbage collector needs to move an object it most check the value of the hash tag. If the object to be moved has a hash tag of 1 the GC must extent the object in a implementation defined way with an additional field to contain the hash value. Common approaches are to added the field at the end of the object or as a negative offset from the base of the object. After allocating the field the GC computes the hash value or retrieves it from the look-aside table and stores the value in the field. The hash tag of the object is set to 2. If a look-aside table is used, the object's table entry is freed at this time. When the hash value is accessed for an object whose hash tag is 2, the hash value is simply retrieved from the extended hash field. Various interesting elaboration are possible. For example, if there are permanent objects that can not move the extra hash tag value might be used to say use the object's address as the hash value. (Or, if the implementation does not use a look-aside table, just use tag 1 to indicate this.) It is sometimes useful, to have the ability to explicitly set an object's identify hash to a specific value. For example, the world is simpler if an externalized object can be reconstituted with the same identify hash value it had when it was externalized. Note that it is perfectly safe for a program to assign arbitrary identify hash values to an object up until the first time that the object's identify hash is actually accessed. The look-aside table variation makes its very easy to do this. Simply add a set identity hash primitive that creates look-aside entries for objects whose hash tag is 0. (Fail for other tag values) Happy hashing, Allen_Wirfs-Brock(a)instantiations.com

1 0

Re: [Q] executing SOME compiledMethod (classless)
by Bob Arning 31 Mar '00

31 Mar '00

On Fri, 31 Mar 2000 16:22:42 +0200 "Peter Novak" <pno(a)whitestein.com> wrote: >But imagine concurrent Workspaces where SOMEONE (doesn't matter now who - >maybe people working in distributed environment) want to evaluate his own >expression in his own workspace. Now You have a problem, because you are not >able to say whose #DoIt will be executed at the moment. Peter, I suspect that this is far from the only problem you will encounter with multiple users sharing one image like that. Too much stuff is not thread safe. One option for the doIt problem (and you did touch on it) would be for each user to have a private class in which context doIts are evaluated (i.e. evaluate the code in PeterNovaksPrivateClass or BobArningsPrivateClass rather than in UndefinedObject). But, as I said, this may be the least of your problems. Cheers, Bob

1 0

Jump to page: