Re: [Pharo-users] Black screen on Mac OSX

[Christophe Demarey]

Hi Hilaire,

I think the problem comes from the VM shipped.
If the VM is too old, it does not work well on recent distributions.
You could try to use the stable VM of Pharo 4 instead and it should work.

Christophe

> Le 26 mars 2018 à 14:19, H. Fernandes  a écrit :
> 
> Hi, 
> 
> I just noted DrGeo 17.07 (pharo 3 based) starts with a black screen on Mac OS 
> X 10.12.6. 
> 
> Can anyone with such configuration confirm it?
> 
> Thanks
> 
> Hilaire
> 
> 
> Dr. Geo -- http://drgeo.eu
> 

[Pharo-users] [ANN] Slides for a Lecture: MetaLinks

[Marcus Denker]

Hi,

I did last week a short lecture at VUB Brussels. Topic: MetaLinks.

Slideshare: https://www.slideshare.net/MarcusDenker/lecture-metalinks
PDF: http://marcusdenker.de/talks/18LectureMetaLinks/MetaLinks.pdf 



Marcus

Re: [Pharo-users] [ANN] Slides for a Lecture: MetaLinks

[Alistair Grant]

Great introduction.  I'd seen MetaLinks mentioned in emails, but
basically ignored them as I didn't know what they were.

Thanks, Marcus!

Cheers,
Alistair


On 27 March 2018 at 10:17, Marcus Denker  wrote:
> Hi,
>
> I did last week a short lecture at VUB Brussels. Topic: MetaLinks.
>
> Slideshare: https://www.slideshare.net/MarcusDenker/lecture-metalinks
> PDF: http://marcusdenker.de/talks/18LectureMetaLinks/MetaLinks.pdf
>
>
> Marcus

[Pharo-users] Launcher User Templates

[Sean P. DeNigris]

How would I make my own images available via Launcher. Where can I read about
this or can you point me to a hook? Thanks!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Looking for small boards and tiny computers which can run Pharo

[Marcus Denker]

Hi,

There are other interesting tiny boards that should fit well with Pharo-IOT (we 
should 

of course:
https://www.raspberrypi.org/products/raspberry-pi-zero/ 


but then, there are many and it should be relatively easy to get 
running there:

beaglebone pocket:

https://beagleboard.org/pocket 

Nanpi Duo:

http://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=197
 


CHIP
https://getchip.com/pages/chippro

or industrial platforms like 
http://www.variscite.com/variscite-products 



> On 23 Mar 2018, at 20:18, Steven Costiou  wrote:
> 
> Hi,
> 
> thanks for the links :)
> 
> Yes i am still working on this topic, however i chose to focus on Raaspbery 
> Pi. It is quite handy to have an embedded linux to experiment things. I do 
> not have a public page on my projects at the moment, but there is the 
> Pharo-iot github project that gather work of the community on the subject 
> (https://github.com/pharo-iot). 
> Did you manage to launch Pharo on the Teensy boards?
> 
> Steven.
> 
> Le 2018-03-23 08:47, Jonathan van Alteren a écrit :
> 
>> Hi Steven,
>> 
>> I found your message and was wondering if you're still working on this.
>> I did some IoT stuff with the little Teensy 3.2 boards, which I find very
>> convenient to use. The new 3.6 board has more memory (1Mb flash and 256Kb
>> RAM).
>> 
>> See info and seller here:
>> - https://www.pjrc.com/teensy/techspecs.html 
>> 
>> - https://www.antratek.com/boards/arduino-compatible/teensy 
>> 
>> 
>> Can I follow your progress anywhere?
>> 
>> Kind regards,
>> Jonathan
>> 
>> 
>> 
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html 
>> 
>  

[Pharo-users] STON shouldn't care about shared references in JSON mode

[Peter Uhnák]

Hi,

I don't think this should throw an error when I am producing JSON.

```
d := {
'a' -> #().
'b' -> #().
} asDictionary.

STON toJsonString: d.
```

dtto this

```
a := {'hm'}.

d := {
'a' -> a.
'b' -> a.
} asDictionary.

STON toJsonString: d.
```

Maybe I should forgo using STON>>toJson* out of laziness (it is
preinstalled) and always go for NeoJSON?

Peter

[Pharo-users] RTLegendBuilder onDemand doesn't popup in html

[Andrei Stebakov]

Just wanted to report that when I add a legend to RTView, it works as
expected when I ispect the view.
When I export it to HTML, it shows the node, but neither mouse clicking nor
hovering bring up the popup.
Could you take a look?

Re: [Pharo-users] STON shouldn't care about shared references in JSON mode

[Sven Van Caekenberghe]

Hi Peter,

Both cases will pass using this expression:

String streamContents: [ :out | 
STON jsonWriter 
referencePolicy: #ignore; 
on: out; 
nextPut: d ].

The problem is what to do with cycles.

Sven

> On 27 Mar 2018, at 17:43, Peter Uhnák  wrote:
> 
> Hi,
> 
> I don't think this should throw an error when I am producing JSON.
> 
> ```
> d := { 
>   'a' -> #().
>   'b' -> #().
> } asDictionary.
> 
> STON toJsonString: d.
> ```
> 
> dtto this
> 
> ```
> a := {'hm'}.
> 
> d := { 
>   'a' -> a.
>   'b' -> a.
> } asDictionary.
> 
> STON toJsonString: d.
> ```
> 
> Maybe I should forgo using STON>>toJson* out of laziness (it is preinstalled) 
> and always go for NeoJSON?
> 
> Peter

Re: [Pharo-users] STON shouldn't care about shared references in JSON mode

[Herbert Vojčík]

Sven Van Caekenberghe wrote:

Hi Peter,

Both cases will pass using this expression:

String streamContents: [ :out |
STON jsonWriter
referencePolicy: #ignore;
on: out;
nextPut: d ].

The problem is what to do with cycles.


Be faithful to what JSON.stringify does in JS. See attachment. :-)

