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

Re: [Pharo-project] New profiler for Pharo: tester wanted!

by Adrian Lienhard

I also got the warnings and an error in the end. Adrian On Jan 20, 2010, at 12:06 , Alexandre Bergel wrote: > Strange, I tried in a 10505 and I got no warning. I will try later > today. > > Alexandre > > >> I tried it in a PharoCore 1.0 10506 and I get a lot of deprecation >> warnings for gofer addPackage:, addVersion: >> >> The method Gofer addVersion: has been deprecated. >> Instead of #addVersion: simply use #version: >> >> Select Proceed to continue, or close this window to cancel the >> operation. >> >> I pressed proceed and then I got: >> >> >> MetacelloGoferPackage(Object)>>doesNotUnderstand: #setName. >> >> Is this for 1.0, what version? >> >> Cheers >>> >>> To invoke the profiler, use the following template: >>> ProfilingPackageSpy viewProfiling: [ "YOUR CODE" ] inPackage: >>> 'YourPackageName' >>> ProfilingPackageSpy viewProfiling: [ "YOUR CODE" ] >>> inPackagesMatching: 'PackageName*' >>> >>> Replace "YOUR CODE" by an expression. Some examples are provided in >>> the class ProfilingPackageSpy (method category 'example'). You can >>> find profilings of Mondrian, Glamour, Moose/CAnalyzer, O2. >>> The profiling of Mondrian looks like this: >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> ProfilingPackageSpy >>> viewProfiling: [ >>> | view | >>> view := MOViewRenderer new. >>> view nodes: (1 to: 100) forEach: [:each | view nodes: (1 to: >>> 100)]. >>> view root applyLayout >>> ] >>> inPackage: 'Mondrian' >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> >>> There are two things you should keep in mind: >>> - "YOUR CODE" will be executed twice. The first time with message >>> Tally, then the second time with the full instrumentation. The second >>> execution should not be impacted by the first execution. >>> - You cannot instrument the whole image. I need more time to make >>> this >>> happens. Therefore, you cannot provide '*' to inPackagesMatching: >>> >>> How to read the picture: >>> - big rectangle are classes >>> - edges represent class inheritance >>> - inner rectangles are methods: >>> * height = total time that the method has been executed >>> * width = number of time the method has been executed >>> * color = number of different receiver: white = the method has >>> been executed on 1 receiver. black = many receivers >>> >>> You can do a right-click on a method, and select viewInvocation. This >>> opens a second view that show the execution flow. A different mapping >>> of metrics is used: >>> - rectangle = methods >>> - edges = invocation (upper invokes below) >>> - gray color = method that always return 'self'. It corresponds to >>> void methods in Java or C++. It is therefore likely that the method >>> performs a side effect >>> - yellow color = method that always returns the same value for a >>> particular object >>> - width and height are as in the first visualization >>> >>> Keep in mind that you mind encounter a freeze of your image if you >>> instrument sensitive methods. >>> >>> I would be sincerely delighted to have experience report on this. >>> >>> Regards, >>> Alexandre >>> >>> >> >> -- >> Miguel CobÃ¡ >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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

Jan. 20, 2010

Re: [Pharo-project] New profiler for Pharo: tester wanted!

by Alexandre Bergel

