Squeak-dev March 1998

squeak-dev@lists.squeakfoundation.org

67 participants
130 discussions

Re: Debugger bug?
by Tim Olson 30 Mar '98

30 Mar '98

>Yeah, ok, but the problem is in the debugger because when you debug the >syntax-error version, it points to 5=4 instead of pointing to #ifTrue:. Actually, the Debugger is working fine; the problem is that the Compiler in-lines code for some selectors like #ifTrue:, but doesn't set the pc value for the code in the encoder's sourceMap. This is probably because in the in-line code there isn't one unique pc value that would correspond to the message send bytecode it replaces. For the #ifTrue: case you point out, I was able to get the debugger to select the correct range with the following changes to MethodNode messages. All this code does is set the default PC value of 0 before calling the MacroEmitter, instead of after, in case the MacroEmitter itself decides to set the PC. In the MacroEmitter for #emitIf... I simply set the pc after the conditional branch bytecode was emitted: 'From Squeak 1.31 of Feb 4, 1998 on 29 March 1998 at 11:00:48 pm'! !MessageNode methodsFor: 'code generation' stamp: 'tao 3/29/98 22:49'! emitForEffect: stack on: strm special > 0 ifTrue: [pc _ 0. self perform: (MacroEmitters at: special) with: stack with: strm with: false] ifFalse: [super emitForEffect: stack on: strm]! ! !MessageNode methodsFor: 'code generation' stamp: 'tao 3/29/98 22:50'! emitForValue: stack on: strm special > 0 ifTrue: [pc _ 0. self perform: (MacroEmitters at: special) with: stack with: strm with: true] ifFalse: [receiver ~~ nil ifTrue: [receiver emitForValue: stack on: strm]. arguments do: [:argument | argument emitForValue: stack on: strm]. selector emit: stack args: arguments size on: strm super: receiver == NodeSuper. pc _ strm position]! ! !MessageNode methodsFor: 'code generation' stamp: 'tao 3/29/98 22:53'! emitIf: stack on: strm value: forValue | thenExpr thenSize elseExpr elseSize | thenSize _ sizes at: 1. elseSize _ sizes at: 2. (forValue not and: [(elseSize*thenSize) > 0]) ifTrue: "Two-armed IFs forEffect share a single pop" [^ super emitForEffect: stack on: strm]. thenExpr _ arguments at: 1. elseExpr _ arguments at: 2. receiver emitForValue: stack on: strm. forValue ifTrue: "Code all forValue as two-armed" [self emitBranchOn: false dist: thenSize pop: stack on: strm. pc _ strm position. thenExpr emitForEvaluatedValue: stack on: strm. stack pop: 1. "then and else alternate; they don't accumulate" thenExpr returns not ifTrue: "Elide jump over else after a return" [self emitJump: elseSize on: strm]. elseExpr emitForEvaluatedValue: stack on: strm] ifFalse: "One arm is empty here (two-arms code forValue)" [thenSize > 0 ifTrue: [self emitBranchOn: false dist: thenSize pop: stack on: strm. pc _ strm position. thenExpr emitForEvaluatedEffect: stack on: strm] ifFalse: [self emitBranchOn: true dist: elseSize pop: stack on: strm. pc _ strm position. elseExpr emitForEvaluatedEffect: stack on: strm]]! ! -- tim

1 0

Re: Documenting Squeak
by Stephen Ma 30 Mar '98

30 Mar '98

