- Pharo-users - lists.pharo.org

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

by Thierry Goubier

Hi Sanjay, 2015-03-10 14:47 GMT+01:00 Sanjay Minni <sm(a)planage.com>: > > sorry folks ... > > so back to terra firma ... > > 1. Is there any way to query an object to finds its index value in the > original collection ... > say when all the objects from a collection are displayed and user clicks on > one item - I want to locate the object back in the collection. Knowing the > index for me would be most efficient. > aCollection indexOf: anElement You will often find this code in list-related gui objects. > > 2. ... also Is there any way to know if I am on the last element ... > aCollection last == anElement > > otherwise I will have to explicitly store the index values ... > If you do it more than once per iteration of the collection, it is probably faster to store the indexes. But I wouldn't do it for anything GUI related; indexOf: is efficient enough. Regards, Thierry

March 10, 2015

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

by Sanjay Minni

sorry folks ... so back to terra firma ... 1. Is there any way to query an object to finds its index value in the original collection ... say when all the objects from a collection are displayed and user clicks on one item - I want to locate the object back in the collection. Knowing the index for me would be most efficient. 2. ... also Is there any way to know if I am on the last element ... otherwise I will have to explicitly store the index values ... regards Sanjay jtuchel wrote > Marcus > > So sorry for this false accusation. It is proprietary in Squeak. > And even if it was Dan's idea to rename it, I'd like to learn more about > the > reasoning. > My understanding would be: > > [...] ----- --- 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] when iterating over a collection how to determine the current objects index

by Joachim Tuchel

Marcus So sorry for this false accusation. It is proprietary in Squeak. And even if it was Dan's idea to rename it, I'd like to learn more about the reasoning. My understanding would be: #do: iterates over a collection #doWithIndex: iterates over a collection and also keeps track of the current index. Sounds very consistent to me. the most important thing I want the machine to do is iterate over the collection, and the index thing is just a variant thereof. #do: iterates over a collection #withIndexDo: keeps track of the index while iterating over a collection Sounds clumsy to me. Introduces incompatibilities for not much value. If people complained about #do: as not intentioon revealing and opted to rename it to something like #withEachDo: , then I could understand it. The variant could be #withEachDoIndexed: But not that one ;-) ... but this is completely off-topic of course... Joachim > Marcus Denker <marcus.denker(a)inria.fr> hat am 10. MÃ¤rz 2015 um 14:32 > geschrieben: > > > > > > On 10 Mar 2015, at 14:25, Joachim Tuchel < > > > jtuchel(a)objektfabrik.de <mailto:jtuchel@objektfabrik.de> > wrote: > > > > Sounds like a bad naming to me. I don't see why withIndexDo is any > > better. It even contradicts the order of the arguments. And it is > > Proprietary to Pharo. > > > > > > > > No, if you look a the timeStamp it was done in 1997 by Dan. > > > > > Joachim > > > > > > Am 10.03.2015 um 13:39 schrieb Sanjay Minni < sm(a)planage.com > > <mailto:sm@planage.com> >: > > > > > > > > > Yes usually I have to open the code and see, use > > > > > intuition or write a sample code to find out > > > incidentally here I also have to figure out which is the current > > > and which is the deprecated version ... well thats it > > > > > > sanjay > > > > > > > > > --- > > > Sanjay Minni > > > +91-9900-902902 > > > http://in.linkedin.com/in/sanjayminni > > > > > > On Tue, Mar 10, 2015 at 5:57 PM, Thierry Goubier [via Smalltalk] > > > <[hidden email]> wrote: > > > > > > > And one has to guess that elementAndIndexBlock > > > > > > > means > > > > > > > > [:each :i | ... ] ? (and of course not [:i :each | ... ] ) > > > > > > > > I'm allways looking for senders with that type of code ;) > > > > arguments to blocks are usually not documented. > > > > > > > > Thierry > > > > > > > > 2015-03-10 13:27 GMT+01:00 Peter UhnÃ¡k <[hidden email] > > > > <http:/user/SendEmail.jtp?type=node&node=4810931&i=0> >: > > > > > > > > > On Tue, Mar 10, 2015 at 1:23 PM, Joachim > > > > > > > > > Tuchel <[hidden email] > > > > > > > > > <http:/user/SendEmail.jtp?type=node&node=4810931&i=1> > > > > > > > > > > wrote: > > > > > > > > > > > #doWithIndex: ? > > > > > > > > > > > > > > > > doWithIndex: elementAndIndexBlock > > > > > "Use the new version with consistent naming" > > > > > ^ self withIndexDo: elementAndIndexBlock > > > > > > > > > > > > > > > > > > > > > --------------------------------------------- > > > > If you reply to this email, your message will be added to the > > > > discussion below: > > > > > > > > http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the… > > > > To unsubscribe from when iterating over a collection how to > > > > determine the current objects index, click here. > > > > NAML > > > > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > > > > > > > > > > --- > > > Regards, Sanjay > > > > > > > > > --------------------------------------------- > > > View this message in context: Re: when iterating over a > > > collection how to determine the current objects index > > > <http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the…> > > > Sent from the Pharo Smalltalk Users mailing list archive > > > <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com > > > <http://nabble.com/> . > > > > > > > > > > >

