Squeak-dev May 2020

squeak-dev@lists.squeakfoundation.org

43 participants
265 discussions

Image damaged due to IO error while saving
by Thiede, Christoph 04 Sep '21

04 Sep '21

Hi all, some months ago, I corrupted my image by accidentally shutting down the host system while saving the image file (many of my images are > 500 MB, so this can take a few seconds even on an SSD). The same can happen due to various other IO/connection issues, so here's an idea: Couldn't we always use overwrite-by-rename when saving the image file? I. e., first the image into a new temporary file and, after saving has completed, replace the original file with that temp file (via mv)? This would ensure the image file's integrity. A possible disadvantage, though, would be that some filesystems, such as NTFS, associate meta-information with the file identity, which changes when using the overwrite-by-rename approach. Also, technologies such as FileSystemWatcher would be confused for the same reason. However, afaik overwrite-by-rename is a quite common approach, in primary for big and sensitive files. However, what are your opinions about this topic? :-) Best, Christoph

6 21

Announcement: Spelling services
by Tim Felgentreff 23 Aug '21

23 Aug '21

Hi Once upon a time, John M. McIntosh built a spellchecker plugin for the MacVM and there was a fileout that added a spelling service class to use it from Squeak. We have added code to provide the same API (for now) to windows and linux users that have ispell (or a compatible program, like aspell) installed on their systems using system callouts. A metacello configuration is available from the MetacelloRepository on Squeaksource, ConfigurationOfSpellingServices. The development repository is at http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/SpellingServices.html, the repo has global read+write, so if anybody finds this useful and has changes, feel free to commit to that repository. -Tim

6 8

[BUG(s)] in Context control (#jump, #runUntilErrorOrReturnFrom:)
by Thiede, Christoph 17 May '21

17 May '21

Hi all, I would like to report a bug I found related to debugging the debugger. I actually found the issue when debugging the context simulation of "Over", but let's start with a simple example. Scenario 1 Steps to reproduce: * (Save your image, if it contained any valuable information.) * Type the following into a Workspace: x := 5. thisContext insertSender: (Context contextEnsure: [x := 4]). * Debug it and step: * (into) #contextEnsure * (through) #ensure: * (into) #jump * step over the implementation, and press (into) while returning. Expected behavior: The same should happen as if you would not debug, but normally do the code: It should run without raising any error, and x should finally contain the value 4. Actual behavior: * In Trunk: * An infinite chain of debuggers appears, making it impossible to reuse the image. If you gain the chance to see any debugger, or to receive a non-empty debug log, you can see there is #errorSubscriptBounds: called from within a context. However, it is not possible to find out the complete stack of this error. (At least, I did not manage after a few attempts.) * In Squeak 5.1 (Note: You will need to replace here with MethodContext, for compatibility): * The same error is raised, but instead of endless debuggers, you get endless emergency evaluators: [cid:2c2ee09f-1f81-4969-a2af-0fac1c093119] Workaround: Modify the #contextEnsure: implementation in the following way: [cid:02411c12-9a78-40fe-a3b3-c7f8357c133d] Reason: As the comment in Context>>#jump states, the receiver context "MUST BE a top context (ie. a suspended context or a abandoned [sic] context that was jumped out of)", which, in particular, "already has its return value on its stack".1 However, in the #contextEnsure: example, ctxt is not a top context because is it still running, and on its top, it does not have a return value but the closure vector2 {ctxt. chain}. This leads to the fact that #jump pops away this closure vector so that any attempt to access this vector will result in Context>>#at: to call #errorSubscriptBounds:. I'm not sure where this attempt is made actually, but I suppose each debugger's ContextVariableInspector could do this and so raise another debugger and so forth ... Considerations: A simple solution would be the workaround presented above. However, we would not only need to patch #contextOn:do: the same way, we also wondered why the same problem does not also has had any visible impacts on the other senders of #jump in past, which are #restart and #runUntilErrorOrReturnFrom:. The first refreshes the context and then jumps into it, and from theory, I think it should be possible to call it from a foreign sender in a similar minimal example in order to invalidate the context register. However, I did not manage to construct an appropriate example yet. The same goes for #runUntilErrorOrReturnFrom:, because when "here jump" is executed, "here" again is neither a sender of the block context, nor it has is return value on stack. In a nutshell, to us, it has been keeping an open question so far whether the other senders of #jump are legitime. Should we maybe add a method like "Context >> jumpWith: aReturnValue" which would push aReturnValue on the receiver first and then perform the jump? Or could this have any negative impacts if there is indeed already a return value on stack of the receiver? Scenario 2 Steps to reproduce: The same as Scenario 1, but instead of stepping into #jump, just step over it. Expected behavior: The same expected behavior as in Scenario 1. Actual behavior: (diff to Actual behavior of Scenario 1 highlighted for ease of reading) * In Trunk: * An infinite chain of debuggers appears, making it impossible to reuse the image. If you gain the chance to see any debugger, or to receive a non-empty debug log, you can see there is #cannotReturn:to: called from within a new process. * In Squeak 5.1 (Note: You will need to replace here with MethodContext, for compatibility): * The same error is raised, but instead of endless debuggers, you get endless emergency evaluators: [cid:f7412be3-907b-441a-8a7e-889cbc88f1cd] Note: This issue continues to exist after applying the workaround patch from Scenario 1. Reason: No idea. After applying the workaround from above, I tried to debug #doStep before stepping over the #jump per button, but this lead me to some kind of infinite loop: When I debug the whole debugging logic via Process>>#completeStep: and Process>>#complete: down to Context>>#runUntilErrorOrReturnFrom: and there step *into* the "self jump" statement, the error does not occur. When I step *over* this line instead, the same error occurs. I also tried to debug that #doStep in the second debugger window again, but this bug seems to be a real Heisenbug - it only occurs when you do *not* step into the relevant #jump call. Considerations: As mentioned above, we also could not yet explain whether all calls to #jump in #runUntilErrorOrReturnFrom: are valid with regard to the "return value on stack" precondition. Maybe there is a connection? We will keep investigating the issue, but any help is appreciated, of course! 1 I'm afraid the example method "Interpreter>>primitiveSuspend" further mentioned in the comment does no longer exist. 2 Is "closure vector" an official term? If not, what would be the official term? :) Best, Christoph

