- Pharo-dev - lists.pharo.org

Re: [Pharo-project] about keys returning a set

by Igor Stasenko

2009/12/4 Lukas Renggli <renggli(a)gmail.com>: > Actually the code can be further optimized: > > Dictionary>>keys > Â Â Â Â "Answer a Set containing the receiver's keys." > > Â Â Â Â | result container | > Â Â Â Â result := Set basicNew setTally: tally array: array copy. > Â Â Â Â container := result array. > Â Â Â Â 1 to: container size do: [ :index | > Â Â Â Â Â Â Â Â (container at: index) > Â Â Â Â Â Â Â Â Â Â Â Â ifNotNil: [ :assoc | container at: index put: assoc key ] ]. > Â Â Â Â ^ result > > This is roughly 22 times faster than the current implementation, and 5 > times faster than the squeak implementation. > > The system doesn't seem to break with this change :-) > except that it breaking encapsulation. Thus i vote -1 for this kind of optimization :) > Lukas > > 2009/12/4 Lukas Renggli <renggli(a)gmail.com>: >> I wonder if ever something along the following lines was considered? >> >> Dictionary>>keys >> Â Â Â Â "Answer a Set containing the receiver's keys." >> >> Â Â Â Â | result | >> Â Â Â Â result := Set basicNew. >> Â Â Â Â result setTally: tally array: (array collect: [ :each | >> Â Â Â Â Â Â Â Â each isNil ifFalse: [ each key ] ]). >> Â Â Â Â ^ result >> >> This returns a Set, so it wouldn't break any semantics. In my >> benchmark this is roughly 8x faster than the current implementation, >> and 2x faster than the optimized Squeak implementation. >> >> The drawback is that it makes some heavy assumptions on the internal >> structure of Dictionary, Association and Set. >> >> Lukas >> >> 2009/12/4 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: >>> A small addendum ;) >>> On 03.12.2009 22:13, Nicolas Cellier wrote: >>>> 3) identify thise sending a potential inefficient message (includes:) >>>> insert keys asSet in this case (only if includes: is in a loop!) >>>> >>>> >>> 3b. If the keys collection isn't used for anything else, change to use >>> includesKey: instead. >>> >>> Cheers, >>> Henry >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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. 4, 2009

Re: [Pharo-project] about keys returning a set

by Lukas Renggli

Actually the code can be further optimized: Dictionary>>keys "Answer a Set containing the receiver's keys." | result container | result := Set basicNew setTally: tally array: array copy. container := result array. 1 to: container size do: [ :index | (container at: index) ifNotNil: [ :assoc | container at: index put: assoc key ] ]. ^ result This is roughly 22 times faster than the current implementation, and 5 times faster than the squeak implementation. The system doesn't seem to break with this change :-) Lukas 2009/12/4 Lukas Renggli <renggli(a)gmail.com>: > I wonder if ever something along the following lines was considered? > > Dictionary>>keys > Â Â Â Â "Answer a Set containing the receiver's keys." > > Â Â Â Â | result | > Â Â Â Â result := Set basicNew. > Â Â Â Â result setTally: tally array: (array collect: [ :each | > Â Â Â Â Â Â Â Â each isNil ifFalse: [ each key ] ]). > Â Â Â Â ^ result > > This returns a Set, so it wouldn't break any semantics. In my > benchmark this is roughly 8x faster than the current implementation, > and 2x faster than the optimized Squeak implementation. > > The drawback is that it makes some heavy assumptions on the internal > structure of Dictionary, Association and Set. > > Lukas > > 2009/12/4 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: >> A small addendum ;) >> On 03.12.2009 22:13, Nicolas Cellier wrote: >>> 3) identify thise sending a potential inefficient message (includes:) >>> insert keys asSet in this case (only if includes: is in a loop!) >>> >>> >> 3b. If the keys collection isn't used for anything else, change to use >> includesKey: instead. >> >> Cheers, >> Henry >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 4, 2009

