March 2018 - Pharo-users - lists.pharo.org

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

by Stephane Ducasse

Tx mathieu for the report!!! On Tue, Mar 27, 2018 at 7:56 PM, Mathieu Dubois via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Mathieu Dubois <duboismathieu_gaas(a)yahoo.fr> > To: pharo-users(a)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 > > >

March 27, 2018

"News" section of the website down

by Mathieu Dubois

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

March 27, 2018

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

by 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 <i.uhnak(a)gmail.com> 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 <herby(a)mailbox.sk> > 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 <herby(a)mailbox.sk > > <mailto:herby@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Ã¡k<i.uhnak(a)gmail.com > > <mailto:i.uhnak@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 > > > > > > > > > > > > > > >

March 27, 2018

Re: [Pharo-users] evaluate: with bindings

by 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

March 27, 2018

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

by 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<i.uhnak(a)gmail.com> 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<herby(a)mailbox.sk> 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<herby(a)mailbox.sk >> <mailto:herby@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Ã¡k<i.uhnak(a)gmail.com >> <mailto:i.uhnak@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 >> >> >> >> >> >> > >

March 27, 2018

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

by 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 <i.uhnak(a)gmail.com> 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 <i.uhnak(a)gmail.com> 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 >> > >

March 27, 2018

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

by 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 <i.uhnak(a)gmail.com> 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 <herby(a)mailbox.sk> 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 <herby(a)mailbox.sk > <mailto:herby@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Ã¡k<i.uhnak(a)gmail.com > <mailto:i.uhnak@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 > > > > > >

March 27, 2018

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

by 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

March 27, 2018

Re: [Pharo-users] PharoLauncher image loading error

by 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

March 27, 2018

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

by 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

March 27, 2018