June 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Morphic or forking bug?

by Sven Van Caekenberghe

Hi Horrido, It is very hard to follow what you are exactly doing or trying to do. Here is the simplest example I can think of that updates something in Morphic on a regular basis. StringMorph subclass: #MyClock instanceVariableNames: '' classVariableNames: '' package: '_UnpackagedPackage' MyClock>>#initialize super initialize. self updateClock MyClock>>#step self updateClock MyClock>>#updateClock self contents: Time now printString MyClock class>>#open "self open" ^ self new openInWindow This inherits #stepTime as 1 second. If I open such a window and save my image, it is still there when the image is restarted, with the clock still working. Updating (data structures in) the main UI process from another process is dangerous. Saving such constructs is even more dangerous. HTH, Sven > On 2 Jun 2017, at 15:54, horrido <horrido.hobbies(a)gmail.com> wrote: > > Sorry, I could be mistaken. I just checked my notes. The *0 asString* test > failed once, but I've not been able to replicate it. I might've been working > with an unclean image. > > So perhaps it is related to Morphic, after all. > > > horrido wrote >> Yup, they all fail. Interesting that > * >> 0 asString > * >> fails. This means it has NOTHING to do with Morphic (or Morphic being >> thread-unsafe). >> >> Ben Coman wrote >>> On Wed, May 31, 2017 at 10:23 PM, horrido < > >>> horrido.hobbies@ > >>> > wrote: >>> >>> Can you try a few other variations... >>> [ [ true ] whileTrue: [ 0 asString. delay wait ] fork. >>> [ [ true ] whileTrue: [ a contents: '0'. delay wait ] fork. >>> [ [ true ] whileTrue: [ a contents: '0'. ] forkAt: 20. >>> >>> cheers -ben > > > > > > -- > View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948984.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 2, 2017

Re: [Pharo-users] Morphic or forking bug?

by horrido

