[Pharo-users] Re: (Re)storing code blocks from text strings (hopefully in STON)

[Offray Vladimir Luna Cárdenas]

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 > > 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 >> > 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
 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/
 
 [2] 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://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
>

[Pharo-users] Re: [Pharo Mooc] Change colors of test results

[Stéphane Ducasse]

sergio 

please let us know how e can proceed because we could do a theme for colorblind 
people. 

S

> On 19 Nov 2020, at 02:12, sergio ruiz  wrote:
> 
> Hey, all.. 
> 
> I am taking the Pharo Mooc, and was wondering:
> 
> is there any way to change the color next to the test method name?
> 
> I am colorblind, and I can’t tell the different between green and yellow.
> 
> Thanks!
> 
> 
> 
> peace,
> sergio
> photographer, journalist, visionary
> 
> Public Key: 
> https://pgp.key-server.io/pks/lookup?op=get&search=0x69B08F58923AB3A2 
> 
> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
> @sergio_101@mastodon.social 
> https://sergio101.com 
> http://www.codeandmusic.com
> http://www.twitter.com/sergio_101
> http://www.facebook.com/sergio101
> 


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

[Pharo-users] Re: (Re)storing code blocks from text strings (hopefully in STON)

[Sven Van Caekenberghe]

Thx!

> On 4 Dec 2020, at 21:24, Stéphane Ducasse  wrote:
> 
> Done :)
> 
> 
>> On 4 Dec 2020, at 21:20, Stéphane Ducasse  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  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 
  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/
 [2] 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://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
> 

[Pharo-users] Re: [Video] Transforming code using RewriteToolsSet

[Stéphane Ducasse]

I want it as part of new tools :)

S

> On 2 Dec 2020, at 16:14, Sebastian Jordan  wrote:
> 
> Hi,
> If you are interested in applying custom code transformations on a selected 
> set of classes, maybe this tool will be of your interest. I made these 
> mini-tutorial-videos in which I transform the code of a set of classes 
> through a transformation rule using this brand new tool RewriteToolsSet.
> 
> Thanks!
> 
> [GitHub's repo: https://github.com/jordanmontt/RewriteToolsSet 
> ]
> 
> - https://www.youtube.com/watch?v=M0ElVhUoWXk 
> 
> - https://www.youtube.com/watch?v=_9v1XTk1J2A 
> 
>  
> Transforming code using RewriteToolsSet 
> 
> In this video we are going to see another common use case of this set of 
> tools. We are going to reactor the code of all classes of a package using a 
> transformation rule. If you have any question or experience any bug, please 
> do not hesitate open an issue on the GitHub page or contact me. Thank you for 
> you time! GitHub's repository: https ...
> www.youtube.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

[Pharo-users] Re: (Re)storing code blocks from text strings (hopefully in STON)

[Stéphane Ducasse]

Done :)


> On 4 Dec 2020, at 21:20, Stéphane Ducasse  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 > > 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 
>>> 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/ 
>>> 
>>> [2] 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://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

[Pharo-users] Re: (Re)storing code blocks from text strings (hopefully in STON)

[Stéphane Ducasse]

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  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 
>>  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/
>> [2] 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://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

[Pharo-users] Re: Magritte

[Stéphane Ducasse]

Hi Sean

May be we should update the Magrrite booklet. I never got the time to go over 
it. 

S. 

> On 23 Nov 2020, at 15:56, Sean P. DeNigris  wrote:
> 
> Sanjay Minni wrote
>> Is Magritte a robust enough package for an application with a large number
>> of forms and sub forms. 
> 
> I use Magritte extensively (for almost all my projects), and have found it
> irreplaceable, but nearly all in desktop apps. Maybe cross-post to the
> Seaside list if you don't get an answer here...
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html


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

[Pharo-users] Re: [Important] The deprecated FileStream removed from Pharo 9

[Stéphane Ducasse]

Today I migrated FFICHeaderExtractor
And tomorrow I wll make sure OSSubprocess will work.

S

> On 1 Dec 2020, at 09:20, Pavel Krivanek  wrote:
> 
> Hi,
> 
> the Pharo 9 finally removed the DeprecatedFileStream package. Please, check 
> whether your projects stopped to use this deprecated file streams API.
> 
> The migration guide is in the FileStream class comment.
> 
> or here: 
> https://pharoweekly.wordpress.com/2018/03/19/new-files-in-pharo-migration-guide-how-tos-and-examples/
>  
> 
> 
> or here: 
> https://github.com/pavel-krivanek/pharoMaterials/blob/master/Filestreams.MD 
> 
> 
> Cheers,
> -- Pavel


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

[Pharo-users] Re: Amber Smalltalk

[g_patrickb--- via Pharo-users]

There was a reply from an Amber Smalltalk developer on Rocket chat and I 
uninstalled npm and cleaned up the previous grunt and amber installs, then 
removed node_modules and ran the command he gave me which was successful.  The 
command to install is:  `npm install -g grunt-cli grunt-init @ambers/cli@latest`

[Pharo-users] Re: Amber Smalltalk

[g_patrickb--- via Pharo-users]

Sending an email really messes up formatting.

I realize Amber isn't a Pharo related question, but there doesn't appear to be 
much activity in their Rocket chat or on google groups.  

The instructions on the site say to install doing:

npm install -g grunt-cli grunt-init @ambers/cli

And when you run:

amber init

It fails:

fatal: repository 'https://lolg.it/amber/amber-contrib-jquery.git/' not found

It appears they moved it to contrib-jquery from amber-contrib-jquery.  Does 
anyone know where this would be changed to get "amber init" to work?

---

[Pharo-users] Amber Smalltalk

[G B via Pharo-users]

I realize Amber isn't a Pharo related question, but there doesn't appear to be 
much activity in their Rocket chat or on google groups.  
The instructions on the site say to install doing:npm install -g grunt-cli 
grunt-init @ambers/cli
And when you run:amber init
It fails:fatal: repository 'https://lolg.it/amber/amber-contrib-jquery.git/' 
not found
It appears they moved it to contrib-jquery from amber-contrib-jquery.  Does 
anyone know where this would be changed to get "amber init" to work?