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

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

by phil＠highoctane.be

Le 14 mars 2015 12:16, "Sebastian Sastre" <sebastian(a)flowingconcept.com> a Ã©crit : > > In such cases I might use a stream and monitor the `stream position` and iterate with > > [ stream atEnd ] whileFalse: [ > item := stream next. > stream position even ifTrue: [ self highlight: item ]. > .... ] > Exactly! Streams and collections are perfect for that. And they can even do: ReadStream class >> on:from:to: or upTo: etc. Phil > from mobile > > > On 10/03/2015, at 09:11, Sanjay Minni <sm(a)planage.com> wrote: > > > > 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 18, 2015

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

by phil＠highoctane.be

Le 16 mars 2015 11:59, "Nicolai Hess" <nicolaihess(a)web.de> a Ã©crit : > > > 2015-03-14 11:55 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: >> >> Marcus Denker-4 wrote >> > which version do we pick? We should pick one, rename the callers >> >> As someone mentioned earlier in the thread, #doWithIndex: has the advantage >> of mirroring the argument order (although this still should be documented), >> and it's the one most people are probably most familiar with, so IMHO it >> makes sense to standardize on that. > > > I like withIndexDo: because code like > > aCollection withIndexDo: aBlock > reads like > "a collection with index" do > I like things ending with do: as they are easy to spot. And you know that is coming next is a block most of the time. Not so with doWithIndex: e.g. someObject mongoDo: [ ... ]. reads better than someObject doWithMongo: [ ]. especially when there are things like mongoDo: mongoCachedCollectionsDo: aggregateDo: and so on. This is the same story with ... readStreamDo: [ ] withIndexDo: obeys the principle of least astonishment to me. Phil > > > >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> 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 18, 2015

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

by stepharo

so may be we should open a bug entry and make sure that doWithIndex: is used in the system. no? Le 16/3/15 12:19, jtuchel(a)objektfabrik.de a Ã©crit : > Nicolai, > > > > > > Am 16.03.15 um 11:59 schrieb Nicolai Hess: >> >> 2015-03-14 11:55 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com >> <mailto:sean@clipperadams.com>>: >> >> Marcus Denker-4 wrote >> > which version do we pick? We should pick one, rename the callers >> >> As someone mentioned earlier in the thread, #doWithIndex: has the >> advantage >> of mirroring the argument order (although this still should be >> documented), >> and it's the one most people are probably most familiar with, so >> IMHO it >> makes sense to standardize on that. >> >> >> I like withIndexDo: because code like >> > so how would you name the current #do: if you had the choice? > > I still think this looks very logical: > > #do: > #do:separatedBy: > #doWithIndex: > #doWithSomeOtherSpecialty:andEvenMoreStuff: > > And then there still ist the question if the order of the arguments > should be changed: > > today: > > do: [:each| ] > doWithIndex: [:each :index| ] > > future: > > do: [:each| ] > withIndexDo: [:idx :each | ] > > Do you really think that is better? > > I think that if we move the withIndex part to the beginning of the > message, it overstates the importance of the fact that we also need > the index inside the iteration block. > > > >> aCollection withIndexDo: aBlock >> reads like >> "a collection with index" do >> > This would make sense if it was a Collection with an Index. If there > was an IndexedCollection class and maybe some message like > asIndexedCollection or withIndex, which turns any collection into an > IndexedCollection. Then the message might be a shortcut for "make thsi > an indexed collection and iterate over it using its index" - > comparable to Dictionary>>#keysAndValuesDo: - but please be aware that > a Dictionary has keys and values by its very own nature. A Collection > doesn't have an index (other than the fact that the elements are > stored in some non-guarantueed order). > > > This may all sound quite picky, but I think this is plain wrong and > you are about to introduce not only incompatible, but also misleading > naming for methods that exist on all Smalltalk dialects. > > Joachim > >> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> 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. >> >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchelmailto:jtuchel@objektfabrik.de > Fliederweg 1http://www.objektfabrik.de > D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >

March 18, 2015

Re: [Pharo-users] Pharo and Pi

by stepharo

