- Pharo-users - lists.pharo.org

deprecation warning in code critic

by Peter UhnÃ¡k

Hi, is there a deprecation warning option in the code critic? Thanks, Peter

March 18, 2015

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

by Nicolai Hess

2015-03-18 22:55 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > e.g. someObject mongoDo: [ ... ]. > > withIndexDo: obeys the principle of least astonishment to me. > > Except the difference between this case and the other examples is that > "withIndex + Do:" reverses the argument order (:e :i). > No, the argument order is perfectly right :) aCollection withIndexDo: == "for each collection element 'e' with index 'i' do: [:e :i | ....]" > > But more importantly, GNU and other Smalltalks have #doWithIndex:. I donât > think that the payoff here is enough to diverge from the rest of the world. > > Lastly, apparently e.g. Dolphin has removed it completely in favor of > #keysAndValuesDo: in response to a change in the ANSI standard. From > http://forum.world.st/doWithIndex-tp3374968p3374975.html : > > #doWithIndex: was in an early ANSI draft, presumably > proposed by one of IBM's representatives but I can't really remember, and > we > had it in the version of Dolphin current at the time. Later it was removed > from the standard and replaced with #keysAndValuesDo:, which makes sense > since a sequenced collection can legimitately represent a "keyed > collection" > with integer keys. Therefore there is no need for a second enumerator that > does the same thing but with key and value reversed. > > > Cheers, > Sean > > ------------------------------ > 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. >

March 18, 2015

Re: [Pharo-users] Pharo and Pi

by kilon alios

I agree with Stef that Pharo needs code that is easy to understand , because code that is easy to understand is far more likely to be maintained. There is little value to boosted performance if you come face to face with show stopper bugs that never get fixed because none dares touch them. Also I am still not convinced that NB is as fast as people claim to be unless I see a very detailed performance test suite that compares NB vs other FFIs side by side. So far it seems to me that people are easily convinced that NB is fast because its based on Assembly code but that is debatable since C is perfectly capable to generate heavily optimized machine code. The one thing that makes NB cool for me is that it can generate machine code on the fly the only downside is that is uses Assembly, which is very verbose and too low level. If NB used C type of syntax for Pharo I think it would be ideal . It would allow you to write C code using Pharo syntax and without a need for a compiler or compiling / linking. In any case none stops anyone from moving NB forward as a third party library. I know I wont be one to do so ;)

March 18, 2015

Re: [Pharo-users] Running startup scripts after the UI has finished

by Peter UhnÃ¡k

After a lot of experimenting and unsuccessful attempts to use both defer: and addDeferredStartupAction: (because I'm probably using it wrong) I ended up with [ myCode ] fork This has not only the wanted behavior of executing after the UI has rendered, but also doesn't freeze the UI when loading external packages. In fact the loader itself seems much responsive. Peter On Tue, Mar 10, 2015 at 6:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Smalltalk addDeferredStartupAction: aBlock. > > aBlock will be executed after startup, as the comment says: > > "Add the monadic or nulladic block to the list of actions that we will be > performed immediately after the startup is totally executed.â > > and > > World defer: aBlock > > aBlock will be executed in the next UI rendering cycle, as the comment > DOES NOT says (because is missing) ;) > > So I think the first one, or the two combined will give you the solution. > > cheers, > Esteban > > > On 10 Mar 2015, at 18:36, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > is it possible to execute startup scripts after the UI has finished > rendering / the image has loaded? > > > > I have install startup script that executes when I create the image, > however since it starts executing very early the UI is frozen and I don't > get any progress bar so I don't know what's happening (since I'm > downloading Roassal and other libraries it can take quite a while.) > > > > Thanks, > > Peter > > >

March 18, 2015

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

by Sean P. DeNigris

> e.g. someObject mongoDo: [ ... ]. > > withIndexDo: obeys the principle of least astonishment to me. > Except the difference between this case and the other examples is that "withIndex + Do:" reverses the argument order (:e :i). But more importantly, GNU and other Smalltalks have #doWithIndex:. I donât think that the payoff here is enough to diverge from the rest of the world. Lastly, apparently e.g. Dolphin has removed it completely in favor of #keysAndValuesDo: in response to a change in the ANSI standard. From http://forum.world.st/doWithIndex-tp3374968p3374975.html : > #doWithIndex: was in an early ANSI draft, presumably > proposed by one of IBM's representatives but I can't really remember, and we > had it in the version of Dolphin current at the time. Later it was removed > from the standard and replaced with #keysAndValuesDo:, which makes sense > since a sequenced collection can legimitately represent a "keyed collection" > with integer keys. Therefore there is no need for a second enumerator that > does the same thing but with key and value reversed. ----- 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 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