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

[Pharo-project] next list of integration ready items
by stephane ducasse Aug. 1, 2010

Aug. 1, 2010

1 0

[Pharo-project] How to remove Monticello?
by Hilaire Fernandes Aug. 1, 2010

Aug. 1, 2010

Dear all, I tried this: (MCPackage named: 'MonticelloGUI') unload. (MCPackage named: 'MonticelloConfiguration') unload. (MCPackage named: 'Monticello') unload. but the third line did not work. Any experiences to share on that topic? Thanks Hilaire

1 1

[Pharo-project] Make PackageOrganizer>>packageOfClass:ifNone: and PackageOrganizer>>packageOfMethod:ifNone: return the most specific package it can find
by StÃ©phane Ducasse Aug. 1, 2010

Aug. 1, 2010

Hi I like the suggestion of daniel in Make PackageOrganizer>>packageOfClass:ifNone: and PackageOrganizer>>packageOfMethod:ifNone: return the most specific package it can find http://code.google.com/p/pharo/issues/detail?id=1752 Now I would like to have another pair of eyes on it. This is related to my idea of non overlapping package. Stef Fixed in: http://www.squeaksource.com/PharoInbox/PackageInfo-DanieRoux.35.mcz Took the fix from, and deprecated #mostSpecificPackageOfMethod:ifNone: and #mostSpecificPackageOfClass:ifNone: Background of problem: In theory it should not be possible for packages to overlap. Every class, and every method should belong to only one Category. In reality packaging bugs and other actions does cause packages to be created that overlap. An example in PharoCore, 10505 is this: (PackageOrganizer default packageNamed: 'Collections' ifAbsent: [ self error: 'hmm']) includesClass: Text. " true " (PackageOrganizer default packageNamed: 'Collections-Text' ifAbsent: [ self error: 'hmm']) includesClass: Text. " also true! " In the old implementation, #packageOfClass: would have returned the first category that matches. It will now return the more specific 'Collections-Text'. I suggest that #mostSpecificPackageOfClass* and #mostSpecificPackageOfMethod* methods be removed?

1 0

[Pharo-project] CogVM as official Pharo VM?
by Mariano Martinez Peck Aug. 1, 2010

Aug. 1, 2010

Hi folks. Hope Eliot is reading this thread. It is time to think in Pharo 1.2 and we need to discuss if we want to have CogVM as the standard Pharo VM. Most of us have tried it and found it incredible fast. So it would be very good to take advantage of it. But I think there are a couple of things to be discussed: 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes: "The Cog VM is a just-in-time compiler that currently supports only x86 No effort has been made to maintain 64-bit compatibility. Apologies, this was unaffordable." So...how much important is this for us? do we care? and if we want to do it, is it "doable" ? is it less doable than the normal squeak VM ? I really would like to have 64bits VM + 64bits images in a near future...but hat's just my thoguhts. 2) The status of the external plugins. Are they working with Cog ? Not only the "core plugings" but FFI, OSProcess (I read some problems with it), TrueType, etc... 3) Is it stable for production use? For example, I read that with seaside there are some crashes. 4) Depends on heroes. I never liked this idea. It has nothing to do with Eliot. He is very cool and helpful. But I wonder, do we understand the new VM and the changes? are we able to handle and fix it even without eliot ? 5) Integration to VMMaker. I saw that they started to merge cog (actually, I think only stack vm?) to the trunk of VMMaker. This is really good news. I hope everything is there and merged. 6) Binaries. It seems the official released didn't come with binaries. So we should compile it for each OS. Ok..that's all my thoughts. I would really like to have a discussion here and see what to do.....grrrrrr you are all in holidays, aren't you? hahah cheers Mariano

9 15

[Pharo-project] More on autotest
by Alexandre Bergel Aug. 1, 2010

Aug. 1, 2010

Hi Laurent! One thing with autotest. When I compile a method, even though it is not covered by the tests, the tests are run again. This does not always make sense I feel since it slow down the way I code... For example, when I am defining a meta-model, then running the test each time I add some business method it makes sense. However, when I define a mondrian visualization, all #visualize have to be excluded by autotest. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1