February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Question regarding LinkedList collect:

by Nicolas Cellier

I've created http://code.google.com/p/pharo/issues/detail?id=5237 and http://code.google.com/p/pharo/issues/detail?id=5238 Nicolas 2012/2/2 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Sure, but this leaves plenty of room to Andreas for improving LinkedList. > For example, collect: has been improved, but what about select: ? > > { > [(Array withAll: (1 to: 1000)) select: [:e | e even]] bench. > [(LinkedList withAll: (1 to: 1000)) select: [:e | e even]] bench. > }. > -> #('7,240 per second.' '64.3 per second.') > > Also, tell why ((1 to: 10) as: LinkedList) isEmpty, or correct it... > > Your contributions are welcome, via > http://www.pharo-project.org/community/issue-tracking > (I hope the page is up to date). > > Nicolas > > 2012/2/2 Ben Coman <btc(a)openinworld.com>: >> Henrik Johansen wrote: >>> >>> On Feb 2, 2012, at 10:34 AM, Andreas Haufler (scireum GmbH) wrote: >>> >>> >>>> >>>> Hi everyone, >>>> >>>> I'm a Pharo newbie with some knowledge about Smalltalk. Surfing through >>>> the code base I stumbled over the implementation of LinkedList collect: - >>>> Your're right, there is none, it's inherited by SequenceableCollection. >>>> Looking through this code, I discovered that it builds a LinkedList of the >>>> same size and then uses the at: and at:put: selector to copy the transformed >>>> values form the first list to the second. >>>> >>>> Knowing that at: and at:put: have O(n) complexity for linked lists, this >>>> makes collect: an O(n^2) operation. On the other hand, this could easily >>>> changed into O(n) by implementing collect: for LinkedList: >>>> >>>> collect: aBlock Â Â Â Â "Evaluate aBlock with each of the receiver's >>>> elements as the argument. Â Â Â Â Â Collect the resulting values into a >>>> collection like the receiver. Answer Â Â Â Â the new collection." >>>> >>>> Â Â Â Â | newCollection | >>>> Â Â Â Â newCollection := self species new. >>>> Â Â Â Â self do: >>>> Â Â Â Â Â Â Â Â [:val | >>>> Â Â Â Â Â Â Â Â newCollection add: (aBlock value: val)]. >>>> Â Â Â Â ^ newCollection >>>> >>>> I profiled this using: >>>> x := LinkedList new. >>>> 1 to: 10000 do: [:n |x add: n]. >>>> TimeProfileBrowser onBlock: [ x collect: [:i | i] ] >>>> >>>> and saw a improvement of: 795msec (old) vs. 6msec (new). >>>> >>>> I wonder therefore, if LinkedList is just seldomly used (in Java i.e. >>>> nearly all lists use ArrayList nowadays)? Or would the system benefit from >>>> this improvement? I could then look through the other methods >>>> (collect:from:to: et. al.) and provide a patch. >>>> >>>> >>>> best regards + thank's for creating such a beautiful system >>>> Andreas Haufler >>>> >>> >>> >>> It does suffer from being a subclass of SequenceableCollection where >>> default implementations assume O(1) at: and at:put: implementationsâ¦ >>> You're right it's not often used (at least not polymorphical to normal >>> collections), and as such it's a tradeoff between keeping the implementation >>> small (by using slow, but working super implementations), and reimplementing >>> methods efficiently. >>> >>> In this case though, it seems Alain already noticed, and collect: has >>> already been reimplemented efficiently in 1.4 >>> >>> Cheers, >>> Henry >>> >>> >> >> Henrik, >> Please note that I've only picked this as an example since it occurred >> coincidently with my having just read the insightful slides of the >> "[Pharo-project] Building a developer community" thread - but in light of >> that... >> >> While your answer was good technically, it was not as good as it could be >> for "building Pharo's developer community". Â Here a "visitor" with >> reasonable Smalltalk ability extended a helping hand. Â The response returned >> was a polite "we are doing good on our own thanks" - which is fine except >> except it does not draw them in. Â An alternative might have included "its >> already been done but come and have a look at it. Â It would be great if you >> could help out with (other stuff)" >> >> Now some disclaimers... >> * I did stretch the example since Alain is a third party whom you can't just >> throw Andreas at unannounced. >> * There has been little time for anyone else to answer >> * I don't mean to posts should be constrained by kid gloves. >> >> Hopefully though this is a useful perspective to mix in with everything else >> important. >> warm regards, >> Ben >>

