Squeak-dev May 2003

squeak-dev@lists.squeakfoundation.org

204 participants
710 discussions

[BUG] infinite recursion on PluggableTextMorph>>extent:
by ned＠bike-nomad.com 14 Aug '03

14 Aug '03

I've noticed this recursion a few times. I chose a method in a RB and asked the RB to "rename method", and got this. I have the RB and Skins packages loaded. 20 May 2003 12:16:08 pm VM: Win32 - Squeak3.4 of 1 March 2003 [latest update: #5170] Image: Squeak3.6alpha [latest update: #5184] PluggableTextMorph>>extent: Receiver: a PluggableTextMorph(2667) Arguments and temporary variables: newExtent: 296@18 Receiver's instance variables: bounds: 2@20 corner: 298@38 owner: a SystemWindow(2881) submorphs: #(a TransformMorph(1395)) fullBounds: nil color: Color transparent extension: a MorphExtension (1334) [other: (layoutFrame -> a LayoutFrame) (lay...etc... borderWidth: 2 borderColor: #inset model: a MethodNameEditor slotName: nil open: false pinSpecs: nil scrollBar: a ScrollBar(2786) scroller: a TransformMorph(1395) retractableScrollBar: false scrollBarOnLeft: false getMenuSelector: nil getMenuTitleSelector: nil scrollBarHidden: nil hasFocus: false textMorph: a TextMorphForEditView(1183) getTextSelector: #selector setTextSelector: #selector: getSelectionSelector: nil hasUnacceptedEdits: false askBeforeDiscardingEdits: true selectionInterval: (1 to: 0) hasEditingConflicts: false PluggableTextMorph>>resetExtent Receiver: a PluggableTextMorph(2667) Arguments and temporary variables: tempSelection: (1 to: 0) Receiver's instance variables: bounds: 2@20 corner: 298@38 owner: a SystemWindow(2881) submorphs: #(a TransformMorph(1395)) fullBounds: nil color: Color transparent extension: a MorphExtension (1334) [other: (layoutFrame -> a LayoutFrame) (lay...etc... borderWidth: 2 borderColor: #inset model: a MethodNameEditor slotName: nil open: false pinSpecs: nil scrollBar: a ScrollBar(2786) scroller: a TransformMorph(1395) retractableScrollBar: false scrollBarOnLeft: false getMenuSelector: nil getMenuTitleSelector: nil scrollBarHidden: nil hasFocus: false textMorph: a TextMorphForEditView(1183) getTextSelector: #selector setTextSelector: #selector: getSelectionSelector: nil hasUnacceptedEdits: false askBeforeDiscardingEdits: true selectionInterval: (1 to: 0) hasEditingConflicts: false PluggableTextMorph(ScrollPane)>>showScrollBar Receiver: a PluggableTextMorph(2667) Arguments and temporary variables: Receiver's instance variables: bounds: 2@20 corner: 298@38 owner: a SystemWindow(2881) submorphs: #(a TransformMorph(1395)) fullBounds: nil color: Color transparent extension: a MorphExtension (1334) [other: (layoutFrame -> a LayoutFrame) (lay...etc... borderWidth: 2 borderColor: #inset model: a MethodNameEditor slotName: nil open: false pinSpecs: nil scrollBar: a ScrollBar(2786) scroller: a TransformMorph(1395) retractableScrollBar: false scrollBarOnLeft: false getMenuSelector: nil getMenuTitleSelector: nil scrollBarHidden: nil hasFocus: false textMorph: a TextMorphForEditView(1183) getTextSelector: #selector setTextSelector: #selector: getSelectionSelector: nil hasUnacceptedEdits: false askBeforeDiscardingEdits: true selectionInterval: (1 to: 0) hasEditingConflicts: false PluggableTextMorph(ScrollPane)>>hideOrShowScrollBar Receiver: a PluggableTextMorph(2667) Arguments and temporary variables: Receiver's instance variables: bounds: 2@20 corner: 298@38 owner: a SystemWindow(2881) submorphs: #(a TransformMorph(1395)) fullBounds: nil color: Color transparent extension: a MorphExtension (1334) [other: (layoutFrame -> a LayoutFrame) (lay...etc... borderWidth: 2 borderColor: #inset model: a MethodNameEditor slotName: nil open: false pinSpecs: nil scrollBar: a ScrollBar(2786) scroller: a TransformMorph(1395) retractableScrollBar: false scrollBarOnLeft: false getMenuSelector: nil getMenuTitleSelector: nil scrollBarHidden: nil hasFocus: false textMorph: a TextMorphForEditView(1183) getTextSelector: #selector setTextSelector: #selector: getSelectionSelector: nil hasUnacceptedEdits: false askBeforeDiscardingEdits: true selectionInterval: (1 to: 0) hasEditingConflicts: false --- The full stack --- PluggableTextMorph>>extent: ...etc...

