May 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Incremental garbage collection

by Alexandre Bergel

Hi! The garbage collection offered by the Pharo VM has two divisions. One for young objects, and another for old objects. I was wondering when a young object become old? I start to have a pretty good idea for human beings, but I am not so sure for Pharo objects. Is it when the object survives its first garbage collection? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 10, 2010

Re: [Pharo-project] Which fonts for Pharo 1.1 ?

by Schwab,Wilhelm K

First, I am far from the best person to make the decision. That said, it would be nice to have the ability to use true type fonts. My move from Windows will not be complete until I have arranged for a home-grown font to produce symbols on paper (but I'm confusing you and scaring, make that terrifying<g>, myself). While I want to be able to use tt fonts, I am not sure whether I care about them being used in the IDE. The things I want are nice looking fonts (Pharo has long since spoiled me for anything less) and fast rendering. If strike fonts look good and are faster than tt, that might be the way to go. I'll shut up now and let people who know something about this comment on it. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Monday, May 10, 2010 9:01 AM To: Pharo Development Subject: [Pharo-project] Which fonts for Pharo 1.1 ? Hi guys. Last Pharo 1.0 images have the TrueType fonts. Now, in Pharo 1.1 Cores we have a StrikeFonts. We have two possibilites: 1) let those (strike fonts) fonts also for the dev image 2) Continue to put TrueType in Pharo dev I am all ears. Cheers Mariano

May 10, 2010

[Pharo-project] keyAtValue: -> keysAtValue:

by Tristan Bourgois

keyAtValue: returns one key of the value specified but if you have more time the same value the method return one key. An example: t:=Dictionary new. t at: 'toto' put: 4. t at: 'foo' put: 4. t keyAtValue:4. -> 'foo' So we can't recuperate all of the keys. I propose to create the methods keysAtValue: who return an Array with all the keys for this value. I'm not in Pharo very long time so I can not say if it can be useful so I am asking to you the question. Tristan Bourgois. -- View this message in context: http://forum.world.st/keyAtValue-keysAtValue-tp2165484p2165484.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 10, 2010

Re: [Pharo-project] Which fonts for Pharo 1.1 ?

by Henrik Johansen

On May 10, 2010, at 4:01 10PM, Mariano Martinez Peck wrote: > Hi guys. Last Pharo 1.0 images have the TrueType fonts. Now, in Pharo 1.1 Cores we have a StrikeFonts. We have two possibilites: > > 1) let those (strike fonts) fonts also for the dev image > 2) Continue to put TrueType in Pharo dev > > I am all ears. > > Cheers > > Mariano Most current VM's have all BitBlt fixes in, so StrikeFonts look ok when dragged (not when rotated though, but that is image-side). The 5.0 line of Mac VM's does not have a working FTPlugin. So, depends on whether you favor speed and opening with (still in beta) VMs reliably, or a wider availability of Fonts to choose from. Rendering-wise, there shouldn't be any differences outside the inherent ones. Cheers, Henry

May 10, 2010

[Pharo-project] Set and get values from the VM AND the image

by Mariano Martinez Peck

Hi folks. I need to intercept all messages. For such purpose, I modified Interpreter >> normalSend like this: normalSend "Send a message, starting lookup with the receiver's class." "Assume: messageSelector and argumentCount have been set, and that the receiver and arguments have been pushed onto the stack," "Note: This method is inlined into the interpreter dispatch loop." | rcvr | self inline: true. self sharedCodeNamed: 'normalSend' inCase: 131. rcvr := self internalStackValue: argumentCount. (self isIntegerObject: rcvr) ifFalse: [ self doSomething: rcvr. ]. lkupClass := self fetchClassOf: rcvr. receiverClass := lkupClass. self commonSend. But now, from the IMAGE side I would like to enable or disable such intercept. It would be great if from the Image side I can set a value to a boolean and read such value and ask, from the VM side. Do you know if I can do this? Should I use specialObjectArray ? If true, can you give me a hint of how to do it ? Thank you very much. Mariano

May 10, 2010

Re: [Pharo-project] idea for a mini browser to trait

