- Pharo-dev - lists.pharo.org

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by Nicolas Cellier

Sorry for the infinite loop, it was my fault. I thought it had been detected and solved already (in squeak ?). Destroying source pointer of un-installed methods was just a workaround to be used in case of already broken sources. There is another strategy : detect the source pointer of un-installed methods and store them in the new change log. This has to be done before logging source code of installed methods. Nicolas 2010/5/9 Igor Stasenko <siguctua(a)gmail.com>: > On 9 May 2010 23:17, Alain Plantec <alain.plantec(a)free.fr> wrote: >> >>> Ok, i took the 11343 >>> - fixed the #condenseChanges >>> - ran Â Smalltalk condenseChanges >>> - changed the single method >>> - saved image >>> - ran Â Smalltalk condenseChanges again >>> >>> no crash reported. >>> >> >> Indeed, with 11343 it seems ok. >> With 11326 (updated -> 11346), crash during the second condenseChanges :( > > Alain, could you please send me an image +.changes saved just before > running a second condenseChanges? > I'll try to find the cause of it. > >> Alain >>> >>> >>>> >>>> Alain >>>> >>>> >>> >>> >>> >> >> >> _______________________________________________ >> 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

May 10, 2010

Re: [Pharo-project] Incremental garbage collection

by Igor Stasenko

On 10 May 2010 18:33, Alexandre Bergel <alexandre.bergel(a)inria.fr> wrote: > 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? > I'd say, whenever VM decides to change a youngStart pointer. Its quite sophisticated, and having a lot of quirks & preconditions. But after compaction (either incremental or full), it usually picks a free memory region which will serve as a space for newly created objects. After that, obviously, all objects, which survived GC treated as old ones. > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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] Incremental garbage collection

by Mariano Martinez Peck

On Mon, May 10, 2010 at 5:33 PM, Alexandre Bergel <alexandre.bergel(a)inria.fr > wrote: > 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? > > Hi Alexandre. I am still newbie with VM stuff, but as I understood, yes, young objects become old when they survive to thei first incremental GC. Notice the INCREMENTAL GC and not FULL GC. But I may be wrong...so I will let other to answer properly ;) I have just looked at the code and I am not sure where that movement happens :( Cheers Mariano > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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] 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