Good morning all from stormy Ohio/USA. Hope everyone is well and sheltering effectively from COVID, etc. I have a STON question. FIrst off, I LOVE STON. It has been the answer to my (minimal) persistence needs. I'm writing two different applications, both of which I hope to distribute someday, and I struggled with what would work to save configurations, templates, status, etc. STON was the answer for me - it's very easy to install and simple to use. But as I add the next feature/function in my code - sort blocks - as soon as I tried to save them (a collection of them in an instvar)... I get an error on the writeToSTON, and the target file is now corrupt - at the point where it tried to write the blocks. I have looked in the documentation and it plainly states the version I'm using does not yet address blocks - but I was hoping someone out there has developed a workaround, or perhaps has STON been updated to handle blocks? I could make the jump to a more sophisticated storage mechanism (i.e. Fuel?), but I'd rather spend my time working on features and figuring out the Spec2 GUI. :) Any advice is welcome and appreciated. Thanks! Russ -- Russ Whaley whaley.russ@gmail.com
Hi Russ, The limitation of STON not being capable of serialising a block closure still stands and will probably not change very soon (it open up the whole language to be written out). You can work around this though, with sort functions for example. Here is an example: { 1->#one. 3->#three. 2->#two } sorted: (STON fromString: (STON toStringPretty: #key ascending)). SortFunctions are really cool BTW (they can handles nil values elegantly). Sven
On 27 Jun 2020, at 16:07, Russ Whaley <whaley.russ@gmail.com> wrote:
Good morning all from stormy Ohio/USA. Hope everyone is well and sheltering effectively from COVID, etc.
I have a STON question. FIrst off, I LOVE STON. It has been the answer to my (minimal) persistence needs. I'm writing two different applications, both of which I hope to distribute someday, and I struggled with what would work to save configurations, templates, status, etc. STON was the answer for me - it's very easy to install and simple to use.
But as I add the next feature/function in my code - sort blocks - as soon as I tried to save them (a collection of them in an instvar)... I get an error on the writeToSTON, and the target file is now corrupt - at the point where it tried to write the blocks. I have looked in the documentation and it plainly states the version I'm using does not yet address blocks - but I was hoping someone out there has developed a workaround, or perhaps has STON been updated to handle blocks?
I could make the jump to a more sophisticated storage mechanism (i.e. Fuel?), but I'd rather spend my time working on features and figuring out the Spec2 GUI. :)
Any advice is welcome and appreciated.
Thanks! Russ
-- Russ Whaley whaley.russ@gmail.com
On 27 Jun 2020, at 16:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Russ,
The limitation of STON not being capable of serialising a block closure still stands and will probably not change very soon (it open up the whole language to be written out).
You can work around this though, with sort functions for example.
Here is an example:
{ 1->#one. 3->#three. 2->#two } sorted: (STON fromString: (STON toStringPretty: #key ascending)).
SortFunctions are really cool BTW (they can handles nil values elegantly).
Sven
Sven do you think that we should have a little section on this question in STON chapter. S
Hi Stef, With the following commit https://github.com/svenvc/ston/commit/3565d388172b76c180454575d4c2f71019f130... there is now basic support for SortCollections using SortFunctions. All of the following can now be serialised and materialised by STON (see #testSortedCollections): SortedCollection new. SortedCollection new: 0. #(5 3 7 2 1 4 10 9 8 6) asSortedCollection. #(5 3 7 2 1 4 10 9 8 6) asSortedCollection: #yourself ascending. #(5 3 7 2 1 4 10 9 8 6) asSortedCollection: #yourself descending. #('****' '*' '*****' '**' '***') asSortedCollection: #size ascending. #('****' '*' '*****' '**' '***') asSortedCollection: #size descending. #(5 3 7 2 1 4 10 nil 9 8 6) asSortedCollection: #yourself ascending undefinedFirst. #(5 3 7 2 1 4 10 nil 9 8 6) asSortedCollection: #yourself ascending reversed undefinedLast. I think this trick covers a large set of SortedCollection use cases avoiding blocks by using SortFunctions. This technique could also be used to replace other block usages elsewhere. To answer your original question: yes we could add this to the documentation (although right now it is very new and unproven). Regards, Sven
On 28 Jun 2020, at 12:25, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On 27 Jun 2020, at 16:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Russ,
The limitation of STON not being capable of serialising a block closure still stands and will probably not change very soon (it open up the whole language to be written out).
You can work around this though, with sort functions for example.
Here is an example:
{ 1->#one. 3->#three. 2->#two } sorted: (STON fromString: (STON toStringPretty: #key ascending)).
SortFunctions are really cool BTW (they can handles nil values elegantly).
Sven
Sven do you think that we should have a little section on this question in STON chapter.
S
Ok I will allocate some time to produce a booklet on ston :). S.
On 30 Jun 2020, at 23:05, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Stef,
With the following commit https://github.com/svenvc/ston/commit/3565d388172b76c180454575d4c2f71019f130...
there is now basic support for SortCollections using SortFunctions.
All of the following can now be serialised and materialised by STON (see #testSortedCollections):
SortedCollection new. SortedCollection new: 0.
#(5 3 7 2 1 4 10 9 8 6) asSortedCollection.
#(5 3 7 2 1 4 10 9 8 6) asSortedCollection: #yourself ascending. #(5 3 7 2 1 4 10 9 8 6) asSortedCollection: #yourself descending.
#('****' '*' '*****' '**' '***') asSortedCollection: #size ascending. #('****' '*' '*****' '**' '***') asSortedCollection: #size descending.
#(5 3 7 2 1 4 10 nil 9 8 6) asSortedCollection: #yourself ascending undefinedFirst. #(5 3 7 2 1 4 10 nil 9 8 6) asSortedCollection: #yourself ascending reversed undefinedLast.
I think this trick covers a large set of SortedCollection use cases avoiding blocks by using SortFunctions.
This technique could also be used to replace other block usages elsewhere.
To answer your original question: yes we could add this to the documentation (although right now it is very new and unproven).
Regards,
Sven
On 28 Jun 2020, at 12:25, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On 27 Jun 2020, at 16:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Russ,
The limitation of STON not being capable of serialising a block closure still stands and will probably not change very soon (it open up the whole language to be written out).
You can work around this though, with sort functions for example.
Here is an example:
{ 1->#one. 3->#three. 2->#two } sorted: (STON fromString: (STON toStringPretty: #key ascending)).
SortFunctions are really cool BTW (they can handles nil values elegantly).
Sven
Sven do you think that we should have a little section on this question in STON chapter.
S
-------------------------------------------- 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
Thank you Sven! This is really convenient. SortFunctions are really cool. Esteban A. Maringolo On Tue, Jun 30, 2020 at 6:06 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Stef,
With the following commit https://github.com/svenvc/ston/commit/3565d388172b76c180454575d4c2f71019f130...
there is now basic support for SortCollections using SortFunctions.
All of the following can now be serialised and materialised by STON (see #testSortedCollections):
SortedCollection new. SortedCollection new: 0.
#(5 3 7 2 1 4 10 9 8 6) asSortedCollection.
#(5 3 7 2 1 4 10 9 8 6) asSortedCollection: #yourself ascending. #(5 3 7 2 1 4 10 9 8 6) asSortedCollection: #yourself descending.
#('****' '*' '*****' '**' '***') asSortedCollection: #size ascending. #('****' '*' '*****' '**' '***') asSortedCollection: #size descending.
#(5 3 7 2 1 4 10 nil 9 8 6) asSortedCollection: #yourself ascending undefinedFirst. #(5 3 7 2 1 4 10 nil 9 8 6) asSortedCollection: #yourself ascending reversed undefinedLast.
I think this trick covers a large set of SortedCollection use cases avoiding blocks by using SortFunctions.
This technique could also be used to replace other block usages elsewhere.
To answer your original question: yes we could add this to the documentation (although right now it is very new and unproven).
Regards,
Sven
On 28 Jun 2020, at 12:25, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On 27 Jun 2020, at 16:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Russ,
The limitation of STON not being capable of serialising a block closure still stands and will probably not change very soon (it open up the whole language to be written out).
You can work around this though, with sort functions for example.
Here is an example:
{ 1->#one. 3->#three. 2->#two } sorted: (STON fromString: (STON toStringPretty: #key ascending)).
SortFunctions are really cool BTW (they can handles nil values elegantly).
Sven
Sven do you think that we should have a little section on this question in STON chapter.
S
Sven Van Caekenberghe-2 wrote
there is now basic support for SortCollections using SortFunctions.
Cool! This would be great to have in Fuel as well. There is a slow and steady stream of users running into trouble trying to serialize blocks (whatever the library) due primarily to sorted collections. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On Thu, Jul 2, 2020 at 11:46 AM Sean P. DeNigris <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
there is now basic support for SortCollections using SortFunctions.
Cool! This would be great to have in Fuel as well. There is a slow and steady stream of users running into trouble trying to serialize blocks (whatever the library) due primarily to sorted collections.
Wouldn't that work out of the box with Fuel? A SortFunction is a simple object, and even a ChainedSortFunction is the same. So if you have: #(4 2 2 1) asSortedCollection: #yourself ascending You end up with a SortedCollection without any blocks, because its sortBlock is actually a SortFunction. Regards! Esteban A. Maringolo
Hi russ, I do not if you know but based on Ston I built chrysal to manage applications configuration: https://github.com/ducasse/chrysal <https://github.com/ducasse/chrysal> The basic idea is that you describe the possible fields of your configuration (i.e. how user can edit JSON files) and it generates a converter from STON to your pharo objects. You ship just the converter and its textual description so that you understand what you did. But this is probably not what you need but more a textual serializer. S.
On 27 Jun 2020, at 16:07, Russ Whaley <whaley.russ@gmail.com> wrote:
Good morning all from stormy Ohio/USA. Hope everyone is well and sheltering effectively from COVID, etc.
I have a STON question. FIrst off, I LOVE STON. It has been the answer to my (minimal) persistence needs. I'm writing two different applications, both of which I hope to distribute someday, and I struggled with what would work to save configurations, templates, status, etc. STON was the answer for me - it's very easy to install and simple to use.
But as I add the next feature/function in my code - sort blocks - as soon as I tried to save them (a collection of them in an instvar)... I get an error on the writeToSTON, and the target file is now corrupt - at the point where it tried to write the blocks. I have looked in the documentation and it plainly states the version I'm using does not yet address blocks - but I was hoping someone out there has developed a workaround, or perhaps has STON been updated to handle blocks?
I could make the jump to a more sophisticated storage mechanism (i.e. Fuel?), but I'd rather spend my time working on features and figuring out the Spec2 GUI. :)
Any advice is welcome and appreciated.
Thanks! Russ
-- Russ Whaley whaley.russ@gmail.com <mailto:whaley.russ@gmail.com>
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
Stephane, Thanks for the info on chrysal. I'm going to like going through the code to see how you solved some things. I created my own Configuration class that operates with a dictionary of keys the applications expect to use, and configuration values (paths, numerics, dates, strings...) but not blocks!... and save to and read from a STON file when a 'configs' instvar is referenced in the application. So far the only limitation I've come into is saving blocks, but admittedly I'm building it out as I need it. Looking forward to reviewing chrysal! Thanks, Russ On Sun, Jun 28, 2020 at 6:25 AM Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi russ,
I do not if you know but based on Ston I built chrysal to manage applications configuration:
https://github.com/ducasse/chrysal
The basic idea is that you describe the possible fields of your configuration (i.e. how user can edit JSON files) and it generates a converter from STON to your pharo objects. You ship just the converter and its textual description so that you understand what you did.
But this is probably not what you need but more a textual serializer.
S.
On 27 Jun 2020, at 16:07, Russ Whaley <whaley.russ@gmail.com> wrote:
Good morning all from stormy Ohio/USA. Hope everyone is well and sheltering effectively from COVID, etc.
I have a STON question. FIrst off, I LOVE STON. It has been the answer to my (minimal) persistence needs. I'm writing two different applications, both of which I hope to distribute someday, and I struggled with what would work to save configurations, templates, status, etc. STON was the answer for me - it's very easy to install and simple to use.
But as I add the next feature/function in my code - sort blocks - as soon as I tried to save them (a collection of them in an instvar)... I get an error on the writeToSTON, and the target file is now corrupt - at the point where it tried to write the blocks. I have looked in the documentation and it plainly states the version I'm using does not yet address blocks - but I was hoping someone out there has developed a workaround, or perhaps has STON been updated to handle blocks?
I could make the jump to a more sophisticated storage mechanism (i.e. Fuel?), but I'd rather spend my time working on features and figuring out the Spec2 GUI. :)
Any advice is welcome and appreciated.
Thanks! Russ
-- Russ Whaley whaley.russ@gmail.com
-------------------------------------------- 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
-- Russ Whaley whaley.russ@gmail.com
On 28 Jun 2020, at 18:22, Russ Whaley <whaley.russ@gmail.com> wrote:
Stephane, Thanks for the info on chrysal. I'm going to like going through the code to see how you solved some things. I created my own Configuration class that operates with a dictionary of keys the applications expect to use, and configuration values (paths, numerics, dates, strings...) but not blocks!... and save to and read from a STON file when a 'configs' instvar is referenced in the application. So far the only limitation I've come into is saving blocks, but admittedly I'm building it out as I need it.
Looking forward to reviewing chrysal!
Chrysal is used to simplify the hell of pillar configuration. Now I just used it in this context. I thought about it from a point of view of a non pharoer. So I have basic types (boolean, string, numbers) + files and sequence and composite.
Thanks, Russ
On Sun, Jun 28, 2020 at 6:25 AM Stéphane Ducasse <stephane.ducasse@inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: Hi russ,
I do not if you know but based on Ston I built chrysal to manage applications configuration:
https://github.com/ducasse/chrysal <https://github.com/ducasse/chrysal>
The basic idea is that you describe the possible fields of your configuration (i.e. how user can edit JSON files) and it generates a converter from STON to your pharo objects. You ship just the converter and its textual description so that you understand what you did.
But this is probably not what you need but more a textual serializer.
S.
On 27 Jun 2020, at 16:07, Russ Whaley <whaley.russ@gmail.com <mailto:whaley.russ@gmail.com>> wrote:
Good morning all from stormy Ohio/USA. Hope everyone is well and sheltering effectively from COVID, etc.
I have a STON question. FIrst off, I LOVE STON. It has been the answer to my (minimal) persistence needs. I'm writing two different applications, both of which I hope to distribute someday, and I struggled with what would work to save configurations, templates, status, etc. STON was the answer for me - it's very easy to install and simple to use.
But as I add the next feature/function in my code - sort blocks - as soon as I tried to save them (a collection of them in an instvar)... I get an error on the writeToSTON, and the target file is now corrupt - at the point where it tried to write the blocks. I have looked in the documentation and it plainly states the version I'm using does not yet address blocks - but I was hoping someone out there has developed a workaround, or perhaps has STON been updated to handle blocks?
I could make the jump to a more sophisticated storage mechanism (i.e. Fuel?), but I'd rather spend my time working on features and figuring out the Spec2 GUI. :)
Any advice is welcome and appreciated.
Thanks! Russ
-- Russ Whaley whaley.russ@gmail.com <mailto:whaley.russ@gmail.com>
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
-- Russ Whaley whaley.russ@gmail.com <mailto:whaley.russ@gmail.com>
-------------------------------------------- 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
participants (5)
-
Esteban Maringolo -
Russ Whaley -
Sean P. DeNigris -
Stéphane Ducasse -
Sven Van Caekenberghe