- Pharo-dev - lists.pharo.org

Re: [Pharo-project] RGMethodDefininition

by StÃ©phane Ducasse

origin is the place (trait) where the method is originally defined. so this is important. On Aug 25, 2012, at 11:52 AM, Veronica Isabel Uquillas Gomez wrote: > origin is not the same as package > in CompiledMethod origin refers to the class or trait that actually defines the method > > we do not have that in Ring. I will add that behavior but not with that name.. It does not say anything to me > > > On 24 Aug 2012, at 17:58, Camillo Bruni wrote: > >> I think instead of having a 'package' instVar we should have something >> like 'origin'. I remember adding #origin to CompiledMethod simplifying quite >> a bit. >> >> >> On 2012-08-24, at 17:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> Good point >>> I'm not sure that we handled that. >>> >>> On Aug 24, 2012, at 4:56 PM, Camillo Bruni wrote: >>> >>>> How can I figure out whether an RGMethodDefininition is coming from a Trait? >>>> >>>> method := (DatePrintFormatTester >> #shouldFix:). >>>> method origin isTrait "returns true". >>>> >>>> how can I do the same with Ring? >> > >

Aug. 25, 2012

[Pharo-project] HorribleBrokeEverythingNotWorkingBug

by Camillo Bruni

Maybe I overreacted a bit, but I put two new bugs on this status... - Metacello doesn't load properly (thus breaking all builds loading stuff from Configs) - Changes in Instance Variables don't trigger proper recompilation I think we should address these two issues urgently :) - the symptoms of the first bug can be cured by loading Metacello by default in 2.0 - the second one is harder and requires a specialist! good wekeend

Aug. 25, 2012

Re: [Pharo-project] serializing DynamicVariables (Zinc so far)

by Frank Shearar

On 25 August 2012 14:30, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sat, 25 Aug 2012, Sven Van Caekenberghe wrote: > >> The nil default is used as a 'not set' third value. >> >> ZnSignalProgress class>>#enabled >> "Answer if HTTPProgress should be signalled. >> The default is false." >> >> ^ self value >> ifNil: [ false ] >> ifNotNil: [ :value | value ] >> >> ZnClient>>#withProgressDo: block >> ^ ZnSignalProgress value >> ifNil: [ >> ZnSignalProgress >> value: self signalProgress >> during: [ ^ block value ] ] >> ifNotNil: [ >> block value ] > > > DynamicVariables are stored in the env variable of Process, the stack > doesn't store this information, so if you're about to serialize a state of a > Process, then you have to serialize the env variable too, otherwise you'll > lose information. I'm sure that's what I said in my initial response to Mariano's question :) Yes, indeed, that is precisely the problem with DynamicVariable. (Scala's and Clojure's dynamic variables suffer the same problem.) That's why these guys don't play well with stack slicing & dicing (http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-expres…) Handily, http://ss3.gemstone.com/ss/Control _does_ do this - keep the information on the stack, that is. Look at the DelimitedDynamicVariable tests in that package. frank > Levente > > >> >> ZnClient>>#signalProgress >> "Return true if I signal HTTPProgress notifications during >> execution." >> >> ^ self optionAt: #signalProgress ifAbsent: [ false ] >> >> Sven >> >> On 25 Aug 2012, at 12:50, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >>> On 25 August 2012 09:31, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>>> >>>> Hi Sean. I am still seing the problem :( >>>> It is difficult to make it YOU to reproduce it, but it is easy that >>>> tomorrow >>>> I show it to you :) >>>> Basically, what is happening is that >>>> >>>> ZnClient >> executeRequestResponse >>>> self logRequest. >>>> ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Writing >>>> request' ]. >>>> request writeOn: connection. >>>> connection flush. >>>> ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Reading >>>> response' >>>> ]. >>>> response := request method = #HEAD >>>> ifTrue: [ ZnResponse readHeaderFrom: connection ] >>>> ifFalse: [ >>>> self streaming >>>> ifTrue: [ ZnResponse readStreamingFrom: connection ] >>>> ifFalse: [ ZnResponse readFrom: connection ] ]. >>>> self logResponse >>>> >>>> throws a mustBeBoolean in the first line "ZnSignalProgress enabled ". It >>>> seems that such expression answered the SmallINteger 30 the first time. >>>> If I take the debugger and I evaluate ZnSignalProgress enabled again, >>>> it >>>> answers me false, which is the correct value. >>>> Ahh yes, this in latest 2.0. >>> >>> >>> I would have expected a ZnSignalProgress class >> default saying "^ >>> true" (or something else of a Boolean nature). DynamicVariables have a >>> default value of nil unless otherwise set. Or, since you're getting a >>> value of 30, something somewhere is saying ZnSignalProgress value: 30 >>> during: ["something"]... which would be very weird. >>> >>> frank >>> >>>> Thanks! >>>> >>>> >>>> On Fri, Aug 17, 2012 at 10:32 PM, Mariano Martinez Peck >>>> <marianopeck(a)gmail.com> wrote: >>>>> >>>>> >>>>> Hi Frank and Sean. The problem was quite hard to reproduce. You need to >>>>> rebuild a Pharo image from a kernel using Tanker ;) >>>>> Anyway, since we are changing completely Tanker now it may have been >>>>> solved. I did a quick test (of a similar case) and it works. So once I >>>>> have >>>>> the example of the kernel again I will trying again. >>>>> Thanks for offering the help! >>>>> >>>>> >>>>> On Fri, Aug 17, 2012 at 2:33 PM, Sean P. DeNigris >>>>> <sean(a)clipperadams.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Mariano Martinez Peck wrote >>>>>>> >>>>>>> >>>>>>> The first time, #enable answers something wrong. The second time it >>>>>>> is >>>>>>> called, it seems to answer the correct value. >>>>>> >>>>>> >>>>>> Mariano, would you give some more details about the wrong value, the >>>>>> expected value, and the steps to reproduce? I took a look but I'm not >>>>>> seeing >>>>>> what the problem is... b.t.w. is this a 1.4 or 2.0 image? >>>>>> >>>>>> Sean >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> >>>>>> http://forum.world.st/serializing-DynamicVariables-Zinc-so-far-tp4643514p46… >>>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >> >> >> >

