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

Re: [Pharo-users] How to visit over packages, classes, methods (all types)

by Tim Mackinnon

Hi Dale - thanks for chipping in. Iâve seen references to Rowan, but hadnât investigated. Interesting. Were you thinking of a standard visitor pattern (Gof) or something else? And/Or, Is this visiting piece already done, or would it help if we had such a beast in Pharo that you could then reuse for your purpose? As an aside, in a separate message, I was lamenting the complexity of managing 100 simple similar packages with the same dependency - would Rowan help with that? Tim Sent from my iPhone > On 20 May 2019, at 20:16, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Tim, > > I know that this doesn't answer your question, but one of the features that I'm building into Rowan is just this capability: > > project definitions composed of package definitions > package definitions composed of class and class extension definitions > class and class extensions definitions composed of method definitions > ... there are also definitions that cover what is now handled by Metacello: conditional packages, package grouping and project dependencies ... > > I am intending/hoping that Rowan will eventually be available for Pharo:) ... I have to finish Rowan for GemStone first:) > > Dale > >> On 5/19/19 10:23 AM, Tim Mackinnon wrote: >> Hi - is there a way to iterate over all the code in a package (or class or baseline) in a generic way (to pretty print out class definitions, and methods - including extensions ). >> >> I was kind of hoping that with TonelWriter and Fileout and Critics that we would have a generic visitor mechanism but it seems that all of them just implemented it again - which misses a big opportunity for refactoring so that when you want to reason/print/manipulate code - it would be more straight forward. >> >> Is there anything/anyone addressing this ? Or maybe Iâve missed an obvious trick somewhere? >> >> Tim >> >> Sent from my iPhone >>

May 20, 2019

Re: [Pharo-users] How to visit over packages, classes, methods (all types)

by Dale Henrichs

Tim, I know that this doesn't answer your question, but one of the features that I'm building into Rowan is just this capability: * project definitions composed of package definitions * package definitions composed of class and class extension definitions * class and class extensions definitions composed of method definitions ... there are also definitions that cover what is now handled by Metacello: conditional packages, package grouping and project dependencies ... I am intending/hoping that Rowan will eventually be available for Pharo:) ... I have to finish Rowan for GemStone first:) Dale On 5/19/19 10:23 AM, Tim Mackinnon wrote: > Hi - is there a way to iterate over all the code in a package (or class or baseline) in a generic way (to pretty print out class definitions, and methods - including extensions ). > > I was kind of hoping that with TonelWriter and Fileout and Critics that we would have a generic visitor mechanism but it seems that all of them just implemented it again - which misses a big opportunity for refactoring so that when you want to reason/print/manipulate code - it would be more straight forward. > > Is there anything/anyone addressing this ? Or maybe Iâve missed an obvious trick somewhere? > > Tim > > Sent from my iPhone >

May 20, 2019

Re: [Pharo-users] [Pharo-dev] [Ann] Lifeware, Schmidt Pro contracts for the consortium

by Torsten Bergmann

May 20, 2019

Re: [Pharo-users] [Pharo-dev] [Ann] Lifeware, Schmidt Pro contracts for the consortium

by Esteban Maringolo

This is really good news! Congratulations! Esteban A. Maringolo On Mon, May 20, 2019 at 3:04 AM ducasse <stepharo(a)netcourrier.com> wrote: > The Pharo consortium is very excited and super happy to bring your > attention to the following announce > that was presented during Pharodays 2019: > https://fr.slideshare.net/pharoproject/ > > The consortium got two contracts to support financially one year of > engineer to improve Pharo. > The companies Lifeware and Schmidt Pro fund work on Pharo to improve > Pharo. The total amount > of the two contracts is around 190 K Euros. > In addition the RMOD team got some resources from Inria. > The net result is that in 2019 the consortium will have 3.5 engineers > working full time on Pharo. > > - Esteban Lorenzano > - Pablo Tesone > - Cyril Ferlicot > - Guillermo Polito > > It will boost Pharo. Note that the issues raised by Schmidt Pro and > Lifeware > and their impacts on the roadmap of Pharo 8 and Pharo 9 are presented in > https://fr.slideshare.net/pharoproject/. > > What is key to notice is that the consortium is working because many > contributing companies are sharing ressources. > This is built a strong soil to grow Pharo and business around. > > On the behalf of Inria, the consortium and the community we would like to > thank > Lifeware and SchmidtPro for their strong support. > > Stef on the behalf of the Pharo consortium > >

May 20, 2019

Re: [Pharo-users] Right clicking often fails first time?

by Christopher Fuhrman

