April 2022 - Pharo-users - lists.pharo.org

Loading from a git repository with Metacello on a running seaside image

by Emilio Oca

Hi List I need some help with Metacello, and may be git too I would like to be able to, in a running headless image, load the last commit of a git repo Something like Metacello new baseline:'MyProject'; repository: 'github://myUser/MyProject:main/myProject'; load. works just once and may open some dialogs Something like this [ [ Metacello new baseline:'MyProject'; repository: 'github://myUser/MyProject:main/myProject'; onConflictUseIncoming; load. ] on: MetacelloSkipDirtyPackageLoad do: [ :ex | ex resume: false ]. ] on: MCMergeOrLoadWarning do: [ :ex | ex load ]. Avoids the dialogs and alerts but the code is still not updated. My intention is to be able to 'refresh' a running seaside image with its latest development version from a git repo (avoiding to personally reach the server and rebuild the docker image) What am I missing? Best Emilio

April 23, 2022

Re: A question about #beginsWith: and #endsWith:

by Richard O'Keefe

Dan Ingalls is of course a big NAME in the world of Smalltalk, but the stated reason for changing the behaviour of #beginsWith: and #endsWith: makes no sense. We have many ways to define a partial order on strings. x <= y iff y beginsWith: x x <= y iff y endsWith: x x <= y iff y includesSubCollection: x x <= y iff y includesSubSequence: x These things are supposed to obey laws: if a beginsWith: b , c then a beginsWith: b if a endsWith: b , c then a endsWith: c if a includesSubCollection: b , c then a includesSubCollection: b and a includesSubCollection: c if a includesSubSequence: b , c then a includesSubSequence: b and a includesSubSequence: c. We also expect the usual rules of equality to hold. So (1) a beginsWith: a (2) a = '' , a (3) THEREFORE a beginsWith: '' (1) a endsWith: a (2) a = a , '' (3) THEREFORE a endsWith: '' (1) a includesSubCollection: a (2) a = '' , a (3) THEREFORE a includesSubCollect: '' Reasoning about strings (as values) gets enormously more complicated if the operations do not follow simple sensible rules, and having '' be the least string under these orderings and having '' be a prefix and a suffix of any string is essential if the rules are going to be simple and coherent. '' is to strings (and more generally empty sequences are to sequences) pretty much what 0 is to integers. Denying that 'abc' beginsWith: '' is *structurally* just like denying that 0 <= 123. Now as it happens I *can* see a use for versions of #beginsWith: and #endsWith: that diverge from the ones we have, but *this* is not where they need to diverge. a beginsWithGraphemesOf: b iff a asGraphemes = b asGraphemes , c asGraphemes for some c, where s asGraphemes returns a sequence of strings each of which is a maximally long grapheme cluster, such that concatenating s asGraphemes recovers s. That is, #beginsWithGraphemesOf: and #endsWithGraphemesOf: would respect the Unicode Text Segmentation boundaries. But s beginsWithGraphemesOf: '' would still need to be true. The thing is, in practice you often DON'T KNOW whether a potential affix is empty or not. Here are some of my test cases. testTestData "Ensure that the sample string has no duplicates." [(Set withAll: string) size = stringSize] assert. testBeginsWith "Test that every prefix of the sample IS a prefix of it." 0 to: stringSize do: [:n | [string beginsWith: (string copyFrom: 1 to: n)] assert]. testEndsWith "Test that every suffix of the sample IS a suffix of it." 0 to: stringSize do: [:n | [string endsWith: (string copyFrom: stringSize - n + 1 to: stringSize)] assert]. testIndexOfSubCollectionAtBeginning "Test that every prefix of 'abcd' is found at the beginning." 0 to: stringSize do: [:n | |s i t| s := string copyFrom: 1 to: n. i := string indexOfSubCollection: s startingAt: 1. [1 = i] assert. t := string copyFrom: i to: i - 1 + n. [t = s] assert]. testIndexOfSubCollectionAtEnd "Test that every proper suffix of the sample is found at the end." 1 to: stringSize do: [:n | |s i t| s := string copyFrom: stringSize - n + 1 to: stringSize. i := string indexOfSubCollection: s startingAt: 1. [stringSize + 1 - n = i] assert. t := string copyFrom: i to: i - 1 + n. [t = s] assert]. testLastIndexOfSubCollectionAtBeginning "Test that every proper prefix of the sample is found at the beginning." 1 to: stringSize do: [:n | |s i t| s := string copyFrom: 1 to: n. i := string lastIndexOfSubCollection: s startingAt: stringSize. [1 = i] assert. t := string copyFrom: i to: i - 1 + n. [t = s] assert]. testLastIndexOfSubCollectionAtEnd "Test that every suffix of the sample is found at the end." 0 to: stringSize do: [:n | |s i t| s := string copyFrom: stringSize - n + 1 to: stringSize. i := string lastIndexOfSubCollection: s startingAt: stringSize. [stringSize + 1 - n = i] assert. t := string copyFrom: i to: i - 1 + n. [t = s] assert]. testOccurrencesOfEmptyCollection "Test that the empty string occurs at the beginning, at the end, and in between every pair of adjacent characters." [(string occurrencesOfSubCollection: '') = (stringSize + 1)] assert. testOccurrencesOfUniqueParts "Test that unique parts occur as many times as they should." |repeated| repeated := string , string , string. 1 to: stringSize do: [:start | start to: stringSize do: [:finish | |s n| s := string copyFrom: start to: finish. n := string occurrencesOfSubCollection: s. [n = 1] assert. n := repeated occurrencesOfSubCollection: s. [n = 3] assert]]. On Fri, 22 Apr 2022 at 13:57, David T. Lewis <lewis(a)mail.msen.com> wrote: > Hi Richard, > > (CC squeak-dev list, replies to the relevant list please) > > On Thu, Apr 21, 2022 at 12:07:32AM +1200, Richard O'Keefe wrote: > > I've just tracked down a nasty little problem > > porting some code to Pharo. As a result, I > > have added to the comments in my own versions > > of these methods. beginsWith: aSequence > > "Answer true if aSequence is a prefix of the receiver. > > This makes sense for all sequences. > > There is a compatibility issue concerning 'abc' beginsWith: '' > > + VisualWorks, Dolphin, astc, GNU ST (where the method is > > called #startsWith:) and VisualAge (where the method > > is called #wbBeginsWith:) > > agree than EVERY sequence begins with an empty prefix. > > - Squeak and Pharo > > agree that NO sequence begins with an empty sequence. > > # ST/X chooses compatibility with Squeak, heaving a big unhappy > > sigh, and adds #startsWith: to have something sensible to use. > > Now ST/X *thinks* it is compatible with VW, though it isn't, so > > I wonder if this was a bug that VW fixed and Squeak didn't? > > astc goes with the majority here. This is also compatible with > > Haskell, ML, and with StartsWith in C# and startsWith in Java." > > ^self beginsWith: aSequence ignoringCase: false > > > > endsWith: aSequence > > "Answer true if aSequence is a suffix of the receiver. > > This makes sense for all sequences. > > There is a compatibility issue concerning 'abc' endsWith: ''. > > + VisualWorks, Dolphin, astc, GNU ST, and VisualAge (where > > the method is called #wbEndsWith:) > > agree that EVERY sequence ends with an empty suffix. > > - Squeak and Pharo > > agree that NO sequence ends with an empty suffix. > > # ST/X chooses compatibility with the majority, apparently > > unaware that this makes #beginsWith: and #endsWith: > inconsistent. > > astc goes with the majority here. This is also compatible with > > Haskell, ML, C#, and Java." > > ^self endsWith: aSequence ignoringCase: false > > > > Does anyone have any idea > > - why Squeak and Pharo are the odd ones out? > > - why anyone thought making #beginsWith: and #endsWith:, um, "quirky" > > was a good idea (it's pretty standard in books on the theory of > > strings to define "x is a prefix of y iff there is a z such that > > y = x concatenated with z") > > The Squeak behavior was introduced in November 1998 by Dan Ingalls > in conjunction with some VM improvements that he was doing, and was > included in the Squeak2.2 release at that time. > > Prior to that update, Squeak did this: > 'abc' beginsWith: '' ==> true > 'abc' endsWith: '' ==> true > > For Squeak2.2 and later it is: > 'abc' beginsWith: '' ==> false > 'abc' endsWith: '' ==> false > > Pharo presumably inherits this from Squeak. > > I am attaching Dan's original change set from the early Squeak > update stream so you can see the context. > > The change set comment says that "endsWith:, beginsWith:, and match > have been rewritten to take advantage of this considerably faster method" > (referring to a new primitive that Dan had added to the VM in this > change set). > > > > > I was about to try to file a bug report for the first time, > > then realised that maybe other people don't think this IS a bug. > > I don't think it is a bug. I can't think of a case where it makes > sense to say that a string of characters "begins with" or "ends with" > a string that contains nothing. > > In any case, that's the history of the change in Squeak and Pharo as > best as I can reconstruct it. > > HTH, > Dave > >

April 23, 2022

Re: A question about #beginsWith: and #endsWith:

by David T. Lewis

Hi Richard, (CC squeak-dev list, replies to the relevant list please) On Thu, Apr 21, 2022 at 12:07:32AM +1200, Richard O'Keefe wrote: > I've just tracked down a nasty little problem > porting some code to Pharo. As a result, I > have added to the comments in my own versions > of these methods. beginsWith: aSequence > "Answer true if aSequence is a prefix of the receiver. > This makes sense for all sequences. > There is a compatibility issue concerning 'abc' beginsWith: '' > + VisualWorks, Dolphin, astc, GNU ST (where the method is > called #startsWith:) and VisualAge (where the method > is called #wbBeginsWith:) > agree than EVERY sequence begins with an empty prefix. > - Squeak and Pharo > agree that NO sequence begins with an empty sequence. > # ST/X chooses compatibility with Squeak, heaving a big unhappy > sigh, and adds #startsWith: to have something sensible to use. > Now ST/X *thinks* it is compatible with VW, though it isn't, so > I wonder if this was a bug that VW fixed and Squeak didn't? > astc goes with the majority here. This is also compatible with > Haskell, ML, and with StartsWith in C# and startsWith in Java." > ^self beginsWith: aSequence ignoringCase: false > > endsWith: aSequence > "Answer true if aSequence is a suffix of the receiver. > This makes sense for all sequences. > There is a compatibility issue concerning 'abc' endsWith: ''. > + VisualWorks, Dolphin, astc, GNU ST, and VisualAge (where > the method is called #wbEndsWith:) > agree that EVERY sequence ends with an empty suffix. > - Squeak and Pharo > agree that NO sequence ends with an empty suffix. > # ST/X chooses compatibility with the majority, apparently > unaware that this makes #beginsWith: and #endsWith: inconsistent. > astc goes with the majority here. This is also compatible with > Haskell, ML, C#, and Java." > ^self endsWith: aSequence ignoringCase: false > > Does anyone have any idea > - why Squeak and Pharo are the odd ones out? > - why anyone thought making #beginsWith: and #endsWith:, um, "quirky" > was a good idea (it's pretty standard in books on the theory of > strings to define "x is a prefix of y iff there is a z such that > y = x concatenated with z") The Squeak behavior was introduced in November 1998 by Dan Ingalls in conjunction with some VM improvements that he was doing, and was included in the Squeak2.2 release at that time. Prior to that update, Squeak did this: 'abc' beginsWith: '' ==> true 'abc' endsWith: '' ==> true For Squeak2.2 and later it is: 'abc' beginsWith: '' ==> false 'abc' endsWith: '' ==> false Pharo presumably inherits this from Squeak. I am attaching Dan's original change set from the early Squeak update stream so you can see the context. The change set comment says that "endsWith:, beginsWith:, and match have been rewritten to take advantage of this considerably faster method" (referring to a new primitive that Dan had added to the VM in this change set). > > I was about to try to file a bug report for the first time, > then realised that maybe other people don't think this IS a bug. I don't think it is a bug. I can't think of a case where it makes sense to say that a string of characters "begins with" or "ends with" a string that contains nothing. In any case, that's the history of the change in Squeak and Pharo as best as I can reconstruct it. HTH, Dave

April 22, 2022

[ANN] Stargate v8.1.1 [v8.1.1] released!

by Buenos Aires Smalltalk

April 21, 2022

UK Smalltalk User Group Meeting - Wednesday, April 27th

by Giovanni Corriga

The next meeting of the UK Smalltalk User Group will be held on Wednesday, April 27th 2022. Newspeak ( https://bracha.org/Site/Newspeak.html ) is a programming system in the Smalltalk tradition, whose current incarnation runs in the web browser. Newspeak is designed to provide the liveness Smalltalkers expect, as well as features atypical of Smalltalk such as modularity, security and good interoperability with the surrounding ecosystem. In this talk, we'll explain how and why Newspeak differs from Smalltalk and demonstrate the Newspeak IDE. Gilad Bracha is the creator of the Newspeak programming language and a well known researcher in the area of object-oriented programming languages. He was awarded the senior Dahl-Nygaard prize in 2017. He is currently a Technical Fellow at F5, and has held positions at Google, SAP Labs, Cadence, and Sun. He has authored or co-authored several books including the Java Language and Virtual Machine Specifications, and the Dart Programming Language. Prior to joining Sun, he worked on Strongtalk, the Animorphic Smalltalk System. He received his B.Sc in Mathematics and Computer Science from Ben Gurion University in Israel and a Ph.D. in Computer Science from the University of Utah. This will be an online meeting from home. If you'd like to join us, please sign up in advance on the meeting's Meetup page ( https://www.meetup.com/UKSTUG/events/cbklbrydcgbkc/ ) to receive the meeting details. Donât forget to bring your laptop and drinks!

April 20, 2022

Re: A question about #beginsWith: and #endsWith:

by Sven Van Caekenberghe

Since 'abc' includesSubstring: ''. "true" 'abc' indexOfSubCollection: ''. "0" and following basic principles, my first reaction would also be that 'abc' beginsWith: ''. 'abc' endsWith: ''. should both be true. On the other hand, this is really a degenerate case. You know the answer upfront (it does not depend on the actual receiver) and thus it does not tell you much. I vote for this to be a bug. > On 20 Apr 2022, at 14:07, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > I've just tracked down a nasty little problem > porting some code to Pharo. As a result, I > have added to the comments in my own versions > of these methods. beginsWith: aSequence > "Answer true if aSequence is a prefix of the receiver. > This makes sense for all sequences. > There is a compatibility issue concerning 'abc' beginsWith: '' > + VisualWorks, Dolphin, astc, GNU ST (where the method is > called #startsWith:) and VisualAge (where the method > is called #wbBeginsWith:) > agree than EVERY sequence begins with an empty prefix. > - Squeak and Pharo > agree that NO sequence begins with an empty sequence. > # ST/X chooses compatibility with Squeak, heaving a big unhappy > sigh, and adds #startsWith: to have something sensible to use. > Now ST/X *thinks* it is compatible with VW, though it isn't, so > I wonder if this was a bug that VW fixed and Squeak didn't? > astc goes with the majority here. This is also compatible with > Haskell, ML, and with StartsWith in C# and startsWith in Java." > ^self beginsWith: aSequence ignoringCase: false > > endsWith: aSequence > "Answer true if aSequence is a suffix of the receiver. > This makes sense for all sequences. > There is a compatibility issue concerning 'abc' endsWith: ''. > + VisualWorks, Dolphin, astc, GNU ST, and VisualAge (where > the method is called #wbEndsWith:) > agree that EVERY sequence ends with an empty suffix. > - Squeak and Pharo > agree that NO sequence ends with an empty suffix. > # ST/X chooses compatibility with the majority, apparently > unaware that this makes #beginsWith: and #endsWith: inconsistent. > astc goes with the majority here. This is also compatible with > Haskell, ML, C#, and Java." > ^self endsWith: aSequence ignoringCase: false > > Does anyone have any idea > - why Squeak and Pharo are the odd ones out? > - why anyone thought making #beginsWith: and #endsWith:, um, "quirky" > was a good idea (it's pretty standard in books on the theory of > strings to define "x is a prefix of y iff there is a z such that > y = x concatenated with z") > > I was about to try to file a bug report for the first time, > then realised that maybe other people don't think this IS a bug. > > >

