- Pharo-dev - lists.pharo.org

[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

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

by pharo＠googlecode.com

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. 2, 2010

Re: [Pharo-project] Issue 2252 in pharo: Error adding a category to a trait

by pharo＠googlecode.com

Updates: Status: Duplicate Mergedinto: 3367 Comment #10 on issue 2252 by aplantec: Error adding a category to a trait http://code.google.com/p/pharo/issues/detail?id=2252 was just already fixed by SLICE-Issue-3367-PopupChoiceDialogWindow-handlesKeyboard-fails-with-empty-label-list :)

Dec. 2, 2010