- Pharo-users - lists.pharo.org

shortlist of businesses providing professional Pharo services in the Netherlands/Europe

by Jonathan van Alteren

Hi all, One of our potential clients has asked about business continuity regarding our use of the Pharo platform. In other words, they want to know which companies can take over development/maintenance of their Pharo application, in the unlikely event that we end our services. Besides the Pharo Consortium members, is there perhaps a shortlist of professional Pharo software service businesses in the Netherlands and/or Europe? Do you know businesses providing professional Pharo services in the Netherlands? Kind regards, Jonathan van Alteren Object Guild (https://objectguild.com)

May 22, 2019

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

by Dale Henrichs

clarification embedded below On 5/20/19 3:43 PM, Dale Henrichs wrote: > > | project className | > project := (Rowan projectNamed:'Exercise') asDefinition. > className := 'Acronym'. > packageName := 'Exercise-', className. > ((project > addPackageNamed: packageName > toComponentNamed: className > withConditions: 'gemstone' > andGroup: 'core') > addClassNamed: className super: 'Object' category: packageName) > addInstanceMethod: 'foo ^1' protocol: 'accessing. > > ((project > addPackageNamed: packageName, '-Test' > toComponentNamed: className > withConditions: 'gemstone' > andGroup: 'test') > addClassNamed: className, 'Test' super: 'TestCase' category: packageName) > addInstanceMethod: 'test ...' protocol: 'testing. > > (project componentNamed: className) > addComponent: 'ExercismDev'. > project export. "to write project to disk" > project load. "to load the project in the image" > 'ExercismDev' above and 'ExercismTools' should be the same component name ('ExercismDev' ?) ... this is the component name containing the required packages ... > > RwComponentLoadConfiguration{ > #name : 'Acronym', > #version : '0.1.0', > #conditionalPackages : { > [ > 'gemstone' > ] : { > 'core' : { > #packageNames : [ > 'Exercise-Acronym' > ] > } > 'test' : { > #packageNames : [ > 'Exercise-Acronym-Test' > ] > } > > } > }, > #componentNames : [ 'ExercismTools' ] > } >

May 21, 2019

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

by Dale Henrichs

On 5/20/19 12:38 PM, Tim Mackinnon wrote: > 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? I haven't focused on visitors at the moment I am focusing on building out the basic definition structure ... providing apis for creating packages in projects, classes in packages and methods in classes, etc. Currently I am using severalÂ flavors visitors for modifications (visiting the result of comparing two project definitions) ... the most interesting pattern is that the modification visitor is being used to write only the changed structures to disk -- instead of rewriting the whole package. A modification visitor is also used by the loader to drive the loading process -- again identifying the definitions that have changed and then applying those changes to the image ... I haven't run into a use case where I needed to use a visitor on the defintion structure itself ... so far doing projectNamed:/packageNamed:/classNamed:/methodNamed: has met my needs, but I would be interested to learn a bit more about the application that you have in mind ... > > 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? I assume that you are referring to this email[1]?Â If so, then I do think that Rowan would simplify things as there as the whole structure is controlled by a definitions structure api, so there is an API for creating and managing packages/classes, so if you were going to add a new class that was supposed to be independently loadable then you would do something like the following: | project className | project := (Rowan projectNamed:'Exercise') asDefinition. className := 'Acronym'. packageName := 'Exercise-', className. ((project addPackageNamed: packageName toComponentNamed: className withConditions: 'gemstone' andGroup: 'core') addClassNamed: className super: 'Object' category: packageName) addInstanceMethod: 'foo ^1' protocol: 'accessing. ((project addPackageNamed: packageName, '-Test' toComponentNamed: className withConditions: 'gemstone' andGroup: 'test') addClassNamed: className, 'Test' super: 'TestCase' category: packageName) addInstanceMethod: 'test ...' protocol: 'testing. (project componentNamed: className) addComponent: 'ExercismTools'. project export. "to write project to disk" project load. "to load the project in the image" In Rowan, packages are not independently loadable. A component is the loadable entity and it may be composed of one or more conditional packages. A component has dependencies upon other components ... One other thing about Rowan is that there is no such thing as load order ... the components/packages are loaded atomically, so dependencies may be circular. The #export method above, writes the package and component structure to disk, and the component would look like the following: RwComponentLoadConfiguration{ #name : 'Acronym', #version : '0.1.0', #conditionalPackages : { [ 'gemstone' ] : { 'core' : { #packageNames : [ 'Exercise-Acronym' ] }, 'test' : { #packageNames : [ 'Exercise-Acronym-Test' ] } } }, #componentNames : [ 'ExercismTools' ] } At the end of the day, you'd have 100 components (one for each exercise). A "well formed" component should have tests. For something to be independently loadable, it is absolutely necessary that the independent aspect be validated by tests ... so I added a Test class and package for Acronym:) ... ExecercismTools is a separate components with all of the necessary packages and "prereqs" defined... Hopefully, I've given you a flavor of how I think your problem would be addressed with Rowan ... The thing that I like is that everything is a definition with an api for creating/maintaining the definitions and all of the definitions exist independent of the loaded image ... the definitions can be read/written from disk without going through a load processÂ ... Let me know what you think ... as these components are still fluid at the moment, feedback will have a real impact on the end product. Dale [1] http://forum.world.st/The-baseline-complexity-of-tiny-big-projects-td509949… > > Tim > > Sent from my iPhone > > On 20 May 2019, at 20:16, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@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 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