- Pharo-dev - lists.pharo.org

Re: [Pharo-project] keeping up with lively-kernel (morphic)
by Fernando Olivero Feb. 3, 2012

Feb. 3, 2012

Pharo is not only targeted at business..you can do research and other cool stuff on top of it. For example, Athens, Ring, the new Event-Model, and many other enhancements and additions to Pharo over the recent years, enable the development of new UI frameworks, in an easier and more elegant manner than before. Fernando On Fri, Feb 3, 2012 at 8:59 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Feb 2, 2012, at 11:21 PM, Helene Bilbo wrote: > >> >> Marcus Denker-4 wrote >>> >>> So there are multiple problems: >>> >>> 1) Morphic is not and API or a codebase but and idea (or principle) >>> And the question is even: a good one? In the current state for sure not. >>> For sure it's instantiation depends *a lot* on the language >>> model you have. >>> >> >> I think exactly the Morphic ideas (or principles) (not the squeak morphic >> code or the missing documentation or a morphic implementation in javascript) >> were so very charming, elegant and intriguing. Directly manipulating, >> combining Objects/Morphs and - as i read in this paper about LivelyKernel >> [1] - serializing them. >> >> But as i understood the Pharo Vision Document, Pharo is more aimed at >> business customers and therefor strives for being similar to other business >> oriented smalltalks rather than becoming Squeak with cleaner and smaller >> code and better documentation (which would have been also a very nice goal)? > > Pharo wants to be a platform where people can innovate so if you want to innovate at the UI level (for example Gaucho) > you need a good and flexible infrastructure. > > > >> >> [1] >> http://www.hpi.uni-potsdam.de/hirschfeld/publications/media/LinckeKrahnInga… >> >> -- >> View this message in context: http://forum.world.st/keeping-up-with-lively-kernel-morphic-tp4349125p43530… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

1 0

[Pharo-project] [ANN] Shared Smalltalk Workspaces
by Sven Van Caekenberghe Feb. 3, 2012

Feb. 3, 2012

Hi, I hacked together a little web service called 'Shared Smalltalk Workspaces'. http://ws.stfx.eu It is basically a pastebin for Smalltalk, a way easily to share Smalltalk workspaces. Follow the link above for the details. There is a special 'Getting Started' workspace with instructions http://ws.stfx.eu/1WS4U Here are 2 more examples http://ws.stfxeu/8O58R5KF1FLQ http://ws.stfxeu/8O58TU6FNFL6 Enjoy ! Sven PS: Of course, it is built and served using Pharo 1.4 -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

5 7

Re: [Pharo-project] Cog+linux: external module not found
by Schwab,Wilhelm K Feb. 3, 2012

Feb. 3, 2012

Eliot, I'm getting the same error with your latest VM. Any ideas? Bill ________________________________ From: Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Friday, January 06, 2012 5:37 PM To: Schwab,Wilhelm K Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Cog+linux: external module not found On Fri, Jan 6, 2012 at 2:32 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Eliot, I'm getting an external library not found error on Ubuntu lucid with the Cog vm from http://gforge.inria.fr/frs/download.php/29042/CogVM-Unix-13307.zip The library lives in /usr/lib and is known to ldconfig by the name that I have specified in #moduleName. What do I need to do? I don't know. Have you tried the latest Cog linux VM from my site? http://www.mirandabanda.org/files/Cog/VM/VM.r2522/coglinux.tgz Bill -- best, Eliot

11 55

Re: [Pharo-project] keeping up with lively-kernel (morphic)
by Marcus Denker Feb. 3, 2012

Feb. 3, 2012

