October 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Linux VM with FreeType and closure bytecodes

by Igor Stasenko

Bryce, are you plan to build a windoze VM as well? 2008/10/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > tx bryce > > Stef > > On Oct 3, 2008, at 9:32 PM, <bryce(a)kampjes.demon.co.uk> > <bryce(a)kampjes.demon.co.uk> wrote: > >> >> http://ftp.squeak.org/Exupery/vms/pharo-vm.tz >> >> It's got both FreeType and Eliot's closure bytecodes. It's fully >> compatable with normal VMs. It can also run the latest Exupery from >> SqueakSource. You could use this VM to run Squeak 3.10, just for >> the sub-pixel anti-aliasing. >> >> I'm still working on automating the image building for rebuilding the >> VM. I'd also like to get automake to find the locations of the >> FreeType headers so the VM is more likely to build on other distros >> where the locations may be different. >> >> Bryce >> >> P.S. Please shout when there's an image built which uses the closure >> bytecodes. >> >> _______________________________________________ >> 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.

Oct. 3, 2008

Re: [Pharo-project] Linux VM with FreeType and closure bytecodes

by StÃ©phane Ducasse

tx bryce Stef On Oct 3, 2008, at 9:32 PM, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > wrote: > > http://ftp.squeak.org/Exupery/vms/pharo-vm.tz > > It's got both FreeType and Eliot's closure bytecodes. It's fully > compatable with normal VMs. It can also run the latest Exupery from > SqueakSource. You could use this VM to run Squeak 3.10, just for > the sub-pixel anti-aliasing. > > I'm still working on automating the image building for rebuilding the > VM. I'd also like to get automake to find the locations of the > FreeType headers so the VM is more likely to build on other distros > where the locations may be different. > > Bryce > > P.S. Please shout when there's an image built which uses the closure > bytecodes. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 3, 2008

[Pharo-project] Linux VM with FreeType and closure bytecodes

by bryce＠kampjes.demon.co.uk

http://ftp.squeak.org/Exupery/vms/pharo-vm.tz It's got both FreeType and Eliot's closure bytecodes. It's fully compatable with normal VMs. It can also run the latest Exupery from SqueakSource. You could use this VM to run Squeak 3.10, just for the sub-pixel anti-aliasing. I'm still working on automating the image building for rebuilding the VM. I'd also like to get automake to find the locations of the FreeType headers so the VM is more likely to build on other distros where the locations may be different. Bryce P.S. Please shout when there's an image built which uses the closure bytecodes.

Oct. 3, 2008

Re: [Pharo-project] Save and quit menu

by StÃ©phane Ducasse

mathieu I check and when you do quit and you chose save, it saves. Stef On Oct 3, 2008, at 2:22 PM, Mathieu Suen wrote: > Hi, > > From the latest pharo image the Save and quit menu have disappear. > Is there any reason for removing it. > I always use it so I found annoying to first click quit and then > answer the question... > > Mth > > > > > > > > > > ___________________________________________________________________________Yahoo > ! Mail rÃ©invente le mail ! DÃ©couvrez le nouveau Yahoo! Mail et son > interface rÃ©volutionnaire. > http://fr.mail.yahoo.com > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 3, 2008

Re: [Pharo-project] Fonts related from OLPC / rome also

by StÃ©phane Ducasse

On Oct 3, 2008, at 7:21 PM, Michael Rueger wrote: > StÃ©phane Ducasse wrote: >> I started to go over >> http://tinlizzie.org/updates/etoys/updates >> to see if some of the fixes of yoshiki for unicode and others were >> there. >> Here is a list of names that may be should be further investigated > > I'm going to tackle these today, unless someone else already did? No I'm still fixing my floor :( and I would be quite slow. Thanks for doing that. I browse sophie-dev and I was planning to extract Rome packages. Stef > > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 3, 2008

Re: [Pharo-project] History and SUnit

by StÃ©phane Ducasse

