February 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3751 in pharo: [FEATURE]: Bringing a window to the front does not effect the selection/cursor

by pharo＠googlecode.com

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…

Feb. 24, 2011

Re: [Pharo-project] Should tools cancel the selection when brought to front?

by Sean P. DeNigris

I'll open an issue. 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.

Feb. 24, 2011

Re: [Pharo-project] Issue 3723 in pharo: The Finder tool does not alphabetize methods.

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3723 by marcus.d...(a)gmail.com: The Finder tool does not alphabetize methods. http://code.google.com/p/pharo/issues/detail?id=3723 In 13063

Feb. 24, 2011

Re: [Pharo-project] Issue 3740 in pharo: Provide Settings to directly open the full Debugger View

by pharo＠googlecode.com

Updates: Status: Closed Comment #4 on issue 3740 by marcus.d...(a)gmail.com: Provide Settings to directly open the full Debugger View http://code.google.com/p/pharo/issues/detail?id=3740 in 13063

Feb. 24, 2011

Re: [Pharo-project] Issue 3749 in pharo: new TimeProfiler integration

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3749 by marcus.d...(a)gmail.com: new TimeProfiler integration http://code.google.com/p/pharo/issues/detail?id=3749 in 13062

Feb. 24, 2011

[Pharo-project] classbuilder...

by StÃ©phane Ducasse

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.

Feb. 24, 2011

Re: [Pharo-project] Error 'primSocket:connectTo:port: failed' in 1.1.11411 on windows xp..

by Diogenes Moreira

Well I find a work arround.. use the hostname instead of ip I don't know why,, but work.. Best.. On Thu, Feb 24, 2011 at 2:42 PM, Diogenes Moreira < diogenes.moreira(a)gmail.com> wrote: > Any clue to solve this.. > > Best... >

Feb. 24, 2011

Re: [Pharo-project] SqueakDBX enableEncryption:

by Mariano Martinez Peck

Thanks. Indeed, it was not just a typo, but a real bug instead. THe encryption option (always, never, and try) where not taken into account. I fixed and I also update the website: Name: OpenDBX-Core-MarianoMartinezPeck.280 Author: MarianoMartinezPeck Time: 24 February 2011, 6:46:26 pm UUID: d3fe4234-0293-4c07-95ae-4f34bb82ffaf Ancestors: OpenDBX-Core-MarianoMartinezPeck.279 Stupid bug in the ecryption test thanks Mariano On Wed, Feb 23, 2011 at 9:02 PM, DougEdmunds <dougedmunds(a)gmail.com> wrote: > > 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. > >

Feb. 24, 2011

[Pharo-project] Error 'primSocket:connectTo:port: failed' in 1.1.11411 on windows xp..

by Diogenes Moreira

Any clue to solve this.. Best...

Feb. 24, 2011

Re: [Pharo-project] I am I am I am ... [WAS] Re: [COTDC] 17 - MCSnapshotReader

by Eliot Miranda

