Squeak-dev August 2017

squeak-dev@lists.squeakfoundation.org

42 participants
86 discussions

The Trunk: MorphicExtras-tpr.209.mcz
by commits＠source.squeak.org 03 Aug '17

03 Aug '17

tim Rowledge uploaded a new version of MorphicExtras to project The Trunk: http://source.squeak.org/trunk/MorphicExtras-tpr.209.mcz ==================== Summary ==================== Name: MorphicExtras-tpr.209 Author: tpr Time: 2 August 2017, 5:53:29.922577 pm UUID: 7ad502c6-49bf-4866-886b-e9e5369b003b Ancestors: MorphicExtras-tpr.208 tiny changes to the init of Hygrometer and Thermomemter dials =============== Diff against MorphicExtras-tpr.208 =============== Item was changed: ----- Method: HygrometerDialMorph>>initialize (in category 'initialize-release') ----- initialize "Build a hygrometer. The background is an ImageMorph showing a dial derived from the same general principles as the BarometerMorph. " | pointerMorph | super initialize. self startAngle: -140 stopAngle: 140; + startValue: 0 stopValue: 100. - startValue: 25 stopValue: 100. self extent: 200@200; color: Color transparent; borderWidth: 0. dialCenter := self center. self buildDial. "build our fancy needle as an ImageMorph, set the position to horizontal centre and about 2/3 down so that it rotates about that point when inside the TransformationMorph" pointerMorph := self fancyNeedleOfLength: (self height * 0.65) rounded. pointerMorph position: pointerMorph extent * ( -0.5@ -0.65). "we keep track of the TransformationMorph since that is what we have to rotate as the incoming pressure values change" needleMorph := TransformationMorph new position: dialCenter; addMorph: pointerMorph. self addMorph: needleMorph. "add a central colored dot. Because we just do." self addMorph: (CircleMorph new extent: 20@20; color: Color black; center: dialCenter) ! Item was changed: ----- Method: ThermometerDialMorph>>buildDial (in category 'dial drawing') ----- buildDial "start by making a damn big Form, twice the size we want to end up with" |outerRadius destForm canvas tickLabel tickLength beginAngle endAngle tickAngle tickLabelSize maxTicks | outerRadius := self height - 1. destForm := Form extent: self extent * 2 depth: 32. (canvas := destForm getCanvas) fillOval: (0@0 extent: self extent * 2) color: Color white. "outer ring" self drawArcAt: destForm center radius: outerRadius thickness: 1 color: Color black beginAngle: 0 endAngle: 360 onForm: destForm. "inner ring" self drawArcAt: destForm center radius: outerRadius * 0.97 thickness: 1 color: Color black beginAngle: 0 endAngle: 360 onForm: destForm. "outer scale for Fahrenheit" beginAngle := startAngle -360. "needs cleaning up about this" endAngle := stopAngle. self drawArcAt: destForm center radius: outerRadius * 0.8 thickness: 1 color: Color black beginAngle:beginAngle endAngle: stopAngle onForm: destForm. self drawArcAt: destForm center radius: outerRadius * 0.73 thickness: 1 color: Color black beginAngle:beginAngle endAngle: stopAngle onForm: destForm. + - "The Fahrenheit values of our range are - startValue -5/ 5 * 9 + 32 ->23 - stopValue 30 / 5 * 9 + 32 -> 86 - which is very conveniently integral but sadly it corresponds to 4.44444 deg per ... degree." maxTicks := stopValue - startValue / 5 * 9 . tickAngle := endAngle - beginAngle / maxTicks. (startValue / 5 * 9 +32) to: (stopValue / 5 * 9 +32) do: [:tick| tickLength := outerRadius * 0.07. tickLabel := nil. tick \\ 10 = 0 ifTrue: [ tickLabel := tick asString. tickLabelSize := 24 ] ifFalse: [ tick \\ 2 = 0 ifTrue:[ tickLabel := (tick \\ 10) asString. tickLabelSize := 18 ] ifFalse: [ tickLength := tickLength * 2 ] ]. self drawTickRadius: outerRadius * 0.73 length: tickLength thickness: 2 color: Color black angle: beginAngle + (tick - (startValue / 5 * 9 +32) * tickAngle) onCanvas: canvas. self tickLabel: tickLabel fontSize: tickLabelSize color: Color black centeredAt: dialCenter radius: (outerRadius * 0.73) + tickLength angle: beginAngle + (tick - (startValue / 5 * 9 +32) * tickAngle) onCanvas: canvas. ]. self tickInnerLabel: (String with: (Unicode value: 16rB0) with: $C) fontSize: 36 color: Color black centeredAt: dialCenter radius: (outerRadius * 0.73) angle: 180 onCanvas: canvas. "inner scale for Celsius" beginAngle := startAngle -360. "needs cleaning up about this" endAngle := stopAngle. self drawArcAt: destForm center radius: outerRadius * 0.71 thickness: 1 color: Color black beginAngle:beginAngle endAngle: stopAngle onForm: destForm. self drawArcAt: destForm center radius: outerRadius * 0.63 thickness: 1 color: Color black beginAngle:beginAngle endAngle: stopAngle onForm: destForm. maxTicks := stopValue - startValue. tickAngle := endAngle - beginAngle / maxTicks. tickLength := outerRadius * 0.07. startValue to: stopValue do: [ :tick ||tickThickness| tickLabel := nil. tick \\ 5 = 0 ifTrue: [ tickLabelSize := 20. tickThickness := 3. tickLabel := tick asString. ] ifFalse: [ tickThickness := 2. ]. self drawTickRadius: outerRadius * 0.63 length: tickLength thickness: tickThickness color: Color black angle: beginAngle + (tick - startValue * tickAngle) onCanvas: canvas. self tickInnerLabel: tickLabel fontSize: tickLabelSize color: Color black centeredAt: dialCenter radius: (outerRadius * 0.63) angle: beginAngle + (tick - startValue * tickAngle) onCanvas: canvas. ]. self tickLabel: (String with: (Unicode value: 16rB0) with: $F) fontSize: 36 color: Color black centeredAt: dialCenter radius: (outerRadius * 0.73) angle: 180 onCanvas: canvas. self addMorph: (destForm magnify: destForm boundingBox by: 0.5 smoothing: 2) asMorph! Item was changed: ----- Method: ThermometerDialMorph>>initialize (in category 'initialize-release') ----- initialize "Build a thermometer. The background is an ImageMorph showing a dial derived from the same general principles as the BarometerMorph. The temperature scale is fixed for now at -5C to 30C but ought to be parameterised someday. We'll have the Celcius scale as the inner and a conversion to Fahrenheit as the outer" | pointerMorph | super initialize. self startAngle: -140 stopAngle: 140; + startValue: -10 stopValue: 35. - startValue: -5 stopValue: 30. self extent: 200@200; color: Color transparent; borderWidth: 0. dialCenter := self center. self buildDial. "build our fancy needle as an ImageMorph, set the position to horizontal centre and about 2/3 down so that it rotates about that point when inside the TransformationMorph" pointerMorph := self fancyNeedleOfLength: (self height * 0.65) rounded. pointerMorph position: pointerMorph extent * ( -0.5@ -0.65). "we keep track of the TransformationMorph since that is what we have to rotate as the incoming pressure values change" needleMorph := TransformationMorph new position: dialCenter; addMorph: pointerMorph. self addMorph: needleMorph. "add a central colored dot. Because we just do." self addMorph: (CircleMorph new extent: 20@20; color: Color black; center: dialCenter) !