April 20, 2022

Re: A question about #beginsWith: and #endsWith:

by Kasper Osterbye

Yes, that one I have come across several times - even without trying to port anything, merely because it is how beginsWith: should work (supporting the empty string). I have no idea about the rationale though. Best, Kasper > On 20 Apr 2022, at 14.07, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > I've just tracked down a nasty little problem > porting some code to Pharo. As a result, I > have added to the comments in my own versions > of these methods. beginsWith: aSequence > "Answer true if aSequence is a prefix of the receiver. > This makes sense for all sequences. > There is a compatibility issue concerning 'abc' beginsWith: '' > + VisualWorks, Dolphin, astc, GNU ST (where the method is > called #startsWith:) and VisualAge (where the method > is called #wbBeginsWith:) > agree than EVERY sequence begins with an empty prefix. > - Squeak and Pharo > agree that NO sequence begins with an empty sequence. > # ST/X chooses compatibility with Squeak, heaving a big unhappy > sigh, and adds #startsWith: to have something sensible to use. > Now ST/X *thinks* it is compatible with VW, though it isn't, so > I wonder if this was a bug that VW fixed and Squeak didn't? > astc goes with the majority here. This is also compatible with > Haskell, ML, and with StartsWith in C# and startsWith in Java." > ^self beginsWith: aSequence ignoringCase: false > > endsWith: aSequence > "Answer true if aSequence is a suffix of the receiver. > This makes sense for all sequences. > There is a compatibility issue concerning 'abc' endsWith: ''. > + VisualWorks, Dolphin, astc, GNU ST, and VisualAge (where > the method is called #wbEndsWith:) > agree that EVERY sequence ends with an empty suffix. > - Squeak and Pharo > agree that NO sequence ends with an empty suffix. > # ST/X chooses compatibility with the majority, apparently > unaware that this makes #beginsWith: and #endsWith: inconsistent. > astc goes with the majority here. This is also compatible with > Haskell, ML, C#, and Java." > ^self endsWith: aSequence ignoringCase: false > > Does anyone have any idea > - why Squeak and Pharo are the odd ones out? > - why anyone thought making #beginsWith: and #endsWith:, um, "quirky" > was a good idea (it's pretty standard in books on the theory of > strings to define "x is a prefix of y iff there is a z such that > y = x concatenated with z") > > I was about to try to file a bug report for the first time, > then realised that maybe other people don't think this IS a bug. > > >

April 20, 2022

A question about #beginsWith: and #endsWith:

by Richard O'Keefe

I've just tracked down a nasty little problem porting some code to Pharo. As a result, I have added to the comments in my own versions of these methods. beginsWith: aSequence "Answer true if aSequence is a prefix of the receiver. This makes sense for all sequences. There is a compatibility issue concerning 'abc' beginsWith: '' + VisualWorks, Dolphin, astc, GNU ST (where the method is called #startsWith:) and VisualAge (where the method is called #wbBeginsWith:) agree than EVERY sequence begins with an empty prefix. - Squeak and Pharo agree that NO sequence begins with an empty sequence. # ST/X chooses compatibility with Squeak, heaving a big unhappy sigh, and adds #startsWith: to have something sensible to use. Now ST/X *thinks* it is compatible with VW, though it isn't, so I wonder if this was a bug that VW fixed and Squeak didn't? astc goes with the majority here. This is also compatible with Haskell, ML, and with StartsWith in C# and startsWith in Java." ^self beginsWith: aSequence ignoringCase: false endsWith: aSequence "Answer true if aSequence is a suffix of the receiver. This makes sense for all sequences. There is a compatibility issue concerning 'abc' endsWith: ''. + VisualWorks, Dolphin, astc, GNU ST, and VisualAge (where the method is called #wbEndsWith:) agree that EVERY sequence ends with an empty suffix. - Squeak and Pharo agree that NO sequence ends with an empty suffix. # ST/X chooses compatibility with the majority, apparently unaware that this makes #beginsWith: and #endsWith: inconsistent. astc goes with the majority here. This is also compatible with Haskell, ML, C#, and Java." ^self endsWith: aSequence ignoringCase: false Does anyone have any idea - why Squeak and Pharo are the odd ones out? - why anyone thought making #beginsWith: and #endsWith:, um, "quirky" was a good idea (it's pretty standard in books on the theory of strings to define "x is a prefix of y iff there is a z such that y = x concatenated with z") I was about to try to file a bug report for the first time, then realised that maybe other people don't think this IS a bug.

April 20, 2022

[ANN] RenoirSt v7.1.0 [v7.1.0] released!

by Buenos Aires Smalltalk

April 20, 2022

[ANN] Cannon v1.1.0 [v1.1.0] released!

by Buenos Aires Smalltalk

April 19, 2022

[ANN] Boardwalk v6.2.0 [v6.2.0] released!

by Buenos Aires Smalltalk

April 19, 2022

[ANN] Ansible v1.1.0 [v1.1.0] released!

by Buenos Aires Smalltalk

April 19, 2022

[ANN] Mole v3.3.0 [v3.3.0] released!

by Buenos Aires Smalltalk

April 19, 2022

Re: [Pharo-dev] [ANN] Pharo Launcher 3.0 released!

by Guillermo Polito

Thanks Christophe, this is super work :) > El 14 abr 2022, a las 14:26, Christophe Demarey <christophe.demarey(a)inria.fr> escribiÃ³: > > Hi all, > > Pharo Launcher 3.0 has just been released! It is available from http://pharo.org/download <http://pharo.org/download>. > It is based on latest Spec2 and Pharo 10 image. > It now comes with a native Apple Silicon version and Mac OS packages are notarized. > Big thanks to all contributors, including issue reports. > > Here is the changelog: > Pharo Launcher v3.0 > New features: > > Full rewrite of the UI using Spec 2 and Pharo 10 > Pharo Launcher can now run natively on Apple Silicon #544 <https://github.com/pharo-project/pharo-launcher/issues/544> > Pharo Launcher is now signed with a Mac Os developper account and notarized #529 <https://github.com/pharo-project/pharo-launcher/issues/529> > Windows "portable" package (only an archive without installer) #534 <https://github.com/pharo-project/pharo-launcher/issues/534> > Improvements: > > While importing image .sources and .version are not moved #543 <https://github.com/pharo-project/pharo-launcher/issues/543> > recreate the image does not re apply the script if one is provided #536 <https://github.com/pharo-project/pharo-launcher/issues/536> (thanks to @hogoww <https://github.com/hogoww>) > Save keybind for scripts #545 <https://github.com/pharo-project/pharo-launcher/pull/545> (thanks to @hogoww <https://github.com/hogoww> and @Inao0 <https://github.com/Inao0>) > Bug fixes: > > GitHub releases artefacts download were not always working #535 <https://github.com/pharo-project/pharo-launcher/issues/535> > "Basic launch" does not do its job in Pharo 10 #540 <https://github.com/pharo-project/pharo-launcher/issues/540> > Proxy settings not applied through settings screen #541 <https://github.com/pharo-project/pharo-launcher/issues/541> > > Regards, > The Pharo team.

April 19, 2022

[ANN] Stargate v8.1.0 [v8.1.0] released!

by Buenos Aires Smalltalk

April 18, 2022

Re: [ANN] Pharo Launcher 3.0 released!

by Renaud de Villemeur

Thanks Craig, that did the trick. Renaud 15 avr. 2022, 04 h 56 de craig(a)hivemind.net: > > Renaud, > > > Â > > > I experienced the same issue.Â I assumed that I did something wrong so did-not report it. > > > I installed PL 3.0 over the previous version and I think that this this broke the VM somehow. > > > To fix this, I uninstalled Pharo-Launcher, cleaned out everything in %userprofile%\AppData\Local\PharoLauncher, reinstalled it, and now it works again. > > > Â > > > Craig > > Â > > On 2022-04-15 04:12, Renaud de Villemeur via Pharo-users wrote: > > >> Thanks for the update. The Pharo Launcher is a really valuable tool. >> Â >> I experience some issue on windows (windows 11 pro). The launcher doesn't show up. >> I double click on the icon, and no window appears. I can however see that the process is running in the task manager. I can open the launcher image from the local install of pharo VM 100-x64 (installed using Pharo Launcher 2.4, last update 2022-03-20), and the launcher is working great that way. >> Â >> Are you using a special build of the VM ? >> Â >> Thanks >> Renaud >> Â >> Â >> Apr 14, 2022, 08:26 by christophe.demarey(a)inria.fr: >> >>> Hi all, >>> Â >>> Pharo Launcher 3.0 has just been released! It is available fromÂ >>> http://pharo.org/download>>> . >>> It is based on latest Spec2 and Pharo 10 image. >>> It now comes with a native Apple Silicon version and Mac OS packages are notarized. >>> Big thanks to all contributors, including issue reports.Â >>> Â >>> Here is the changelog: >>> Pharo Launcher v3.0 >>> >>> New features: >>> >>> Full rewrite of the UI using Spec 2 and Pharo 10 >>> Pharo Launcher can now run natively on Apple Silicon >>> #544 <https://github.com/pharo-project/pharo-launcher/issues/544> >>> Pharo Launcher is now signed with a Mac Os developper account and notarized >>> #529 <https://github.com/pharo-project/pharo-launcher/issues/529> >>> Windows "portable" package (only an archive without installer) >>> #534 <https://github.com/pharo-project/pharo-launcher/issues/534> >>> >>> Improvements: >>> >>> While importing image .sources and .version are not moved >>> #543 <https://github.com/pharo-project/pharo-launcher/issues/543> >>> recreate the image does not re apply the script if one is provided >>> #536 <https://github.com/pharo-project/pharo-launcher/issues/536>>>> (thanks to >>> @hogoww <https://github.com/hogoww>>>> ) >>> Save keybind for scripts >>> #545 <https://github.com/pharo-project/pharo-launcher/pull/545>>>> (thanks to >>> @hogoww <https://github.com/hogoww>>>> and >>> @Inao0 <https://github.com/Inao0>>>> ) >>> >>> Bug fixes: >>> >>> GitHub releases artefacts download were not always working >>> #535 <https://github.com/pharo-project/pharo-launcher/issues/535> >>> "Basic launch" does not do its job in Pharo 10 >>> #540 <https://github.com/pharo-project/pharo-launcher/issues/540> >>> Proxy settings not applied through settings screen >>> #541 <https://github.com/pharo-project/pharo-launcher/issues/541> >>> Â >>> Regards, >>> The Pharo team. >>> >> Â >>

April 15, 2022

Re: [ANN] Pharo Launcher 3.0 released!

by craig

Renaud, I experienced the same issue. I assumed that I did something wrong so did-not report it. I installed PL 3.0 over the previous version and I think that this this broke the VM somehow. To fix this, I uninstalled Pharo-Launcher, cleaned out everything in %userprofile%AppDataLocalPharoLauncher, reinstalled it, and now it works again. Craig On 2022-04-15 04:12, Renaud de Villemeur via Pharo-users wrote: > Thanks for the update. The Pharo Launcher is a really valuable tool. > > I experience some issue on windows (windows 11 pro). The launcher doesn't show up. > I double click on the icon, and no window appears. I can however see that the process is running in the task manager. I can open the launcher image from the local install of pharo VM 100-x64 (installed using Pharo Launcher 2.4, last update 2022-03-20), and the launcher is working great that way. > > Are you using a special build of the VM ? > > Thanks > Renaud > > Apr 14, 2022, 08:26 by christophe.demarey(a)inria.fr: > >> Hi all, >> >> Pharo Launcher 3.0 has just been released! It is available from http://pharo.org/download [1]. >> It is based on latest Spec2 and Pharo 10 image. >> >> It now comes with a native Apple Silicon version and Mac OS packages are notarized. >> Big thanks to all contributors, including issue reports. >> >> Here is the changelog: >> Pharo Launcher v3.0 >> >> New features: >> >> * Full rewrite of the UI using Spec 2 and Pharo 10 >> * Pharo Launcher can now run natively on Apple Silicon #544 [2] >> * Pharo Launcher is now signed with a Mac Os developper account and notarized #529 [3] >> * Windows "portable" package (only an archive without installer) #534 [4] >> >> Improvements: >> >> * While importing image .sources and .version are not moved #543 [5] >> * recreate the image does not re apply the script if one is provided #536 [6] (thanks to @hogoww [7]) >> * Save keybind for scripts #545 [8] (thanks to @hogoww [7] and @Inao0 [9]) >> >> Bug fixes: >> >> * GitHub releases artefacts download were not always working #535 [10] >> * "Basic launch" does not do its job in Pharo 10 #540 [11] >> * Proxy settings not applied through settings screen #541 [12] >> >> Regards, >> The Pharo team. Links: ------ [1] http://pharo.org/download [2] https://github.com/pharo-project/pharo-launcher/issues/544 [3] https://github.com/pharo-project/pharo-launcher/issues/529 [4] https://github.com/pharo-project/pharo-launcher/issues/534 [5] https://github.com/pharo-project/pharo-launcher/issues/543 [6] https://github.com/pharo-project/pharo-launcher/issues/536 [7] https://github.com/hogoww [8] https://github.com/pharo-project/pharo-launcher/pull/545 [9] https://github.com/Inao0 [10] https://github.com/pharo-project/pharo-launcher/issues/535 [11] https://github.com/pharo-project/pharo-launcher/issues/540 [12] https://github.com/pharo-project/pharo-launcher/issues/541