Herby


Sven


On 27 Mar 2018, at 17:43, Peter Uhnák  wrote:

Hi,

I don't think this should throw an error when I am producing JSON.

```
d := {
'a' ->  #().
'b' ->  #().
} asDictionary.

STON toJsonString: d.
```

dtto this

```
a := {'hm'}.

d := {
'a' ->  a.
'b' ->  a.
} asDictionary.

STON toJsonString: d.
```

Maybe I should forgo using STON>>toJson* out of laziness (it is preinstalled) 
and always go for NeoJSON?

Peter

[Pharo-users] fuel docs shows the same content twice

[Peter Uhnák]

Hi,

not sure where to report this, but in this page of fuel docs

https://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/GettingStarted?_s=gnS5amSI-7GcDf_k&_k=4e8w5tCS4RRm35p7&_n&18

all the chapters are twice there

Basic examples
...
FileStream
...
Compressing
...
Showing a progress bar
...
Basic examples
...
FileStream
...
Compressing
...
Showing a progress bar
...

Peter

Re: [Pharo-users] STON shouldn't care about shared references in JSON mode

[Peter Uhnák]

Hi Sven,

shouldn't it be set to #ignore by default for JSON then? Or is there a use
case where it makes sense to have something else for JSON?

Herbert: I am not talking about (infinitely) recursive references, but
referencing the same object, e.g.


Peter

On Tue, Mar 27, 2018 at 6:08 PM, Herbert Vojčík  wrote:

>
>
> Sven Van Caekenberghe wrote:
>
>> Hi Peter,
>>
>> Both cases will pass using this expression:
>>
>> String streamContents: [ :out |
>> STON jsonWriter
>> referencePolicy: #ignore;
>> on: out;
>> nextPut: d ].
>>
>> The problem is what to do with cycles.
>>
>
> Be faithful to what JSON.stringify does in JS. See attachment. :-)
>
> Herby
>
>
> Sven
>>
>> On 27 Mar 2018, at 17:43, Peter Uhnák  wrote:
>>>
>>> Hi,
>>>
>>> I don't think this should throw an error when I am producing JSON.
>>>
>>> ```
>>> d := {
>>> 'a' ->  #().
>>> 'b' ->  #().
>>> } asDictionary.
>>>
>>> STON toJsonString: d.
>>> ```
>>>
>>> dtto this
>>>
>>> ```
>>> a := {'hm'}.
>>>
>>> d := {
>>> 'a' ->  a.
>>> 'b' ->  a.
>>> } asDictionary.
>>>
>>> STON toJsonString: d.
>>> ```
>>>
>>> Maybe I should forgo using STON>>toJson* out of laziness (it is
>>> preinstalled) and always go for NeoJSON?
>>>
>>> Peter
>>>
>>
>>
>>