1 0

The Trunk: System-dtl.961.mcz
by commits＠source.squeak.org 02 Aug '17

02 Aug '17

David T. Lewis uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-dtl.961.mcz ==================== Summary ==================== Name: System-dtl.961 Author: dtl Time: 2 August 2017, 9:22:02.611529 am UUID: 4485dae2-bb1b-48ca-bdc1-5f1f4dd89eb0 Ancestors: System-eem.960 When Project class>>tryOtherProjectForRecovery is searching for a safe project to use for emergency recovery, test for projects of a type that the current project inherits from, but do not require that they be of the same class. This handles the case of errors in a FooMorphicProject that inherits from MorphicProject, for which another Morphic project is not likely to be suitable for handling a fatal error raised in the FooMorphicProject. Expected behavior when evaluating "Project handlePrimitiveError: 'Foobar' " In an MVC project that is a chlid of a Morphic project, enter the Mophic project and open a debugger on the process that failed in MVC. In a Mophic project that is a chlid of an MVC project, enter the MVC project and open a debugger on the process that failed in Morphic. For the common case of a parent project of the same type as the project from which the error is raised, do not attempt to enter another project, and open an emergency evaluator instead. =============== Diff against System-eem.960 =============== Item was changed: ----- Method: Project class>>tryOtherProjectForRecovery: (in category 'error recovery') ----- tryOtherProjectForRecovery: errorMessage "Try entering the parent project if it uses a different user interface. We determine this by comparing the project's class." | safeProject nextProject | nextProject := Project current. safeProject := nil. [safeProject notNil or: [nextProject isTopProject]] whileFalse: [ nextProject := nextProject parent. + (Project current isKindOf: nextProject class) - nextProject class == Project current class ifFalse: [safeProject := nextProject]]. safeProject ifNotNil: [:p | p enterForEmergencyRecovery. "Active process will usually suspend after this."].!