Aug. 25, 2012

Re: [Pharo-project] serializing DynamicVariables (Zinc so far)

by Levente Uzonyi

On Sat, 25 Aug 2012, Sven Van Caekenberghe wrote: > The nil default is used as a 'not set' third value. > > ZnSignalProgress class>>#enabled > "Answer if HTTPProgress should be signalled. > The default is false." > > ^ self value > ifNil: [ false ] > ifNotNil: [ :value | value ] > > ZnClient>>#withProgressDo: block > ^ ZnSignalProgress value > ifNil: [ > ZnSignalProgress > value: self signalProgress > during: [ ^ block value ] ] > ifNotNil: [ > block value ] DynamicVariables are stored in the env variable of Process, the stack doesn't store this information, so if you're about to serialize a state of a Process, then you have to serialize the env variable too, otherwise you'll lose information. Levente > > ZnClient>>#signalProgress > "Return true if I signal HTTPProgress notifications during execution." > > ^ self optionAt: #signalProgress ifAbsent: [ false ] > > Sven > > On 25 Aug 2012, at 12:50, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 25 August 2012 09:31, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> Hi Sean. I am still seing the problem :( >>> It is difficult to make it YOU to reproduce it, but it is easy that tomorrow >>> I show it to you :) >>> Basically, what is happening is that >>> >>> ZnClient >> executeRequestResponse >>> self logRequest. >>> ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Writing request' ]. >>> request writeOn: connection. >>> connection flush. >>> ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Reading response' >>> ]. >>> response := request method = #HEAD >>> ifTrue: [ ZnResponse readHeaderFrom: connection ] >>> ifFalse: [ >>> self streaming >>> ifTrue: [ ZnResponse readStreamingFrom: connection ] >>> ifFalse: [ ZnResponse readFrom: connection ] ]. >>> self logResponse >>> >>> throws a mustBeBoolean in the first line "ZnSignalProgress enabled ". It >>> seems that such expression answered the SmallINteger 30 the first time. >>> If I take the debugger and I evaluate ZnSignalProgress enabled again, it >>> answers me false, which is the correct value. >>> Ahh yes, this in latest 2.0. >> >> I would have expected a ZnSignalProgress class >> default saying "^ >> true" (or something else of a Boolean nature). DynamicVariables have a >> default value of nil unless otherwise set. Or, since you're getting a >> value of 30, something somewhere is saying ZnSignalProgress value: 30 >> during: ["something"]... which would be very weird. >> >> frank >> >>> Thanks! >>> >>> >>> On Fri, Aug 17, 2012 at 10:32 PM, Mariano Martinez Peck >>> <marianopeck(a)gmail.com> wrote: >>>> >>>> Hi Frank and Sean. The problem was quite hard to reproduce. You need to >>>> rebuild a Pharo image from a kernel using Tanker ;) >>>> Anyway, since we are changing completely Tanker now it may have been >>>> solved. I did a quick test (of a similar case) and it works. So once I have >>>> the example of the kernel again I will trying again. >>>> Thanks for offering the help! >>>> >>>> >>>> On Fri, Aug 17, 2012 at 2:33 PM, Sean P. DeNigris <sean(a)clipperadams.com> >>>> wrote: >>>>> >>>>> >>>>> Mariano Martinez Peck wrote >>>>>> >>>>>> The first time, #enable answers something wrong. The second time it is >>>>>> called, it seems to answer the correct value. >>>>> >>>>> Mariano, would you give some more details about the wrong value, the >>>>> expected value, and the steps to reproduce? I took a look but I'm not >>>>> seeing >>>>> what the problem is... b.t.w. is this a 1.4 or 2.0 image? >>>>> >>>>> Sean >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://forum.world.st/serializing-DynamicVariables-Zinc-so-far-tp4643514p46… >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> > > >