Re: [Pharo-users] fuel docs shows the same content twice

[Peter Uhnák]

In fact this is problem on every page: it shows the Getting Started on the
top, and then continues with the actual content of the page, e.g.
https://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Globals?_s=gnS5amSI-7GcDf_k&_k=4e8w5tCS4RRm35p7&_n&19

On Tue, Mar 27, 2018 at 6:29 PM, Peter Uhnák  wrote:

> Hi,
>
> not sure where to report this, but in this page of fuel docs
>
> https://rmod.inria.fr/web/software/Fuel/Version1.9/
> Documentation/GettingStarted?_s=gnS5amSI-7GcDf_k&_k=4e8w5tCS4RRm35p7&_n&18
>
> all the chapters are twice there
>
> Basic examples
> ...
> FileStream
> ...
> Compressing
> ...
> Showing a progress bar
> ...
> Basic examples
> ...
> FileStream
> ...
> Compressing
> ...
> Showing a progress bar
> ...
>
> Peter
>

Re: [Pharo-users] STON shouldn't care about shared references in JSON mode

[Herbert Vojčík]

Peter Uhnák wrote:

Hi Sven,

shouldn't it be set to #ignore by default for JSON then? Or is there a
use case where it makes sense to have something else for JSON?


To keep STON practices / assumptions while using JSON to hold the data 
where STON is not supported yet, maybe? IIRC STON is positioning itself 
as JSON superset; but maybe only syntactic superset, while semantically 
it can be a bit different (so STONize to more low-level, JSON, syntax 
via STON; JSONize faithfully to JSON semantics using NeoJSON; but maybe 
I am just making things up).



Herbert: I am not talking about (infinitely) recursive references, but


I know; Sven explicitly asked what to do with cycles in that case, though.


referencing the same object, e.g.


Peter

On Tue, Mar 27, 2018 at 6:08 PM, Herbert Vojčík mailto:he...@mailbox.sk>> wrote:



Sven Van Caekenberghe wrote:

Hi Peter,

Both cases will pass using this expression:

String streamContents: [ :out |
 STON jsonWriter
 referencePolicy: #ignore;
 on: out;
 nextPut: d ].

The problem is what to do with cycles.


Be faithful to what JSON.stringify does in JS. See attachment. :-)

Herby


Sven

On 27 Mar 2018, at 17:43, Peter Uhnákmailto:i.uh...@gmail.com>>  wrote:

Hi,

I don't think this should throw an error when I am producing
JSON.

```
d := {
'a' ->  #().
'b' ->  #().
} asDictionary.

STON toJsonString: d.
```

dtto this

```
a := {'hm'}.

d := {
'a' ->  a.
'b' ->  a.
} asDictionary.

STON toJsonString: d.
```

Maybe I should forgo using STON>>toJson* out of laziness (it
is preinstalled) and always go for NeoJSON?

Peter

Re: [Pharo-users] STON shouldn't care about shared references in JSON mode

[Peter Uhnák]

Ah sorry, I'm blind.

Yes, ideally it should throw up an error in case of recursive.
And I see that NeoJSON runs into infinite cycle, so I guess this should be
addressed there too.



On Tue, Mar 27, 2018 at 6:41 PM, Herbert Vojčík  wrote:

>
>
> Peter Uhnák wrote:
>
>> Hi Sven,
>>
>> shouldn't it be set to #ignore by default for JSON then? Or is there a
>> use case where it makes sense to have something else for JSON?
>>
>
> To keep STON practices / assumptions while using JSON to hold the data
> where STON is not supported yet, maybe? IIRC STON is positioning itself as
> JSON superset; but maybe only syntactic superset, while semantically it can
> be a bit different (so STONize to more low-level, JSON, syntax via STON;
> JSONize faithfully to JSON semantics using NeoJSON; but maybe I am just
> making things up).
>
> Herbert: I am not talking about (infinitely) recursive references, but
>>
>
> I know; Sven explicitly asked what to do with cycles in that case, though.
>
> referencing the same object, e.g.
>>
>>
>> Peter
>>
>> On Tue, Mar 27, 2018 at 6:08 PM, Herbert Vojčík > > wrote:
>>
>>
>>
>> Sven Van Caekenberghe wrote:
>>
>> Hi Peter,
>>
>> Both cases will pass using this expression:
>>
>> String streamContents: [ :out |
>>  STON jsonWriter
>>  referencePolicy: #ignore;
>>  on: out;
>>  nextPut: d ].
>>
>> The problem is what to do with cycles.
>>
>>
>> Be faithful to what JSON.stringify does in JS. See attachment. :-)
>>
>> Herby
>>
>>
>> Sven
>>
>> On 27 Mar 2018, at 17:43, Peter Uhnák> >  wrote:
>>
>> Hi,
>>
>> I don't think this should throw an error when I am producing
>> JSON.
>>
>> ```
>> d := {
>> 'a' ->  #().
>> 'b' ->  #().
>> } asDictionary.
>>
>> STON toJsonString: d.
>> ```
>>
>> dtto this
>>
>> ```
>> a := {'hm'}.
>>
>> d := {
>> 'a' ->  a.
>> 'b' ->  a.
>> } asDictionary.
>>
>> STON toJsonString: d.
>> ```
>>
>> Maybe I should forgo using STON>>toJson* out of laziness (it
>> is preinstalled) and always go for NeoJSON?
>>
>> Peter
>>
>>
>>
>>
>>
>

[Pharo-users] evaluate: with bindings

[Stephane Ducasse]

Hi Marcus

I would like to be able to do the following:

Compiler
bindings: {'aValue' -> 33};
evaluate: 'aValue + aValue'

and get 66

Is it possible?

Stef

Re: [Pharo-users] Black screen on Mac OSX

[Hilaire]

Yes, please try with this version, based on Pharo4 VM

https://www.dropbox.com/s/oe7hvdrmz7mstvx/DrGeo-Pharo4.0.app.zip?dl=0

Thanks

Hilaire

Le 26/03/2018 à 22:15, Stephane Ducasse a écrit :

Let me know if you want that I retry.


--
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] STON shouldn't care about shared references in JSON mode

[Sven Van Caekenberghe]

The JSON spec does (of course) not deal with cycles nor structure sharing, STON 
does (by design).

The class comment clearly states:

...
- referencePolicy <#normal|#ignore|#error> default is #normal
if #normal, track and count object references and use references to 
implement sharing and break cycles
if #error, track object references and signal STONWriterError when a 
shared reference is encountered
if #ignore, don't track object references which might loop forever on 
cycles

...

For JSON production (not a main goes of STON), it was set to #error, but like I 
showed, it you could prefer #ignore. You have to know what to feed it.

Cycle/shared structure checking is expensive, i.e. slow(er) and uses more 
memory.

I am not sure it is easy to make a difference between a cycle and a shared 
structure, I would have to think about that.

And yes, NeoJSON will go happily in cycles.

> On 27 Mar 2018, at 18:52, Peter Uhnák  wrote:
> 
> Ah sorry, I'm blind.
> 
> Yes, ideally it should throw up an error in case of recursive.
> And I see that NeoJSON runs into infinite cycle, so I guess this should be 
> addressed there too.
> 
> 
> 
> On Tue, Mar 27, 2018 at 6:41 PM, Herbert Vojčík  wrote:
> 
> 
> Peter Uhnák wrote:
> Hi Sven,
> 
> shouldn't it be set to #ignore by default for JSON then? Or is there a
> use case where it makes sense to have something else for JSON?
> 
> To keep STON practices / assumptions while using JSON to hold the data where 
> STON is not supported yet, maybe? IIRC STON is positioning itself as JSON 
> superset; but maybe only syntactic superset, while semantically it can be a 
> bit different (so STONize to more low-level, JSON, syntax via STON; JSONize 
> faithfully to JSON semantics using NeoJSON; but maybe I am just making things 
> up).
> 
> Herbert: I am not talking about (infinitely) recursive references, but
> 
> I know; Sven explicitly asked what to do with cycles in that case, though.
> 
> referencing the same object, e.g.
> 
> 
> Peter
> 
> On Tue, Mar 27, 2018 at 6:08 PM, Herbert Vojčík  > wrote:
> 
> 
> 
> Sven Van Caekenberghe wrote:
> 
> Hi Peter,
> 
> Both cases will pass using this expression:
> 
> String streamContents: [ :out |
>  STON jsonWriter
>  referencePolicy: #ignore;
>  on: out;
>  nextPut: d ].
> 
> The problem is what to do with cycles.
> 
> 
> Be faithful to what JSON.stringify does in JS. See attachment. :-)
> 
> Herby
> 
> 
> Sven
> 
> On 27 Mar 2018, at 17:43, Peter Uhnák >  wrote:
> 
> Hi,
> 
> I don't think this should throw an error when I am producing
> JSON.
> 
> ```
> d := {
> 'a' ->  #().
> 'b' ->  #().
> } asDictionary.
> 
> STON toJsonString: d.
> ```
> 
> dtto this
> 
> ```
> a := {'hm'}.
> 
> d := {
> 'a' ->  a.
> 'b' ->  a.
> } asDictionary.
> 
> STON toJsonString: d.
> ```
> 
> Maybe I should forgo using STON>>toJson* out of laziness (it
> is preinstalled) and always go for NeoJSON?
> 
> Peter
> 
> 
> 
> 
> 
> 