3 3

Re: [squeak-dev] The Trunk: System-dtl.961.mcz
by Jakob Reschke 02 Aug '17

02 Aug '17

Hi Chris, enterForEmergencyRecovery is sent to the safeProject at the end of the method. HTH, Jakob 2017-08-02 16:15 GMT+02:00 Chris Cunningham <cunningham.cb(a)gmail.com>: > Hi. > > This message really confuses me (as does the previous version). It checks > for a safe project - I get that. > But then, after if finds the safe project, it stores it in a temporary > variable and does nothing else with it? > What magic actually causes Squeak to USE that safe project? I can't find it > in this method, nor in the caller of this method (#handlePrimitiveError:). > > Very confused, > cbc > > On Wed, Aug 2, 2017 at 6:22 AM, <commits(a)source.squeak.org> wrote: >> >> David T. Lewis uploaded a new version of System to project The Trunk: >> http://source.squeak.org/trunk/System-dtl.961.mcz >> >> ==================== Summary ==================== >> >> Name: System-dtl.961 >> Author: dtl >> Time: 2 August 2017, 9:22:02.611529 am >> UUID: 4485dae2-bb1b-48ca-bdc1-5f1f4dd89eb0 >> Ancestors: System-eem.960 >> >> When Project class>>tryOtherProjectForRecovery is searching for a safe >> project to use for emergency recovery, test for projects of a type that the >> current project inherits from, but do not require that they be of the same >> class. This handles the case of errors in a FooMorphicProject that inherits >> from MorphicProject, for which another Morphic project is not likely to be >> suitable for handling a fatal error raised in the FooMorphicProject. >> >> Expected behavior when evaluating "Project handlePrimitiveError: 'Foobar' >> " >> >> In an MVC project that is a chlid of a Morphic project, enter the Mophic >> project and open a debugger on the process that failed in MVC. >> >> In a Mophic project that is a chlid of an MVC project, enter the MVC >> project and open a debugger on the process that failed in Morphic. >> >> For the common case of a parent project of the same type as the project >> from which the error is raised, do not attempt to enter another project, and >> open an emergency evaluator instead. >> >> =============== Diff against System-eem.960 =============== >> >> Item was changed: >> ----- Method: Project class>>tryOtherProjectForRecovery: (in category >> 'error recovery') ----- >> tryOtherProjectForRecovery: errorMessage >> "Try entering the parent project if it uses a different user >> interface. We determine this by comparing the project's class." >> >> | safeProject nextProject | >> nextProject := Project current. >> safeProject := nil. >> [safeProject notNil or: [nextProject isTopProject]] whileFalse: [ >> nextProject := nextProject parent. >> + (Project current isKindOf: nextProject class) >> - nextProject class == Project current class >> ifFalse: [safeProject := nextProject]]. >> safeProject ifNotNil: [:p | >> p enterForEmergencyRecovery. >> "Active process will usually suspend after this."].! >> >> >