On Thu, Feb 24, 2011 at 3:25 AM, Craig Latta <craig(a)netjam.org> wrote: > > Hi Mariano-- > >> I know the reasons and the history... > > Â Â Hm, I don't think I know the history. As far as I can tell, > Smalltalk-80 used "the receiver" instead of "I". When did the > anthropomorphic style arise? >From at least Smalltalk-80 V2. AFAIA ParcPlace systems started "cleaning up" class comments adding the impersonal style in the Objectworks 2.5 timeframe. The following is derived from the Smalltalk-80 V2 sources: $ grep "I am " BrouHaHa/XeroxV2.0/Smalltalk-80.sources.lf | wc 82 2232 13441 $ grep "I am " BrouHaHa/XeroxV2.0/Smalltalk-80.sources.lf | sed 's/\..*/./' | pbcopy 'I am a RunArray where each run represents the virtual addresses of a block of contiguous pages. 'I am a code controller that will do an accept even if the text is the same. 'I am an arrayed collection of pointers. 'I am an abstract collection of elements with integers as external keys. Association comment: 'I am a pair of associated objects--a key and a value. Bag comment: 'I am an unordered collection of elements. 'I am a view of a BinaryChoice. BlockNode comment: 'I represent a bracketed block with 0 or more arguments and 1 or more statements. "I am a copy; put me in the right state to browse a hierarchy" 'I am a StandardSystemView that provides initialization methods (messages to myself) to create and schedule the various system browsers: System Browser, System Category Browser, Class Browser, Message Category Browser, Message Browser. 'I am a Switch that turns off automatically after being turned on, that is, I act like a push-button switch. 'I am the text view controller for a change browser. 'I am the controller for ChangeListView, handling the list menu. 'I am a list view of various system changes. 'I am a class used for running static checks over the system. I am created during fileIn in response to "class methodsFor: cat" message. 'I am a change to some part of a class definition (actual definition, comment, name, . 'I am a change to some part of a class comment. 'I am a change to some part of a class definition. 'I am a change related in some way to a particular class. 'I am a TextView that assumes the text is code. Collection comment: 'I am the abstract class of all collection classes. 'I am a FillInTheBlankController that causes termination on a carriage return. 'I am a 16 x 16 dot matrix suitable for use as the current cursor. 'I am used by the decompiler to construct parse tree nodes and other appropriate items corresponding to each unit identified by the decompiler. Dictionary comment: 'I am a set of associations. 'I am a display object which can both paint myself on a medium (displayOn: messages), and can act as a medium myself. if I am displayed at location. 'I am an abstract representation of a collection of FilePages and a reference to a FileDirectory which contains me. fileName <String> The name of the file I am viewing. 'I am a StringHolderController for a FillInTheBlankView. 'I am a view of a FillInTheBlank--I display a query and an area in which the user can type some information. FormButtonCache comment: 'I am used to save information needed to construct the menu for the form editor. IdentityDictionary comment: 'I am a subclass of Dictionary in which the lookup is done using == rather than =. 'I am a SwitchController that has its View (a SwitchView) highlighted while the model (a Switch) handles the messages it is sent. 'I am a StandardSystemView that provides initialization methods (messages to myself) to create and schedule the interface to an object Inspector. 'I am a common abstract superclass for all Integer implementations. LeafNode comment: 'I represent a leaf node of the compiler parse tree. Link comment: 'I am a simple record of a pointer to another Link'! 'I am a kind of ScrollController that assumes that the view is a kind of ListView. 'I am an abstract View of a list of items. LiteralNode comment: 'I am a parse tree leaf representing a literal string or number'! 'I am a kind of ListController that blocks new selections if the model is locked--i. 'I am a SwitchController that will not take control if the model (a Switch) is locked. MappedCollection comment: 'I am re-ordering or subcollecting of a writeable SequenceableCollection. MethodNode comment: 'I am the root of the parse tree. "I am the root of a parse tree; answer with an instance of CompiledMethod. "I am the root of a parse tree; answer with a sorted collection of associations 'I am a Controller that modifies the scheduling of user activities so that the three mouse buttons can be used to make selections or display menus. 'I represent a controller that never wants control. 'I am a kind of MouseMenuController that creates a yellow button menu for proceeding an interrupted process or for creating and scheduling a debugger on the interrupted machine state. 'I am a view of interrupted machine state. 'I am a kind of Switch that can be connected to some related object, typically to a collection of my instances. 'I am a code controller that will not take control unless my model has some selection. 'I am a code view for an OnlyWhenSelectedCodeController. OrderedCollection comment: 'I am an ordered collection of elements. 'I keep track of the current and high position of the stack that will be needed by code being compiled. Point comment: 'I am an x-y pair of numbers usually designating a location on the screen'! PositionableStream comment: 'I assume that my contents is an indexable collection and that, in support of accessing the elements of my contents, I can reposition a pointer. "Since I am not necessarily writable, it is up to my subclasses to override myList <LinkedList> on which I am suspended 'I am a kind of StringHolderController (a ParagraphEditor that adds the doIt, printIt, accept, and cancel commands). 'I am a StringHolderView of the description of a Project. ReadStream comment: 'I am a reader of an indexable collection. ReadWriteStream comment: 'I am a positionable stream into which we can both read and write. 'I am the controller for the parts of the display screen that have no window on them. 'I represent control for scrolling using a scrollBar. SelectorNode comment: 'I am a parse tree leaf representing a selector'! Set comment: 'I am an unordered collection of elements that are not duplicated in me. ["Negate carefully in case I am SmallInteger minVal" SortedCollection comment: 'I am an ordered collection of elements, sorted via the function sortBlock. 'I am a controller for StandardSystemViews, that is, those views that are at the top level of a project in the system user interface. Stream comment: 'I am an abstract class representing objects that stream over a self typing data structure. String comment: 'I am an indexed collection of Characters. 'I am a View of a String that is an aspect of a more structured object. 'I represent a selection setting and actions to take depending on a change in the setting. 'I am a view of a Switch. SystemDictionary comment: 'I am a special dictionary that supports protocol for asking questions about the structure of the system. 'I am a kind of StringHolderController (a ParagraphEditor) that adds the doIt, printIt, accept, and cancel commands. 'I am a StringHolderView of the description of the contents of a TextCollector or Transcript. VariableNode comment: 'I am a parse tree leaf representing a variable. WriteStream comment: 'I am a writer of an indexable collection. > >> And it is even worst when you read it outside a system browser (like >> in a webpage or any kind of document). > > Â Â I don't think it's particularly worse if you still have the context > (which class you're talking about). > >> Am I alone? > > Â Â No, I recall a couple of others who didn't like it either. In my > experience, though, the vast majority either don't care or like it at > least as much as you dislike it. :) Â Personally, in a system so strongly > inspired by biological and verbal metaphors, I think it makes a great > deal of sense. It's sweet and cuddly and not a bad thing for all that. The false assumption is that the impersonal style is more informative. It's not intrinsically better, merely plays to our prejudices of what good technical documentation should be; style over substance. The important thing is whether a class comment is useful not whether it is written in an approachable style or not. Persnally I prefer the approachable style, but prefer useful documentation over style any day. 2Â¢ Eliot > > > -C > > -- > Craig Latta > www.netjam.org/resume > +31 Â 06 2757 7177 > + 1 415 Â 287 3547 > > > > >

Feb. 24, 2011