Strange, I tried in a 10505 and I got no warning. I will try later today. Alexandre > I tried it in a PharoCore 1.0 10506 and I get a lot of deprecation > warnings for gofer addPackage:, addVersion: > > The method Gofer addVersion: has been deprecated. > Instead of #addVersion: simply use #version: > > Select Proceed to continue, or close this window to cancel the > operation. > > I pressed proceed and then I got: > > > MetacelloGoferPackage(Object)>>doesNotUnderstand: #setName. > > Is this for 1.0, what version? > > Cheers >> >> To invoke the profiler, use the following template: >> ProfilingPackageSpy viewProfiling: [ "YOUR CODE" ] inPackage: >> 'YourPackageName' >> ProfilingPackageSpy viewProfiling: [ "YOUR CODE" ] >> inPackagesMatching: 'PackageName*' >> >> Replace "YOUR CODE" by an expression. Some examples are provided in >> the class ProfilingPackageSpy (method category 'example'). You can >> find profilings of Mondrian, Glamour, Moose/CAnalyzer, O2. >> The profiling of Mondrian looks like this: >> -=-=-=-=-=-=-=-=-=-=-=-= >> ProfilingPackageSpy >> viewProfiling: [ >> | view | >> view := MOViewRenderer new. >> view nodes: (1 to: 100) forEach: [:each | view nodes: (1 to: >> 100)]. >> view root applyLayout >> ] >> inPackage: 'Mondrian' >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> There are two things you should keep in mind: >> - "YOUR CODE" will be executed twice. The first time with message >> Tally, then the second time with the full instrumentation. The second >> execution should not be impacted by the first execution. >> - You cannot instrument the whole image. I need more time to make >> this >> happens. Therefore, you cannot provide '*' to inPackagesMatching: >> >> How to read the picture: >> - big rectangle are classes >> - edges represent class inheritance >> - inner rectangles are methods: >> * height = total time that the method has been executed >> * width = number of time the method has been executed >> * color = number of different receiver: white = the method has >> been executed on 1 receiver. black = many receivers >> >> You can do a right-click on a method, and select viewInvocation. This >> opens a second view that show the execution flow. A different mapping >> of metrics is used: >> - rectangle = methods >> - edges = invocation (upper invokes below) >> - gray color = method that always return 'self'. It corresponds to >> void methods in Java or C++. It is therefore likely that the method >> performs a side effect >> - yellow color = method that always returns the same value for a >> particular object >> - width and height are as in the first visualization >> >> Keep in mind that you mind encounter a freeze of your image if you >> instrument sensitive methods. >> >> I would be sincerely delighted to have experience report on this. >> >> Regards, >> Alexandre >> >> > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 20, 2010

Re: [Pharo-project] After OB, compare to current version uses old diff

by Mariano Martinez Peck

Thanks Gary, I have just checked, but it keeps the same. Now new version after loading OB 2010/1/20 Gary Chambers <gazzaguru2(a)btinternet.com> > Sorry I meant compareToCurrentVersion... > > Regards, Gary > > ----- Original Message ----- > *From:* Mariano Martinez Peck <marianopeck(a)gmail.com> > *To:* Pharo-project(a)lists.gforge.inria.fr > *Sent:* Wednesday, January 20, 2010 9:04 AM > *Subject:* Re: [Pharo-project] After OB,compare to current version uses > old diff > > I created the issue http://code.google.com/p/pharo/issues/detail?id=1855 > > On Tue, Jan 19, 2010 at 8:38 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Gary: I compared that method before and after loading OB and it is the >> same. >> >> The method is from gvc 2/9/2009 12:45 like this: >> >> >> compareToOtherVersion >> "Prompt the user for a reference version, then spawn a window >> showing the diffs between the older and the newer of the current >> version and the reference version as text." >> >> | change1 change2 s1 s2 | >> change1 := changeList at: listIndex ifAbsent: [^self]. >> change2 := UIManager default >> chooseFrom: (list copyWithoutIndex: listIndex) >> values: (changeList copyWithoutIndex: listIndex). >> change2 ifNil: [^self]. >> s1 := change1 string. >> s2 := change2 string. >> s1 = s2 ifTrue: [^self inform: 'Exact Match' translated]. >> (DiffMorph >> from: s1 >> to: s2 >> contextClass: change1 methodClass) >> openInWindowLabeled: (('Comparison from {1} to {2}' translated) >> format: {change1 stamp. change2 stamp}) >> >> >> >> >> >> On Tue, Jan 19, 2010 at 8:29 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> do you have the correct version? >>> The problem is certainly link with override and moving package around >>> (this is bogus with MC). >>> >>> Stef >>> >>> >>> On Jan 19, 2010, at 7:00 PM, Gary Chambers wrote: >>> >>> > Clearly the cruicial method is overwritten... >>> VersionsBrowser>>compareToOtherVersion. >>> > >>> > Regards, Gary >>> > ----- Original Message ----- >>> > From: Mariano Martinez Peck >>> > To: Pharo-project(a)lists.gforge.inria.fr >>> > Sent: Tuesday, January 19, 2010 5:57 PM >>> > Subject: Re: [Pharo-project] After OB,compare to current version uses >>> old diff >>> > >>> > >>> > >>> > 2010/1/19 Gary Chambers <gazzaguru2(a)btinternet.com> >>> > Unless code has changed then the setting for "Use Polymorph difference >>> tools" should do. >>> > I expect some code regression may have happened though. >>> > >>> > Thanks Gary. The preference is the one Henrik said, >>> useNewDiffToolsForMC, but it is not working for me. You can try it like >>> this: take the latest PharoCore 1.0 image, (10506). You will notice that it >>> is working with the new diff. Then, evaluate: >>> > >>> > Gofer new >>> > squeaksource: 'MetacelloRepository'; >>> > package: 'ConfigurationOfOmniBrowser'; >>> > load. >>> > >>> > >>> > ((Smalltalk at: #ConfigurationOfOmniBrowser) project version: '1.0') >>> load. >>> > >>> > Or download OB by hand from Lukas repo. >>> > >>> > After this, you will notice it uses the old diff even if the preference >>> is enable and even disabling it and enabling again. >>> > >>> > Cheers >>> > >>> > Mariano >>> > >>> > >>> > Regards, Gary >>> > ----- Original Message ----- >>> > From: Mariano Martinez Peck >>> > To: Pharo-project(a)lists.gforge.inria.fr >>> > Sent: Tuesday, January 19, 2010 4:35 PM >>> > Subject: Re: [Pharo-project] After OB,compare to current version uses >>> old diff >>> > >>> > >>> > >>> > On Tue, Jan 19, 2010 at 5:22 PM, Henrik Johansen < >>> henrik.s.johansen(a)veloxit.no> wrote: >>> > Preferences >> useNewDiffToolsForMC? >>> > >>> > I tried this before sending the email, but not. I didn't work :( >>> > >>> > >>> > There was some discussion some time back, I believe Lukas stated he >>> liked the old tools better. >>> > >>> > Ok..didn't know. >>> > >>> > Can't say I blame him, I'm never quite sure if I'm installing new one >>> or keeping old when merging from MC until after the fact when I use the >>> Polymorph tools ... >>> > >>> > >>> > I can blame him at all. He is helping us a lot maintaining OB a lot. If >>> we use his OB repository, then we should adapt to him. I don't pretend he >>> change his default values or preferences. I just want to know how to set up >>> again the new diff :) >>> > >>> > Cheers >>> > >>> > Mariano >>> > >>> > Cheers, >>> > Henry >>> > >>> > On Jan 19, 2010, at 5:05 26PM, Mariano Martinez Peck wrote: >>> > >>> > > Hi: If you take a PharoCore image, and browse the editions of a >>> class, then select an older one, and then select "compare to current", you >>> see the differences using the "new" diff, the same that we use in MC. >>> > > >>> > > However, after installing OB in a core image, it uses the "old" >>> version. I am not sure that change is due to OB, but at least it seems. I >>> checked in Preferences but I didn't find anything. >>> > > >>> > > Any hint how to put new diff again after installing OB ? >>> > > >>> > > Thanks! >>> > > >>> > > 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 >>> > >>> > _______________________________________________ >>> > 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 >

