- Pharo-dev - lists.pharo.org

Re: [Pharo-project] old debugger bugs and the Closure changes

by StÃ©phane Ducasse

I will send you the code of the closure that we got. Stef On Apr 5, 2009, at 2:08 AM, Dale Henrichs wrote: > StÃ©phane, > > What image did the changes come from? Presumably there are also > changes that have been made to the pharo image that are not > compatible with the new code ... > > I've 'fixed' the obvious problems in the changes that were in the > install changeSet, but that didn't fix the 'step into' problem... > > In order to straighten things out, it may be necessary to review > code on both sides.. > > Dale > ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > > | ok probably because we could not check all the code unfortunately. > | So changes between 3.9 and pharo may have been supplanted by the > | closure changes. > | > | On Apr 4, 2009, at 6:39 PM, Dale Henrichs wrote: > | > | > I've started taking a look at the problem reported by Michael > | Roberts. > | > > | > I got slightly different misbehavior using the 10259- > | > ClosureBootstrap download on linux than reported by Michael, but > in > | > | > checking things out I discovered that the code in the Debugger for > | > | > the *Core* downloads is different from the *dev* downloads. > | > > | > For example the source for Debugger>>selectedMessageName in the > | > *Core* image (10259-ClosureBootstrap) is: > | > selectedMessageName > | > "Answer the message selector of the currently selected context. > | > If the method is unbound we can still usefully answer its old > | > selector." > | > > | > | selector | > | > selector := self selectedContext methodSelector. > | > ^(selector ~~ self selectedContext method selector > | > and: [selector beginsWith: 'DoIt']) > | > ifTrue: [self selectedContext method selector] > | > ifFalse: [selector] > | > > | > and I get a DNU for #methodSelector. On the other hand in the > *dev* > | > | > image (pharo0.1-10259dev09.03.3) the source is: > | > selectedMessageName > | > "Answer the message selector of the currently selected context." > | > > | > ^self selectedContext selector > | > > | > When I looked at the Pharo0.1Core-10259 image, the source is > | > identical to the pharo0.1-10259dev09.03.3, so the Closure > changeset > | > | > is apparently introducing some 'unwanted' changes to the Debugger > | > (and perhaps elsewhere?). > | > > | > Dale > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > Pharo-project(a)lists.gforge.inria.fr > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > project > | > >

April 5, 2009

Re: [Pharo-project] old debugger bugs and the Closure changes

by Dale Henrichs

StÃ©phane, What image did the changes come from? Presumably there are also changes that have been made to the pharo image that are not compatible with the new code ... I've 'fixed' the obvious problems in the changes that were in the install changeSet, but that didn't fix the 'step into' problem... In order to straighten things out, it may be necessary to review code on both sides.. Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | ok probably because we could not check all the code unfortunately. | So changes between 3.9 and pharo may have been supplanted by the | closure changes. | | On Apr 4, 2009, at 6:39 PM, Dale Henrichs wrote: | | > I've started taking a look at the problem reported by Michael | Roberts. | > | > I got slightly different misbehavior using the 10259- | > ClosureBootstrap download on linux than reported by Michael, but in | | > checking things out I discovered that the code in the Debugger for | | > the *Core* downloads is different from the *dev* downloads. | > | > For example the source for Debugger>>selectedMessageName in the | > *Core* image (10259-ClosureBootstrap) is: | > selectedMessageName | > "Answer the message selector of the currently selected context. | > If the method is unbound we can still usefully answer its old | > selector." | > | > | selector | | > selector := self selectedContext methodSelector. | > ^(selector ~~ self selectedContext method selector | > and: [selector beginsWith: 'DoIt']) | > ifTrue: [self selectedContext method selector] | > ifFalse: [selector] | > | > and I get a DNU for #methodSelector. On the other hand in the *dev* | | > image (pharo0.1-10259dev09.03.3) the source is: | > selectedMessageName | > "Answer the message selector of the currently selected context." | > | > ^self selectedContext selector | > | > When I looked at the Pharo0.1Core-10259 image, the source is | > identical to the pharo0.1-10259dev09.03.3, so the Closure changeset | | > is apparently introducing some 'unwanted' changes to the Debugger | > (and perhaps elsewhere?). | > | > Dale | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project(a)lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | >

April 5, 2009

Re: [Pharo-project] old debugger bugs and the Closure changes

by Michael Roberts

