Squeak-dev March 1998

squeak-dev@lists.squeakfoundation.org

67 participants
130 discussions

Re: On a more...(Inboard Squeak Source)
by Mike Klein 03 Mar '98

03 Mar '98

> More generally, some of the losing changes/sources problem could > probably be helped by the suggestions bandied aruond a while ago > about putting the sources 'in the vm' in some sense (ie mac resource, > windows resource, Acorn app.dir., unix links etc) and perhaps, by > making releases that have condensed sources and null change logs (so > it gets created on first startup rather than being looked for). I was going for the minimum cognitive overhead. People are used to the idea of an "application & document" on their host OS. VM = application image = document Simplicity itself. Why hide the sources in the VM? Make them accessible and understandable from within Squeak. What could be eaiser to understand than having CompiledMethods having an instVar named 'source' that points to a string? What could be easier to extend than having a source pointer that points to an object? One could always have a method that externalizes the sources, so people who understand the sources/changes mechanism could easily generate them. I'm always seeing people new to Smalltalk doing things like starting an image from a directory other than the current working directory, and then saving image to a new name. It doesn't work right in squeak. The changes gets copied to the original image directory, but the new image gets saved in the current working directory. (VW can't even find the changes file BEFORE saving). -- Mike Klein

1 0

Re: Prototypes
by johnson＠cs.uiuc.edu 03 Mar '98

03 Mar '98

I would like to throw some cold water on this love-fest. I've been following the class vs. prototypes discussion since 1987. I've built a prototype based application (in Smalltalk, of course). In my opinion, "the emperor has no clothes". Anything you can do in a prototype language, you can do in Smalltalk just as easily. It would be a waste of time to restructure the VM to be based on prototypes. I agree that it is often useful for a programming environment to prototype-based. But this does not require the language to be based on prototypes. Bob Hinkle wrote the "Object Inspector" that lets you place breakpoints on a single object. He provided library support that lets you give any object its own method dictionary so you can hack on it without affecting any other objects. He has a subclass of Behavior called "LightweightClass" and there is a method that makes an object replace its class with a LightweightClass that is a subclass of its old class. Then you can add methods to its class without affecting any other object. We used it in a Hypercard clone to add behavior to buttons, and in a Alternate Reality Kit clone to add behavior to objects. Plus, Accounts was based on prototypes, but entirely at the application programming level, without any meta programming support. BTW, the one VM hack that is useful in LightweightClass is the ability to set the class of an object. You can get around this by making a shallow copy of the object, but with the new class, and then having the old copy "become" the new one. -Ralph

1 0

Re: Prototypes
by David Stes 03 Mar '98

03 Mar '98

Steve Dekorte wrote: > > You really don't have to "throw away" anything. From a "class" > consumer's point of view, there's no difference between a class > and a proto with the clone method renamed "new". I think in practice you will have to remember at least that there's protos and protos that act like classes. You have (I mean Steve D.), in the Objective-C case, been advocating similar changes, and in fact some implementations of Objective-C have been changing somewhat to arrange methods not to be grouped in classes, and changing the way instances are created. Was is it in the end worth it? Did we win anything by adding methods that have "new" as special case? In my opinion, no. I just stick with how it originally was (in my implementation of Objective-C) as in Stepstone ICpak. I like the way it's class based, and in fact, for extensions, I use Squeak as *reference* implementation. That doesn't mean that I don't sometimes design a class with the prototype/clone paradigm for creating new instances, but it is not because something _sometimes_ is convenient and a good idea, that you have to make a *global* transformation to use it "everywhere".

1 0

Re: On a more mundane level Was: "Open Implementations
by Mike Klein 03 Mar '98

03 Mar '98

[Snip on new person losing source, and explaination of sources & changes] > The VM > a '.image' file > a '.changes' file > a '.sources' file. In Squeak 1.3: CompiledMethod allInstances inject: 0 into: [:total :each | total + each getSourceFromFile size] 3939446 Hmm... 4 Megabytes. If we kept the source in the image it would only cost 4 Megabytes. No more wondering if the image has the right path to the source/changes files. No more newbies asking what 't2' means. (Your source has been terminated :-) No more CR/CRLF nonsense causing run-on (or double-spaced) methods. No more questions as to source file encodings. Ability to experiment with non-string source representations. People used to say windowing systems were a waste of computer power, while command line interfaces were cheap. What is the power of the computer to be used for, if not for the user? I can't imagine anyone who is learning Squeak to miss an extra 4M. I'm sure that the people who are getting Squeak to run in a limited environment will be dealing with far more complex issues, and having to strip out the source will be quite minor. Opinions? -- Mike Klein

2 1

Re: Prototypes
by Mike Klein 03 Mar '98

03 Mar '98

Craig Latta wrote: I do think it's a mistake to think that classing is a required "first principle" of object-orientation; it's just a implementation detail supporting method lookup that's been around for a long time. (The really important things for me are messages and autonomous computational units of state and behavior.) I agree with this. I wanted to point out a very common and annoying problem with a lot of Smalltalk code. Every object has a "hidden" instVar that points to it's class. The mandates of OO say that we should consider this slot "private". Yet Object implements the #class method to turn it into essentially a public instance variable (fortunately read-only). This seems to "encourage" code that makes decisions based upon the class of an object. (Just look at senders of class and isKindOf:, compared to the less intrusive respondsTo:. I'm not talking about tools such as the debugger & inspector for which sending #class makes sense.) -- Mike Klein

1 0

re: the decompiler
by Tim Olson 03 Mar '98

03 Mar '98

> >Hi-- > > Why not just make decompiled method sources have a friendly little method >comment, saying something like "This is decompiled code." or somesuch, >perhaps even with a hyperlink to instructions on setting up the sources >databases? This can be done by modifying a single method: 'From Squeak 1.31 of Feb 4, 1998 on 3 March 1998 at 12:45:32 pm'! !DecompilerConstructor methodsFor: 'constructor' stamp: 'tao 3/3/98 12:45'! codeMethod: selector block: block tempVars: vars primitive: primitive class: class | node precedence regenComment | node _ self codeSelector: selector code: nil. precedence _ selector isInfix ifTrue: [2] ifFalse: [selector isKeyword ifTrue: [3] ifFalse: [1]]. tempVars _ vars. node _ MethodNode new selector: node arguments: (tempVars copyFrom: 1 to: nArgs) precedence: precedence temporaries: (tempVars copyFrom: nArgs + 1 to: tempVars size) block: block encoder: (Encoder new initScopeAndLiteralTables nTemps: tempVars size literals: literalValues class: class) primitive: primitive. regenComment _ OrderedCollection with: 'source automatically re-generated by the Decompiler' with: 'temporary variable names may have been substituted with t1, t2...'. node comment: (node comment isNil ifTrue: [regenComment] ifFalse: [node comment addAllFirst: regenComment; yourself]). ^ node! ! -- tim

1 0

On a more mundane level Was: "Open Implementations
by CYNTHIA NELSON 03 Mar '98

03 Mar '98

At 03:52 PM 3/1/98 -0800, Alan C. Kay wrote: >At 3:36 PM -0800 3/1/98, Bruce Cohen wrote: Hi, I have a more mundane question than the those that normally are posted to this list...however I would like to know WHAT I am supposed to do about the fact that ver 1.31 seems to capriciously change my carefully chosen temporary variable names to t1, t2,.... This is a royal waste of my time to have to go back an change this. I have tried everything in the "documentation" to no avail. I even created a changes folder before I saved as something else... nothing seems to work. Also I have had a problem saving workspaces to an external text editor sometimes it works and sometimes it does not. I am used to C++ (OK throw MUD now) where everything may be very verbose and dangerous for the inexperienced but at least it is fast and reliable...maybe that explains part of my frustration. Now you guys are most likely going to say it is a bug in the C compiler used to create Squeak that is to blame. I do not care just answer the question I would appreciate it. Cindy Nelson PS. I would like to try the sound capabilities since I am a professional musician but first the "nuts and bolts' have to work before I spend my time...and NO I do not use a Mac. **************************************************************************** ******************************* Cynthia L. Nelson Phone: (770) 622-6805 P.O. Box 846 Fax: (770) 622-2779 Duluth, GA 30096 e-mail: cindynelson(a)abraxis.com

4 3

Re: more prototypes
by n.moray＠surrey.ac.uk 03 Mar '98

03 Mar '98

The phrase is "ex nihilo" - classical Latin for "out of nothing" :>) >It has already been mentioned that there are two ways to >create new objects: > > - ask a factory object to build one from a kind of blueprint > - ask a similar object for a copy of itself > >There is also an important variant of the first kind - ask >a special factory (the parser) to build an object from a >textual description, like > > #('help' with this 2) > >This is sometimes called "creating from nothing" (or >"ex nilo" creation, or something equally silly) which >is only accurate if we consider the parser to be >nothing. > >One important use of classes is as a factory object that >understands the #new message. We don't really need this, >as cloning and literal object are quite sufficient. But >classes also are used for reflection - they hold the >meta-level information about their instances that is >needed by the programming environment. > >If we eliminate classes, then we will need to create new >objects (Self calls them mirrors) so we can still write >the programming environment within the same language. So >it would seem that nothing is gained by getting rid of >classes, but this is not true as these mirrors can be >created "on the fly" only when needed instead of having >to hang around all the time. > >My own experience is that having to create classes before >you can make an instance is as bothersome as having to >declare all of your variable types. It is so much better >to point to something on the screen, copy it, call up its >definition and then start hacking away. With the ability >to drag-n-drop objects, cleaning up the mess you make is >hardly a chore later on. > >-- Jecel Work email: N.Moray(a)surrey.ac.uk Home email: nmoray(a)globalnet.co.uk send messages to both if Urgent Work address: DERA Professor of Applied Cognitive Psychology, Department of Psychology, University of Surrey, Guildford, Surrey GU2 5XH United Kingdom. Phone number: +44-(0)1483-300-800 and ask for extension 2865 Fax: +44-(0)1483-32813 Home address: 10a Hampstead Hill Gardens, London NW3 2PL. Phone: +44-(0)171-431-4813 "Be well, do good work, and keep in touch" (Garrison Keiler)