Jan. 20, 2010

Re: [Pharo-project] After OB, compare to current version uses old diff

by Gary Chambers

Sorry I meant compareToCurrentVersion... Regards, Gary ----- Original Message ----- From: Mariano Martinez Peck To: Pharo-project(a)lists.gforge.inria.fr Sent: Wednesday, January 20, 2010 9:04 AM Subject: Re: [Pharo-project] After OB,compare to current version uses old diff I created the issue http://code.google.com/p/pharo/issues/detail?id=1855 On Tue, Jan 19, 2010 at 8:38 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: Gary: I compared that method before and after loading OB and it is the same. The method is from gvc 2/9/2009 12:45 like this: compareToOtherVersion "Prompt the user for a reference version, then spawn a window showing the diffs between the older and the newer of the current version and the reference version as text." | change1 change2 s1 s2 | change1 := changeList at: listIndex ifAbsent: [^self]. change2 := UIManager default chooseFrom: (list copyWithoutIndex: listIndex) values: (changeList copyWithoutIndex: listIndex). change2 ifNil: [^self]. s1 := change1 string. s2 := change2 string. s1 = s2 ifTrue: [^self inform: 'Exact Match' translated]. (DiffMorph from: s1 to: s2 contextClass: change1 methodClass) openInWindowLabeled: (('Comparison from {1} to {2}' translated) format: {change1 stamp. change2 stamp}) On Tue, Jan 19, 2010 at 8:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: do you have the correct version? The problem is certainly link with override and moving package around (this is bogus with MC). Stef On Jan 19, 2010, at 7:00 PM, Gary Chambers wrote: > Clearly the cruicial method is overwritten... VersionsBrowser>>compareToOtherVersion. > > Regards, Gary > ----- Original Message ----- > From: Mariano Martinez Peck > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Tuesday, January 19, 2010 5:57 PM > Subject: Re: [Pharo-project] After OB,compare to current version uses old diff > > > > 2010/1/19 Gary Chambers <gazzaguru2(a)btinternet.com> > Unless code has changed then the setting for "Use Polymorph difference tools" should do. > I expect some code regression may have happened though. > > Thanks Gary. The preference is the one Henrik said, useNewDiffToolsForMC, but it is not working for me. You can try it like this: take the latest PharoCore 1.0 image, (10506). You will notice that it is working with the new diff. Then, evaluate: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfOmniBrowser'; > load. > > > ((Smalltalk at: #ConfigurationOfOmniBrowser) project version: '1.0') load. > > Or download OB by hand from Lukas repo. > > After this, you will notice it uses the old diff even if the preference is enable and even disabling it and enabling again. > > Cheers > > Mariano > > > Regards, Gary > ----- Original Message ----- > From: Mariano Martinez Peck > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Tuesday, January 19, 2010 4:35 PM > Subject: Re: [Pharo-project] After OB,compare to current version uses old diff > > > > On Tue, Jan 19, 2010 at 5:22 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Preferences >> useNewDiffToolsForMC? > > I tried this before sending the email, but not. I didn't work :( > > > There was some discussion some time back, I believe Lukas stated he liked the old tools better. > > Ok..didn't know. > > Can't say I blame him, I'm never quite sure if I'm installing new one or keeping old when merging from MC until after the fact when I use the Polymorph tools ... > > > I can blame him at all. He is helping us a lot maintaining OB a lot. If we use his OB repository, then we should adapt to him. I don't pretend he change his default values or preferences. I just want to know how to set up again the new diff :) > > Cheers > > Mariano > > Cheers, > Henry > > On Jan 19, 2010, at 5:05 26PM, Mariano Martinez Peck wrote: > > > Hi: If you take a PharoCore image, and browse the editions of a class, then select an older one, and then select "compare to current", you see the differences using the "new" diff, the same that we use in MC. > > > > However, after installing OB in a core image, it uses the "old" version. I am not sure that change is due to OB, but at least it seems. I checked in Preferences but I didn't find anything. > > > > Any hint how to put new diff again after installing OB ? > > > > Thanks! > > > > 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 > > _______________________________________________ > 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

