- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3724 in pharo: Finder updated
by pharo＠googlecode.com Feb. 24, 2011

Feb. 24, 2011

Status: Fixed Owner: Benjamin...(a)gmail.com New issue 3724 by Benjamin...(a)gmail.com: Finder updated http://code.google.com/p/pharo/issues/detail?id=3724 Finder-BenjaminVanRyseghem.20 in PharoInbox Issue 3722: no comment I also added a 'Search' button that force the finder to perform the search :)

1 3

[Pharo-project] Issue 3751 in pharo: [FEATURE]: Bringing a window to the front does not effect the selection/cursor
by pharo＠googlecode.com Feb. 24, 2011

Feb. 24, 2011

Status: New Owner: ---- New issue 3751 by sean.p.d...(a)gmail.com: [FEATURE]: Bringing a window to the front does not effect the selection/cursor http://code.google.com/p/pharo/issues/detail?id=3751 Motivation: In the tools (e.g. Workspaces, Browser (System and OB)), when you click in a text field to bring the tool to the front, it cancels the selection and places the cursor where the click is. For me, this behavior is less useful than what seems to me to be the standard "clicking anywhere on me when I'm not active does nothing but activate me" behavior (e.g. try it with two Safari windows in Mac). I find my self contorting and having to move windows so I can click on the title bar of a window underneath so I don't cancel a selection which I want to evaluate repeatedly. I'd rather have one extra click to move the cursor. Implementation: It was suggested that this might be best as a setting. Discussion at: http://forum.world.st/Should-tools-cancel-the-selection-when-brought-to-fro…

1 0

[Pharo-project] Should tools cancel the selection when brought to front?
by Sean P. DeNigris Feb. 24, 2011

Feb. 24, 2011

In the tools (e.g. Workspaces, Browser (System and OB)), when you click in a text field to bring the tool to the front, it cancels the selection and places the cursor where the click is. For me, this behavior is less useful than what seems to me to be the standard "clicking anywhere on me when I'm not active does nothing but activate me" behavior (e.g. try it with two Safari windows in Mac). I find my self contorting and having to move windows so I can click on the title bar of a window underneath so I don't cancel a selection which I want to evaluate repeatedly. I'd rather have one extra click to move the cursor. What does the community think? In service, Sean -- View this message in context: http://forum.world.st/Should-tools-cancel-the-selection-when-brought-to-fro… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 4

[Pharo-project] Issue 3723 in pharo: The Finder tool does not alphabetize methods.
by pharo＠googlecode.com Feb. 24, 2011

Feb. 24, 2011

Status: New Owner: ---- New issue 3723 by DougEdmu...(a)gmail.com: The Finder tool does not alphabetize methods. http://code.google.com/p/pharo/issues/detail?id=3723 Steps to reproduce: 1) Open Finder tool from World> Tools> Finder 2) In the top left box, type "Object" 3) Change the selection in box to the right from "Selectors" to "Classes" 4) There is no 'Go' button. Click back to the top left box, where you typed "Object", then go to the keyboard, and press enter. 5) Classes with "Object" in them will appear below. 6) Select "Object". 7) Click on the little arrowhead, to make it point downward, which will show the methods for "Object". 8) Scroll through the list until you find the method "needsWork" (it's in there). I'd also suggest considering grouping by class and instance, rather than just alphabetically.

1 3

[Pharo-project] Issue 3740 in pharo: Provide Settings to directly open the full Debugger View
by pharo＠googlecode.com Feb. 24, 2011

Feb. 24, 2011

Status: New Owner: ---- New issue 3740 by camillob...(a)gmail.com: Provide Settings to directly open the full Debugger View http://code.google.com/p/pharo/issues/detail?id=3740 Instead of only opening the small preview window which requires another interaction to get to the full debugger view, directly open the full debugger view. Since this is triggered by a setting, the default behavior is unaffected. Attachments: FullDebuggerSettings.2.cs 5.4 KB

1 4

[Pharo-project] Issue 3749 in pharo: new TimeProfiler integration
by pharo＠googlecode.com Feb. 24, 2011

Feb. 24, 2011

Status: Accepted Owner: aplan...(a)gmail.com Labels: Milestone-1.3 New issue 3749 by aplan...(a)gmail.com: new TimeProfiler integration http://code.google.com/p/pharo/issues/detail?id=3749 improved UI for time profiling

1 2

[Pharo-project] classbuilder...
by StÃ©phane Ducasse Feb. 24, 2011

Feb. 24, 2011