2 1

Re: [squeak-dev] Recovery project hanging after recursive error in debugger
by Jakob Reschke 02 Aug '17

02 Aug '17

Thank you, Dave. Now I will have to wait until "it" happens again and see whether things have gotten better or worse in the situation. ;-) If the symptom is gone now, I still have that bogus "fatal" error lurking around. Which is usually not so fatal after all because I can simply reenter the project. But that is another story for another day. For those of you who like guessing games or may actually find it plausible: the situation that raises the "fatal" error is usually when something goes wonky while debugging test cases. Sometimes when pressing one of the stepping buttons a second debugger with only a single context on the stack appears and it tells me that the context is gone or not in the sender chain or something in that direction, I don't remember the exact message right now. Pressing the wrong buttons in the wrong debugger (which are "wrong" and which are harmless I could not exactly sort out yet either) can then trigger the "fatal" error. Another situation is when I build something with the ToolBuilder, but have not implemented all the methods (e. g., fetching tree node children or item labels) in advance. I find it convenient to just open the tool and then use the "Create" button in the debugger to start implementing it, but this approach got me drawing errors in the tool and also several times a "fatal" error after (!) eventually adding a particular method, so I have stopped doing that... 2017-08-02 15:38 GMT+02:00 David T. Lewis <lewis(a)mail.msen.com>: > Jakob, > > I just committed a small update in System-dtl.961 that I think will address > the issue you are seeing. The assumption is that a fatal error in an AniMorphic > project is likely to be fatal also in a Morphic project, and therefore the > error handling logic should treat them similarly, hence an #isKindOf: test > rather than a test for equal classes. > > Subclasses of MorphicProject will hopefully be a common case some day, and > we can easily imagine having things like ScratchProject and EtoysProject in > addition to AniMorphicProject. So it is important for the error recovery to > work in those cases. > > Dave > > > On Tue, Aug 01, 2017 at 08:59:14PM +0200, Jakob Reschke wrote: >> My image is as updated as can be, but Eliot's fix does not help for >> the "fatal drawing error" case because that still suspends from inside >> the critical block, as my "stack trace" shows. >> >> I noticed that the recovery project detection queries the class of the >> project. I run an AnimMorphicProject (from the Animations [1] package, >> inherits from MorphicProject) that is a child of a MorphicProject, so >> the classes are different, otherwise the outer project would not be >> tried. That might explain why nobody of you runs into the issue -- >> that is, in addition to not producing "fatal" errors all the time, >> unlike me ;-) >> >> [1] https://github.com/hpi-swa/Animations >> >> >> 2017-08-01 20:47 GMT+02:00 David T. Lewis <lewis(a)mail.msen.com>: >> > Cool, thanks Chris. >> > >> > Jakob, I'm assuming you are working with a trunk image. Can you confirm if >> > the issue is resolved after updating your image to the latest? >> > >> > Dave >> > >> >> ErrorRecursionGuard is a _patch_ to a relatively new addition, the >> >> introduction of Debugger>>'ErrorRecursion' which resulted in the >> >> Emergency Evaluator being opened too eagerly (and unable to be >> >> closed!) -- even when there was no recursion. >> >> >> >> Eliot fixed the symptom described by Jakob with Morphic-eem.1334. >> >> >> >> On Tue, Aug 1, 2017 at 7:18 AM, David T. Lewis <lewis(a)mail.msen.com> >> >> wrote: >> >>> Is anyone else experiencing this problem? I have not seen it, but I have >> >>> not recently been doing things that could lead to an emergency >> >>> evaluator, >> >>> so it is not surprising that I would not have seen it. Anyone else? >> >>> >> >>> The ErrorRecursionGuard mutex is a relatively new addition >> >>> (Tools-cmm.755 >> >>> added in April), so it certainly seems possible the we may have a >> >>> problem >> >>> related to the mutex. >> >>> >> >>> Dave >> >>> >> >>> On Sun, Jul 30, 2017 at 08:42:43PM +0200, Jakob Reschke wrote: >> >>>> Hi, >> >>>> >> >>>> Recently, it occurs quite frequently in my image that something goes >> >>>> so wrong that the Debugger fails to open and I am bumped out to the >> >>>> parent Project. However, the debugger for the crippled Process does >> >>>> not open there either, because the ErrorRecursionGuard Mutex is still >> >>>> held by the suspended Process that wants to be debugged. >> >>>> >> >>>> Interrupting with Cmd+. and terminating the suspended process usually >> >>>> works to get going again, but this seems not like something I should >> >>>> have to do manually. Is something broken with the recovery mechanism? >> >>>> >> >>>> More details from the stack (extracted with the Process Browser): >> >>>> - some UnhandledError is raised >> >>>> - ToolSet class>>debugError: is called >> >>>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is >> >>>> reached, the ErrorRecursionGuard Mutex is acquired >> >>>> - ErrorRecursion is true there for some reason unknown to me, no >> >>>> further debuggers are on that particular stack >> >>>> - Project current handleFatalDrawingError: >> >>>> - Project class>>tryOtherProjectForRecovery: >> >>>> - SomeProjectType(Project)>>enterForEmergencyRecovery >> >>>> - MorphicProject>>suspendProcessForDebug >> >>>> >> >>>> Now it is waiting to be picked up by the 'FATAL PROJECT ERROR!' >> >>>> debugger, but it cannot because that Mutex is still held, so the >> >>>> debugger waits for the suspended process that it should debug. >> >>>> >> >>>> - reproduce the hanging by ProcessBrowser>>debugProcess on the >> >>>> suspended Process >> >>>> - Process>>debugWithTitle: ... >> >>>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is >> >>>> reached, wants to enter the critical section with ErrorRecursionGuard, >> >>>> but has to wait ... >> >>>> >> >>>> Kind regards, >> >>>> Jakob >> >>>> >> >>> >> >> >> >> >> > >> > >> > >> >