1 0

Re: On a more...(Inboard Squeak sources)
by Mike Klein 03 Mar '98

03 Mar '98

1) I would never give up the security of the change log. I want the sources internally in addition. (You people saving hard-disk power can disable if you want...) 2) Having to distribute a new changes file with each new revision kind of defeats the purpose of having an unchanging sources file. Besides, The changes file is almost twice the size of the sources. Does the changes file contain the source of every released method (including past released versions)? 3) I know that it's easy to change. But if I do it in my own little world, all of those people who are getting their first take on Smalltalk from Squeak do not benefit. (I am an experienced Smalltalker, and my first take on Squeak was: "Sheesh... I can't seem to get the line end convention to show all of the methods properly.... what a hassle"). 4) Having things internal has the nice feature of not needing weirdo platform- specific configuration. If the windows come up, "everything" works. 5) A quick dig around in Squeak (especially internalizeSources, etc.) reveals a rather annoying problem: CompiledMethod is a byte-type object, and therefore cannot store a pointer to a source object. It can only store some number that the source code system must then translate to the source. So much for non-string based source code... -- Mike Klein > Folks - > > It's not hard to bring the Squeak source code inboard -- it actually all > worked once. Look at the methods like SystemDictionary makeSourceInternal > (or the like -- I'm away from my machine right now). > > It has one wonderful property - you can run for long periods without > spinning up the disk of a portable computer. -- and the analogous awful > property -- if anything crashes, there's nothing to replay :-( > > - Dan >

2 1

Re: On a more...
by Boris G. Chr. Shingarov 03 Mar '98

03 Mar '98

Mike, > I can't imagine anyone who is learning Squeak to miss an extra 4M. > I'm sure that the people who are getting Squeak to run in a limited > environment will be dealing with far more complex issues, and having to > strip out the source will be quite minor. Opinion: I don't think the problem is really in getting the image big, but instead a philosophical one. At least my first Smalltalk experience was with Envy, so I used to think of the image as my private resource while the common source code repository is a shared resource. Of course it will require effort to make Squeak a true multideveloper tool (to allow *simultaneous* access to the sources from different images) but we should always keep the possibility in mind. In one word, I think incorporating sources into image would be a bad idea. Boris

2 1