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

Re: [Pharo-project] Spec Drag and Drop

by Benjamin

We will have a look together tomorrow ;) Ben On Aug 25, 2012, at 11:31 PM, Sean P. DeNigris wrote: > Ben, Christophe and I ran into problems implementing drag and drop in > Versionner. I'd like to get a quick point in the right direction tomorrow. > Also, it'd be great to be able to load Spec 1.1 in Pharo 1.4... > > See you tomorrow. > Sean > > > > -- > View this message in context: http://forum.world.st/Spec-Drag-and-Drop-tp4645300.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 26, 2012

Re: [Pharo-project] RGMethodDefininition

by Camillo Bruni

On 2012-08-25, at 21:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > origin is the place (trait) where the method is originally defined. so this is important. exactly, I'm just wondering if you need another variable. Cause you have - parent (which I assume is the class the method is installed id) - package (currently used to model extensions/normal methods) I think just having origin would solve this no? (most probably I forgot something :P) Basically you need to know two things of a method, where it is installed and where it came from. The installed place is given in Ring with parent, the place the method comes from however is not always correctly given...

Aug. 25, 2012

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

by Levente Uzonyi

On Sat, 25 Aug 2012, Frank Shearar wrote: > 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. Yeah, right, but it lacks the performance advantage of DynamicVariable over Exceptions. I don't think it's too much hassle to serialize the variables of the Process besides the stack (sometimes you just can't avoid it), but if you think it is, then a mixed system is the best solution: - store the value both in the process and on the stack - start the lookup in the process first, if the variable is not found there, then continue on the stack and store the result in the process before returning it, so it will be found next time there Levente > > 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

[Pharo-project] Spec Drag and Drop

by Sean P. DeNigris

Ben, Christophe and I ran into problems implementing drag and drop in Versionner. I'd like to get a quick point in the right direction tomorrow. Also, it'd be great to be able to load Spec 1.1 in Pharo 1.4... See you tomorrow. Sean -- View this message in context: http://forum.world.st/Spec-Drag-and-Drop-tp4645300.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 25, 2012

Re: [Pharo-project] HorribleBrokeEverythingNotWorkingBug

by StÃ©phane Ducasse

Thanks camillo! Do not worry about overreaction we are latin :) On Aug 25, 2012, at 5:52 PM, Camillo Bruni wrote: > 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 StÃ©phane Ducasse

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. 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. 25, 2012

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