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

Re: [Pharo-project] Dev09.12.1 does not look nice on Linux

by Mariano Martinez Peck

It should be explained somewhere how to replace StrikeFonts for FreeType. Or even better, a preference for that maybe be cool. On Tue, Dec 8, 2009 at 5:14 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > Would be nice to expose the technique used in FreeType for > underline/strikeout... even if only stub where rendered by a StrikeFont. > > Would help a lot for other canvas types (PDF, PostScript etc.)... For > instance, a P{DF canvas would draw the underline using graphics > primitives... > > Regards, Gary > > ----- Original Message ----- > From: "Marcus Denker" <denker(a)acm.org> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, December 08, 2009 3:36 PM > Subject: Re: [Pharo-project] Dev09.12.1 does not look nice on Linux > > > > > > On Dec 8, 2009, at 4:27 PM, Hernan Wilkinson wrote: > > > >> but why the previous verson of pharo worked fine? there must be > >> something different in this new image... > >> > > > > It uses pre-rendered sub-pixel fonts instead of rendering the fonts via > > FreeType. > > (Much faster, not quite as nice in details). > > Freetype fonts are available if needed, though. The pre-rendered fonts > > just replace > > the 80ties=looking Squeak fonts and provide a good enough selection for a > > development image. > > > > Marcus > > > > > >> 2009/12/8 laurent laffont <laurent.laffont(a)gmail.com>: > >>> Hi, > >>> I had the same issue with exupery vm. Works with VM > Squeak-3.11.3.2135. > >>> See: http://n2.nabble.com/New-pharo-images-td4125021.html#a4125467 > >>> Laurent > >>> > >>> 2009/12/8 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > >>>> > >>>> Hi, > >>>> the last version's fonts look really bad. See attached files > >>>> I have Ubuntu 9.10, 64 bits. > >>>> Dev09.11.4 looks fine > >>>> Maybe is a preference setting? > >>>> Hernan > >>>> > >>>> _______________________________________________ > >>>> 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 >

Dec. 8, 2009

Re: [Pharo-project] MetacelloRepository is online

by Dale Henrichs

Dec. 8, 2009

Re: [Pharo-project] BUG: 'Error: Instances of UndefinedObject are not indexable' with Interpreter

by Henrik Johansen

Although I'm unable to reproduce it, it seems to me the possibility of a situation where this error could occur increases if text compositing takes too long. (notice how primitiveStoreImageSegment is ). Reasoning; - In TextMorph>> paragraph, an uninitialized paragraph is installed in the instvar, then line composition happens. - If this method is called from another thread than the UI thread, (say, as a response to an Event, which seems to be the case at least for OB) it might be interrupted by the UI process, which will happily go ahead and try to render the paragraph before it is initialized, then throw an error since lines is still nil. A fix for this problem (which would be to create the paragraph in a temp, then store in instvar only when fully intialized) is attached. If you would file it in and see if it helps, that'd be nice. If it does, feel free to commit a slice to the inbox :) Cheers, Henry On Dec 8, 2009, at 2:56 15PM, Mariano Martinez Peck wrote: > Hi folks! I having this problem in pharo1.0-10496-rc1dev09.11.4 but I cannot reproduce it in PharoCore-1.1-11078-ALPHA > I don't think it is because of the Pharo version but becuase of dev/core. I would like to tested in a dev from 11078 but the last one I tested was not working as I have warings and popups everywhere (there is already a thread for that). > > I am in Mac OS. > > Anyway, you can reproduce it in a fresh pharo1.0-10496-rc1dev09.11.4 image. > > Steps to reproduce: > > 1) Download from http://www.squeaksource.com/JBARepo the package VMMakerLoader > > 2) Evaluate "VMMakerLoader loadAndFix" > > 3) Browse the class Interpreter > > 4) Go to the method primitiveStoreImageSegment. Click on the method and after a second you will have this error. > > I attach PharoDebug.log in the issue tracker: http://code.google.com/p/pharo/issues/detail?id=1559 > > Cheers, > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 8, 2009

Re: [Pharo-project] Dev09.12.1 does not look nice on Linux

by Gary Chambers

