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

Frank Shearar frank.shearar at gmail.com
Sun Aug 26 13:25:53 CEST 2012


On 25 August 2012 22:34, Levente Uzonyi <leves at elte.hu> wrote:
> On Sat, 25 Aug 2012, Frank Shearar wrote:
>
>> On 25 August 2012 14:30, Levente Uzonyi <leves at 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-express-delimited-dynamic-variables).
>>
>> 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.

Sure: every time you want to evaluate the delimited dynvar you have to
walk the stack up to the last set value. The solution to that would be
to hack Contexts to support the dynamic environment, but that would be
rather more drastic.

The choices thus become, if you want sensible behaviour with general
stack hacking:
* have DynamicVariables that have broken behaviour when you do any
kind of stack manipulations (and they cannot be fixed: implement them
differently and you'll simply have _different_ broken behaviour)
* take the performance hit and use DelimitedDynamicVariables as they are
* spend ages hacking the image/VM to support dynamic environments
directly, instead of using resumable exceptions. (Essentially you'd
need to extend a Context to have a Dictionary (or similar) containing
the dynamic environment. Touching Context means - as far as I
understand things, at least - touching the VM because the VM knows a
whole lot about Contexts.)

frank

> 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

That sounds like a reasonable workaround to address Mariano's
immediate problem :)

frank

> 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 at gmail.com> wrote:
>>>>
>>>>> On 25 August 2012 09:31, Mariano Martinez Peck <marianopeck at 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 at 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 at 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-tp4643514p4644374.html
>>>>>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mariano
>>>>>>> http://marianopeck.wordpress.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mariano
>>>>>> http://marianopeck.wordpress.com
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>



More information about the Pharo-project mailing list