- Pharo-users - lists.pharo.org

The results are in!

by Richard Kenneth Eng

Round 1 â #1 Leading Team: https://youtu.be/QWHeN5WXfBQ I'm actually quite amazed by their effort. They surpassed my expectations. At the risk of sounding immodest, I think this is a terrific way to promote Smalltalk (Pharo). I think the video is an absolute blast. Richard

Feb. 8, 2020

Re: [Pharo-users] About "it's not pharo but smalltalk"

by TedVanGaalen

Hi Ben Maybe you misunderstood what I meant. I was thinking of Pharo-backward-compatibility. not Smalltalk-backward-compatibility I am only suggesting that Pharo should be downward compatible (that is, within Pharo's scope only). meaning that everything built wit Pharo version X should load and run in Pharo pharo version X + n without any changes. This means that a package/app running OK in Pharo 8, should work without any changes whatsoever in, say, Pharo 12, ca 2 years later. and even beyond that, preferably many Pharo releases later! Therefore, any extension/improvement of Pharo itself should be done on top of that, not by replacing/deprecating existing classes. As not to break downward compatibility. (looking at the basic underlying system classes, it looks like this has already been done that way in most cases, simply because Smalltalk is a hierarchical rooted object system, which means that changing the deeper is very hard because it (could) tears up the very fabric of Smalltalk/Pharo itself, right?) If one reads through this Pharo user forum, and also many other Smalltalk forums, you can read about many cases of packages that no longer will work after yet another version of Pharo is released. This is unacceptable: new Pharo releases should not break those packages. read again: > Downward compatibility prevents people > from have tediously edit and test their packages > again and again each time some have > the "brilliant" idea to deprecate stuff. Let's assume for a moment that I want (currently i don't) to create a package/application, taking many months of my precious time. After a long time, my hard work is finally completed and tested: wow, the big dragon flies! However, yet another year later, it no longer loads and I have to spend a considerable amount of time re-editing and testing my package to get it working correctly again, let alone thereby considering the delicate interaction with other third party packages that -guess what?- are dealing with similar release breaking problems at the same time. Unnecessary work, repeating itself with almost every new version of Pharo. Realizing that this is an almost eternal trap, this suffices to deter me from even starting to create such a package! Thus trying to avoid a very tedious and iterating process of repairing things that once were perfectly OK. Somehow many don't seem get this: Too academic? making some sort of hobby out of their work. without realizing real-world situations in a though production/industrial environment. In combination with the lack of standardization of Smalltalk, this is probably one the reasons the installed base of Smalltalk (and Pharo based apps) is very small. If one doesn't understand this, one should ask themselves why the heck they are software developers in the first place. On IBM mainframes I can still load and recompile unchanged COBOL source files from ca. 1974 and they'll run flawlessly: more than 40 years later. (btw your bank account runs on mainframes, probably in COBOL btw.) Of course it is a splendid idea to improve Pharo, seeing how Pharo is now, great to work with. However, this should be done in such a way that downward compatibility is guaranteed. IMHO, Regards TedvG. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 8, 2020

Re: [Pharo-users] About "it's not pharo but smalltalk"

by horrido

I agree completely. Pharo is a Smalltalk, but it need not be constrained by Smalltalk-80. Pharo is completely free to chart its own course. As far as I can tell, Nik Boyd's Hoot Smalltalk is doing the same thing. This is purely a PR matter. Pharo's reputation doesn't want to be tarred with Smalltalk's feathers. So the philosophy is, sever all ties with Smalltalk's legacy. Well, that's one approach. Here's another: change the public's perception of Smalltalk. Take the bull by the horns. That's the total premise of my five-year PR campaign. Smalltalk's legacy is not an albatross. It can be a source of great power for publicity. I intend to prove that. Ben Coman wrote > I am of the side of this argument that Pharo is a kind of Smalltalk, > but the group that forked Squeak to create Pharo did so with the > express intention of being separate-from-Smalltalk > and we should respect that intention. Indeed here we can see three > reasons why they feel the need to advertise that separation... > > On Fri, 7 Feb 2020 at 21:45, TedVanGaalen < > tedvga@ > > wrote: >> >> make improvement/changes only in such >> a way that anything written before will >> run without any modification > > You are constraining what Pharo can be. > > >> Downward compatibility prevents people >> from have tediously edit and test their packages >> again and again each time some have >> the "brilliant" idea to deprecate stuff. > > You are constraining what Pharo can be. > > >> If you want to implement newer core like things >> co-existence with previous is preferable. >> Do at the very least not alter the core/system classes. > > You are constraining what Pharo can be. > > > The aim of the advertised statement that Pharo-is-not-Smalltalk is to > avoid you "later" being surprised if it differs from ST-80. > A marketing strategy analogous to a "fail early" programming paradigm, > and avoid such arguments that try to shackle Pharo. > > In practice, its probably many years before Pharo is any more > incompatible with Smalltalk than the incompatibilities between > existing Smalltalks. > But Smalltalk-backward-compatibility should not be one of your > tick-boxes to choose Pharo. > > cheers -ben -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 8, 2020

Re: [Pharo-users] About "it's not pharo but smalltalk"

by Benoit St-Jean

Smalltalk didn't "fail". We just didn't have the CPU power at the time to achieve our dreams! And "Smalltalk is slow" was tagged forever besides the name... 2020-02-08 07:17, Ben Coman wrote:The aim of the advertised statement that Pharo-is-not-Smalltalk is to > avoid you "later" being surprised if it differs from ST-80. > A marketing strategy analogous to a "fail early" programming paradigm, > and avoid such arguments that try to shackle Pharo. > > In practice, its probably many years before Pharo is any more > incompatible with Smalltalk than the incompatibilities between > existing Smalltalks. > But Smalltalk-backward-compatibility should not be one of your > tick-boxes to choose Pharo. > > cheers -ben > -- ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth GitHub: bstjean Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)

Feb. 8, 2020

Re: [Pharo-users] About "it's not pharo but smalltalk"

by Ben Coman

I am of the side of this argument that Pharo is a kind of Smalltalk, but the group that forked Squeak to create Pharo did so with the express intention of being separate-from-Smalltalk and we should respect that intention. Indeed here we can see three reasons why they feel the need to advertise that separation... On Fri, 7 Feb 2020 at 21:45, TedVanGaalen <tedvga(a)gmail.com> wrote: > > make improvement/changes only in such > a way that anything written before will > run without any modification You are constraining what Pharo can be. > Downward compatibility prevents people > from have tediously edit and test their packages > again and again each time some have > the "brilliant" idea to deprecate stuff. You are constraining what Pharo can be. > If you want to implement newer core like things > co-existence with previous is preferable. > Do at the very least not alter the core/system classes. You are constraining what Pharo can be. The aim of the advertised statement that Pharo-is-not-Smalltalk is to avoid you "later" being surprised if it differs from ST-80. A marketing strategy analogous to a "fail early" programming paradigm, and avoid such arguments that try to shackle Pharo. In practice, its probably many years before Pharo is any more incompatible with Smalltalk than the incompatibilities between existing Smalltalks. But Smalltalk-backward-compatibility should not be one of your tick-boxes to choose Pharo. cheers -ben

Feb. 8, 2020

Re: [Pharo-users] NeoJSONParseError: invalid input: ' while parsing a Wikipedia exported article.

by Sven Van Caekenberghe

Hi, Like Erik says the input is indeed illegal JSON. JSON strings are delimited using double quotes not single quotes. There is no way around this, this is not optional. As Peter says, STON is more flexible. STON itself uses single quotes to be closer to Smalltalk. STON in its JSON compatibility mode does also recognise double quotes. So the class STONReader supports both, without further configuration. Sven > On 8 Feb 2020, at 10:34, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Offray > > I have a workaround, not an explanation. I don't use NeoJSON, because for me the JSON facilities of STON are sufficient. So I tried you script with 'NeoJSONReader fromString:' replaced by 'STON fromString:' - everything worked perfectly, no parsing error. So clearly there is nothing wrong with your input file. If you have STON installed, or think it worth installing, this could get you moving. > > HTH > > Peter Kenny > > -----Original Message----- > From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Offray Vladimir Luna CÃ¡rdenas > Sent: 08 February 2020 07:38 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: [Pharo-users] NeoJSONParseError: invalid input: ' while parsing a Wikipedia exported article. > > Hi, > > I'm trying to read the contents of a Wikipedia article that was exported from there using Wikipedias JSON API. > > The script I'm trying is: > > NeoJSONReader fromString: > 'https://mutabit.com/repos.fossil/pharopedia/doc/tip/docs/wikipedia.org/wiki…' > asUrl retrieveContents utf8Decoded > > But I get "NeoJSONParseError: invalid input: '". As far as I can tell, the file at [1] seems like valid JSON, as is the one that Wikipedia API exports > > [1] > 'https://mutabit.com/repos.fossil/pharopedia/doc/tip/docs/wikipedia.org/wiki…' > > Could anybody point me to a solution? > > Thanks, > > Offray > > >

Feb. 8, 2020

Re: [Pharo-users] NeoJSONParseError: invalid input: ' while parsing a Wikipedia exported article.

by PBKResearch

Offray I have a workaround, not an explanation. I don't use NeoJSON, because for me the JSON facilities of STON are sufficient. So I tried you script with 'NeoJSONReader fromString:' replaced by 'STON fromString:' - everything worked perfectly, no parsing error. So clearly there is nothing wrong with your input file. If you have STON installed, or think it worth installing, this could get you moving. HTH Peter Kenny -----Original Message----- From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Offray Vladimir Luna CÃ¡rdenas Sent: 08 February 2020 07:38 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: [Pharo-users] NeoJSONParseError: invalid input: ' while parsing a Wikipedia exported article. Hi, I'm trying to read the contents of a Wikipedia article that was exported from there using Wikipedias JSON API. The script I'm trying is: NeoJSONReader fromString: 'https://mutabit.com/repos.fossil/pharopedia/doc/tip/docs/wikipedia.org/wiki…' asUrl retrieveContents utf8Decoded But I get "NeoJSONParseError: invalid input: '". As far as I can tell, the file at [1] seems like valid JSON, as is the one that Wikipedia API exports [1] 'https://mutabit.com/repos.fossil/pharopedia/doc/tip/docs/wikipedia.org/wiki…' Could anybody point me to a solution? Thanks, Offray

Feb. 8, 2020

Re: [Pharo-users] NeoJSONParseError: invalid input: ' while parsing a Wikipedia exported article.

by Erik Stel

Offray, JSON only allows double quotes for strings, not single quotes. Cheers, Erik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 8, 2020

NeoJSONParseError: invalid input: ' while parsing a Wikipedia exported article.

by Offray Vladimir Luna CÃ¡rdenas

Hi, I'm trying to read the contents of a Wikipedia article that was exported from there using Wikipedias JSON API. The script I'm trying is: NeoJSONReader fromString:Â 'https://mutabit.com/repos.fossil/pharopedia/doc/tip/docs/wikipedia.org/wiki…' asUrl retrieveContents utf8Decoded But I get "NeoJSONParseError: invalid input: '". As far as I can tell, the file at [1] seems like valid JSON, as is the one that Wikipedia API exports [1] 'https://mutabit.com/repos.fossil/pharopedia/doc/tip/docs/wikipedia.org/wiki…' Could anybody point me to a solution? Thanks, Offray

Feb. 8, 2020

Re: [Pharo-users] [FOSDEM] Grafoscopio

by phil＠highoctane.be

Same for me! Phil On Fri, 7 Feb 2020, 17:41 Offray Vladimir Luna CÃ¡rdenas, < offray.luna(a)mutabit.com> wrote: > Thanks a lot Santiago! You did a pretty good job representing the > community and is nice to have you also in the community channels. > > I will shared on my networks. > > Offray > > On 7/02/20 2:50 a. m., Santiago Bragagnolo wrote: > > Fosdem organization uploaded the videos on grafoscopio :). > > > > Maybe it would be nice to spread it through our medias > > > > > https://video.fosdem.org/2020/AW1.126/open_research_pocket_infrastructures.… > > > https://video.fosdem.org/2020/AW1.126/open_research_pocket_infrastructures.… > > > > Santiago > > >

Feb. 7, 2020