3 4

The Inbox: Morphic-ct.1586.mcz
by commits＠source.squeak.org 01 May '21

01 May '21

A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1586.mcz ==================== Summary ==================== Name: Morphic-ct.1586 Author: ct Time: 10 November 2019, 4:06:17.228559 pm UUID: d752eb23-2116-0945-b043-aff08fed94fd Ancestors: Morphic-mt.1584 Proposal: Style printIt results as a pluggable link that can be clicked to inspect the result. To enable this behavior, this commit also extends #insertAndSelect:at: to allow for inserting both strings and texts. =============== Diff against Morphic-mt.1584 =============== Item was changed: ----- Method: PluggableTextMorph>>printIt (in category 'menu commands') ----- printIt | oldEditor | textMorph editor selectFrom: selectionInterval first to: selectionInterval last; model: model. "For, eg, evaluateSelection" textMorph handleEdit: [(oldEditor := textMorph editor) evaluateSelectionAndDo: [:result | selectionInterval := oldEditor selectionInterval. textMorph installEditorToReplace: oldEditor. + textMorph handleEdit: [ oldEditor afterSelectionInsertAndSelect: + (oldEditor printTextFor: result)]. - textMorph handleEdit: [oldEditor afterSelectionInsertAndSelect: result printString]. selectionInterval := oldEditor selectionInterval. textMorph editor selectFrom: selectionInterval first to: selectionInterval last. self scrollSelectionIntoView]]! Item was changed: ----- Method: TextEditor>>afterSelectionInsertAndSelect: (in category 'new selection') ----- + afterSelectionInsertAndSelect: aStringOrText - afterSelectionInsertAndSelect: aString + self insertAndSelect: aStringOrText at: self stopIndex ! - self insertAndSelect: aString at: self stopIndex ! Item was changed: ----- Method: TextEditor>>insertAndSelect:at: (in category 'new selection') ----- + insertAndSelect: aStringOrText at: anInteger - insertAndSelect: aString at: anInteger + aStringOrText isString ifTrue: [ + ^ self + insertAndSelect: (Text string: aStringOrText attributes: emphasisHere) + at: anInteger]. - self closeTypeIn. + self closeTypeIn. self selectInvisiblyFrom: anInteger to: anInteger - 1. self openTypeIn. self replace: self selectionInterval + with: (Text string: ' ' attributes: emphasisHere), aStringOrText - with: (Text string: (' ', aString) attributes: emphasisHere) and: []. - self closeTypeIn.! Item was changed: ----- Method: TextEditor>>printIt (in category 'do-its') ----- printIt self evaluateSelectionAndDo: [:result | (model respondsTo: #printIt:result:) ifTrue: [model perform: #printIt:result: with: self selection with: result] + ifFalse: [self afterSelectionInsertAndSelect: (self printTextFor: result)]]! - ifFalse: [self afterSelectionInsertAndSelect: result printString]]! Item was added: + ----- Method: TextEditor>>printTextFor: (in category 'do-its') ----- + printTextFor: anObject + + ^ Text + string: anObject printString + attributes: {PluggableTextAttribute evalBlock: [anObject inspect]}!

