On 25 August 2012 20:19, Stéphane Ducasse <[email protected]> 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 <[email protected]> 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 >>> <[email protected]> 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 <[email protected]> >>>> 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-tp4643514p4644374.html >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> > >