Since I read your email, I've noticed now that an image when opened ignores my first click (right or otherwise). Using the latest Pharo Launcher with Pharo 703 images in Windows Subsystem for Linux (Windows 10). It's very easy to just click again, so I never really noticed before. But it is mildly annoying. At first I was thinking it was an XWindows focus problem (under Windows 10). My tests show that keyboard events go through (e.g., I can use the arrow keys to move selections around), but the first mouse-click is ignored. On Tue, 30 Apr 2019 at 17:16, Tim Mackinnon <tim(a)testit.works> wrote: > This has been bugging me for a long time - but its incredibly annoying > that when you right click on a class, package, Iceberg entry - that the > context menu doesnât often appear. You have to click again (or remember to > click first and then right click - even if the reverent item is already > highlighted). > > Why is this? Is it a bug worth reporting and seeing if it can be fixed (or > is it just me? This is in 703, OSX High Sierra) > > Tim >

May 20, 2019

Re: [Pharo-users] [Pharo-dev] [Ann] Lifeware, Schmidt Pro contracts for the consortium

by Sven Van Caekenberghe

Indeed, thank you for the support ! > On 20 May 2019, at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Great news! > > Cheers, > Doru > >> On May 20, 2019, at 8:03 AM, ducasse <stepharo(a)netcourrier.com> wrote: >> >> The Pharo consortium is very excited and super happy to bring your attention to the following announce >> that was presented during Pharodays 2019: https://fr.slideshare.net/pharoproject/ >> >> The consortium got two contracts to support financially one year of engineer to improve Pharo. >> The companies Lifeware and Schmidt Pro fund work on Pharo to improve Pharo. The total amount >> of the two contracts is around 190 K Euros. >> In addition the RMOD team got some resources from Inria. >> The net result is that in 2019 the consortium will have 3.5 engineers working full time on Pharo. >> >> - Esteban Lorenzano >> - Pablo Tesone >> - Cyril Ferlicot >> - Guillermo Polito >> >> It will boost Pharo. Note that the issues raised by Schmidt Pro and Lifeware >> and their impacts on the roadmap of Pharo 8 and Pharo 9 are presented in https://fr.slideshare.net/pharoproject/. >> >> What is key to notice is that the consortium is working because many contributing companies are sharing ressources. >> This is built a strong soil to grow Pharo and business around. >> >> On the behalf of Inria, the consortium and the community we would like to thank >> Lifeware and SchmidtPro for their strong support. >> >> Stef on the behalf of the Pharo consortium >> > > -- > www.feenk.com > > âProgramming is executable philosophy." > >

May 20, 2019

[Ann] Lifeware, Schmidt Pro contracts for the consortium

by ducasse

The Pharo consortium is very excited and super happy to bring your attention to the following announce that was presented during Pharodays 2019: https://fr.slideshare.net/pharoproject/ <https://fr.slideshare.net/pharoproject/> The consortium got two contracts to support financially one year of engineer to improve Pharo. The companies Lifeware and Schmidt Pro fund work on Pharo to improve Pharo. The total amount of the two contracts is around 190 K Euros. In addition the RMOD team got some resources from Inria. The net result is that in 2019 the consortium will have 3.5 engineers working full time on Pharo. - Esteban Lorenzano - Pablo Tesone - Cyril Ferlicot - Guillermo Polito It will boost Pharo. Note that the issues raised by Schmidt Pro and Lifeware and their impacts on the roadmap of Pharo 8 and Pharo 9 are presented in https://fr.slideshare.net/pharoproject/ <https://fr.slideshare.net/pharoproject/>. What is key to notice is that the consortium is working because many contributing companies are sharing ressources. This is built a strong soil to grow Pharo and business around. On the behalf of Inria, the consortium and the community we would like to thank Lifeware and SchmidtPro for their strong support. Stef on the behalf of the Pharo consortium

May 20, 2019

Re: [Pharo-users] The baseline complexity of tiny big projects...

by Tim Mackinnon