Re: [Pharo-users] Black screen on Mac OSX

[Hilaire]

Thanks for the tip


Le 27/03/2018 à 08:59, Christophe Demarey a écrit :

If the VM is too old, it does not work well on recent distributions.
You could try to use the stable VM of Pharo 4 instead and it should work.


--
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] PharoLauncher image loading error

[Hilaire]

Le 26/03/2018 à 22:17, Stephane Ducasse a écrit :

And you are on MacOSX?

No, I am not. Just some testing on school computers.

Can you describe what you did? Because with the Launcher you can also
I open the "Official distributions" subtree, select Pharo6.1 then click 
on the icon with the play symbol, on the top of the window.

open old images and ask it to sort them.
You just double click on the left pane on the Pharo6.1(stable) item
(as attached?)


--
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] fuel docs shows the same content twice

[Peter Uhnák]

Finally it would be great if all code such as this

'demo.fuel' asFileReference writeStreamDo: [ ... ]

be written as this

'demo.fuel' asFileReference ensureDelete; writeStreamDo:  [ ... ]

Otherwise it is way too easy to forget and creates a major problem,
especially for binary files.

Thanks!

Peter

On Tue, Mar 27, 2018 at 6:39 PM, Peter Uhnák  wrote:

> In fact this is problem on every page: it shows the Getting Started on the
> top, and then continues with the actual content of the page, e.g.
> https://rmod.inria.fr/web/software/Fuel/Version1.9/
> Documentation/Globals?_s=gnS5amSI-7GcDf_k&_k=4e8w5tCS4RRm35p7&_n&19
>
> On Tue, Mar 27, 2018 at 6:29 PM, Peter Uhnák  wrote:
>
>> Hi,
>>
>> not sure where to report this, but in this page of fuel docs
>>
>> https://rmod.inria.fr/web/software/Fuel/Version1.9/Documenta
>> tion/GettingStarted?_s=gnS5amSI-7GcDf_k&_k=4e8w5tCS4RRm35p7&_n&18
>>
>> all the chapters are twice there
>>
>> Basic examples
>> ...
>> FileStream
>> ...
>> Compressing
>> ...
>> Showing a progress bar
>> ...
>> Basic examples
>> ...
>> FileStream
>> ...
>> Compressing
>> ...
>> Showing a progress bar
>> ...
>>
>> Peter
>>
>
>

Re: [Pharo-users] STON shouldn't care about shared references in JSON mode

[Herbert Vojčík]

Sven Van Caekenberghe wrote:

The JSON spec does (of course) not deal with cycles nor structure sharing, STON 
does (by design).


That surprises me. I thought cycles are explicitly prohibited in JSON.


The class comment clearly states:

...
- referencePolicy<#normal|#ignore|#error>  default is #normal
if #normal, track and count object references and use references to 
implement sharing and break cycles
if #error, track object references and signal STONWriterError when a 
shared reference is encountered
if #ignore, don't track object references which might loop forever on 
cycles

...