1 0

Re: [squeak-dev] Recovery project hanging after recursive error in debugger
by Jakob Reschke 02 Aug '17

02 Aug '17

My image is as updated as can be, but Eliot's fix does not help for the "fatal drawing error" case because that still suspends from inside the critical block, as my "stack trace" shows. I noticed that the recovery project detection queries the class of the project. I run an AnimMorphicProject (from the Animations [1] package, inherits from MorphicProject) that is a child of a MorphicProject, so the classes are different, otherwise the outer project would not be tried. That might explain why nobody of you runs into the issue -- that is, in addition to not producing "fatal" errors all the time, unlike me ;-) [1] https://github.com/hpi-swa/Animations 2017-08-01 20:47 GMT+02:00 David T. Lewis <lewis(a)mail.msen.com>: > Cool, thanks Chris. > > Jakob, I'm assuming you are working with a trunk image. Can you confirm if > the issue is resolved after updating your image to the latest? > > Dave > >> ErrorRecursionGuard is a _patch_ to a relatively new addition, the >> introduction of Debugger>>'ErrorRecursion' which resulted in the >> Emergency Evaluator being opened too eagerly (and unable to be >> closed!) -- even when there was no recursion. >> >> Eliot fixed the symptom described by Jakob with Morphic-eem.1334. >> >> On Tue, Aug 1, 2017 at 7:18 AM, David T. Lewis <lewis(a)mail.msen.com> >> wrote: >>> Is anyone else experiencing this problem? I have not seen it, but I have >>> not recently been doing things that could lead to an emergency >>> evaluator, >>> so it is not surprising that I would not have seen it. Anyone else? >>> >>> The ErrorRecursionGuard mutex is a relatively new addition >>> (Tools-cmm.755 >>> added in April), so it certainly seems possible the we may have a >>> problem >>> related to the mutex. >>> >>> Dave >>> >>> On Sun, Jul 30, 2017 at 08:42:43PM +0200, Jakob Reschke wrote: >>>> Hi, >>>> >>>> Recently, it occurs quite frequently in my image that something goes >>>> so wrong that the Debugger fails to open and I am bumped out to the >>>> parent Project. However, the debugger for the crippled Process does >>>> not open there either, because the ErrorRecursionGuard Mutex is still >>>> held by the suspended Process that wants to be debugged. >>>> >>>> Interrupting with Cmd+. and terminating the suspended process usually >>>> works to get going again, but this seems not like something I should >>>> have to do manually. Is something broken with the recovery mechanism? >>>> >>>> More details from the stack (extracted with the Process Browser): >>>> - some UnhandledError is raised >>>> - ToolSet class>>debugError: is called >>>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is >>>> reached, the ErrorRecursionGuard Mutex is acquired >>>> - ErrorRecursion is true there for some reason unknown to me, no >>>> further debuggers are on that particular stack >>>> - Project current handleFatalDrawingError: >>>> - Project class>>tryOtherProjectForRecovery: >>>> - SomeProjectType(Project)>>enterForEmergencyRecovery >>>> - MorphicProject>>suspendProcessForDebug >>>> >>>> Now it is waiting to be picked up by the 'FATAL PROJECT ERROR!' >>>> debugger, but it cannot because that Mutex is still held, so the >>>> debugger waits for the suspended process that it should debug. >>>> >>>> - reproduce the hanging by ProcessBrowser>>debugProcess on the >>>> suspended Process >>>> - Process>>debugWithTitle: ... >>>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is >>>> reached, wants to enter the critical section with ErrorRecursionGuard, >>>> but has to wait ... >>>> >>>> Kind regards, >>>> Jakob >>>> >>> >> >> > > >

