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

[Pharo-project] Fwd: [INRIAGforge] 27-28 Jan 2009 : Scheduled dowtime

by StÃ©phane Ducasse

Begin forwarded message: > From: <noreply(a)gforge.inria.fr> > Date: January 26, 2009 6:30:19 PM CEST > To: stephane.ducasse(a)inria.fr > Subject: [INRIAGforge] 27-28 Jan 2009 : Scheduled dowtime > > On January 27th 2009, from 7h00pm to 8h00pm and January 28th > 2009,from 6h00am to 8h00am, the site and all associated services > will be unavailable due to maintenance operations on servers and > networks by Renater. > A reply to this announce will signal the end of the maintenance. > We apologize for any inconvenience. > Cordially > The InriaGforge Team >

Jan. 26, 2009

[Pharo-project] Fwd: Process stuck in 10156+OB?

by StÃ©phane Ducasse

Begin forwarded message: > From: John M McIntosh <johnmci(a)smalltalkconsulting.com> > Date: January 26, 2009 7:30:23 PM CEST > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] Process stuck in 10156+OB? > Reply-To: johnmci(a)smalltalkconsulting.com > > Ok, I think the test is attached, however you should change the name > from JMMTest to something else. > > like MacHostMenusTestCaseCharacterSubstitutions > > > On 20-Nov-08, at 1:27 PM, StÃ©phane Ducasse wrote: > > >> john do you have a new version of the package since >> the method calculateShouldBeFrom:using: is missing >> >> On Nov 20, 2008, at 12:03 AM, John M McIntosh wrote: >> >>> testCharacterChanging >>> | testString item shouldBe resultingString where | >>> #(';' '^' '!' '<' '/' '(' ) >>> do: [:c | #('*' '* ' '* ' '**' '** ' '** ' >>> ')' '*)' '* )' '* )' '**)' '** )' '** )' >>> ')' '*)' '*X)' '*XX)' '**)' '**X)' '**XX)' >>> '))' '*))' '*X))' '*XX))' '**))' '**X))' '**XX))' >>> '(' '*(' '*X(' '*XX(' '**)' '**X(' '**XX(' >>> '((' '*((' '*X((' '*XX((' '**((' '**X((' '**XX((' >>> ) >>> do: [:template | >>> testString := template copyReplaceAll: '*' with: c. >>> testString >>> permutationsDo: [:mixedUp | >>> item := mixedUp copy. >>> shouldBe := self calculateShouldBeFrom: item using: c. >>> resultingString := self modifySqueakMenu: item copy. >>> self should: [shouldBe = resultingString]. >>> (where := resultingString indexOf: $/) > 0 >>> ifTrue: [self should: [(mixedUp at: where) = $(]. >>> self should: [(mixedUp at: where+2) = $)]. >>> self should: [(mixedUp at: where+1) asUppercase = >>> (resultingString at: where+1)]]]]] >> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > >

Jan. 26, 2009

[Pharo-project] Issue 465 - Pharo dev

by Francois Stephany

Hi, Small bug found in Pharo-dev in OTToolset class. See issue 465. Cheers, Francois [Thanks to David]

Jan. 26, 2009

Re: [Pharo-project] Writing a conditions for breakpoint

by Mariano Martinez Peck

Igor: Sorry not beeing able to help you. I am still learning squeak. However, I would really like conditional breakpoints. I found them very useful in Eclipse IDE. Let me know if you could get them working. Cheers, Mariano On Fri, Jan 23, 2009 at 3:57 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > suppose, you have a method, say > foo: bar baz: zork > and want to set a conditional breakpoint for it.. > a most easy way to provide a condition is to ask user for providing a > block like: > > [:receiver :arguments :context | " .... return true to break " ] > > but more convenient would be to ask user to write a condition as a method: > > foo: bar baz: zork > "put your condition code here" > ^ bar == 0 "break if bar is zero" > > then user naturally would access interesting things w/o need to deal > with block-like constructs, where arguments is accessible but in > inconvenient manner > i.e. type 'bar' instead of 'arguments at: 1' > > This is very good, except one thing, which i worry about: > what if i want to write a condition which needs to test a specific > context state. > I can freely pass a context in a block, but can't pass it in method , > because 'condition' method selector should be same as selector where > breakpoint will be installed to. > > What you think would be better? Or maybe i should let users decide , > what is best for them? So, they can write conditions using both forms > - as a block closure or as method? > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 26, 2009