Aug. 25, 2012

Re: [Pharo-project] RGMethodDefininition

by Camillo Bruni

On 2012-08-25, at 11:52, Veronica Isabel Uquillas Gomez <vuquilla(a)vub.ac.be> wrote: > origin is not the same as package > in CompiledMethod origin refers to the class or trait that actually defines the method > > we do not have that in Ring. I will add that behavior but not with that name.. It does not say anything to me I think it would work out of the box with just one variable... origin would denote the logical place the method has been defined: normal method: the class trait method: the trait class extension method: the package I think that would make things quite clear...

Aug. 25, 2012

Re: [Pharo-project] serializing DynamicVariables (Zinc so far)

by Sven Van Caekenberghe

The nil default is used as a 'not set' third value. ZnSignalProgress class>>#enabled "Answer if HTTPProgress should be signalled. The default is false." ^ self value ifNil: [ false ] ifNotNil: [ :value | value ] ZnClient>>#withProgressDo: block ^ ZnSignalProgress value ifNil: [ ZnSignalProgress value: self signalProgress during: [ ^ block value ] ] ifNotNil: [ block value ] ZnClient>>#signalProgress "Return true if I signal HTTPProgress notifications during execution." ^ self optionAt: #signalProgress ifAbsent: [ false ] Sven On 25 Aug 2012, at 12:50, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 25 August 2012 09:31, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> Hi Sean. I am still seing the problem :( >> It is difficult to make it YOU to reproduce it, but it is easy that tomorrow >> I show it to you :) >> Basically, what is happening is that >> >> ZnClient >> executeRequestResponse >> self logRequest. >> ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Writing request' ]. >> request writeOn: connection. >> connection flush. >> ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Reading response' >> ]. >> response := request method = #HEAD >> ifTrue: [ ZnResponse readHeaderFrom: connection ] >> ifFalse: [ >> self streaming >> ifTrue: [ ZnResponse readStreamingFrom: connection ] >> ifFalse: [ ZnResponse readFrom: connection ] ]. >> self logResponse >> >> throws a mustBeBoolean in the first line "ZnSignalProgress enabled ". It >> seems that such expression answered the SmallINteger 30 the first time. >> If I take the debugger and I evaluate ZnSignalProgress enabled again, it >> answers me false, which is the correct value. >> Ahh yes, this in latest 2.0. > > I would have expected a ZnSignalProgress class >> default saying "^ > true" (or something else of a Boolean nature). DynamicVariables have a > default value of nil unless otherwise set. Or, since you're getting a > value of 30, something somewhere is saying ZnSignalProgress value: 30 > during: ["something"]... which would be very weird. > > frank > >> Thanks! >> >> >> On Fri, Aug 17, 2012 at 10:32 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >>> >>> Hi Frank and Sean. The problem was quite hard to reproduce. You need to >>> rebuild a Pharo image from a kernel using Tanker ;) >>> Anyway, since we are changing completely Tanker now it may have been >>> solved. I did a quick test (of a similar case) and it works. So once I have >>> the example of the kernel again I will trying again. >>> Thanks for offering the help! >>> >>> >>> On Fri, Aug 17, 2012 at 2:33 PM, Sean P. DeNigris <sean(a)clipperadams.com> >>> wrote: >>>> >>>> >>>> Mariano Martinez Peck wrote >>>>> >>>>> The first time, #enable answers something wrong. The second time it is >>>>> called, it seems to answer the correct value. >>>> >>>> Mariano, would you give some more details about the wrong value, the >>>> expected value, and the steps to reproduce? I took a look but I'm not >>>> seeing >>>> what the problem is... b.t.w. is this a 1.4 or 2.0 image? >>>> >>>> Sean >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://forum.world.st/serializing-DynamicVariables-Zinc-so-far-tp4643514p46… >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

