[Cuis-dev]  storeString freezes the image
Nicolás Papagna Maldonado
nicolas.papagna at gmail.com
Tue Oct 27 17:16:43 PDT 2020
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
One minor thing, this is how it looks (I don't know if that is intended or
put: '[ BrowserWindow findClass. ]';
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 :)
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.
> 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
>> 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?
>> 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.
>> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
> Nicolás Papagna
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cuis-dev