- Pharo-dev - lists.pharo.org

[Pharo-project] 1.1 -- Inconsistent enumeration behavior of WeakKeyDictionary and subclasses
by Martin McClure Dec. 31, 2009

Dec. 31, 2009

If you run this in 1.1: | dict | dict := WeakKeyDictionary new. dict at: 'foo' copy put: 'bar'. Smalltalk garbageCollect. dict associationsDo: [:assoc | self halt]. dict do: [:val | self halt] It stops in the second halt, but not the first. This is because #associationsDo: does not include associations whose keys have been GCed, but #do: *does* include values whose corresponding keys have been GCed. This behavior seems inconsistent, and not particularly useful, and also seems to contradict the comments by the author in the Squeak bug from 2007, from which I'd think that #do: would not include the value which it currently does. So I *think* this is an oversight, and is easy to fix by defining WeakKeyDictionary>>do: in terms of self associationsDo:. But then there's the question of #size. The collection above answers 1 to #size, which also seems wrong. Comments? Regards, -Martin

3 4

Re: [Pharo-project] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )
by Igor Stasenko Dec. 31, 2009

Dec. 31, 2009

2009/12/28 Andreas Raab <andreas.raab(a)gmx.de>: > Igor Stasenko wrote: >> >> 1. diff the number of lines between existing traits implementation & yours >> ? > > It's a bit tricky to get a precise comparison, since Berne traits reuse > various methods across Kernel-Classes and Traits. OTOH, there are many > methods that will be removed from Kernel due to completely unnecessary > complexities. I think the real comparison can only be done if you look at > the totals of Kernel+[Nano]Traits before and after and since I haven't done > the cleanup yet there is a bit of a problem in comparing this precisely. But > you give an idea, here is a bit of data measured as follows: > > #('Traits' 'Traits-Kernel' 'Traits-Kernel-Traits' 'Traits-Composition' > 'NanoTraits-Kernel' 'NanoTraits-Tests') do:[:pkgName| | pkg | > Â Â Â Â pkg := PackageInfo named: pkgName. > Â Â Â Â Transcript cr; show: pkg name; > Â Â Â Â Â Â Â Â tab; show: pkg classes size; > Â Â Â Â Â Â Â Â tab; show: pkg methods size. > ]. > > Package Â Â Â Â Â Â Â Â Classes Â Â Â Â Methods > Traits Â Â Â Â Â Â Â Â Â 59 Â Â Â Â Â Â Â 873 > Traits-Kernel Â Â Â Â Â 22 Â Â Â Â Â Â Â 343 > Traits-Kernel-Traits Â Â 17 Â Â Â Â Â Â Â 215 > Traits-Composition Â Â Â 7 Â Â Â Â Â Â Â 127 > NanoTraits-Kernel Â Â Â 9 Â Â Â Â Â Â Â 190 > NanoTraits-Tests Â Â Â Â 9 Â Â Â Â Â Â Â 122 > oh, that's quite a big difference. I am curious, is it because of simpler implementation or because of smaller feature set? > The "meat" for NanoTraits is 9 classes and 190 methods And, after installing > NanoTraits there will be many other methods removed in Behavior and friends > which are only the result of unnecessary complexity in Berned traits. It > will be *significantly* simpler by any measures and unloadable. > >> 2. tools support, MC, Browser etc ? > > Same as before. Slightly better on older systems (i.e., 3.8 based) because > browsers can cope with traits as is and mostly don't need special support > (i.e., using #classSide etc). > >> 3. are there some common protocols with old traits, so one could use >> traits for metaprogramming? > > As far as black-box reuse is concerned, there is no difference at all. There > is also plenty of common stuff for the internals but it's very hard to know > which protocols a particular client would use. > Well, browser should use some protocol to distingush between traits & classes, trait methods and regular ones etc.. As well as MC, SystemNotifier , changesets etc. Do you plan to fully adopt new traits in trunk (means completely replacing current ones, of course)? >> I haven't time to take a look at your code. But if it is smaller & >> less complex than current version, i will vote for it. > > Try it. Load it via: > > (Installer repository: 'http://www.squeaksource.com/NanoTraits') > Â Â Â Â install: 'NanoTraits-Kernel'; > Â Â Â Â install: 'NanoTraits-Tests'. > > then install it using: > > Â Â Â Â NanoTrait install. > > (WARNING: Be prepared to throw the image away if something goes wrong) > >> I just have some concerns about common protocols, so developers could >> use traits in both pharo & squeak without need of refactoring. > > Fair enough. I don't think there's much difficulty as far as extending the > existing protocols go. We could even add compatibility traits > (TCompilingBehavior etc) that model the old structure if people want to add > extension methods to those. > AFAIK, Pharo cleaned-up some stuff , removed this particular trait. I am however, think that putting traits in use for core classes having one VERY IMPORTANT aspect, that in this way we can decompose a bloated protocol(s) into a number a smaller ones, with well-distinguished roles, aside of code reuse. > And hey, my code is always MIT, so if the Pharo folks are interested, tell > them they're more than welcome to use and enhance it. The squeaksource > repository is world-writable. Aye, i CC this conversation to pharo list. Personally, amount of code is the major criteria for me to choose from. Especially for things in Kernel. And especially, if it doesn't having heavy tradeoffs. > > Cheers, > Â - Andreas > > -- Best regards, Igor Stasenko AKA sig.

