March 2015 - Pharo-users - lists.pharo.org

GTTools and Mongo

by Torsten Bergmann

After loading MongoTalk or VoyageMongo in Pharo 4 you can additionally load the package: "Mongo-Pharo-Tools" from mongotalk repo on SmalltalkHub. This way you can browse your mongo database (collections and documents) directly from within Pharo using GTInspector tools (see screenshot). Just by adding two methods - nice! Bye T.

March 10, 2015

Re: [Pharo-users] Why `aFileReference asString = aFileReference fullName` is false?

by Ben Coman

On Tue, Mar 10, 2015 at 9:52 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Yo should use #pathString to obtain the full path of the file reference. > > #asString isn't implemented in FileReference and it's inherited from > Object, which delegates it to the default implementation of > #printString, which isn't intented to be user friendly, and not for > conversion. > > Regards! > Esteban A. Maringolo > Thanks for the explanation Esteban. Now the followup question is whether its natural to expect something better from #asString, and other people will fall into the same trap? cheers -ben > > > 2015-03-09 22:35 GMT-03:00 Sebastian Sastre <sebastian(a)flowingconcept.com > >: > > right, and what's the practical use of that? > > > > from mobile > > > >> On 09/03/2015, at 12:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> The thing before the @ indicates the kind of file system you are on > (there are not just disk based files, but virtual in-memory ones, or in-zip > ones). > >> > >>> On 09 Mar 2015, at 16:06, Sebastian Sastre < > sebastian(a)flowingconcept.com> wrote: > >>> > >>> A frequent thing to do is to work with files, so their paths. > >>> > >>> Take the image directory for example: > >>> > >>> `FileLocator imageDirectory resolve asString` > >>> > >>> 1) Whatâs the reason to make `aFileReference asString` to be different > to what `aFileReference fullName` answers? > >>> > >>> 2) Whatâs the practical use of the current answer of `aFileReference > asString`? > >>> > >>> > >> > >> > > > >

March 10, 2015

Re: [Pharo-users] smaller configurations vs groups [was Re: Pillar and GT tools in Pharo4]

by Tudor Girba

Hi, Thanks for raising the issue. The "ripple" effect exists anyway when you have nested configurations, even with groups, only when you have groups you do not notice it because it is implicit. As you say, the solution is to build tool support, and among others, I argued that tooling and debugging becomes simpler without groups. The only reason I see for wanting groups is that it makes it easy to edit configurations manually in the code browser. We should not optimize around this, but we should favor tooling. Just a note: you still did not address my original argument about the conceptual problem of a group not being first class :) Cheers, Doru On Tue, Mar 10, 2015 at 9:53 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > This is one of the issues we need to avoid: having an unneeded ripple > effect. GlamourCore was updated, making it necessary to update > everything that has a hard version dependency on it. Even worse is > that there is actually no change in GlamourCore 3.0.4. This problem > gets worse the more configurations we have. > > ConfigurationOfGTInspectorCore>>version203: spec > <version: '2.0.3' imports: #('2.0-baseline' )> > > spec for: #'common' do: [ > spec blessing: #'stable'. > spec description: 'version 2.0.3'. > spec author: 'AndreiChis'. > spec timestamp: '12/07/2014 13:58'. > > spec > package: 'GT-Inspector' with: 'GT-Inspector- > EstebanLorenzano.271'; > package: 'GT-InspectorExtensions-Core' with: > 'GT-InspectorExtensions-Core-TudorGirba.86'; > package: 'GT-Tests-Inspector' with: > 'GT-Tests-Inspector-AndreiChis.24'. > spec > project: 'GlamourCore' with: '3.0.3'. ]. > > > ConfigurationOfGTInspectorCore>>version204: spec > <version: '2.0.4' imports: #('2.0-baseline' )> > > spec for: #'common' do: [ > spec blessing: #'stable'. > spec description: 'version 2.0.4'. > spec author: 'AndreiChis'. > spec timestamp: '12/09/2014 12:08'. > > spec > package: 'GT-Inspector' with: 'GT-Inspector- > EstebanLorenzano.271'; > package: 'GT-InspectorExtensions-Core' with: > 'GT-InspectorExtensions-Core-TudorGirba.86'; > package: 'GT-Tests-Inspector' with: > 'GT-Tests-Inspector-AndreiChis.24'. > spec > project: 'GlamourCore' with: '3.0.4'. ]. > > The same happens with the subconfigurations of GT, a change in GTInspector > leads to a change in the playground. > > ConfigurationOfGTPlayGround>>version106: spec > <version: '1.0.6' imports: #('1.0-baseline' )> > > spec for: #'common' do: [ > spec blessing: #'stable'. > spec description: 'version 1.0.6'. > spec author: 'AndreiChis'. > spec timestamp: '10/06/2014 11:42'. > spec project: 'GTInspector' with: '1.0.6'. > spec package: 'GT-Playground' with: > 'GT-Playground-TudorGirba.38'. ] > > > ConfigurationOfGTPlayGround>>version107: spec > <version: '1.0.7' imports: #('1.0-baseline' )> > > spec for: #'common' do: [ > spec blessing: #'stable'. > spec description: 'version 1.0.7'. > spec author: 'AndreiChis'. > spec timestamp: '10/12/2014 19:56'. > spec project: 'GTInspector' with: '1.0.7'. > spec package: 'GT-Playground' with: > 'GT-Playground-TudorGirba.38'. ] > > And this means that we are better of with configurations having > high cohesion and low coupling. And tool support for groups. > > Stephan > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 10, 2015

