August 2012 - Pharo-dev - lists.pharo.org

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

by Ben Coman

Igor Stasenko wrote: > you can open .changes file in another image to rescue your code. > Thanks Igor. I gave that a go but couldn't work it out. I tried the following: Unzipped a fresh image, copied the .changes file into the folder to overwrite the existing .changes file, then after starting the image tried (World > Tools > Recover lost changes...) but I get "Information: this image has never been saved since changes were compressed." Saving the image seems to empty the .changes file. I could not find another way. Is there something else I should be doing? > 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) > Thanks, but that is beyond my capability at the moment. Probably wishing for too much, but ideally some mechanism might use info from the debug.log to do this automatically. > 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 >> >> [Debug logs deleted]

Aug. 27, 2012

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

by Frank Shearar

On 27 August 2012 12:16, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sun, 26 Aug 2012, Frank Shearar wrote: > >> On 26 August 2012 17:55, Levente Uzonyi <leves(a)elte.hu> wrote: >>> >>> On Sun, 26 Aug 2012, Frank Shearar wrote: >>> >>>> That sounds like a reasonable workaround to address Mariano's >>>> immediate problem :) >>> >>> >>> >>> I don't see what other issues are there to solve. :) >> >> >> Then you should go reread my article, and the articles it references >> :) Both have examples of how undelimited dynamic variables don't work >> sensibly with delimited continuations. Kiselyov goes further and shows >> how they _cannot_ work sensibly. > > > I took a look why DynamicVariable doesn't work with Control and I found that > the reason is that Control doesn't play well with #ensure:. > Let's see it in this example: > > DynamicVariable value: 1 during: [ > [ DynamicVariable value: 2 during: [ > [ :k | DynamicVariable value ] shift ]] reset ] > > When #reset is sent, the value of the variable is 1, then it starts > evaluating the receiver block. The value is set to 2 and then #shift occurs. > #shift cuts the stack back, so the argument of #ensure:, which would restore > the value of the variable in the process' environment to 1 is never > evaluated. > > So Control breaks the contract of #ensure:, because it starts the evaluation > of its receiver, but doesn't evaluate its argument: The shift looks like it cuts out that part of the stack responsible for setting the DynamicVariable to 2. In fact, rather, it DOES cut it out. The problem is that the value's not stored on the stack, so the stack cutting doesn't behave as it should. So you have a well-implemented dynamic variable, and a well-implemented delimited continuation, and yet when you add them together you get broken behaviour. My point is that you _cannot_ have undelimited dynamic variables and delimited continuations behaving well together. Hence, if you're slicing stacks, you _cannot_ just use dynamic variables because they will not behave as they should. If you need a dynamic variable when slicing a stack, you need to use a delimited dynamic variable, which _will_ behave sensibly. Other than claims of higher performance (which would probably require VM changes to remove the need for all the stack-walking caused by the resumable exceptions), there's really no reason to choose undelimited dynamic variables: they're as expressive, but can't be combined with delimited continuations. And you want delimited continuations because undelimited continuations (call/cc and friends) not only suck but suck _hard_. Oh, and of course we have continuations whether we like them or not - thisContext. (In fact a fork is a delimited continuation.) frank > x := 0. > [ > [ > x := 1. > [ :k | x ] shift ] > ensure: [ x := 2 ] ] reset. > "==> 1" > > >> >> Serialising a running process implicitly creates a delimited >> continuation. Ergo, Fun Times! >> >> frank >> >>> Anyway, here's a highly >>> untested example of what I had in my mind: >>> http://leves.web.elte.hu/squeak/StackSerializableDynamicVariable.st >> >> >> Yep, using resumable exceptions to implement delimited dynamic >> variables. That's exactly what Control does, only without >> DynamicVariable necessarily polluting the global namespace. > > > The most common use case of DynamicVariable involves accessing the variable > from "unrelated" places. Using the global namespace is an easy way to avoid > passing the variable around all the time. It's basically the same as > subclassing Notification (which is a common practice - a pattern - to > implement dynamic variables) from this POV. > > >> >>> Is uses a method in Process which is not present in current images: >>> >>> environmentAt: key ifAbsentPut: aBlock >>> >>> ^(env ifNil: [ env := Dictionary new ]) at: key ifAbsentPut: >>> aBlock. >> >> >> Current _Pharo_ images, maybe. I'm pretty sure I looked at a trunk >> image with it in the last few hours (but obviously am too lazy to >> actually go check :/) > > > I just wrote this method, so I'm pretty sure it's not present in any image. > :) > > > Levente > >> >> frank >> >>> Levente >>> >> >> >

Aug. 27, 2012

Re: [Pharo-project] [ANN] NativeBoost v 1.3

by Igor Stasenko