5 14

[Pharo-project] Fwd: 2GB changes file and a pony (was: [squeak-dev] ALL CLEAR (Re: CompiledMethodTrailers ready for use))
by Igor Stasenko Dec. 30, 2009

Dec. 30, 2009

---------- Forwarded message ---------- From: David T. Lewis <lewis(a)mail.msen.com> Date: 2009/12/27 Subject: Re: 2GB changes file and a pony (was: [squeak-dev] ALL CLEAR (Re: CompiledMethodTrailers ready for use)) To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> I have put the updates for large changes and sources files into the inbox. I would appreciate if someone can review this before moving into trunk. There are three mcz updates: Â Files-dtl.62 Â System-dtl.205 Â Kernel-dtl.347 Important: The changes *must* be loaded in the order listed above. This will require a configuration map update when the changes are moved to trunk. The use of ExpandedSourceFileArray takes effect after the first image restart. To change back to using the StandardSourceFileArray, the procedure is as follows: Â 1) Evaluate 'StandardSourceFileArray install' Â 2) Edit SourceFileArray class>>concreteClass to answer Â Â StandardSourceFileArray rather than ExpandedSourceFileArray. Thanks, Dave -- Best regards, Igor Stasenko AKA sig.

4 7

[Pharo-project] Squeak VM Opt[31852:903] Can't open input server /Library/InputManagers/Inquisitor
by StÃ©phane Ducasse Dec. 30, 2009

Dec. 30, 2009

Hi john When I'm doing /Applications/Squeak/Squeak\ 4.2.2beta1U.app/Contents/MacOS/Squeak\ VM\ Opt coral.image I get 2009-12-30 22:38:01.629 Squeak VM Opt[31852:903] Can't open input server /Library/InputManagers/Inquisitor Also this is strange but I have the impression that the image starts seems slower (of course I have around or more 20 app open). Stef

1 0

Re: [Pharo-project] Pharo-beginner mailing list ? (St?phane Ducasse)
by John Escobedo Dec. 30, 2009

Dec. 30, 2009

+1 Please start a beginner mailing list because Pharo is also some people's first look at smalltalk. A place to ask a mixture of question that come from being new to both would be welcome.

3 2

[Pharo-project] I have a problem with 11126
by StÃ©phane Ducasse Dec. 30, 2009

Dec. 30, 2009

hi igor up to 11125 it works well and after when I was trying to do the last two cs using MC in 11125 I get new ^ self trailerClass basicNew initialize trailerClass ^ TrailerClass ifNil: [ OldMethodTrailer ] in 11126 when I try to load these packages. I get CompiledMethodTrailer new does understand trailerClass Stef (now I have to run downtown with my boys and I will come back in 2hours or so). CompiledMethodTrailer class(Object)>>doesNotUnderstand: #trailerClass CompiledMethodTrailer class>>new CompiledMethod>>trailer CompiledMethod>>getSourceFor:in: Metaclass(Behavior)>>sourceCodeAt:ifAbsent: Metaclass(Behavior)>>ultimateSourceCodeAt:ifAbsent: Browser(CodeHolder)>>sourceStringPrettifiedAndDiffed Browser>>selectedMessage Browser>>contents PluggableTextMorph>>getText PluggableTextMorph>>update: [] in Browser(Object)>>changed: DependentsArray>>do: Browser(Object)>>changed: Browser(Object)>>contentsChanged Browser(CodeHolder)>>contentsChanged Browser>>messageListIndex: PluggableListMorph>>changeModelSelection: PluggableListMorph>>mouseUp: PluggableListMorph(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableListMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: PluggableListMorph(Morph)>>processEvent:using: PluggableListMorph(Morph)>>processEvent: PluggableListMorph>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: [] in PasteUpMorph>>becomeActiveDuring: BlockClosure>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: Array(SequenceableCollection)>>do: WorldState>>handsDo:

