December 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3375 in pharo: PositionableStream remove dependence to Compiler

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo New issue 3375 by Benjamin.VanRyseghem.Pharo: PositionableStream remove dependence to Compiler http://code.google.com/p/pharo/issues/detail?id=3375 fix, but using a not so pretty way. I've to discuss with Steph about extensions Attachments: PositionableStreamRemoveDependenceToCompiler.1.cs 1.8 KB

Dec. 3, 2010

[Pharo-project] MC2 on Pharo

by Martin Dias

Hi, is possible to load and run Monticello2 in Pharo? Thank you, Martin

Dec. 3, 2010

[Pharo-project] Dollars to documentation

by laurent laffont

Interesting action from the rails project: http://pledgie.com/campaigns/14034 Laurent Laffont

Dec. 3, 2010

[Pharo-project] Issue 3374 in pharo: Problem when opening a DIalogItemsChooser

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo New issue 3374 by Benjamin.VanRyseghem.Pharo: Problem when opening a DIalogItemsChooser http://code.google.com/p/pharo/issues/detail?id=3374 Fix Attachments: FixDialogItemsChooser.1.cs 1.8 KB

Dec. 3, 2010

Re: [Pharo-project] Issue 3371 in pharo: problem with find & replace in PharoCore 1.2

by pharo＠googlecode.com

Updates: Status: Fixed Comment #2 on issue 3371 by aplantec: problem with find & replace in PharoCore 1.2 http://code.google.com/p/pharo/issues/detail?id=3371 In InBox SLICE-Issue-3371-problem-with-find--replace-in-PharoCore-1-2

Dec. 3, 2010

Re: [Pharo-project] newbie smalltalk question

by Elliot Finley

On Thu, Dec 2, 2010 at 10:59 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Thu, Dec 2, 2010 at 9:49 PM, Elliot Finley <efinley.lists(a)gmail.com>wrote: > >> I have the following code: >> >> isValid (self value == nil and: [self required == false]) ifTrue: [^true]. >> self isCorrectType ifFalse: [self validationError: 'value doesn''t coerce to >> correct type'. ^false.] ^ self allConditionsValid. >> >> when I try to save this I get a ' Nothing more expected ->' right before >> '^ self allConditionsValid'. I'm guessing this is because I have the >> '^false' in the second line? >> >> > You are missing a period after the close of the block. You have a period > /before/ the end of the block, which is unnecessary. Move it to the other > side of the ']'. > > > <me turning bright red with embarrassment> Thank you. </>

Dec. 3, 2010

Re: [Pharo-project] newbie smalltalk question

by Eliot Miranda

On Thu, Dec 2, 2010 at 9:49 PM, Elliot Finley <efinley.lists(a)gmail.com>wrote: > I have the following code: > > isValid (self value == nil and: [self required == false]) ifTrue: [^true]. > self isCorrectType ifFalse: [self validationError: 'value doesn''t coerce to > correct type'. ^false.] ^ self allConditionsValid. > > when I try to save this I get a ' Nothing more expected ->' right before '^ > self allConditionsValid'. I'm guessing this is because I have the '^false' > in the second line? > > You are missing a period after the close of the block. You have a period /before/ the end of the block, which is unnecessary. Move it to the other side of the ']'. best Eliot > How would I accomplish the same thing - correctly? > > Thanks, > Elliot > >

Dec. 3, 2010

[Pharo-project] newbie smalltalk question

by Elliot Finley

I have the following code: isValid (self value == nil and: [self required == false]) ifTrue: [^true]. self isCorrectType ifFalse: [self validationError: 'value doesn''t coerce to correct type'. ^false.] ^ self allConditionsValid. when I try to save this I get a ' Nothing more expected ->' right before '^ self allConditionsValid'. I'm guessing this is because I have the '^false' in the second line? How would I accomplish the same thing - correctly? Thanks, Elliot

Dec. 3, 2010

Re: [Pharo-project] Issue 3371 in pharo: problem with find & replace in PharoCore 1.2

by Francisco Ortiz PeÃ±aloza

Ok, thanks! I agree with you about the colors, now i see them :) Francisco On Thu, Dec 2, 2010 at 7:47 PM, <pharo(a)googlecode.com> wrote: > > Comment #1 on issue 3371 by aplantec: problem with find & replace in > PharoCore 1.2 > > http://code.google.com/p/pharo/issues/detail?id=3371 > > Le 02/12/2010 22:19, Francisco Ortiz PeÃ±aloza a Ã©crit : > > imho setting search text to empty string in any other context different >> that the >> place you did the search would be the best >> > The search text is shared (as it has always been). maybe you notice that > now because of the color. > As an example, when you browse all senders of a selector, > the selector is also in orange everywhere because the search text it set > with it. > It can't be changed without further investigation. > and other people (like me) will argue that they like the current > behavior... > Cheers > Alain > > >

Dec. 3, 2010

Re: [Pharo-project] Issue 1594 in pharo: refactor to use #ifNil:

by Peter van Rooijen

On Thu, 02 Dec 2010 12:32:02 +0100, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 2 Dec 2010, Peter van Rooijen wrote: > >> I agree, >> >> If you want to know if a object is the same object as >> that designated by the expression nil, you use the message #== >> (this message had guaranteed semantics since it can not be redefined). >> >> If you want to know if the message ifNil: aBlock sent to the object >> evaluates the block argument, you use the message #ifNil: >> (which could do anything it has been defined to do >> - at least, I would hope so!). >> >> Those two uses are distinct and mean something different. > > In theory yes, but the compiler also inlines #ifNil:, #ifNil:ifNotNil:, > #ifNotNil: and #ifNotNil:ifNil: if the arguments are literal blocks. So > in that case, they are equivalent with == nil ifTrue:/ifFalse:. Thanks for explaining, I wasn't aware of that. Seems like a really ugly hack to me. Deciding semantics based on an argument type, before the receiver type is known...extremely fishy. Now, if the compiler inlined [...] ifNil: <something> that would be a different matter, since the receiver class is known at compile time, and it's not such a big deal to require those semantics to be fixed. Cheers, Peter > Levente

Dec. 2, 2010