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

[Pharo-project] Copy for SequenceableCollection subclasses? (Was: Fix for 987)

by Henrik Johansen

Somewhat related, at least I noticed it when debugging this: Sending copy to a LinkedList or a Semaphore will give back an array, since it uses shallowCopy from SequenceableCollection. Probably applies to more of SequenceableCollection's subclasses too, f.ex. DirectoryEntry for which copy leads to an MNU. Another side-effect of strange class-hierarchy, I guess :) Not quite sure how/if you want to implement those differently. Submitted to tracker as Issue1272. Cheers, Henry On Oct 5, 2009, at 1:12 38PM, StÃ©phane Ducasse wrote: > Thanks we will integrate that as soon as we can breath :) > > On Oct 5, 2009, at 12:14 PM, Henrik Johansen wrote: > >> Updated Issue987 with a SLICE in Inbox, which "fixes" the DNU in the >> way below. >> Used printString instead of asString as proposed by HernÃ¡n, as it (in >> principle) should be more robustly implemented and thus more suited >> for debugger display. >> (If sig's idea from some time back was adopted, this should be >> debugString instead of printString, of course). >> >> Cheers, >> Henry >> >> On Oct 5, 2009, at 11:51 23AM, Henrik Johansen wrote:

Oct. 5, 2009

[Pharo-project] Fwd: [squeak-dev] The Trunk: Compiler-jcg.87.mcz

by StÃ©phane Ducasse

Begin forwarded message: > From: commits(a)source.squeak.org > Date: October 1, 2009 8:21:58 AM GMT+02:00 > To: squeak-dev(a)lists.squeakfoundation.org > Subject: [squeak-dev] The Trunk: Compiler-jcg.87.mcz > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > Joshua Gargus uploaded a new version of Compiler to project The Trunk: > http://source.squeak.org/trunk/Compiler-jcg.87.mcz > > ==================== Summary ==================== > > Name: Compiler-jcg.87 > Author: jcg > Time: 30 September 2009, 11:21:53 am > UUID: 71bf4e8d-f9f3-4371-a218-ad31a985cfd8 > Ancestors: Compiler-ul.86 > > Revert to lazy-initialization of method properties, which is used by > the externally-maintained Prolog package (which loads cleanly into > 3.10.2, but not trunk). > > Part 2 of 2... need to load -jcg.85 first (this is taken care of by > the Monticello Configuration update-jcg.32.mcm) > > =============== Diff against Compiler-ul.86 =============== > > Item was changed: > ----- Method: Parser>>addPragma: (in category 'pragmas') ----- > addPragma: aPragma > + properties := self properties copyWith: aPragma! > - properties := properties copyWith: aPragma! > > Item was changed: > ----- Method: Parser>>method:context:encoder: (in category > 'expression types') ----- > method: doit context: ctxt encoder: encoderToUse > " pattern [ | temporaries ] block => MethodNode." > > | sap blk prim temps messageComment methodNode | > - properties := AdditionalMethodState new. > encoder := encoderToUse. > sap := self pattern: doit inContext: ctxt. > "sap={selector, arguments, precedence}" > + self properties selector: (sap at: 1). > - properties selector: (sap at: 1). > encoder selector: (sap at: 1). > (sap at: 2) do: [:argNode | argNode beMethodArg]. > doit ifFalse: [self pragmaSequence]. > temps := self temporaries. > messageComment := currentComment. > currentComment := nil. > doit ifFalse: [self pragmaSequence]. > prim := self pragmaPrimitives. > self statements: #() innerBlock: doit. > blk := parseNode. > doit ifTrue: [blk returnLast] > ifFalse: [blk returnSelfIfNoOther: encoder]. > hereType == #doIt ifFalse: [^self expected: 'Nothing more']. > self interactive ifTrue: [self removeUnusedTemps]. > methodNode := self newMethodNode comment: messageComment. > ^methodNode > selector: (sap at: 1) > arguments: (sap at: 2) > precedence: (sap at: 3) > temporaries: temps > block: blk > encoder: encoder > primitive: prim > properties: properties! > > Item was changed: > ----- Method: > MethodNode > >>selector:arguments:precedence:temporaries:block:encoder:primitive: > (in category 'initialize-release') ----- > selector: selOrFalse arguments: args precedence: p temporaries: > temps block: blk encoder: anEncoder primitive: prim > + > + self > + selector: selOrFalse > + arguments: args > + precedence: p > + temporaries: temps > + block: blk encoder: > + anEncoder > + primitive: prim > + properties: AdditionalMethodState new.! > - "Initialize the receiver with respect to the arguments given." > - > - encoder := anEncoder. > - selectorOrFalse := selOrFalse. > - precedence := p. > - arguments := args. > - temporaries := temps. > - block := blk. > - primitive := prim! > > Item was changed: > ----- Method: Parser>>pragmaPrimitives (in category 'pragmas') ----- > pragmaPrimitives > | primitives | > + self properties isEmpty ifTrue: > - properties isEmpty ifTrue: > [^0]. > primitives := properties pragmas select: > [:pragma| > self class primitivePragmaSelectors includes: pragma keyword]. > primitives isEmpty ifTrue: > [^0]. > primitives size > 1 ifTrue: > [^self notify: 'Ambigous primitives']. > ^self perform: primitives first keyword withArguments: primitives > first arguments! > >