Re: [Pharo-users] smaller configurations vs groups [was Re: Pillar and GT tools in Pharo4]

by Stephan Eggermont

This is one of the issues we need to avoid: having an unneeded ripple effect. GlamourCore was updated, making it necessary to update everything that has a hard version dependency on it. Even worse is that there is actually no change in GlamourCore 3.0.4. This problem gets worse the more configurations we have. ConfigurationOfGTInspectorCore>>version203: spec <version: '2.0.3' imports: #('2.0-baseline' )> spec for: #'common' do: [ spec blessing: #'stable'. spec description: 'version 2.0.3'. spec author: 'AndreiChis'. spec timestamp: '12/07/2014 13:58'. spec package: 'GT-Inspector' with: 'GT-Inspector-EstebanLorenzano.271'; package: 'GT-InspectorExtensions-Core' with: 'GT-InspectorExtensions-Core-TudorGirba.86'; package: 'GT-Tests-Inspector' with: 'GT-Tests-Inspector-AndreiChis.24'. spec project: 'GlamourCore' with: '3.0.3'. ]. ConfigurationOfGTInspectorCore>>version204: spec <version: '2.0.4' imports: #('2.0-baseline' )> spec for: #'common' do: [ spec blessing: #'stable'. spec description: 'version 2.0.4'. spec author: 'AndreiChis'. spec timestamp: '12/09/2014 12:08'. spec package: 'GT-Inspector' with: 'GT-Inspector-EstebanLorenzano.271'; package: 'GT-InspectorExtensions-Core' with: 'GT-InspectorExtensions-Core-TudorGirba.86'; package: 'GT-Tests-Inspector' with: 'GT-Tests-Inspector-AndreiChis.24'. spec project: 'GlamourCore' with: '3.0.4'. ]. The same happens with the subconfigurations of GT, a change in GTInspector leads to a change in the playground. ConfigurationOfGTPlayGround>>version106: spec <version: '1.0.6' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'stable'. spec description: 'version 1.0.6'. spec author: 'AndreiChis'. spec timestamp: '10/06/2014 11:42'. spec project: 'GTInspector' with: '1.0.6'. spec package: 'GT-Playground' with: 'GT-Playground-TudorGirba.38'. ] ConfigurationOfGTPlayGround>>version107: spec <version: '1.0.7' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'stable'. spec description: 'version 1.0.7'. spec author: 'AndreiChis'. spec timestamp: '10/12/2014 19:56'. spec project: 'GTInspector' with: '1.0.7'. spec package: 'GT-Playground' with: 'GT-Playground-TudorGirba.38'. ] And this means that we are better of with configurations having high cohesion and low coupling. And tool support for groups. Stephan

March 10, 2015