On Feb 1, 2012, at 11:27 PM, Lawson English wrote: > Does Pharo use Morphic? Is there a conscious decision on people's parts to NOT try and keep the various flavors of Morphic compatible, or is it just "too hard," or that people don't care, or think it irrelevant? > So there are multiple problems: 1) Morphic is not and API or a codebase but and idea (or principle) And the question is even: a good one? In the current state for sure not. For sure it's instantiation depends *a lot* on the language model you have. 2) Hard problems get harder if you add players. It is already nearly impossible to change Pharo alone. Add Squeak (with the stated goal to never ever remove etoys..), that pair to keep compatible is already impossible. Add another *language* and we are speaking about something that is just not possible 3) compatibility across languages means using only the comman denominator. Feature wise. Graphics subsystem, alone that. But then language. Imagine we add the Slots to Pharo. Then morphic gets much simpler: no morph extension, all bit values will be bit slots (compact), properties will be dictonary slots. So now: Squeak will not have that. Self will not have that. So does that mean we can never use new abstraction for our base frameworks? How things are done in Self vs. Javascript is completely different. You can not at all share a framwork in any meaningful sense across these languages. And then add Smalltalk. (Ah, and as we are on it, VA, VW, STX, GNU Smalltalk of course, too!). Marcus -- Marcus Denker -- http://marcusdenker.de

3 2

[Pharo-project] prime number generation issue [Was: Question regarding LinkedList collect:]
by Nicolas Cellier Feb. 3, 2012

Feb. 3, 2012

Do you mean http://code.google.com/p/pharo/issues/detail?id=4997 ? In any case, finding a divisor with a naive iteration on all odd numbers is not the thing to do. Programming a deterministic and efficient primality test is a hard thing... I suggest to simply pick squeak version and let isPrime implemented in term of isProbablyPrime for large integers, put a comment why. Nicolas 2012/2/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > thanks > Nicolas could you have a look at the prime number generation issue? > > Stef > >

2 1

[Pharo-project] Question regarding LinkedList collect:
by Andreas Haufler (scireum GmbH) Feb. 2, 2012

Feb. 2, 2012

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

5 5

Re: [Pharo-project] keeping up with lively-kernel (morphic)
by Marcus Denker Feb. 2, 2012

Feb. 2, 2012

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

1 0

Re: [Pharo-project] keeping up with lively-kernel (morphic)
by Marcus Denker Feb. 2, 2012

Feb. 2, 2012

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

4 3

[Pharo-project] Flattening traits
by Andy Kellens Feb. 2, 2012

Feb. 2, 2012

Hello, I am trying to load Ring into GemStone. As Ring uses traits, the first thing I did was flatten the traits. Based on a thread on this mailing list from June 2011 (Elliot flattening the traits in Fuel) I used Behavior>flattenDownAllTraits. One thing I noticed is that, while this method successfully flattens the instance methods of the trait, the class methods appear to be just removed. I was able to fix this by changing method Behavior>>flattenDown. Before this method was implemented as: flattenDown: aTrait | selectors | [self hasTraitComposition and: [self traitComposition allTraits includes: aTrait]] assert. selectors := (self traitComposition transformationOfTrait: aTrait) selectors. self basicLocalSelectors: self basicLocalSelectors , selectors. self removeFromComposition: aTrait. My guess is that the culprit for this is the method Behavior>>removeFromComposition:, which removes the trait both from the instance and the class side. While the trait selectors were added to the instance side, they are not to the class side and therefore they are gone after the flattening. I was able to fix this by changing the method to: flattenDown: aTrait | selectors classSelectors transformation classTransformation | [self hasTraitComposition and: [self traitComposition allTraits includes: aTrait]] assert. transformation := self traitComposition transformationOfTrait: aTrait. selectors := transformation selectors. classSelectors := classTransformation selectors. self basicLocalSelectors: (self basicLocalSelectors ifNil:[selectors] ifNotNil:[:bs | bs, selectors]). self class basicLocalSelectors: (self class basicLocalSelectors ifNil:[classSelectors] ifNotNil:[:bs | bs, classSelectors]). self removeFromComposition: aTrait. My fix feels more like a workaround than a real solution to the problem, so before that I submit a patch to the inbox I was wondering if someone with more knowledge regarding the traits implementation has any input on this ... Cheers, Andy

3 2

Re: [Pharo-project] keeping up with lively-kernel (morphic)
by Marcus Denker Feb. 2, 2012

Feb. 2, 2012

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

3 2