- Pharo-users - lists.pharo.org

when iterating over a collection how to determine the current objects index

by Sanjay Minni

Hi when iterating over a sequenced collection (array / ordered collection) how can I determine the current objects index value (without explicitly storing a counter or looking to match each time) Typically I need it: 1. to display a serial number when printing a report. 2. to determine if I am on the last element. 3. To highlight every n-th element. regards Sanjay ----- --- Regards, Sanjay -- View this message in context: http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 10, 2015

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

by stepharo

I agree!!!!!!!! Stef Le 8/3/15 13:24, Tudor Girba a Ã©crit : > Hi, > > I summarize below why I think fine grained configurations should be > preferred to groups. > > The group is not a first class configuration, although it can be > depended on. If you depend on a group of a configuration, it's harder > to understand the consequences and it's harder to build tools for it. > > Consider the graph below representing the dependencies starting from > ConfigurationOfMoose #development: > Inline image 2 > > It's a simple representation of dependencies, and it makes the maze of > configurations easier to grasp. The interesting thing about it is that > by showing a configuration node only once, you can see how multiple > other projects depend on it. For example, HashTable is being depended > on by two distinct configurations. > > You can also see that Magritte depends on Grease, but you do not see > that it only depends on the Core group. To do that, you have to look > at the details of the edge. > > We used to have groups in GT, however, after a while we moved to more > fine grained configurations. As a consequence, you can see that > GlamourCore (which used to be a group in Glamour) is being depended on > by three different configurations. Using first class configurations > makes tool building (like representation, navigation or release) easier. > > You could argue that we could represent a Group as node, however, even > then you would not be able to see dependencies between groups that > reside within the same configuration because groups are not first > class configurations that can explicitly define dependencies, they are > just groups. > > Groups might provide an apparent ease of use for quick things, but I > strongly believe that they are an unessential construct and that if we > would not use them, tools would become cheaper and more effective. > > Cheers, > Doru > > > > > On Sun, Mar 8, 2015 at 1:14 AM, Damien Cassou <damien.cassou(a)gmail.com > <mailto:damien.cassou@gmail.com>> wrote: > > > On Mar 7, 2015 4:42 AM, "Tudor Girba" <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > > > Actually, I would rather prefer to create a separate > ConfigurationOfPillarTools that adds the Pillar-Pharo-Tools and > the PetitParser dependency. What that be Ok? > > Ok for me, do as you prefer. What is your rationale? > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

March 10, 2015

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

by Esteban A. Maringolo

2015-03-10 8:43 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Sorry, but the mechanism is one thing, the semantics another. Calling it displayString won't solve the problem. > > The problem is that there is often more than one useful string representation. That's why I said it is a matter of taste. In the end, not having a concrete #asString implementation might be a good choice. Esteban A. Maringolo

March 10, 2015

Re: [Pharo-users] new link to query all projects in smalltalkhub

by Nicolai Hess

2015-03-10 11:50 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > You can now look at > > http://smalltalkhub.com/projectList > > to query all public smalltalkhub projects. > Great! > 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] Why `aFileReference asString = aFileReference fullName` is false?

by Sven Van Caekenberghe

Sorry, but the mechanism is one thing, the semantics another. Calling it displayString won't solve the problem. The problem is that there is often more than one useful string representation. Like for the example at hand. (FileLocator desktop / 'foo.txt') resolve. Has the following #printString File @ /Users/sven/Desktop/foo.txt OK, both of the following make sense /Users/sven/Desktop/foo.txt file:///Users/sven/Desktop/foo.txt But what about native (OS platform) conventions ? I don't want to see Windows backslashes, but Windows user might disagree. There is not one good solution, hence you must use specific accessors/convertors. > On 10 Mar 2015, at 12:20, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > > 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 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