8 34

The Inbox: Tools-ct.959.mcz
by commits＠source.squeak.org 18 Apr '21

18 Apr '21

Christoph Thiede uploaded a new version of Tools to project The Inbox: http://source.squeak.org/inbox/Tools-ct.959.mcz ==================== Summary ==================== Name: Tools-ct.959 Author: ct Time: 16 March 2020, 9:03:12.729937 pm UUID: cae0b2d6-e131-7a40-b6a9-62a90172de94 Ancestors: Tools-mt.955 Proposal: Allow simple change sorters to become become dual sorters, and dual change sorters to be split into two separate change sorters. This commit also refactors DualChangeSorter in general. =============== Diff against Tools-mt.955 =============== Item was added: + ----- Method: ChangeSorter>>addModelItemsToWindowMenu: (in category 'as yet unclassified') ----- + addModelItemsToWindowMenu: aMenu + "Add model-related item to the window menu" + + super addModelItemsToWindowMenu: aMenu. + aMenu addLine. + aMenu add: 'Become dual sorter' translated target: self action: #becomeDualSorter.! Item was added: + ----- Method: ChangeSorter>>becomeDualSorter (in category 'as yet unclassified') ----- + becomeDualSorter + "Switch the contents of the receiver's view to represent a DualChangeSorter. Kind of mitosis: We're doing the anaphase right now." + + | dualSorter | + dualSorter := DualChangeSorter withLeft: self right: nil. + dualSorter initializeSides. + self changed: #close. + ToolBuilder open: dualSorter.! Item was added: + ----- Method: DualChangeSorter class>>new (in category 'instance creation') ----- + new + + ^ super new + initializeSides; + yourself! Item was added: + ----- Method: DualChangeSorter class>>withLeft:right: (in category 'instance creation') ----- + withLeft: leftChangeSorter right: rightChangeSorter + + ^ self basicNew + leftChangeSorter: leftChangeSorter; + rightChangeSorter: rightChangeSorter; + yourself! Item was added: + ----- Method: DualChangeSorter>>addModelItemsToWindowMenu: (in category 'user interface') ----- + addModelItemsToWindowMenu: aMenu + "Add model-related item to the window menu" + + super addModelItemsToWindowMenu: aMenu. + aMenu addLine. + aMenu add: 'Split sides' translated target: self action: #splitSides.! Item was changed: ----- Method: DualChangeSorter>>buildWith: (in category 'toolbuilder') ----- buildWith: builder - | windowSpec window | - leftCngSorter := ChangeSorter new myChangeSet: ChangeSet current. - leftCngSorter parent: self. - rightCngSorter := ChangeSorter new myChangeSet: - ChangeSet secondaryChangeSet. - rightCngSorter parent: self. + | windowSpec window | windowSpec := builder pluggableWindowSpec new. windowSpec model: self. windowSpec label: 'Change Sorter'. windowSpec children: OrderedCollection new. windowSpec label: #labelString. leftCngSorter buildWith: builder in: windowSpec rect: (0@0 extent: 0.5@1). rightCngSorter buildWith: builder in: windowSpec rect: (0.5@0 extent: 0.5@1). window := builder build: windowSpec. leftCngSorter addDependent: window. "so it will get changed: #relabel" rightCngSorter addDependent: window. "so it will get changed: #relabel" ^window! Item was added: + ----- Method: DualChangeSorter>>initializeSides (in category 'initialization') ----- + initializeSides + + leftCngSorter ifNil: [ + leftCngSorter := ChangeSorter new myChangeSet: ChangeSet current]. + leftCngSorter parent: self. + rightCngSorter ifNil: [ + rightCngSorter := ChangeSorter new myChangeSet: ChangeSet secondaryChangeSet]. + rightCngSorter parent: self.! Item was changed: + ----- Method: DualChangeSorter>>isLeftSide: (in category 'accessing') ----- - ----- Method: DualChangeSorter>>isLeftSide: (in category 'other') ----- isLeftSide: theOne "Which side am I?" ^ theOne == leftCngSorter! Item was changed: + ----- Method: DualChangeSorter>>labelString (in category 'toolbuilder') ----- - ----- Method: DualChangeSorter>>labelString (in category 'other') ----- labelString "The window label" ^'Changes go to "', ChangeSet current name, '"'.! Item was added: + ----- Method: DualChangeSorter>>leftChangeSorter: (in category 'initialization') ----- + leftChangeSorter: aChangeSorter + + leftCngSorter := aChangeSorter! Item was changed: + ----- Method: DualChangeSorter>>modelWakeUp (in category 'updating') ----- - ----- Method: DualChangeSorter>>modelWakeUp (in category 'other') ----- modelWakeUp "A window with me as model is being entered. Make sure I am up-to-date with the changeSets." "Dumb way" leftCngSorter canDiscardEdits ifTrue: [leftCngSorter update] "does both" ifFalse: [rightCngSorter update]. ! Item was changed: + ----- Method: DualChangeSorter>>okToChange (in category 'updating') ----- - ----- Method: DualChangeSorter>>okToChange (in category 'initialization') ----- okToChange ^ leftCngSorter okToChange & rightCngSorter okToChange! Item was changed: + ----- Method: DualChangeSorter>>other: (in category 'accessing') ----- - ----- Method: DualChangeSorter>>other: (in category 'other') ----- other: theOne "Return the other side's ChangeSorter" ^ theOne == leftCngSorter ifTrue: [rightCngSorter] ifFalse: [leftCngSorter]! Item was added: + ----- Method: DualChangeSorter>>rightChangeSorter: (in category 'initialization') ----- + rightChangeSorter: aChangeSorter + + rightCngSorter := aChangeSorter! Item was added: + ----- Method: DualChangeSorter>>splitSides (in category 'menu commands') ----- + splitSides + "Split the receiver into two independent views. Kind of mitosis: We're doing cytokinesis right now." + + {leftCngSorter. rightCngSorter} do: [:sorter | + ToolBuilder open: sorter]. + self changed: #close.!