Feb. 2, 2012

[Pharo-project] ConfigurationOfCitezen - any bugs?

by Schwab,Wilhelm K

Hello all, I am making progress toward building a 1.3 image, but I am getting a hung system when loading (#loadNoWeb) Citezen. Is this a known problem? Bill

Feb. 2, 2012

Re: [Pharo-project] keeping up with lively-kernel (morphic)

by Marcus Denker

On Feb 2, 2012, at 7:27 PM, Lawson English wrote: > I apparently misread some of the papers. I can't find mention of how Morphic was ported, though the ability to use smalltalk inside an LK morph suggests that there is some expectation of reuse of code or perhaps they simply wanted Smalltalk programmers to feel more comfortable with LK morphs from the start. > When I looked at the first LK release I was very disappointed. Why do the same than in Squeak? If you do the same you can just use Squeak, not fight against JS to get the same... "I did the same but in JavaScript". Why? I never understood the goal of LK, I have to admit. I thought that they would have moved on in the meantime. If not, this is a huge mistake. Morphic needs to be redone, not ported to Javascript 1-to-1. Marcus -- Marcus Denker -- http://marcusdenker.de

Feb. 2, 2012

Re: [Pharo-project] keeping up with lively-kernel (morphic)

by Lawson English

I apparently misread some of the papers. I can't find mention of how Morphic was ported, though the ability to use smalltalk inside an LK morph suggests that there is some expectation of reuse of code or perhaps they simply wanted Smalltalk programmers to feel more comfortable with LK morphs from the start. L. On 2/2/12 11:00 AM, Marcus Denker wrote: > On Feb 2, 2012, at 6:56 PM, Lawson English wrote: > >> My understanding is that one of the design-specs of Lively Kernel Morph was to allow easy porting of the original Smalltalk-based Morphs to LK. > If they did that, they did a mistake. Do you really want to be compatible to Squeak Morphic? To that mess? > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > >

Feb. 2, 2012

Re: [Pharo-project] keeping up with lively-kernel (morphic)

by StÃ©phane Ducasse

On Feb 2, 2012, at 7:16 PM, dimitris chloupis wrote: > curious , do you basically say that Pharo community searches for a way to get rid and replace Morphic in Pharo ? improve it or replace it if someone propose something better :). Stef > > > > From: Marcus Denker <marcus.denker(a)inria.fr> > To: Pharo-project(a)lists.gforge.inria.fr; lenglish5(a)cox.net > Sent: Thursday, 2 February 2012, 20:00 > Subject: Re: [Pharo-project] keeping up with lively-kernel (morphic) > > > On Feb 2, 2012, at 6:56 PM, Lawson English wrote: > > > My understanding is that one of the design-specs of Lively Kernel Morph was to allow easy porting of the original Smalltalk-based Morphs to LK. > > If they did that, they did a mistake. Do you really want to be compatible to Squeak Morphic? To that mess? > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > >

Feb. 2, 2012

Re: [Pharo-project] A couple more questions on traits

by StÃ©phane Ducasse

On Feb 2, 2012, at 6:27 PM, Markus Rother wrote: > Hi, > > I just got done reading the paper "Traits: Composable Units of Behaviour". > In general, I think the concept is massively underrated and has tons of potential. > I can recommend the paper to anyone to make up one's mind about inheritance issues. > > I did not yet try to use traits in Pharo, myself. But Two things came to my mind that were not quite clear from your paper, Stef and other authors in case you are following this list... > > * Why aren't getter methods defined within a trait? > Imho that would make a lot of sense. If you apply a trait, but don't like the getter/setter, then override it - no big deal. Why don't you include them as default in the trait? because we did not know at compile time of the accessor the offset of the instance variables. Now I would love seen people doing another pass on what we did. And I would love to have slot and other cool compiler infrastructure and meta model so that we can rethink everything. > * When do unresolved conflicts error? > Runtime vs. compile-time? composition time > > Thanks, and keep it up. > Markus >