No comment. We should rewrite it. Stef name: className inEnvironment: env subclassOf: newSuper type: type instanceVariableNames: instVarString classVariableNames: classVarString poolDictionaries: poolString category: category unsafe: unsafe "Define a new class in the given environment. If unsafe is true do not run any validation checks. This facility is provided to implement important system changes." | oldClass instVars classVars copyOfOldClass copyOfOldTraitComposition copyOfOldClassTraitComposition newClass | environ := env. instVars := instVarString subStrings: ' '. classVars := (classVarString subStrings: ' ') collect: [ :x | x asSymbol ]. "Validate the proposed name" unsafe ifFalse: [ (self validateClassName: className) ifFalse: [ ^ nil ] ]. oldClass := env at: className ifAbsent: [ nil ]. oldClass isBehavior ifFalse: [ oldClass := nil ] ifTrue: [ copyOfOldClass := oldClass copy. copyOfOldClass superclass addSubclass: copyOfOldClass. copyOfOldClass ifNotNil: [ oldClass hasTraitComposition ifTrue: [ copyOfOldTraitComposition := oldClass traitComposition copyTraitExpression ]. oldClass class hasTraitComposition ifTrue: [ copyOfOldClassTraitComposition := oldClass class traitComposition copyTraitExpression ] ] ]. "Already checked in #validateClassName:" [ | newCategory oldCategory needNew force organization | unsafe ifFalse: [ "Run validation checks so we know that we have a good chance for recompilation" (self validateSuperclass: newSuper forSubclass: oldClass) ifFalse: [ ^ nil ]. (self validateInstvars: instVars from: oldClass forSuper: newSuper) ifFalse: [ ^ nil ]. (self validateClassvars: classVars from: oldClass forSuper: newSuper) ifFalse: [ ^ nil ]. (self validateSubclassFormat: type from: oldClass forSuper: newSuper extra: instVars size) ifFalse: [ ^ nil ] ]. "See if we need a new subclass" needNew := self needsSubclassOf: newSuper type: type instanceVariables: instVars from: oldClass. needNew == nil ifTrue: [ ^ nil ]. "some error" (needNew and: [ unsafe not ]) ifTrue: [ "Make sure we don't redefine any dangerous classes" (self tooDangerousClasses includes: oldClass name) ifTrue: [ self error: oldClass name , ' cannot be changed' ]. "Check if the receiver should not be redefined" (oldClass ~~ nil and: [ oldClass shouldNotBeRedefined ]) ifTrue: [ self notify: oldClass name asText allBold , ' should not be redefined. \Proceed to store over it.' withCRs ] ]. needNew ifTrue: [ "Create the new class" newClass := self newSubclassOf: newSuper type: type instanceVariables: instVars from: oldClass. newClass == nil ifTrue: [ ^ nil ]. "Some error" newClass setName: className ] ifFalse: [ "Reuse the old class" newClass := oldClass ]. "Install the class variables and pool dictionaries... " force := (newClass declare: classVarString) | (newClass sharing: poolString). "... classify ..." newCategory := category asSymbol. organization := environ ifNotNil: [ environ organization ]. oldClass isNil ifFalse: [ oldCategory := (organization categoryOfElement: oldClass name) asSymbol ]. organization classify: newClass name under: newCategory. newClass environment: environ. "... recompile ..." newClass := self recompile: force from: oldClass to: newClass mutate: false. "... export if not yet done ..." (environ at: newClass name ifAbsent: [ nil ]) == newClass ifFalse: [ environ at: newClass name put: newClass. Smalltalk globals flushClassNameCache ]. "... set trait composition..." copyOfOldTraitComposition ifNotNil: [ newClass setTraitComposition: copyOfOldTraitComposition ]. copyOfOldClassTraitComposition ifNotNil: [ newClass class setTraitComposition: copyOfOldClassTraitComposition ]. newClass doneCompiling. "... notify interested clients ..." oldClass isNil ifTrue: [ SystemChangeNotifier uniqueInstance classAdded: newClass inCategory: newCategory. ^ newClass ]. newCategory ~= oldCategory ifTrue: [ SystemChangeNotifier uniqueInstance class: newClass recategorizedFrom: oldCategory to: category ] ifFalse: [ SystemChangeNotifier uniqueInstance classDefinitionChangedFrom: copyOfOldClass to: newClass ] ] ensure: [ copyOfOldClass ifNotNil: [ copyOfOldClass superclass removeSubclass: copyOfOldClass ]. Behavior flushObsoleteSubclasses ]. ^ newClass mutate: oldClass to: newClass "Mutate the old class and subclasses into newClass and subclasses. Note: This method is slightly different from: #mutate:toSuper: since here we are at the root of reshaping and have two distinct roots." | copyOfOldTraitComposition copyOfOldClassTraitComposition | self showProgressFor: oldClass. "Convert the subclasses" oldClass subclasses do: [:oldSubclass | | newSubclass | copyOfOldTraitComposition := copyOfOldClassTraitComposition := nil. oldSubclass hasTraitComposition ifTrue: [ copyOfOldTraitComposition := oldSubclass traitComposition copyTraitExpression ]. oldSubclass class hasTraitComposition ifTrue: [ copyOfOldClassTraitComposition := oldSubclass class traitComposition copyTraitExpression ]. newSubclass := self reshapeClass: oldSubclass toSuper: newClass. self mutate: oldSubclass to: newSubclass. copyOfOldTraitComposition ifNotNil: [ newSubclass setTraitComposition: copyOfOldTraitComposition ]. copyOfOldClassTraitComposition ifNotNil: [ newSubclass class setTraitComposition: copyOfOldClassTraitComposition ]. ]. "And any obsolete ones" oldClass obsoleteSubclasses do: [:oldSubclass | | newSubclass | oldSubclass ifNotNil: [ copyOfOldTraitComposition := copyOfOldClassTraitComposition := nil. oldSubclass hasTraitComposition ifTrue: [ copyOfOldTraitComposition := oldSubclass traitComposition copyTraitExpression ]. oldSubclass class hasTraitComposition ifTrue: [ copyOfOldClassTraitComposition := oldSubclass class traitComposition copyTraitExpression ]. newSubclass := self reshapeClass: oldSubclass toSuper: newClass. self mutate: oldSubclass to: newSubclass. copyOfOldTraitComposition ifNotNil: [ newSubclass setTraitComposition: copyOfOldTraitComposition ]. copyOfOldClassTraitComposition ifNotNil: [ newSubclass class setTraitComposition: copyOfOldClassTraitComposition ]. ]. ]. self update: oldClass to: newClass. ^newClass update: oldClass to: newClass "Convert oldClass, all its instances and possibly its meta class into newClass, instances of newClass and possibly its meta class. The process is surprisingly simple in its implementation and surprisingly complex in its nuances and potentially bad side effects. We can rely on two assumptions (which are critical): #1: The method #updateInstancesFrom: will not create any lasting pointers to 'old' instances ('old' is quote on quote since #updateInstancesFrom: will do a become of the old vs. the new instances and therefore it will not create pointers to *new* instances before the #become: which are *old* afterwards) #2: The non-preemptive execution of the critical piece of code guarantees that nobody can get a hold by 'other means' (such as process interruption and reflection) on the old instances. Given the above two, we know that after #updateInstancesFrom: there are no pointer to any old instances. After the forwarding become there will be no pointers to the old class or meta class either. Meaning that if we throw in a nice fat GC at the end of the critical block, everything will be gone (but see the comment right there). There's no need to worry. " | meta | meta := oldClass isMeta. "Note: Everything from here on will run without the ability to get interrupted to prevent any other process to create new instances of the old class." [ "Note: The following removal may look somewhat obscure and needs an explanation. When we mutate the class hierarchy we create new classes for any existing subclass. So it may look as if we don't have to remove the old class from its superclass. However, at the top of the hierarchy (the first class we reshape) that superclass itself is not newly created so therefore it will hold both the oldClass and newClass in its (obsolete or not) subclasses. Since the #become: below will transparently replace the pointers to oldClass with newClass the superclass would have newClass in its subclasses TWICE. With rather unclear effects if we consider that we may convert the meta-class hierarchy itself (which is derived from the non-meta class hierarchy). Due to this problem ALL classes are removed from their superclass just prior to converting them. Here, breaking the superclass/subclass invariant really doesn't matter since we will effectively remove the oldClass (become+GC) just a few lines below." oldClass superclass removeSubclass: oldClass. oldClass superclass removeObsoleteSubclass: oldClass. "Convert the instances of oldClass into instances of newClass" newClass updateInstancesFrom: oldClass. meta ifTrue:[oldClass becomeForward: newClass] ifFalse:[(Array with: oldClass with: oldClass class) elementsForwardIdentityTo: (Array with: newClass with: newClass class)]. Smalltalk garbageCollect. "Warning: Read this before you even think about removing the GC. Yes, it slows us down. Quite heavily if you have a large image. However, there's no good and simple alternative here, since unfortunately, #become: does change class pointers. What happens is that after the above become all of the instances of the old class will have a class pointer identifying them as instances of newClass. If we get our hands on any of these instances we will break immediately since their expected instance layout (that of its class, e.g., newClass) will not match their actual instance layout (that of oldClass). And getting your hands on any of those instances is really simple - just reshaping one class two times in rapid succession will do it. Reflection techniques, interrupts, etc. will only add to this problem. In the case of Metaclass things get even worse since when we recompile the entire class hierarchy we will recompile both, Metaclass and its instances (and some of its instances will have the old and some the new layout). The only easy solution to this problem would be to 'fix up' the class pointers of the old instances to point to the old class (using primitiveChangeClassTo:). But this won't work either - as we do a one-way become we would have to search the entire object memory for the oldClass and couldn't even clearly identify it unless we give it some 'special token' which sounds quite error-prone. If you really need to get rid of the GC here are some alternatives: On the image level, one could create a copy of the oldClass before becoming it into the new class and, after becoming it, 'fix up' the old instances. That would certainly work but it sounds quite complex, as we need to make sure we're not breaking any of the superclass/subclass meta/non-meta class variants. Alternatively, fix up #becomeForward on the VM-level to 'dump the source objects' of #become. This would be quite doable (just 'convert' them into a well known special class such as bitmap) yet it has problems if (accidentally or not) one of the objects in #become: appears on 'both sides of the fence' (right now, this will work ... in a way ... even though the consequences are unclear). Another alternative is to provide a dedicated primitive for this (instead of using it implicitly in become) which would allow us to dump all the existing instances right here. This is equivalent to a more general primitiveChangeClassTo: and might be worthwhile but it would likely have to keep in mind the differences between bits and pointer thingies etc. Since all of the alternatives seem rather complex and magical compared to a straight-forward GC it seems best to stick with the GC solution for now. If someone has a real need to fix this problem, that person will likely be motivated enough to check out the alternatives. Personally I'd probably go for #1 (copy the old class and remap the instances to it) since it's a solution that could be easily reverted from within the image if there's any problem with it." ] valueUnpreemptively.