Re: [Pharo-project] about keys returning a set

by Lukas Renggli

I wonder if ever something along the following lines was considered? Dictionary>>keys "Answer a Set containing the receiver's keys." | result | result := Set basicNew. result setTally: tally array: (array collect: [ :each | each isNil ifFalse: [ each key ] ]). ^ result This returns a Set, so it wouldn't break any semantics. In my benchmark this is roughly 8x faster than the current implementation, and 2x faster than the optimized Squeak implementation. The drawback is that it makes some heavy assumptions on the internal structure of Dictionary, Association and Set. Lukas 2009/12/4 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: > A small addendum ;) > On 03.12.2009 22:13, Nicolas Cellier wrote: >> 3) identify thise sending a potential inefficient message (includes:) >> insert keys asSet in this case (only if includes: is in a loop!) >> >> > 3b. If the keys collection isn't used for anything else, change to use > includesKey: instead. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 4, 2009

Re: [Pharo-project] about keys returning a set

by Henrik Sperre Johansen

A small addendum ;) On 03.12.2009 22:13, Nicolas Cellier wrote: > 3) identify thise sending a potential inefficient message (includes:) > insert keys asSet in this case (only if includes: is in a loop!) > > 3b. If the keys collection isn't used for anything else, change to use includesKey: instead. Cheers, Henry

Dec. 4, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by James Foster

On Dec 3, 2009, at 2:19 PM, StÃ©phane Ducasse wrote: > I'm not sure that forbidding new: is a good idea. In Smalltalk it is rare to forbid such methods. "If an instance created by sending the #new method ... would cause an error, a common practice is to override the behavior of #new so that it fails." Skublics, Klimas, & Thomas, Smalltalk with Style, p. 14 (Prentice Hall, 1996). James Foster

Dec. 4, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by Martin McClure

StÃ©phane Ducasse wrote: > I'm not sure that forbidding new: is a good idea. > In Smalltalk it is rare to forbid such methods. > There are actually quite a few examples in existing code where #new and #new: are implemented as #shouldNotImplement or #error:. Classes that require a special way of creating their instances, such as CompiledMethod, often disallow new:. Singleton classes disallow new. Symbols seem to fit the pattern pretty well, and although it doesn't cause huge problems it seems like you shouldn't be able to create an invalid system state by sending public messages like #new:. Regards, -Martin

Dec. 4, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by StÃ©phane Ducasse