Aug. 25, 2012

Re: [Pharo-project] serializing DynamicVariables (Zinc so far)

by Frank Shearar

On 25 August 2012 09:31, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi Sean. I am still seing the problem :( > It is difficult to make it YOU to reproduce it, but it is easy that tomorrow > I show it to you :) > Basically, what is happening is that > > ZnClient >> executeRequestResponse > self logRequest. > ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Writing request' ]. > request writeOn: connection. > connection flush. > ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Reading response' > ]. > response := request method = #HEAD > ifTrue: [ ZnResponse readHeaderFrom: connection ] > ifFalse: [ > self streaming > ifTrue: [ ZnResponse readStreamingFrom: connection ] > ifFalse: [ ZnResponse readFrom: connection ] ]. > self logResponse > > throws a mustBeBoolean in the first line "ZnSignalProgress enabled ". It > seems that such expression answered the SmallINteger 30 the first time. > If I take the debugger and I evaluate ZnSignalProgress enabled again, it > answers me false, which is the correct value. > Ahh yes, this in latest 2.0. I would have expected a ZnSignalProgress class >> default saying "^ true" (or something else of a Boolean nature). DynamicVariables have a default value of nil unless otherwise set. Or, since you're getting a value of 30, something somewhere is saying ZnSignalProgress value: 30 during: ["something"]... which would be very weird. frank > Thanks! > > > On Fri, Aug 17, 2012 at 10:32 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> Hi Frank and Sean. The problem was quite hard to reproduce. You need to >> rebuild a Pharo image from a kernel using Tanker ;) >> Anyway, since we are changing completely Tanker now it may have been >> solved. I did a quick test (of a similar case) and it works. So once I have >> the example of the kernel again I will trying again. >> Thanks for offering the help! >> >> >> On Fri, Aug 17, 2012 at 2:33 PM, Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >>> >>> >>> Mariano Martinez Peck wrote >>> > >>> > The first time, #enable answers something wrong. The second time it is >>> > called, it seems to answer the correct value. >>> >>> Mariano, would you give some more details about the wrong value, the >>> expected value, and the steps to reproduce? I took a look but I'm not >>> seeing >>> what the problem is... b.t.w. is this a 1.4 or 2.0 image? >>> >>> Sean >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/serializing-DynamicVariables-Zinc-so-far-tp4643514p46… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 25, 2012

Re: [Pharo-project] RGMethodDefininition

by Veronica Isabel Uquillas Gomez

origin is not the same as package in CompiledMethod origin refers to the class or trait that actually defines the method we do not have that in Ring. I will add that behavior but not with that name.. It does not say anything to me On 24 Aug 2012, at 17:58, Camillo Bruni wrote: > I think instead of having a 'package' instVar we should have something > like 'origin'. I remember adding #origin to CompiledMethod simplifying quite > a bit. > > > On 2012-08-24, at 17:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Good point >> I'm not sure that we handled that. >> >> On Aug 24, 2012, at 4:56 PM, Camillo Bruni wrote: >> >>> How can I figure out whether an RGMethodDefininition is coming from a Trait? >>> >>> method := (DatePrintFormatTester >> #shouldFix:). >>> method origin isTrait "returns true". >>> >>> how can I do the same with Ring? >

