- Pharo-dev - lists.pharo.org

[Pharo-project] iphone squeak vm 1.05b4

by John M McIntosh

I've push out the source code and placed a 1.05b4 iPhone VM on my ftp site. This VM includes a fix to ensure equalTo: uses the correct Objective-C method so that all the SUnit tests now pass when running it via the ObjectiveCPlugin.bundle under OS-X, or within the iPhone VM. I note the 1.0.5b3 and 1.0.5b4 VMs use a different squeak image that includes an VNC server, this allows you to interact with the VM from a VM client and have full keyboard/mouse control within the image from your VNC client.

Oct. 3, 2008

Re: [Pharo-project] History and SUnit

by Keith Hodges

StÃ©phane Ducasse wrote: > 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 1. The old suite building code was a mess and had lots of duplication for very little functionality. Here we get much more for less code. For the rest, I suggest looking at the feature set backwards, start with the basic uber-use case* and see what features are needed to support it. * I implemented much of this for my own project in st/x 10 years ago, and have missed it ever since. 2. Use Case: Be able to run... "All tests or specifications for my project which are expected to run on this platform, this image version, and this vm... with the ability to mark tests as 'expected failures', 'to do' , 'slow', 'long', 'uses network' etc, and then be able to run a suite with or without the marked tests. btw: The next refactoring is to remove the whole notion of expectedFailures from TestResult and further simplify things. I asked on squeak-dev over a year ago to ascertain whether there are any users of this confusing feature, and I don't think there are any. Keith

Oct. 3, 2008

[Pharo-project] [update] 10086

by Marcus Denker

Issue 214: [enh] executeMethod via primitives - moves the *executeMethod: method to protoObject - uncomments the commented primitive for faster execution Issue 211: undeclared fix for 10084 - fixes one remaining reference to CurrentProjectRefactoring Issue 210: [ENH] CompiledMethod explorer Issue 206: [ENH] simplify unreferencedInstanceVariables, allUnreferencedInstanceVariables - add test for and simplify Behavor>>#whichSelectorsAccess: - simplify Behavior>>#unreferencedInstanceVariables - simplify and remove #isDoIt check from Behavior>>#allUnreferencedInstanceVariables Issue 196: remove #hash from Association Issue 212: random cleans - KillNewWorld: remove class NewWorldWindow - InspectorTileRemove: remove the menus from inspector for tiles - delPlayerSurrogate.1: remove class PlayerSurrogate - CleanExplanation: remove more code related to the "explain" functionality - UnsentMessages: remove some unsent messages Postscript: Vocabulary allStandardVocabularies removeKey: #unknown. PartsBin allInstances do: [:pb| pb submorphs do: [:sm| (sm target name=#AnObsoleteGeeMailMorph) ifTrue: [ pb removeMorph: sm ]]]. Preferences removePreference: #thoroughSenders. Preferences removePreference: #dragNDropWithAnimation. Set rehashAllSets. -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 3, 2008

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

by bryce＠kampjes.demon.co.uk

Igor Stasenko writes: > Bryce, are you plan to build a windoze VM as well? Eventually, or ask for one to be built, and I'll need a Mac VM as well. But I've neither a Windows or Mac build environment here, and it could be a while before I set them up. If you've got the build environment you used for the FreeType VM then just load the latest VMMaker package from the Exupery project on SqueakSource and rebuild. If you build it, then we'll have it now. Oh, and how hard was it getting the FreeType libraries installed on Windows? Bryce

Oct. 3, 2008

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