by Alexandre Bergel

If I have to express my wishlist, I would say having a set of trait- based refactorings is important. I often realize after having written some code that I want to have this and that methods in a trait. Doing a right click on a method and choose 'move method to trait' is useful (with O2). But much more can be done. Cheers, Alexandre On 10 May 2010, at 10:20, Tristan Bourgois wrote: > > I'm working on trait and when there conflicts we can see the > problematic > methods. But if you want to see what there are into the methods > where there > are the problem you have to do it manually. > So why not create a mini browser to: > 1)see the code of the methods > 2)choose the method to keep (so remove the other method) > > Like that you can rapidly see what method to keep or simply see the > methods > and could reuse the code for an overridden method. > > I think that's a good idea! > > Tristan Bourgois. > -- > View this message in context: http://forum.world.st/idea-for-a-mini-browser-to-trait-tp2165466p2165466.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 10, 2010

[Pharo-project] idea for a mini browser to trait

by Tristan Bourgois

I'm working on trait and when there conflicts we can see the problematic methods. But if you want to see what there are into the methods where there are the problem you have to do it manually. So why not create a mini browser to: 1)see the code of the methods 2)choose the method to keep (so remove the other method) Like that you can rapidly see what method to keep or simply see the methods and could reuse the code for an overridden method. I think that's a good idea! Tristan Bourgois. -- View this message in context: http://forum.world.st/idea-for-a-mini-browser-to-trait-tp2165466p2165466.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 10, 2010

[Pharo-project] Which fonts for Pharo 1.1 ?

by Mariano Martinez Peck

Hi guys. Last Pharo 1.0 images have the TrueType fonts. Now, in Pharo 1.1 Cores we have a StrikeFonts. We have two possibilites: 1) let those (strike fonts) fonts also for the dev image 2) Continue to put TrueType in Pharo dev I am all ears. Cheers Mariano

May 10, 2010

Re: [Pharo-project] Bug PackageInfo >> classes return also Traits

by Igor Stasenko

2010/5/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Mon, May 10, 2010 at 1:06 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> not for 1.1 guy. it worked so far.... so let us finish 1.1 >> >> > > Ok, I agree. I never said to include it in 1.1. I want just to discuss about > it. > 2c I think , right question is to ask, why PackageInfo should even bother to answer this message. Right now , we having a classes and traits. Now suppose, that in some distant future, we might want to add another kind of behavior/data grouping into a package. So, should we then implement PackageInfo >>classesAndTraitsAndGrouping as well? > > >> >> On May 10, 2010, at 11:15 AM, Mariano Martinez Peck wrote: >> >> > Hi folks. I've just discovered that PackageInfo >> classes Â return a >> > collection of classes AND traits. This is incorrect. Solutions are: >> > >> > 1) Rename #classes to #classesAndTraits >> > 2) Modify #classes so that it ONLY answer classes >> > >> > I would like to fix it but I am not sure the consequences of such >> > change. Maybe Monticello doesn't take into account Traits anymore hahha >> > >> > Thanks for any help you can give. >> > >> > Mariano >> > _______________________________________________ >> > 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 > -- Best regards, Igor Stasenko AKA sig.

May 10, 2010

Re: [Pharo-project] Bug PackageInfo >> classes return also Traits

by Mariano Martinez Peck

On Mon, May 10, 2010 at 1:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > not for 1.1 guy. it worked so far.... so let us finish 1.1 > > > Ok, I agree. I never said to include it in 1.1. I want just to discuss about it. > > On May 10, 2010, at 11:15 AM, Mariano Martinez Peck wrote: > > > Hi folks. I've just discovered that PackageInfo >> classes return a > collection of classes AND traits. This is incorrect. Solutions are: > > > > 1) Rename #classes to #classesAndTraits > > 2) Modify #classes so that it ONLY answer classes > > > > I would like to fix it but I am not sure the consequences of such change. > Maybe Monticello doesn't take into account Traits anymore hahha > > > > Thanks for any help you can give. > > > > Mariano > > _______________________________________________ > > 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 >

May 10, 2010