Oct. 5, 2009

[Pharo-project] Fwd: [squeak-dev] Re: The Trunk: Monticello-ar.323.mcz

by StÃ©phane Ducasse

mc semantics Begin forwarded message: > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: September 30, 2009 4:53:10 PM GMT+02:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > Subject: [squeak-dev] Re: The Trunk: Monticello-ar.323.mcz > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > Miguel Enrique CobÃ¡ Martinez wrote: >> El miÃ©, 30-09-2009 a las 04:39 +0000, commits(a)source.squeak.org >> escribiÃ³: >>> Andreas Raab uploaded a new version of Monticello to project The >>> Trunk: >>> http://source.squeak.org/trunk/Monticello-ar.323.mcz >> Doesn't Monticello has its master repository on the wiresong site? > > It does, but this is an interim experiment with the only purpose of > trying to improve our local situation a little. Plus I have no > commit rights to the upstream repository. Plus I need that now ;-) > > There is always an interesting tension between upstream and > downstream usage and we haven't really found out how to > realistically deal with that tension in a sustained manner. If > anyone has ideas, I'm all ears. > > Cheers, > - Andreas > >>> ==================== Summary ==================== >>> >>> Name: Monticello-ar.323 >>> Author: ar >>> Time: 29 September 2009, 9:38:50 am >>> UUID: 927bef84-8215-0443-afe4-c8575b3a300c >>> Ancestors: Monticello-cwp.322 >>> >>> A small improvement to MC loading. New rules are: >>> - Pass 1: Load class changes first >>> - Pass 2: Compile new / changed methods >>> - Pass 3: Install new / changed methods >>> - Pass 4: Remove old methods >>> This should provide a bit more stability to the loading process. >>> >>> =============== Diff against Monticello-cwp.322 =============== >>> >>> Item was added: >>> + ----- Method: MCMethodDefinition>>asMethodAddition (in category >>> 'accessing') ----- >>> + asMethodAddition >>> + ^MethodAddition new >>> + compile: source >>> + classified: category >>> + withStamp: timeStamp >>> + notifying: (SyntaxError new category: category) >>> + logSource: true >>> + inClass: self actualClass.! >>> >>> Item was changed: >>> ----- Method: MCPackageLoader>>basicLoad (in category 'private') >>> ----- >>> basicLoad >>> errorDefinitions := OrderedCollection new. >>> + [["Pass 1: Load everything but the methods, which are >>> collected in methodAdditions." >>> + additions do: [:ea | + [ea isMethodDefinition + ifTrue: >>> [methodAdditions add: ea asMethodAddition] >>> + ifFalse:[ea load]]on: Error do: [errorDefinitions add: ea]. >>> + ] displayingProgress: 'Reshaping classes...'. >>> + + "Pass 2: We compile new / changed methods" >>> + methodAdditions do:[:ea| ea createCompiledMethod] >>> displayingProgress: 'Compiling...'. >>> - [[ >>> - >>> - "FIXME. Do a separate pass on loading class definitions as the >>> very first thing. >>> - This is a workaround for a problem with the so-called 'atomic' >>> loading (you wish!!) >>> - which isn't atomic at all but mixes compilation of methods with >>> reshapes of classes. >>> - - Since the method is not installed until later, any class >>> reshape in the middle *will* >>> - affect methods in subclasses that have been compiled before. >>> There is probably >>> - a better way of dealing with this by ensuring that the sort >>> order of the definition lists >>> - superclass definitions before methods for subclasses but I need >>> this NOW, and adding >>> - an extra pass ensures that methods are compiled against their >>> new class definitions." >>> + "Pass 3: Install the new / changed methods >>> + (this is a separate pass to allow compiler changes to be loaded)" >>> + methodAdditions do:[:ea| ea installMethod] displayingProgress: >>> 'Installing...'. >>> + + "Pass 4: Remove the obsolete methods" >>> + removals do:[:ea| ea unload] displayingProgress: 'Cleaning >>> up ...'. >>> + + "Try again any delayed definitions" >>> - additions do: [:ea | self loadClassDefinition: ea] >>> displayingProgress: 'Loading classes...'. >>> - >>> - additions do: [:ea | self tryToLoad: ea] displayingProgress: >>> 'Compiling methods...'. >>> - removals do: [:ea | ea unload] displayingProgress: 'Cleaning >>> up...'. >>> self shouldWarnAboutErrors ifTrue: [self warnAboutErrors]. >>> + errorDefinitions do: [:ea | ea load] displayingProgress: >>> 'Reloading...'. >>> + + "Finally, notify observers for the method additions" >>> - errorDefinitions do: [:ea | ea addMethodAdditionTo: >>> methodAdditions] displayingProgress: 'Reloading...'. >>> - methodAdditions do: [:each | each installMethod]. >>> methodAdditions do: [:each | each notifyObservers]. >>> + + additions do: [:ea | ea postloadOver: (self obsoletionFor: >>> ea)] displayingProgress: 'Initializing...' >>> + ] on: InMidstOfFileinNotification do: [:n | n resume: true] >>> + ] ensure: [self flushChangesFile]! >>> - additions do: [:ea | ea postloadOver: (self obsoletionFor: ea)] >>> displayingProgress: 'Initializing...'] >>> - on: InMidstOfFileinNotification - do: [:n | n resume: true]] >>> - ensure: [self flushChangesFile]! >>> >>> > >