1 1

[FIX] ProjectSubclassesOK-nk
by Ned Konz 12 Aug '03

12 Aug '03

from preamble: "Change Set: ProjectSubclassesOK-nk Date: 13 March 2003 Author: Ned Konz An explicit test for class == Project was preventing subclasses of Project (like NCDrawingProject) from being loadable. This CS fixes that problem. "!

5 4

[ENH] RunToSelection-nk
by ned＠bike-nomad.com 08 Aug '03

08 Aug '03

from preamble: "Change Set: RunToSelection-nk Date: 31 May 2003 Author: Ned Konz This adds a 'run to here' item to the Debugger code pane context menu. This lets you select some code and step until the context changes or until the PC reaches the range you've selected. "!

3 3

RE: [BUG][FIX]Browser explain of pooldicts fails
by Magistrello Alejandro (SFA) 04 Aug '03

04 Aug '03

Tim, can you check http://swiki.gsug.org:8080/sqfixes/3263.html ? regards, Alejandro > -----Mensaje original----- > De: Tim Rowledge [SMTP:tim@sumeru.stanford.edu] > Enviado el: jueves 29 de mayo de 2003 18:46 > Para: squeak-dev(a)lists.squeakfoundation.org > Asunto: Re: [BUG][FIX]Browser explain of pooldicts fails > > A seemingly related problem has just caught me. > > Using a FileContentsBrowser I had 'remove existing' to compare a .st > file with the contents of my image. Sometime in the process of browsing > the remaining list of changes I got a walkback as in the attached > debug.log; note that the problem is that nobody understands #Definition > again. > > If you look in CodeHolder>didCodeChangeElsewhere you'll see that the > same #selectedMessageName is the likely culprit. > > Who actually knows what is the intended behaviour here? > > tim > -- > Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim > Useful random insult:- Immune from any serious head injury. <<Archivo: > SqueakDebug.log>> <<Archivo: ATT615707.txt>>

3 3

VI4 (was: RE: [ANN]Draft rough plan for 3.6!)
by Anthony Hannan 03 Aug '03

03 Aug '03

I ran macrobenchmarks (after fixing it up, see my fixes posted). The results are: 3.4 image with closure compiler loaded and active but no methods recompiled: #(67308 246197 116342 31254 0 16290 14740) 3.4 image with closure compiler active and all method recompiled under closure compiler: #(85788 348667 124072 46906 0 18674 23292) Since marcroBenchmarks mostly tests the compiler/decompiler and messageTally (hence contexts), most of these test are not executing exactly the same code from the first image to the second. The only test that doesn't change is number 6, the one that opens and closes 10 browsers. Number 6 results are 18674 vs. 16290, a 15% slow down. Let me clarify why I think we should wait for a Jitter before changing the image format. Because the Jitter itself will likely required a image format change and we don't want two format changes in a row, especially when the second will superscede the first. Only the compiled method format change would remain from the first change, which could wait for the second because it is only an aesthetic change. It adds no new functionality. I know past Jitters did not require a format change. But since Ian is on Eliot's Bytecode-to-Bytecode Adaptive Optimization for Smalltalk project (along with myself, Dan, Marcus, and John Sarkela) I suspect the next Jitter will be a Smalltalk Jitter producing optimized bytecodes. Some of these bytecodes will be new special low-level bytecodes, which will require a new image format. Even if Ian produces a C Jitter before that with no format change, it will speed things up enough to not need VI4. Only the compiled method format change will be missing, which again is not important. So I believe we can live with the 15% slow down for a year or so. If not we can try to speed up the interpreter a little by just including stack enhancements but not bytecodes enhancements so we don't change the image format. I think any bytecode changes should be in conjunction with Eliot's project or some Jitter project. And to reiterate, I think the compiled method format change should only be include on the back of some other more significant image format change like bytecodes. Cheers, Anthony

