July 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.2] #12028
by StÃ©phane Ducasse July 2, 2010

July 2, 2010

12028 ----- - Issue 2615: Use overflow rows for ToolBuilder button panels. Thanks Gary! - Issue 2616: Use overflow rows for Debugger custom buttons. Thanks Gary! - Issue 2624: Much faster Dictionary>>unreferencedKeys. Thanks Eliot

2 1

Re: [Pharo-project] [Esug-list] [vwnc] ESUG 2010 registration dead-line is approaching!
by Serge Stinckwich July 2, 2010

July 2, 2010

Hi Joaquim, There is no information on the FB event that is not on the ESUG website. This is just a convenient way to do some some buzz. Thank you. Le 2 juil. 2010 Ã 17:49, "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de> a Ã©crit : > Just a side note: > >> http://www.esug.org/Conferences/2010 > > If I visit the conference page, there is a link to Conference news on Facebook > This is only accessible for registered Facebook users. > I think it's not a good idea to be a closed circle. > > Joachim > > > > Noury Bouraqadi <bouraqadi(a)gmail.com> hat am 2. Juli 2010 um 00:32 geschrieben > >> Dear Smalltalkers, >> >> The dead-line for registration at early bird fees is approaching (one month to >> go). >> So, hurry up and register on our new seaside-based server. >> http://registration.esug.org/ >> This server comes with new features. >> You can now do a group registration and make a single payment. >> Also, we have reduction tickets (typically for Golden and Platinum sponsors). >> >> The ESUG 2010 conference program is about to be ready, and it is as promising >> as was for the previous editions of the conference. >> Checkout the preliminary schedule is already on the web, >> http://www.esug.org/Conferences/2010 >> >> See you in Barcelona, >> Noury >> ESUG treasurer >> >> >> _______________________________________________ >> vwnc mailing list >> vwnc(a)cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > -- > ------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

1 0

[Pharo-project] [ANN 1.1] pre-built 1.1 Core RC4
by Marcus Denker July 2, 2010

July 2, 2010

https://gforge.inria.fr/frs/download.php/27242/PharoCore-1.1-11409-rc4.zip

1 0

[Pharo-project] [update 1.1] #11409
by Marcus Denker July 2, 2010

July 2, 2010

(it is getting *far* too hot here...) 11409 ----- RC4

1 0

[Pharo-project] Fixed Nile for Pharo 1.1 [WAS] Re: Found senders of #isSystemDefined in Nile
by Mariano Martinez Peck July 2, 2010

July 2, 2010

Ok....I finally take an hour and fix all the Nile tests in Pharo 1.1. They are now all green. While doing this, I have removed all (or all I saw) from uniClasses in Nile. It would be very cool if someone from Nile can check my latests commits in the repository. If you want to load it: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfNile'; load. and then (ConfigurationOfNile project version: '1.1') load: 'Core Tests' Cheers Mariano On Sat, May 22, 2010 at 6:37 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Yes we should just update Nile > This is a clear example of the fact that since we do not record refactoring > external packages can easily degrade > > > > On May 22, 2010, at 6:26 PM, Alexandre Bergel wrote: > > > I have the feeling that all these uniClasses are stone age. All traces > should be removed. > > > > Cheers, > > Alexandre > > > > > > On 22 May 2010, at 13:19, Mariano Abel Coca wrote: > > > >> Hi, > >> > >> I've found a few senders of #isSystemDefined when trying to run the > pharo dev test suite, and I don't know what is the expected behavior. > >> > >> I've read in: > http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg12075.ht… the idea is to remove the message and all it's senders, but I don't > know why is used here in Nile. > >> > >> The senders are in NSSmartRefStream, inside of #uniClassInstVarsRefs:, > #uniClasesDo: and #beginInstance:size: > >> > >> Any hint on this will be appreciated. > >> > >> Cheers, > >> > >> Mariano. > >> _______________________________________________ > >> 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 >

1 0

Re: [Pharo-project] [squeak-dev] BlockClosure asContext losing bound variable?
by Eliot Miranda July 2, 2010

July 2, 2010

Hi Rob, Hi All, On Sun, Jun 27, 2010 at 3:34 PM, Rob Withers <reefedjib(a)yahoo.com> wrote: > I am getting a walkback on this code, with a valid vat: > > EventualProcess class>>#newOnVat: vat > ^ super new > suspendedContext: [ > vat processSends. > Processor terminateActive] asContext; > priority: Processor userSchedulingPriority; > eventualName: 'vat thread'; > vat: vat; > yourself > > once it has been resumed. The exception is > UndefinedObject(Object)>>doesNotUnderstand: #processSends. Somehow the vat > variable inside the Closure/MethodContext has become nil. Anyone know > about this stuff? > This is due to a bad bug i the closure support for BlockClosure>>asContext, which was forgetting to push any copied values (in the above case the argument vat) onto the stack of the new context so that when the process resumed the initial pushTemp0 that should push the copied value of vat in fact pushed (at least in the Cog VM) 4 bytes from the middle of the method, and hence bang! The fixes are in Kernel-eem.468 and Kernel-eem.469. Its probably best to load Kernel-eem.468 and then Kernel-eem.469 rather than just Kernel-eem.469 because the system will crash if the fixes come i in the wrong order. Kernel-eem.468 also fixes restart in blocks in the debugger (its the same issue; forgetting to initialize the context with any arguments and copied values; local temps get initialized by explicit pushNil bytecodes). thanks for the test case Rob! best Eliot P.S. Here are the methods: > Many thanks, > Rob > >

2 1

[Pharo-project] [update 1.1] #11408
by Marcus Denker July 2, 2010

July 2, 2010

11408 ----- Issue 2598: Trait composition with exclusion lost when loading package from MC

1 0

[Pharo-project] How-to load O2 on 1.1?
by Geert Claes July 2, 2010

July 2, 2010

How do I load O2 in the 1.1 RC3? -- View this message in context: http://forum.world.st/How-to-load-O2-on-1-1-tp2276308p2276308.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

1 0

[Pharo-project] [update 1.2] #12027
by Marcus Denker July 2, 2010

July 2, 2010

12027 ----- Issue 2612: DateAndTime current asUnixTime walkback in 1.1 rc3 Issue 2588: Dictionary>>do: Issue 2598: Trait composition with exclusion lost when loading package from MC

1 0

[Pharo-project] Bug in 1.1 RC2? Trait composition lost when loading a MC package
by Simon Denier July 2, 2010

July 2, 2010

When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image. It seems closely related to previous issues 2477 and 2148 But I am not sure if this is the same bug reappearing or a variant. To reproduce: Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; package: 'Moose-Tests-Algos-Graph'; load Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes. After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes: MOGraphNode subclass: #MABfsNode uses: MATEdgeNode - {#previousEdges. #from:edge:} instanceVariableNames: 'nextEdges firstDepth' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph' MODisjointSetNode subclass: #MANextNode uses: MATNodeNode - {#from:. #previousNodes} instanceVariableNames: 'nextNodes' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph' The problem has been reproduced in 11383 and 11400 RC2. -- Simon

5 11