April 15, 2022

Re: [ANN] Pharo Launcher 3.0 released!

by Renaud de Villemeur

Thanks for the update. The Pharo Launcher is a really valuable tool. I experience some issue on windows (windows 11 pro). The launcher doesn't show up. I double click on the icon, and no window appears. I can however see that the process is running in the task manager. I can open the launcher image from the local install of pharo VM 100-x64 (installed using Pharo Launcher 2.4, last update 2022-03-20), and the launcher is working great that way. Are you using a special build of the VM ? Thanks Renaud Apr 14, 2022, 08:26 by christophe.demarey(a)inria.fr: > Hi all, > > Pharo Launcher 3.0 has just been released! It is available fromÂ > http://pharo.org/download> . > It is based on latest Spec2 and Pharo 10 image. > It now comes with a native Apple Silicon version and Mac OS packages are notarized. > Big thanks to all contributors, including issue reports.Â > > Here is the changelog: > Pharo Launcher v3.0 > > New features: > > Full rewrite of the UI using Spec 2 and Pharo 10 > Pharo Launcher can now run natively on Apple Silicon > #544 <https://github.com/pharo-project/pharo-launcher/issues/544> > Pharo Launcher is now signed with a Mac Os developper account and notarized > #529 <https://github.com/pharo-project/pharo-launcher/issues/529> > Windows "portable" package (only an archive without installer) > #534 <https://github.com/pharo-project/pharo-launcher/issues/534> > > Improvements: > > While importing image .sources and .version are not moved > #543 <https://github.com/pharo-project/pharo-launcher/issues/543> > recreate the image does not re apply the script if one is provided > #536 <https://github.com/pharo-project/pharo-launcher/issues/536>> (thanks to > @hogoww <https://github.com/hogoww>> ) > Save keybind for scripts > #545 <https://github.com/pharo-project/pharo-launcher/pull/545>> (thanks to > @hogoww <https://github.com/hogoww>> and > @Inao0 <https://github.com/Inao0>> ) > > Bug fixes: > > GitHub releases artefacts download were not always working > #535 <https://github.com/pharo-project/pharo-launcher/issues/535> > "Basic launch" does not do its job in Pharo 10 > #540 <https://github.com/pharo-project/pharo-launcher/issues/540> > Proxy settings not applied through settings screen > #541 <https://github.com/pharo-project/pharo-launcher/issues/541> > > Regards, > The Pharo team. >

April 15, 2022

Re: [ANN] Pharo Launcher 3.0 released!

by Steffen MÃ¤rcker

Hi Christophe, thanks, that's great news! [Downloading ...] Cheers! Steffen Christophe Demarey schrieb am Donnerstag, 14. April 2022 14:26:26 (+02:00): Hi all, Pharo Launcher 3.0 has just been released! It is available from http://pharo.org/download. It is based on latest Spec2 and Pharo 10 image. It now comes with a native Apple Silicon version and Mac OS packages are notarized. Big thanks to all contributors, including issue reports. Here is the changelog: Pharo Launcher v3.0 New features: Full rewrite of the UI using Spec 2 and Pharo 10 Pharo Launcher can now run natively on Apple Silicon #544 Pharo Launcher is now signed with a Mac Os developper account and notarized #529 Windows "portable" package (only an archive without installer) #534 Improvements: While importing image .sources and .version are not moved #543 recreate the image does not re apply the script if one is provided #536 (thanks to @hogoww) Save keybind for scripts #545 (thanks to @hogoww and @Inao0) Bug fixes: GitHub releases artefacts download were not always working #535 "Basic launch" does not do its job in Pharo 10 #540 Proxy settings not applied through settings screen #541 Regards, The Pharo team. -- Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com herunter.

April 14, 2022

[ANN] Pharo Launcher 3.0 released!

by Christophe Demarey

Hi all, Pharo Launcher 3.0 has just been released! It is available from http://pharo.org/download. It is based on latest Spec2 and Pharo 10 image. It now comes with a native Apple Silicon version and Mac OS packages are notarized. Big thanks to all contributors, including issue reports. Here is the changelog: Pharo Launcher v3.0 New features: Full rewrite of the UI using Spec 2 and Pharo 10 Pharo Launcher can now run natively on Apple Silicon #544 <https://github.com/pharo-project/pharo-launcher/issues/544> Pharo Launcher is now signed with a Mac Os developper account and notarized #529 <https://github.com/pharo-project/pharo-launcher/issues/529> Windows "portable" package (only an archive without installer) #534 <https://github.com/pharo-project/pharo-launcher/issues/534> Improvements: While importing image .sources and .version are not moved #543 <https://github.com/pharo-project/pharo-launcher/issues/543> recreate the image does not re apply the script if one is provided #536 <https://github.com/pharo-project/pharo-launcher/issues/536> (thanks to @hogoww <https://github.com/hogoww>) Save keybind for scripts #545 <https://github.com/pharo-project/pharo-launcher/pull/545> (thanks to @hogoww <https://github.com/hogoww> and @Inao0 <https://github.com/Inao0>) Bug fixes: GitHub releases artefacts download were not always working #535 <https://github.com/pharo-project/pharo-launcher/issues/535> "Basic launch" does not do its job in Pharo 10 #540 <https://github.com/pharo-project/pharo-launcher/issues/540> Proxy settings not applied through settings screen #541 <https://github.com/pharo-project/pharo-launcher/issues/541> Regards, The Pharo team.

April 14, 2022

[ANN] Kepler v5.1.0 [v5.1.0] released!

by Buenos Aires Smalltalk

April 13, 2022

Re: Intended behaviour of flatten and flatCollect:

by Richard O'Keefe

PS: *Neither* #flattened nor #flatCollect: can be blamed on 40 years of history. #flatten(ed) arrived in Squeak back in 2015, at which time #flatCollect: did not exist. In fact there is *still* no #flatCollect: in Squeak, although Squeak does have #gather:, since 2002. #flatCollect: was added to Pharo more recently still, as a new name for the tolerably well established #gather:, apparently in the belief that it was a better name. Given #flattened, it is not. #gather: is not all that helpful, but #flatCollect: is just wrong. Even if #flattened did not exist, the result of #flatCollect: is generally not in any sense flat. I repeat: NONE of this can be blamed on Smalltalk history. #flattened was born crufty in 2015 and #flatCollect: is a recent addition to Pharo. On Thu, 14 Apr 2022 at 02:03, Richard O'Keefe <raoknz(a)gmail.com> wrote: > It would help to know which version of Pharo you are using. > #(1 2 3) flatten > raises an exception in Pharo 9 because there is no #flatten > in Array's protocol. > Collection has > #flatCollect: > -- #gather: was not a terribly helpful name, > -- but #flatCollect: is horribly misleading. > #flatCollect:as: > -- A misplaced method, should be > -- Collection class >> withAll: aCollection gather: aBlock > #flatCollectAsSet: > -- a trivial special case of #flatCollect:as:, > -- not clear why this special case exists. > #flattenOn: > -- aStream nextPutAll: self flattened > -- but without creating the intermediate data structure > #flattened > -- a curiously twisted "flatten" that does not work > -- at all for non-collections. > > #(1 2 3) flattened => #(1 2 3) > 1 flattened => BOOM! > > By the way, we cannot blame the cruftiness of #flattened on > 40 years of history. #flatten/#flattened only entered Squeak > about 7 years ago and it was BORN crufty. I mistakenly thought > Squeak and Pharo agreed on what it meant. They do not. > Squeak: puts it on SequenceableCollection and Stream. > Pharo : puts it on Collection (more general) and not Stream (less so). > Squeak: treats stream elements like nested collections. > Pharo : doesn't. > So my earlier claim bears repeating: of the Smalltalk systems that > have some kind of flattening, no two agree on what it means. > > The one use I have ever had for flattening is to build up a > large string by accumulating characters, strings, symbols, > and sequences of the same in a sequence and then flattening > the tree into a single string, which is something that > Squeak and Pharo flatly refuse to do. > > One improvement I would like to see in Pharo 11 is for these > methods to be deleted. > >

April 13, 2022

Re: Intended behaviour of flatten and flatCollect:

by Richard O'Keefe

It would help to know which version of Pharo you are using. #(1 2 3) flatten raises an exception in Pharo 9 because there is no #flatten in Array's protocol. Collection has #flatCollect: -- #gather: was not a terribly helpful name, -- but #flatCollect: is horribly misleading. #flatCollect:as: -- A misplaced method, should be -- Collection class >> withAll: aCollection gather: aBlock #flatCollectAsSet: -- a trivial special case of #flatCollect:as:, -- not clear why this special case exists. #flattenOn: -- aStream nextPutAll: self flattened -- but without creating the intermediate data structure #flattened -- a curiously twisted "flatten" that does not work -- at all for non-collections. #(1 2 3) flattened => #(1 2 3) 1 flattened => BOOM! By the way, we cannot blame the cruftiness of #flattened on 40 years of history. #flatten/#flattened only entered Squeak about 7 years ago and it was BORN crufty. I mistakenly thought Squeak and Pharo agreed on what it meant. They do not. Squeak: puts it on SequenceableCollection and Stream. Pharo : puts it on Collection (more general) and not Stream (less so). Squeak: treats stream elements like nested collections. Pharo : doesn't. So my earlier claim bears repeating: of the Smalltalk systems that have some kind of flattening, no two agree on what it means. The one use I have ever had for flattening is to build up a large string by accumulating characters, strings, symbols, and sequences of the same in a sequence and then flattening the tree into a single string, which is something that Squeak and Pharo flatly refuse to do. One improvement I would like to see in Pharo 11 is for these methods to be deleted.

April 13, 2022

Re: Intended behaviour of flatten and flatCollect:

by Richard O'Keefe

"Flattening" is problematic in every programming language I know that has something like it in its library. It was born problematic in Lisp and it has continued problematic ever since. (I am aware of several Smalltalk systems offering it. With the exception of Squeak and Pharo, no two of them agree.) The fundamental problem is that which containers (if any) should be treated as leaves and which should not is not something that the language can define. It is problem-specific. Your best bet is to figure out what YOU need for YOUR problem and implement exactly that. I was about to include some code I wrote while trying to make sense of "flattening", but no. There is no substitute for writing something that works for precisely the objects you want it to work and for no others.

April 13, 2022

[ANN] Aconcagua v8.1.0 [v8.1.0] released!

by Buenos Aires Smalltalk

April 13, 2022

Re: WebDav and CalDav in Pharo ?

by jonathan＠objectguild.com

Hi Udo, I hope you are well. Would like to hear more about the updates you mentioned back in November 2019 on your FileSystemNetwork library and WebDAV specifically. We are looking to work with WebDAV/CalDAV using your FileSystemNetwork library for a customer application. As a first step, we have migrated your SmalltalkHub project to a GitHub repo here:Â https://github.com/objectguild/FileSystemNetwork After some modifications to the code for Pharo 8, all unit tests are showing green (we're using a test server URL created usingÂ https://www.webdavserver.com) However, there seem to be some issues handling the actual (binary) file contents. I'm not familiar with the FileSystem classes and I'm having some trouble understanding the technical design, so I'm sure to have made mistakes. Are you willing (and able) to take a look and help out? Perhaps you can show me in the right direction :-) FYI, we have to work in Pharo 8 because of technical contraints. Hope to hear from you! Best, Jonathan van Alteren Guild Member | Object Guild B.V. \ Software that works âwithâ you [jonathan@objectguild.com](mailto:jonathan@objectguild.com)

April 13, 2022

Re: ReStore and storing mixed dictionaries

by John Aspinall