On 27 August 2012 09:01, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Pharo 2.0 has implemented & -> bitAnd: and | -> bitOr: > > For who is dealing with bits, that's convenient, however it creates > one more case of false polymorphism, these messages being used for > Boolean already... > yeah.. and it created some problems with NB, since i using those methods internally as extensions , disregarding false/true polymorphism. perhaps i should refactor all senders of & and | to use bitAnd:/bitOr: to avoid being a victim of this. > Nicolas > > 2012/8/27 S Krish <krishnamachari.sudhakar(a)gmail.com>: >> On loading up and testing NB: >> >> I get possibly a very basic hurdle... Obliged for a heads up.. >> >> Can send the stack if its needed.. >> >> SmallInteger(Object)>>doesNotUnderstand: #& >> Receiver: 3 >> Arguments and temporary variables: >> aMessage: & 3 >> exception: MessageNotUnderstood: SmallInteger>>& >> resumeValue: nil >> Receiver's instance variables: >> 3 >> >> AJx86Instruction>>emitMod:reg:rm: >> Receiver: <<error during printing>> >> Arguments and temporary variables: >> mod: 3 >> reg: 37 >> rm: 36 >> Receiver's instance variables: >> name: #mov >> operands: an Array(EBP ESP) >> machineCode: a WriteStream >> position: 1 >> next: <<error during printing>> >> >> On Fri, Aug 24, 2012 at 7:19 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> > To load NativeBoost you can follow an instructions on project page: >>> > >>> http://code.google.com/p/nativeboost/wiki/Installation >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > -- Best regards, Igor Stasenko.

Aug. 27, 2012

Re: [Pharo-project] Reef examples and documentation

by StÃ©phane Ducasse

It is powerful Here are the old documentation. Esteban started to work on a new version but there is nothing readable. Stef On Aug 26, 2012, at 8:08 PM, Oscar E A Callau wrote: > Hi all, > > Do You known where I can find examples and documentation about Reef?. It seems to be quite powerful. I just found the slides and videos from esug 2010 and 2011. > > Cheers > > Ãscar E A Callau >

Aug. 27, 2012

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

by Levente Uzonyi

On Sun, 26 Aug 2012, Frank Shearar wrote: > On 26 August 2012 17:55, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Sun, 26 Aug 2012, Frank Shearar wrote: >> >>> That sounds like a reasonable workaround to address Mariano's >>> immediate problem :) >> >> >> I don't see what other issues are there to solve. :) > > Then you should go reread my article, and the articles it references > :) Both have examples of how undelimited dynamic variables don't work > sensibly with delimited continuations. Kiselyov goes further and shows > how they _cannot_ work sensibly. I took a look why DynamicVariable doesn't work with Control and I found that the reason is that Control doesn't play well with #ensure:. Let's see it in this example: DynamicVariable value: 1 during: [ [ DynamicVariable value: 2 during: [ [ :k | DynamicVariable value ] shift ]] reset ] When #reset is sent, the value of the variable is 1, then it starts evaluating the receiver block. The value is set to 2 and then #shift occurs. #shift cuts the stack back, so the argument of #ensure:, which would restore the value of the variable in the process' environment to 1 is never evaluated. So Control breaks the contract of #ensure:, because it starts the evaluation of its receiver, but doesn't evaluate its argument: x := 0. [ [ x := 1. [ :k | x ] shift ] ensure: [ x := 2 ] ] reset. "==> 1" > > Serialising a running process implicitly creates a delimited > continuation. Ergo, Fun Times! > > frank > >> Anyway, here's a highly >> untested example of what I had in my mind: >> http://leves.web.elte.hu/squeak/StackSerializableDynamicVariable.st > > Yep, using resumable exceptions to implement delimited dynamic > variables. That's exactly what Control does, only without > DynamicVariable necessarily polluting the global namespace. The most common use case of DynamicVariable involves accessing the variable from "unrelated" places. Using the global namespace is an easy way to avoid passing the variable around all the time. It's basically the same as subclassing Notification (which is a common practice - a pattern - to implement dynamic variables) from this POV. > >> Is uses a method in Process which is not present in current images: >> >> environmentAt: key ifAbsentPut: aBlock >> >> ^(env ifNil: [ env := Dictionary new ]) at: key ifAbsentPut: aBlock. > > Current _Pharo_ images, maybe. I'm pretty sure I looked at a trunk > image with it in the last few hours (but obviously am too lazy to > actually go check :/) I just wrote this method, so I'm pretty sure it's not present in any image. :) Levente > > frank > >> Levente >> > >

Aug. 27, 2012

Re: [Pharo-project] [ENH]: MCHttpRepository Authentication (Issue 6449)

by Sean P. DeNigris