Oct. 5, 2009

[Pharo-project] Fwd: [squeak-dev] The Trunk: System-cwp.152.mcz

by StÃ©phane Ducasse

should avoid to OBPAckage2Browser kind of name Stef Begin forwarded message: > From: commits(a)source.squeak.org > Date: September 28, 2009 6:34:25 PM GMT+02:00 > To: squeak-dev(a)lists.squeakfoundation.org > Subject: [squeak-dev] The Trunk: System-cwp.152.mcz > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > Colin Putney uploaded a new version of System to project The Trunk: > http://source.squeak.org/trunk/System-cwp.152.mcz > > ==================== Summary ==================== > > Name: System-cwp.152 > Author: cwp > Time: 28 September 2009, 9:31:21 am > UUID: f3d14748-2ff3-408f-9ec5-6451f6b158f4 > Ancestors: System-dtl.151 > > AppRegistry now allows classes to decide how they will be displayed > in menus rather than always using the class name. > > =============== Diff against System-dtl.151 =============== > > Item was changed: > SystemOrganization addCategory: #'System-Applications'! > SystemOrganization addCategory: #'System-Change Notification'! > SystemOrganization addCategory: #'System-Changes'! > SystemOrganization addCategory: #'System-Digital Signatures'! > SystemOrganization addCategory: #'System-Digital Signatures-Tests'! > SystemOrganization addCategory: #'System-Download'! > SystemOrganization addCategory: #'System-FilePackage'! > SystemOrganization addCategory: #'System-FileRegistry'! > SystemOrganization addCategory: #'System-Finalization'! > SystemOrganization addCategory: #'System-Localization'! > SystemOrganization addCategory: #'System-Object Events'! > SystemOrganization addCategory: #'System-Object Events-Tests'! > SystemOrganization addCategory: #'System-Object Storage'! > SystemOrganization addCategory: #'System-Pools'! > - SystemOrganization addCategory: #'System-Serial Port'! > - SystemOrganization addCategory: #'System-Support'! > SystemOrganization addCategory: #'System-Preferences'! > + SystemOrganization addCategory: #'System-Serial Port'! > + SystemOrganization addCategory: #'System-Support'! > SystemOrganization addCategory: #'System-Support-Tests'! > SystemOrganization addCategory: #'System-Tools'! > > Item was changed: > ----- Method: AppRegistry class>>askForDefault (in category 'as yet > unclassified') ----- > askForDefault > > self registeredClasses isEmpty ifTrue: > [self inform: 'There are no ', self appName, ' applications > registered.'. > ^ default := nil]. > self registeredClasses size = 1 ifTrue: > [^ default := self registeredClasses anyOne]. > default := UIManager default > + chooseFrom: (self registeredClasses collect: [:ea | ea > nameForViewer]) > - chooseFrom: self registeredClasses > values: self registeredClasses > title: 'Which ', self appName, ' would you prefer?'. > default ifNil: [default := self registeredClasses first]. > ^default.! > >