March 10, 2015

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

by Thierry Goubier

2015-03-10 14:13 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > > > >> >> 2015-03-10 13:27 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> >>> On Tue, Mar 10, 2015 at 1:23 PM, Joachim Tuchel <jtuchel(a)objektfabrik.de >>> > wrote: >>> >>>> #doWithIndex: ? >>>> >>> >>> doWithIndex: elementAndIndexBlock >>> "Use the new version with consistent naming" >>> ^ self withIndexDo: elementAndIndexBlock >>> >> >> On Tue, Mar 10, 2015 at 8:36 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> And one has to guess that elementAndIndexBlock means >> >> [:each :i | ... ] ? (and of course not [:i :each | ... ] ) >> > > The Principle Of Least Surprise would imply that the variables appear in > the same order that they appear in the method name. Of course that doesn't > mean you don't get surprised sometimes. Are there any that don't follow > that rule? We should consider fixing them. > In Pharo 4. GLMTableColumn>>#modifiedBlock: anObject. I tried to follow the trail and it's a three arguments block, according to GLMTreeMorphNodeModel>>#rowMorphForColumn: , since we see: aGlamourColumn modifiedBlock cull: contentMorph text cull: self item cull: self containerTree glamourPresentation Following senders, I have GLMTablePresentation>>column: aBlockOrString evaluated: aBlock modified: aModifiedBlock, (still no documentation) and: GTObjectVariablesBrowser>>variablesIn: composite where I find: column: 'Value' evaluated: [:assoc | GTObjectPrinter new asTruncatedTextFrom: assoc value ] modified: [:newValue :assoc :presentation | self updateInstanceVariable: assoc key from: presentation entity basedOn: newValue. presentation update ]; Now, I know :) A good experience: use a finder or spotter, search for senders of cull:cull:cull:. I choose the first one I found for the example above (I have a memory of some which were annoying, in Morphic or Spec, but couldn't remember which ones). It would be interesting if something like autocompletion could supply the > template for the block. > Ouch. It would not be easy, but possible. A pragma ? ;) Thierry

March 10, 2015

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

by Marcus Denker

> On 10 Mar 2015, at 14:25, Joachim Tuchel <jtuchel(a)objektfabrik.de> wrote: > > Sounds like a bad naming to me. I don't see why withIndexDo is any better. It even contradicts the order of the arguments. And it is Proprietary to Pharo. > No, if you look a the timeStamp it was done in 1997 by Dan. > Joachim > > > Am 10.03.2015 um 13:39 schrieb Sanjay Minni <sm(a)planage.com <mailto:sm@planage.com>>: > >> Yes usually I have to open the code and see, use intuition or write a sample code to find out >> incidentally here I also have to figure out which is the current and which is the deprecated version ... well thats it >> >> sanjay >> >> >> --- >> Sanjay Minni >> +91-9900-902902 >> http://in.linkedin.com/in/sanjayminni <http://in.linkedin.com/in/sanjayminni> >> On Tue, Mar 10, 2015 at 5:57 PM, Thierry Goubier [via Smalltalk] <[hidden email] <x-msg://6/user/SendEmail.jtp?type=node&node=4810945&i=0>> wrote: >> And one has to guess that elementAndIndexBlock means >> >> [:each :i | ... ] ? (and of course not [:i :each | ... ] ) >> >> I'm allways looking for senders with that type of code ;) arguments to blocks are usually not documented. >> >> Thierry >> >> 2015-03-10 13:27 GMT+01:00 Peter UhnÃ¡k <[hidden email] <http://user/SendEmail.jtp?type=node&node=4810931&i=0>>: >> On Tue, Mar 10, 2015 at 1:23 PM, Joachim Tuchel <[hidden email] <http://user/SendEmail.jtp?type=node&node=4810931&i=1>> wrote: >> #doWithIndex: ? >> >> doWithIndex: elementAndIndexBlock >> "Use the new version with consistent naming" >> ^ self withIndexDo: elementAndIndexBlock >> >> >> >> If you reply to this email, your message will be added to the discussion below: >> http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the… <http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the…> >> To unsubscribe from when iterating over a collection how to determine the current objects index, click here <applewebdata://B2A91C9C-780D-40B2-9C35-3155BCAFCB80>. >> NAML <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> >> --- >> Regards, Sanjay >> >> View this message in context: Re: when iterating over a collection how to determine the current objects index <http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the…> >> Sent from the Pharo Smalltalk Users mailing list archive <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com <http://nabble.com/>.

