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

[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

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

by Mariano Martinez Peck

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. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > 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 Damien Pollet

I just found that besides DejaVu, the Droid Fonts designed for Google Android are available under an apache licence: http://www.droidfonts.com/ On Wed, Feb 25, 2009 at 15:27, Damien Pollet <damien.pollet(a)gmail.com> wrote: > On Tue, Feb 24, 2009 at 19:54, JÃ©rÃ´me <jerome(a)minusfreun.de> wrote: >> Â Â Â Â * It is a Unicode font, with an already remarkable range of Unicode >> characters that will be extened over time by the SIL people, while >> Vera is limited mainly to the characters in the Basic Latin and >> Latin-1 Supplement portions of Unicode > > That's why you should all forget about vera and look at dejavu > instead, since it's the open-source, unicode-complete version of vera. > >> Â Â Â Â * The visual identity of Vera is worn out by its use in other >> projects like GNOME â as Times New Roman's has been worn out to the >> overuse in Word > > Granted, but there are few opensource fonts that have this much > coverage in this many styles (bold, italic, monospacedâ¦). Andika only > has the roman style ATM, though in your screenshots it looks like > pharo can fake other styles quite nicely. > Also, I'm not convinced we need a mono font for code, the only real > constraint is that the non-alphanumeric characters are clearly > legible. > >> Â Â Â Â * Pharo is new and its visual identity undefined, it therefor can >> profit from use of a font with a more fresh design > > Sure, but I'd make sure the UI is fast and usable too. Now maybe it's > best to go for the looks first and the usability second, that's what > apple did with OS X after all. > >> >> JÃ©rÃ´me >> >> Am 24.02.2009 um 18:56 schrieb Adrian Lienhard: >> >>> I looked at Andika with Marcus yesterday, and we both had the >>> impression that Bitstream Vera fits better. Is there any advantage to >>> the Andika font? Andika does not seem to provide a monotype too. >>> >>> Adrian >>> >>> >>> On Feb 24, 2009, at 18:25 , Igor Stasenko wrote: >>> >>>> 2009/2/24 Jerome <jerome(a)minusfreun.de>: >>>>> It seems Andika has a higher line-spacing because it takes >>>>> characters >>>>> with multiple stacked unicode diacritics[2] into account which would >>>>> be clipped otherwise[1]. If this is deemed not aceptable, there >>>>> exists >>>>> the SIL Type Tuner, which can change the line-height easily. [3] >>>>> Unfortunatly I have no windows system. >>>>> >>>> here the .xml config produced by running: >>>> TypeTuner.exe -x and.xml AndBasR.ttf >>>> >>>> So, there is >>>> <feature name="Line spacing" value="Normal"> >>>> and possible values >>>> Â Â Â Â Â Â Â <value name="Normal"/> >>>> Â Â Â Â Â Â Â <value name="Tight"/> >>>> Â Â Â Â Â Â Â <value name="Loose"/> >>>> Â Â Â Â Â Â Â <value name="Imported"/> >>>> >>>> i can try to rebuild font using 'Tight' line spacing. >>>> But i don't want to install this font on my windoze box. Is >>>> squeak/freetype allows to load a truetype font from directory where >>>> vm >>>> located? >>>> >>>> >>>>> [1] http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=Andika_FAQ… >>>>> [2] http://en.wikipedia.org/wiki/Diacritic >>>>> [3] http://scripts.sil.org/TypeTuner >>>>> >>>>> Am 24.02.2009 um 16:55 schrieb Igor Stasenko: >>>>> >>>>>> 2009/2/24 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>>>>> That's just down to the fact that textstyles are applied on >>>>>>> opening >>>>>>> of >>>>>>> browsers/morphs. >>>>>>> Reopening the browsers should sort it. >>>>>>> >>>>>>> The slight other concern I have with this font is the apparently >>>>>>> excessive >>>>>>> line spacing, not as compact as, say, Arial. >>>>>>> >>>>>> >>>>>> Does anyone knows, how/where line height is calculated? >>>>>> Maybe this code does not takes font DPI in account, or assuming a >>>>>> fixed dpi which is mismatching with screen dpi. >>>>>> >>>>>> >>>>>> >>>>>>> Regards, Gary >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Hilaire Fernandes" <hilaire(a)ofset.org> >>>>>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>>>>> Sent: Monday, February 23, 2009 7:20 PM >>>>>>> Subject: Re: [Pharo-project] Font for Pharo >>>>>>> >>>>>>> >>>>>>> Can it be related to a problem I saw recently with text string >>>>>>> inappropriately clipped toward the end (string length calculus >>>>>>> seems >>>>>>> too short of 1 or 2 pixels)? >>>>>>> I can see it in last release when using deja vue font for example. >>>>>>> >>>>>>> It does not show up in #194 however. >>>>>>> >>>>>>> Hilaire >>>>>>> >>>>>>> >>>>>>> 2009/2/23 Norbert Hartl <norbert(a)hartl.name>: >>>>>>>> On Mon, 2009-02-23 at 20:18 +0200, Igor Stasenko wrote: >>>>>>>>> 2009/2/23 Norbert Hartl <norbert(a)hartl.name>: >>>>>>>>>> On linux it doesn't look very good. There is something weird >>>>>>>>>> with the font height and position. Well, it looks a lot better >>>>>>>>>> in pharo than in gnome :) >>>>>>>>>> >>>>>>>>> seems like you changed font after opening a browser window. And >>>>>>>>> it >>>>>>>>> using old font height to calculate line heights. >>>>>>>>> >>>>>>>> If I would have changed the font after opening the window I >>>>>>>> couldn't >>>>>>>> see the new font. The fonts are only applied on opening a window. >>>>>>>> You can see it in the workspace and the menu two. There is enough >>>>>>>> space through the big line height. In the class browser it is >>>>>>>> somehow >>>>>>>> cut off. >>>>>>>> >>>>>>>> Norbert >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> screenshot is attached. >>>>>>>>>> >>>>>>>>>> Norbert >>>>>>>>>> >>>>>>>>>> On Mon, 2009-02-23 at 13:33 +0100, JÃ©rÃ´me wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I found the Font "Andika Basic"[2] which is an Open Source and >>>>>>>>>>> Free- >>>>>>>>>>> Software[1] Unicode-ready font made by the same people who >>>>>>>>>>> brought us >>>>>>>>>>> Gentium, the typeface for the nations. I suggest using Andika >>>>>>>>>>> as the >>>>>>>>>>> Pharo CI Font since it can be distributed along with Pharo and >>>>>>>>>>> looks a >>>>>>>>>>> little bit like Lucida Grande, the Mac-UI-font, but at the >>>>>>>>>>> same >>>>>>>>>>> time >>>>>>>>>>> is more friendly and better readable[3]. According to the >>>>>>>>>>> Andika >>>>>>>>>>> Website, Andika is Swahili, which is spoken widely in >>>>>>>>>>> southeastern >>>>>>>>>>> regions of the African continent, and means "Write!". >>>>>>>>>>> >>>>>>>>>>> Have a look: >>>>>>>>>>> [2] >>>>>>>>>>> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=Andika >>>>>>>>>>> [3] http://minusfreun.de/blog/uploads/Pharo.png >>>>>>>>>>> >>>>>>>>>>> JÃ©rÃ´me >>>>>>>>>>> >>>>>>>>>>> [1] http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>>>>> project >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> http://blog.ofset.org/hilaire >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>> >>>>> JÃ©rÃ´me Agater >>>>> j.agater(a)uni-oldenburg.de >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> <and.xml>_______________________________________________ >>>> 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 >>> >> >> JÃ©rÃ´me Agater >> j.agater(a)uni-oldenburg.de >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

April 3, 2009

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

by Adrian Lienhard

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). 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? 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

April 3, 2009

[Pharo-project] Undefined symbol using Exupery VM

by Damien Cassou

While using Monticello : ioFindExternalFunctionIn(primitiveResolverHostNameSize, 0x89bc1b0): /usr/local/lib/squeak/exupery-0.15/SocketPlugin/.libs/SocketPlugin: undefined symbol: primitiveResolverHostNameSize -- Damien Cassou http://damiencassou.seasidehosting.st

April 3, 2009