Hi Richard, there isnât an easy way to communicate with Exercism users (Iâm arranging an email to be sent) but essentially just apply this upgrade https://github.com/exercism/pharo-smalltalk/blob/master/docs/UPGRADE.md Sent from my iPhone Sent from my iPhone > On 20 May 2019, at 04:20, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > This is not an answer to your question, but it is an observation by someone who was trying all > the exercises. As a user, it was just working. Then suddenly, there was a change. Instead of > a new exercise popping up underneath Exercism, it would appear as Exercise@Foobar. No big > deal. What *is* a big deal is that the "submit" menu item disappeared, and the only way I > have found to submit a solution is > - File Out the class > - Use the command line to download the exercise > - Move the filed out class to the exercise directly > - exercism submit Foobar.st > I had been quite impressed with how smoothly everything went in the UI before. > > >> On Mon, 20 May 2019 at 09:57, Tim Mackinnon <tim(a)testit.works> wrote: >> Iâm wondering if others might spot a better way of handling this - but with Exercism, Iâve got 100 exercises to manage. An Exercise is a TestCase and 1 or more solution classes (normally 1, but sometimes several). I had initially used Tags to manage this, there was an ExercismExercise package, and then a tag for each exercise. This was quite neat and tidy - however its flawed as it doesnât allow extension methods on the tags (they live on the parent package - which is problematic as in use, the exercises are loaded one by one from tonel files as the student progresses), it also does let you critique an individual exerciseâ¦ so essentially they arenât sub-projects and I was recommended to promote them to proper Packages. >> >> This was all quite trivial to support with tags but now I have to grapple with the BaselineOf for my project (to manage all these exercises in development mode - where you want to load them all, run all their tests, and add to them etc). >> >> As each exercise depends on an ExercismTestCase - I have a single pre-req for each one, and then, in development mode, I have to load all 100 of them. The best I came up with was the following - but its a hell of a lot more complicated than the previous tag solution where effectively the owning package let me do this once (and membership of that package automatically gave a tag this pre-req and containment behaviour). >> >> So instead I have to do the following (and Iâm left wondering if Iâm missing some easier way). The bold bits are where Iâve tried to do something to try and workaround this - its the array of packageNames that is a bit distasteful to me, and it feels a lot like I have to express the same information twice - one in the iceberg window to add all these packages, and then again in the method of names, to set the identical pre-req on each of themâ¦ I find in this respect, Iâm missing Envy developer here? >> >> Anyone have some better suggestions? Or do we need to try and make the tools better? >> >> Tim >> >> baseline: spec >> <baseline> >> >> spec >> for: #common >> do: [ >> self setUpExercisesFor: spec. >> spec >> package: 'ExercismPharo70'; "Pharo override/patch methods" >> package: 'ExercismTools' >> with: [ spec requires: #('ExercismPharo70') ]; >> >> package: 'ExercismTests' >> with: [ spec requires: #('ExercismTools' 'ExercismMocking'), >> self exerciseTestPackageNames ]; >> >> package: 'ExercismSystemTests' >> with: [ spec requires: #('ExercismTests') ]; >> >> >> package: 'ExercismDev' >> with: [ spec requires: #( >> 'OSProcess' "For shelling out to configlet" >> 'Ring2' "For mentoring support of shadow browsing" >> 'ExercismTools' ), >> self exercisePackageNames, >> #('Exercism' >> >> 'ExercismTests' >> 'ExercismSystemTests')]; >> >> group: 'default' >> with: #('ExercismTools' 'Exercise@Welcome'); >> >> group: 'dev' >> with: #('ExercismDevâ)]. >> >> setUpExercisesFor: spec >> self class exercisePackageNames, self class exerciseTestPackageNames >> do: >> [ :name | spec package: name with: [ spec requires: #('ExercismTools') ] ]. >> >> exercisePackageNames >> "Answer the list of exercise package names (as we don't yet have proper projects)" >> >> ^ #('Exercise@Acronym' 'Exercise@Allergies' 'Exercise@Anagram' 'Exercise@ArmstrongNumbers' 'Exercise@AtbashCipher' 'Exercise@Binary' 'Exercise@Bowling' 'Exercise@Clock' 'Exercise@CollatzConjecture' 'Exercise@Darts' 'Exercise@Diamond' 'Exercise@Die' 'Exercise@Etl' 'Exercise@Forth' 'Exercise@GradeSchool' 'Exercise@Grains' 'Exercise@Hamming' 'Exercise@HelloWorld' 'Exercise@HighScores' 'Exercise@IsbnVerifier' 'Exercise@Isogram' 'Exercise@Leap' 'Exercise@Luhn' 'Exercise@MatchingBrackets' 'Exercise@Pangram' 'Exercise@Proverb' 'Exercise@Raindrops' 'Exercise@ResistorColorDuo' 'Exercise@ReverseString' 'Exercise@RobotSimulator' 'Exercise@RomanNumerals' 'Exercise@SecretHandshake' 'Exercise@Sieve' 'Exercise@SpaceAge' 'Exercise@SumOfMultiples' 'Exercise@Tournament' 'Exercise@TwelveDays' 'Exercise@TwoFer' 'Exercise@Welcome' 'Exercise@WordCount')