Thanks keith After I really wonder if we need all that. I would be really interested in understanding what are the 20% nost useful features and focus on them. Stef On Oct 3, 2008, at 7:14 PM, Keith Hodges wrote: > The latest SUnit in ss/Testing allows suites and filters (e.g. > #myCustomSuite , #todoFilter ) to be assembled adding and subtracting > TestSuite's (collections or tests) obtained using the following > methods. > > #suiteWithFlagged: "looks for flag: #literal or Pragma: <suite: > #literal>" > #suiteWithMethodCategoryMatching: pattern "for sspec it would be > specs*" > #suiteWithSelectorsMatching: pattern "the default is test*" > > e.g. > > MyTestCaseClass-myCustomSuite > > ^ (self suiteWithSelectorsMatching: 'test*') , ( self > suiteWithFlagged: > #test ) > > The custom suite is published on the class side of your TestCase class > in #publishedSuites ^ #( #allStandardTests #myCustomSuite ) , > likewise > for #publishedFilters. > > The TestRunner allows you to chose a suite, only the classes > included in > the suite are displayed. This finally allows you to define a project > to > work within, and have the UI ignore the other tests. > > The TestRunner also allows you to either reject or select items in the > suite that match the filter. So you could run all of the todoItems > from > mySuite, or all of the non-todo items from mySuite. > > TestCaseVersioned makes extensive use of this. Tests in subclasses can > flag specifically which versions of squeak the test is expected to > work > in, and on which platform. > > This allow you to have some means of flagging pharo specific tests, > i.e. > tests that you would only expect to work in pharo, and tests that you > would only expect to work in squeak. Thus we can still keep an "all > tests green" policy, even though we may have different tests for > different image-kernels. > > As we move to images that may have modules removed, we can add a > mechanism for specifying "tests that only apply if a particular > package > is loaded." > > hope this helps to explain things a bit > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 3, 2008

Re: [Pharo-project] Save and quit menu

by Lukas Renggli

> There is a Save option and a Quit option. +1 -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 3, 2008

Re: [Pharo-project] Fonts related from OLPC / rome also

by Michael Rueger

StÃ©phane Ducasse wrote: > I started to go over > > http://tinlizzie.org/updates/etoys/updates > > to see if some of the fixes of yoshiki for unicode and others were there. > > Here is a list of names that may be should be further investigated I'm going to tackle these today, unless someone else already did? Michael

Oct. 3, 2008

Re: [Pharo-project] History and SUnit

by Keith Hodges

The latest SUnit in ss/Testing allows suites and filters (e.g. #myCustomSuite , #todoFilter ) to be assembled adding and subtracting TestSuite's (collections or tests) obtained using the following methods. #suiteWithFlagged: "looks for flag: #literal or Pragma: <suite: #literal>" #suiteWithMethodCategoryMatching: pattern "for sspec it would be specs*" #suiteWithSelectorsMatching: pattern "the default is test*" e.g. MyTestCaseClass-myCustomSuite ^ (self suiteWithSelectorsMatching: 'test*') , ( self suiteWithFlagged: #test ) The custom suite is published on the class side of your TestCase class in #publishedSuites ^ #( #allStandardTests #myCustomSuite ) , likewise for #publishedFilters. The TestRunner allows you to chose a suite, only the classes included in the suite are displayed. This finally allows you to define a project to work within, and have the UI ignore the other tests. The TestRunner also allows you to either reject or select items in the suite that match the filter. So you could run all of the todoItems from mySuite, or all of the non-todo items from mySuite. TestCaseVersioned makes extensive use of this. Tests in subclasses can flag specifically which versions of squeak the test is expected to work in, and on which platform. This allow you to have some means of flagging pharo specific tests, i.e. tests that you would only expect to work in pharo, and tests that you would only expect to work in squeak. Thus we can still keep an "all tests green" policy, even though we may have different tests for different image-kernels. As we move to images that may have modules removed, we can add a mechanism for specifying "tests that only apply if a particular package is loaded." hope this helps to explain things a bit Keith

Oct. 3, 2008

[Pharo-project] Fwd: Yet another Objective-C bridge

by John M McIntosh

Begin forwarded message: > From: John M McIntosh <jmmcintosh(a)gmail.com> > Date: October 2, 2008 11:50:56 PM PDT (CA) > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > Cc: iSqueak(a)isqueak.org > Subject: Yet another Objective-C bridge > Reply-To: johnmci(a)smalltalkconsulting.com > > As part of my iPhone work I've built yet another Objective-C bridge. > > It can be found within ftp://ftp.smalltalkconsulting.com/experimental/ > The required Smalltalk code for the basic logic, the SUnits, and the > Plugin generation can be loaded from http://www.squeaksource.com/ObjectiveCBridge2.html > The additional pieces required to build the plugin are found within > the iSqueak SVN tree. http://svn.isqueak.org/vm/ > > Using aregular 3.8.18b4U macintosh carbon VM with the > ObjectiveCBridge installed means you can invoke. > > testRetainCount > | classOop instance1 count | > > classOop := ObjectiveCObject findClassName: 'NSObject'. > instance1 := classOop new. > count := instance1 retainCount. > self should: [count = 1]. > instance1 retain. > count := instance1 retainCount. > self should: [count = 2]. > instance1 release. > count := instance1 retainCount. > self should: [count = 1]. > > > People are welcome to confirm that it works, although it is compiled > for ppc and i386 (32bit) I have not yet tested on ppc. > > This plugin was also installed for the currently shipping iPhone VM > 1.05b3, however there seems to be a problem > where resolving the method signature object isEqualTo: for usage > between two instances of NSObject returns nil. > But only on an ipod touch or iPhone not in the Simulator, or running > as an os-x application. > > > >

Oct. 3, 2008