Hi Tansel, I think we are attacking the documentation shortage from two orthogonal directions, both necessary. Your tool for "Dynamic Document Capture" seems very useful for creating content, especially for tutorials; one screen shot can save a thousand adjectives. However, information once created needs to be organized and made easily accessible, and this is where the documentation browser can be helpful. I think both tools will be needed; both should be developed. Regards, Stephen Ma <stephen_ma(a)mindlink.net> ------------------------------------------------------------------------------ Tansel Ersavas <tansel(a)rase.com> writes: > > Stephen Ma wrote: > [snip...] > > > I agree. In my experience, the only way to maintain consistent > > documentation in a rapidly evolving system like Squeak is to attach > > that documentation as tightly as possible to the code. > > > > I'm looking forward to it! > > Thank you > > > However, Tansel, I have a feeling that even your utility may not be > > enough. There's also a desperate need for overviews and tutorials; > > these tend not to fit well into Smalltalk's traditional hierarchy of > > classes, categories, and methods. > > > > Hence I propose a "documentation browser", similar in appearance and > > behavior to the system's other multi-paned browsers, which allows > > people to navigate and modify an independent hierarchy of "books", > > "chapters", "sections", and so forth. There would of course be > > hyperlinks, not only to points within the documentation hierarchy, but > > also to class and method comments. > > I totally agree with what you are talking about and one part of my tool > deals with it. I called it "Dynamic Document Capture" which has two > aspects: > 1. Captures information from a running window and automatically creates > a document for that window cutting and saving bitmap image of the window > itself, and each widget to an image (including whatever information that > widget contains at that moment), and creating a title for each image, so > that the writer of the documentation can come up with some meaningful > text explaining that window and/or widget. The entire information is > kept in the image with hyperlinks, and saved, filed out and in with the > source. > > 2. Allows a mechanism to capture sequences of events suh as pop-up menu > selections or modal dialogs with images and allows the user to document > these events > > Using these techniques one can evolve an on-line help system while the > program is running as well as capturing essential information that can > be a basis of "dead" documentation such as HTML or RTF > > > The documentation browser would sit on the desktop, and would probably > > be the first thing any new Squeaker sees. If books like "Squeak > > Tutorial" and "Morphic Guide" were this easily accessible, I think > > Squeak would become much more approachable. > > > > Here is a wild idea: why not make the tutorials interactive? After > > all, we have the full power of Smalltalk behind every page. > > This is another thing that can be done locally as well as with something > like a wiki-wiki server, assuming most tutorials will be available on > the web, a wiki can calculate expressions and convert results to a HTML > page even when one doesn't have a local copy of Smalltalk. However there > are security and integrity problems. Using certain templates to allow > only certain expressions can help a great deal but very inflexible. > > What about linking a local copy of Squeak to a server to make the client > run some chunks of code as if it were typed from the keyboard to run on > the client machine? That way a tutorial could discuss an example, even > execute it step by step and display intermediate results on an HTML > page, and at the click of a button this example or a variation of it > would be downloaded to a browser for the user to play with and test in > their environment. > > Tutorials on the image have the danger of being quickly outdated, and > inflating the image far beyond what it is now. Also it helps to > centralize these tutorials to a few locations in the web and hopefully > all linking them together so that the thing evolves to a huge body of > information that can be accessed from anywhere but doesn't bulk up the > image. > > > What do you people think? > > Great > > > ------------------------------------ > > Stephen Ma <stephen_ma(a)mindlink.net> > > -- > Tansel > ----------------------------------------------------------------------- > RASE Inc. 214W 29th Street Suite 901 10001 New York NY USA > Voice: (212)584 8040 mailto:tansel@rase.com > Fax: (212)584 8042 http://www.rase.com/ > -----"violence is the last refuge of the incompetent" Isaac Asimov----- (begin news server fodder) .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. (end news server fodder)

1 0

Debugger bug?
by sqrmax＠cvtci.com.ar 29 Mar '98

29 Mar '98

Hi Phil. >Syntax ERROR. (4=5) ifTrue:[5=4] is okay. >ifTrue: is implemeted in Boolean NOT Block. Yeah, ok, but the problem is in the debugger because when you debug the syntax-error version, it points to 5=4 instead of pointing to #ifTrue:. Andres.

1 0

Debugger bug?
by sqrmax＠cvtci.com.ar 29 Mar '98

29 Mar '98

Hi. [4 = 5] ifTrue: [5 = 4] <alt-d> Then, error, because #ifTrue: was sent to aBlock. Debug it and you will find that the debugger points to the next selector. Note: if you evaluate [4 = 5] ifTrue: [] <alt-d> and debug it, the debugger will point at #ifTrue:. Andres.

2 1

1.31
by sqrmax＠cvtci.com.ar 29 Mar '98

29 Mar '98

Hi. Yes! The Squeak 1.31 VM doesn't take up cpu when it's doing "nothing"! Great. Andres.

1 0

Squeak 1.31, #rename: in Class
by sqrmax＠cvtci.com.ar 28 Mar '98

28 Mar '98

Hi. I just upgraded from 1.23 to 1.31, saved all the changes and file them into 1.31. And then, error! (But hey, this is Smalltalk, so let's debug it instead of calling tech support at 2am). The #rename: method in Class answers an error if you try to rename it to its name. Should it answer an error telling you that you tried to rename a class to an existing class which in fact is the class itself, or just rename itself to itself? Like, doing something as this: newName = self name ifTrue: [^self]. This brings another question. How come the Change Sorter wrote down a rename-to-yourself? In fact, it also wrote down another rename that failed... odd. Andres.

1 0

Re: 1) CD0.2 as PDF; 2) CD0.2.2 are there
by Phil Weichert 28 Mar '98

28 Mar '98

Acorbat Version 2.1 will not read the CheeseDoc_v0_2.pdf. Have downloaded and try it twice.

1 0

Re: Documenting Squeak
by Stephen Ma 28 Mar '98

28 Mar '98