I started a small diagnosis on the issue tracker. Some of the changes are intentional. The closure image introduces a layer of indirection to get out the offsets for highlighting code. I think the next place to check is the compiler/ method changes since I think that's where they come from but I need to check. Mike On 4/4/09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > ok probably because we could not check all the code unfortunately. > So changes between 3.9 and pharo may have been supplanted by the > closure changes. > > On Apr 4, 2009, at 6:39 PM, Dale Henrichs wrote: > >> I've started taking a look at the problem reported by Michael Roberts. >> >> I got slightly different misbehavior using the 10259- >> ClosureBootstrap download on linux than reported by Michael, but in >> checking things out I discovered that the code in the Debugger for >> the *Core* downloads is different from the *dev* downloads. >> >> For example the source for Debugger>>selectedMessageName in the >> *Core* image (10259-ClosureBootstrap) is: >> selectedMessageName >> "Answer the message selector of the currently selected context. >> If the method is unbound we can still usefully answer its old >> selector." >> >> | selector | >> selector := self selectedContext methodSelector. >> ^(selector ~~ self selectedContext method selector >> and: [selector beginsWith: 'DoIt']) >> ifTrue: [self selectedContext method selector] >> ifFalse: [selector] >> >> and I get a DNU for #methodSelector. On the other hand in the *dev* >> image (pharo0.1-10259dev09.03.3) the source is: >> selectedMessageName >> "Answer the message selector of the currently selected context." >> >> ^self selectedContext selector >> >> When I looked at the Pharo0.1Core-10259 image, the source is >> identical to the pharo0.1-10259dev09.03.3, so the Closure changeset >> is apparently introducing some 'unwanted' changes to the Debugger >> (and perhaps elsewhere?). >> >> Dale >> >> _______________________________________________ >> 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 >

April 4, 2009

Re: [Pharo-project] old debugger bugs and the Closure changes

by StÃ©phane Ducasse

ok probably because we could not check all the code unfortunately. So changes between 3.9 and pharo may have been supplanted by the closure changes. On Apr 4, 2009, at 6:39 PM, Dale Henrichs wrote: > I've started taking a look at the problem reported by Michael Roberts. > > I got slightly different misbehavior using the 10259- > ClosureBootstrap download on linux than reported by Michael, but in > checking things out I discovered that the code in the Debugger for > the *Core* downloads is different from the *dev* downloads. > > For example the source for Debugger>>selectedMessageName in the > *Core* image (10259-ClosureBootstrap) is: > selectedMessageName > "Answer the message selector of the currently selected context. > If the method is unbound we can still usefully answer its old > selector." > > | selector | > selector := self selectedContext methodSelector. > ^(selector ~~ self selectedContext method selector > and: [selector beginsWith: 'DoIt']) > ifTrue: [self selectedContext method selector] > ifFalse: [selector] > > and I get a DNU for #methodSelector. On the other hand in the *dev* > image (pharo0.1-10259dev09.03.3) the source is: > selectedMessageName > "Answer the message selector of the currently selected context." > > ^self selectedContext selector > > When I looked at the Pharo0.1Core-10259 image, the source is > identical to the pharo0.1-10259dev09.03.3, so the Closure changeset > is apparently introducing some 'unwanted' changes to the Debugger > (and perhaps elsewhere?). > > Dale > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 4, 2009

[Pharo-project] old debugger bugs and the Closure changes

by Dale Henrichs

I've started taking a look at the problem reported by Michael Roberts. I got slightly different misbehavior using the 10259-ClosureBootstrap download on linux than reported by Michael, but in checking things out I discovered that the code in the Debugger for the *Core* downloads is different from the *dev* downloads. For example the source for Debugger>>selectedMessageName in the *Core* image (10259-ClosureBootstrap) is: selectedMessageName "Answer the message selector of the currently selected context. If the method is unbound we can still usefully answer its old selector." | selector | selector := self selectedContext methodSelector. ^(selector ~~ self selectedContext method selector and: [selector beginsWith: 'DoIt']) ifTrue: [self selectedContext method selector] ifFalse: [selector] and I get a DNU for #methodSelector. On the other hand in the *dev* image (pharo0.1-10259dev09.03.3) the source is: selectedMessageName "Answer the message selector of the currently selected context." ^self selectedContext selector When I looked at the Pharo0.1Core-10259 image, the source is identical to the pharo0.1-10259dev09.03.3, so the Closure changeset is apparently introducing some 'unwanted' changes to the Debugger (and perhaps elsewhere?). Dale

April 4, 2009

[Pharo-project] Added PackageInfo class>>existPackageNamed:

by Alexandre Bergel

Waiting in PharoInbox Name: PackageInfo-Alexandre_Bergel.19 Author: Alexandre.Bergel Time: 4 April 2009, 9:30:16 am UUID: cf56dd7d-c21b-4176-a2d6-874d4544a21a Ancestors: PackageInfo- stephane_ducasse.18 Issue #712 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 4, 2009

Re: [Pharo-project] SUnit History

by Alexandre Bergel