Sorry, I could be mistaken. I just checked my notes. The *0 asString* test failed once, but I've not been able to replicate it. I might've been working with an unclean image. So perhaps it is related to Morphic, after all. horrido wrote > Yup, they all fail. Interesting that * > 0 asString * > fails. This means it has NOTHING to do with Morphic (or Morphic being > thread-unsafe). > > Ben Coman wrote >> On Wed, May 31, 2017 at 10:23 PM, horrido < >> horrido.hobbies@ >> > wrote: >> >> Can you try a few other variations... >> [ [ true ] whileTrue: [ 0 asString. delay wait ] fork. >> [ [ true ] whileTrue: [ a contents: '0'. delay wait ] fork. >> [ [ true ] whileTrue: [ a contents: '0'. ] forkAt: 20. >> >> cheers -ben -- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948984.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 2, 2017

Re: [Pharo-users] Morphic or forking bug?

by horrido

Yup, they all fail. Interesting that *0 asString* fails. This means it has NOTHING to do with Morphic (or Morphic being thread-unsafe). Ben Coman wrote > On Wed, May 31, 2017 at 10:23 PM, horrido < > horrido.hobbies@ > > wrote: > > Can you try a few other variations... > [ [ true ] whileTrue: [ 0 asString. delay wait ] fork. > [ [ true ] whileTrue: [ a contents: '0'. delay wait ] fork. > [ [ true ] whileTrue: [ a contents: '0'. ] forkAt: 20. > > cheers -ben -- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948983.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 2, 2017

Other halt messages

by Stephane Ducasse

Hi I would love to have

June 2, 2017

Re: [Pharo-users] Porting Transducers to Pharo

by Stephane Ducasse

There is a package for that NGFileOuter or something like that on cincom store. We used it for mobydic code. On Wed, May 31, 2017 at 6:35 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > If I remember correctly, there is a parcel in VisualWorks to export a file > out (Squeak format). > > @Milton, can you give a hand to Steffen? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On May 31, 2017, at 10:32 AM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > > Thanks for the encouraging response! First question: Which is the > recommended (friction free) way to exchange code between VW and Pharo? > > Cheers! > Steffen > > Am .05.2017, 16:22 Uhr, schrieb Alexandre Bergel <alexandre.bergel(a)me.com > >: > > I second Sven. This is very exciting! > > Let us know when you have something ready to be tested. > > Alexandre > > > > > >

June 2, 2017

Re: [Pharo-users] Morphic or forking bug?

by horrido

Here is something I found by accident... If I run my app, then close it, then save/exit the image, then open the image again, edit my application class to add a new instance variable, then save the change â Pow! â I get about a dozen debugger pop-ups saying "#wait was sent to nil". What this tells me (and you may correct me if I'm wrong), the VM still has a thread running that is sending #wait messages to my application *which has already shutdown*. This can't be good, but whether this is related to the segmentation fault is anybody's guess at this point. Stephane Ducasse-3 wrote > Thanks for reporting. > I hope that in Pharo 70 we will get rid of the FreeType pluging. > > Stef > > On Thu, Jun 1, 2017 at 3:30 PM, horrido < > horrido.hobbies@ > > wrote: > >> I downloaded Pharo 6.0 but used the same Spur VM (which I presume is >> still >> the latest for Raspberry Pi): >> http://files.pharo.org/vm/pharo-spur32/linux/armv6/pharo-linux-ARMv6- >> 201705051953-b8db6de.zip >> >> It crashed, too. >> >> >> Denis Kudriashov wrote >> > 2017-05-31 17:57 GMT+02:00 horrido < >> >> > horrido.hobbies@ >> >> > >: >> > >> >> I'm using Pharo 5.0 >> > >> > >> > I test it with Pharo 6 (latest image and VM) and have no problem. Could >> > you >> > check it too? >> >> >> >> >> >> -- >> View this message in context: http://forum.world.st/Morphic- >> or-forking-bug-tp4948727p4948818.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> -- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948911.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 2, 2017

Re: [Pharo-users] Pharo and QT

by Stephane Ducasse

Hi dimitris We would love to have that. We could have a Spec binding and build automatically applications in QT for people willing. Esteban always wanted to have a Cocoa binding used the same way. But this is large task Stef On Thu, Jun 1, 2017 at 2:44 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > A must for any serious dekstop application with Pharo, but it is a hudge > task > > > Le 29/05/2017 Ã 14:35, Dimitris Chloupis a Ã©crit : > > Is there an interest for working with QT from Pharo ? I make no > > promises just something I was interested in trying. > > -- > Dr. Geo > http://drgeo.eu > > > >

June 1, 2017

Re: [Pharo-users] Morphic or forking bug?

by Stephane Ducasse

Thanks for reporting. I hope that in Pharo 70 we will get rid of the FreeType pluging. Stef On Thu, Jun 1, 2017 at 3:30 PM, horrido <horrido.hobbies(a)gmail.com> wrote: > I downloaded Pharo 6.0 but used the same Spur VM (which I presume is still > the latest for Raspberry Pi): > http://files.pharo.org/vm/pharo-spur32/linux/armv6/pharo-linux-ARMv6- > 201705051953-b8db6de.zip > > It crashed, too. > > > Denis Kudriashov wrote > > 2017-05-31 17:57 GMT+02:00 horrido < > > > horrido.hobbies@ > > > >: > > > >> I'm using Pharo 5.0 > > > > > > I test it with Pharo 6 (latest image and VM) and have no problem. Could > > you > > check it too? > > > > > > -- > View this message in context: http://forum.world.st/Morphic- > or-forking-bug-tp4948727p4948818.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 1, 2017

[ANN] Pharo Sprint App minor release for the Pharo Sprint June 2

by Juraj Kubelka

Hi, we have just released new minor version of the Pharo Sprint App. There are some minor bug fixes included and users asked me to be able to remove cases from the proposed list. See you around tomorrow during the sprint and if you have issues to work on, propose them using the app :-) Juraj Download link: https://github.com/JurajKubelka/PharoSprint <https://github.com/JurajKubelka/PharoSprint>

June 1, 2017

Re: [Pharo-users] Morphic or forking bug?

by horrido

I downloaded Pharo 6.0 but used the same Spur VM (which I presume is still the latest for Raspberry Pi): http://files.pharo.org/vm/pharo-spur32/linux/armv6/pharo-linux-ARMv6-201705… It crashed, too. Denis Kudriashov wrote > 2017-05-31 17:57 GMT+02:00 horrido < > horrido.hobbies@ > >: > >> I'm using Pharo 5.0 > > > I test it with Pharo 6 (latest image and VM) and have no problem. Could > you > check it too? -- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948818.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 1, 2017

Re: [Pharo-users] Morphic or forking bug?

by horrido

See below for the crash dump. Guillermo Polito wrote > Horrido, > > Can you also provide the stack associated with the segmentation fault? > Usually the VM captures the signal and dumps the current stack at the > moment of the crash in stdout. You'll find the same stack in the file > crash.dmp. > > On Thu, Jun 1, 2017 at 6:51 AM, Ben Coman < > btc@ > > wrote: > >> >> >> On Wed, May 31, 2017 at 10:23 PM, horrido < > horrido.hobbies@ > > >> wrote: >> >>> I have a puzzling bug. I've narrowed the scenario down to this code: >>> >>> CrankyÂ»initA >>> a := ((StringMorph contents: '####') color: Color white) position: >>> (0@0 >>> ). >>> m addMorph: a >>> >>> CrankyÂ»initialize >>> f := Form fromFileNamed: 'hot_air_balloon_mysticmorning.jpg'. >>> m := ImageMorph new. >>> m form: f. >>> self initA. >>> m openInWindowLabeled: 'Cranky'. >>> delay := (Delay forSeconds: 5). >>> [ [ true ] whileTrue: [ a contents: 0 asString. delay wait ] fork >>> >>> I can run this application for hours and hours with no problem. However, >>> if >>> I run it for a while and then close the application and then save/exit >>> the >>> image, the next time I start the image, there is some likelihood it will >>> crash dump. The probability is something like 5-10%. >>> >>> Interestingly, if I remove the statement... >>> >>> a contents: 0 asString. >>> >>> from the infinite loop, I've not been able to replicate the crash. Is >>> there >>> something wrong with the way I'm updating the contents of the >>> StringMorph? >>> Segmentation fault Thu Jun 1 09:04:56 2017 /home/pi/pharo50-dev/lib/pharo/5.0-201705051953/pharo Pharo VM version: 5.0-201705051953 Fri May 5 21:02:28 UTC 2017 gcc 4.9.2 [Production Spur VM] Built from: CoInterpreter VMMaker.oscog-eem.2207 uuid: 8da5de9b-33d7-478b-9081-58591f7da69a May 5 2017 With: StackToRegisterMappingCogit VMMaker.oscog-eem.2208 uuid: 4877be7d-941d-4e15-b6df-4f1b8c7072a8 May 5 2017 Revision: VM: 201705051953 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Fri May 5 12:53:38 2017 -0700 $ Plugins: 201705051953 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Build host: Linux testing-gce-4db3c1dc-5576-4a70-9128-5f5e3d62217a 4.4.0-62-generic #83~14.04.1-Ubuntu SMP Wed Jan 18 18:10:30 UTC 2017 armv7l GNU/Linux plugin path: ./lib/pharo/5.0-201705051953 [default: /home/pi/pharo50-dev/lib/pharo/5.0-201705051953/] C stack backtrace & registers: r0 0x75d94008 r1 0x74d7ca00 r2 0x00000000 r3 0x75f45000 r4 0x004089d8 r5 0x76fe6f10 r6 0x7e8586ec r7 0x00000003 r8 0x00000000 r9 0x75f44298 r10 0x7e8586ec fp 0x74746366 ip 0x00000000 sp 0x7e858678 lr 0x00047c44 pc 0x75ebe478 *[0x0] [0x7e8572a0] Smalltalk stack dump: 0x7e85c864 I FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: 0x3457050: a(n) FreeTypeFace 0x7e85c88c I FreeTypeFace>create 0x3457050: a(n) FreeTypeFace 0x7e85c8ac I FreeTypeFace>validate 0x3457050: a(n) FreeTypeFace 0x7e85c8cc I FreeTypeFont>face 0x765b18: a(n) FreeTypeFont 0x7e85c908 I FreeTypeFontProvider>fontFor:familyName: 0x11d4450: a(n) FreeTypeFontProvider 0x7e85c934 M [] in LogicalFontManager>bestFontFor:whenFindingAlternativeIgnoreAll: 0x12db5b0: a(n) LogicalFontManager 0x7e85c958 M OrderedCollection>do: 0x12db5c0: a(n) OrderedCollection 0x7e85c97c M [] in LogicalFontManager>bestFontFor:whenFindingAlternativeIgnoreAll: 0x12db5b0: a(n) LogicalFontManager 0x7e85c9a0 M Array(SequenceableCollection)>do: 0x7649d8: a(n) Array 0x7e85c9c8 I LogicalFontManager>bestFontFor:whenFindingAlternativeIgnoreAll: 0x12db5b0: a(n) LogicalFontManager 0x7e85c9f0 I LogicalFontManager>bestFontFor: 0x12db5b0: a(n) LogicalFontManager 0x7e85ca14 I LogicalFont>findRealFont 0x12db578: a(n) LogicalFont 0x7e85ca34 I LogicalFont>realFont 0x12db578: a(n) LogicalFont 0x7e85ca54 I LogicalFont>widthOfString: 0x12db578: a(n) LogicalFont 0x7e85ca7c I StringMorph>measureContents 0x325a480: a(n) StringMorph 0x7e85caa4 I StringMorph>fitContents 0x325a480: a(n) StringMorph 0x7e85cac4 I StringMorph>contents: 0x325a480: a(n) StringMorph 0x7e85cae8 I [] in Cranky>initialize 0x325a390: a(n) Cranky 0x325a408 s [] in BlockClosure>newProcess Most recent primitives class class class class + **PrimitiveFailure** digitAdd: normalize class primUTCMicrosecondsClock at: + at: at: at: + signal primSignalAtBytesLeft: suspend class scanFor: scanFor: scanFor: basicAt: isNil isNil findNextUnwindContextUpTo: findContextSuchThat: valueNoContextSwitch valueNoContextSwitch **StackOverflow** at: objectAt: class header basicNew: stackp: at: at:put: valueNoContextSwitch value stackp: at:put: at: stackp: valueNoContextSwitch ensure: ensure: ensure: ensure: stackp: at:put: at: stackp: findNextUnwindContextUpTo: terminateTo: value stackp: at:put: at: stackp: at: value at: stackp: findNextUnwindContextUpTo: at:put: at:put: stackp: at:put: stepToCallee stepToCallee stepToCallee stepToCallee at: stackp: at: stackp: at:put: at: stackp: return:from: return:from: at:put: at:put: stackp: at:put: at: class bitAnd: bitAnd: bitAnd: numCopiedValues stackp: numCopiedValues priority: primitiveResume garbageCollectMost **IncrementalGC** at:put: basicNew primLowSpaceSemaphore: primSignalAtBytesLeft: wait compare:with:collated: class stringHash:initialHash: at: basicNew new: value: value basicNew value primCurrentLibrary hash compare:with:collated: value: at: at: value:value: **StackOverflow** **StackOverflow** closenessVectorForStretch:slant:weight: * * * * * **StackOverflow** class second **StackOverflow** raisedTo: raisedTo: raisedTo: raisedTo: raisedTo: raisedTo: at: third asFloat sqrt truncated sqrt sqrt = = = = = bitShift: **PrimitiveFailure** bitShiftMagnitude: timesTwoPower: >= at: value:value: value:value: **StackOverflow** truncated truncated value:value: **StackOverflow** truncated truncated **PrimitiveFailure** bitShiftMagnitude: timesTwoPower: **PrimitiveFailure** basicAt: basicAt: bitShift: **PrimitiveFailure** bitShiftMagnitude: basicAt: + bitOr: digitCompare: digitAt: digitAt: at: bitShiftMagnitude: bitShift: **PrimitiveFailure** bitShiftMagnitude: basicNew = = < perform:with: < **PrimitiveFailure** perform:with: denominator **PrimitiveFailure** digitMultiply:neg: numerator numerator at: value:value: **StackOverflow** truncated truncated at: value:value: truncated truncated value:value: value:value: value:value: value:value: value:value: value:value: value:value: value:value: value:value: value:value: at: at: at:put: at:put: at: value:value: truncated truncated sort:to: sort:to: sort:to: sort:to: truncated truncated truncated truncated bitShiftMagnitude: timesTwoPower: basicNew allInstancesOrNil value: index value: size primNewFaceFromExternalMemory:size:index: stack page bytes 4096 available headroom 2788 minimum unused headroom 3036 (Segmentation fault) -- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948806.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 1, 2017

Re: [Pharo-users] Pharo and QT

by Hilaire

A must for any serious dekstop application with Pharo, but it is a hudge task Le 29/05/2017 Ã 14:35, Dimitris Chloupis a Ã©crit : > Is there an interest for working with QT from Pharo ? I make no > promises just something I was interested in trying. -- Dr. Geo http://drgeo.eu

June 1, 2017

Re: [Pharo-users] Morphic or forking bug?

by Hilaire

In that case the problem is really somewhere else. I use step since years in DrGeo to get selected geometric shapes to blink. May be your problem is related to the use of processes. Hilaire Le 01/06/2017 Ã 00:27, horrido a Ã©crit : > Thanks, Hilaire. I had high hopes for your suggestion. > > But after testing a few times, Pharo crashed again. > > So the step protocol doesn't solve the problem, either. > -- Dr. Geo http://drgeo.eu

June 1, 2017

Re: [Pharo-users] anotations like <todo> etc.

by Tudor Girba

This would be really great. Doru > On Jun 1, 2017, at 11:38 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 1 Jun 2017, at 10:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> >> 2017-05-31 19:48 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> the pragma is less intromission with code, but it has to be put in a specific place. >> >> I think Marcus with Ronie extended pragmas to bind them to AST-nodes. It was needed for lowcode if I remember correctly. Maybe we can add it in Pharo 7? > > It would be nice to revisit this directionâ¦ we had a number of designs (the one Ronie did was the third oneâ¦ for 3 different projectsâ¦) > > In addition, we should explore pragmas for variable definitions on the class level. > > I will add this to my list of things to explore for pharo 7. > > Marcus -- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them."

June 1, 2017

Re: [Pharo-users] anotations like <todo> etc.

by Marcus Denker

> On 1 Jun 2017, at 10:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-05-31 19:48 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > the pragma is less intromission with code, but it has to be put in a specific place. > > I think Marcus with Ronie extended pragmas to bind them to AST-nodes. It was needed for lowcode if I remember correctly. Maybe we can add it in Pharo 7? It would be nice to revisit this directionâ¦ we had a number of designs (the one Ronie did was the third oneâ¦ for 3 different projectsâ¦) In addition, we should explore pragmas for variable definitions on the class level. I will add this to my list of things to explore for pharo 7. Marcus

June 1, 2017

Re: [Pharo-users] anotations like <todo> etc.

by Denis Kudriashov

2017-06-01 10:36 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > In fact it is not something new. You always able put any flag as pragma or > message in your methods to easily find them later. For example you can put > <issue: 'this method is not working when arg = 5'>. Then you can find it in > spotter by tapping "issue:". > With Calypso we can implement special method group "todo" and also class > group to show classes which methods has this flag > I add issue for this Implement method and class groups for #todo <https://github.com/dionisiydk/Calypso/issues/56>

June 1, 2017

Re: [Pharo-users] anotations like <todo> etc.

by Denis Kudriashov

2017-05-31 19:48 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > the pragma is less intromission with code, but it has to be put in a > specific place. I think Marcus with Ronie extended pragmas to bind them to AST-nodes. It was needed for lowcode if I remember correctly. Maybe we can add it in Pharo 7?

June 1, 2017

Re: [Pharo-users] anotations like <todo> etc.

by Denis Kudriashov

2017-05-31 19:19 GMT+02:00 Petr Fischer <petr.fischer(a)me.com>: > Hello, in Pharo 6.0, there is new annotations/pragmas like "<todo>". > > Is there any doc about this? How can I browse all "todos", how can I > browse all possible annotations etc.? > In fact it is not something new. You always able put any flag as pragma or message in your methods to easily find them later. For example you can put <issue: 'this method is not working when arg = 5'>. Then you can find it in spotter by tapping "issue:". With Calypso we can implement special method group "todo" and also class group to show classes which methods has this flag

June 1, 2017

Re: [Pharo-users] Morphic or forking bug?

by Denis Kudriashov

2017-06-01 10:20 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 2017-05-31 17:57 GMT+02:00 horrido <horrido.hobbies(a)gmail.com>: > >> I'm using Pharo 5.0 > > > I test it with Pharo 6 (latest image and VM) and have no problem. Could > you check it too? (I tested it on MAC)

June 1, 2017

Re: [Pharo-users] Morphic or forking bug?

by Denis Kudriashov

2017-05-31 17:57 GMT+02:00 horrido <horrido.hobbies(a)gmail.com>: > I'm using Pharo 5.0 I test it with Pharo 6 (latest image and VM) and have no problem. Could you check it too?

June 1, 2017

Re: [Pharo-users] Morphic or forking bug?

by Guillermo Polito

Horrido, Can you also provide the stack associated with the segmentation fault? Usually the VM captures the signal and dumps the current stack at the moment of the crash in stdout. You'll find the same stack in the file crash.dmp. On Thu, Jun 1, 2017 at 6:51 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Wed, May 31, 2017 at 10:23 PM, horrido <horrido.hobbies(a)gmail.com> > wrote: > >> I have a puzzling bug. I've narrowed the scenario down to this code: >> >> CrankyÂ»initA >> a := ((StringMorph contents: '####') color: Color white) position: (0@0 >> ). >> m addMorph: a >> >> CrankyÂ»initialize >> f := Form fromFileNamed: 'hot_air_balloon_mysticmorning.jpg'. >> m := ImageMorph new. >> m form: f. >> self initA. >> m openInWindowLabeled: 'Cranky'. >> delay := (Delay forSeconds: 5). >> [ [ true ] whileTrue: [ a contents: 0 asString. delay wait ] fork >> >> I can run this application for hours and hours with no problem. However, >> if >> I run it for a while and then close the application and then save/exit the >> image, the next time I start the image, there is some likelihood it will >> crash dump. The probability is something like 5-10%. >> >> Interestingly, if I remove the statement... >> >> a contents: 0 asString. >> >> from the infinite loop, I've not been able to replicate the crash. Is >> there >> something wrong with the way I'm updating the contents of the StringMorph? >> > > Can you try a few other variations... > [ [ true ] whileTrue: [ 0 asString. delay wait ] fork. > [ [ true ] whileTrue: [ a contents: '0'. delay wait ] fork. > [ [ true ] whileTrue: [ a contents: '0'. ] forkAt: 20. > > cheers -ben > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

June 1, 2017

Re: [Pharo-users] Morphic or forking bug?

by Ben Coman

On Wed, May 31, 2017 at 10:23 PM, horrido <horrido.hobbies(a)gmail.com> wrote: > I have a puzzling bug. I've narrowed the scenario down to this code: > > CrankyÂ»initA > a := ((StringMorph contents: '####') color: Color white) position: (0@0 > ). > m addMorph: a > > CrankyÂ»initialize > f := Form fromFileNamed: 'hot_air_balloon_mysticmorning.jpg'. > m := ImageMorph new. > m form: f. > self initA. > m openInWindowLabeled: 'Cranky'. > delay := (Delay forSeconds: 5). > [ [ true ] whileTrue: [ a contents: 0 asString. delay wait ] fork > > I can run this application for hours and hours with no problem. However, if > I run it for a while and then close the application and then save/exit the > image, the next time I start the image, there is some likelihood it will > crash dump. The probability is something like 5-10%. > > Interestingly, if I remove the statement... > > a contents: 0 asString. > > from the infinite loop, I've not been able to replicate the crash. Is there > something wrong with the way I'm updating the contents of the StringMorph? > Can you try a few other variations... [ [ true ] whileTrue: [ 0 asString. delay wait ] fork. [ [ true ] whileTrue: [ a contents: '0'. delay wait ] fork. [ [ true ] whileTrue: [ a contents: '0'. ] forkAt: 20. cheers -ben

June 1, 2017