8 19

The Inbox: Morphic-ct.1659.mcz
by commits＠source.squeak.org 17 Apr '21

17 Apr '21

Christoph Thiede uploaded a new version of Morphic to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1659.mcz ==================== Summary ==================== Name: Morphic-ct.1659 Author: ct Time: 16 May 2020, 8:48:50.198708 pm UUID: 49bbe6f6-5242-1b41-9823-d21b50d6b438 Ancestors: Morphic-nice.1658 Proposal: Have windows' menu box act on mouseDown rather than on mouseUp like the other boxes. This saves you another click and is more consistent to the usual menu flow in Squeak. =============== Diff against Morphic-nice.1658 =============== Item was changed: ----- Method: SystemWindow>>createMenuBox (in category 'initialization') ----- createMenuBox ^ (self createBox: self class menuBoxImage) actionSelector: #offerWindowMenu; + setBalloonText: 'window menu' translated; + actWhen: #buttonDown; + yourself! - setBalloonText: 'window menu' translated!

4 4

The Inbox: System-ct.1149.mcz
by commits＠source.squeak.org 14 Apr '21

14 Apr '21

Christoph Thiede uploaded a new version of System to project The Inbox: http://source.squeak.org/inbox/System-ct.1149.mcz ==================== Summary ==================== Name: System-ct.1149 Author: ct Time: 29 March 2020, 1:35:58.40756 pm UUID: 1bf6e87f-fc73-7747-af4d-df3e339a0627 Ancestors: System-ul.1148 Proposal: Add some convenience methods for debugging blocks. See examples in #debugFromContextThat:title:. While I know that we already talked about the sense of convenience methods that are not actually used in the base system, I think that these ones actually add value and should be used in the base system. We are experiencing an ascending number of methods that implement "debugging of a specific action", such as "debug action" and "debug get-list invocation" in Morphic, or "debug test" in SUnit (see SUnit-ct.125). As they have little duplication at the moment, it is also hard to make them more convenient: For example, if you try to debug a test case that overrides #performTest in a way that it does not actually invoke the test selector; or for another example, if you try to debug the action of a morphic button that we do not support properly at the moment (e. g. the buttons in a UserDialogBox), the current approach opens a debugger on a terminated process on #newProcess. If we follow this suggestion to refactor that behavior into one place, this will allow us to be a bit smarter and mo re convenient, as you can see in the edge case in #debugFromContextThat:title:. My follow-up proposal would thus be to call this convenience methods from all implementors of #debugAction & Co. This commit also tries to solve the issue mentioned in [1]. However, I'm not sure whether BlockClosure is the optimal place for this. I am open for your suggestions to move this somewhere else, for example into Debugger, Process or ToolSet. [1] http://forum.world.st/The-Inbox-Morphic-ct-1590-mcz-tp5106996p5107059.html =============== Diff against System-ul.1148 =============== Item was added: + ----- Method: BlockClosure>>debug (in category '*System-debugging') ----- + debug + + ^ self debugWithTitle: nil! Item was added: + ----- Method: BlockClosure>>debugFromContextThat: (in category '*System-debugging') ----- + debugFromContextThat: contextBlock + + ^ self debugFromContextThat: contextBlock title: nil! Item was added: + ----- Method: BlockClosure>>debugFromContextThat:title: (in category '*System-debugging') ----- + debugFromContextThat: contextBlock title: title + "Evaluate the receiver on a new process (synchronously). Once the contextBlock criterium is satisfied, open a debugger on that process. If the criterium is never satisfied until the process terminates, offer the user to debug the receiver again without waiting for contextBlock again. + + [self halt] debug. + [15 factorial] debugWithTitle: 'Fun with Math!!'. + [self inform: #foo] debugFromContextThat: [:ctxt | ctxt receiver isMorph] title: 'Debug dialog invocation'. + [15 factorial] debugFromContextThat: [:ctxt | ctxt selector = #+]." + + | process | + process := self newProcess. + process runUntil: contextBlock. + process isTerminated ifTrue: [ + ^ (self confirm: 'Did not reach the desired piece of code.\Would you like to debug the whole process again?' withCRs translated) + ifTrue: [self debugWithTitle: title] + ifFalse: [self]]. + ^ process debugWithTitle: title! Item was added: + ----- Method: BlockClosure>>debugWithTitle: (in category '*System-debugging') ----- + debugWithTitle: title + + ^ self + debugFromContextThat: [:ctx | ctx closure == self] + title: title!

