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

[Pharo-project] [ANN] new pre-build 1.0rc1#10501

by Marcus Denker

http://gforge.inria.fr/frs/download.php/24991/PharoCore-1.0-10501rc1.zip

Dec. 9, 2009

[Pharo-project] [update] #10501

by Marcus Denker

10501 ----- Issue 1562: Font browser button "Update" does load fonts but font list is not updated Issue 1559: BUG: "Error: Instances of UndefinedObject are not indexable" with Interpreter Issue 1475: Cancelling from the Unknown Variable prompt, gives error Issue 1478: ScriptLoader loadFFI fails with a dependency error

Dec. 9, 2009

[Pharo-project] [update 1.1] #11082

by Marcus Denker

11082 ----- Issue 1562: Font browser button "Update" does load fonts but font list is not updated Issue 1559: BUG: "Error: Instances of UndefinedObject are not indexable" with Interpreter Issue 1475: Cancelling from the Unknown Variable prompt, gives error I will do an update for 1.0 with these now, too.... Marcus

Dec. 9, 2009

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

by Adrian Lienhard

I don't have the VMMaker code at hand right now (or rather, don't have time to look at it ;)), but I guess that after that piece of code you pasted below there is a loop from the first field (BaseHeader+4) to the last non-weak field (lastFieldOffset) in which the non-weak fields are traced. Note, that if an object both fixed and indexable weak fields the latter are always located after the former. You can see the memory layout and object formats on the pages 9 and 10 of the slides [1] (from a lecture about VMs I gave recently). Cheers, Adrian [1] http://www.adrian-lienhard.ch/presentations On Dec 8, 2009, at 22:57 , Mariano Martinez Peck wrote: > On Tue, Dec 8, 2009 at 10:54 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Tue, Dec 8, 2009 at 5:07 PM, Adrian Lienhard <adi(a)netstyle.ch> >> wrote: >> >>> >>> 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. >>> >> >> Ahhh ok. Now I see Symbol class >> rehash where it sets to >> SymbolTable >> := WeakSet >> >> Now...my finally question is, where in the code you can see the GC >> only >> mark "normal" objects and that week objects are not being taken into >> account. Do you know ? I tried to search it but I didn't find it. >> >> > Sorry, I forgot to said I found this in ObjectMemory >> markAndTrace: > > (self isWeakNonInt: oop) ifTrue: [ > "Set lastFieldOffset before the weak fields in the receiver" > lastFieldOffset := (self nonWeakFieldsOf: oop) << ShiftForWord. > "And remember as weak root" > weakRootCount := weakRootCount + 1. > weakRoots at: weakRootCount put: oop. > ] ifFalse: [ > "Do it the usual way" > lastFieldOffset := self lastPointerOf: oop. > ]. > > > But I don't know if this make sense or not. > > Thanks!! > > Mariano > > >>>> 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 >>> >>> _______________________________________________ >>> 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. 9, 2009

Re: [Pharo-project] DeprecationHistory

by HernÃ¡n Morales Durand

Hi Alain, It looks a pretty nice way to keep the developer informed, I like it. Cheers, HernÃ¡n 2009/12/8 Alain Plantec <alain.plantec(a)free.fr>: > Hi all, > One of my recents slice for preferences migration has made pharo nearly > unusable > because a lot of Â deprecation dialogs was opened for a single browser. > Then, the user had to forbid the deprecation warnings in order to avoid > these popups. > > Now, what about a non blocking window which is opened automatically when a > deprecated method is run, > but showing the list of recents deprecations ? > A double click on a list item, et hop!, Â a browser is opened on the > deprecated method. > I've tried it on the last pharo image and it seems ok. With it, it is still > always possible to let deprecation warning > without having to close any dialog window. > What do you think ? > > A screenshot is attached. > Cheers > Alain > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 9, 2009

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

by John M McIntosh

