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

[Pharo-project] [update 1.1] #11115

by StÃ©phane Ducasse

11115 ----- Issue 1683: From The Trunk: minor improvement of MethodDictionary>>includesKey: N. Cellier and Traits :) Issue 1664: Long method can not be compiled using #compile: aString Issue 1158: System Browser vs Class Browser tx David R. Issue 1624: 1.1#alpha should be renamed to 1.1#unstable

Dec. 25, 2009

Re: [Pharo-project] Fwd: hasEqualElements:

by StÃ©phane Ducasse

thanks for the explanation. I will add this in the method comment and probably class comment http://code.google.com/p/pharo/issues/detail?id=1685 Stef On Dec 25, 2009, at 1:11 AM, Eliot Miranda wrote: > > > On Thu, Dec 24, 2009 at 2:52 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 24 Dec 2009, Eliot Miranda wrote: > > > > This 'hack' is as old as Smalltalk-80 V2 and is AFAICT in all Smalltalk-80 > > derived Smalltalks: > > > > !Object methodsFor: 'accessing'! > > at: index > > "Answer the value of an indexable field in the receiver. Fail if the > > argument index is not an Integer or is out of bounds. Essential. See > > documentation in Object metaclass." > > > > <primitive: 60> > > index isInteger > > ifTrue: [self errorSubscriptBounds: index]. > > (index isKindOf: Number) > > ifTrue: [^self at: index truncated] > > ifFalse: [self errorNonIntegerIndex]! > > > > It is also free in the sense that the failure code is only invoked when the > > primitive fails and so adds nothing to the cost of successful accesses, > > which are the high dynamic frequency operation. It will also show up under > > profiling if one is concerned about efficiency, and so isn't a hidden cost. > > > > It is also in keeping with Smalltalk's mixed mode/arbitrary precision > > implicit coercion number system that one *can* use fractions or floats as > > indices. > > > > Stripping out coercions like this will make the system more brittle. So > > please do *not* remove this "hack". I think it's a feature and a useful > > one. > > Can you give me an example that demonstrates the usefulness of this > feature? > > | a r | > a := Array new: 10 withAll: 0. > r := Random new. > 100 timesRepeat: [| v | v := r next * 10 + 1. a at: v put: (a at: v) + 1]. > a > > i.e. I didn't have to provide an explicit rounding step. That's useful. But in general anywhere where an index is derived by some calculation not having to provide the rounding step could be useful/helpful/more concise. e.g. (n roundTo: 0.1) * 10 vs ((n roundTo: 0.1) * 10) asInteger. > > Some thought went into the original choice. It is not a hack but there by intent. The integers are simply a subset of the reals and forcing the programmer to use them is favouring the machine above the programmer. > > But I think you should justify getting rid of it rather than my having to justify keeping it. Getting rid of it risks breaking code. If it is there but does not harm then why get rid of it? > > best > Eliot > > > Levente > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 25, 2009

[Pharo-project] [update 1.1] #11113

by StÃ©phane Ducasse

11113 ----- - Issue 1681: change default font -- Issue 1550: Make Bitmap DejaVu as default fonts in 1.1 - Issue 1660: SortBlock and sort L. Uzonyi . S. Ducasse - Issue 1647: Fix FixAndTesstForAdditionalMethodStateAtPut - A. Raab - Issue 1675: Change FixedIdentitySet behaviour wrt silently ignoring collisions and fullness - Issue 1676: change QuickIntegerDictionary superclass Stef

Dec. 25, 2009

Re: [Pharo-project] More from TheTrunk

by StÃ©phane Ducasse

I tried to understand > > > > A very simple example to illustrate the bug: > > | x | > x := (1.0 timesTwoPower: 53). > (x to: x + 2) size. > x to: x+2 do: [:i | Transcript cr; show: i printString] it is normal that it still loops forever after loading the slice? Stef

Dec. 25, 2009

[Pharo-project] Preferences left over..... a Question

by StÃ©phane Ducasse

Alain stan proposed in http://code.google.com/p/pharo/issues/detail?can=2&q=1679 to change (Smalltalk at: #Preferences ifAbsent: []) ifNotNil: [:oldPrefClass | (oldPrefClass allPreferenceObjects select: [:pref | pref changeInformee = Sensor class]) do: [:pref | pref changeInformee: newSensor class]]. into (Preferences allPreferenceObjects select: [:pref | pref changeInformee = Sensor class]) do: [:pref | pref changeInformee: newSensor class]. in installEventSensorFramework: fetcherClass But it seems to me that there is probably a better solution. installEventSensorFramework: fetcherClass "Installs the new sensor framework." "InputEventSensor installEventSensorFramework: InputEventPollingFetcher" | newSensor | "Do some extra cleanup" {InputEventFetcher. InputEventPollingFetcher. } do: [:oldSensorClass | Smalltalk removeFromShutDownList: oldSensorClass. Smalltalk removeFromStartUpList: oldSensorClass]. InputEventFetcher deinstall. newSensor := self new. fetcherClass install. newSensor registerIn: InputEventPollingFetcher default. "Shut down old sensor" Sensor shutDown. Smalltalk removeFromShutDownList: Sensor class. Smalltalk removeFromStartUpList: Sensor class. (Smalltalk at: #Preferences ifAbsent: []) ifNotNil: [:oldPrefClass | (oldPrefClass allPreferenceObjects select: [:pref | pref changeInformee = Sensor class]) do: [:pref | pref changeInformee: newSensor class]]. "Note: We must use #become: here to replace all references to the old sensor with the new one, since Sensor is referenced from all the existing controllers." Sensor becomeForward: newSensor. "done" "Register the interrupt handler" UserInterruptHandler new registerIn: InputEventFetcher default. Smalltalk addToStartUpList: Sensor class after: fetcherClass. Smalltalk addToShutDownList: Sensor class after: Form. "Project spawnNewProcessAndTerminateOld: true"