2 1

Problems with #caseError
by Thiede, Christoph 28 Mar '21

28 Mar '21

Hi all, there are two problems with #caseError. First one: Given the following example, you will receive a confusing error message: #foo caseOf: {[#bar] -> [2]. [#baz] -> [3]} "--> Error: Case not found (nil), and no otherwise clause" Either #caseError should be called on #foo, then this would be compiler bug. Otherwise, I don't see any reason to print out the receiver. We could also name it #caseError: anObject and print out this object, but the current message is not helpful IMO ... Second one: I'm not sure whether it is expected behavior how #allLiterals works on the following example: method := Compiler new compiledMethodFor: '#bar caseOf: {[#bar] -> [2]}' in: nil to: nil notifying: nil ifFail: nil. method allLiterals. "--> #(#caseError #bar #caseOf:)"

4 9

Proposal: Geometry Classes
by patrick.rein＠hpi.uni-potsdam.de 11 Mar '21

11 Mar '21

Hi everyone, during some recent clean-up an issue with geometry objects came up. As a result the following idea came up which I thereby would like to put out for an initial discussion. In case we find that this might be useful, I would continue by implementing a first prototype of the package as a foundation of a more in-depth discussion later on. Bests Patrick # Squeak Change Proposal - Geometry Package ## Why? Squeak implements basic geometry logic in too many different places. For example intersection of different kinds of geometric objects is implemented all over Morphic, ST80, Balloon, Graphics, and Etoys. Such extensive scattering across packages and classes impedes modularity, that is, readability and extensibility. An example for this recently came up when we discovered an issue with testing for graphical intersections between PolygonMorph and RectangleMorph. It was not possible to compute that overlapping area because the class Rectangle omits to provide an important method. A quick fix would entail unnecessary dependencies (here: Morphic -> Balloon) or duplicated code (see also http://bugs.squeak.org/view.php?id=7872). Consequently, we might want to modularize the geometry objects and operations. As a side effect, dependent packages such as Morphic can be simplified a little bit (more). ## Scope The proposed package should cover basic 2D geometric objects and their operations represented by the following classes: - Point - Line - LineSegment - Polygon - Rectangle (as an optimization as it could be represented as a special Polygon already) Most classes could simply be moved from their previous packages. Afterwards the interfaces would need to be made consistent with each other to allow interoperability of all geometry classes within the new package. ### Affected classes: - All classes in ST80-Paths - LineSegement, Bezier2Segment, Bezier3Segment (Balloon-Geometry) - Rectangle, Quadrangle, Point (Graphics-Primitives) - LineIntersections, LineIntersectionSegment, LineIntersectionEvent (Etoys-Squeakland-Graphics-Tools-Intersection) ## Open questions - Should this become a single new package or a subcategory in the Graphics package? - Should the package contain an Ellipses class? - Should we model curved line segments as BezierLineSegments, CurvedLineSegment, or Arc? ## Risks - This would potentially deprecate the existing ST80 geometry classes (ST80-Paths) - Some of the new classes will cause name clashes with existing classes. For example Line is currently in ST-80 and represents a line segment, and the class LineSegment is a line segment but not in the geometric sense as it also incorporates arcs. Both names might then be used by new classes with different meanings. This might be mitigated by introducing a pre-/postfix for the names of the new classes.

6 16

find original change set
by Javier Orsaria 09 Mar '21

09 Mar '21

Hi, I was trying to use, in VersionsBrowser, the feature "find original change set" for a method. In old versions (3.8 and earlier) this work fine. But in 3.10 and 3.9 don´t. I followed the sequence and detect the problem at MethodChangeRecord-noteNewMethod: noteNewMethod: newMethod "NEVER do this. It is evil." currentMethod _ nil. should be: noteNewMethod: newMethod "NEVER do this. It is evil." currentMethod _ newMethod. This way work as I expect. But with that comment I understand was intentioned. What is the problem with this? I can´t see it... I'm the devil? Thanks, Javier

3 2

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

Jump to page: