August 2019 - Pharo-users - lists.pharo.org

R: VW vs Pharo Performance

by Lorenzo Schiavina

Ciao Giorgio, vedo che sei sempre sulla braccia; perchÃ© non ci sentiamo per mettere insieme due vecchiaie? Lorenzo Da: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] Per conto di giorgio ferraris Inviato: sabato 31 agosto 2019 17:48 A: Any question about pharo is welcome Oggetto: Re: [Pharo-users] VW vs Pharo Performance hello, Test seems old, both virtual machines (VW and Pharo) have upgraded in the meantime. VW has always been faster that Pharo for what I know, up to recent time. Recently Pharo changed the vm technology so now it should be much faster, but I don'r know is faster that VW , so it would be nice to have a up to date comparison. Related to Matrix, this is a nice way to have many smalltalk images running in parallel, but it doesn't seems the case of this test. It requires a specific way of writing the code, it is not as automatic as defining a piece of code "parallel". The thread model of VW and Pharo are still the same, green thread and (almost) single core systems ciao giorgio On Sat, Aug 31, 2019 at 2:37 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 31 Aug 2019, at 13:27, Richard Kenneth Eng <horrido.hobbies(a)gmail.com> wrote: > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/vw-phar… > > Is VisualWorks really faster than Pharo? Why??? The Pharo code is single threaded, single core, while the VW code uses something called MatriX.VirtualMachines to create workers that run on multiple cores. Presumably that makes a huge difference. Also, such parallelism is easy for benchmarks that can be split in independent tasks, real world code is a completely different story. Basically, this is not the same code that is being compared.

Aug. 31, 2019

Re: [Pharo-users] VW vs Pharo Performance

by giorgio ferraris

hello, Test seems old, both virtual machines (VW and Pharo) have upgraded in the meantime. VW has always been faster that Pharo for what I know, up to recent time. Recently Pharo changed the vm technology so now it should be much faster, but I don'r know is faster that VW , so it would be nice to have a up to date comparison. Related to Matrix, this is a nice way to have many smalltalk images running in parallel, but it doesn't seems the case of this test. It requires a specific way of writing the code, it is not as automatic as defining a piece of code "parallel". The thread model of VW and Pharo are still the same, green thread and (almost) single core systems ciao giorgio On Sat, Aug 31, 2019 at 2:37 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 31 Aug 2019, at 13:27, Richard Kenneth Eng <horrido.hobbies(a)gmail.com> > wrote: > > > > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/vw-phar… > > > > Is VisualWorks really faster than Pharo? Why??? > > The Pharo code is single threaded, single core, while the VW code uses > something called MatriX.VirtualMachines to create workers that run on > multiple cores. > > Presumably that makes a huge difference. > > Also, such parallelism is easy for benchmarks that can be split in > independent tasks, real world code is a completely different story. > > Basically, this is not the same code that is being compared. > > >

Aug. 31, 2019

Re: [Pharo-users] VW vs Pharo Performance

by Sven Van Caekenberghe

> On 31 Aug 2019, at 13:27, Richard Kenneth Eng <horrido.hobbies(a)gmail.com> wrote: > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/vw-phar… > > Is VisualWorks really faster than Pharo? Why??? The Pharo code is single threaded, single core, while the VW code uses something called MatriX.VirtualMachines to create workers that run on multiple cores. Presumably that makes a huge difference. Also, such parallelism is easy for benchmarks that can be split in independent tasks, real world code is a completely different story. Basically, this is not the same code that is being compared.

Aug. 31, 2019

VW vs Pharo Performance

by Richard Kenneth Eng

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/vw-phar… Is VisualWorks really faster than Pharo? Why???

Aug. 31, 2019

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

by Kasper Ãsterbye

