- Pharo-users - lists.pharo.org

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

by Sean P. DeNigris

Ben Coman wrote > Now the followup question is whether its natural to expect something > better from #asString I feel like #asString is such a general question that no answer would be satisfying. What string representation should be returned? 'file://'? '/path/to'? And what to do with memory file systems? It's been mentioned a few times on the list that we should all be more disciplined in sending e.g. #displayString vs. #printString instead of #asString. The more I hear that argument, the more sense it makes to me. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Why-aFileReference-asString-aFileReference-fullName-i… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 10, 2015

new link to query all projects in smalltalkhub

by Esteban Lorenzano

Hi, You can now look at http://smalltalkhub.com/projectList <http://smalltalkhub.com/projectList> to query all public smalltalkhub projects. is an âold styleâ web pageâ¦ so do not expect too muchâ¦ but at least you can see what is around :) enjoy, Esteban

March 10, 2015

Re: [Pharo-users] GTTools and Mongo

by Christophe Demarey

Really nice addition! Thanks Le 10 mars 2015 Ã 10:20, Torsten Bergmann a Ã©crit : > 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. > <mongo.png>

March 10, 2015

Re: [Pharo-users] GTTools and Mongo

by Tudor Girba

Nice job! Doru On Tue, Mar 10, 2015 at 10:20 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > 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. > -- www.tudorgirba.com "Every thing has its own flow"

March 10, 2015

Re: [Pharo-users] Cleaning changes file?

by Thierry Goubier

2015-03-10 9:48 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 10 Mar 2015, at 09:43, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > 2015-03-10 9:28 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> > >> > But stiil, the changes allow you a recovery in case of a crash. It has >> some valuables side effects. >> > >> >> Yes, it was genius to merge both source storage and transaction log 30 >> years ago... today we would >> not do that. >> > > Wouldn't we? Or would we do a more compact log format, optimizing by the > knowledge of what is in the image and what is inside the package > repositories? > > > right now we throw away the transaction log with the image. So we are not > talking about a lot of data. > Hum. The .sources is big and duplicated in the packages. > > i.e. I'm not sure that the fundamental is wrong. Just that the environment > is a bit different. > > I toyed a long time ago with the idea of having a git as a replacement of > the changes. On every method change, you commit... Has a way of compacting > by itself the changes. Largely overkill :) > > Now, I could also see a scheme based on MC, where the source of a method > is fetched from the package (with an ast cache, if needed). Not very > difficult to do. > > But it's not very grandiose. Just a bit of software engineering. Not > interesting ;) > > > Everything is like that. Just your *goal* changes if typing "do:" is part > of something interesting or not. > It also depends on a very significant factor. Will this do: be used or not? If it won't because the next best thing will take preeminence as soon as it is ready in a few years, then you don't invest in the do:. Thierry

March 10, 2015

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

Re: [Pharo-users] Cleaning changes file?

by Marcus Denker

> On 10 Mar 2015, at 09:43, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-03-10 9:28 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > > > > But stiil, the changes allow you a recovery in case of a crash. It has some valuables side effects. > > > > Yes, it was genius to merge both source storage and transaction log 30 years agoâ¦ today we would > not do that. > > Wouldn't we? Or would we do a more compact log format, optimizing by the knowledge of what is in the image and what is inside the package repositories? > right now we throw away the transaction log with the image. So we are not talking about a lot of data. > i.e. I'm not sure that the fundamental is wrong. Just that the environment is a bit different. > > I toyed a long time ago with the idea of having a git as a replacement of the changes. On every method change, you commit... Has a way of compacting by itself the changes. Largely overkill :) > > Now, I could also see a scheme based on MC, where the source of a method is fetched from the package (with an ast cache, if needed). Not very difficult to do. > > But it's not very grandiose. Just a bit of software engineering. Not interesting ;) > Everything is like that. Just your *goal* changes if typing âdo:â is part of something interesting or not. Marcus

March 10, 2015