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 ]
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 <[email protected]> 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
>>
>