The chore of loading all 500 fonts on a macintosh, rendering them all to show what they look like, was *quite* expensive and added many 10's of seconds to Sophie startup time. At first we dumped the entire font menu oops tree into a image segment. The did a merge process by checking the current machine's view of the fonts, versus our historical view. usually fonts don't change much so the cost was only reading the directory. This worked oh, 99.99% of the time. The 0.01% was the hassle. Our fallback was then to store the rendered form for each font in an image segment. That seemed to work 100% As pointed out there is just a mess of eToys/Projects/whatever special casing going on in the default storage/reading of the segments, and when it goes bad, it's *hard* to figure out why. I did explore this area a bit more with WikiServer. In fact it's still on my to-do list, you can customize/override things to get a more simplistic set of steps, but I wasn't quite sure that sending a Pier Wiki to an image segment would be readable in the future, so I decided not to offer that as a storage option. On 2009-12-08, at 3:04 AM, Henrik Johansen wrote: > > On Dec 8, 2009, at 11:33 20AM, Mariano Martinez Peck wrote: > >> >> >> Thanks John. I am interested in your experience. However, I didn't understand this last paragraph where you said to finally make it work. >> I don't understand what did you change. What is the difference between "font menu" and " stored forms of >> each font face for the menu" ? > The way I read it, instead of storing the fonts themselves in an image segment, they stored a form with a string rendered by the font, then used that to display in list instead of actually loading the font, and rendering text with it. > That way the list could be shown fast, without having to load the fonts themselves until actually used/fonts on the machine changes. >> >> In addition, do you know why this has solved the problems ? > > If you look at the relative complexity of TTCFont and Form instances, it'd hardly come as a surprise that one may be loaded consistently, while the other is harder to get loaded correctly in all cases... > In other words, to me it seems like a workaround for non-repeatable errors when loading complex objects within ImageSegments (by storing simpler objects instead). > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Dec. 9, 2009

Re: [Pharo-project] DeprecationHistory

by Henrik Sperre Johansen

On 08.12.2009 23:28, Nicolas Cellier wrote: > 2009/12/8 Alain Plantec<alain.plantec(a)free.fr>: > >> Hi all, >> One of my recents slice for preferences migration has made pharo nearly >> unusable >> because a lot of deprecation dialogs was opened for a single browser. >> Then, the user had to forbid the deprecation warnings in order to avoid >> these popups. >> >> Now, what about a non blocking window which is opened automatically when a >> deprecated method is run, >> but showing the list of recents deprecations ? >> A double click on a list item, et hop!, a browser is opened on the >> deprecated method. >> I've tried it on the last pharo image and it seems ok. With it, it is still >> always possible to let deprecation warning >> without having to close any dialog window. >> What do you think ? >> >> A screenshot is attached. >> Cheers >> Alain >> >> > +1 I like the idea... > > Nicolas > +2 Even better if there's a button in each row to open a list of the methods that have been recorded as calling the deprecated version :D Henry

Dec. 8, 2009

Re: [Pharo-project] DeprecationHistory

by Nicolas Cellier

2009/12/8 Alain Plantec <alain.plantec(a)free.fr>: > Hi all, > One of my recents slice for preferences migration has made pharo nearly > unusable > because a lot of Â deprecation dialogs was opened for a single browser. > Then, the user had to forbid the deprecation warnings in order to avoid > these popups. > > Now, what about a non blocking window which is opened automatically when a > deprecated method is run, > but showing the list of recents deprecations ? > A double click on a list item, et hop!, Â a browser is opened on the > deprecated method. > I've tried it on the last pharo image and it seems ok. With it, it is still > always possible to let deprecation warning > without having to close any dialog window. > What do you think ? > > A screenshot is attached. > Cheers > Alain > +1 I like the idea... Nicolas > > > _______________________________________________ > 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] DeprecationHistory

by Alain Plantec

Hi all, One of my recents slice for preferences migration has made pharo nearly unusable because a lot of deprecation dialogs was opened for a single browser. Then, the user had to forbid the deprecation warnings in order to avoid these popups. Now, what about a non blocking window which is opened automatically when a deprecated method is run, but showing the list of recents deprecations ? A double click on a list item, et hop!, a browser is opened on the deprecated method. I've tried it on the last pharo image and it seems ok. With it, it is still always possible to let deprecation warning without having to close any dialog window. What do you think ? A screenshot is attached. Cheers Alain

Dec. 8, 2009

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

by Mariano Martinez Peck

On Tue, Dec 8, 2009 at 7:42 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Why a preference? Its just a matter of selecting the font you like: > > System > Preferences > System fonts > > In the Font Browser you can click on "Update" and you *should* get all > your system fonts. The problem is, that the font browser does not > update. If you open it again, you see the fonts. > > Excellent :) I wasn't aware of this! really cool. > I filed an issue for 1.0/1.1: > > http://code.google.com/p/pharo/issues/detail?id=1562 > > Adrian > > > On Dec 8, 2009, at 19:25 , Mariano Martinez Peck wrote: > > > 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 > >> > > _______________________________________________ > > 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