Feb. 2, 2012

Re: [Pharo-project] keeping up with lively-kernel (morphic)

by dimitris chloupis

curious , do you basically say that Pharo community searches for a way to get rid and replace Morphic in Pharo ? ________________________________ From: Marcus Denker <marcus.denker(a)inria.fr> To: Pharo-project(a)lists.gforge.inria.fr; lenglish5(a)cox.net Sent: Thursday, 2 February 2012, 20:00 Subject: Re: [Pharo-project] keeping up with lively-kernel (morphic) On Feb 2, 2012, at 6:56 PM, Lawson English wrote: > My understanding is that one of the design-specs of Lively Kernel Morph was to allow easy porting of the original Smalltalk-based Morphs to LK. If they did that, they did a mistake. Do you really want to be compatible to Squeak Morphic? To that mess? Â Â Â Marcus -- Marcus Denker -- http://marcusdenker.de

Feb. 2, 2012

Re: [Pharo-project] keeping up with lively-kernel (morphic)

by Marcus Denker

On Feb 2, 2012, at 6:56 PM, Lawson English wrote: > My understanding is that one of the design-specs of Lively Kernel Morph was to allow easy porting of the original Smalltalk-based Morphs to LK. If they did that, they did a mistake. Do you really want to be compatible to Squeak Morphic? To that mess? Marcus -- Marcus Denker -- http://marcusdenker.de

Feb. 2, 2012

Re: [Pharo-project] keeping up with lively-kernel (morphic)

by Lawson English

My understanding is that one of the design-specs of Lively Kernel Morph was to allow easy porting of the original Smalltalk-based Morphs to LK. To that end, they incorporate the OMeta parser with a built-in St to JS translator. L. On 2/2/12 10:34 AM, Marcus Denker wrote: > On Feb 2, 2012, at 6:31 PM, dimitris chloupis wrote: > >> Well if there is a widget that can be easily ported and be useful to people I dont see any harm in taking an interest in other Morphic implementations. >> > No, you don't understand. Morphic is not a code base that is compatible. It's a pattern. Like MVC. Imagine someone requesting form Smalltlak > to work with, what, Ruby on Rails because they are the ones that "define the future of MVC". > > Patterns are abstract ideas. Of course you can be inspired by ideas. But that is not "working together". > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > >

Feb. 2, 2012

Re: [Pharo-project] keeping up with lively-kernel (morphic)

by dimitris chloupis

ok so you basically sayÂ differentÂ Morphics areÂ differentÂ architectures,Â differentÂ method/functions names, diffirent class names and generally different workflows ? If that is the case, yes in that case I can see the reason behind the lack of interest. Â By default anyway LK Morphic and Pharo Morphic cant be compatible cause LK uses JS and Pharo uses ST.Â I am not saying that you should work together though . Thats completely up to you. I will certainly will not ask for LK's permission or even your permission for my Morpheas library. I can appreciate that. Thats the beauty of open source , the freedom to follow your own path.Â ________________________________ From: Marcus Denker <marcus.denker(a)inria.fr> To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> Sent: Thursday, 2 February 2012, 19:34 Subject: Re: [Pharo-project] keeping up with lively-kernel (morphic) On Feb 2, 2012, at 6:31 PM, dimitris chloupis wrote: > Well if there is a widget that can be easily ported and be useful to people I dont see any harm in taking an interest in other Morphic implementations. > No, you don't understand. Morphic is not a code base that is compatible. It's a pattern. Like MVC. Imagine someone requesting form Smalltlak to work with, what, Ruby on Rails because they are the ones that "define the future of MVC". Patterns are abstract ideas. Of course you can be inspired by ideas. But that is not "working together". Â Â Â Marcus -- Marcus Denker -- http://marcusdenker.de

Feb. 2, 2012