May 20, 2019

Re: [Pharo-users] The baseline complexity of tiny big projects...

by Richard O'Keefe

This is not an answer to your question, but it is an observation by someone who was trying all the exercises. As a user, it was just working. Then suddenly, there was a change. Instead of a new exercise popping up underneath Exercism, it would appear as Exercise@Foobar. No big deal. What *is* a big deal is that the "submit" menu item disappeared, and the only way I have found to submit a solution is - File Out the class - Use the command line to download the exercise - Move the filed out class to the exercise directly - exercism submit Foobar.st I had been quite impressed with how smoothly everything went in the UI before. On Mon, 20 May 2019 at 09:57, Tim Mackinnon <tim(a)testit.works> wrote: > Iâm wondering if others might spot a better way of handling this - but > with Exercism, Iâve got 100 exercises to manage. An Exercise is a TestCase > and 1 or more solution classes (normally 1, but sometimes several). I had > initially used Tags to manage this, there was an ExercismExercise package, > and then a tag for each exercise. This was quite neat and tidy - however > its flawed as it doesnât allow extension methods on the tags (they live on > the parent package - which is problematic as in use, the exercises are > loaded one by one from tonel files as the student progresses), it also does > let you critique an individual exerciseâ¦ so essentially they arenât > sub-projects and I was recommended to promote them to proper Packages. > > This was all quite trivial to support with tags but now I have to grapple > with the BaselineOf for my project (to manage all these exercises in > development mode - where you want to load them all, run all their tests, > and add to them etc). > > As each exercise depends on an ExercismTestCase - I have a single pre-req > for each one, and then, in development mode, I have to load all 100 of > them. The best I came up with was the following - but its a hell of a lot > more complicated than the previous tag solution where effectively the > owning package let me do this once (and membership of that package > automatically gave a tag this pre-req and containment behaviour). > > So instead I have to do the following (and Iâm left wondering if Iâm > missing some easier way). The bold bits are where Iâve tried to do > something to try and workaround this - its the array of packageNames that > is a bit distasteful to me, and it feels a lot like I have to express the > same information twice - one in the iceberg window to add all these > packages, and then again in the method of names, to set the identical > pre-req on each of themâ¦ I find in this respect, Iâm missing Envy developer > here? > > Anyone have some better suggestions? Or do we need to try and make the > tools better? > > Tim > > baseline: spec > <baseline> > spec > for: #common > do: [ > *self setUpExercisesFor: spec.* > spec > package: 'ExercismPharo70'; "Pharo override/patch methods" > package: 'ExercismTools' > with: [ spec requires: #('ExercismPharo70') ]; > package: 'ExercismTests' > with: [ spec requires: #('ExercismTools' 'ExercismMocking'), > self exerciseTestPackageNames ]; > package: 'ExercismSystemTests' > with: [ spec requires: #('ExercismTests') ]; > package: 'ExercismDev' > with: [ spec requires: #( > 'OSProcess' "For shelling out to configlet" > 'Ring2' "For mentoring support of shadow browsing" > 'ExercismTools' ), > *self exercisePackageNames,* > #('Exercism' > > 'ExercismTests' > 'ExercismSystemTests')]; > group: 'default' > with: #('ExercismTools' 'Exercise@Welcome'); > group: 'dev' > with: #('ExercismDevâ)]. > > *setUpExercisesFor*: spec > self class exercisePackageNames, self class exerciseTestPackageNames > do: > [ :name | spec package: name with: [ spec requires: #('ExercismTools') ] ]. > > *exercisePackageNames* > "Answer the list of exercise package names (as we don't yet have proper > projects)" > > ^ #('Exercise@Acronym' 'Exercise@Allergies' 'Exercise@Anagram' > 'Exercise@ArmstrongNumbers' 'Exercise@AtbashCipher' 'Exercise@Binary' > 'Exercise@Bowling' 'Exercise@Clock' 'Exercise@CollatzConjecture' > 'Exercise@Darts' 'Exercise@Diamond' 'Exercise@Die' 'Exercise@Etl' > 'Exercise@Forth' 'Exercise@GradeSchool' 'Exercise@Grains' > 'Exercise@Hamming' 'Exercise@HelloWorld' 'Exercise@HighScores' > 'Exercise@IsbnVerifier' 'Exercise@Isogram' 'Exercise@Leap' 'Exercise@Luhn' > 'Exercise@MatchingBrackets' 'Exercise@Pangram' 'Exercise@Proverb' > 'Exercise@Raindrops' 'Exercise@ResistorColorDuo' 'Exercise@ReverseString' > 'Exercise@RobotSimulator' 'Exercise@RomanNumerals' > 'Exercise@SecretHandshake' 'Exercise@Sieve' 'Exercise@SpaceAge' > 'Exercise@SumOfMultiples' 'Exercise@Tournament' 'Exercise@TwelveDays' > 'Exercise@TwoFer' 'Exercise@Welcome' 'Exercise@WordCount') > >

