and you can send PR to improve it :)
> On 5 Dec 2020, at 00:23, Offray Vladimir Luna Cárdenas > <offray.l...@mutabit.com> wrote: > > Ohhh :-O ... where is the STON booklet. I would love to read it. > > Thanks, > > Offray > > On 4/12/20 3:24 p. m., Stéphane Ducasse wrote: >> Done :) >> >> >>> On 4 Dec 2020, at 21:20, Stéphane Ducasse <stephane.duca...@inria.fr >>> <mailto:stephane.duca...@inria.fr>> wrote: >>> >>> It looks like it is recurring enough to be part of the Ston booklet :) >>> >>> I will add it. >>> >>> S. >>> >>>> On 1 Dec 2020, at 10:54, Sven Van Caekenberghe <s...@stfx.eu >>>> <mailto:s...@stfx.eu>> wrote: >>>> >>>> Hi Offray, >>>> >>>> This is a recurring question. BlockClosures are way too general and >>>> powerful to be serialised. That is why serialising BlockClosures is not >>>> supported in STON. >>>> >>>> The code inside a block can refer to and even affect state outside the >>>> block. Furthermore the return operator is quite special as it returns from >>>> some outer context. >>>> >>>> A subset of BlockClosures are those that are clean. These do not close >>>> over other variables, nor do they contain a return. By using their source >>>> code representation, it is possible to serialise/materialise them. >>>> >>>> You can try this by adding the following methods: >>>> >>>> BlockClosure>>#stonOn: stonWriter >>>> self isClean >>>> ifTrue: [ stonWriter writeObject: self listSingleton: self printString ] >>>> ifFalse: [ stonWriter error: 'Only clean blocks can be serialized' ] >>>> >>>> BlockClosure>>#stonContainSubObjects >>>> ^ false >>>> >>>> BlockClosure class>>#fromSton: stonReader >>>> ^ self compilerClass new >>>> source: stonReader parseListSingleton; >>>> evaluate >>>> >>>> With these additions you can do the following: >>>> >>>> STON fromString: (STON toString: [ :x :y | x + y ]). >>>> >>>> Note that the actual class name depends on the Pharo version (BlockClosure >>>> in Pharo 7, FullBlockClosure in Pharo 9 and maybe soon CleanBlockClosure - >>>> Marcus is working on that last one and that would be very cool because it >>>> would say exactly what it it). >>>> >>>> I am still not 100% convinced to add this as a standard feature to STON. >>>> Using source code fully exposes the implementation, while using the >>>> compiler can be dangerous. It also adds a dependency on source code and >>>> the compiler. But it would be good if people can experiment with this >>>> feature. >>>> >>>> Does this help you ? >>>> >>>> Regards, >>>> >>>> Sven >>>> >>>> PS: I would not modify an object just to serialise it. >>>> >>>>> On 30 Nov 2020, at 18:19, Offray Vladimir Luna Cárdenas >>>>> <offray.l...@mutabit.com <mailto:offray.l...@mutabit.com>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm using STON for all my light storage serialization needs, like the >>>>> Grafoscopio notebooks, and I also love it, as Russ stated in their mail >>>>> question, and I share with him a similar request: for my Brea[1] static >>>>> site generator I would like to store some BreaQuery objects as external >>>>> STON files, and recover them, so I can run the queries that >>>>> recreate/update the website easily. I could store them as Grafoscopio >>>>> notebooks, but I don't want to make Grafoscopio a prerequisite for Brea >>>>> or I could use Fuel, but I would like to store queries as a diff >>>>> friendly text based format. I have considered Metacello/Iceberg packages >>>>> to export code in a diff friendly format, but It maybe overkill. So I >>>>> would like to see if STON can serve me here too. >>>>> >>>>> [1] https://mutabit.com/repos.fossil/brea/ >>>>> <https://mutabit.com/repos.fossil/brea/> >>>>> [2] https://mutabit.com/repos.fossil/indieweb/ >>>>> <https://mutabit.com/repos.fossil/indieweb/> >>>>> >>>>> So far, I'm able to serialize a code block as a string using: >>>>> >>>>> BreaQuery>>asStonModified >>>>> self codeBlock: self codeBlock asString >>>>> ^ STON toStringPretty: self >>>>> >>>>> But I'm unable to populate a block from a string. There is any way to >>>>> make a string, lets say 'a + b', to become the code contents of a block, >>>>> ie: [a + b ] ? >>>>> >>>>> Thanks, >>>>> >>>>> Offray >>>>> >>> >>> -------------------------------------------- >>> Stéphane Ducasse >>> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / >>> http://www.pharo.org <http://www.pharo.org/> >>> 03 59 35 87 52 >>> Assistant: Aurore Dalle >>> FAX 03 59 57 78 50 >>> TEL 03 59 35 86 16 >>> S. Ducasse - Inria >>> 40, avenue Halley, >>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza >>> Villeneuve d'Ascq 59650 >>> France >>> >> >> -------------------------------------------- >> Stéphane Ducasse >> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / >> http://www.pharo.org <http://www.pharo.org/> >> 03 59 35 87 52 >> Assistant: Aurore Dalle >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> -------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France