Fix in inbox. You specify the credentials to be used for a url and all new instances of MCHttpRepository will use those credentials. For example: registry := MCServerRegistry uniqueInstance. registry on: self exampleServerUrl beUser: 'myusername' withPassword: 'mypassword'. repo := MCHttpRepository location: self exampleServerUrl. repo user = 'myusername'. repo password = 'mypassword'. Full details: * Add MCServerRegistry, a singleton which stores credentials for MCHttpRepository locations (see #on:beUser:withPassword:) * Add MCHttpRepository class>>location:, which uses any stored credentials, or empty user and password if none -Change all senders manually setting empty credentials to use #location. e.g. MCHttpRepository location: 'http://ss3.gemstone.com/ss/Pharo20' user: '' password: '' or worse MCHttpRepository new location: self inboxRepositoryUrlString; user: ''; password: '' becomes: MCHttpRepository location: 'http://ss3.gemstone.com/ss/Pharo20'. * Fix Gofer repo authentication - Replace switch statement with polymorphic delegation - Setting credentials only effects the repo for that Gofer instance; does not change the stored credentials * Tests - added for new behavior, fixed relevant existing; all passing * MCHttpRepository class>>location:user:password: only effects that repo; does not change the stored credentials -- View this message in context: http://forum.world.st/ENH-MCHttpRepository-Authentication-Issue-6449-tp4641… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 27, 2012

Re: [Pharo-project] [update 2.0] #20269

by Pavel Krivanek

Hi, it is not possible to move messages between packages. http://code.google.com/p/pharo/issues/detail?id=6607 -- Pavel On Sun, Aug 26, 2012 at 4:28 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > btw... this last change finish first step to getting rid off PackageInfo (replacing it with RPackage)... your browser will looks weird, but with some time this will be cool... just be patient :) > > Esteban > > On Aug 26, 2012, at 4:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> 20269 >> ----- >> >> Issue 6575: Import RPackage from MC packages with tags >> http://code.google.com/p/pharo/issues/detail?id=6575 >> >> Issue 6578: Make Monticello work with new repackaging announcements >> http://code.google.com/p/pharo/issues/detail?id=6578 > >

Aug. 27, 2012

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

by StÃ©phane Ducasse

we are not in hurry :) On Aug 26, 2012, at 4:25 PM, Frank Shearar wrote: > On 25 August 2012 20:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> frank would you be interested to write a chapter on dynamicVariable and delimited one? >> Because it would be really good to be able to read that. > > I would, but I'll only have time for it next month or later. I need to > write decent documentation for the library anyway, so I could always > solve both issues in one go. > > frank > >> On Aug 25, 2012, at 12:50 PM, Frank Shearar 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. 27, 2012

Re: [Pharo-project] [ANN] NativeBoost v 1.3

by Nicolas Cellier

Pharo 2.0 has implemented & -> bitAnd: and | -> bitOr: For who is dealing with bits, that's convenient, however it creates one more case of false polymorphism, these messages being used for Boolean already... Nicolas 2012/8/27 S Krish <krishnamachari.sudhakar(a)gmail.com>: > On loading up and testing NB: > > I get possibly a very basic hurdle... Obliged for a heads up.. > > Can send the stack if its needed.. > > SmallInteger(Object)>>doesNotUnderstand: #& > Receiver: 3 > Arguments and temporary variables: > aMessage: & 3 > exception: MessageNotUnderstood: SmallInteger>>& > resumeValue: nil > Receiver's instance variables: > 3 > > AJx86Instruction>>emitMod:reg:rm: > Receiver: <<error during printing>> > Arguments and temporary variables: > mod: 3 > reg: 37 > rm: 36 > Receiver's instance variables: > name: #mov > operands: an Array(EBP ESP) > machineCode: a WriteStream > position: 1 > next: <<error during printing>> > > On Fri, Aug 24, 2012 at 7:19 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> > To load NativeBoost you can follow an instructions on project page: >> > >> http://code.google.com/p/nativeboost/wiki/Installation >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

Aug. 27, 2012

Re: [Pharo-project] [ANN] NativeBoost v 1.3

by S Krish

On loading up and testing NB: I get possibly a very basic hurdle... Obliged for a heads up.. Can send the stack if its needed.. SmallInteger(Object)>>doesNotUnderstand: #& Receiver: 3 Arguments and temporary variables: aMessage: & 3 exception: MessageNotUnderstood: SmallInteger>>& resumeValue: nil Receiver's instance variables: 3 AJx86Instruction>>emitMod:reg:rm: Receiver: <<error during printing>> Arguments and temporary variables: mod: 3 reg: 37 rm: 36 Receiver's instance variables: name: #mov operands: an Array(EBP ESP) machineCode: a WriteStream position: 1 next: <<error during printing>> On Fri, Aug 24, 2012 at 7:19 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > To load NativeBoost you can follow an instructions on project page: > > > http://code.google.com/p/nativeboost/wiki/Installation > > > -- > Best regards, > Igor Stasenko. > >

Aug. 27, 2012