I always like to find a way not to make the choice. #(1 2) allButFirst: 3 ifInsufficient: [â¦] allButFirst: N ^self allButFirst: N ifInsufficent: [ âfight about this"]. â Kasper On 30 August 2019 at 12.28.14, Cyril Ferlicot (cyril.ferlicot(a)gmail.com) wrote: On Fri 30 Aug 2019 at 09:34, Julien <julien.delplanque(a)inria.fr> wrote: > Hello, > > I opened that issue: https://github.com/pharo-project/pharo/issues/4442 > > And I think to fix it we need to actually discuss about what we want. > > #allButFirst: behaves differently depending on the actual type of > sequenceable collection when argument is greater than collection size. > > For instance: > > #(1 2) allButFirst: 3. "PrimitiveFailed signaled" > (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled" > (OrderedCollection with: 1 with: 2) allButFirst: 3. "an > OrderedCollection() Â» > > The question is then, who is right? > > Should #allButFirst: with an argument greater than the collection size > raise an error > > Or > > Should #allButFirst: with an argument greater than the collection size > returns an empty collection ? > > I asked a few people about it @ ESUG and it appears that the expected > behaviour from #allButFirst: is not the same to all people. > > We need to decide so we improve consistence of collections. > > And then, we need to document that with a test :-). > Hi, I was one of the person who discussed this with Julien at ESUG and IMO it should launch an error. While working on complexe models, errors in such cases are really really really helpful to find bugs. Errors such as SubscriptOutOfBound or NotFound help me a lot to find bugs and sometimes without this kind of methods it could have take me days to find the problem (and itâs only in the case I know there is a bug). > Cheers. > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> > Villeneuve > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> > d'Ascq > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > > -- Cyril Ferlicot https://ferlicot.fr

Aug. 30, 2019

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

by Herby VojÄÃk

On 30. 8. 2019 11:56, Ben Coman wrote: > > > On Fri, 30 Aug 2019 at 15:34, Julien <julien.delplanque(a)inria.fr > <mailto:julien.delplanque@inria.fr>> wrote: > > Hello, > > I opened that issue: https://github.com/pharo-project/pharo/issues/4442 > > And I think to fix it we need to actually discuss about what we want. > > #allButFirst: behaves differently depending on the actual type of > sequenceable collection when argument is greater than collection size. > > For instance: > > #(1 2) allButFirst: 3. Â "PrimitiveFailed signaled" > (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled" > (OrderedCollection with: 1 with: 2) allButFirst: 3. Â "an > OrderedCollection()Â Â» > > The question is then, who is right? > > > Its worthwhile to at least survey other Smalltalks. > For Visualworks... > Â Â Â #(1 2) allButFirst: 3.Â "==> #()" > Â Â Â Â (OrderedCollection with: 1 with: 2) allButFirst: 3.Â Â "==> > OrderedCollection ()" > Â Â Â Â (LinkedList with: Link new with: Link new ) allButFirst: 3. > "raises an error Subscription out of bounds error" > and also... > Â Â Â Â (LinkedList with: Link new with: Link new ) allButFirst: 2. > "raises an error Subscription out of bounds error" > > I feel that proceeding-without-iterating is nicer than > showing-an-application-error. > It provides the opportunity to not-check the number elements or wrapping > error handling around it - i.e. less code if its not important. That's what I think as well. > If its important not to exceed the number of elements, then that check > can be explicitly coded. > > cheers -ben

Aug. 30, 2019

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

by Cyril Ferlicot

On Fri 30 Aug 2019 at 09:34, Julien <julien.delplanque(a)inria.fr> wrote: > Hello, > > I opened that issue: https://github.com/pharo-project/pharo/issues/4442 > > And I think to fix it we need to actually discuss about what we want. > > #allButFirst: behaves differently depending on the actual type of > sequenceable collection when argument is greater than collection size. > > For instance: > > #(1 2) allButFirst: 3. "PrimitiveFailed signaled" > (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled" > (OrderedCollection with: 1 with: 2) allButFirst: 3. "an > OrderedCollection() Â» > > The question is then, who is right? > > Should #allButFirst: with an argument greater than the collection size > raise an error > > Or > > Should #allButFirst: with an argument greater than the collection size > returns an empty collection ? > > I asked a few people about it @ ESUG and it appears that the expected > behaviour from #allButFirst: is not the same to all people. > > We need to decide so we improve consistence of collections. > > And then, we need to document that with a test :-). > Hi, I was one of the person who discussed this with Julien at ESUG and IMO it should launch an error. While working on complexe models, errors in such cases are really really really helpful to find bugs. Errors such as SubscriptOutOfBound or NotFound help me a lot to find bugs and sometimes without this kind of methods it could have take me days to find the problem (and itâs only in the case I know there is a bug). > Cheers. > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> > Villeneuve > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> > d'Ascq > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > > -- Cyril Ferlicot https://ferlicot.fr

Aug. 30, 2019

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

by Ben Coman