Oct. 5, 2009

[Pharo-project] Fwd: [squeak-dev] The Trunk: Compiler-jcg.85.mcz

by StÃ©phane Ducasse

Begin forwarded message: > From: commits(a)source.squeak.org > Date: September 30, 2009 10:14:22 AM GMT+02:00 > To: squeak-dev(a)lists.squeakfoundation.org > Subject: [squeak-dev] The Trunk: Compiler-jcg.85.mcz > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > Joshua Gargus uploaded a new version of Compiler to project The Trunk: > http://source.squeak.org/trunk/Compiler-jcg.85.mcz > > ==================== Summary ==================== > > Name: Compiler-jcg.85 > Author: jcg > Time: 30 September 2009, 1:14:16 am > UUID: 21a5f88d-4107-48c3-b41c-d5ea735319a7 > Ancestors: Compiler-tfel.84 > > Revert to lazy-initialization of method properties, which is used by > the externally-maintained Prolog package (which loads cleanly into > 3.10.2, but not trunk). > > Part 1 of 2... need to first re-add the #properties method to Parser > before changing methods to send it. > > =============== Diff against Compiler-tfel.84 =============== > > Item was added: > + ----- Method: Parser>>properties (in category 'pragmas') ----- > + properties > + ^ properties ifNil: [ properties := AdditionalMethodState new ]! > >

Oct. 5, 2009

Re: [Pharo-project] Fix for 987 (Was:Re: issue 996: analogousCodeTo: )

by StÃ©phane Ducasse