> Stef wrote: >> Our goal is to remove the dependencies to nativeboost. > I know that FFI is now maintained again and there is some initiative > on a (more) unified FFI. Also there may be some issues with NB: harder to > understand than FFI, not complete for ARM, ... not working with Spur, not working with 64bits > Also for Apple devices it is not able to generate/perform machine code > in memory. But when you go native you usually have to take care of the > underlying system anyway. > > But if I understood correctly all this new improvements/movements away from > NB will be at the cost of performance: FFI will slower than NB. Or did I > misunderstood? probably in the first period. > The only issues I had with NB so far ist that it initially takes > some effort to know the details. But it worked great once one get > used to it and I like that Pharo gets fast with it... Me too. But between fast on principle and not working in reality and slower and working, I chose the second. I want Pharo to run on Spur. > > Why not complete 64 bit, AsmJIT/NB for ARM beside x86 and where possible > provide the NB layer? Do you know how to do it? Should we burn months of Esteban to learn it so that after he can extend it. Should we be relying on the knowledge of one single person? > For other platforms we can fall back to FFI when needed. > For sure there could be a more unified way to call. I spent 14 000 Euros on my budget to pay max as intern to work on virtualCPU with igor so that NB could take advantage of having a CPU abstraction. They worked great and hard. But NB was never updated to take advantage of virtualCPU and probably virtual CPU was not totally finished. I thought that Igor would continue to improve NB and use Virtual CPU but I was wrong. To me this is a pure lost of money and max should have worked on updates. So I learned something: I will not pay interns on projects that I cannot use/or maintain myself I was stupid but I'm learning. > > Maybe thats the goal of the unified FFI and I just do not know the > details. Maybe NB is already planned as a possible backend and it is > still possible to use it. Or will it be legacy afterwards? NB will be a possible backend if uFFI happens and if NB works with the system. So the first step is use NB syntax for "uFFI front end" provide FFI as back-end hope that ronie delivers low end hope that igor release NB Spur > > I do not care if it is called "NB" or "FFI" or other, but I would dislike if I had > to give up performance or native possibilities or if we just throw away > something that was developed/integrated with effort into the image initially. I can tell you that I did my best (and even more) but that this is not something that I can control. If Igor turned into a pumpskin is not my fault or wish. He always got all my support (you can ask the team here). Now there is a lesson in that story: we should not rely on a single person. > > I guess more info or patience is required... We want Pharo on Spur! This is key for clement's works and for all the community. Stef

March 18, 2015

Pharo and Pi

by Torsten Bergmann

Stef wrote: >Our goal is to remove the dependencies to nativeboost. I know that FFI is now maintained again and there is some initiative on a (more) unified FFI. Also there may be some issues with NB: harder to understand than FFI, not complete for ARM, ... Also for Apple devices it is not able to generate/perform machine code in memory. But when you go native you usually have to take care of the underlying system anyway. But if I understood correctly all this new improvements/movements away from NB will be at the cost of performance: FFI will slower than NB. Or did I misunderstood? The only issues I had with NB so far ist that it initially takes some effort to know the details. But it worked great once one get used to it and I like that Pharo gets fast with it... Why not complete 64 bit, AsmJIT/NB for ARM beside x86 and where possible provide the NB layer? For other platforms we can fall back to FFI when needed. For sure there could be a more unified way to call. Maybe thats the goal of the unified FFI and I just do not know the details. Maybe NB is already planned as a possible backend and it is still possible to use it. Or will it be legacy afterwards? I do not care if it is called "NB" or "FFI" or other, but I would dislike if I had to give up performance or native possibilities or if we just throw away something that was developed/integrated with effort into the image initially. I guess more info or patience is required...

March 18, 2015

Re: [Pharo-users] Users of Versionner?

by stepharo

I use it but I often code by hand the configurations ;) Le 18/3/15 09:46, Stephan Eggermont a Ã©crit : > Who is actually using Versionner to maintain configurations? > Especially configurations that are used in other configurations? > > Stephan > > > >

March 18, 2015

Re: [Pharo-users] Pharo and Pi

by stepharo