For JSON production (not a main goes of STON), it was set to #error, but like I 
showed, it you could prefer #ignore. You have to know what to feed it.

Cycle/shared structure checking is expensive, i.e. slow(er) and uses more 
memory.


Maybe not. You do not need to _count_ references actually, just 
mark/unmark on enter/leave (that is, no (Identity)Dictionary is needed, 
just an (Identity)Set). Assuming you do depth-first.



I am not sure it is easy to make a difference between a cycle and a shared 
structure, I would have to think about that.

And yes, NeoJSON will go happily in cycles.


See above.


On 27 Mar 2018, at 18:52, Peter Uhnák  wrote:

Ah sorry, I'm blind.

Yes, ideally it should throw up an error in case of recursive.
And I see that NeoJSON runs into infinite cycle, so I guess this should be 
addressed there too.



On Tue, Mar 27, 2018 at 6:41 PM, Herbert Vojčík  wrote:


Peter Uhnák wrote:
Hi Sven,

shouldn't it be set to #ignore by default for JSON then? Or is there a
use case where it makes sense to have something else for JSON?

To keep STON practices / assumptions while using JSON to hold the data where 
STON is not supported yet, maybe? IIRC STON is positioning itself as JSON 
superset; but maybe only syntactic superset, while semantically it can be a bit 
different (so STONize to more low-level, JSON, syntax via STON; JSONize 
faithfully to JSON semantics using NeoJSON; but maybe I am just making things 
up).

Herbert: I am not talking about (infinitely) recursive references, but

I know; Sven explicitly asked what to do with cycles in that case, though.

referencing the same object, e.g.


Peter

On Tue, Mar 27, 2018 at 6:08 PM, Herbert Vojčíkmailto:he...@mailbox.sk>>  wrote:



 Sven Van Caekenberghe wrote:

 Hi Peter,

 Both cases will pass using this expression:

 String streamContents: [ :out |
  STON jsonWriter
  referencePolicy: #ignore;
  on: out;
  nextPut: d ].

 The problem is what to do with cycles.


 Be faithful to what JSON.stringify does in JS. See attachment. :-)

 Herby


 Sven

 On 27 Mar 2018, at 17:43, Peter Uhnákmailto:i.uh...@gmail.com>>   wrote:

 Hi,

 I don't think this should throw an error when I am producing
 JSON.

 ```
 d := {
 'a' ->   #().
 'b' ->   #().
 } asDictionary.

 STON toJsonString: d.
 ```

 dtto this

 ```
 a := {'hm'}.

 d := {
 'a' ->   a.
 'b' ->   a.
 } asDictionary.

 STON toJsonString: d.
 ```

 Maybe I should forgo using STON>>toJson* out of laziness (it
 is preinstalled) and always go for NeoJSON?

 Peter

Re: [Pharo-users] evaluate: with bindings

[Sean P. DeNigris]

Stephane Ducasse-3 wrote
> I would like to be able to do the following:

Smalltalk compiler 
bindings: {#aValue -> 33} asDictionary; 
evaluate: 'aValue + aValue' 



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] STON shouldn't care about shared references in JSON mode

[Peter Uhnák]

>
> The class comment clearly states:
>

The docs also say "When using JSON mode the reference policy should be set
to #error or #ignore for full JSON compatibility." But demonstrably setting
it to #error does not give me full JSON compatibility.


If I feed it valid input, then I expect valid output. Now it throws up.
This is a bug.

If I feed it infinite input, then I cannot be surprised it will start
producing infinite output. Having a cycle detection is a nice feature, but
I cannot sacrifice functionality for it.

In the end this is your call, maybe it makes sense for STON's json to be
closer to STON's behavior, even if it sometimes breaks down. And I can
always switch to NeoJSON if I want to be sure.

Peter



