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

Re: [Pharo-project] Nautilus question

by Francois Stephany

Right! I don't really care if its bold/blue/blinking as long as it shows me that i'm in the class side. It's just that bold seems to be shouting at me ;) Haha, speaking of habits my muscle memory was so trained to OB that I'm still struggling with Nautilus ;) Super nice browser anyway! On 30/04/12 11:27, Benjamin wrote: > It is bold because previously we thought that the good default value is bold ^^ > > These kind of stuff clearly depend of the users (and the habits ^^) > > Ben > > On Apr 30, 2012, at 7:50 PM, Francois Stephany wrote: > >> Not necessarily a setting, a good default value (e.g., blue color as Francisco suggest) should be enough? >> >> On 30/04/12 10:13, Benjamin wrote: >>> It's intentional :) >>> >>> For now, you can't change it easily (ie by using a setting). >>> >>> Open a bug entry and I will try to change that :) >>> >>> Ben >>> >>> On Apr 30, 2012, at 7:03 PM, Francisco Garau wrote: >>> >>>> It is showing the class side methods in bold. Is that intentional? >>>> >>>> Can we change it to something else? Blue, maybe -- but not bold! Is hard to read... >>>> >>>> - Francisco >>>> >>>> >>> >>> >> > > -- http://tulipemoutarde.be CA: +1 778 558 3225 BE: +32 65 709 131

April 30, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,linux - Build # 23 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

April 30, 2012

[Pharo-project] [update 2.0] #20031

by Marcus Denker

20031 ----- Issue 5679: Removing a trait does not remove trait methods from class http://code.google.com/p/pharo/issues/detail?id=5679 Issue 5737: cleanup #useClosureBytecodes http://code.google.com/p/pharo/issues/detail?id=5737 Issue 5752: Update Keymapping http://code.google.com/p/pharo/issues/detail?id=5752 -- Marcus Denker -- http://marcusdenker.de

April 30, 2012

[Pharo-project] Questionn

by Santiago Bragagnolo

Hi all! I was chating with Guille, who's blaming me for make a refactor in sunit for pharo 1.4 instead of 2.0 and told me 'pharo 2.0 probably adds class layouts and slots'. Well, i'm with a concrete type inference project, i want to know what is made and who is in that part of the project to annoy and bore him with questions, 'cause probably i'll want to type the slots, but i need to understand the metaphor of the slots implementation. I want to understand too whats implication has the class layout over the types. Santiago.

April 30, 2012

Re: [Pharo-project] Nautilus question

by Benjamin

It is bold because previously we thought that the good default value is bold ^^ These kind of stuff clearly depend of the users (and the habits ^^) Ben On Apr 30, 2012, at 7:50 PM, Francois Stephany wrote: > Not necessarily a setting, a good default value (e.g., blue color as Francisco suggest) should be enough? > > On 30/04/12 10:13, Benjamin wrote: >> It's intentional :) >> >> For now, you can't change it easily (ie by using a setting). >> >> Open a bug entry and I will try to change that :) >> >> Ben >> >> On Apr 30, 2012, at 7:03 PM, Francisco Garau wrote: >> >>> It is showing the class side methods in bold. Is that intentional? >>> >>> Can we change it to something else? Blue, maybe -- but not bold! Is hard to read... >>> >>> - Francisco >>> >>> >> >> >

April 30, 2012

Re: [Pharo-project] What about making the configuration browser more visible?

by Schwab,Wilhelm K

I am using 1.3 now, but dread another round of "no, install it THIS way..." re 1.4. The CogVM/linux looks for stuff in the wrong places on Ubuntu, but symlinks (kinda shameful) fix that with some effort. Alien callbacks mixed with FFI do appear to be a problem, and I have some other FFI related challenges that appear to be "unjust." I've been over and over the code looking for mistakes on my part, and see nothing that *should* be correlated with the error messages. Looking forward to Spok's arrival. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Norbert Hartl [norbert(a)hartl.name] Sent: Monday, April 30, 2012 3:54 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Am 30.04.2012 um 00:11 schrieb Schwab,Wilhelm K: > I stayed on 1.1.1 for a long time for just these reasons. If want people to test new versions, there needs to be at least some hope that they will work. > To be honest I'm not sure if you should upgrade to 1.2. Just wait a little more. And then remember that it will be close to impossible to load an external module. If you don't need one, good, if not you are in serious trouble. Norbert > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean(a)clipperadams.com] > Sent: Saturday, April 28, 2012 6:44 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] What about making the configuration browser more visible? > > Dale Henrichs wrote >> >> In my last post, I provided my vision of the future >> > That was very helpful. I can see the big picture much better now... > > > Dale Henrichs wrote >> >> If you don't want to experience the pain of developing on a new platform, >> then don't move to the new platform until the hubbub has died down ... >> > I'm perfectly happy, but it seemed like nobody knew where bill was coming > from, while the API and best practices have been rapidly evolving... > > Sean > > -- > View this message in context: http://forum.world.st/What-about-making-the-configuration-browser-more-visi… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