6 7

[FIX] EventRecorderPosFix-nk
by ned＠bike-nomad.com 20 Jul '03

20 Jul '03

from preamble: "Change Set: EventRecorderPosFix-nk Date: 3 March 2003 Author: Ned Konz This CS ensures that keyboard events are given positions when replayed from the Event Recorder"!

3 3

[BUG][FIX][TEST] ClassBuilder does not move iVars correctly
by Andreas Raab 19 Jul '03

19 Jul '03

Hi, Just noticed that moving iVars between classes is broken in ClassBuilder. Attached is a fix and a test illustrating the problem. Note: The test has been written against the base image tests @ SM. Don't try to file it in unless you have those loaded. Cheers, - Andreas

3 2

[MCP][ENH] self deprecate for crufty methods
by David T. Lewis 19 Jul '03

19 Jul '03

As part of MCP, there has been some discussion about cleaning out unnecessary methods in Morphic. Here is a way to mark methods for future removal. I'm sure this is not a new idea, but maybe it will help with the housekeeping. This change set adds Object>>deprecatedOn:by: to declare a method obsolete and provide a warning to any sender of the message to discourage use of the deprecated method. Send "self deprecatedOn: aDateString by: yourNameOrInitials" in the method being marked for future removal. Dave

3 2

RE: destructors, how?
by Peter Crowther 18 Jul '03

18 Jul '03

> From: Ragnar Hojland Espinosa [mailto:ragnar@linalco.com] > I want to automatically call self terminate on an object on > destruction (or when it goes out of scope..) Smalltalk objects are not 'destroyed'. They are garbage-collected at some time after no other object references them. The 'some time after' could be microseconds or days. > I can't find out how to write a destructor > or something functionally equivalent. Check out implementors of 'finalize' (IIRC). In essence, you hold onto the object using a weak array; are notified when it is garbage-collected; and clear appropriate fields based on copies of the data in the object. - Peter

17 22

[Fun][Weird][VM] Objects as compiled methods
by Andreas Raab 12 Jul '03

12 Jul '03

Hi Guys, For some experimentation I wanted to have the ability to have *any* object act as a compiled method, so that it can be 'invoked' as if it were a function. I've just published a package for this at SqueakMap. http://map2.squeakfoundation.org/sm/package/b6a0d3eb-1241-4e3c-b790-e1995b59 9784 >From the description: Nothing for the faint-hearted. This package is a VM modification which allows arbitrary objects to 'act' like CompiledMethods. In other words, if you want to have some object to act like a method you merely add it to the appropriate method dictionary, like in: Object addSelector: #foo:bar: withMethod: FooBarAlgorithm. When you now say something like: someObject foo: 42 bar: 'mumble'. the special message #run:with:in: will be sent to FooBarAlgorithm so you could handle it like this: FooBarAlgorithm class>>run: originalSelector with: argsArray in: aReceiver "Run the FooBarAlgorithm when invoked via originalSelector from aReceiver. argsArray contains the arguments passed along with the original invokation." Pretty cool, eh? Needless to say, the package requires a new VM. Without it, the supplied tests will horribly crash your system. Cheers, - Andreas

12 38

← Newer
1
2
3
4
5
6
7
...
71
Older →

Jump to page: