- Pharo-dev - lists.pharo.org

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

by Lawson English

I get this using Pharo 1.4. Thing is, it was working a few weeks ago and now not. I was hoping to do a video on how to add simple ultra-fast assembler methods using NB but still can't because the target is moving way too fast. My usual strategy is to show how to load a package in a brief intro video, and then how to use it in the second part. During the time I learned how to use NB at the assembler level, everything that I was doing broke. Kinda hard to make a video to show how to install and then use it those circumstances. L On 8/27/12 12:01 AM, Nicolas Cellier 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... > > 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. >>> > -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all

Aug. 27, 2012

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

by Igor Stasenko

On 27 August 2012 17:44, Ben Coman <btc(a)openinworld.com> wrote: > > > > > > 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? yes, just open .changes file in a file browser. this is what i meant to say.. Or, if you look at ChangeSet (or ChangeBrowser - don't remember the name) code, at class side you can find the methods which actually allow you to browse contents of a .changes file. and you can specify what file to open. you just need to do some research :) > >> 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. > maybe.. i don't know. need to think about it. >> 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] > -- Best regards, Igor Stasenko.

Aug. 27, 2012

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

by Eliot Miranda

On Mon, Aug 27, 2012 at 8:44 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > > > 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? > Ben, your changes were in the .changes file that you overwrote. You should have either a) unpacked the second image/changes in a different directory b) renamed the changes file you wanted to recover before unpacking the second image/changes c) unpacked the second image/changes with different names d) anything else that avoids overwriting the changes file you wanted to recover. its gone now unless you have a recent backup 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] > > -- best, Eliot

Aug. 27, 2012

Re: [Pharo-project] Reef examples and documentation

by Oscar E A CallaÃº

Thanks a lot. It would be really useful and a great marketing campaign to have a demo image. Something similar to JQueryMobile for Seaside: http://jquerymobile.seasidehosting.st May be I can work on it later, when I understand how Reef works. Cheers. On Aug 27, 2012, at 7:53 , StÃ©phane Ducasse wrote: > It is powerful > Here are the old documentation. > Esteban started to work on a new version but there is nothing readable. > > Stef > <ReefChapter1.pdf><reefChapter2.pdf> > 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] '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