> 1. I noticed is that all the results are stored in a dictionary of > TestResult mapping the classes to their last result. When I delete > tests, these obsolete classes remain references from the dictionary > and thus never get garbage collected. Why not save the history in a > class-instance variable of the TestCase itself? That would even make > the code much simpler. Good point indeed. ISSUE 711. SUnit-Alexandre_Bergel.62.mcz in PharoInbox > 2. Why to store the history of test results in nested dictionaries, > sets and arrays? We have a nice TestResult object that remembers > exactly the same information and additionally allows to do all kinds > of queryies like #hasFailures, hasPassed, ... I see that there is one > problem here: the current implementation of TestResult remembers the > test case instances, and thus would reference potentially a lot of > unnecessary state. Maybe TestResult should only remember the method > references of the tests, instead of the test cases? I guess that would > solve other problems people regularly report with SUnit as well. We did this because an history does not contains the last run for the class. You could run all the tests for a class, subsequently run just one test. The history associated to this class should not contains the last run, but a combination of the both. Having a method TestResult>>merge: would help. I will work on that soon. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 4, 2009

Re: [Pharo-project] Undefined symbol using Exupery VM

by Bryce Kampjes

On Fri, 2009-04-03 at 19:22 -0100, Mariano Martinez Peck wrote: > > > On Fri, Apr 3, 2009 at 2:46 PM, Damien Cassou > <damien.cassou(a)gmail.com> wrote: > While using Monticello : > > ioFindExternalFunctionIn(primitiveResolverHostNameSize, > 0x89bc1b0): > /usr/local/lib/squeak/exupery-0.15/SocketPlugin/.libs/SocketPlugin: > undefined symbol: primitiveResolverHostNameSize > > The other day I had the same problem using exupery in ubuntu. I was > trying to download something from Monticello. I think It was FFI. I've added this to my list of known issues with the VM. It's odd that I haven't seen it myself as I do use Monticello and these have been my normal VMs for the last few years. Bryce

April 3, 2009

Re: [Pharo-project] [update] #10263

by StÃ©phane Ducasse

On Apr 3, 2009, at 6:39 PM, Adrian Lienhard wrote: > > On Apr 3, 2009, at 00:04 , StÃ©phane Ducasse wrote: > >> for the moment 10263 is the last update :) >> for the tests I imagine that they are normal. > > Hm, seems not normal... > > without closures (10263): 2929 run, 2909 passes, 2 expected failures, > 12 failures, 6 errors, 0 unexpected passes > with closures (10262cl): 2970 run, 2900 passes, 2 expected failures, > 17 failures, 51 errors, 0 unexpected passes > > Not sure though, if the 10262cl image I downloaded from GForge already > has the fixes in http://code.google.com/p/pharo/issues/detail?id=685 ? > (sorry, was a bit offline from Pharo the last week). No. None of them are in the release. > > > A couple of errors exist simply because BlockClosure is expected to > understand messages from BlockContext. Fixing the few obvious ones (I > atteched a cs to isse #685) brings me down to: > > 2970 run, 2923 passes, 2 expected failures, 20 failures, 25 errors, 0 > unexpected passes > > But still, not normal. > > A few couple other errors are from BlockContextTest. Shall this one be > removed or are these tests still valuable if we adapt them? > > Another question: did somebody check the methods that the closure > changeset modified for conflicts with fixes that we applied in Pharo? Somehow since this is difficult to know exactly. > > I mean, if the closures implementation touched one of these methods, > our changes/fixes would be gone. > > Cheers, > Adrian > >> >> but we need help to improve the tests and for example avoid to have >> test popping up menu. >> >> stef >> >> On Apr 2, 2009, at 11:42 PM, dmason(a)mason-rose.ca wrote: >> >>>> self inform: 'Updates after #10263 are for closure-enable Pharo. >>>> You >>>> need a 4.0 VM and continue updating from the #10262 closure image. >>>> Updating non-closure images will not work. Visit https://gforge.inria.fr/frs/?group_id=1299 >>>> for downloading the closure image'.! >>> >>> Sorry, I'm a come-lately to this. How to I get to (and past) 10263? >>> >>> I downloaded Pharo0.1Core-10262cl from INRIA, but on the 4.0 vm I >>> get 17 >>> failures and 51 errors with all-tests. >>> >>> ../Dave >>> >>> _______________________________________________ >>> 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 >

April 3, 2009

Re: [Pharo-project] Font for Pharo

by Hilaire Fernandes

In Mono type, DejaVu seems better to differenciate 0 and O; 1 and l. Hilaire 2009/4/3 Damien Pollet <damien.pollet(a)gmail.com> > I just found that besides DejaVu, the Droid Fonts designed for Google > Android are available under an apache licence: > > http://www.droidfonts.com/ > -- http://blog.ofset.org/hilaire

April 3, 2009