Jan. 20, 2010

Re: [Pharo-project] Question on recursive structures

by Mariano Martinez Peck

Copied from another thread: http://wiki.squeak.org/squeak/899 http://wiki.squeak.org/squeak/1542 2010/1/20 Viktor Kerkez <alefnula(a)gmail.com> > Hi, > > Since this is my first post on the list, first I want to thank you all for > the great job you're doing on Pharo :) It was a real revelation when I > discovered it :) > > Now to the question: > > I'm reading the Pharo by Example, and came to this part: > > The problem with deepCopy is that it will not terminate when applied to a > mutually recursive structure: > a1 := { 'harry' }. > a2 := { a1 }. > a1 at: 1 put: a2. > a1 deepCopy -! ... does not terminate! > > (Pharo actually get stuck at the step: a1 at: 1 put: a2. but that's not the > question :) ) > > 1. Isn't this behaviour (the complete environment get stuck and there is no > way to unfreeze it) considered a bug? I mean the environment shouldn't let > you shoot yourself in the foot (at least not so easily). Actually the same > behaviour can be created just doing: [true] whileTrue: []... > > 2. Shouldn't Pharo recognize recursive structures in some way? > > > I'm asking because I'm coming from a Python world, which is very similar to > smalltalk in some manners and I'm trying to make a big picture comparison in > my head. > > 1. I know that this doesn't really compares to Pharo which is a graphical > environment, but in python you can always hit Ctrl-C and break the > statements that block... > > >>> while True: > ... pass > ... > ^CTraceback (most recent call last): > File "<stdin>", line 1, in <module> > KeyboardInterrupt > >>> > > Shouldn't the UI thread always be responsive? > > 2. And Python recognizes recursive structures: > > >>> a = [] > >>> a > [] > >>> a.append(5 > ... > KeyboardInterrupt > >>> a = [] > >>> a > [] > >>> a.append(5) > >>> a > [5] > >>> a.append(a) > >>> a > [5, [...]] > >>> a[0] > 5 > >>> a[1] > [5, [...]] > >>> a[1][1][1][1][0] > 5 > >>> > > > Don't get me wrong, I'm not trying to start a language war :) I wouldn't > got to page 171 if I'm not really interested in Smalltalk :-D I'm just > trying to get a clearer vision if these are some things that are there for > some reason (design decision), or they are just not yet implemented, or they > cannot be implemented for some other reasons? > > Thank you in advance for your time :), > Viktor > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 20, 2010

[Pharo-project] Scripts that should be run after a slice and ScriptLoader

by Mariano Martinez Peck

