- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Point name Point class name are not both symbol

by Adrian Lienhard

Maybe you've also run into the problem with the symbol table that had very bad performance characteristics: http://code.google.com/p/pharo/issues/detail?id=1047 It was fixed in Pharo last summer. Adrian On Dec 25, 2009, at 22:45 , Adrian Kuhn wrote: > StÃ©phane Ducasse <stephane.ducasse@...> writes: > >> I was wondering if it would make sense to have >> Point name >> Point class name >> both returning a symbol and not in one case a symbol and the other a >> string. > > To my understanding, the role of a symbol is to be a speed-optimized > identifier > (of either a class or method) and #'Point class' is not an > identifier but an > expression which does not evaluate faster when being a symbol. > > Also creating too many symbols might harm system performance. I > learned that > the hard way with Moose, it used to use symbols everywhere and > eventually it > would take 10 seconds to open autocompletion. So I am always > reluctant to make > too many symbols. > > --AA > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 26, 2009

Re: [Pharo-project] [update 1.1] #11115

by Michael Roberts

Ok, I take your point but I had given system version the ability to write out the image name. Now it doesn't have enough information or we need this special case. This is with a view to automatic building. Anyway it is not important at the moment. We can solve it later. Mike On Friday, December 25, 2009, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > we can keep alpha for us and just have the name of the image tagged UNSTABLE > because else we may have to change the update list and so on. > So I would not do more than I did because we can spend good energy on something else. > > Stef > On Dec 25, 2009, at 8:53 PM, Michael Roberts wrote: > >> re: #1624 >> >> you need to do this ;-) >> >> SystemVersion current suffix: 'UNSTABLE' >> >> thanks, >> Mike >> >> On Fri, Dec 25, 2009 at 10:50 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> 11115 >>> ----- >>> >>> Issue 1683: Â Â From The Trunk: minor improvement of MethodDictionary>>includesKey: >>> Â Â Â Â N. Cellier and Traits :) >>> Issue 1664: Â Â Long method can not be compiled using #compile: aString >>> Issue 1158: Â Â System Browser vs Class Browser tx David R. >>> Issue 1624: Â Â 1.1#alpha should be renamed to 1.1#unstable >>> _______________________________________________ >>> 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. 26, 2009

Re: [Pharo-project] freetype plugin on os-x squeak v5.0 -> goes to 5.1

by John M McIntosh

Ok after a day of slugging thru bits between way too much turkey I reworked the freetype plugin code so that it now works with 64bit VMs running 32bit images. There was a slight mistruth in the freetype header. /*************************************************************************/ /* */ /* <Type> */ /* FT_Pos */ /* */ /* <Description> */ /* The type FT_Pos is a 32-bit integer used to store vectorial */ /* coordinates. Depending on the context, these can represent */ /* distances in integer font units, or 16.16, or 26.6 fixed float */ /* pixel coordinates. */ /* */ typedef signed long FT_Pos; Yes sure it's a 32bit number stored in a 64bit integer. Unfortunately when you map that to your handy IntegerArray instance, you get whiteness. There were of course a few other places where "Oops" oops is a object reference, it's NOT a memory address, it can become one if you use the proper routine tho. Once that was all corrected then it works. I'm not able to check the FT2Plugin changes in yet because of a missing password. Now in order to make this all work I had to recompile the Squeak VM so that it exposes the object memory base memory address so the plugin can find it. So you'll find 5.1 at... http://smalltalkconsulting.com/squeak.html at the usual places, look in the experimental folder for the "64bit" directory then for the 64bit VM 32 bit image directory "32bitImage*64bitVM" and the zipped VM "Squeak 64/32 5.1b1.app.zip" Confirmation that it works elsewhere than my computer is welcome. PS yes please check on 32bit intel, 32/64bit intel, and 32bit powerpc. I'll build a 64bit version for 64bit images at some point in the future, but I think I'll look at the hostmenu logic first to get mac menus back. On 2009-12-20, at 6:16 PM, John M McIntosh wrote: > Ok, I spent a good 4 hours here working through issues. > > Unfortunately the plugin just assumes an oops reference is a pointer (it's not), and that the squeak word size is (4), it might not be, > and the occasional FreeType variable is that an int or long? FreeType defines their own var types so their code isn't confused, but we are... > > Plus a sprinkling of self cCode: to do magic transformations between oops pointers and instance pointer values transformed to an int, or is that a long... > > So it will be sometime yet before I get it working with a 64bit VM and 32bit image. > > On 2009-12-17, at 3:16 AM, Henrik Johansen wrote: > >> >> On Dec 17, 2009, at 11:09 01AM, John M McIntosh wrote: >> >>> Now I need someone to tell me where it fails when running as a 64bit VM with a 32bit image. >>> No doubt there is a primitive call that needs to be changed, but I'm a bit too tired now to >>> sort thru how the heck the FreeType class works to find out where it fails. (Silently I might add...) > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Dec. 26, 2009

Re: [Pharo-project] Fwd: hasEqualElements:

by csrabak＠bol.com.br

