- Pharo-dev - lists.pharo.org

[Pharo-project] [update] #10502

by Marcus Denker

Hi, Two more fixes for 1.0... 10502 ----- Issue 889: MouseOverHandler send messages to nil Issue 1136: DejaVu strinkeFonts render ascii character in WideStrings as black boxes

Dec. 9, 2009

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

by Tudor Girba

We are already using the MorphTreeMorph in Glamour in a 1.0 image. It's pretty cool. You can get it at: Gofer new squeaksource: 'Momo'; addPackage: 'Morphic-MorphTreeWidget'; load. Cheers, Doru On 8 Dec 2009, at 21:36, StÃ©phane Ducasse wrote: > 1.1 of course :) > I'm riding the wafe :) > > > On Dec 8, 2009, at 9:05 PM, Schwab,Wilhelm K wrote: > >> Stef, >> >> Where does this work? My RC1 image either does not contain the >> classes, or I'm being too dense to see the corrected thing in the >> list of choices. Interested, if only as examples to help me with a >> couple of tasks... >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of StÃ©phane Ducasse >> Sent: Tuesday, December 08, 2009 11:08 AM >> To: Pharo-project(a)lists.gforge.inria.fr Development >> Cc: notre liste >> Subject: [Pharo-project] ClassTree new openOn: Collection :) >> >> 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 >> _______________________________________________ >> 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 -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Dec. 9, 2009

[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