2 5

Re: [Pharo-project] We need to do something, seriously!!!! [WAS] Fwd: Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols
by Dale Henrichs Dec. 30, 2009

Dec. 30, 2009

2 1

[Pharo-project] Issue 1720: Recompile on a class should only recompile that class, not the whole image
by Stan Shepherd Dec. 30, 2009

Dec. 30, 2009

pharo1.0-10502-rc1web09.12.2 Class browser used (if applicable): OBSystemBrowserAdaptor Steps to reproduce: 1.Middle click on any class 2.select refactor, recompile 3. alt-. ORCmdRecompile execute OBWaitRequest block: [ self environment classesAndSelectorsDo: [ :class :selector | class recompile: selector from: class ] ] where self environment = Smalltalk Surely it should only recompile the class we clicked on. ...Stan -- View this message in context: http://n2.nabble.com/Issue-1720-Recompile-on-a-class-should-only-recompile-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

1 0

[Pharo-project] Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols
by Stan Shepherd Dec. 30, 2009

Dec. 30, 2009

NB this logs a particular walkback, but the whole area appears to be unworkable in the web dev image. Please could the maintainers click, right click, middle click on each part of refactoring browser, take each menu item, etc. This will be much quicker than logging one bug at a time. If this turns out to be the last one, my apologies in advance. Thanks. ...Stan VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Image: PharoCore1.0rc1 [Latest update: #10502] pharo1.0-10502-rc1web09.12.2 Class browser used (if applicable): OR2PackageBrowser. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols Receiver: OBClassNode<ShortIntegerArray> Arguments and temporary variables: aMessage: dynamicProtocols exception: MessageNotUnderstood: OBClassNode>>dynamicProtocols resumeValue: nil Receiver's instance variables: metaNode: Class #allCategory->AllMethodCategory #categories->MethodCategory #dy...etc... navigation: an O2DefaultEdgeNavigation theClass: ShortIntegerArray O2MetaEdge>>nodesForParent: Receiver: #dynamicProtocols->DynamicProtocols Arguments and temporary variables: aNode: OBClassNode<ShortIntegerArray> Receiver's instance variables: label: 'dynamicProtocols' selector: #dynamicProtocols metaNode: DynamicProtocols #methods->Method navigation: an O2DefaultEdgeNavigation isDropEdge: nil ... -- View this message in context: http://n2.nabble.com/Issue-1721-Refactoring-appears-to-be-broken-in-web-dev… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

1 0

[Pharo-project] New class factory for tests (and other use cases)
by Adrian Kuhn Dec. 30, 2009

Dec. 30, 2009

`ClassFactoryForTestCase` is a awesome tool when you need to create throw-away classes for tests. And the new akuhn/SUnit includes a DSL that makes creating anonymous classes even simpler! The new DSL is put in a new class to avoid compatibility issues. To create an anonymous class just do class := ClassFactory newClass. this creates a new subclass of Object. The creates classes is automatically reclaimed by garbage collection when no longer used. That is, tear down of class factory is not required anymore. The class is created without logging and not registered with the system. That is, `Object subclasses` does not include the created class. To create a subclass of a specific class do class := ClassFactory newSubclass: Point. To create a subclass with accessors do class := ClassFactory newSubclass: Point with: [ :f | f compileAccessorsFor: 'color' ]. If you want getters or setters only, use `#compileSetterFor:` or `#compilerGetterFor:`. If you want an instance variable without accessor, use `#declareInstVar:`. To create a subclass with methods do class := ClassFactory newSubclass: Point with: [ :f | f compile: 'answer ^ 42' ]. NB: please note that class factory compiles silently without logging. To create a method on the class side do class := ClassFactory newSubclass: Point with: [ :f | f forClass: [ :cf | cf compile: 'somePoint ^ self x: 2 y: 3' ]]. In fact, the class side factory `cf` supports the same protocol as the instance side factory. Please note that creating instance variables on the class side creates "class instances variables" and not "instance class variables". That is, they are local to the creates class but not to subclasses of the created class. Typically this should not be a limitation since you only create one class without further subclasses. Also, please note that the created classes and all instances created from that class are ment to be thrown away after their use. The created class is not registered with the system, and thus when you change the instance size of its superclass the created instances will not be updated. Gofer it disablePackageCache; squeaksource: 'akuhn'; package: 'SUnit'; package: 'SUnitGUI'; load --AA

3 8