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 >