Aug. 25, 2012

Re: [Pharo-project] serializing DynamicVariables (Zinc so far)

by Mariano Martinez Peck

Hi Sean. I am still seing the problem :( It is difficult to make it YOU to reproduce it, but it is easy that tomorrow I show it to you :) Basically, what is happening is that ZnClient >> executeRequestResponse self logRequest. ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Writing request' ]. request writeOn: connection. connection flush. ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Reading response' ]. response := request method = #HEAD ifTrue: [ ZnResponse readHeaderFrom: connection ] ifFalse: [ self streaming ifTrue: [ ZnResponse readStreamingFrom: connection ] ifFalse: [ ZnResponse readFrom: connection ] ]. self logResponse throws a mustBeBoolean in the first line "ZnSignalProgress enabled ". It seems that such expression answered the SmallINteger 30 the first time. If I take the debugger and I evaluate ZnSignalProgress enabled again, it answers me false, which is the correct value. Ahh yes, this in latest 2.0. Thanks! On Fri, Aug 17, 2012 at 10:32 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi Frank and Sean. The problem was quite hard to reproduce. You need to > rebuild a Pharo image from a kernel using Tanker ;) > Anyway, since we are changing completely Tanker now it may have been > solved. I did a quick test (of a similar case) and it works. So once I have > the example of the kernel again I will trying again. > Thanks for offering the help! > > > On Fri, Aug 17, 2012 at 2:33 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > >> >> Mariano Martinez Peck wrote >> > >> > The first time, #enable answers something wrong. The second time it is >> > called, it seems to answer the correct value. >> >> Mariano, would you give some more details about the wrong value, the >> expected value, and the steps to reproduce? I took a look but I'm not >> seeing >> what the problem is... b.t.w. is this a 1.4 or 2.0 image? >> >> Sean >> >> >> >> -- >> View this message in context: >> http://forum.world.st/serializing-DynamicVariables-Zinc-so-far-tp4643514p46… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Aug. 25, 2012

Re: [Pharo-project] 'self halt' safety net

by Igor Stasenko