Dec. 25, 2009

Re: [Pharo-project] #sortBlock:

by StÃ©phane Ducasse

ouf honor is safe :) So try to convince VA to do a better job than ANSI. because with sort: polymorph and sorted (suboptimal but ok) we can have a better solution Stef >>>>> #sortBlock: is defined by ANSI on SortedCollection as an accessor and >>>>>>> an instance creation method. That's what it sounds like and shouldn't >>>>>>> be implemented on non-sorted collections. >>>>>> >>>>>> Why? what would be the reason not to use sortBlock: for others? >>>>> >>>>> The intention is different. #sortBlock: tells a collection to maintain >>>>> itself as sorted even after additions and deletions. This message is not >>>>> appropriate for collections that do not have that ability. >>>>> >>>>> #sortBlock: is not the best name for this functionality, but I think >>>>> it's bad to use #sortBlock: with a different meaning. >>>> >>>> I agree :) >>>> Now SortedCollection should understand sort too which uses sortBlock: >>>> My main concern is polymorphism between collection which are nearly the same! >>> >>> #sortBlock: is an accessor for the sortBlock instance variable on >>> SortedCollection. It makes no sense for a collection that doesn't have >>> that instance variable to have that accessor. >> >> did I say that? I do not think so. I'm not that idiot. >> No I say that SortedCollection should understand sort: > > Ah, apologies - I misunderstood what you were saying (I was a little > surprised that you would be arguing what I thought you were arguing :) > ). > > Julian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 25, 2009

Re: [Pharo-project] From The Trunk: SLICE-MethodDictionaryTest

by StÃ©phane Ducasse

thanks alex if christmas day let me approach a computer without considering that I'm a bad father I will do that list of updates: Issue 1680: Update Gofer Issue 1681: change default font -- Issue 1550: Make Bitmap DejaVu as default fonts in 1.1 Issue 1679: InputEventSensor refers to defunct class InputSensor Issue 1660: SortBlock Issue 1677: Change QuickStack superclass Issue 1676: change QuickIntegerDictionary superclass Issue 1675: Change FixedIdentitySet behaviour wrt silently ignoring collisions and fullness Issue 1664: Long method can not be compiled using #compile: aString ISSUE #1683 Issue 1214: [Squeak] Collection possible improvements (not sure) first publish the slice Issue 1113: [squeak trunk] Tools-bf.106.mcz - Fix Message Finder problem - bug #7380 -> Issue 1158: System Browser vs Class Browser To close: Issue 1632: Don't accept script files as VM parameter Issue 1607: ProjectLauncher readDocumentAtStartup a setting Issue 1379: Sometimes my author names ends up being "TestRunner" Issue 1624: 1.1#alpha should be renamed to 1.1#unstable On Dec 25, 2009, at 9:40 AM, Alexandre Bergel wrote: > Name: SLICE-MethodDictionaryTest-AlexandreBergel.1 > Author: TestRunner > Time: 25 December 2009, 9:29:13 am > UUID: 2170f234-8a10-49e6-9c0a-6ce0ad27f70f > Ancestors: > Dependencies: Kernel-TestRunner.521, KernelTests-TestRunner.180 > > ISSUE #1683 > > Pharo image: Pharo-core > Pharo core version: 11112 > > SLICE-MethodDictionaryTest-Alexandre_Bergel.1 in the inbox fixes what > is proposed by Nicolas. > It also defines a class MethodDictionaryTest in the class category: > KernelTests-Methods. > MethodDictionaryTest uses some traits defined by Cyrille. This is > really cool! It permitted to find a bug in MethodDictionary (removes > removeKey:ifAbsent: should return the value that has been removed). > MethodDictionaryTest has 21 green tests. > > Before loading the SLICE: > 7320 run, 7272 passes, 20 expected failures, 12 failures, 16 errors, 0 > unexpected passes > > After loading the SLICE: > 7341 run, 7293 passes, 19 expected failures, 12 failures, 16 errors, 1 > unexpected passes > > Unfortunately, I was not able to find the unexpected pass. Apparently, > running twice the unit tests have different results. > > The description of the issue in Trunk follows: > > Nicolas Cellier uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-nice.343.mcz > > ==================== Summary ==================== > > Name: Kernel-nice.343 > Author: nice > Time: 24 December 2009, 10:22:02 am > UUID: 155bf515-f41c-bc40-9dad-f98c01dfce8d > Ancestors: Kernel-nice.342 > > Smalltalk commandments #7: > 'Thu shalt not invoke super when self could do the job' > > =============== Diff against Kernel-nice.342 =============== > > Item was changed: > ----- Method: MethodDictionary>>includesKey: (in category > 'accessing') ----- > includesKey: aSymbol > "This override assumes that pointsTo is a fast primitive" > > aSymbol ifNil: [^ false]. > + ^ self pointsTo: aSymbol! > - ^ super pointsTo: aSymbol! > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 25, 2009

