January 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Load OB

by Fernando Olivero

How can i load OB into a clean Pharo image? Thanks, Fernando

Jan. 25, 2011

Re: [Pharo-project] Issue 3579 in pharo: "declare temp" adds the variable twice

by pharo＠googlecode.com

Comment #2 on issue 3579 by laurent....(a)gmail.com: "declare temp" adds the variable twice http://code.google.com/p/pharo/issues/detail?id=3579 On accept and select 'declare temp': Parser>>declareTempAndPaste: adds the temp |bar| (put a halt here, easy to follow) but then EncoderForV3PlusClosures>>bindAndJuggle: throws signal ReparseAfterSourceEditing and then I'm totally lost :)

Jan. 25, 2011

Re: [Pharo-project] search stack tricks

by laurent laffont

On Mon, Jan 24, 2011 at 2:50 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > For me, if nothing else is going on, an Alt-. will get you there... > cool, that's the real trick I was looking for ! Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ > > Regards, Gary > > ----- Original Message ----- > *From:* laurent laffont <laurent.laffont(a)gmail.com> > *To:* An open mailing list to discuss any topics related to an > open-sourceSmalltalk <pharo-project(a)lists.gforge.inria.fr> > *Sent:* Sunday, January 23, 2011 8:46 AM > *Subject:* [Pharo-project] search stack tricks > > Hi, > > I'm trying to look at http://code.google.com/p/pharo/issues/detail?id=3579 > > When I accept the method, the "Unknow variable...." dialog pops up. > > But I struggle to find from where this dialog has been created. > > So when you have a modal dialog and you want to find / explore the > stack/context from which it has been opened, how do you get it ? > > Cheers, > > Laurent Laffont (@lolgzs) > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > >

Jan. 25, 2011

[Pharo-project] debugger problems?

by Tudor Girba

Hi, >From time to time, I seem to get confused in the Debugger because somehow the current selection does not seem to reflect the execution point. Is it just me, or are there others that encountered this problem as well? Cheers, Doru -- www.tudorgirba.com "Every thing should have the right to be different."

Jan. 25, 2011

[Pharo-project] Issue 3592 in pharo: MenuMorph uses action: and selector: to mean the same thing

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3592 by sean.p.d...(a)gmail.com: MenuMorph uses action: and selector: to mean the same thing http://code.google.com/p/pharo/issues/detail?id=3592 e.g. MenuMorph #add:target:action: and #add:target:selector: do the same thing and should be merged. Any preference? I think action is more intention revealing How about #add:sending:to:, which from the API user's perspective would look like: menu add: 'New instance creation method' sending: #addInstanceCreationMethod to: self. Sean

Jan. 25, 2011

[Pharo-project] Issue 3591 in pharo: Implementors of #listMorph place it in different (or no) category

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3591 by sean.p.d...(a)gmail.com: Implementors of #listMorph place it in different (or no) category http://code.google.com/p/pharo/issues/detail?id=3591 Pharo1.2rc1 Latest update: #12320 What is (if any) the standard here? I usually follow Kent Beck's advice to put getters in 'private' unless they are meant to be public, and in that case, in 'accessing'. But here we have 'accessing'/'callbacks' (OB)/'user interface'. Sean

Jan. 25, 2011

Re: [Pharo-project] What about a little rename in MouseEvent?

by csrabak＠bol.com.br

> Em 24/01/2011 05:25, Marcus Denker < marcus.denker(a)inria.fr > > escreveu: > On Jan 24, 2011, at 5:39 AM, Guillermo Polito wrote: > > I hate yellowButtonPressed and redButtonPressed and > > blueButtonPressed messages. Why not lefClick, rightClick and > > "middleClick"? > > > Yes. > Back in the days, the color buttons where "holy cows". You just > could not even suggest to change it. On the other hand, as the buttons of mice can be reassigned, the 'names' "right" and "left" could become ambiguous... my 0.019999... -- Cesar Rabak

Jan. 25, 2011

Re: [Pharo-project] Gofer issue

by Lukas Renggli

> In VW we use the following convention > > Â Â Â Â base version + branch id - branch version > > which then naturally extends to > > Â Â Â Â base version + branch id - branch version + branch2 id - branch2 version Multiple branches are specified as given in the grammar. { "." Branch } in EBNF means zero or more of whatever is enclosed. Whenever a new branch is started its id resets to 1. The ancestry information does not need to be tracked in the name, it is luckily already contained in the meta-information. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 24, 2011

Re: [Pharo-project] Gofer issue

by mkobetic＠gmail.com

What about branch from a branch ? In general you need a tuple of (base version, branch id, branch version) to identify a branch version. Similarly a branch on a branch would become ((base version, branch id, branch version), branch2 id, branch2 version). In VW we use the following convention base version + branch id - branch version which then naturally extends to base version + branch id - branch version + branch2 id - branch2 version In monticello, your 'version' is author.nr (to accommodate distributed development) so the scheme would become author0.nr0 + branch1 - author1.nr1 + branch2 - author2.nr2 People probably won't like that, but I think the notion of the version identification tuple is relevant to the discussion. For example neither of the schemes below indicates where the branch starts. "Lukas Renggli"<renggli(a)gmail.com> wrote: > You cannot get rid of branching, this is a central part of version > control and extensively used in many large projects. > > In Seaside we use the following pattern, also see the documentation at > http://code.google.com/p/seaside/wiki/PackageNaming: > > Package = PackageName "-" Author { "." Branch } "." Version > > However I noticed that other projects (and earlier versions of > Seaside) use a different scheme: > > Package = PackageName { "." Branch } "-" Author "." Version > > In this case I guess we must support: > > Package = PackageName { "." Branch } "-" Author { "." Branch > } "." Version > > However, that doesn't change that $. and $- cannot be part of the > PackageName or Author.

Jan. 24, 2011

Re: [Pharo-project] Issue 3562 in pharo: Deferred UI messages executed slowly

by pharo＠googlecode.com

Updates: Status: Fixed Labels: Milestone-1.3 Comment #1 on issue 3562 by marianopeck: Deferred UI messages executed slowly http://code.google.com/p/pharo/issues/detail?id=3562 thanks richo :)

Jan. 24, 2011