July 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 8. Epicea seems to be turned off. how do I get it working again?

by Paul DeBruicker

Hi ! I just figured it out. I must've ran EpMonitor current disable And forgot all about doing that. Everything works how it should. My fault. Thanks StÃ©phane Ducasse wrote > Hi Paul > > I do not know. > This is the first time I hear that epicea blocks. > If you close your image and goes to changes you will be able to reopen > epicea and check your code. > At start up epicea just check if there was a new session but besides that > there is nothing > different than opening it. > > S. > >> On 30 May 2020, at 17:05, PAUL DEBRUICKER < > pdebruic@ > > wrote: >> >> Hi- >> >> I had an image lock up so I "Force quit" it from the apple menu. >> >> When I check "Code Changes" its most recent changes are from 9 days ago. >> My most recent save was a few hours ago & I was able to restore the >> missing code between the save & now by dropping the changes file in the >> image. >> >> How do I double check and get epicea running again in this image? >> >> Thanks >> >> >> > <Screen Shot 2020-05-29 at 4.44.51 PM.png> > -------------------------------------------- > 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 -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 1, 2020

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

by Russ Whaley

I'd be happy to, but um... I don't know how/where (color me embarrassed...). Can you point me in the right direction? I've not submitted a bug report before. I've created a sample Class, App, & Presenter that demonstrates the error consistently. I was kindof hoping when I created this example I would find it was something in my code... I'll attach the fileout here but will also include it in the bug report. Also attached are the screenshots before and after I clicked on the first row. Is there a way to tell the build number of an image I'm using? I'd like to go back to a fresh image of the image I'm using... it has inflated to over 350MB and I'd like to start fresh with an image that doesn't have this defect. If I can get hold of the build of the image I'm using, that would be great. Thanks, Russ On Wed, Jul 1, 2020 at 1:42 PM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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 > > > -------------------------------------------- > 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 > > -- Russ Whaley whaley.russ(a)gmail.com

July 1, 2020

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