> ...
> - referencePolicy <#normal|#ignore|#error> default is #normal
> if #normal, track and count object references and use references
> to implement sharing and break cycles
> if #error, track object references and signal STONWriterError when
> a shared reference is encountered
> if #ignore, don't track object references which might loop forever
> on cycles
>
> ...
>
> For JSON production (not a main goes of STON), it was set to #error, but
> like I showed, it you could prefer #ignore. You have to know what to feed
> it.
>
> Cycle/shared structure checking is expensive, i.e. slow(er) and uses more
> memory.
>
> I am not sure it is easy to make a difference between a cycle and a shared
> structure, I would have to think about that.
>
> And yes, NeoJSON will go happily in cycles.
>
> > On 27 Mar 2018, at 18:52, Peter Uhnák  wrote:
> >
> > Ah sorry, I'm blind.
> >
> > Yes, ideally it should throw up an error in case of recursive.
> > And I see that NeoJSON runs into infinite cycle, so I guess this should
> be addressed there too.
> >
> >
> >
> > On Tue, Mar 27, 2018 at 6:41 PM, Herbert Vojčík 
> wrote:
> >
> >
> > Peter Uhnák wrote:
> > Hi Sven,
> >
> > shouldn't it be set to #ignore by default for JSON then? Or is there a
> > use case where it makes sense to have something else for JSON?
> >
> > To keep STON practices / assumptions while using JSON to hold the data
> where STON is not supported yet, maybe? IIRC STON is positioning itself as
> JSON superset; but maybe only syntactic superset, while semantically it can
> be a bit different (so STONize to more low-level, JSON, syntax via STON;
> JSONize faithfully to JSON semantics using NeoJSON; but maybe I am just
> making things up).
> >
> > Herbert: I am not talking about (infinitely) recursive references, but
> >
> > I know; Sven explicitly asked what to do with cycles in that case,
> though.
> >
> > referencing the same object, e.g.
> >
> >
> > Peter
> >
> > On Tue, Mar 27, 2018 at 6:08 PM, Herbert Vojčík  > > wrote:
> >
> >
> >
> > Sven Van Caekenberghe wrote:
> >
> > Hi Peter,
> >
> > Both cases will pass using this expression:
> >
> > String streamContents: [ :out |
> >  STON jsonWriter
> >  referencePolicy: #ignore;
> >  on: out;
> >  nextPut: d ].
> >
> > The problem is what to do with cycles.
> >
> >
> > Be faithful to what JSON.stringify does in JS. See attachment. :-)
> >
> > Herby
> >
> >
> > Sven
> >
> > On 27 Mar 2018, at 17:43, Peter Uhnák > >  wrote:
> >
> > Hi,
> >
> > I don't think this should throw an error when I am producing
> > JSON.
> >
> > ```
> > d := {
> > 'a' ->  #().
> > 'b' ->  #().
> > } asDictionary.
> >
> > STON toJsonString: d.
> > ```
> >
> > dtto this
> >
> > ```
> > a := {'hm'}.
> >
> > d := {
> > 'a' ->  a.
> > 'b' ->  a.
> > } asDictionary.
> >
> > STON toJsonString: d.
> > ```
> >
> > Maybe I should forgo using STON>>toJson* out of laziness (it
> > is preinstalled) and always go for NeoJSON?
> >
> > Peter
> >
> >
> >
> >
> >
> >
>
>
>

[Pharo-users] "News" section of the website down

[Mathieu Dubois via Pharo-users]

--- Begin Message ---

Hello,

I don't know how to report that but for several weeks (maybe months), I 
can't reach the "News" section of the website (I have tried from several 
locations with different ISP). I usually get a timeout error (error 524 
from Cloudflare) that comes from pharo.org.


Mathieu


--- End Message ---

Re: [Pharo-users] "News" section of the website down

[Stephane Ducasse]

Tx mathieu for the report!!!

On Tue, Mar 27, 2018 at 7:56 PM, Mathieu Dubois via Pharo-users
 wrote:
>
>
> -- Forwarded message --
> From: Mathieu Dubois 
> To: pharo-users@lists.pharo.org
> Cc:
> Bcc:
> Date: Tue, 27 Mar 2018 19:56:41 +0200
> Subject: "News" section of the website down
> Hello,
>
> I don't know how to report that but for several weeks (maybe months), I can't 
> reach the "News" section of the website (I have tried from several locations 
> with different ISP). I usually get a timeout error (error 524 from 
> Cloudflare) that comes from pharo.org.
>
> Mathieu
>
>
>

[Pharo-users] Detecting "window closed" for modal Spec window

[Peter Uhnák]

Hi,

is it possible to detect when a modal window was closed in Spec?

I can do the following