Re: [Pharo-project] Plugin organization

by Michael Rueger

bryce(a)kampjes.demon.co.uk wrote: > Why not just add the plugin's to the VMMaker package? > > I don't see any gain for having another official plugin package besides > VMMaker. It'll have the main problem and advantage of VMMaker of > central ownership. That's not what I suggested, just a naming scheme. I also don't think that all plugins will be centrally maintained, as that would require write access of every plugin maintainer to the VM repository. Michael

Jan. 26, 2009

[Pharo-project] Added Class>>subclass: and Class>>subclass:instanceVariableNames:

by Alexandre Bergel

I always missed these two methods. Class has been extended with these two methods. A new version of Kernel has been saved in PharoInbox (version 253). Note that it has been merged with Kernel- adrian_lienhard.252 http://code.google.com/p/pharo/issues/detail?id=464 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 26, 2009

Re: [Pharo-project] Smalltalk condenseChanges broken?

by Adrian Lienhard

I can take a look into this (may not be today, though). Adrian On Jan 26, 2009, at 09:29 , Alexandre Bergel wrote: > Hi John, > > in a fresh 10204, I did a "Smalltalk condenseChanges". > I can browse the system normally it seems, but browsing TraitBehavior > rollbacks for some methods. > > Looking for implementors of > recompileNonResidentMethod:atSelector:from: and noteChangedSelectors: > will opens a debugger. > The problem, is that method source code got lost for some reason. For > example: > (TraitBehavior >> #noteChangedSelectors:) getSourceFromFile > ==> a Text for 'mp: ''stephane.ducasse 10/5/2008 13:05''' > > Which does not contains a method definition, which is incomplete. > > Cheers, > Alexandre > > On 26 Jan 2009, at 05:38, John M McIntosh wrote: > >> Well I'm fairly sure that I downloaded a Pharo0.1Core-10204.image >> then did a "Smalltalk condenseChanges" >> then an extended search for 'foobar' and walkback time, the changes >> file is messed up. >> >> at TraitBehavior class>>sourceCodeAt: where selector is >> noteChangedSelectors: >> >> However if someone can cross check for me, that would be helpful. >> >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> >> 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

Jan. 26, 2009

Re: [Pharo-project] a few obsolete classes?

by Adrian Lienhard

On Jan 26, 2009, at 05:10 , John M McIntosh wrote: > That sits in the special object's array in the array of compact > classes. I don' quite see where that array of compact classes is > updated. In Behavior>>#becomeCompact and #becomeUncompact. > I note rebuilding the special object's array just reuses the array of > compact classes it already had. Sending #becomeUncompact to AnObsoleteTranslatedMethod removes it from the compact classes array and finally makes it garbage. Adrian > On 24-Jan-09, at 12:33 AM, StÃ©phane Ducasse wrote: > >> AnObsoleteTranslatedMethod > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > 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

Jan. 26, 2009

Re: [Pharo-project] Smalltalk condenseChanges broken?

by Alexandre Bergel

Hi John, in a fresh 10204, I did a "Smalltalk condenseChanges". I can browse the system normally it seems, but browsing TraitBehavior rollbacks for some methods. Looking for implementors of recompileNonResidentMethod:atSelector:from: and noteChangedSelectors: will opens a debugger. The problem, is that method source code got lost for some reason. For example: (TraitBehavior >> #noteChangedSelectors:) getSourceFromFile ==> a Text for 'mp: ''stephane.ducasse 10/5/2008 13:05''' Which does not contains a method definition, which is incomplete. Cheers, Alexandre On 26 Jan 2009, at 05:38, John M McIntosh wrote: > Well I'm fairly sure that I downloaded a Pharo0.1Core-10204.image > then did a "Smalltalk condenseChanges" > then an extended search for 'foobar' and walkback time, the changes > file is messed up. > > at TraitBehavior class>>sourceCodeAt: where selector is > noteChangedSelectors: > > However if someone can cross check for me, that would be helpful. > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 26, 2009

[Pharo-project] Smalltalk condenseChanges broken?

by John M McIntosh

Well I'm fairly sure that I downloaded a Pharo0.1Core-10204.image then did a "Smalltalk condenseChanges" then an extended search for 'foobar' and walkback time, the changes file is messed up. at TraitBehavior class>>sourceCodeAt: where selector is noteChangedSelectors: However if someone can cross check for me, that would be helpful. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Jan. 26, 2009