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

Re: [Pharo-project] Issue 3191 in pharo: SparseLargeArray

by pharo＠googlecode.com

Updates: Status: Fixed Comment #2 on issue 3191 by jbaptiste.arnaud: SparseLargeArray http://code.google.com/p/pharo/issues/detail?id=3191 Inbox at Issue 3191: SparseLargeArray-JB.1

Nov. 26, 2010

Re: [Pharo-project] Issue 3329 in pharo: Object>>closeTo:

by pharo＠googlecode.com

Comment #2 on issue 3329 by alexandre.bergel: Object>>closeTo: http://code.google.com/p/pharo/issues/detail?id=3329 Yeah, I agree. But it is essentially interesting for Float: Float>>closeTo: num "are these two numbers close?" num isNumber ifFalse: [^[self = num] ifError: [false]]. self = 0.0 ifTrue: [^num abs < 0.0001]. num = 0 ifTrue: [^self abs < 0.0001]. ^self = num asFloat or: [(self - num) abs / (self abs max: num abs) < 0.0001] The problem is that you can two float which are the same, but have a different internal representation. But still, having closeTo: on Object does not make sense. Does it make sense to be able to do 'abc' closeTo: 'abc' ?

Nov. 26, 2010

Re: [Pharo-project] Issue 3192 in pharo: Unused block

by pharo＠googlecode.com

Comment #1 on issue 3192 by jbaptiste.arnaud: Unused block http://code.google.com/p/pharo/issues/detail?id=3192 Seem to be already fix.

Nov. 26, 2010

Re: [Pharo-project] Issue 3329 in pharo: Object>>closeTo:

by pharo＠googlecode.com

Comment #1 on issue 3329 by jbaptiste.arnaud: Object>>closeTo: http://code.google.com/p/pharo/issues/detail?id=3329 Not only Float, Point and Number too. The Behavior on Object is just a default Behavior, If the object can be compare and is equal return try, else false. I think is a artifact of defensive programming, "ok we declare the method in Object to be sure it's defined somewhere." Nevertheless that don't really making sense to create this kind of method on Object, what is relevant to decide if a object is "close" of another object. The semantics is completely ambiguous. i think we should remove that crap. I think we can discuss about renaming,remove or Replace the other occurrence of #closeTo: too.

Nov. 26, 2010

Re: [Pharo-project] Issue 3328 in pharo: Complete rewrite of Recent Message List

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3328 by stephane.ducasse: Complete rewrite of Recent Message List http://code.google.com/p/pharo/issues/detail?id=3328 in 12257

Nov. 26, 2010

[Pharo-project] PackageInfo named: creates one if doesn't exist....confusing

by Mariano Martinez Peck

Hi folks. PackageInfo >> named: aString ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register] creates a new one when it doesn't exist, instead of throwing an error. This has already driven me to different problems difficult to debug. What about doing something like: PackageInfo >> named: aString ifAbsent: aBlock ^ PackageOrganizer default packageNamed: aString ifAbsent: [aBlock value] PackageInfo >> namedForcingNew: aString ^ self named: aString ifAbsent: [(self new packageName: aString) register]. PackageInfo >> named: aString ^ self named: aString ifAbsent: [Error signal: 'The package: ', aString, ' doesnt exist']. The other option is to directly change PackageOrganizer and implement there: PackageOrganizer >> packageNamed: aString ^ packages at: aString ifAbsent: [Error signal: 'The package: ', aString, ' doesnt exist']. With this one the only non confortable is that to use it, is longer...you have to do: PackageOrganizer default packageNamed: 'ZarazaPackage' but it is safer than changing PackageInfo>>named Cheers mariano

Nov. 26, 2010

Re: [Pharo-project] Issue 3328 in pharo: Complete rewrite of Recent Message List

by pharo＠googlecode.com

Updates: Summary: Complete rewrite of Recent Message List Labels: Milestone-1.2 Comment #1 on issue 3328 by stephane.ducasse: Complete rewrite of Recent Message List http://code.google.com/p/pharo/issues/detail?id=3328 (No comment was entered for this change.)

Nov. 26, 2010

Re: [Pharo-project] Issue 3327 in pharo: Senders broken

by pharo＠googlecode.com

Comment #4 on issue 3327 by tudor.girba: Senders broken http://code.google.com/p/pharo/issues/detail?id=3327 Thank you!

Nov. 26, 2010

Re: [Pharo-project] Issue 3297 in pharo: [Kernel Dependencies] Object>>#notifyWithLabel:

by pharo＠googlecode.com

Updates: Labels: Type-Seed Comment #2 on issue 3297 by Benjamin.VanRyseghem.Pharo: [Kernel Dependencies] Object>>#notifyWithLabel: http://code.google.com/p/pharo/issues/detail?id=3297 (No comment was entered for this change.)

Nov. 26, 2010

Re: [Pharo-project] Issue 3298 in pharo: [Kernel Dependencies] Object >> #cannotReturn

by pharo＠googlecode.com

Updates: Labels: Type-Seed Comment #1 on issue 3298 by Benjamin.VanRyseghem.Pharo: [Kernel Dependencies] Object >> #cannotReturn http://code.google.com/p/pharo/issues/detail?id=3298 (No comment was entered for this change.)

Nov. 26, 2010