May 20, 2019

The baseline complexity of tiny big projects...

by Tim Mackinnon

Iâm wondering if others might spot a better way of handling this - but with Exercism, Iâve got 100 exercises to manage. An Exercise is a TestCase and 1 or more solution classes (normally 1, but sometimes several). I had initially used Tags to manage this, there was an ExercismExercise package, and then a tag for each exercise. This was quite neat and tidy - however its flawed as it doesnât allow extension methods on the tags (they live on the parent package - which is problematic as in use, the exercises are loaded one by one from tonel files as the student progresses), it also does let you critique an individual exerciseâ¦ so essentially they arenât sub-projects and I was recommended to promote them to proper Packages. This was all quite trivial to support with tags but now I have to grapple with the BaselineOf for my project (to manage all these exercises in development mode - where you want to load them all, run all their tests, and add to them etc). As each exercise depends on an ExercismTestCase - I have a single pre-req for each one, and then, in development mode, I have to load all 100 of them. The best I came up with was the following - but its a hell of a lot more complicated than the previous tag solution where effectively the owning package let me do this once (and membership of that package automatically gave a tag this pre-req and containment behaviour). So instead I have to do the following (and Iâm left wondering if Iâm missing some easier way). The bold bits are where Iâve tried to do something to try and workaround this - its the array of packageNames that is a bit distasteful to me, and it feels a lot like I have to express the same information twice - one in the iceberg window to add all these packages, and then again in the method of names, to set the identical pre-req on each of themâ¦ I find in this respect, Iâm missing Envy developer here? Anyone have some better suggestions? Or do we need to try and make the tools better? Tim baseline: spec <baseline> spec for: #common do: [ self setUpExercisesFor: spec. spec package: 'ExercismPharo70'; "Pharo override/patch methods" package: 'ExercismTools' with: [ spec requires: #('ExercismPharo70') ]; package: 'ExercismTests' with: [ spec requires: #('ExercismTools' 'ExercismMocking'), self exerciseTestPackageNames ]; package: 'ExercismSystemTests' with: [ spec requires: #('ExercismTests') ]; package: 'ExercismDev' with: [ spec requires: #( 'OSProcess' "For shelling out to configlet" 'Ring2' "For mentoring support of shadow browsing" 'ExercismTools' ), self exercisePackageNames, #('Exercism' 'ExercismTests' 'ExercismSystemTests')]; group: 'default' with: #('ExercismTools' 'Exercise@Welcome'); group: 'dev' with: #('ExercismDevâ)]. setUpExercisesFor: spec self class exercisePackageNames, self class exerciseTestPackageNames do: [ :name | spec package: name with: [ spec requires: #('ExercismTools') ] ]. exercisePackageNames "Answer the list of exercise package names (as we don't yet have proper projects)" ^ #('Exercise@Acronym' 'Exercise@Allergies' 'Exercise@Anagram' 'Exercise@ArmstrongNumbers' 'Exercise@AtbashCipher' 'Exercise@Binary' 'Exercise@Bowling' 'Exercise@Clock' 'Exercise@CollatzConjecture' 'Exercise@Darts' 'Exercise@Diamond' 'Exercise@Die' 'Exercise@Etl' 'Exercise@Forth' 'Exercise@GradeSchool' 'Exercise@Grains' 'Exercise@Hamming' 'Exercise@HelloWorld' 'Exercise@HighScores' 'Exercise@IsbnVerifier' 'Exercise@Isogram' 'Exercise@Leap' 'Exercise@Luhn' 'Exercise@MatchingBrackets' 'Exercise@Pangram' 'Exercise@Proverb' 'Exercise@Raindrops' 'Exercise@ResistorColorDuo' 'Exercise@ReverseString' 'Exercise@RobotSimulator' 'Exercise@RomanNumerals' 'Exercise@SecretHandshake' 'Exercise@Sieve' 'Exercise@SpaceAge' 'Exercise@SumOfMultiples' 'Exercise@Tournament' 'Exercise@TwelveDays' 'Exercise@TwoFer' 'Exercise@Welcome' 'Exercise@WordCount')

May 19, 2019