- Pharo-users - lists.pharo.org

Agile Artificial Intelligence

by StÃ©phane Ducasse

We are happy to announce that the book of A. Bergel is out https://www.apress.com/gp/book/9781484253830 Agile Artificial Intelligence in Pharo Implementing Neural Networks, Genetic Algorithms, and Neuroevolution Cover classical algorithms commonly used as artificial intelligence techniques and program agile artificial intelligence applications using Pharo in this book. It takes a practical approach by presenting the implementation details to illustrate the numerous concepts it explainâ¦ https://www.amazon.com/Agile-Artificial-Intelligence-Pharo-Neuroevolution/d… As a book author I want to congratulate alex for this effort. S. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

July 1, 2020

Re: [Pharo-users] I think I've discovered an error in the later v9 builds

by StÃ©phane Ducasse

Thanks can you enter a bug entry in the spec project? S. > On 1 Jul 2020, at 16:58, Russ Whaley <whaley.russ(a)gmail.com> wrote: > > (Overall, this error does not occur in v8 - even the latest snapshot.1140. It did not exist in the v9 image from February - I don't know how to tell what build it is. But the latest Official Distribution for v9 and the latest snapshot.840 - the following error occurs:). > > This error appears to be around the transmitTo: within SpPresenterWithModel>>connectPresenters. I haven't been able to (yet) trace why, but the debug message is in the 2nd 'transform:' below -- erroring saying that 'each' is nil - and doesn't understand the #method2 message. > > Here is the scenario: > > (aSpTablePresenter(1) transmitTo: aSpTablePresenter(2)) > transform: [ :each | ((each #method asOrderedCollection ) sorted: #title ascending ) ]. > > "transmit aSpTablePresenter(2) to aSpTablePresenter(3)" > (aSpTablePresenter(2) transmitTo: aSpTablePresenter(3)) > transform: [ :each | ((each #method2 asOrderedCollection) sorted: #number ascending )]. > > The UI populates just fine - when I click a row in the first aSpTablePresenter(1) - it fills the 2nd aSpTablePresenter(2), but it looks like the code above attempts to do the 2nd transmitTo: to populate aSpTablePresenter(3) and is trying to do so without data from aSpTablePresenter(2) - there could be a number of reasons for this. > > Behavior-wise, I would prefer that SpTablePresenters default to a first row selected and populate (transmitTo:) to each of their SpTablePresenters in kind (defaulting to first row, then transmitTo: the next tablePresenter). > > Through the Inspector, all three SpTablePresenters have their lists populated - and the UI shows these lists - even after punching through error. > > Another observable - when I click on column headers to sort, the transmitTo:'s get called again and also error out - even the first transmitTo:... could be one simple change will correct all these anomalies. > > I will try and mock-up a simpler version to share. Please let me know if you have any questions or items I should specifically include. > > Thanks! > Russ > > -- > Russ Whaley > whaley.russ(a)gmail.com <mailto:whaley.russ@gmail.com> -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

July 1, 2020

I think I've discovered an error in the later v9 builds

by Russ Whaley

(Overall, this error does not occur in v8 - even the latest snapshot.1140. It did not exist in the v9 image from February - I don't know how to tell what build it is. But the latest Official Distribution for v9 and the latest snapshot.840 - the following error occurs:). This error appears to be around the transmitTo: within SpPresenterWithModel>>connectPresenters. I haven't been able to (yet) trace why, but the debug message is in the 2nd 'transform:' below -- erroring saying that 'each' is nil - and doesn't understand the #method2 message. Here is the scenario: (aSpTablePresenter(1) transmitTo: aSpTablePresenter(2)) transform: [ :each | ((each #method asOrderedCollection ) sorted: #title ascending ) ]. "transmit aSpTablePresenter(2) to aSpTablePresenter(3)" (aSpTablePresenter(2) transmitTo: aSpTablePresenter(3)) transform: [ :each | ((*each #method2* asOrderedCollection) sorted: #number ascending )]. The UI populates just fine - when I click a row in the first aSpTablePresenter(1) - it fills the 2nd aSpTablePresenter(2), but it looks like the code above attempts to do the 2nd transmitTo: to populate aSpTablePresenter(3) and is trying to do so without data from aSpTablePresenter(2) - there could be a number of reasons for this. Behavior-wise, I would prefer that SpTablePresenters default to a first row selected and populate (transmitTo:) to each of their SpTablePresenters in kind (defaulting to first row, then transmitTo: the next tablePresenter). Through the Inspector, all three SpTablePresenters have their lists populated - and the UI shows these lists - even after punching through error. Another observable - when I click on column headers to sort, the transmitTo:'s get called again and also error out - even the first transmitTo:... could be one simple change will correct all these anomalies. I will try and mock-up a simpler version to share. Please let me know if you have any questions or items I should specifically include. Thanks! Russ -- Russ Whaley whaley.russ(a)gmail.com

July 1, 2020

Re: [Pharo-users] STON question

by Esteban Maringolo

Thank you Sven! This is really convenient. SortFunctions are really cool. Esteban A. Maringolo On Tue, Jun 30, 2020 at 6:06 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Stef, > > With the following commit https://github.com/svenvc/ston/commit/3565d388172b76c180454575d4c2f71019f13… > > there is now basic support for SortCollections using SortFunctions. > > All of the following can now be serialised and materialised by STON (see #testSortedCollections): > > SortedCollection new. > SortedCollection new: 0. > > #(5 3 7 2 1 4 10 9 8 6) asSortedCollection. > > #(5 3 7 2 1 4 10 9 8 6) asSortedCollection: #yourself ascending. > #(5 3 7 2 1 4 10 9 8 6) asSortedCollection: #yourself descending. > > #('****' '*' '*****' '**' '***') asSortedCollection: #size ascending. > #('****' '*' '*****' '**' '***') asSortedCollection: #size descending. > > #(5 3 7 2 1 4 10 nil 9 8 6) asSortedCollection: #yourself ascending undefinedFirst. > #(5 3 7 2 1 4 10 nil 9 8 6) asSortedCollection: #yourself ascending reversed undefinedLast. > > I think this trick covers a large set of SortedCollection use cases avoiding blocks by using SortFunctions. > > This technique could also be used to replace other block usages elsewhere. > > To answer your original question: yes we could add this to the documentation (although right now it is very new and unproven). > > Regards, > > Sven > > > On 28 Jun 2020, at 12:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > > > > > >> On 27 Jun 2020, at 16:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> Hi Russ, > >> > >> The limitation of STON not being capable of serialising a block closure still stands and will probably not change very soon (it open up the whole language to be written out). > >> > >> You can work around this though, with sort functions for example. > >> > >> Here is an example: > >> > >> { 1->#one. 3->#three. 2->#two } sorted: (STON fromString: (STON toStringPretty: #key ascending)). > >> > >> SortFunctions are really cool BTW (they can handles nil values elegantly). > >> > >> Sven > > > > Sven do you think that we should have a little section on this question in STON chapter. > > > > S > >

July 1, 2020

Re: [Pharo-users] Zinc HTTP Components, P3, MQTT and NeoUniversalBinaryJSON now require Pharo 7.0.5 as minimum version

by StÃ©phane Ducasse

Thanks Sven. > On 1 Jul 2020, at 13:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > Here is a little heads up: in order to support Pharo 9, I made a change in a couple of my libraries/frameworks (using Integer #byteAt: instead of #digitAt:) that requires Pharo 7.0.5 (released recently) as minimum version. > > https://github.com/svenvc/zinc > https://github.com/svenvc/P3 > https://github.com/svenvc/mqtt > https://github.com/svenvc/NeoUniversalBinaryJSON > > If you are unable or unwilling to upgrade, you can patch this by adding the follow alias to Pharo versions < 7.0.5: > > Integer>>#byteAt: index > ^ self digitAt: index > > Sven > > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

July 1, 2020

Zinc HTTP Components, P3, MQTT and NeoUniversalBinaryJSON now require Pharo 7.0.5 as minimum version

by Sven Van Caekenberghe

Hi, Here is a little heads up: in order to support Pharo 9, I made a change in a couple of my libraries/frameworks (using Integer #byteAt: instead of #digitAt:) that requires Pharo 7.0.5 (released recently) as minimum version. https://github.com/svenvc/zinc https://github.com/svenvc/P3 https://github.com/svenvc/mqtt https://github.com/svenvc/NeoUniversalBinaryJSON If you are unable or unwilling to upgrade, you can patch this by adding the follow alias to Pharo versions < 7.0.5: Integer>>#byteAt: index ^ self digitAt: index Sven

July 1, 2020

Re: [Pharo-users] STON question

by StÃ©phane Ducasse

Ok I will allocate some time to produce a booklet on ston :). S. > On 30 Jun 2020, at 23:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Stef, > > With the following commit https://github.com/svenvc/ston/commit/3565d388172b76c180454575d4c2f71019f13… > > there is now basic support for SortCollections using SortFunctions. > > All of the following can now be serialised and materialised by STON (see #testSortedCollections): > > SortedCollection new. > SortedCollection new: 0. > > #(5 3 7 2 1 4 10 9 8 6) asSortedCollection. > > #(5 3 7 2 1 4 10 9 8 6) asSortedCollection: #yourself ascending. > #(5 3 7 2 1 4 10 9 8 6) asSortedCollection: #yourself descending. > > #('****' '*' '*****' '**' '***') asSortedCollection: #size ascending. > #('****' '*' '*****' '**' '***') asSortedCollection: #size descending. > > #(5 3 7 2 1 4 10 nil 9 8 6) asSortedCollection: #yourself ascending undefinedFirst. > #(5 3 7 2 1 4 10 nil 9 8 6) asSortedCollection: #yourself ascending reversed undefinedLast. > > I think this trick covers a large set of SortedCollection use cases avoiding blocks by using SortFunctions. > > This technique could also be used to replace other block usages elsewhere. > > To answer your original question: yes we could add this to the documentation (although right now it is very new and unproven). > > Regards, > > Sven > >> On 28 Jun 2020, at 12:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> >> >>> On 27 Jun 2020, at 16:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Hi Russ, >>> >>> The limitation of STON not being capable of serialising a block closure still stands and will probably not change very soon (it open up the whole language to be written out). >>> >>> You can work around this though, with sort functions for example. >>> >>> Here is an example: >>> >>> { 1->#one. 3->#three. 2->#two } sorted: (STON fromString: (STON toStringPretty: #key ascending)). >>> >>> SortFunctions are really cool BTW (they can handles nil values elegantly). >>> >>> Sven >> >> Sven do you think that we should have a little section on this question in STON chapter. >> >> S > > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

July 1, 2020

Re: [Pharo-users] [Esug-list] [Glass] Webminar about VA Smalltalk new OS Process Framework

by Luc Fabresse

Hi Mariano, Thank you for the info. Cheers, #Luc Le mar. 30 juin 2020 Ã 16:55, Mariano Martinez Peck <marianopeck(a)gmail.com> a Ã©crit : > Yes to both questions :) > > On Tue, Jun 30, 2020 at 11:05 AM Damien Pollet <damien.pollet(a)gmail.com> > wrote: > >> Will this be recorded for watching later ? Maybe posted to youtube ? >> >> On Tue, 30 Jun 2020 at 15:25, Mariano Martinez Peck via Glass < >> glass(a)lists.gemtalksystems.com> wrote: >> >>> Greetings all, >>> >>> Some time ago, I had the pleasure and privilege of being sponsored by >>> the Pharo Consortium to implement OSSubprocess. Because of that work, I >>> quickly realized that a new OS process framework created by Instantiations >>> was quite advanced and unlike anything I had seen before. If you are able, >>> I would highly recommend that you attend the technology preview of this >>> framework coming to VAST 2021: >>> >>> Seth Berman will be presenting, registration here: >>> https://attendee.gotowebinar.com/register/7491754880594201356 >>> >>> We hope the community can attend and we look forward to your feedback >>> and questions during the event's Q&A session. >>> >>> Best regards, >>> >>> -- >>> Mariano Martinez Peck >>> Email: marianopeck(a)gmail.com >>> Twitter: @MartinezPeck >>> LinkedIn: www.linkedin.com/in/mariano-martinez-peck >>> <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> >>> Blog: https://marianopeck.wordpress.com/ >>> _______________________________________________ >>> Glass mailing list >>> Glass(a)lists.gemtalksystems.com >>> https://lists.gemtalksystems.com/mailman/listinfo/glass >>> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > > > -- > Mariano Martinez Peck > Email: marianopeck(a)gmail.com > Twitter: @MartinezPeck > LinkedIn: www.linkedin.com/in/mariano-martinez-peck > <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> > Blog: https://marianopeck.wordpress.com/ > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >

July 1, 2020

Re: [Pharo-users] [ANN] Launchpad v3.0.0 [v3.0.0] released!

by Gabriel Cotelli

I've fixed the links. Thanks for reporting Hernan. We renamed the class and forgot to update the docs. Should be fixed now. On Tue, Jun 30, 2020 at 6:28 PM HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Hi guys, > > First thank you for sharing this. Seems to be very useful. > I found the Example Handler is missing in the How To: > https://github.com/ba-st/Launchpad/blob/release-candidate/docs/HowTo.md > > Should I look somewhere else? > > Cheers, > > HernÃ¡n > > El lun., 29 jun. 2020 a las 14:16, Buenos Aires Smalltalk (< > github(a)fast.org.ar>) escribiÃ³: > >> Launchpad <https://github.com/ba-st/Launchpad>, the entrypoint for your >> Pharo application reached it's v3.0.0 >> <https://github.com/ba-st/Launchpad/releases/tag/v3.0.0> version. >> Breaking Changes >> >> - Handlers must now subclass LaunchpadCommandLineHandler instead of >> ApplicationStarterCommandLineHandler >> - Pharo 6.1 is no longer supported >> >> Non breaking changes >> >> - PR #7 Fix --suspend-ui flag when the image is already headless >> - Added Pharo 8 to the build matrix >> - Use GitHubActions and CodeCov >> >> Regards, >> >> The Buenos Aires Smalltalk team >> >

July 1, 2020

Re: [Pharo-users] [ANN] Launchpad v3.0.0 [v3.0.0] released!

by HernÃ¡n Morales Durand

Hi guys, First thank you for sharing this. Seems to be very useful. I found the Example Handler is missing in the How To: https://github.com/ba-st/Launchpad/blob/release-candidate/docs/HowTo.md Should I look somewhere else? Cheers, HernÃ¡n El lun., 29 jun. 2020 a las 14:16, Buenos Aires Smalltalk (< github(a)fast.org.ar>) escribiÃ³: > Launchpad <https://github.com/ba-st/Launchpad>, the entrypoint for your > Pharo application reached it's v3.0.0 > <https://github.com/ba-st/Launchpad/releases/tag/v3.0.0> version. > Breaking Changes > > - Handlers must now subclass LaunchpadCommandLineHandler instead of > ApplicationStarterCommandLineHandler > - Pharo 6.1 is no longer supported > > Non breaking changes > > - PR #7 Fix --suspend-ui flag when the image is already headless > - Added Pharo 8 to the build matrix > - Use GitHubActions and CodeCov > > Regards, > > The Buenos Aires Smalltalk team >

June 30, 2020