April 30, 2012

Re: [Pharo-project] Nautilus question

by Francois Stephany

Not necessarily a setting, a good default value (e.g., blue color as Francisco suggest) should be enough? On 30/04/12 10:13, Benjamin wrote: > It's intentional :) > > For now, you can't change it easily (ie by using a setting). > > Open a bug entry and I will try to change that :) > > Ben > > On Apr 30, 2012, at 7:03 PM, Francisco Garau wrote: > >> It is showing the class side methods in bold. Is that intentional? >> >> Can we change it to something else? Blue, maybe -- but not bold! Is hard to read... >> >> - Francisco >> >> > >

April 30, 2012

Re: [Pharo-project] Block questions

by Eliot Miranda

On Mon, Apr 30, 2012 at 4:01 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > > > > foo > > > > |b| > > b := 3. > > ^ [ |a | a :=2. a] > > > > In my stupid lisp implementation an environment is represented by > bindings and closure points to their own environment > > so > > [ |a | a :=2. a] > > points to > > (b.3) (toplevel) (and not top-level) > > > > and for closure execution we just added temporaly a binding for a to the > closure environment. > > eval a:=2. a in (a) (b.3) (toplevel) > > > > This is the wrong example. > > I understand your example below and the fact that closure environment is > allocated on the heap via an array to be independent of the activation > context but I do not get why consing the local environment to be one > current one is wrong. > I mean the example is not a useful example because it doesn't show the problem "my" representation solves, which is to make closures independent of their enclosing activations if they outlive their dynamic extent. > (define (%apply proc largs) > (cond ((%primitive? proc) (%apply-internal proc largs)) > ((%closure? proc) (%apply-closure proc largs)) > (else (error "Bad ! Un-apply-able object !" proc)))) > > (define (%apply-closure proc largs) > ;; apply a closure: evaluate proc body in > ;; extended the closure environment with > ;; proc arguments and largs > (%eval (%closure-body proc) > (%extend-env (%closure-args proc) largs (%closure-env > proc)))) > > (define (%eval-lambda expr env) > ;; lambda in Scheme captures the environment at compile time > ;; expr = ((x) (+ x 2)) > (%make-closure (car expr) (cadr expr) env)) > > > You need to consider how to implement this example: > > > > Object subclass: #AbstractSuperclass > > > > AbstractSuperclass>>computeV > > | v | > > v := 0. > > self maybeCapture: [v := v + 1. v]. > > ^self maybeBlock: v > > > > AbstractSuperclass subclass: #CaptureBlock > > instanceVariableNames: 'block' > > > > CaptureBlock>>maybeCapture: aBlock > > block := aBlock > > > > CaptureBlock>>maybeBlock: value > > ^block > > > > AbstractSubclass subclass: #DontCaptureBlock > > > > DontCaptureBlock>>maybeCapture: aBlock > > > > DontCaptureBlock>>maybeBlock: value > > ^value > > > > > > Then > > | thingOne thingTwo | > > thingOne := CaptureBlock computeV. > > thingTwo := DontCaptureBlock computeV. > > (1 to: 10) collect: [:ignore| { thingOne value. thingTwo value }] > > > > should answer > > #((1 0) (2 0) (3 0) ... (10 0)) > > if 0 value returns 0? yes. (it confused me for a while). > > > right? So where does the l-value for v in computeV live? Iy must be an > l-value since it is assigned to in the block in computeV. It must outlive > the activation of computeV since CaptureBlock>maybeCapture: captures the > block and CaptureBlock>>maybeBlock: answers it and the doit evaluates it. > If it lives on the stack of the activation of computeV then there is no > problem in a Context VM, but in a VM that maps activations to stack frames > something special (and slow) has to happen when returning from computeV. > However, if the l-value lives in a separate Array (as it does in my > VisualWorks and Squeak closure implementations, and as happens in some Lisp > implementations), nothing special has to happen. The block refers to the > Array, *not* to the activation of computeV. > > > > Make sense now? > > Yes you allocate on the heap closure binding to be orthogonal to > activation context. > > > I will reread your blog now. > > Stef > -- best, Eliot

April 30, 2012

Re: [Pharo-project] Nautilus question

by Benjamin

It's intentional :) For now, you can't change it easily (ie by using a setting). Open a bug entry and I will try to change that :) Ben On Apr 30, 2012, at 7:03 PM, Francisco Garau wrote: > It is showing the class side methods in bold. Is that intentional? > > Can we change it to something else? Blue, maybe -- but not bold! Is hard to read... > > - Francisco > >

April 30, 2012

[Pharo-project] Nautilus question

by Francisco Garau

It is showing the class side methods in bold. Is that intentional? Can we change it to something else? Blue, maybe -- but not bold! Is hard to read... - Francisco

April 30, 2012