Thanks we will integrate that as soon as we can breath :) On Oct 5, 2009, at 12:14 PM, Henrik Johansen wrote: > Updated Issue987 with a SLICE in Inbox, which "fixes" the DNU in the > way below. > Used printString instead of asString as proposed by HernÃ¡n, as it (in > principle) should be more robustly implemented and thus more suited > for debugger display. > (If sig's idea from some time back was adopted, this should be > debugString instead of printString, of course). > > Cheers, > Henry > > On Oct 5, 2009, at 11:51 23AM, Henrik Johansen wrote: > >> For the stack top error, a better solution than adding asText to >> Object would be to implement: >> ContextVariablesInspector >> contents >> ^super contents printString >> >> It's a subclass of StringHolder for some reason, which explain why it >> doesn't exactly like that the ContextVariable can be any arbitrary >> object... >> >> Cheers, >> Henry >> >> On Oct 5, 2009, at 11:17 33AM, HernÃ¡n Morales Durand wrote: >> >>> Hi Ramiro, >>> You don't need to modify a method to open a debugger, hitting Alt + >>> . will do it. The behavior you describe is present in Pharo-Core >>> #10466 too and is probably the same when clicking the "stack top" >>> item >>> in the Debugger right bottom pane (the context variables inspector). >>> I'm not fan at all of populating Object, but a quick workaround for >>> those who want to continue debugging without meta-debugging is to >>> define in Object >>> >>> asText >>> ^ self asString asText >>> >>> Cheers, >>> >>> HernÃ¡n >>> >>> 2009/10/5 Ramiro Diaz Trepat <ramiro(a)diaztrepat.name>: >>>> Sorry, and the way to reproduce was simply introducing a "self >>>> halt" in some >>>> method, or executing over a real bug as well, and trying to debug >>>> from >>>> there. >>>> Thanks again >>>> >>>> >>>> On Mon, Oct 5, 2009 at 8:47 AM, Ramiro Diaz Trepat <ramiro(a)diaztrepat.name >>>>> >>>> wrote: >>>>> >>>>> Hi Damien, thanks for answering. >>>>> The error happens on a the previous dev image (09.09.03) that was >>>>> updated >>>>> until yesterday night. >>>>> If I download the new dev image though, the error seems to go >>>>> away. >>>>> I thought there was no difference, in theory at least, between an >>>>> updated >>>>> image and a freshly downloaded one. >>>>> Cheers >>>>> >>>>> r. >>>>> >>>>> >>>>> On Mon, Oct 5, 2009 at 12:41 AM, Damien Cassou <damien.cassou(a)gmail.com >>>>>> >>>>> wrote: >>>>>> >>>>>> 2009/10/4 Ramiro Diaz Trepat <ramiro(a)diaztrepat.name>: >>>>>>> I saw previous posts from Steph saying that this fix had already >>>>>>> been >>>>>>> pushed, but I have an image updated up to now and it does >>>>>>> happen. >>>>>> >>>>>> Please provide a detailed process on how to reproduce. Telling us >>>>>> the >>>>>> image you used is of interest too. >>>>>> >>>>>> -- >>>>>> Damien Cassou >>>>>> http://damiencassou.seasidehosting.st >>>>>> >>>>>> "Lambdas are relegated to relative obscurity until Java makes >>>>>> them >>>>>> popular by not having them." James Iry >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 5, 2009

Re: [Pharo-project] Easy bug submission

by Andrey Larionov

Thanks. On Mon, Oct 5, 2009 at 14:55, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > See Debugger>>mailOutbugReport - I have no idea whether or not it actually works; it is available on the debugger's call-stack menu, at least in the standard toolset. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Andrey Larionov > Sent: Monday, October 05, 2009 3:30 AM > To: Pharo Development > Subject: [Pharo-project] Easy bug submission > > What about to add another button to error dialog? The button action "Report bug", which gather debug info and ask user to provide meaningful description of how to reproduce, and then posts this information (maybe possibly search for duplicates entries) as defect report in bugtracker. > > _______________________________________________ > 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 >

Oct. 5, 2009

Re: [Pharo-project] Easy bug submission

by Schwab,Wilhelm K

See Debugger>>mailOutbugReport - I have no idea whether or not it actually works; it is available on the debugger's call-stack menu, at least in the standard toolset. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Andrey Larionov Sent: Monday, October 05, 2009 3:30 AM To: Pharo Development Subject: [Pharo-project] Easy bug submission What about to add another button to error dialog? The button action "Report bug", which gather debug info and ask user to provide meaningful description of how to reproduce, and then posts this information (maybe possibly search for duplicates entries) as defect report in bugtracker. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 5, 2009

Re: [Pharo-project] issue 996: analogousCodeTo:

by Ramiro Diaz Trepat

Thanks HernÃ¡n and Henrik for your workarounds, but neither of them fixes the problem in my image.Here's a bit of my stack: VM: Mac OS - intel - 1058 - Squeak3.8.1 of '28 Aug 2006' [latest update: #6747] Squeak VM 4.2.1b1 Image: Pharo1.0beta [Latest update: #10466] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /Users/ramiro/Smalltalk/pharo Trusted Dir /foobar/tooBar/forSqueak/bogus Untrusted Dir /Users/ramiro/Library/Preferences/Squeak/Internet/My Squeak ByteSymbol(Object)>>doesNotUnderstand: #analogousCodeTo: Receiver: #visitComponent: Arguments and temporary variables: <<error during printing> Receiver's instance variables: #visitComponent: CompiledMethod>>= Receiver: a CompiledMethod(2377: WAPainterVisitor>>visitComponent:) Arguments and temporary variables: <<error during printing> Receiver's instance variables: a CompiledMethod(2377: WAPainterVisitor>>visitComponent:) Set>>scanFor: Receiver: a Set(a CompiledMethod(1962: BlockClosure>>newProcess) a CompiledMethod(2377: WAPainterVis...etc... Arguments and temporary variables: <<error during printing> Receiver's instance variables: tally: 9 array: #(nil nil nil nil nil a CompiledMethod(1962: BlockClosure>>newProcess) n...etc... Set>>findElementOrNil: Receiver: a Set(a CompiledMethod(1962: BlockClosure>>newProcess) a CompiledMethod(2377: WAPainterVis...etc... Arguments and temporary variables: <<error during printing> Receiver's instance variables: tally: 9 array: #(nil nil nil nil nil a CompiledMethod(1962: BlockClosure>>newProcess) n...etc... Set>>add: Receiver: a Set(a CompiledMethod(1962: BlockClosure>>newProcess) a CompiledMethod(2377: WAPainterVis...etc... Arguments and temporary variables: <<error during printing> Receiver's instance variables: tally: 9 array: #(nil nil nil nil nil a CompiledMethod(1962: BlockClosure>>newProcess) n...etc... [] in WeakIdentityKeyDictionary(Dictionary)>>keys Receiver: a WeakIdentityKeyDictionary(a CompiledMethod(1422: WAHtmlCanvas>>form:)->a DebuggerMethodM...etc... Arguments and temporary variables: <<error during printing> Receiver's instance variables: tally: 16 array: an Array(nil nil a CompiledMethod(1962: BlockClosure>>newProcess)->a Deb...etc... [] in WeakIdentityKeyDictionary(WeakKeyDictionary)>>keysDo: Receiver: a WeakIdentityKeyDictionary(a CompiledMethod(1422: WAHtmlCanvas>>form:)->a DebuggerMethodM...etc... Arguments and temporary variables: <<error during printing> Receiver's instance variables: tally: 16 array: an Array(nil nil a CompiledMethod(1962: BlockClosure>>newProcess)->a Deb...etc... WeakIdentityKeyDictionary(Set)>>do: Receiver: a WeakIdentityKeyDictionary(a CompiledMethod(1422: WAHtmlCanvas>>form:)->a DebuggerMethodM...etc... Arguments and temporary variables: <<error during printing> Receiver's instance variables: tally: 16 array: an Array(nil nil a CompiledMethod(1962: BlockClosure>>newProcess)->a Deb...etc... WeakIdentityKeyDictionary(Dictionary)>>associationsDo: Receiver: a WeakIdentityKeyDictionary(a CompiledMethod(1422: WAHtmlCanvas>>form:)->a DebuggerMethodM...etc... Arguments and temporary variables: <<error during printing> Receiver's instance variables: tally: 16 array: an Array(nil nil a CompiledMethod(1962: BlockClosure>>newProcess)->a Deb...etc... WeakIdentityKeyDictionary(WeakKeyDictionary)>>keysDo: Receiver: a WeakIdentityKeyDictionary(a CompiledMethod(1422: WAHtmlCanvas>>form:)->a DebuggerMethodM...etc... Arguments and temporary variables: <<error during printing> Receiver's instance variables: tally: 16 array: an Array(nil nil a CompiledMethod(1962: BlockClosure>>newProcess)->a Deb...etc... WeakIdentityKeyDictionary(Dictionary)>>keys Receiver: a WeakIdentityKeyDictionary(a CompiledMethod(1422: WAHtmlCanvas>>form:)->a DebuggerMethodM...etc... Arguments and temporary variables: <<error during printing> Receiver's instance variables: tally: 16 array: an Array(nil nil a CompiledMethod(1962: BlockClosure>>newProcess)->a Deb...etc... DebuggerMethodMap class>>cacheDebugMap:forMethod: Receiver: DebuggerMethodMap Arguments and temporary variables: <<error during printing> Receiver's instance variables: superclass: Object methodDict: a MethodDictionary(#abstractSourceMap->a CompiledMethod(1655: Debug...etc... format: 140 instanceVariables: #('timestamp' 'methodReference' 'methodNode' 'abstractSource...etc... organization: ('accessing' markRecentlyUsed method namedTempAt:in: namedTempAt:...etc... subclasses: {DebuggerMethodMapForBlueBookMethods . DebuggerMethodMapForClosureC...etc... name: #DebuggerMethodMap classPool: a Dictionary(#MapCache->a WeakIdentityKeyDictionary(a CompiledMethod...etc... sharedPools: nil environment: Smalltalk category: #'Tools-Debugger' traitComposition: nil localSelectors: nil [] in DebuggerMethodMap class>>forMethod: Receiver: DebuggerMethodMap Arguments and temporary variables: <<error during printing> Receiver's instance variables: superclass: Object methodDict: a MethodDictionary(#abstractSourceMap->a CompiledMethod(1655: Debug...etc... format: 140 instanceVariables: #('timestamp' 'methodReference' 'methodNode' 'abstractSource...etc... organization: ('accessing' markRecentlyUsed method namedTempAt:in: namedTempAt:...etc... subclasses: {DebuggerMethodMapForBlueBookMethods . DebuggerMethodMapForClosureC...etc... name: #DebuggerMethodMap classPool: a Dictionary(#MapCache->a WeakIdentityKeyDictionary(a CompiledMethod...etc... sharedPools: nil environment: Smalltalk category: #'Tools-Debugger' traitComposition: nil localSelectors: nil WeakIdentityKeyDictionary(Dictionary)>>at:ifAbsent: Receiver: a WeakIdentityKeyDictionary(a CompiledMethod(1422: WAHtmlCanvas>>form:)->a DebuggerMethodM...etc... Arguments and temporary variables: <<error during printing> Receiver's instance variables: tally: 16 array: an Array(nil nil a CompiledMethod(1962: BlockClosure>>newProcess)->a Deb...etc... DebuggerMethodMap class>>forMethod: Receiver: DebuggerMethodMap Arguments and temporary variables: <<error during printing> Receiver's instance variables: superclass: Object methodDict: a MethodDictionary(#abstractSourceMap->a CompiledMethod(1655: Debug...etc... format: 140 instanceVariables: #('timestamp' 'methodReference' 'methodNode' 'abstractSource...etc... organization: ('accessing' markRecentlyUsed method namedTempAt:in: namedTempAt:...etc... subclasses: {DebuggerMethodMapForBlueBookMethods . DebuggerMethodMapForClosureC...etc... name: #DebuggerMethodMap classPool: a Dictionary(#MapCache->a WeakIdentityKeyDictionary(a CompiledMethod...etc... sharedPools: nil environment: Smalltalk category: #'Tools-Debugger' traitComposition: nil localSelectors: nil CompiledMethod>>debuggerMap Receiver: a CompiledMethod(2048: TWebComponent>>updateRoot:) Arguments and temporary variables: <<error during printing> Receiver's instance variables: a CompiledMethod(2048: TWebComponent>>updateRoot:) MethodContext(InstructionStream)>>debuggerMap Receiver: TLoginComponent(TWebComponent)>>updateRoot: Arguments and temporary variables: <<error during printing> Receiver's instance variables: sender: WAUpdateRootVisitor>>visitPainter: pc: 52 stackp: 1 method: a CompiledMethod(2048: TWebComponent>>updateRoot:) closureOrNil: nil receiver: a TLoginComponent Debugger>>selectedMessage Receiver: a Debugger Arguments and temporary variables: <<error during printing> Receiver's instance variables: dependents: a DependentsArray(a SystemWindow(1276) a PluggableListMorph(255) a ...etc... contents: nil currentCompiledMethod: nil contentsSymbol: #source interruptedProcess: a Process in Debugger class>>openOn:context:label:contents:...etc... interruptedController: nil contextStack: an OrderedCollection(TLoginComponent(Object)>>halt TLoginComponen...etc... contextStackTop: TLoginComponent(Object)>>halt contextStackIndex: 2 contextStackList: an OrderedCollection('TLoginComponent(Object)>>halt' 'TLoginC...etc... receiverInspector: an Inspector contextVariablesInspector: a ContextVariablesInspector externalInterrupt: false proceedValue: nil selectingPC: true debuggerMap: nil savedCursor: ((CursorWithMask extent: 16@16 depth: 1 fromArray: #( 2r0 2...etc... isolationHead: nil failedProject: nil errorWasInUIProcess: false labelString: nil

Oct. 5, 2009

Re: [Pharo-project] Splitting MorphicExtras

by StÃ©phane Ducasse

Yes we will have a cut Morphic into parts. This is on our todo with Jannik tools. On Oct 4, 2009, at 10:49 PM, Nicolas Cellier wrote: > Then it seems both trunk and Pharo don't have the same boundaries. > SketchEditorMorph is in trunk/MorphicExtras and Pharo/Morphic > > Nicolas > > 2009/10/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Thanks. >> BTW we already split morphicExtras and remove a lot of stuff. >> So is not the case? >> >> Stef >> >> On Oct 4, 2009, at 9:53 PM, Nicolas Cellier wrote: >> >>> source.squeak.org/trunk did it, it would be welcome to follow, >>> because >>> publishing Morphic is a bit loooongish. >>> >>> Nicolas >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 5, 2009