>> From: Sheridan Mahoney <sheridan(a)sheridan-mahoney.com> >> Date: December 3, 2009 11:04:19 PM GMT+01:00 >> To: pharo-project-bounces(a)lists.gforge.inria.fr >> Subject: Re: getting rid of Symbol >> new: ? >> Reply-To: sheridan(a)sheridan-mahoney.com >> >> >> A colleague and I are investigating the ImageSegment class and its methods, we came across an issue I would like to get external opinions on. Newbie alert, BTW (at least one of us, no names mentioned...). Also, this is not a problem that will affect many users, but it is familiarizing us with the check-in process, slices, etc. While working on ImageSegment tests, we discovered a problem on trying to load segments that had Symbols in the root array. It is possible to create 2 ByteSymbols with the same sequence of characters. :( In trying to track down how this is possible, we came across a side issue, that ByteSymbol new: had the capacity to create multiple new ByteSymbols with the same number of nil characters (as in, initialized with nil). We want to dissallow Symbol new: , which would cause people to use one of the nicer methods for Symbol/ByteSymbol creation (namely, one which checks that the sequence of characters doesn't already exist, as part of the creation process). We have a fix we want to check in, but currently it breaks a test case in the SymbolTest class, which is checking that new: works. We also changed the intern: method on the class side of Symbol to use basicNew: instead of new: . Are there reasons to keep 'Symbol new:' , that outweigh the reasons to get rid of it? >> Many thanks, >> and Cheers, >> Sheri Mahoney I'm not sure that forbidding new: is a good idea. In Smalltalk it is rare to forbid such methods. Do you know from where your two byteSymbols were coming? Stef

Dec. 3, 2009

Re: [Pharo-project] code coverage?

by Alexandre Bergel

> does your spy support spy itself or detect that and does not spy > dangerous > guys. So far no. I would love to have Reflectivity for this... Cheers, Alexandre > > Stef > > On Dec 3, 2009, at 10:57 PM, Alexandre Bergel wrote: > >> hi John, >> >> I have been working on a code instrumentation mechanism that use the >> "object as method" trick to get the runtime info. The "hello world" >> of >> the test coverage of Spy could be: >> 1- open a workspace, and doit: >> Gofer new >> squeaksource: 'Spy'; >> addPackage: 'ConfigurationOfSpy'; >> load. >> (Smalltalk at: #ConfigurationOfSpy) perform: #loadDefault. >> >> 2- doit: >> CoveragePackageSpy viewCoverageForPackagesMatching: 'Mondrian*' >> >> 3- after few seconds, a mondrian window will open. Pink inner boxes >> methods that are not covered by unit tests. The expression above >> (i)instruments all methods belonging to Mondrian, (ii) run all the >> test, (iii) open a simple mondrian visualization that tells whether a >> method is executed or not when running th test. >> >> So far, it is good enough for small and controlled experiments. I >> would to do the coverage for the whole image, but I need some time >> for >> this. In 2 weeks I will be in holidays, I will therefore have time to >> work on this. >> >> I also worked on a mechanism to extract type information from SUnit >> tests. >> Try: (TypingPackageSpy runTestAndGatherForPackagesMatching: >> 'Mondrian*') viewBasic >> >> Cheers, >> Alexandre >> >> On 3 Dec 2009, at 17:20, John M McIntosh wrote: >> >>> >>> On 2009-12-03, at 7:33 AM, Alexandre Bergel wrote: >>> >>>>>> Ok as I'm testing this new VM I"m wondering has anyone done a >>>>>> code >>>>>> coverage review of the Pharo >>>>>> image in relationship to the suite of available tests? I >>>>>> wondering >>>>>> how much of the image side code is >>>>>> actually used? >>>>>> >>>>>> Part of the problem here in cross checking the list of internal >>>>>> plugins is that I need test cases to >>>>>> actually exploit the plugin code so that I can confirm it works, >>>>>> even to confirm it gets called. >>>>> >>>>> this would be really interesting indeed. >>>>> alex is spy working enough to see that? >>>> >>>> I used Spy on a number of projects, including Moose, Glamour, >>>> Mondrian, Seaside, ... >>>> But checking it on the whole image is worth trying. >>>> >>>> Give me a couple of hours... >>> >>> Thank you, allow me to give some clues about what internal plugins >>> are in each macintosh VM (3.x, 4.x) series. >>> >>> >>> ADPCMCodecPlugin_exports, class ADPCMCodec >>> AsynchFilePlugin_exports, class AsynchFile >>> B2DPlugin_exports, class BallonEngine >>> BitBltPlugin_exports, class BitBlt,WarpBlt >>> DSAPrims_exports, class SHA1,SecureHashAlgorithm >>> FFTPlugin_exports, class FFT >>> FilePlugin_exports, class FileDirectory,StandardFileStream >>> FloatArrayPlugin_exports, class >>> BallonBuffer,FloatArray,MatrixTransform2x3 >>> HostWindowPlugin_exports, class HostWindowProxy + subclasses >>> InternetConfigPlugin_exports, class InternetConfiguration >>> JoystickTabletPlugin_exports, class InputEventSensor >>> JPEGReaderPlugin_exports, class JPEGReadWriter >>> JPEGReadWriter2Plugin_exports, class JPEGReadWriter2 >>> LargeIntegers_exports, Large positive/negative number >>> usage... >>> MacMenubarPlugin_exports, class HostSystemMenus + subclasses >>> Matrix2x3Plugin_exports, class MatrixTransform2x3 >>> MIDIPlugin_exports, class MidiPrimTester,SimpleMIDIPort >>> MiscPrimitivePlugin_exports, class BitMap, ByteArray, >>> ByteString,ByteSymbol,SampledSound >>> SecurityPlugin_exports, class SecurityManager >>> SerialPlugin_exports, class SerialPort >>> SocketPlugin_exports, class NetNameResolver, >>> Socket,SocketAddress >>> SoundCodecPrims_exports, class GSMCodec >>> SoundGenerationPlugin_exports, class >>> FMSound,LoopedSampledSound,PluckedSound,ReverbSound,SampledSound >>> SoundPlugin_exports, class SoundPlayer,SoundRecorder >>> UUIDPlugin_exports, class UUID >>> ZipPlugin_exports, class >>> DeflateStream,FastInflateStream,NSAbstractDeflateStream >>> +subclasses,ZipEncoder, ZipWriteStream >>> >>> >>> These plugins are built in, but not used directly by Pharo >>> 1.0-10496-rc1dev09.11.4.image >>> >>> B3DAcceleratorPlugin_exports, Requires Ballon 3d http://www.squeaksource.com/Balloon3D.html >>> Squeak3D_exports, >>> >>> BMPReadWriterPlugin_exports, Oddly the smalltalk usage of this >>> plugin was deleted by the author. >>> GeniePlugin_exports, Requires http://www.squeaksource.com/genie.html >>> Klatt_exports, Requires http://www.squeaksource.com/ >>> Speech.html >>> RePlugin_exports, I think this is for the http://www.squeaksource.com/Regex.html >>> StarSqueakPlugin_exports, Etoys >>> SurfacePlugin_exports, Internal usage and exploited by various >>> plugins like QuickTime for Sophie >>> -- >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> ==================================================================== >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >>> squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http:// >>> www.smalltalkconsulting.com >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> ==================================================================== >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 3, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by StÃ©phane Ducasse

> From: Sheridan Mahoney <sheridan(a)sheridan-mahoney.com> > Date: December 3, 2009 11:04:19 PM GMT+01:00 > To: pharo-project-bounces(a)lists.gforge.inria.fr > Subject: Re: getting rid of Symbol >> new: ? > Reply-To: sheridan(a)sheridan-mahoney.com > > > A colleague and I are investigating the ImageSegment class and its methods, we came across an issue I would like to get external opinions on. Newbie alert, BTW (at least one of us, no names mentioned...). Also, this is not a problem that will affect many users, but it is familiarizing us with the check-in process, slices, etc. While working on ImageSegment tests, we discovered a problem on trying to load segments that had Symbols in the root array. It is possible to create 2 ByteSymbols with the same sequence of characters. :( In trying to track down how this is possible, we came across a side issue, that ByteSymbol new: had the capacity to create multiple new ByteSymbols with the same number of nil characters (as in, initialized with nil). We want to dissallow Symbol new: , which would cause people to use one of the nicer methods for Symbol/ByteSymbol creation (namely, one which checks that the sequence of characters doesn't already exist, as part of the creation process). We have a fix we want to check in, but currently it breaks a test case in the SymbolTest class, which is checking that new: works. We also changed the intern: method on the class side of Symbol to use basicNew: instead of new: . Are there reasons to keep 'Symbol new:' , that outweigh the reasons to get rid of it? > Many thanks, > and Cheers, > Sheri Mahoney

Dec. 3, 2009

[Pharo-project] news about PackageInfo substitute candidate

by StÃ©phane Ducasse

Hi guys I continued to code on PackgeInfo killing and I changed completely the internal structure of an RPackage. All the tests are green now. Now I should read what john and don did in RBSelectorEnvironment because this is really similar. After I should deal with - class renaming - hooking into the system (ugly) - how to make sure that * are sucked in and sucked out. Some people told me that they would like to help and you are welcome. The code is in PharoTaskForces/RPackage Stef

Dec. 3, 2009