Hi: I found that several times, we need to run some piece of code after a slide. The only way I see doing this is to write it in a txt , and, hopefully (many times, the commiter or the integrator forget about it), remember to put that in the email or issue, when I let you know the fix is ready. Is there a better way ? What about having a method in ScriptLoader where we can commit that together with the slice? Then when someone integrates that, it will see that, and will move that piece of code, from there, to the update or script methods. I don't know. What do you think ? Would be cool, maybe, to reify the "slice" concept, where you can have: pre-doits, a collections of "pieces of code" (several times we have, part1, part2, tc), post-doits, etc...But I guess that requires a lot of effort. Cheers Mariano

Jan. 20, 2010

Re: [Pharo-project] how to get nice native fonts in 1.0

by Simon Denier

On 20 janv. 2010, at 09:27, Damien Cassou wrote: > On Wed, Jan 20, 2010 at 8:48 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I have to give some demos of seaside today and I would like to have nice fonts in 1.0 >> and I cannot find the preferences to say that the fonts can be looked up on my disc. >> and I'm looking for some nice combination (but the code snippets on the wiki do not work). > > FreeTypeFontProvider current updateFromSystem. > > font := LogicalFont familyName: 'DejaVu Sans' pointSize: 10. > codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. > titleFont := LogicalFont familyName: 'DejaVu Sans' pointSize: 11. > > Preferences > setListFontTo: font; > setMenuFontTo: font; > setCodeFontTo: codeFont; > setButtonFontTo: font; > setSystemFontTo: font; > setWindowTitleFontTo: titleFont. > Yep, this is more or less the script I use in my images (Pharo 1.0) -- Simon

Jan. 20, 2010

Re: [Pharo-project] Parrot VM

by Igor Stasenko

2010/1/20 Randal L. Schwartz <merlyn(a)stonehenge.com>: >>>>>> "Randal" == Randal L Schwartz <merlyn(a)stonehenge.com> writes: > > Randal> Parrot's GC suffers from having many different kinds of mixed objects. > > Randal> http://wknight8111.blogspot.com/2010/01/boehm-in-parrot.html > > And worse, having untyped data blobs on a stack... that's probably the worst > thing there. > > If you can't tell what live pointers you have for sure, you can't GC, and if > you can't GC reliably, you lose. Boehm GC is conservative one. Not a good way to achieve good performance. Mixing object pointers and non-object pointers on stack/object contents is different story. If you providing a good way to determine if given memory chunk cointains oops, or just raw bytes (like compiled method or bytearray etc), then this is not a problem, since you still can use precise GC. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion > > _______________________________________________ > 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.

Jan. 20, 2010

[Pharo-project] XMLRPC client/server

by Serge Stinckwich

Hi all, i'm looking for a XMLRPC client/server implementation for Pharo. I found an implementation for Squeak that look a bit outdated: http://www.squeaksource.com/XMLRPC.html Anyone using this one ? Thank you, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Jan. 20, 2010

Re: [Pharo-project] how to get nice native fonts in 1.0

by Tudor Girba

Hi Stef, If you load the Setup package from the http://www.squeaksource.com/ setup, you get in the ImageSetup class some scripts I use for setting up fonts. For presentations I typically use: Gofer new squeaksource: 'setup'; package: 'Setup'; load. (Smalltalk at: #ImageSetup) new girbaSmallDemoFontsSetting Cheers, Doru On 20 Jan 2010, at 09:34, Mariano Martinez Peck wrote: > Be aware need a "Fonts" folder if you don't have DejaVu isntalled in > your OS. > > Stef, which image are you going to use ? PharoCore, PharoDev, > Seaside one click ? > > On Wed, Jan 20, 2010 at 9:27 AM, Damien Cassou <damien.cassou(a)gmail.com > > wrote: > On Wed, Jan 20, 2010 at 8:48 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > I have to give some demos of seaside today and I would like to > have nice fonts in 1.0 > > and I cannot find the preferences to say that the fonts can be > looked up on my disc. > > and I'm looking for some nice combination (but the code snippets > on the wiki do not work). > > FreeTypeFontProvider current updateFromSystem. > > font := LogicalFont familyName: 'DejaVu Sans' pointSize: 10. > codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. > titleFont := LogicalFont familyName: 'DejaVu Sans' pointSize: 11. > > Preferences > setListFontTo: font; > setMenuFontTo: font; > setCodeFontTo: codeFont; > setButtonFontTo: font; > setSystemFontTo: font; > setWindowTitleFontTo: titleFont. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > 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 "Relationships are of two kinds: those we choose and those that happen. They both matter."

Jan. 20, 2010