Our goal is to remove the dependencies to nativeboost. So we will release Pharo 40 and esteban will work on an FFI to remove NB. Stef Le 18/3/15 16:33, Sebastian Heidbrink a Ã©crit : > Hi Torsten, > > we tried to start pharo 4.0 on the Parallella board , which is somehow > like the Pi2 and did succeed partially. > > The problem with Pharo4 and the VM is that there is no NativeBoost nor > OSProcess available o ARM VMs. > > I just strated to do some reseach on this and can't provide more > information on this but jsut google: > "vm pharo arm nativeboost Can't find the requested origin" > > you can start the image, you can save it, you can load source, but you > can't use stuff like VirtualGPU yet. > > The VMs I tried were all from Inria's jenkins servers. > > Sebastian > > > > > Am 18.03.2015 um 07:35 schrieb Torsten Bergmann: >> Read about "piCore" this week which is a Tiny Core Linux >> for the Pi. >> >> As there is >> - a quick bootable Pharo on top of TinyLinux (Mikes "PharoNOS" >> project) >> - a Pharo that is runnable on Pi >> >> I wonder if anyone already did some experiments on booting directly >> into Pharo on a pi. >> >> Still a "pi newbee" I also would like to know how to get started to >> Pharo on Pi. Seems like the CI job is not available: >> >> https://ci.inria.fr/pharo-contribution/computer/RaspberryPi/ >> >> Where to get started with Pharo on Pi these days? Any "quick >> guide"? >> >> Thx >> T. >> >> > > >

March 18, 2015

Re: [Pharo-users] Pharo and Pi

by itlists＠schrievkrom.de

As I posted on my blog yesterday: Pharo 3 is running. Marten Am 18.03.2015 um 15:35 schrieb Torsten Bergmann: > Read about "piCore" this week which is a Tiny Core Linux > for the Pi. > > As there is > - a quick bootable Pharo on top of TinyLinux (Mikes "PharoNOS" project) > - a Pharo that is runnable on Pi > > I wonder if anyone already did some experiments on booting directly > into Pharo on a pi. > > Still a "pi newbee" I also would like to know how to get started to > Pharo on Pi. Seems like the CI job is not available: > > https://ci.inria.fr/pharo-contribution/computer/RaspberryPi/ > > Where to get started with Pharo on Pi these days? Any "quick > guide"? > > Thx > T. > -- Marten Feldtmann

March 18, 2015

Pharo and Pi

by Torsten Bergmann

thanks for your answers so far >we tried to start pharo 4.0 on the Parallella board OK, but I would like to give the original PI a try. Especially because there are nice additions like the Tontec mini touch screen, etc. >The problem with Pharo4 and the VM is that there is no NativeBoost nor >OSProcess available o ARM VMs. Yes NB is x86 so far. Mhh... without OSProcess or NB one can not issue commands to the underlying system (like Tiny Linux). >you can start the image, you can save it, you can load source At least it is a start and it runs. I guess I would be able to run Teapot at least. So one can use it as a simple Pharo based web (app) serving machine. Right? Is Filesystem access working (FileBrowser)? Bye T.

March 18, 2015

Re: [Pharo-users] Pharo and Pi

by Sebastian Heidbrink

Hi Torsten, we tried to start pharo 4.0 on the Parallella board , which is somehow like the Pi2 and did succeed partially. The problem with Pharo4 and the VM is that there is no NativeBoost nor OSProcess available o ARM VMs. I just strated to do some reseach on this and can't provide more information on this but jsut google: "vm pharo arm nativeboost Can't find the requested origin" you can start the image, you can save it, you can load source, but you can't use stuff like VirtualGPU yet. The VMs I tried were all from Inria's jenkins servers. Sebastian Am 18.03.2015 um 07:35 schrieb Torsten Bergmann: > Read about "piCore" this week which is a Tiny Core Linux > for the Pi. > > As there is > - a quick bootable Pharo on top of TinyLinux (Mikes "PharoNOS" project) > - a Pharo that is runnable on Pi > > I wonder if anyone already did some experiments on booting directly > into Pharo on a pi. > > Still a "pi newbee" I also would like to know how to get started to > Pharo on Pi. Seems like the CI job is not available: > > https://ci.inria.fr/pharo-contribution/computer/RaspberryPi/ > > Where to get started with Pharo on Pi these days? Any "quick > guide"? > > Thx > T. > >

March 18, 2015