1 0

[Pharo-project] Error 'primSocket:connectTo:port: failed' in 1.1.11411 on windows xp..
by Diogenes Moreira Feb. 24, 2011

Feb. 24, 2011

Any clue to solve this.. Best...

1 1

[Pharo-project] SqueakDBX enableEncryption:
by DougEdmunds Feb. 24, 2011

Feb. 24, 2011

Re: http://www.squeakdbx.org/Special%20options The page is not accurate. It says: "Encrypting You must call DBXConnection #enableEncryption." There is no enableEncryption method. There is enableEncryption:aEncryptionOption Please update the site to give examples of enableEncryption: Thanks. - Doug Edmunds -- View this message in context: http://forum.world.st/SqueakDBX-enableEncryption-tp3321630p3321630.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 1

[Pharo-project] I am I am I am ... [WAS] Re: [COTDC] 17 - MCSnapshotReader
by Mariano Martinez Peck Feb. 24, 2011

Feb. 24, 2011

Did I already say that I don't like the way Smalltalk classes are documented? yes yes, I know the reasons and the history, but I don't like it. And it is even worst when you read it outside a system browser (like in a webpage or any kind of document). Am I alone? On Wed, Feb 23, 2011 at 9:06 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > hehe, not so much :) > http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > 14 vs 17 > > Laurent. > > > On Wed, Feb 23, 2011 at 8:47 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > >> Was there a difference in the responses? ;-) >> >> Regards, Gary >> >> ----- Original Message ----- >> *From:* laurent laffont <laurent.laffont(a)gmail.com> >> *To:* Pharo-project(a)lists.gforge.inria.fr >> *Sent:* Wednesday, February 23, 2011 7:20 PM >> *Subject:* Re: [Pharo-project] [COTDC] 17 - MCSnapshotReader >> >> And I'm plain stupid: we've already done MCSnapshotReader last week :) >> >> Laurent - currently integrating a week of COTDC >> >> On Wed, Feb 23, 2011 at 8:14 PM, Alexandre Bergel < >> alexandre.bergel(a)me.com> wrote: >> >>> Looks okay in principle. However, 4 tests will turn yellow >>> >>> Alexandre >>> >>> >>> On 23 Feb 2011, at 16:03, laurent laffont wrote: >>> >>> > To me it seems this class is useless and that it can be safely removed. >>> The only reference is in MCMczReader>>extractDefinitionsFrom: and it can be >>> replaced by MCReader. >>> > >>> > Laurent >>> > >>> > >>> > On Tue, Feb 22, 2011 at 8:08 PM, laurent laffont < >>> laurent.laffont(a)gmail.com> wrote: >>> > Today: MCSnapshotReader >>> > >>> > >>> > Comment Of The Day Contest - One Day One Comment >>> > Rules: >>> > #1: Each day a not commented class is elected. Each day the best >>> comment will be integrated with name of the author(s). >>> > #2: If you cannot comment it, deprecate it. >>> > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >>> > >>> > Laurent >>> > >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> >> >

6 5