Hi Offray, There isnât currently a formal way to do the automatic transformation you describe (it would be a nice enhancement though). What I have done in similar situations is to carry out the transformation in inst var accessors, e.g. userPictureURL ^userPictureURL ifNotNil: [ZnUrl fromString: userPictureURL] userPictureURL: aZnUrl userPictureURL := aZnUrl pathPrintString ânot sure if this is the correct conversion but you get the ideaâ You then define: #userPictureUrl as: String. This works because ReStore accesses instance variables directly via instVarAt:[put:], but obviously depends on your own code using accessors rather than direct references. Hope this helps. John > On 12 Apr 2022, at 18:32, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi John, > > Thanks. With the improved error message I was able to pin the cause of error better. > The issue was that I was declaring the user picture URL as a ZnURL instead of as a string in the reStoreDefinition, but I was not telling ReStore how to store ZnUrl objects. So I made the returning method to give me a string instead of a ZnUrl, which is kind of counterintuitive for the my model, but returned something that ReStore knew how to serialize. > > I wonder if there is a way, maybe using something like derived keys, to tell reStoreDefinition: execute this block instead of calling the current method to store the value in the database. So, the #profileImageUrl returns a ZnUrl object inside the image model, but is stored as a string in the database without adding more reStoreDefinition for particular objects (like a ZnUrl). Could be this possible in someway? Am I missing something? > > The objects storing is advancing now and hopefully we will have results soon to share, instead of troubleshooting (but we'll share both anyway ;-P). > > Cheers, > > Offray > On 7/04/22 16:19, John Aspinall wrote: >> Hi Offray - could you try modifying SSWReStore>>createProxyForNewObject: as follows: >> >> ... >> table := self tableForClass: anObject class. >> "Add this ->â table isNil ifTrue: [ self error: 'cannot find table for ', anObject class name ]. >> id := table idDataField ifNotNil: [ :idDataField | idDataField accessor valueIn: anObject]. >> â¦ >> >> This should change the error message to show the class of object which doesnât have a valid table. >> >> Thanks. >> >> John >> >> >>> On 7 Apr 2022, at 20:29, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >>> >>> Hi John, >>> >>> Effectively ReStore didn't was storing the table object for the Nitter class. But after following your advice, i'm now able to debug both the TwitterUser and the NitterUser and obtain the same result (which makes sense as the later is inherited from the former). I think that my error was related with the definition of the synchronized tables, as I was not including explicitly the NitterUser (as I thought it would suffice with the TwitterUser one). Now it looks like this: >>> >>> === >>> ReStore connection: (SSWSQLite3Connection on: privateDatabase fullName); >>> connect; >>> addClasses: { Tweet. "TwitterUser." NitterUser }; >>> synchronizeAllClasses. >>> === >>> Now I can get a non nil idDataField that has the same shape when #tableForClass: and "reStoreDefinition asTableIn: ReStore" are send to TwitterUser and NitterUser. Despite of that I still get the pre-commit error: "#idDataField was send to nil". Here is a screenshot of the trace of the error and the idDataFiled seems right (or at least equal to the same field in the TwitterUser): >>> https://i.imgur.com/F3UDC93.png <https://i.imgur.com/F3UDC93.png> >>> For the moment, I'm planing to use an extra/temporal TwitterStoreHelper object that stores via ReStore/SQLite the objects I'm unable to store so far, but as dictionaries of key/value helper objects, where the value is just the STON serialization of the object (with the inconveniences of not being able to query it properly). For example, a 'profiles' dictionary in TwitterStoreHelper would have a Twitter/Nitter user id as a key and its Ston representation as a value. It's a temporal workaround, while I debug the above error further. >>> I'll keep you posted on the advances and regarding the booklet, I answered you in a direct message. >>> >>> Cheers, >>> >>> Offray >>> On 7/04/22 2:59, John Aspinall wrote: >>>> Hi Offray, >>>> >>>> Regarding the error, Iâm guessing that ReStore doesnât have a table object for your NitterUser class for some reason. Could you try: >>>> >>>> myReStore tableForClass: NitterUser >>>> >>>> â¦and check if this is returning nil? If so thereâs an issue with creating the table for the class; you could try stepping through >>>> >>>> NitterUser reStoreDefinition asTableIn: myReStore >>>> >>>> ...to get an idea of whatâs wrong. >>>> >>>> If this isnât the issue please let me know. >>>> >>>> Regarding the manual, Iâll send this to you by mail. >>>> >>>> Cheers. >>>> >>>> John >>>> >>>> >>>> >>>>> On 6 Apr 2022, at 19:48, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >>>>> >>>>> Thanks Jhon, it definitively helps. >>>>> >>>>> What I did was to extract some important metadata as slots of the Tweet object and made explicit the authorId, which allows me to trace tweets authorship: >>>>> >>>>> === >>>>> Tweet>>class #reStoreDefinition >>>>> ^ super reStoreDefinition >>>>> defineAsID: #id; >>>>> define: #text as: String; >>>>> define: #created as: String; >>>>> define: #authorId as: String; >>>>> define: #timelines as: (Dictionary of: String -> String); yourself >>>>> >>>>> === >>>>> Also I'm going to put in the radar the idea of storing STON strings for metadata residues. >>>>> >>>>> On a related matter, I'm still unable to store properly the NitterUser, which inherits from TwitterUser into SQLite and always get a pre-commit error: "#idDataField was send to nil" when I ran "myNitterUser store". Here is my TwitterUser storing definition: >>>>> >>>>> === >>>>> TwitterUser>>class #reStoreDefinition >>>>> ^ super reStoreDefinition >>>>> defineAsID: #id; >>>>> define: #userName as: String; >>>>> define: #profileImageUrl as: String; >>>>> define: #profileBio as: String; >>>>> "define: #createdAt as: String;" >>>>> yourself. >>>>> >>>>> === >>>>> >>>>> What I'm missing? And more importantly: how can I debug the message, so I can asign the proper non nil object as receiver of #idDataField ? >>>>> >>>>> Finally (for now ;-) ), the ReStore manual has been and important learning resource. Are you the author? And if so, would you be so kind to upload the Word source code to the Documentation/ folder in the repository under a permissive license that allow at least some format changes? We would like to add some table of contents and translate it to other formats, as we have done before with other free/libre cultural works (see [1] [2]). >>>>> >>>>> [1] https://mutabit.com/repos.fossil/datafem <https://mutabit.com/repos.fossil/datafem> >>>>> [2] https://mutabit.com/repos.fossil/mapeda/ <https://mutabit.com/repos.fossil/mapeda/> >>>>> >>>>> Thanks, >>>>> >>>>> Offray >>>>> On 6/04/22 2:52, John Aspinall wrote: >>>>>> Hi Offray, >>>>>> >>>>>> Youâre correct that ReStore canât store that kind of mixed dictionary directly. You could store the entire STON text as one string and reify it on read, though that would mean you canât easily query on the metadata. >>>>>> >>>>>> A compromise solution would be to define objects and slots for the key data youâd need to query on and a STON string for the residue. This could be a better solution anyway as excessive/complex Dictionaries can be a sign that you need to define a new class/classes. For your particular project this would depend on how similar the metadata is between tweets - if thereâs not much commonality then a Dictionary approach may be more appropriate. >>>>>> >>>>>> Hope this helps, >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>>> On 5 Apr 2022, at 20:07, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> First of all, despite of being on a non-directly related matter with my question, congrats of Pharo 10. >>>>>>> >>>>>>> We (as now we have 2 active Smalltalkers in my country... Yay!) are creating a civic tech project with Pharo/Lepiter and we would like to store some Tweet metadata coming from Nitter[1]. As we're dealing with the differences between the official Twitter API and the unofficial Nitter one, we put the metadata we need in a dictionary that has several kinds of objects, from ordered collections to other dictionaries. >>>>>>> [1] https://nitter.net/about <https://nitter.net/about> >>>>>>> Currently if we serialize a Tweet object in STON, we get this: >>>>>>> >>>>>>> Tweet { #created : 'Tue, 05 Apr 2022 12:37:56 GMT', #text : ' >>>>>>> >>>>>>> [ANN] Pharo 10 Released: pharo.org/news/pharo10-releaâ¦ <https://pharo.org/news/pharo10-released>\n', #id : '1511322244353597443', #user : NitterUser { #userName : 'pharoproject', #profileImageUrl : URL [ 'http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo… <http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo…>' ] }, #metadata : { 'queries' : OrderedCollection [ { 'date' : DateAndTime [ '2022-04-05T13:36:58.546011-05:00' ], 'parameters' : 'https://nitter.42l.fr/pharoproject <https://nitter.42l.fr/pharoproject>' } ], 'timelines' : { 'pharoproject' : '1511048498703126529' } } } >>>>>>> As you can see, the metadata slot contains a dictionary with mixed classes of objects. But I read in the ReStore manual[2] (pg 14): >>>>>>> >>>>>>> """ >>>>>>> >>>>>>> Like other collections, the class of elements for both key and value can be any other >>>>>>> persistent class, and will be the same for all elements of that collection (except in the case of >>>>>>> inheritance). >>>>>>> """ >>>>>>> So, is ReStore unable to store metadata dictionaries like the one described in the previous STON code? if this is possible, how can I define it in the Tweet class>>reStoreDefinition? >>>>>>> For the moment, I'm going to create a explicit "timelines" slot to store what was being stored at the #timelines key of the metadata dictionary. But, as metadata increases, instead of moving variables previously inside of a dictionary as explicit slots of an object, I think that having a explicit way of storing dictionaries with different kinds of objects, in contrast with only uniform ones, would be needed (but I don't know if this is in the design scope of ReStore). >>>>>>> >>>>>>> BTW, Lepiter has allow us to build a pretty fluent interface to browser Twitter/Nitter profiles and messages. Here it is how such UI looks for browsing last @pharoproject tweets: >>>>>>> >>>>>>> https://i.imgur.com/bxFze1g.png <https://i.imgur.com/bxFze1g.png> >>>>>>> Any help on how to use ReStore in storing mixed dictionaries is appreciated. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Offray >>>>>> >>>> >>

April 13, 2022

Re: ReStore and storing mixed dictionaries

by Offray Vladimir Luna CÃ¡rdenas

Hi John, Thanks. With the improved error message I was able to pin the cause of error better. The issue was that I was declaring the user picture URL as a ZnURL instead of as a string in the reStoreDefinition, but I was not telling ReStore how to store ZnUrl objects. So I made the returning method to give me a string instead of a ZnUrl, which is kind of counterintuitive for the my model, but returned something that ReStore knew how to serialize. I wonder if there is a way, maybe using something like derived keys, to tell reStoreDefinition: execute this block instead of calling the current method to store the value in the database. So, the #profileImageUrl returns a ZnUrl object inside the image model, but is stored as a string in the database without adding more reStoreDefinition for particular objects (like a ZnUrl). Could be this possible in someway? Am I missing something? The objects storing is advancing now and hopefully we will have results soon to share, instead of troubleshooting (but we'll share both anyway ;-P). Cheers, Offray On 7/04/22 16:19, John Aspinall wrote: > Hi Offray - could you try modifying > SSWReStore>>createProxyForNewObject: as follows: > > ... > Â Â Â table := self tableForClass: anObject class. > "Add this ->â Â table isNil ifTrue: [ self error: 'cannot find table > for ', anObject class name ]. > Â Â Â id := table idDataField ifNotNil: [ :idDataField | idDataField > accessor valueIn: anObject]. > Â Â Â â¦ > > This should change the error message to show the class of object which > doesnât have a valid table. > > Thanks. > > John > > >> On 7 Apr 2022, at 20:29, Offray Vladimir Luna CÃ¡rdenas >> <offray.luna(a)mutabit.com> wrote: >> >> Hi John, >> >> Effectively ReStore didn't was storing the table object for the >> Nitter class. But after following your advice, i'm now able to debug >> both the TwitterUser and the NitterUser and obtain the same result >> (which makes sense as the later is inherited from the former). I >> think that my error was related with the definition of the >> synchronized tables, as I was not includingÂ explicitly the >> NitterUser (as I thought it would suffice with the TwitterUser one). >> Now it looks like this: >> >> === >> ReStore connection: (SSWSQLite3Connection on: privateDatabase fullName); >> Â Â Â connect; >> Â Â Â addClasses: { Tweet. "TwitterUser." NitterUser }; >> Â Â Â synchronizeAllClasses. >> === >> >> Now I can get a non nil idDataField that has the same shape when >> #tableForClass: and "reStoreDefinition asTableIn: ReStore" are send >> to TwitterUser and NitterUser. Despite of that I still get the >> pre-commit error: "#idDataField was send to nil". Here is a >> screenshot of the trace of the error and the idDataFiled seems right >> (or at least equal to the same field inÂ the TwitterUser): >> >> https://i.imgur.com/F3UDC93.png >> >> For the moment, I'm planing to use an extra/temporal >> TwitterStoreHelper object that stores via ReStore/SQLite the objects >> I'm unable to store so far, but as dictionaries of key/value helper >> objects, where the value is just the STON serialization of the object >> (with the inconveniences of not being able to query it properly). For >> example, a 'profiles' dictionary in TwitterStoreHelper would have a >> Twitter/Nitter user id as a key and its Ston representation as a >> value. It's a temporal workaround, while I debug the above error further. >> >> I'll keep you posted on the advances and regarding the booklet, I >> answered you in a direct message. >> >> Cheers, >> >> Offray >> >> On 7/04/22 2:59, John Aspinall wrote: >>> Hi Offray, >>> >>> Regarding the error, Iâm guessing that ReStore doesnât have a table >>> object for your NitterUser class for some reason. Could you try: >>> >>> Â Â myReStore tableForClass: NitterUser >>> >>> â¦and check if this is returning nil? If so thereâs an issue with >>> creating the table for the class; you could try stepping through >>> >>> Â Â NitterUser reStoreDefinition asTableIn: myReStore >>> >>> ...to get an idea of whatâs wrong. >>> >>> If this isnât the issue please let me know. >>> >>> Regarding the manual, Iâll send this to you by mail. >>> >>> Cheers. >>> >>> John >>> >>> >>> >>>> On 6 Apr 2022, at 19:48, Offray Vladimir Luna CÃ¡rdenas >>>> <offray.luna(a)mutabit.com> wrote: >>>> >>>> Thanks Jhon, it definitively helps. >>>> >>>> What I did was to extract some important metadata as slots of the >>>> Tweet object and made explicit the authorId, which allows me to >>>> trace tweets authorship: >>>> >>>> === >>>> Tweet>>class #reStoreDefinition >>>> ^ super reStoreDefinition >>>> Â Â Â defineAsID: #id; >>>> Â Â Â define: #text as: String; >>>> Â Â Â define: #created as: String; >>>> Â Â Â define: #authorId as: String; >>>> Â Â Â define: #timelines as: (Dictionary of: String -> String); yourself >>>> >>>> === >>>> >>>> Also I'm going to put in the radar the idea of storing STON strings >>>> for metadata residues. >>>> >>>> On a related matter, I'm still unable to store properly the >>>> NitterUser, which inherits from TwitterUserÂ into SQLite and always >>>> get a pre-commit error: "#idDataField was send to nil" when I ran >>>> "myNitterUser store". Here is my TwitterUser storing definition: >>>> >>>> === >>>> TwitterUser>>class #reStoreDefinition >>>> >>>> Â Â Â ^ super reStoreDefinition >>>> Â Â Â Â Â Â Â Â Â defineAsID: #id; >>>> Â Â Â Â Â Â Â Â Â define: #userName as: String; >>>> Â Â Â Â Â Â Â Â Â define: #profileImageUrl as: String; >>>> Â Â Â Â Â Â Â Â Â define: #profileBio as: String; >>>> Â Â Â Â Â Â Â Â Â "define: #createdAt as: String;" >>>> Â Â Â Â Â Â Â Â Â yourself. >>>> >>>> === >>>> >>>> What I'm missing? And more importantly: how can I debug the >>>> message, so I can asign the proper non nil object as receiver of >>>> #idDataField ? >>>> >>>> Finally (for now ;-) ), the ReStore manual has been and important >>>> learning resource. Are you the author? And if so, would you be so >>>> kind to upload the Word source code to the Documentation/ folder in >>>> the repository under a permissive license that allow at least some >>>> format changes? We would like to add some table of contents and >>>> translate it to other formats, as we have done before with other >>>> free/libre cultural works (see [1] [2]). >>>> >>>> [1] https://mutabit.com/repos.fossil/datafem >>>> [2] https://mutabit.com/repos.fossil/mapeda/ >>>> >>>> Thanks, >>>> >>>> Offray >>>> >>>> On 6/04/22 2:52, John Aspinall wrote: >>>>> Hi Offray, >>>>> >>>>> Youâre correct that ReStore canât store that kind of mixed >>>>> dictionary directly. You could store the entire STON text as one >>>>> string and reify it on read, though that would mean you canât >>>>> easily query on the metadata. >>>>> >>>>> A compromise solution would be to define objects and slots for the >>>>> key data youâd need to query on and a STON string for the residue. >>>>> This could be a better solution anyway as excessive/complex >>>>> Dictionaries can be a sign that you need to define a new >>>>> class/classes. For your particular project this would depend on >>>>> how similar the metadata is between tweets - if thereâs not much >>>>> commonality then a Dictionary approach may be more appropriate. >>>>> >>>>> Hope this helps, >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>>> On 5 Apr 2022, at 20:07, Offray Vladimir Luna CÃ¡rdenas >>>>>> <offray.luna(a)mutabit.com> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> First of all, despite of being on a non-directly related matter >>>>>> with my question, congrats of Pharo 10. >>>>>> >>>>>> We (as now we have 2 active Smalltalkers in my country... Yay!) >>>>>> are creating a civic tech project with Pharo/Lepiter and we would >>>>>> like to store some Tweet metadata coming from Nitter[1]. As we're >>>>>> dealing with the differences between the official Twitter API and >>>>>> the unofficial Nitter one, we put the metadata we need in a >>>>>> dictionary that has several kinds of objects, from ordered >>>>>> collections to other dictionaries. >>>>>> >>>>>> [1] https://nitter.net/about >>>>>> >>>>>> Currently if we serialize a Tweet object in STON, we get this: >>>>>> >>>>>> Tweet { #created : 'Tue, 05 Apr 2022 12:37:56 GMT', #text : ' >>>>>> >>>>>> [ANN] Pharo 10 Released: pharo.org/news/pharo10-releaâ¦ >>>>>> <https://pharo.org/news/pharo10-released> >>>>>> >>>>>> \n', #id : '1511322244353597443', #user : NitterUser { #userName >>>>>> : 'pharoproject', #profileImageUrl : URL [ >>>>>> 'http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo…' >>>>>> ] }, #metadata : { 'queries' : OrderedCollection [ { 'date' : >>>>>> DateAndTime [ '2022-04-05T13:36:58.546011-05:00' ], 'parameters' >>>>>> : 'https://nitter.42l.fr/pharoproject' } ], 'timelines' : { >>>>>> 'pharoproject' : '1511048498703126529' } } } >>>>>> >>>>>> As you can see, the metadata slot contains a dictionary with >>>>>> mixed classes of objects. But I read in the ReStore manual[2] (pg >>>>>> 14): >>>>>> >>>>>> """ >>>>>> >>>>>> Like other collections, the class of elements for both key and >>>>>> value can be any other >>>>>> persistent class, and will be the same for all elements of that >>>>>> collection (except in the case of >>>>>> inheritance). >>>>>> >>>>>> """ >>>>>> >>>>>> So, is ReStore unable to store metadata dictionaries like the one >>>>>> described in the previous STON code? if this is possible, how can >>>>>> I define it in the Tweet class>>reStoreDefinition? >>>>>> >>>>>> For the moment, I'm going to create a explicit "timelines" slot >>>>>> to store what was being stored at the #timelines key of the >>>>>> metadata dictionary. But, as metadata increases, instead of >>>>>> moving variables previously inside of a dictionary as explicit >>>>>> slots of an object, I think that having a explicit way of storing >>>>>> dictionaries with different kinds of objects, in contrast with >>>>>> only uniform ones, would be needed (but I don't know if this is >>>>>> in the design scope of ReStore). >>>>>> >>>>>> BTW, Lepiter has allow us to build a pretty fluent interface to >>>>>> browser Twitter/Nitter profiles and messages. Here it is how such >>>>>> UI looks for browsing last @pharoproject tweets: >>>>>> >>>>>> https://i.imgur.com/bxFze1g.png >>>>>> >>>>>> Any help on how to use ReStore in storing mixed dictionaries is >>>>>> appreciated. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Offray >>>>>> >>>>> >>> >

