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

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

by Esteban A. Maringolo

El mar 10, 2015 8:13 AM, "Sean P. DeNigris" <sean(a)clipperadams.com> escribiÃ³: > > 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. I would remove #asString and use #displayString everywhere. But it should be implemented in Object, based on a #displayOn: method just like printString does. If a method starts with #as... I read "I will cast this object into something else". Which will be subject to taste. Regarding this particular case I would implement #asString as a delegation to the method that returns '/foo/bar/baz'. An URL's #asString would return 'file:///foo/bar/baz'. Regards!

March 10, 2015

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

by Tudor Girba

Well, not now. In Pharo 5 :) Doru On Tue, Mar 10, 2015 at 12:18 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Indeed. In GT, we introduced gtDisplayString which is meant to be used as > a default brief string representation. > > I think that we could promote this to displayString now that it is in the > Pharo image. > > Cheers, > Doru > > On Tue, Mar 10, 2015 at 12:03 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> 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. >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

March 10, 2015

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

by Tudor Girba

Indeed. In GT, we introduced gtDisplayString which is meant to be used as a default brief string representation. I think that we could promote this to displayString now that it is in the Pharo image. Cheers, Doru On Tue, Mar 10, 2015 at 12:03 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > 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. > > -- www.tudorgirba.com "Every thing has its own flow"

March 10, 2015

Re: [Pharo-users] Native language support

by Sean P. DeNigris

Nick Doodka wrote > next error MessageNotUnderstood:Character>>isArrow. What is the exact image version (incl. update number)? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Native-language-support-tp4809392p4810892.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 10, 2015

Re: [Pharo-users] GTTools and Mongo

by Esteban Lorenzano

cool! > On 10 Mar 2015, at 10:20, 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. > <mongo.png>

March 10, 2015

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