[Cuis-dev] [] storeString freezes the image

[Nicolás Papagna Maldonado]

Hi Juan, folks

I gave the code a quick try and, for my needs, it is working great.
Tried storing a block closure as a preference value and I was able to
retrieve and evaluated fine.

Also, I removed the preference so the compiled accessor exercise the
"ifAbsent" branch, and the closure was reconstructed and evaluated fine
too 👏

One minor thing, this is how it looks (I don't know if that is intended or
not):

*testPref*
  ^ self
    valueOfFlag: #testPref
    ifAbsent: [
           (*SerializableBlockClosure* basicNew

            instVarAt: 1
            put: nil;

            instVarAt: 2
            put: '[ BrowserWindow findClass. ]';

            instVarAt: 3
            put: #();
      yourself) asEvaluable ].

Al least from my needs, it is good to go.
Thinking out loud here too, I don't think anyone is relying on this
behavior because, well... the image freezes :)

Thanks!
Nico PM

On Tue, Oct 27, 2020 at 12:19 PM Nicolás Papagna Maldonado <
nicolas.papagna at gmail.com> wrote:

> Yay! That sounds awesome!
>
> I'll take it for a ride tonight and let you folks know how it worked.
>
> Thanks!
> Nico PM
>
> On Tue, Oct 27, 2020 at 10:55 AM Juan Vuletich <juan at jvuletich.org> wrote:
>
>> On 10/26/2020 10:41 PM, Nicolás Papagna Maldonado via Cuis-dev wrote:
>>
>> Hi folks!
>> Hope you're doing fine :)
>>
>> Just found this issue while I was trying to add a new Preference whose
>> value is a block.
>> Specifically, I want users to be able to configure the block that should
>> be used for opening the class finder (either the default one or
>> Cuis-Finder).
>>
>> The issue starts when Preferences>>compileAccessMethodForPreference: is
>> evaluated: the message storeString is sent to the preference value (in
>> this case a block) to create the code for its accessor method.
>> Turns out that if you send storeString to a block (say [] storeString)
>> the image freezes and the only way to exit is to kill the process.
>>
>> The whole thing seems to be caused by the default implementation that is
>> used (Object>>storeOn:) when the first instance variable is retrieved.
>> I'm not sure what a custom implementation of BlockClosure>>storeOn: or
>> if it should have one at all, but if we are unable to store blocks into
>> strings maybe it will be better if we fail.
>>
>> What are your thoughts?
>>
>> Cheers,
>> Nico PM
>>
>>
>> Hi Nico, Folks,
>>
>> You are lucky today! This problem is not trivial, and our friend Ken
>> Dickey complained for years about not being able to store closures in
>> SmartRefStreams. I finally implemented the solution about a year ago. So,
>> the only thing you need is
>> BlockClosure >>
>> storeOn: aStream
>>     aStream nextPut: $(.
>>     self asSerializable storeOn: aStream.
>>     aStream nextPutAll: ' asEvaluable)'
>>
>> Please try it. If this works fine for everybody, I'll push it to GitHub.
>>
>> BTW, you can browse SerializableBlockClosure to see how I did it. It took
>> me many hours to get it right! This has many applications, for example, the
>> ability to store any object (including SortedCollections with sortBlock,
>> live Morphs, etc) on files or even the clipboard, and materializing them in
>> a different image.
>>
>> Cheers,
>>
>> --
>> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
>> @JuanVuletich
>>
>>
>
> --
>
> Nicolás Papagna
>


-- 

Nicolás Papagna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201027/40473c49/attachment.htm>