I've put some comments in the issue #1685. Em 25/12/2009 08:02, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: thanks for the explanation. I will add this in the method comment and probably class comment http://code.google.com/p/pharo/issues/detail?id=1685 Stef

Dec. 26, 2009

[Pharo-project] [OT] Marry Xmas

by Igor Stasenko

Hello, my best wishes to everyone! I enjoying to be a part of smalltalk community, its good spirit and friendly people. I'd like to thank everyone who actively participating in discussions, because that's the way we all have a chance to learn something new. And, of course, thanks to everyone who are pushing things forward. Do not hesitate to share your ideas and thoughts. We are need them, if we want to make better things. With all my respect to everyone, sincerely yours, Igor Stasenko.

Dec. 26, 2009

Re: [Pharo-project] Nicolas tests for MultiByteFileStreamTest

by Nicolas Cellier

2009/12/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Nicolas: I was trying to integrate your changes from here: > http://source.squeak.org/trunk/MultilingualTests-nice.4.mcz > > in the latest Pharo Core 11116Â and I have 2 failures and 2 errors. I just > load the MultiByteFileStreamTest from that version. > > The question is, should I integrate some changes from MultiByteFileStream > that are in squeak trunk so that the tests are green ? > > Thanks > > Mariano > Hmm, don't remember... BackChunk problem seems related to Damien changes (oldBack vs back) ByteConverter problem seems connected to lazy initialization of latin1Map > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 26, 2009

[Pharo-project] Nicolas tests for MultiByteFileStreamTest

by Mariano Martinez Peck

Nicolas: I was trying to integrate your changes from here: http://source.squeak.org/trunk/MultilingualTests-nice.4.mcz in the latest Pharo Core 11116 and I have 2 failures and 2 errors. I just load the MultiByteFileStreamTest from that version. The question is, should I integrate some changes from MultiByteFileStream that are in squeak trunk so that the tests are green ? Thanks Mariano

Dec. 26, 2009

[Pharo-project] 1696 ready to integrate

by Mariano Martinez Peck

http://code.google.com/p/pharo/issues/detail?id=1696 In PharoInbox Name: SLICE-Issue1696-NewTestsToWeek-MarianoMartinezPeck.2 Author: MarianoMartinezPeck Time: 25 December 2009, 11:45:35 pm UUID: 19032e1f-517d-4e47-97dc-97da66fb19fb Ancestors: SLICE-Issue1696-NewTestsToWeek-MarianoMartinezPeck.1 Dependencies: KernelTests-MarianoMartinezPeck.185 Added tests for Week class methods indexOfDay:, nameOfDay: and dayNames. >From Andreas in Squeak trunk Name: KernelTests-ar.85 Author: ar Time: 25 August 2009, 8:22:23 am UUID: 4e893949-199f-dc4d-9585-0814f2d57630 Ancestors: KernelTests-mha.84, KernelTests-it.69 Merged KernelTests-it.69: Reformatted code in Week>>startDay. Added tests for Week class methods indexOfDay:, nameOfDay: and dayNames.

Dec. 25, 2009

Re: [Pharo-project] Need Levente Uzonyi license

by Mariano Martinez Peck

Sorry for my confusion. I didn't know squeak trunk was MIT. This is excellent then. Sorry Levente! Cheers Mariano On Fri, Dec 25, 2009 at 11:01 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2009/12/25 Levente Uzonyi <leves(a)elte.hu>: > > On Fri, 25 Dec 2009, Mariano Martinez Peck wrote: > > > >> Hi Levente: I would like to integrate some of your code (most changes to > >> squeak) but as you may know, any code commited to Pharo must be MIT > license > >> and we need the sign of the author ( > http://www.pharo-project.org/license) > >> > >> Would you mind to send it ? > >> > >> Thank you very much. > >> > >> Mariano > >> > > > > Since you're about to take code from an MIT licensed repository this is > > superfluous. > > > > > > Levente > > > > I second this. Please take the code from trunk without asking. > If Levente ever had to sign an agreement, it should only apply to code > commited by Levente to a Pharo repository... > ...unless you request that each code commited by Levente anywhere > anytime be MIT ;) > > Nicolas > > > _______________________________________________ > > 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. 25, 2009

[Pharo-project] 1695 ready to integrate

by Mariano Martinez Peck

http://code.google.com/p/pharo/issues/detail?id=1695 Commited in PharoInbox: Name: SLICE-issue1695-PruneSearchInMonticello-MarianoMartinezPeck.2 Author: MarianoMartinezPeck Time: 25 December 2009, 11:12:33 pm UUID: cb9c068d-bc33-40b0-8ede-c2891cc99c2d Ancestors: SLICE-issue1695-PruneSearchInMonticello-MarianoMartinezPeck.1 Dependencies: Monticello-MarianoMartinezPeck.411 - prune search in MCFilteredVersionSorter >From squeak trunk: Name: Monticello-bf.341 Author: bf Time: 19 December 2009, 5:49:47 am UUID: ab5017e8-0082-4570-b6cb-1d678262ccfe Ancestors: Monticello-gsa.340 - prune search in MCFilteredVersionSorter

Dec. 25, 2009