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 <[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 >>>> >>> >> >> >