On Fri, 30 Aug 2019 at 15:34, Julien <julien.delplanque(a)inria.fr> wrote: > Hello, > > I opened that issue: https://github.com/pharo-project/pharo/issues/4442 > > And I think to fix it we need to actually discuss about what we want. > > #allButFirst: behaves differently depending on the actual type of > sequenceable collection when argument is greater than collection size. > > For instance: > > #(1 2) allButFirst: 3. "PrimitiveFailed signaled" > (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled" > (OrderedCollection with: 1 with: 2) allButFirst: 3. "an > OrderedCollection() Â» > > The question is then, who is right? > Its worthwhile to at least survey other Smalltalks. For Visualworks... #(1 2) allButFirst: 3. "==> #()" (OrderedCollection with: 1 with: 2) allButFirst: 3. "==> OrderedCollection ()" (LinkedList with: Link new with: Link new ) allButFirst: 3. "raises an error Subscription out of bounds error" and also... (LinkedList with: Link new with: Link new ) allButFirst: 2. "raises an error Subscription out of bounds error" I feel that proceeding-without-iterating is nicer than showing-an-application-error. It provides the opportunity to not-check the number elements or wrapping error handling around it - i.e. less code if its not important. If its important not to exceed the number of elements, then that check can be explicitly coded. cheers -ben

Aug. 30, 2019

Exercism - creating fresh image with previously submitted exercises

by DavidBajger

Hi Tim & Pharo Exercism contributors!I had a chance to come back to my exercism challenges and tried to create new image for continuing on solutions. I've tried to load manually previously submitted/completed exercises into fresh image (with Exercism loaded) and found few issues. Here is my list: */Batch loading/* 1) It would be great to have menu item to "Batch load already submitted exercises", so I should create issue on Github for this enhancement, right? */Renamed exercises/* 2) I faced few challenges when loading my already posted exercises and one of them was renamed package and class. My old solution was in different package and class was named differently too, so I had to rename class with solution to new name, so the tests would be green again. I had to move class to new package as well. Examples are: ResistorColorDuo(new class name) <-> ResistorColors (old)MatchingBrackets(new class name) <-> BracketPush(old)Is there a way, to have some migration mechanism as part of loading the exercise into image, which would rename class (and package) automatically and resubmit solution again? */Loading subclasses with missing references to superclass/* 3) Some of my solutions are using more classes and sub-classes, for some reason loading such exercise failed, because it tried to load subclass first without having superclass loaded. So workaround for this was to create superclass as stub manually and load exercise again. I had to move classes to correct package, but somehow I struggle to understand what is really right package name (screenshots below). <http://forum.world.st/file/t371519/2019-08-29_10_48_51-Clipboard.png> <http://forum.world.st/file/t371519/2019-08-29_bowling_error_class_missing.p…> <http://forum.world.st/file/t371519/2019-08-30_package_exercism_or_exercise.…> */Exercises in independent packages /* 4) Old way of organizing Exercism exercises was using package extension of package Exercism, which I found a bit more well-arranged than using package for each exercise. Is there a reason for having each exercise in standalone package? I guess there is a good reason for that. <http://forum.world.st/file/t371519/2019-08-30_package_extensions.png> <http://forum.world.st/file/t371519/2019-08-30-exercism-packages.png> *Thanks for your insights!* David ----- David Bajger -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 30, 2019

Re: [Pharo-users] how to open a system browser on a environment?

by Denis Kudriashov

Hi Bernardo. RBEnvironment is not supported in Calypso. But you can scope browser to the set of packages: ClyFullBrowser openWithState: [:browser | browser switchToPackageScopeOf: {Announcer package. Array package}] It will keep given scope in following navigation from opened browser. for example try open senders from the browser and then spawn full browser from one of items. Ð¿Ñ, 30 Ð°Ð²Ð³. 2019 Ð³. Ð² 01:02, Bernardo Ezequiel Contreras < vonbecmann(a)gmail.com>: > thanks, but nop. (i downloaded drgeo and tested that expression) > i want to open the system browser with my project's packages, only that. > thanks again. > > > On Thu, Aug 29, 2019 at 9:16 AM Hilaire <hilaire(a)drgeo.eu> wrote: > >> On DrGeo based on P7, I do this: >> >> Smalltalk tools browser openOnClass: DrGeoSketch >> >> Hope it help. >> >> Hilaire >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >> > > -- > Bernardo E.C. > > Sent from a cheap desktop computer in South America. >

Aug. 30, 2019