[Pharo-project] From The Trunk: SLICE-MethodDictionaryTest

by Alexandre Bergel

Name: SLICE-MethodDictionaryTest-AlexandreBergel.1 Author: TestRunner Time: 25 December 2009, 9:29:13 am UUID: 2170f234-8a10-49e6-9c0a-6ce0ad27f70f Ancestors: Dependencies: Kernel-TestRunner.521, KernelTests-TestRunner.180 ISSUE #1683 Pharo image: Pharo-core Pharo core version: 11112 SLICE-MethodDictionaryTest-Alexandre_Bergel.1 in the inbox fixes what is proposed by Nicolas. It also defines a class MethodDictionaryTest in the class category: KernelTests-Methods. MethodDictionaryTest uses some traits defined by Cyrille. This is really cool! It permitted to find a bug in MethodDictionary (removes removeKey:ifAbsent: should return the value that has been removed). MethodDictionaryTest has 21 green tests. Before loading the SLICE: 7320 run, 7272 passes, 20 expected failures, 12 failures, 16 errors, 0 unexpected passes After loading the SLICE: 7341 run, 7293 passes, 19 expected failures, 12 failures, 16 errors, 1 unexpected passes Unfortunately, I was not able to find the unexpected pass. Apparently, running twice the unit tests have different results. The description of the issue in Trunk follows: Nicolas Cellier uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-nice.343.mcz ==================== Summary ==================== Name: Kernel-nice.343 Author: nice Time: 24 December 2009, 10:22:02 am UUID: 155bf515-f41c-bc40-9dad-f98c01dfce8d Ancestors: Kernel-nice.342 Smalltalk commandments #7: 'Thu shalt not invoke super when self could do the job' =============== Diff against Kernel-nice.342 =============== Item was changed: ----- Method: MethodDictionary>>includesKey: (in category 'accessing') ----- includesKey: aSymbol "This override assumes that pointsTo is a fast primitive" aSymbol ifNil: [^ false]. + ^ self pointsTo: aSymbol! - ^ super pointsTo: aSymbol! -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 25, 2009

Re: [Pharo-project] Fonts

by Lukas Renggli

> Are the bitmap fonts by choice or compromise (perhaps OS specific)? The bitmap fonts look ok (in the standard Squeak theme) and are faster than the true-type fonts. So it is a compromise. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 25, 2009

Re: [Pharo-project] Fwd: hasEqualElements:

by Igor Stasenko

2009/12/25 Levente Uzonyi <leves(a)elte.hu>: > On Thu, 24 Dec 2009, Eliot Miranda wrote: >> >> This 'hack' is as old as Smalltalk-80 V2 and is AFAICT in all Smalltalk-80 >> derived Smalltalks: >> >> !Object methodsFor: 'accessing'! >> at: index >> Â Â "Answer the value of an indexable field in the receiver. Fail if the >> Â Â argument index is not an Integer or is out of bounds. Essential. See >> Â Â documentation in Object metaclass." >> >> Â Â <primitive: 60> >> Â Â index isInteger >> Â Â Â Â ifTrue: [self errorSubscriptBounds: index]. >> Â Â (index isKindOf: Number) >> Â Â Â Â ifTrue: [^self at: index truncated] >> Â Â Â Â ifFalse: [self errorNonIntegerIndex]! >> >> It is also free in the sense that the failure code is only invoked when the >> primitive fails and so adds nothing to the cost of successful accesses, >> which are the high dynamic frequency operation. Â It will also show up under >> profiling if one is concerned about efficiency, and so isn't a hidden cost. >> >> It is also in keeping with Smalltalk's mixed mode/arbitrary precision >> implicit coercion number system that one *can* use fractions or floats as >> indices. >> >> Stripping out coercions like this will make the system more brittle. Â So >> please do *not* remove this "hack". Â I think it's a feature and a useful >> one. > > Can you give me an example that demonstrates the usefulness of this > feature? > > I think the right question is: - if we going to remove that, what alternative we're proposing? Like: throw a special exception class, so people may handle it and use rounding in case of need? And will it be more convenient to programmer? Less error prone? > Levente > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Dec. 25, 2009