Would be nice to expose the technique used in FreeType for underline/strikeout... even if only stub where rendered by a StrikeFont. Would help a lot for other canvas types (PDF, PostScript etc.)... For instance, a P{DF canvas would draw the underline using graphics primitives... Regards, Gary ----- Original Message ----- From: "Marcus Denker" <denker(a)acm.org> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, December 08, 2009 3:36 PM Subject: Re: [Pharo-project] Dev09.12.1 does not look nice on Linux > > On Dec 8, 2009, at 4:27 PM, Hernan Wilkinson wrote: > >> but why the previous verson of pharo worked fine? there must be >> something different in this new image... >> > > It uses pre-rendered sub-pixel fonts instead of rendering the fonts via > FreeType. > (Much faster, not quite as nice in details). > Freetype fonts are available if needed, though. The pre-rendered fonts > just replace > the 80ties=looking Squeak fonts and provide a good enough selection for a > development image. > > Marcus > > >> 2009/12/8 laurent laffont <laurent.laffont(a)gmail.com>: >>> Hi, >>> I had the same issue with exupery vm. Works with VM Squeak-3.11.3.2135. >>> See: http://n2.nabble.com/New-pharo-images-td4125021.html#a4125467 >>> Laurent >>> >>> 2009/12/8 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> >>>> >>>> Hi, >>>> the last version's fonts look really bad. See attached files >>>> I have Ubuntu 9.10, 64 bits. >>>> Dev09.11.4 looks fine >>>> Maybe is a preference setting? >>>> Hernan >>>> >>>> _______________________________________________ >>>> 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

Dec. 8, 2009

Re: [Pharo-project] New User Experience Suggestion for 1.0

by Reg Krock

This has to do with learning styles. There was an interesting discussion on the vw or squeak list a few weeks ago about this. One wants something to allow people to choose what fits their learning style in their initial contact. In addtion to Tim's susggestions, a series of videos could also be useful. Regards, Reg > Interesting analogy given Pharo's roots in something widely (and proudly) > considered a toy by its creators. However, a game is simply an > entertainment medium, and it either works for you or it does not. A > programming language hopefully gets a better look, and one with a free pdf > book including a walk-through should be worth a noob's time. > > That said, a workspace full of examples is fine with me. But I continue > to think that we should point people to PBE. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stephen > Taylor > Sent: Monday, December 07, 2009 10:48 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] New User Experience Suggestion for 1.0 > > Schwab,Wilhelm K wrote: >> The counter argument is that PBE is readily available and very well >> written. > > It is, but I think it's well worth considering what people think in their > first couple of seconds of exposure to a new product - especially > something like Smalltalk where people may well be looking at it only from > idle curiosity. > > When I think how quickly and arbitrarily I can reject a game that > someone's spent three years sweating blood over... > > > > > Steve > > _______________________________________________ > 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 >

Dec. 8, 2009

Re: [Pharo-project] Dealing with Preferences in external packages?

by Gary Chambers

I was thinking ahead to the point where there would be "shared" settings amongst disparate packages... would be nice to not introduce a superficail dependency. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, December 07, 2009 10:22 PM Subject: Re: [Pharo-project] Dealing with Preferences in external packages? You lost me gary :) On Dec 7, 2009, at 6:56 PM, Gary Chambers wrote: > "Shared" settings will introduce another kind of package dependency... > Perhaps > there is some benefit of all settings being local to a package but > cross-linked in some way such > that the compatible preferences all change value at the same time in the > settings browsers? > > There will always be some kind of compromise, one way or the other, but it > might work ;-) > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, December 07, 2009 1:50 PM > Subject: [Pharo-project] Dealing with Preferences in external packages? > > >> Now that setting is starting to get integrated (great) we will also face >> the problem >> of branching. >> For example, how do we manage that OB uses Preferences.... and that we >> don't. >> Any idea or process is welcome. >> >> Of course we can have a package full of override but this is the ultimate >> solution >> before complete fork. >> >> Stef >> _______________________________________________ >> 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

Dec. 8, 2009

Re: [Pharo-project] TheWorldMainDockingBar

by Gary Chambers

Indeed, sure I said before that it can go... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, December 08, 2009 2:39 PM Subject: Re: [Pharo-project] TheWorldMainDockingBar >+ 2 > We kept it because we thought gary used it but this is not the case. > > Stef > > On Dec 8, 2009, at 9:33 AM, Adrian Lienhard wrote: > >> +1 >> >> On Dec 8, 2009, at 09:17 , Marcus Denker wrote: >> >>> >>> On Dec 8, 2009, at 9:10 AM, alain.plantec(a)free.fr wrote: >>> >>>> Hi all, >>>> While migrating a preference for it I noticed that >>>> at least, it is not very well integrated in pharo... >>>> Before I open an issue (if none already opened) I would like to >>>> know what >>>> people think about it. >>>> Personally I would not be very sad to see it killed :) >>> >>> I would say kill it. >>> >>> Marcus >>> >>> _______________________________________________ >>> 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

Dec. 8, 2009

[Pharo-project] ClassTree new openOn: Collection :)

by StÃ©phane Ducasse

I started to understand MorphTreeMorph to build a class documentation browsing browser and I discovered that ClassTree new openOn: Collection ClassList new openOn: Collection This is really a good start. We could have it for package and displaying methods.... Stef

Dec. 8, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by Adrian Lienhard

On Dec 8, 2009, at 12:08 , Mariano Martinez Peck wrote: > On Fri, Dec 4, 2009 at 12:05 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > When you are creating your root of objects and you put symbols > inside, they > are not put in ourPointers but in ByteArray. > This is due to the fact that the only object who is pointing to that > symbol > is inside the segment ? To be precise, the symbols are also pointed to by the symbol table, but only by weak references. Since image segments use the GC mark logic, these pointers are not considered. > What you do with this piece of code: > > symbolHolder := Symbol allSymbols. > > is to hold those symbols there. So, when ImageSegment uses the GC > techniques > to detect which objects are ONLY pointed from inside of the segment, > the > symbols is not found (because it is accessible trough that test) and > thus, > it goes to outPointers instead of ByteArray. > > And of course, if it is in outPointers instead of ByteArray when the > segment > is loaded again, yo don't create a symbol again but use the same > object (the > one of the oop). > > I am correct? or I understood anything ? yes. Cheers, Adrian

Dec. 8, 2009

[Pharo-project] [update 1.1] #11081

by Marcus Denker

11081 ----- Issue 1527: Move *Freetype-override back to Graphics in CharacterScanner & co Issue 1560: ImageSegment: recategorize some methtods Issue 1556: FontTest testResetAfterEmphasis fails with StrikeFont

Dec. 8, 2009