April 12, 2022

Re: Intended behaviour of flatten and flatCollect:

by Konrad Hinsen

Hi Kasper, Thanks for your reply! > Sorry, but which version of Pharo are we talking about. Sorry, I forgot to say that I am still using Pharo 9. > I just tried with Pharo 10, which has no flatten method for arrays at Interesting. So I double-checked - and found that the "flatten" in my image actually comes from an add-on package called CollectionExtensions (https://github.com/pharo-contributions/CollectionExtensions/blob/master/src…) So I will complain there :-) > I am not going to comment on naming of such core api methods - they tend to have > a 40 year history of forgotten arguments and random âclean upsâ. I agree, I didn't expect any level of homogeneous naming. Just an agreement between code and documentation. Cheers, Konrad

April 12, 2022

Re: Intended behaviour of flatten and flatCollect:

by Kasper Osterbye

Hi Konrad Sorry, but which version of Pharo are we talking about. I just tried with Pharo 10, which has no flatten method for arrays at all, somewhere along the version I believe the method was renamed to flattened. #(1 #(2 #(a b) 3) 4) flattened >>> #(1 2 #a #b 3 4) as one would expect. flatCollect: does not flatten the collection it is called on, but the result produced by the block #(1 3) flatCollect: [ :e | {e. e * 10} ] >>> #(1 10 3 30), and #(1 #(2 3 #(4 5)) 6) flatCollect: [ :e | {e. e * 10} ] >>> #(1 10 #(2 3 #(4 5)) #(20 30 #(40 50)) 6 60) I am not going to comment on naming of such core api methods - they tend to have a 40 year history of forgotten arguments and random âclean upsâ. Best, Kasper > On 12 Apr 2022, at 11.51, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > Hi everyone, > > I am getting surprising results trying to flatten nested arrays. So I > read the docstrings. And now I understand even less how flatten and > flatCollect are supposed to work. > > flatten says: > > "Recursively collect each non-collection element of the receiver and > its descendant collections. Please note, this implementation > assumes that strings are to be treated as objects rather than as > collection." > > That suggests that > > #(1 2 3) flatten > > should yield #(1 2 3). But it raises an exception, trying to send do: to > an integer. > > A quick look at the code shows that flatten is just flatCollect: [ > :each | each ]. flatCollect: says: > > "Evaluate aBlock for each of the receiver's elements and answer the > list of all resulting values flatten one level. Assumes that aBlock > returns some kind of collection for each element. Equivalent to the > lisp's mapcan" > > "Flatten one level" is different from flatten's "recursively". The > assumption that aBlock returns a collection is also incompatible with > what flatten is supposed to do (and explains my exception). > > I don't find the reference to a Lisp function very helpful. Assuming > "Lisp" means "Common Lisp", this confirms the docstring of flatCollect:, > this confirms the assumption of aBlock returning a collection, and that > only one level of nesting is flattened. > > Since flatCollect does what it says, the problem seems to be in > flatten. Either its docstring or its implementation are wrong. > > Or is it me misunderstanding something? > > Cheers, > Konrad

April 12, 2022

Intended behaviour of flatten and flatCollect:

by Konrad Hinsen

Hi everyone, I am getting surprising results trying to flatten nested arrays. So I read the docstrings. And now I understand even less how flatten and flatCollect are supposed to work. flatten says: "Recursively collect each non-collection element of the receiver and its descendant collections. Please note, this implementation assumes that strings are to be treated as objects rather than as collection." That suggests that #(1 2 3) flatten should yield #(1 2 3). But it raises an exception, trying to send do: to an integer. A quick look at the code shows that flatten is just flatCollect: [ :each | each ]. flatCollect: says: "Evaluate aBlock for each of the receiver's elements and answer the list of all resulting values flatten one level. Assumes that aBlock returns some kind of collection for each element. Equivalent to the lisp's mapcan" "Flatten one level" is different from flatten's "recursively". The assumption that aBlock returns a collection is also incompatible with what flatten is supposed to do (and explains my exception). I don't find the reference to a Lisp function very helpful. Assuming "Lisp" means "Common Lisp", this confirms the docstring of flatCollect:, this confirms the assumption of aBlock returning a collection, and that only one level of nesting is flattened. Since flatCollect does what it says, the problem seems to be in flatten. Either its docstring or its implementation are wrong. Or is it me misunderstanding something? Cheers, Konrad

April 12, 2022

[ANN] Stargate-Consul v4.0.0 [v4.0.0] released!

by Buenos Aires Smalltalk

April 11, 2022

[ANN] Superluminal v4.0.0 [v4.0.0] released!

by Buenos Aires Smalltalk

April 11, 2022

Re: list archive search broken

by Marcus Denker

It is fixed! The provider provider fixed it quickly. Marcus > On 6 Apr 2022, at 09:08, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > Thanks, I will open a Ticket with the provider. > > All in all, I am not that happy with Empathyâ¦ maybe we should start looking for an alternative > hosting provider for the mailing lists. > > Marcus > >> On 6 Apr 2022, at 00:01, PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: >> >> the Empathy search box here: https://lists.pharo.org/empathy/list/pharo-users.lists.pharo.org >> >> Doesn't work. Not sure if thats something everyone knows and is working on or not as I can't search the list to see because doing in the normal way with google also doesn't work or comes up empty.... e.g. googling >> >> >> search box site:https://lists.pharo.org/empathy/list/pharo-users.lists.pharo.org >> >> search box site:https://lists.pharo.org/ >> >> >> >> Thanks >> >> >

April 11, 2022

[ANN] Stargate v8.0.0 [v8.0.0] released!

by Buenos Aires Smalltalk

April 8, 2022

Re: Installing code in a running image

by Davide Varvello

Thanks Tim, that's a valid question, I don't love git so much, we have the code repository versioned on mercurial and we are also trying to have no more that a single baseline in production. On customers' machines should run only a small portion of code so I guess CodeImporter is enough, but I'll feedback the list within some days with my results ;-) Thanks for helpingCheersDavide On Monday, April 4, 2022, 03:31:42 PM GMT+2, Tim Mackinnon <tim(a)testit.works> wrote: From memory - the Excercism project does this too (can't recall if it uses CodeImporter, but it does get source from Exercism and load it into the image). Having said this - are you sure you don't want to have some versioned packed in git that your image can load up when needed? It would add a version control element for you which might make sense. Tim On Mon, 4 Apr 2022, at 2:15 PM, Davide Varvello via Pharo-users wrote: Thanks Markus It seems CodeImporter is the right tool Davide On Monday, April 4, 2022, 11:41:50 AM GMT+2, Marcus Denker <marcus.denker(a)inria.fr> wrote: On 1 Apr 2022, at 18:35, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: Hi Folks! For a customer of mine I want to download a bunch of new code from my webserver and installing it in a running Pharo image, is there a feasible way to do it? Maybe you could just have file-outs on the server and then just load it with CodeImporter? Reading from a URL: ZnClient new get: âsomeURLâ. Loading file outs from a String: CodeImporter class>>#evaluateString: Marcus

April 8, 2022

Re: [ANN] Pharo 10 released!

by vinref＠gmail.com

Looking forward to doing some serious work with Pharo. Thanks for all the hard work that has gone into Pharo over the years. Marcus Denker wrote: > I added an issue tracker entry as I have no idea where/how to fix itâ¦ > > ``` > PharoLauncher: List Pharo10 as stable #11102 > https://github.com/pharo-project/pharo/issues/11102 > ``` This is the page that has to be updated: https://files.pharo.org/pharo-launcher/sources.list Vince

April 8, 2022

Re: ReStore and storing mixed dictionaries

by John Aspinall

Hi Offray - could you try modifying SSWReStore>>createProxyForNewObject: as follows: ... table := self tableForClass: anObject class. "Add this ->â table isNil ifTrue: [ self error: 'cannot find table for ', anObject class name ]. id := table idDataField ifNotNil: [ :idDataField | idDataField accessor valueIn: anObject]. â¦ This should change the error message to show the class of object which doesnât have a valid table. Thanks. John > On 7 Apr 2022, at 20:29, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi John, > > Effectively ReStore didn't was storing the table object for the Nitter class. But after following your advice, i'm now able to debug both the TwitterUser and the NitterUser and obtain the same result (which makes sense as the later is inherited from the former). I think that my error was related with the definition of the synchronized tables, as I was not including explicitly the NitterUser (as I thought it would suffice with the TwitterUser one). Now it looks like this: > > === > ReStore connection: (SSWSQLite3Connection on: privateDatabase fullName); > connect; > addClasses: { Tweet. "TwitterUser." NitterUser }; > synchronizeAllClasses. > === > Now I can get a non nil idDataField that has the same shape when #tableForClass: and "reStoreDefinition asTableIn: ReStore" are send to TwitterUser and NitterUser. Despite of that I still get the pre-commit error: "#idDataField was send to nil". Here is a screenshot of the trace of the error and the idDataFiled seems right (or at least equal to the same field in the TwitterUser): > https://i.imgur.com/F3UDC93.png <https://i.imgur.com/F3UDC93.png> > For the moment, I'm planing to use an extra/temporal TwitterStoreHelper object that stores via ReStore/SQLite the objects I'm unable to store so far, but as dictionaries of key/value helper objects, where the value is just the STON serialization of the object (with the inconveniences of not being able to query it properly). For example, a 'profiles' dictionary in TwitterStoreHelper would have a Twitter/Nitter user id as a key and its Ston representation as a value. It's a temporal workaround, while I debug the above error further. > I'll keep you posted on the advances and regarding the booklet, I answered you in a direct message. > > Cheers, > > Offray > On 7/04/22 2:59, John Aspinall wrote: >> Hi Offray, >> >> Regarding the error, Iâm guessing that ReStore doesnât have a table object for your NitterUser class for some reason. Could you try: >> >> myReStore tableForClass: NitterUser >> >> â¦and check if this is returning nil? If so thereâs an issue with creating the table for the class; you could try stepping through >> >> NitterUser reStoreDefinition asTableIn: myReStore >> >> ...to get an idea of whatâs wrong. >> >> If this isnât the issue please let me know. >> >> Regarding the manual, Iâll send this to you by mail. >> >> Cheers. >> >> John >> >> >> >>> On 6 Apr 2022, at 19:48, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >>> >>> Thanks Jhon, it definitively helps. >>> >>> What I did was to extract some important metadata as slots of the Tweet object and made explicit the authorId, which allows me to trace tweets authorship: >>> >>> === >>> Tweet>>class #reStoreDefinition >>> ^ super reStoreDefinition >>> defineAsID: #id; >>> define: #text as: String; >>> define: #created as: String; >>> define: #authorId as: String; >>> define: #timelines as: (Dictionary of: String -> String); yourself >>> >>> === >>> Also I'm going to put in the radar the idea of storing STON strings for metadata residues. >>> >>> On a related matter, I'm still unable to store properly the NitterUser, which inherits from TwitterUser into SQLite and always get a pre-commit error: "#idDataField was send to nil" when I ran "myNitterUser store". Here is my TwitterUser storing definition: >>> >>> === >>> TwitterUser>>class #reStoreDefinition >>> ^ super reStoreDefinition >>> defineAsID: #id; >>> define: #userName as: String; >>> define: #profileImageUrl as: String; >>> define: #profileBio as: String; >>> "define: #createdAt as: String;" >>> yourself. >>> >>> === >>> >>> What I'm missing? And more importantly: how can I debug the message, so I can asign the proper non nil object as receiver of #idDataField ? >>> >>> Finally (for now ;-) ), the ReStore manual has been and important learning resource. Are you the author? And if so, would you be so kind to upload the Word source code to the Documentation/ folder in the repository under a permissive license that allow at least some format changes? We would like to add some table of contents and translate it to other formats, as we have done before with other free/libre cultural works (see [1] [2]). >>> >>> [1] https://mutabit.com/repos.fossil/datafem <https://mutabit.com/repos.fossil/datafem> >>> [2] https://mutabit.com/repos.fossil/mapeda/ <https://mutabit.com/repos.fossil/mapeda/> >>> >>> Thanks, >>> >>> Offray >>> On 6/04/22 2:52, John Aspinall wrote: >>>> Hi Offray, >>>> >>>> Youâre correct that ReStore canât store that kind of mixed dictionary directly. You could store the entire STON text as one string and reify it on read, though that would mean you canât easily query on the metadata. >>>> >>>> A compromise solution would be to define objects and slots for the key data youâd need to query on and a STON string for the residue. This could be a better solution anyway as excessive/complex Dictionaries can be a sign that you need to define a new class/classes. For your particular project this would depend on how similar the metadata is between tweets - if thereâs not much commonality then a Dictionary approach may be more appropriate. >>>> >>>> Hope this helps, >>>> >>>> John >>>> >>>> >>>> >>>>> On 5 Apr 2022, at 20:07, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> First of all, despite of being on a non-directly related matter with my question, congrats of Pharo 10. >>>>> >>>>> We (as now we have 2 active Smalltalkers in my country... Yay!) are creating a civic tech project with Pharo/Lepiter and we would like to store some Tweet metadata coming from Nitter[1]. As we're dealing with the differences between the official Twitter API and the unofficial Nitter one, we put the metadata we need in a dictionary that has several kinds of objects, from ordered collections to other dictionaries. >>>>> [1] https://nitter.net/about <https://nitter.net/about> >>>>> Currently if we serialize a Tweet object in STON, we get this: >>>>> >>>>> Tweet { #created : 'Tue, 05 Apr 2022 12:37:56 GMT', #text : ' >>>>> >>>>> [ANN] Pharo 10 Released: pharo.org/news/pharo10-releaâ¦ <https://pharo.org/news/pharo10-released>\n', #id : '1511322244353597443', #user : NitterUser { #userName : 'pharoproject', #profileImageUrl : URL [ 'http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo… <http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo…>' ] }, #metadata : { 'queries' : OrderedCollection [ { 'date' : DateAndTime [ '2022-04-05T13:36:58.546011-05:00' ], 'parameters' : 'https://nitter.42l.fr/pharoproject <https://nitter.42l.fr/pharoproject>' } ], 'timelines' : { 'pharoproject' : '1511048498703126529' } } } >>>>> As you can see, the metadata slot contains a dictionary with mixed classes of objects. But I read in the ReStore manual[2] (pg 14): >>>>> >>>>> """ >>>>> >>>>> Like other collections, the class of elements for both key and value can be any other >>>>> persistent class, and will be the same for all elements of that collection (except in the case of >>>>> inheritance). >>>>> """ >>>>> So, is ReStore unable to store metadata dictionaries like the one described in the previous STON code? if this is possible, how can I define it in the Tweet class>>reStoreDefinition? >>>>> For the moment, I'm going to create a explicit "timelines" slot to store what was being stored at the #timelines key of the metadata dictionary. But, as metadata increases, instead of moving variables previously inside of a dictionary as explicit slots of an object, I think that having a explicit way of storing dictionaries with different kinds of objects, in contrast with only uniform ones, would be needed (but I don't know if this is in the design scope of ReStore). >>>>> >>>>> BTW, Lepiter has allow us to build a pretty fluent interface to browser Twitter/Nitter profiles and messages. Here it is how such UI looks for browsing last @pharoproject tweets: >>>>> >>>>> https://i.imgur.com/bxFze1g.png <https://i.imgur.com/bxFze1g.png> >>>>> Any help on how to use ReStore in storing mixed dictionaries is appreciated. >>>>> >>>>> Thanks, >>>>> >>>>> Offray >>>> >>

April 7, 2022

Re: ReStore and storing mixed dictionaries

by Offray Vladimir Luna CÃ¡rdenas

Hi John, Effectively ReStore didn't was storing the table object for the Nitter class. But after following your advice, i'm now able to debug both the TwitterUser and the NitterUser and obtain the same result (which makes sense as the later is inherited from the former). I think that my error was related with the definition of the synchronized tables, as I was not includingÂ explicitly the NitterUser (as I thought it would suffice with the TwitterUser one). Now it looks like this: === ReStore connection: (SSWSQLite3Connection on: privateDatabase fullName); Â Â Â connect; Â Â Â addClasses: { Tweet. "TwitterUser." NitterUser }; Â Â Â synchronizeAllClasses. === Now I can get a non nil idDataField that has the same shape when #tableForClass: and "reStoreDefinition asTableIn: ReStore" are send to TwitterUser and NitterUser. Despite of that I still get the pre-commit error: "#idDataField was send to nil". Here is a screenshot of the trace of the error and the idDataFiled seems right (or at least equal to the same field inÂ the TwitterUser): https://i.imgur.com/F3UDC93.png For the moment, I'm planing to use an extra/temporal TwitterStoreHelper object that stores via ReStore/SQLite the objects I'm unable to store so far, but as dictionaries of key/value helper objects, where the value is just the STON serialization of the object (with the inconveniences of not being able to query it properly). For example, a 'profiles' dictionary in TwitterStoreHelper would have a Twitter/Nitter user id as a key and its Ston representation as a value. It's a temporal workaround, while I debug the above error further. I'll keep you posted on the advances and regarding the booklet, I answered you in a direct message. Cheers, Offray On 7/04/22 2:59, John Aspinall wrote: > Hi Offray, > > Regarding the error, Iâm guessing that ReStore doesnât have a table > object for your NitterUser class for some reason. Could you try: > > Â Â myReStore tableForClass: NitterUser > > â¦and check if this is returning nil? If so thereâs an issue with > creating the table for the class; you could try stepping through > > Â Â NitterUser reStoreDefinition asTableIn: myReStore > > ...to get an idea of whatâs wrong. > > If this isnât the issue please let me know. > > Regarding the manual, Iâll send this to you by mail. > > Cheers. > > John > > > >> On 6 Apr 2022, at 19:48, Offray Vladimir Luna CÃ¡rdenas >> <offray.luna(a)mutabit.com> wrote: >> >> Thanks Jhon, it definitively helps. >> >> What I did was to extract some important metadata as slots of the >> Tweet object and made explicit the authorId, which allows me to trace >> tweets authorship: >> >> === >> Tweet>>class #reStoreDefinition >> ^ super reStoreDefinition >> Â Â Â defineAsID: #id; >> Â Â Â define: #text as: String; >> Â Â Â define: #created as: String; >> Â Â Â define: #authorId as: String; >> Â Â Â define: #timelines as: (Dictionary of: String -> String); yourself >> >> === >> >> Also I'm going to put in the radar the idea of storing STON strings >> for metadata residues. >> >> On a related matter, I'm still unable to store properly the >> NitterUser, which inherits from TwitterUserÂ into SQLite and always >> get a pre-commit error: "#idDataField was send to nil" when I ran >> "myNitterUser store". Here is my TwitterUser storing definition: >> >> === >> TwitterUser>>class #reStoreDefinition >> >> Â Â Â ^ super reStoreDefinition >> Â Â Â Â Â Â Â Â Â defineAsID: #id; >> Â Â Â Â Â Â Â Â Â define: #userName as: String; >> Â Â Â Â Â Â Â Â Â define: #profileImageUrl as: String; >> Â Â Â Â Â Â Â Â Â define: #profileBio as: String; >> Â Â Â Â Â Â Â Â Â "define: #createdAt as: String;" >> Â Â Â Â Â Â Â Â Â yourself. >> >> === >> >> What I'm missing? And more importantly: how can I debug the message, >> so I can asign the proper non nil object as receiver of #idDataField ? >> >> Finally (for now ;-) ), the ReStore manual has been and important >> learning resource. Are you the author? And if so, would you be so >> kind to upload the Word source code to the Documentation/ folder in >> the repository under a permissive license that allow at least some >> format changes? We would like to add some table of contents and >> translate it to other formats, as we have done before with other >> free/libre cultural works (see [1] [2]). >> >> [1] https://mutabit.com/repos.fossil/datafem >> [2] https://mutabit.com/repos.fossil/mapeda/ >> >> Thanks, >> >> Offray >> >> On 6/04/22 2:52, John Aspinall wrote: >>> Hi Offray, >>> >>> Youâre correct that ReStore canât store that kind of mixed >>> dictionary directly. You could store the entire STON text as one >>> string and reify it on read, though that would mean you canât easily >>> query on the metadata. >>> >>> A compromise solution would be to define objects and slots for the >>> key data youâd need to query on and a STON string for the residue. >>> This could be a better solution anyway as excessive/complex >>> Dictionaries can be a sign that you need to define a new >>> class/classes. For your particular project this would depend on how >>> similar the metadata is between tweets - if thereâs not much >>> commonality then a Dictionary approach may be more appropriate. >>> >>> Hope this helps, >>> >>> John >>> >>> >>> >>>> On 5 Apr 2022, at 20:07, Offray Vladimir Luna CÃ¡rdenas >>>> <offray.luna(a)mutabit.com> wrote: >>>> >>>> Hi all, >>>> >>>> First of all, despite of being on a non-directly related matter >>>> with my question, congrats of Pharo 10. >>>> >>>> We (as now we have 2 active Smalltalkers in my country... Yay!) are >>>> creating a civic tech project with Pharo/Lepiter and we would like >>>> to store some Tweet metadata coming from Nitter[1]. As we're >>>> dealing with the differences between the official Twitter API and >>>> the unofficial Nitter one, we put the metadata we need in a >>>> dictionary that has several kinds of objects, from ordered >>>> collections to other dictionaries. >>>> >>>> [1] https://nitter.net/about >>>> >>>> Currently if we serialize a Tweet object in STON, we get this: >>>> >>>> Tweet { #created : 'Tue, 05 Apr 2022 12:37:56 GMT', #text : ' >>>> >>>> [ANN] Pharo 10 Released: pharo.org/news/pharo10-releaâ¦ >>>> <https://pharo.org/news/pharo10-released> >>>> >>>> \n', #id : '1511322244353597443', #user : NitterUser { #userName : >>>> 'pharoproject', #profileImageUrl : URL [ >>>> 'http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo…' >>>> ] }, #metadata : { 'queries' : OrderedCollection [ { 'date' : >>>> DateAndTime [ '2022-04-05T13:36:58.546011-05:00' ], 'parameters' : >>>> 'https://nitter.42l.fr/pharoproject' } ], 'timelines' : { >>>> 'pharoproject' : '1511048498703126529' } } } >>>> >>>> As you can see, the metadata slot contains a dictionary with mixed >>>> classes of objects. But I read in the ReStore manual[2] (pg 14): >>>> >>>> """ >>>> >>>> Like other collections, the class of elements for both key and >>>> value can be any other >>>> persistent class, and will be the same for all elements of that >>>> collection (except in the case of >>>> inheritance). >>>> >>>> """ >>>> >>>> So, is ReStore unable to store metadata dictionaries like the one >>>> described in the previous STON code? if this is possible, how can I >>>> define it in the Tweet class>>reStoreDefinition? >>>> >>>> For the moment, I'm going to create a explicit "timelines" slot to >>>> store what was being stored at the #timelines key of the metadata >>>> dictionary. But, as metadata increases, instead of moving variables >>>> previously inside of a dictionary as explicit slots of an object, I >>>> think that having a explicit way of storing dictionaries with >>>> different kinds of objects, in contrast with only uniform ones, >>>> would be needed (but I don't know if this is in the design scope of >>>> ReStore). >>>> >>>> BTW, Lepiter has allow us to build a pretty fluent interface to >>>> browser Twitter/Nitter profiles and messages. Here it is how such >>>> UI looks for browsing last @pharoproject tweets: >>>> >>>> https://i.imgur.com/bxFze1g.png >>>> >>>> Any help on how to use ReStore in storing mixed dictionaries is >>>> appreciated. >>>> >>>> Thanks, >>>> >>>> Offray >>>> >>> >

April 7, 2022

[ANN] Launchpad v4.3.0 [v4.3.0] released!

by Buenos Aires Smalltalk

April 7, 2022

Re: PharoJS mobile development

by Noury Bouraqadi

Yes indeed, this is a mobile app developed using PharoJS. During tests, the app is run in a web browser. For production, PharoJS exports a JS file which is then fed into the Crodova build process. Noury On Apr 6 2022, at 11:23 pm, danhunfeldz(a)mail.com wrote: > Brain Treats App: Your Daily Dose of Fun Facts! â nootrix (https://nootrix.com/projects/brain-treats-app/) > > > This is a PharoJS app for mobile devices. How do you use Cordova with PharoJS to develop for mobile apps?

April 7, 2022

Re: [ANN] Pharo 10 released!

by Marcus Denker

I added an issue tracker entry as I have no idea where/how to fix itâ¦ PharoLauncher: List Pharo10 as stable #11102 https://github.com/pharo-project/pharo/issues/11102 > On 6 Apr 2022, at 18:48, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > > Congratulations to the new release. That's quite an impressive amount of changes and cleanups. Will the stable version be available in the PharoLauncher soon? > > Cheers, Steffen > > > Esteban Lorenzano schrieb am Dienstag, 5. April 2022 12:39:44 (+02:00): > > Dear Pharo users and dynamic language lovers: > > We have released Pharo version 10 ! > > Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback. > > > > Pharo 10 was a short iteration where we focused mainly on stability and enhancement of the environment : > > â¢ Massive system cleanup > â¢ > â¢ gained speed > â¢ removed dead code > â¢ removed old/deprecated frameworks (Glamour, GTTools, Spec1) > â¢ All Remaining tools written using the deprecated frameworks have been rewritten: Dependency Analyser, Critique Browser, and many other small utilities. > â¢ Modularisation has made a leap, creating correct baselines (project descriptions) for many internal systems, making possible the work and deployment of minimal images. > â¢ Removing support for the old Bytecode sets and embedded blocks simplified the compiler and language core. > â¢ As a result, our image size has been reduced by 10% (from 66MB to 58MB) > â¢ The VM has also improved in several areas: better async I/O support, socket handling, FFI ABI, > Even being a short iteration, we have closed a massive amount of issues: around 600 issues and 700 pull requests. A more extended changelog can be found at https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo100Chang…. > > While the technical improvements are significant, still the most impressive fact is that the new code that got in the main Pharo 10 image was contributed by more than 80 people. > > Pharo is more than code. It is an exciting project involving a great community. > > We thank all the contributors to this release: > > Aaron Bieber, Ackerley Tng, Alban Benmouffek, Alejandra Cossio, Aless Hosry, Alexandre Bergel, Aliaksei Syrel, Alistair Grant, Arturo Zambrano, Asbathou Biyalou-Sama, Axel Marlard, Bastien Degardins, Ben Coman, Bernardo Contreras, Bernhard Pieber, Carlo Teixeira, Carlos Lopez, Carolina Hernandez, Christophe Demarey, Clotilde Toullec, Connor Skennerton, Cyril Ferlicot, Dave Mason, David Wickes, Denis Kudriashov, Eric Gade, Erik Stel, Esteban Lorenzano, Evelyn Cusi Lopez, Ezequiel R. Aguerre, Gabriel Omar Cotelli, Geraldine Galindo, Giovanni Corriga, Guille Polito, Himanshu, Jan Bliznicenko, Jaromir Matas, Kasper Ãsterbye, Kausthub Thekke Madathil, Konrad Hinsen, Kurt Kilpela, Luz Paz, Marco Rimoldi, Marcus Denker, MartÃn Dias, Massimo Nocentini, Max Leske, Maximilian-ignacio Willembrinck Santander, Miguel Campero, Milton Mamani Torres, Nahuel Palumbo, Norbert Hartl, Norm Green, Nour Djihan, Noury Bouraqadi, Oleksandr Zaitsev, Pablo SÃ¡nchez RodrÃguez, Pablo Tesone, Pavel Krivanek, Pierre Misse-Chanabier, Quentin Ducasse, Raffaello Giulietti, Rakshit, Renaud de Villemeur, Rob Sayers, Roland Bernard, Ronie Salgado, Santiago Bragagnolo, Sean DeNigris, Sebastian Jordan Montt, Soufyane Labsari, Stephan Eggermont, Steven Costiou, StÃ©phane Ducasse, Sven Van Caekenberghe, Theo Rogliano, Thomas Dupriez, ThÃ©o Lanord, Torsten Bergmann, Vincent Blondeau. > > > (If you contributed to Pharo 10 development in any way and we missed your name, please send us an email and we will add you). > > Enjoy! > > The Pharo Team > > Discover Pharo: https://pharo.org/features > > Try Pharo: http://pharo.org/download > > Learn Pharo: http://pharo.org/documentation > > -- > Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com herunter.

April 7, 2022

Re: ReStore and storing mixed dictionaries

by John Aspinall

Hi Offray, Regarding the error, Iâm guessing that ReStore doesnât have a table object for your NitterUser class for some reason. Could you try: myReStore tableForClass: NitterUser â¦and check if this is returning nil? If so thereâs an issue with creating the table for the class; you could try stepping through NitterUser reStoreDefinition asTableIn: myReStore ...to get an idea of whatâs wrong. If this isnât the issue please let me know. Regarding the manual, Iâll send this to you by mail. Cheers. John > On 6 Apr 2022, at 19:48, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Thanks Jhon, it definitively helps. > > What I did was to extract some important metadata as slots of the Tweet object and made explicit the authorId, which allows me to trace tweets authorship: > > === > Tweet>>class #reStoreDefinition > ^ super reStoreDefinition > defineAsID: #id; > define: #text as: String; > define: #created as: String; > define: #authorId as: String; > define: #timelines as: (Dictionary of: String -> String); yourself > > === > Also I'm going to put in the radar the idea of storing STON strings for metadata residues. > > On a related matter, I'm still unable to store properly the NitterUser, which inherits from TwitterUser into SQLite and always get a pre-commit error: "#idDataField was send to nil" when I ran "myNitterUser store". Here is my TwitterUser storing definition: > > === > TwitterUser>>class #reStoreDefinition > ^ super reStoreDefinition > defineAsID: #id; > define: #userName as: String; > define: #profileImageUrl as: String; > define: #profileBio as: String; > "define: #createdAt as: String;" > yourself. > > === > > What I'm missing? And more importantly: how can I debug the message, so I can asign the proper non nil object as receiver of #idDataField ? > > Finally (for now ;-) ), the ReStore manual has been and important learning resource. Are you the author? And if so, would you be so kind to upload the Word source code to the Documentation/ folder in the repository under a permissive license that allow at least some format changes? We would like to add some table of contents and translate it to other formats, as we have done before with other free/libre cultural works (see [1] [2]). > > [1] https://mutabit.com/repos.fossil/datafem <https://mutabit.com/repos.fossil/datafem> > [2] https://mutabit.com/repos.fossil/mapeda/ <https://mutabit.com/repos.fossil/mapeda/> > > Thanks, > > Offray > On 6/04/22 2:52, John Aspinall wrote: >> Hi Offray, >> >> Youâre correct that ReStore canât store that kind of mixed dictionary directly. You could store the entire STON text as one string and reify it on read, though that would mean you canât easily query on the metadata. >> >> A compromise solution would be to define objects and slots for the key data youâd need to query on and a STON string for the residue. This could be a better solution anyway as excessive/complex Dictionaries can be a sign that you need to define a new class/classes. For your particular project this would depend on how similar the metadata is between tweets - if thereâs not much commonality then a Dictionary approach may be more appropriate. >> >> Hope this helps, >> >> John >> >> >> >>> On 5 Apr 2022, at 20:07, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >>> >>> Hi all, >>> >>> First of all, despite of being on a non-directly related matter with my question, congrats of Pharo 10. >>> >>> We (as now we have 2 active Smalltalkers in my country... Yay!) are creating a civic tech project with Pharo/Lepiter and we would like to store some Tweet metadata coming from Nitter[1]. As we're dealing with the differences between the official Twitter API and the unofficial Nitter one, we put the metadata we need in a dictionary that has several kinds of objects, from ordered collections to other dictionaries. >>> [1] https://nitter.net/about <https://nitter.net/about> >>> Currently if we serialize a Tweet object in STON, we get this: >>> >>> Tweet { #created : 'Tue, 05 Apr 2022 12:37:56 GMT', #text : ' >>> >>> [ANN] Pharo 10 Released: pharo.org/news/pharo10-releaâ¦ <https://pharo.org/news/pharo10-released>\n', #id : '1511322244353597443', #user : NitterUser { #userName : 'pharoproject', #profileImageUrl : URL [ 'http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo… <http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo…>' ] }, #metadata : { 'queries' : OrderedCollection [ { 'date' : DateAndTime [ '2022-04-05T13:36:58.546011-05:00' ], 'parameters' : 'https://nitter.42l.fr/pharoproject <https://nitter.42l.fr/pharoproject>' } ], 'timelines' : { 'pharoproject' : '1511048498703126529' } } } >>> As you can see, the metadata slot contains a dictionary with mixed classes of objects. But I read in the ReStore manual[2] (pg 14): >>> >>> """ >>> >>> Like other collections, the class of elements for both key and value can be any other >>> persistent class, and will be the same for all elements of that collection (except in the case of >>> inheritance). >>> """ >>> So, is ReStore unable to store metadata dictionaries like the one described in the previous STON code? if this is possible, how can I define it in the Tweet class>>reStoreDefinition? >>> For the moment, I'm going to create a explicit "timelines" slot to store what was being stored at the #timelines key of the metadata dictionary. But, as metadata increases, instead of moving variables previously inside of a dictionary as explicit slots of an object, I think that having a explicit way of storing dictionaries with different kinds of objects, in contrast with only uniform ones, would be needed (but I don't know if this is in the design scope of ReStore). >>> >>> BTW, Lepiter has allow us to build a pretty fluent interface to browser Twitter/Nitter profiles and messages. Here it is how such UI looks for browsing last @pharoproject tweets: >>> >>> https://i.imgur.com/bxFze1g.png <https://i.imgur.com/bxFze1g.png> >>> Any help on how to use ReStore in storing mixed dictionaries is appreciated. >>> >>> Thanks, >>> >>> Offray >>

April 7, 2022

Re: [Pharo-dev] [ANN] Pharo 10 released!

by Esteban Maringolo

Congratulations to the core team and to the whole list of contributors! It's always good to see Smalltalk moving forward. Regards! Esteban A. Maringolo On Tue, Apr 5, 2022 at 7:40 AM Esteban Lorenzano <estebanlm(a)netc.eu> wrote: > Dear Pharo users and dynamic language lovers: > > We have released Pharo version 10 <https://pharo.org/> ! > > Pharo is a pure object-oriented programming language and a powerful > environment, focused on simplicity and immediate feedback. > > > Pharo 10 was a short iteration where we focused mainly on stability and > enhancement of the environment : > > > - Massive system cleanup > - > - gained speed > - removed dead code > - removed old/deprecated frameworks (Glamour, GTTools, Spec1) > - All Remaining tools written using the deprecated frameworks have > been rewritten: Dependency Analyser, Critique Browser, and many other small > utilities. > - Modularisation has made a leap, creating correct baselines (project > descriptions) for many internal systems, making possible the work and > deployment of minimal images. > - Removing support for the old Bytecode sets and embedded blocks > simplified the compiler and language core. > - As a result, our image size has been reduced by 10% (from 66MB to > 58MB) > - The VM has also improved in several areas: better async I/O support, > socket handling, FFI ABI, > > Even being a short iteration, we have closed a massive amount of issues: > around 600 issues and 700 pull requests. A more extended changelog can be > found at > https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo100Chang… > . > > While the technical improvements are significant, still the most > impressive fact is that the new code that got in the main Pharo 10 image > was contributed by more than 80 people. > > Pharo is more than code. It is an exciting project involving a great > community. > > We thank all the contributors to this release: > > Aaron Bieber, Ackerley Tng, Alban Benmouffek, Alejandra Cossio, Aless > Hosry, Alexandre Bergel, Aliaksei Syrel, Alistair Grant, Arturo Zambrano, > Asbathou Biyalou-Sama, Axel Marlard, Bastien Degardins, Ben Coman, Bernardo > Contreras, Bernhard Pieber, Carlo Teixeira, Carlos Lopez, Carolina > Hernandez, Christophe Demarey, Clotilde Toullec, Connor Skennerton, Cyril > Ferlicot, Dave Mason, David Wickes, Denis Kudriashov, Eric Gade, Erik Stel, > Esteban Lorenzano, Evelyn Cusi Lopez, Ezequiel R. Aguerre, Gabriel Omar > Cotelli, Geraldine Galindo, Giovanni Corriga, Guille Polito, Himanshu, Jan > Bliznicenko, Jaromir Matas, Kasper Ãsterbye, Kausthub Thekke Madathil, > Konrad Hinsen, Kurt Kilpela, Luz Paz, Marco Rimoldi, Marcus Denker, MartÃn > Dias, Massimo Nocentini, Max Leske, Maximilian-ignacio Willembrinck > Santander, Miguel Campero, Milton Mamani Torres, Nahuel Palumbo, Norbert > Hartl, Norm Green, Nour Djihan, Noury Bouraqadi, Oleksandr Zaitsev, Pablo > SÃ¡nchez RodrÃguez, Pablo Tesone, Pavel Krivanek, Pierre Misse-Chanabier, > Quentin Ducasse, Raffaello Giulietti, Rakshit, Renaud de Villemeur, Rob > Sayers, Roland Bernard, Ronie Salgado, Santiago Bragagnolo, Sean DeNigris, > Sebastian Jordan Montt, Soufyane Labsari, Stephan Eggermont, Steven > Costiou, StÃ©phane Ducasse, Sven Van Caekenberghe, Theo Rogliano, Thomas > Dupriez, ThÃ©o Lanord, Torsten Bergmann, Vincent Blondeau. > > > (If you contributed to Pharo 10 development in any way and we missed your > name, please send us an email and we will add you). > > Enjoy! > > The Pharo Team > > Discover Pharo: https://pharo.org/features > > Try Pharo: http://pharo.org/download <https://pharo.org/download> > > Learn Pharo: http://pharo.org/documentation > <https://pharo.org/documentation> >

April 6, 2022

PharoJS mobile development

by danhunfeldz＠mail.com

##### [Brain Treats App: Your Daily Dose of Fun Facts! â nootrix](https://nootrix.com/projects/brain-treats-app/) This is a PharoJS app for mobile devices. How do you use Cordova with PharoJS to develop for mobile apps?

April 6, 2022

Re: [ANN] Pharo 10 released!

by Norbert Hartl

Congratulations! Iâm happy that finally the image lost some of the deprecated things. Great work! I could migrate our product today to pharo10 in less than 90 minutes. While all the time went into docker, jenkins and all the infrastructure stuff. Only a single thing I needed to change because my code did not handle Deprecations. I hope we can keep the release cycle as short as this. Norbert > Am 05.04.2022 um 12:41 schrieb Esteban Lorenzano <estebanlm(a)netc.eu>: > > ï»¿ > Dear Pharo users and dynamic language lovers: > > We have released Pharo version 10 ! > > Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback. > > > > Pharo 10 was a short iteration where we focused mainly on stability and enhancement of the environment : > > Massive system cleanup > gained speed > removed dead code > removed old/deprecated frameworks (Glamour, GTTools, Spec1) > All Remaining tools written using the deprecated frameworks have been rewritten: Dependency Analyser, Critique Browser, and many other small utilities. > Modularisation has made a leap, creating correct baselines (project descriptions) for many internal systems, making possible the work and deployment of minimal images. > Removing support for the old Bytecode sets and embedded blocks simplified the compiler and language core. > As a result, our image size has been reduced by 10% (from 66MB to 58MB) > The VM has also improved in several areas: better async I/O support, socket handling, FFI ABI, > Even being a short iteration, we have closed a massive amount of issues: around 600 issues and 700 pull requests. A more extended changelog can be found at https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo100Chang…. > > While the technical improvements are significant, still the most impressive fact is that the new code that got in the main Pharo 10 image was contributed by more than 80 people. > > Pharo is more than code. It is an exciting project involving a great community. > > We thank all the contributors to this release: > > Aaron Bieber, Ackerley Tng, Alban Benmouffek, Alejandra Cossio, Aless Hosry, Alexandre Bergel, Aliaksei Syrel, Alistair Grant, Arturo Zambrano, Asbathou Biyalou-Sama, Axel Marlard, Bastien Degardins, Ben Coman, Bernardo Contreras, Bernhard Pieber, Carlo Teixeira, Carlos Lopez, Carolina Hernandez, Christophe Demarey, Clotilde Toullec, Connor Skennerton, Cyril Ferlicot, Dave Mason, David Wickes, Denis Kudriashov, Eric Gade, Erik Stel, Esteban Lorenzano, Evelyn Cusi Lopez, Ezequiel R. Aguerre, Gabriel Omar Cotelli, Geraldine Galindo, Giovanni Corriga, Guille Polito, Himanshu, Jan Bliznicenko, Jaromir Matas, Kasper Ãsterbye, Kausthub Thekke Madathil, Konrad Hinsen, Kurt Kilpela, Luz Paz, Marco Rimoldi, Marcus Denker, MartÃn Dias, Massimo Nocentini, Max Leske, Maximilian-ignacio Willembrinck Santander, Miguel Campero, Milton Mamani Torres, Nahuel Palumbo, Norbert Hartl, Norm Green, Nour Djihan, Noury Bouraqadi, Oleksandr Zaitsev, Pablo SÃ¡nchez RodrÃguez, Pablo Tesone, Pavel Krivanek, Pierre Misse-Chanabier, Quentin Ducasse, Raffaello Giulietti, Rakshit, Renaud de Villemeur, Rob Sayers, Roland Bernard, Ronie Salgado, Santiago Bragagnolo, Sean DeNigris, Sebastian Jordan Montt, Soufyane Labsari, Stephan Eggermont, Steven Costiou, StÃ©phane Ducasse, Sven Van Caekenberghe, Theo Rogliano, Thomas Dupriez, ThÃ©o Lanord, Torsten Bergmann, Vincent Blondeau. > > > (If you contributed to Pharo 10 development in any way and we missed your name, please send us an email and we will add you). > > Enjoy! > > The Pharo Team > > Discover Pharo: https://pharo.org/features > > Try Pharo: http://pharo.org/download > > Learn Pharo: http://pharo.org/documentation

April 6, 2022

Re: ReStore and storing mixed dictionaries

by Offray Vladimir Luna CÃ¡rdenas

Thanks Jhon, it definitively helps. What I did was to extract some important metadata as slots of the Tweet object and made explicit the authorId, which allows me to trace tweets authorship: === Tweet>>class #reStoreDefinition ^ super reStoreDefinition Â Â Â defineAsID: #id; Â Â Â define: #text as: String; Â Â Â define: #created as: String; Â Â Â define: #authorId as: String; Â Â Â define: #timelines as: (Dictionary of: String -> String); yourself === Also I'm going to put in the radar the idea of storing STON strings for metadata residues. On a related matter, I'm still unable to store properly the NitterUser, which inherits from TwitterUserÂ into SQLite and always get a pre-commit error: "#idDataField was send to nil" when I ran "myNitterUser store". Here is my TwitterUser storing definition: === TwitterUser>>class #reStoreDefinition Â Â Â ^ super reStoreDefinition Â Â Â Â Â Â Â Â Â defineAsID: #id; Â Â Â Â Â Â Â Â Â define: #userName as: String; Â Â Â Â Â Â Â Â Â define: #profileImageUrl as: String; Â Â Â Â Â Â Â Â Â define: #profileBio as: String; Â Â Â Â Â Â Â Â Â "define: #createdAt as: String;" Â Â Â Â Â Â Â Â Â yourself. === What I'm missing? And more importantly: how can I debug the message, so I can asign the proper non nil object as receiver of #idDataField ? Finally (for now ;-) ), the ReStore manual has been and important learning resource. Are you the author? And if so, would you be so kind to upload the Word source code to the Documentation/ folder in the repository under a permissive license that allow at least some format changes? We would like to add some table of contents and translate it to other formats, as we have done before with other free/libre cultural works (see [1] [2]). [1] https://mutabit.com/repos.fossil/datafem [2] https://mutabit.com/repos.fossil/mapeda/ Thanks, Offray On 6/04/22 2:52, John Aspinall wrote: > Hi Offray, > > Youâre correct that ReStore canât store that kind of mixed dictionary > directly. You could store the entire STON text as one string and reify > it on read, though that would mean you canât easily query on the > metadata. > > A compromise solution would be to define objects and slots for the key > data youâd need to query on and a STON string for the residue. This > could be a better solution anyway as excessive/complex Dictionaries > can be a sign that you need to define a new class/classes. For your > particular project this would depend on how similar the metadata is > between tweets - if thereâs not much commonality then a Dictionary > approach may be more appropriate. > > Hope this helps, > > John > > > >> On 5 Apr 2022, at 20:07, Offray Vladimir Luna CÃ¡rdenas >> <offray.luna(a)mutabit.com> wrote: >> >> Hi all, >> >> First of all, despite of being on a non-directly related matter with >> my question, congrats of Pharo 10. >> >> We (as now we have 2 active Smalltalkers in my country... Yay!) are >> creating a civic tech project with Pharo/Lepiter and we would like to >> store some Tweet metadata coming from Nitter[1]. As we're dealing >> with the differences between the official Twitter API and the >> unofficial Nitter one, we put the metadata we need in a dictionary >> that has several kinds of objects, from ordered collections to other >> dictionaries. >> >> [1] https://nitter.net/about >> >> Currently if we serialize a Tweet object in STON, we get this: >> >> Tweet { #created : 'Tue, 05 Apr 2022 12:37:56 GMT', #text : ' >> >> [ANN] Pharo 10 Released: pharo.org/news/pharo10-releaâ¦ >> <https://pharo.org/news/pharo10-released> >> >> \n', #id : '1511322244353597443', #user : NitterUser { #userName : >> 'pharoproject', #profileImageUrl : URL [ >> 'http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo…' >> ] }, #metadata : { 'queries' : OrderedCollection [ { 'date' : >> DateAndTime [ '2022-04-05T13:36:58.546011-05:00' ], 'parameters' : >> 'https://nitter.42l.fr/pharoproject' } ], 'timelines' : { >> 'pharoproject' : '1511048498703126529' } } } >> >> As you can see, the metadata slot contains a dictionary with mixed >> classes of objects. But I read in the ReStore manual[2] (pg 14): >> >> """ >> >> Like other collections, the class of elements for both key and value >> can be any other >> persistent class, and will be the same for all elements of that >> collection (except in the case of >> inheritance). >> >> """ >> >> So, is ReStore unable to store metadata dictionaries like the one >> described in the previous STON code? if this is possible, how can I >> define it in the Tweet class>>reStoreDefinition? >> >> For the moment, I'm going to create a explicit "timelines" slot to >> store what was being stored at the #timelines key of the metadata >> dictionary. But, as metadata increases, instead of moving variables >> previously inside of a dictionary as explicit slots of an object, I >> think that having a explicit way of storing dictionaries with >> different kinds of objects, in contrast with only uniform ones, would >> be needed (but I don't know if this is in the design scope of ReStore). >> >> BTW, Lepiter has allow us to build a pretty fluent interface to >> browser Twitter/Nitter profiles and messages. Here it is how such UI >> looks for browsing last @pharoproject tweets: >> >> https://i.imgur.com/bxFze1g.png >> >> Any help on how to use ReStore in storing mixed dictionaries is >> appreciated. >> >> Thanks, >> >> Offray >> >

April 6, 2022

Re: [ANN] Pharo 10 released!

by Steffen MÃ¤rcker

Congratulations to the new release. That's quite an impressive amount of changes and cleanups. Will the stable version be available in the PharoLauncher soon? Cheers, Steffen Esteban Lorenzano schrieb am Dienstag, 5. April 2022 12:39:44 (+02:00): Dear Pharo users and dynamic language lovers: We have released Pharo version 10 ! Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback. Pharo 10 was a short iteration where we focused mainly on stability and enhancement of the environment : Massive system cleanup gained speed removed dead code removed old/deprecated frameworks (Glamour, GTTools, Spec1) All Remaining tools written using the deprecated frameworks have been rewritten: Dependency Analyser, Critique Browser, and many other small utilities. Modularisation has made a leap, creating correct baselines (project descriptions) for many internal systems, making possible the work and deployment of minimal images. Removing support for the old Bytecode sets and embedded blocks simplified the compiler and language core. As a result, our image size has been reduced by 10% (from 66MB to 58MB) The VM has also improved in several areas: better async I/O support, socket handling, FFI ABI, Even being a short iteration, we have closed a massive amount of issues: around 600 issues and 700 pull requests. A more extended changelog can be found at https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo100Chang…. While the technical improvements are significant, still the most impressive fact is that the new code that got in the main Pharo 10 image was contributed by more than 80 people. Pharo is more than code. It is an exciting project involving a great community. We thank all the contributors to this release: Aaron Bieber, Ackerley Tng, Alban Benmouffek, Alejandra Cossio, Aless Hosry, Alexandre Bergel, Aliaksei Syrel, Alistair Grant, Arturo Zambrano, Asbathou Biyalou-Sama, Axel Marlard, Bastien Degardins, Ben Coman, Bernardo Contreras, Bernhard Pieber, Carlo Teixeira, Carlos Lopez, Carolina Hernandez, Christophe Demarey, Clotilde Toullec, Connor Skennerton, Cyril Ferlicot, Dave Mason, David Wickes, Denis Kudriashov, Eric Gade, Erik Stel, Esteban Lorenzano, Evelyn Cusi Lopez, Ezequiel R. Aguerre, Gabriel Omar Cotelli, Geraldine Galindo, Giovanni Corriga, Guille Polito, Himanshu, Jan Bliznicenko, Jaromir Matas, Kasper Ãsterbye, Kausthub Thekke Madathil, Konrad Hinsen, Kurt Kilpela, Luz Paz, Marco Rimoldi, Marcus Denker, MartÃn Dias, Massimo Nocentini, Max Leske, Maximilian-ignacio Willembrinck Santander, Miguel Campero, Milton Mamani Torres, Nahuel Palumbo, Norbert Hartl, Norm Green, Nour Djihan, Noury Bouraqadi, Oleksandr Zaitsev, Pablo SÃ¡nchez RodrÃguez, Pablo Tesone, Pavel Krivanek, Pierre Misse-Chanabier, Quentin Ducasse, Raffaello Giulietti, Rakshit, Renaud de Villemeur, Rob Sayers, Roland Bernard, Ronie Salgado, Santiago Bragagnolo, Sean DeNigris, Sebastian Jordan Montt, Soufyane Labsari, Stephan Eggermont, Steven Costiou, StÃ©phane Ducasse, Sven Van Caekenberghe, Theo Rogliano, Thomas Dupriez, ThÃ©o Lanord, Torsten Bergmann, Vincent Blondeau. (If you contributed to Pharo 10 development in any way and we missed your name, please send us an email and we will add you). Enjoy! The Pharo Team Discover Pharo: https://pharo.org/features Try Pharo: http://pharo.org/download Learn Pharo: http://pharo.org/documentation -- Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com herunter.

April 6, 2022

Re: [ANN] Hyperspace v3.1.0 [v3.1.0] released!

by Gabriel Cotelli

The images showing the inspector extensions got lost in the announcement mail but can be seen here: https://github.com/ba-st/Hyperspace/releases/tag/v3.1.0 On Wed, Apr 6, 2022 at 9:58 AM Buenos Aires Smalltalk <github(a)fast.org.ar> wrote: > Hyperspace <https://github.com/ba-st/Hyperspace>, building blocks for > Internet technologies on top of Zinc HTTP Components reached it's v3.1.0 > <https://github.com/ba-st/Hyperspace/releases/tag/v3.1.0> version. > What's Changed > > - Added Pharo 10 support > - Added inspector extensions in Pharo 10 for HTTPError exceptions, > HTTP requests/responses. > > HTTPClientError inspector > > [image: image] > ZnResponse inspectors > > [image: image] [image: image] [image: image] [image: image] [image: image] > > *Full Changelog*: https://github.com/ba-st/Hyperspace/compare/v3.0.0 > â¦v3.1.0 > > Regards, > > The Buenos Aires Smalltalk team >

April 6, 2022

[ANN] Hyperspace v3.1.0 [v3.1.0] released!

by Buenos Aires Smalltalk

April 6, 2022