you can open .changes file in another image to rescue your code. also you can patch the image's bytecode to avoid entering an offending method (like a method which enters the drawing , just see its bytecode in another image, and the find same byte sequence in crashing image, and put return self bytecode) On 25 August 2012 03:42, Ben Coman <btc(a)openinworld.com> wrote: > Igor Stasenko wrote: >> >> On 4 August 2012 04:11, Ben Coman <btc(a)openinworld.com> wrote: >> >>> >>> As probably many newbies do from time to time, I am learning the system >>> splattering 'self halt' around, and once again slipped one into the wrong >>> place where I should have used 'haltOnce' and had a massive number of >>> pre-debugger windows come up. I managed to get it back this time with >>> the >>> user interrupt - but not always - and anyhow clearing so many debug >>> windows >>> is a pain. So..... could 'self halt' be made to monitor the rate that >>> the >>> halt windows appear, and when more than some value from one of them (say >>> five per second) it starts getting ignored and shows a dialog asking the >>> user if they really meant this and enable danger mode, or if they screwed >>> up >>> and want to revert the method containing the suspect 'halt'. >>> >>> >> >> >> If we look from user's perspective (not machine perspective), apparently >> it is pointless to throw so many messages at the user's face, because >> he cannot deal with them >> in meaningful manner at such rate. >> So, i think there should be something like following: >> - if exception requires a user interaction, we do show the popup, but >> meanwhile remember >> the exception which initiated it. >> - if there's next exception incoming and also asks UI manager to show >> it to user, we queue it, >> letting user to deal with first one.. (or we delay the popup , say 1 >> each 5 seconds). >> and finally, a queue should have some reasonable limit, after which we >> stop queuing , because again, user certainly won't be willing to waste >> his time dealing with 10000000 exceptions of same kind one by one. It >> doesn't makes sense anyways. >> >> In such case we can just ignore halt and let program continue (but >> increment some counter to show user how many of them are there). >> If exception is different (an Error) then on queue overflow, i think >> it should terminate the process with exception (but of course, special >> care must be taken if process is UI process). >> Of course making it too smart is pointless, because it is impossible >> to predict whether it is good idea >> to terminate process or letting it continue to run in case of exception. >> But for that we can have settings and options, to tune that at user's >> discretion, as well as default >> settings on a per-exception class base. >> >> >>> >>> anyhow, just musing.... -ben >>> >>> >> >> >> i know by myself how annoying it can be (up to unresponsive image) >> and i think most of us is facing such situation time to time (heh.. >> just yesterday we had it with Camillo while hacking ocompletion >> stuff). >> i learned to be careful and avoid such situations.. but sometimes it >> is hard and better tooling support will be helpful, no doubt. >> >> > > > > Another use case that just happened to me. This is not 'halt' related but > just a typo... (which suddenly makes the whole system feel a bit fragile) > Working on a small new feature in the drawing loop of Roassal, I would guess > "all" that I did was leave out a full stop at the end a line. So the image > locked and crashed after about 20 seconds. Unfortunately now the image is > crashing every time I try to open it. Some mechanism to throttle and > temporarily ignore the error to allow me to rectify the problem would have > been immensely useful. In this case, perhaps something like blocking the > main UI loop and presenting a modal window of a very basic self contained > text editor on the offending method. > At this moment, another immensely useful tool would be able to diff the > source code between a running image and an offline image, and import the > changes. > Is there any other way I might recover recent changes? Previously I have > not had much luck mixing a new image with the changes file fromt he crashed > image. > > regards -ben > > > ---------------------------------------- > THERE_BE_DRAGONS_HERE > MessageNotUnderstood: SmallInteger>>Transcript > 25 August 2012 8:58:18.345 am > > VM: Win32 - IX86 - 6.1 - CoInterpreter VMMaker-oscog-EstebanLorenzano.158 > uuid: 82eded98-68af-4c80-a472-4f6de293adcf May 1 2012, > StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.158 uuid: > 82eded98-68af-4c80-a472-4f6de293adcf May 1 2012, > https://git.gitorious.org/cogvm/blessed.git Commit: > 6aa3fd0f1188078d3167dec1a53031a61b97b688 Date: Tue May 1 20:28:14 2012 +0200 > By: Esteban Lorenzano <estebanlm(a)gmail.com> > Image: Pharo1.4 [Latest update: #14457] > > SmallInteger(Object)>>doesNotUnderstand: #Transcript > Receiver: 1 > Arguments and temporary variables: > aMessage: Transcript > exception: MessageNotUnderstood: SmallInteger>>Transcript > resumeValue: nil > Receiver's instance variables: > 1 > > ROOrthoVerticalLineShape>>lineSegmentsFor: > Receiver: a ROOrthoVerticalLineShape > Arguments and temporary variables: > > > --------------------------------------------------------------------- > Sat Aug 25 09:15:38 2012 > > > Error in the VM thread > Reason: out of memory > > > > Hardware information: > Manufacturer: Unknown > Model: Unknown > Number of processors: 4 > Page size: 4096 > > Memory Information (upon launch): > Physical Memory Size: 4194303 kbytes > Physical Memory Free: 4194303 kbytes > Page File Size: 4194303 kbytes > Page File Free: 4194303 kbytes > Virtual Memory Size: 2097024 kbytes > Virtual Memory Free: 2030848 kbytes > Memory Load: 21 percent > > Processor 0: AMD A10-4600M APU with Radeon(tm) HD Graphics > Identifier: AMD64 Family 21 Model 16 Stepping 1 > ~MHZ: 2295 > > Processor 1: AMD A10-4600M APU with Radeon(tm) HD Graphics > Identifier: AMD64 Family 21 Model 16 Stepping 1 > ~MHZ: 2295 > > Processor 2: AMD A10-4600M APU with Radeon(tm) HD Graphics > Identifier: AMD64 Family 21 Model 16 Stepping 1 > ~MHZ: 2295 > > Processor 3: AMD A10-4600M APU with Radeon(tm) HD Graphics > Identifier: AMD64 Family 21 Model 16 Stepping 1 > ~MHZ: 2295 > > Operating System: Windows 7 Home Premium (Build 7601 Service Pack 1) > Registered Owner: Ben > Registered Company: Toshiba > SP major version: 1 > SP minor version: 0 > Suite mask: 300 > Product type: 1 > > Display Information: > Graphics adapter name: AMD Radeon HD 7660G > Primary monitor resolution: 1366 x 768 > > Device: RDPDD Chained DD > Adapter String: ??? > Bios String: ??? > Chip Type: ??? > DAC Type: ??? > Memory Size: 0xFFFFFFFF > > Driver Versions: > RDPDD: > > VM Version: Cog VM 4.0.0 (release) from May 1 2012 > Compiler: gcc 4.5.2 > Interpreter Build: CoInterpreter VMMaker-oscog-EstebanLorenzano.158 uuid: > 82eded98-68af-4c80-a472-4f6de293adcf May 1 2012 > Cogit Build: StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.158 > uuid: 82eded98-68af-4c80-a472-4f6de293adcf May 1 2012 > Source Version: https://git.gitorious.org/cogvm/blessed.git Commit: > 6aa3fd0f1188078d3167dec1a53031a61b97b688 Date: Tue May 1 20:28:14 2012 +0200 > By: Esteban Lorenzano <estebanlm(a)gmail.com> > > Current byte code: 208 > Primitive index: 0 > > Loaded plugins: > > Module information: > 00400000 - 005ec000: > C:\Smalltalk\moose47-20120728-(StepCIM)\CogVM.exe > 04180000 - 04280000: CogCode > 695f0000 - 696d7000: C:\windows\system32\DDRAW.dll > 69770000 - 69838000: C:\windows\system32\OPENGL32.DLL > 6c240000 - 6c267000: C:\windows\system32\crtdll.dll > 719d0000 - 71a50000: C:\windows\system32\uxtheme.dll > 721c0000 - 72244000: > C:\windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\COMCTL32.dll > 72250000 - 7228c000: C:\windows\system32\OLEACC.dll > 72290000 - 722e1000: C:\windows\system32\WINSPOOL.DRV > 723d0000 - 723d9000: C:\windows\system32\VERSION.dll > 728f0000 - 72922000: C:\windows\system32\WINMM.dll > 729b0000 - 729e8000: C:\Program Files\Listary\ListaryHook32.dll > 730c0000 - 730d3000: C:\windows\system32\dwmapi.dll > 73150000 - 732ee000: > C:\windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.DLL > 73640000 - 73662000: C:\windows\system32\GLU32.dll > 73670000 - 73695000: C:\windows\system32\dinput.dll > 73830000 - 73836000: C:\windows\system32\DCIMAN32.dll > 74170000 - 74177000: C:\windows\system32\WSOCK32.DLL > 74310000 - 74315000: C:\windows\system32\SHFolder.dll > 746c0000 - 746cc000: C:\windows\syswow64\CRYPTBASE.dll > 746d0000 - 74730000: C:\windows\syswow64\SspiCli.dll > 74730000 - 74742000: C:\windows\syswow64\DEVOBJ.dll > 74750000 - 74860000: C:\windows\syswow64\kernel32.dll > 74860000 - 74960000: C:\windows\syswow64\USER32.dll > 74960000 - 7496a000: C:\windows\syswow64\LPK.dll > 74970000 - 749b6000: C:\windows\syswow64\KERNELBASE.dll > 74a20000 - 74a47000: C:\windows\syswow64\CFGMGR32.dll > 74a50000 - 74bac000: C:\windows\syswow64\OLE32.dll > 74bb0000 - 74bb6000: C:\windows\syswow64\NSI.dll > 74bc0000 - 74c50000: C:\windows\syswow64\GDI32.dll > 74c50000 - 74ced000: C:\windows\syswow64\USP10.dll > 74cf0000 - 74d50000: C:\windows\system32\IMM32.DLL > 74f00000 - 74f19000: C:\windows\SysWOW64\sechost.dll > 750e0000 - 751ac000: C:\windows\syswow64\MSCTF.dll > 752d0000 - 75327000: C:\windows\syswow64\SHLWAPI.dll > 75380000 - 7542c000: C:\windows\syswow64\msvcrt.dll > 75430000 - 75465000: C:\windows\syswow64\WS2_32.dll > 754a0000 - 75540000: C:\windows\syswow64\ADVAPI32.DLL > 755d0000 - 7564b000: C:\windows\syswow64\COMDLG32.DLL > 75650000 - 757ed000: C:\windows\syswow64\SETUPAPI.dll > 757f0000 - 7643a000: C:\windows\syswow64\SHELL32.dll > 76590000 - 76680000: C:\windows\syswow64\RPCRT4.dll > 76690000 - 7671f000: C:\windows\syswow64\OLEAUT32.dll > 76720000 - 76725000: C:\windows\syswow64\psapi.dll > 76ff0000 - 77170000: C:\windows\SysWOW64\ntdll.dll > > Primitive trace: > parameterAt:put: > parameterAt:put: > setGCBiasToGrowGCLimit: > setGCBiasToGrow: > > > Stack backtrace: > [0041E90D] ??? + 125197 in CogVM.exe > [00442022] ??? + 270370 in CogVM.exe > [004443F9] ??? + 279545 in CogVM.exe > [00445136] ??? + 282934 in CogVM.exe > [0043F735] ??? + 259893 in CogVM.exe > [0044BE49] ??? + 310857 in CogVM.exe > [0044CC2C] ??? + 314412 in CogVM.exe > [00537726] ??? + 1275686 in CogVM.exe > [004010DB] ??? + 4315 in CogVM.exe > [00401158] ??? + 4440 in CogVM.exe > [7476339A] AcquireSRWLockExclusive + 18 in kernel32.dll > [77029EF2] RtlInsertElementGenericTableAvl + 99 in ntdll.dll > [77029EC5] RtlInsertElementGenericTableAvl + 54 in ntdll.dll > [00000000] ??? + 0 in (null) > > > Smalltalk stack dump: > 0x1f00dc I SmalltalkImage>clearExternalObjects 71623188: a(n) > SmalltalkImage > 0x1f0108 I SmalltalkImage>snapshot:andQuit: 71623188: a(n) SmalltalkImage > 0x12105644 s [] in WorldState class>saveSession > 0x121056a0 s BlockClosure>ensure: > 0x120a7ed4 s CursorWithMask(Cursor)>showWhile: > 0x120a7e68 s WorldState class>saveSession > 0x121056fc s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: > 0x12105758 s BlockClosure>ensure: > 0x120a7df8 s CursorWithMask(Cursor)>showWhile: > 0x120a7d88 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: > 0x121057b4 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp: > 0x12105810 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp: > 0x1210586c s MouseButtonEvent>sentTo: > 0x121058c8 s ToggleMenuItemMorph(Morph)>handleEvent: > 0x12105924 s MorphicEventDispatcher>dispatchDefault:with: > 0x12105980 s MorphicEventDispatcher>dispatchEvent:with: > 0x121059dc s ToggleMenuItemMorph(Morph)>processEvent:using: > 0x12105a38 s MorphicEventDispatcher>dispatchDefault:with: > 0x12105a94 s MorphicEventDispatcher>dispatchEvent:with: > 0x12105af0 s MenuMorph(Morph)>processEvent:using: > 0x12105b4c s MenuMorph(Morph)>processEvent: > 0x12105ba8 s MenuMorph>handleFocusEvent: > 0x12105c04 s [] in HandMorph>sendFocusEvent:to:clear: > 0x12105c60 s [] in PasteUpMorph>becomeActiveDuring: > 0x12105cbc s BlockClosure>on:do: > 0x120a7c10 s PasteUpMorph>becomeActiveDuring: > 0x120a7b98 s HandMorph>sendFocusEvent:to:clear: > 0x12105d18 s HandMorph>sendEvent:focus:clear: > 0x120a7b24 s HandMorph>sendMouseEvent: > 0x12105d74 s HandMorph>handleEvent: > 0x12105dd0 s HandMorph>processEvents > 0x12105e2c s [] in WorldState>doOneCycleNowFor: > 0x12105e88 s Array(SequenceableCollection)>do: > 0x12105ee4 s WorldState>handsDo: > 0x120a79cc s WorldState>doOneCycleNowFor: > 0x12105f40 s WorldState>doOneCycleFor: > 0x12105f9c s PasteUpMorph>doOneCycle > 0xb289e94 s [] in MorphicUIManager>spawnNewProcess > 0xb289e10 s [] in BlockClosure>newProcess > > -- Best regards, Igor Stasenko.

Aug. 25, 2012