[Cuis-dev] [] storeString freezes the image

Juan Vuletich juan at jvuletich.org
Tue Oct 27 06:55:53 PDT 2020

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.


Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201027/b6af0dbc/attachment.htm>

More information about the Cuis-dev mailing list