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

[Pharo-project] More menu cleanup
by Adrian Lienhard Sept. 20, 2008

Sept. 20, 2008

Here is a changeset that cleans up and restructures the code context menu. In the process of removing stuff I also removed around 30 methods, some of which were huge (ever seen the implementation of the "explain" functionality?). Cheers, Adrian BTW: After loading the changeset save and restart to get all icons in the menu. ___________________ http://www.adrian-lienhard.ch/

2 2

Fwd: [Pharo-project] [ANN] first one-click image
by David Mitchell Sept. 19, 2008

Sept. 19, 2008

(Forgot to copy the list) Yep, that fixed them all after I did a Load code updates. Did have one new error in testPrinting: self assert: nonSEarray2 printString = 'an Array(#Array)' But I have to say, I have never experienced a Squeak release where there was only one test error. (Of course, before the test runner was integrated, there were no errors, but that doesn't count!) Great work everyone. On Fri, Sep 19, 2008 at 11:06 AM, Marcus Denker <denker(a)iam.unibe.ch> wrote: > > On 19.09.2008, at 17:31, Norbert Hartl wrote: >>> >>> >> No need to. None of these seem to fail in 10073. The one-click is >> based on 10072. > > Sorry for that... I will do a new release soon. > > Marcus > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > >

2 1

[Pharo-project] Image size
by Norbert Hartl Sept. 19, 2008

Sept. 19, 2008

Hi, I have problems in understanding the image size of pharo. I monitored it since we started and I did not recognize a notably change. So I took a pharo 10073 and squeak 3.10.2 for comparsion. Amount classes, amount methods and lines of code are all 10% less in pharo. But the image is approx. 0,5% - 1% smaller than the squeak one. To clarify this. I closed all windows and did condenseChanges and garbageCollect, flushed the monticello cache... What could be the reason for this? thanks, Norbert

4 10

[Pharo-project] [ANN] update 10073
by Marcus Denker Sept. 19, 2008

Sept. 19, 2008

update 10073 ------------ - Issue 44: 7094 FixClassCompatibilityForClassVar (M6472) - Issue 86: 7138 TransformationMorph-isSticky - Issue 89: 7141 PrintingArraysWithMetaclasses - Issue 42: 7092 TTCFontDNUfix (M5309) - Issue 176:failing tests in 70072 - delete ParagraphEditor>>#initializeTextEditorMenus (never called, has undeclared) - revert Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej (broke tests) - MorphExtension now stores properties in SmallIdentityDictionary. - in loadscript: Smalltalk associations do: [:each | each beReadWriteBindingAnnouncing: true] Because it recompiles all methods multiple times, the update takes a while to load. (this is to be able to remove ReadOnlyVariableBinding, which has never seen any use) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

3 7

[Pharo-project] CS in pharo
by StÃ©phane Ducasse Sept. 19, 2008

Sept. 19, 2008

> We have two important fixes: compiler fixes and trait that are in > Changesets or cannot be loaded (in the case of the compiler > with MC). > I suggest for now to add them as changesets > Then we should keep the Compiler package to evaluate if MC1.6 can > be used. > I asked matthew to see if he can load the package. > > I still believe that having atomic loading in pharo is important. > > > > Stef > > >> Issue 167: Please check the traits fixes >> http://code.google.com/p/pharo/issues/detail?id=167 >> >> Comment #2 by adrian.lienhard: >> additionally remove caching of marker methods and make condensing >> work >> looks good now >> >> how do we integrate this since it is a changeset? >> >> Attachments: >> TraitsSharingCM-3.cs 14.6 KB > > > > > > >

3 6

[Pharo-project] 10073 error
by StÃ©phane Ducasse Sept. 19, 2008

Sept. 19, 2008

Hi I took 10072 and pressed update. After 10 or 15 min I got DoIt ^ server aborted early So may be the server stopped in the middle. Stef

2 3

[Pharo-project] Non-pharo reports in pharo bugtracker...
by Marcus Denker Sept. 18, 2008

Sept. 18, 2008

Hi, There are reports in the pharo tracker that are not solvable because the software the bug is reported about is not part of pharo. I wonder if that makes sense... from the bug-fixing of Squeak, I have found that it's very important to keep the numner of open issues as small as possible. (the nearly 1000 open reports they gatheres when doing 3.10 in Squeak is completely unmanagable, for example). I would suggest to put these reports on a wiki page, instead of the bugstracker. Or report them to the developers of the package. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

4 6

[Pharo-project] Bugs on bugs.squeak.org
by Marcus Denker Sept. 18, 2008

Sept. 18, 2008

Hi, bugs.squeak.org is a mess. (and people wonder why I always stress that doing harvesting was a lot of work... we got the tracker down to 250 entries with 3.9, if I remember correctly). Even for 3.11, they will have some real work ahead to get this in some form of managable shape. Now for Pharo, I don't see that we can benefit from the bug-tracker at all anymore: there is so much stuff, no way to do here anything in a strategic, "all covering" way, as we did for example when moving from BFAV to Mantis. So if someone has reported a bug against Squeak, the only way I see this change ending up in pharo is that the bug is reported again on the pharo tracker. So if you want something to be fixed: http://code.google.com/p/pharo/issues/list (down to 79 open issues, we already fixed and closed 96 reports) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

2 1

[Pharo-project] Re: Monticello 1.5
by Hilaire Fernandes Sept. 17, 2008

Sept. 17, 2008

Oh, Chris I am just a dumb developer and I don't know much about the tools, I just know it is a pain to get MC 1.5 working. I am cc to Pharo firends with a small recall of the situation, may be they have some tips Chris is working on new beta version of Magma which I am testing with him. As far as I can understand, Chris use Monticello configuration to be able to load in one click several Magma mcz packages. This requires Monticello 1.5, but this ones does not work equally on the different version of Squeak nor with Pharo. Which tools could be suggested to Chris ? (I can give more details if needed but really this is becoming insane --and unproductive--, and I really hope Pharo people will do it right) Hilaire 2008/6/27 Chris Muller <ma.chris.m(a)gmail.com>: > Well of course I am always open to suggestions. Everyone knows what > the requirement is: one-click loading of an entire (multi-package) > system. Do you know another way I can accomplish this other than > Monticello? What is everyone else doing? > > > > > > On Thu, Jun 26, 2008 at 3:09 PM, Hilaire Fernandes <hilaire(a)ofset.org> wrote: >> Chris, >> >> As MC seems to be a source of frustration, I am wondering why do you >> need it for the beta release of Magma? >> >> Now I really think I want to move in the future to Pharo as the >> development plans are clearer (https://gforge.inria.fr/projects/pharo) >> Yet Seasider are participating to Pharo so I am confident. >> >> I will first try Magma beta and my code as well. >> >> Hilaire >> >> >> -- >> http://blog.ofset.org/hilaire >> > -- http://blog.ofset.org/hilaire

10 27

[Pharo-project] Call for ideas for a Continuous Integration server
by Alexandre Bergel Sept. 16, 2008

Sept. 16, 2008

Dear List, Here are the notes I took on AmbientTalk. In Ambientalk: Table: >def table[5] { z := z + 1 } >>[1, 2, 3, 4, 5] Table splicing: >[1,@[2,3],4] >>[1, 2, 3, 4] >def [first, @rest] := [1,2,3,4] >>[1, 2, 3, 4] >rest >>[2, 3, 4] Function >def square (x) { x*x } >>nil >square(5) >>25 There is no check about fulfilling required methods. There is a way to declare a method as required. Required method are part of a structural type. Reflection is then used to ensure that a composition makes sense at composition time. Aliasing changes the name on the surface (it is not a rename), and does not create a new entry. The import clause (which is used to use a trait), may accept any expression, and not only a trait name. There is no precedence of the locally defined methods. Note that traits are composed when object composer are instantiated. Ambientalk may use the same trick than in Smalltalk to declare a method as required (self requiredMethod), but the lack of precedency is problematic. The fact that you do not have precedency, implies that a method used in a trait needs to be specify as required (using the reflective trick mentioned above) in case of the composer is likely to not provide an implementation for this method. Else, better is not mark the used method as required since the composer will have to exclude it when using the trait. Two methods that are acquired using different import path are not conflicting since they are the same compiled method. In Ambientalk, this will always cause a conflict since methods are âduplicatedâ between composers. In Ambientalk, deep equality (i.e., comparing bytecode instructions) may not lead to what we want since methods can be nested. The Morphic framework. Inspired from the Self version and has been influenced by John Maloneyâs work. Requirement between traits is specified with for exemple require: [Trait1, Trait2], in that case, all public methods defined in Trait1 and Trait2 will be set as required method for the trait that made the require. This framework is composed of 18 traits -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1