Tansel Ersavas <tansel(a)rase.com> writes: > Reinier van Loon wrote: > > > > I am more or less busy documenting Squeak using [Paradigm Plus]. > > [Found a possible inconsistency in Controller re: Sensor] > > [Volunteer to maintain a list of similar oddities] > > [Describes a nice tool for generating graphical class diagrams in HTML] > > http://www.rase.com/cybercards/db/ccm.htm > (click on the subsystem and class icons in images) > > [Above URL may disappear because it's supposed to be sort of > secret, so see it soon!] > > The disadvantage of doing all these is in Paradigm Plus is it is a > pain, especially to redo parts of it every time the system > changes. I agree. In my experience, the only way to maintain consistent documentation in a rapidly evolving system like Squeak is to attach that documentation as tightly as possible to the code. > ... [snip] ... although normally this system is for sale > for VSE (and soon VA), I'll make it freely available for Squeak > community for learning and developing Squeak (I'll still ask people > who use it for commercial purposes to buy it though). > > When it is ready to be tested, I will let everyone in this group > know so that people can download and play with it true to the > culture of Squeak. I'm looking forward to it! However, Tansel, I have a feeling that even your utility may not be enough. There's also a desperate need for overviews and tutorials; these tend not to fit well into Smalltalk's traditional hierarchy of classes, categories, and methods. Hence I propose a "documentation browser", similar in appearance and behavior to the system's other multi-paned browsers, which allows people to navigate and modify an independent hierarchy of "books", "chapters", "sections", and so forth. There would of course be hyperlinks, not only to points within the documentation hierarchy, but also to class and method comments. The documentation browser would sit on the desktop, and would probably be the first thing any new Squeaker sees. If books like "Squeak Tutorial" and "Morphic Guide" were this easily accessible, I think Squeak would become much more approachable. Here is a wild idea: why not make the tutorials interactive? After all, we have the full power of Smalltalk behind every page. What do you people think? ------------------------------------ Stephen Ma <stephen_ma(a)mindlink.net>

3 2

Documenting Squeak
by Reinier van Loon 28 Mar '98

28 Mar '98

I am more or less busy documenting Squeak using a CASE tool (Paradigm Plus). During this I found that for example Controller has an instance variable 'sensor' which is sometimes not used in subclasses. Instead these subclasses refer to Sensor (a global object) *1. I think we should try to eliminate all such references to globals. Therefore, I am volunteering to keep a list of errors, warnings (like above) and fixes. I will then compile this list into an HTML page and put it on the Web. But: I am not interested in platform specific VM related things. Just things which would make the (base) image cleaner. BTW I am thinking of putting the documentation on the Web but I need something which can make a GIF or JPG from a WMF (Windows Meta File format) file. Yeah, I know, I should code it in Squeak. Does anyone have the WMF file format available? Houdoe, Reinier. *1 For example: MouseMenuController>>controlActivity MouseMenuController>>isControlActive BitEditor>>test

2 1

Re: Question: #evaluate:in:to:notifying:ifFail:
by Tim Olson 28 Mar '98

28 Mar '98

>Although the comments in Compiler don't say anything about this, >in fact the bomb receives many other messages which it does not >understand as if it were a ParagraphEditor (even if the expression >is perfectly ok) =:^$. Any simple solution? If the requestor (the object passed in "notifying:") is not nil or is not a kind of SyntaxError, then the compiler assumes it is running interactively and the requestor to notify is a kind of ParagraphEditor, hence the extra messages. The easiest thing to do is probably to subclass SyntaxError, adding a new instance variable 'requestor' to reflect the notification to. To use it: | stream | stream _ ReadWriteStream on: string from: 1 to: string size. Compiler new evaluate: stream in: nil to: nil notifying: (SyntaxErrorCollector for: bombInTheCorner) ifFail: []. ---- 'From Squeak 1.31 of Feb 4, 1998 on 27 March 1998 at 7:03:15 pm'! SyntaxError subclass: #SyntaxErrorCollector instanceVariableNames: 'requestor ' classVariableNames: '' poolDictionaries: '' category: 'Interface-Syntax Errors'! !SyntaxErrorCollector commentStamp: 'tao 3/27/98 19:03' prior: 0! I am a kind of SyntaxError that can collect (intercept) compiler syntax errors and reflect the notification to my receiver. I exist because the compiler only understands requestors that are either: nil SyntaxError ParagraphEditor ! !SyntaxErrorCollector methodsFor: 'as yet unclassified' stamp: 'tao 3/27/98 18:59'! notify: error at: location in: source ^ requestor isNil ifTrue: [super notify: error at: location in: source] ifFalse: [requestor notify: error at: location in: source]! ! !SyntaxErrorCollector methodsFor: 'as yet unclassified' stamp: 'tao 3/27/98 18:55'! requestor ^ requestor! ! !SyntaxErrorCollector methodsFor: 'as yet unclassified' stamp: 'tao 3/27/98 18:56'! requestor: aRequestor requestor _ aRequestor! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! SyntaxErrorCollector class instanceVariableNames: ''! !SyntaxErrorCollector class methodsFor: 'as yet unclassified' stamp: 'tao 3/27/98 18:55'! for: aRequestor ^ super new requestor: aRequestor! ! -- tim

1 0