2 1

Recovery project hanging after recursive error in debugger
by Jakob Reschke 01 Aug '17

01 Aug '17

Hi, Recently, it occurs quite frequently in my image that something goes so wrong that the Debugger fails to open and I am bumped out to the parent Project. However, the debugger for the crippled Process does not open there either, because the ErrorRecursionGuard Mutex is still held by the suspended Process that wants to be debugged. Interrupting with Cmd+. and terminating the suspended process usually works to get going again, but this seems not like something I should have to do manually. Is something broken with the recovery mechanism? More details from the stack (extracted with the Process Browser): - some UnhandledError is raised - ToolSet class>>debugError: is called - Debugger class>>morphicOpenOn:context:label:contents:fullView: is reached, the ErrorRecursionGuard Mutex is acquired - ErrorRecursion is true there for some reason unknown to me, no further debuggers are on that particular stack - Project current handleFatalDrawingError: - Project class>>tryOtherProjectForRecovery: - SomeProjectType(Project)>>enterForEmergencyRecovery - MorphicProject>>suspendProcessForDebug Now it is waiting to be picked up by the 'FATAL PROJECT ERROR!' debugger, but it cannot because that Mutex is still held, so the debugger waits for the suspended process that it should debug. - reproduce the hanging by ProcessBrowser>>debugProcess on the suspended Process - Process>>debugWithTitle: ... - Debugger class>>morphicOpenOn:context:label:contents:fullView: is reached, wants to enter the critical section with ErrorRecursionGuard, but has to wait ... Kind regards, Jakob

3 3