March 10, 2015

Re: [Pharo-users] Cleaning changes file?

by Marcus Denker

> On 10 Mar 2015, at 14:17, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > >> On Mar 10, 2015, at 03:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> You can do that using the expression: >>> >>> PharoChangesCondenser condense >>> >>> Although that also means you lose the version history of methods inside your image. This is typically not done a lot, maybe for production deploy, maybe for release of Pharo itself. >>> >>> >> Yes, but we need to change that. The artefact on the CI server needs to be the artefact of release. We should not have *anything* of the kind âand a day before release we call Xâ. >> Because for sure it will be broken. And we waste resources: the changes are the history of the revision control system. > > OK so a silly and not-so-innocent question: Why not include that in the build script *right now* ? It has to be done some time, and now the discussion is open why not make use of the opportunity? > > Also, my use of the changes file is uniquely to recover in case of a crash. With condensed changes for every daily build I download this would make my recovery just that bit easier. One small change â¦ > >From a size point of view it would make sense: a âPharo4.sourcesâ is even a bit smaller than the current .changes (which itself would be empty). Compressed it would be 15,7 instead of 13,7 due to the .changes being better compressible (it contains much useless things even by that metricâ¦) The problem is that we would need to see how it plays with the get.pharo.org <http://get.pharo.org/> where the vm download contains all of Pharo1, Pharo2 and Pharo3 sourcesâ¦ This is a real messâ¦ I am locking forward to a time when we just have one .pharo image. Marcus

March 10, 2015

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

by Joachim Tuchel

Sounds like a bad naming to me. I don't see why withIndexDo is any better. It even contradicts the order of the arguments. And it is Proprietary to Pharo. Joachim > Am 10.03.2015 um 13:39 schrieb Sanjay Minni <sm(a)planage.com>: > > Yes usually I have to open the code and see, use intuition or write a sample code to find out > incidentally here I also have to figure out which is the current and which is the deprecated version ... well thats it > > sanjay > > > --- > Sanjay Minni > +91-9900-902902 > http://in.linkedin.com/in/sanjayminni > >> On Tue, Mar 10, 2015 at 5:57 PM, Thierry Goubier [via Smalltalk] <[hidden email]> wrote: >> And one has to guess that elementAndIndexBlock means >> >> [:each :i | ... ] ? (and of course not [:i :each | ... ] ) >> >> I'm allways looking for senders with that type of code ;) arguments to blocks are usually not documented. >> >> Thierry >> >> 2015-03-10 13:27 GMT+01:00 Peter UhnÃ¡k <[hidden email]>: >>>> On Tue, Mar 10, 2015 at 1:23 PM, Joachim Tuchel <[hidden email]> wrote: >>>> #doWithIndex: ? >>> >>> doWithIndex: elementAndIndexBlock >>> "Use the new version with consistent naming" >>> ^ self withIndexDo: elementAndIndexBlock >> >> >> >> If you reply to this email, your message will be added to the discussion below: >> http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the… >> To unsubscribe from when iterating over a collection how to determine the current objects index, click here. >> NAML > > --- > Regards, Sanjay > > View this message in context: Re: when iterating over a collection how to determine the current objects index > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 10, 2015

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

by Sanjay Minni

Is there a way to query an object to its index value otherwise in withIndexDo: I have to explicitly store the index values if I need it later in some cases 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] GTTools and Mongo

by Johan Fabry

Excellent !! > On Mar 10, 2015, at 06: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> ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

March 10, 2015

Re: [Pharo-users] Cleaning changes file?

by Johan Fabry

> On Mar 10, 2015, at 03:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> You can do that using the expression: >> >> PharoChangesCondenser condense >> >> Although that also means you lose the version history of methods inside your image. This is typically not done a lot, maybe for production deploy, maybe for release of Pharo itself. >> >> > Yes, but we need to change that. The artefact on the CI server needs to be the artefact of release. We should not have *anything* of the kind âand a day before release we call Xâ. > Because for sure it will be broken. And we waste resources: the changes are the history of the revision control system. OK so a silly and not-so-innocent question: Why not include that in the build script *right now* ? It has to be done some time, and now the discussion is open why not make use of the opportunity? Also, my use of the changes file is uniquely to recover in case of a crash. With condensed changes for every daily build I download this would make my recovery just that bit easier. One small change ... ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

March 10, 2015