window := TextModel new openWithSpec.
window window announcer when: WindowClosed do: [ self inform: 'window
closed' ].

But when I make the window modal it is no longer being announced

window := TextModel new openWithSpec.
window modalRelativeTo: self currentWorld.
window window announcer when: WindowClosed do: [ self inform: 'window
closed' ].

Is there some other way how I can achieve this?


Thanks,
Peter

Re: [Pharo-users] RTLegendBuilder onDemand doesn't popup in html

[Alexandre Bergel]

Hi Andrei,

onDemand for the legend is not supported when exporting to HTML.

Cheers,
Alexandre


> On Mar 27, 2018, at 12:48 PM, Andrei Stebakov  wrote:
> 
> Just wanted to report that when I add a legend to RTView, it works as 
> expected when I ispect the view.
> When I export it to HTML, it shows the node, but neither mouse clicking nor 
> hovering bring up the popup.
> Could you take a look?

Re: [Pharo-users] RTDoubleScrollBar is not rendered properly in html

[Alexandre Bergel]

> Alexandre, is there a way to display RTTreeLayout so that it would try to fit 
> elements in a more vertical fashion.
> Let's say even if the parent node has 8 children it would try to arrange them 
> not in one long horizontal line (which depending on the width of elements can 
> be really wide), 
> but spread them more vertically, so they would be viewable on one page.
> Or maybe I need to try another layout to reach that goal?

There is the horizontal tree layout that you may want to try.

-=-=-=-=-=-=-=-=
b := RTMondrian new.
b shape circle.
b nodes: Collection withAllSubclasses.
b edges connectFrom: #superclass.
b normalizer normalizeSize: #numberOfMethods; normalizeColor: 
#numberOfLinesOfCode.
b layout horizontalTree.
b
-=-=-=-=-=-=-=-=



Does it help?

Cheers,
Alexandre

> On Fri, Mar 23, 2018 at 8:15 PM, Alexandre Bergel  
> wrote:
> > Thanks, Alexandre, it works!
> > Also since I use RTView and RTEdgeBuilder I can use
> > view @ RTDraggableView to achieve the “draggability"
> 
> Yes! Glad to hear the problem is solved!
> 
> Alexandre
> 
> >
> > On Mar 22, 2018 14:01, "Alexandre Bergel"  wrote:
> > I see.
> > Do you know you can drag and drop the background to scroll?
> >
> > You can also make the view zoomable, using the mouse wheel.
> >
> > Try this:
> > -=-=-=-=-=-=-=-=-=
> > b := RTMondrian new.
> > b nodes: (RTObject withAllSubclasses).
> > b edges connectFrom: #superclass.
> > b layout radial.
> > b build.
> >
> > b view @ RTZoomableView.
> > RTHTML5Exporter new
> >   directoryPathname: '/tmp';
> >   export: b view.
> >
> > b view
> > -=-=-=-=-=-=-=-=-=
> >
> > Alexandre
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >> On Mar 22, 2018, at 1:40 PM, Andrei Stebakov  wrote:
> >>
> >> Hi Alexandre
> >>
> >> I don't see how I can do without the scroll bars in HTML since the node 
> >> tree that I tender using RTTreeLayout has a big width and only 1/4 of it 
> >> fits in one page view.
> >> Since I am building a web service I rely on rendering and serving the view 
> >> in HTML and without the scroll bars there is no way for me to view all 
> >> elements of the model in Chrome.
> >>
> >> On Mar 22, 2018 11:50, "Alexandre Bergel"  wrote:
> >> Hi!
> >>
> >> Scroll bar are not exportable to HTML, as benefits in doing so are not 
> >> really apparent.
> >> What would be the ideal behavior? Will removing scrollbars when exporting 
> >> to HTML sufficient for your need?
> >>
> >> Cheers,
> >> Alexandre
> >> --
> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> >> Alexandre Bergel  http://www.bergel.eu
> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >>
> >>
> >>
> >>> On Mar 22, 2018, at 11:20 AM, Andrei Stebakov  wrote:
> >>>
> >>> When I do
> >>> v @ RTDoubleScrollBar.
> >>> and then export to HTML
> >>> the bars are rendered in the middle of HTML page and they don't actually 
> >>> scroll.
> >>> I checked in in Chrome and IE on windows. Could you guys take a look?
> >>
> >
> 
> 
>