- Pharo-dev - lists.pharo.org

[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

[Pharo-project] is pharo ready for production?
by Esteban Lorenzano Sept. 16, 2008

Sept. 16, 2008

Hi, I'm planning to start a new commercial, seaside based project in a few weeks, and I wish to start it in Pharo, but I'm afraid is not very stable yet... Can somebody tell me if is usable right now and if not, more or less when it will be? Thanks, Esteban

3 4

[Pharo-project] [ANN] update 10072
by Marcus Denker Sept. 16, 2008

Sept. 16, 2008

update10072 ----------- -> Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej -> Issue 174: XMLSupport can't be loaded into latest Pharo image -> Issue 52: 7102 ObjectPerformOrSendToFix (M1666) -> Issue 106: 7090 DSAunimplementedCleanup -> Issue 77: 7127 RemoveMappedCollection -> More ifNil: refactorings -> replace all occurrances of "isNil not" with "notNil" -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

5 12

[Pharo-project] Throwing out the windowing support from core VM features
by Igor Stasenko Sept. 16, 2008

Sept. 16, 2008

Hello, i'd like to discuss with you this quite radical idea. I , in particular, not happy that windowing in squeak VM is mandatory. Sure, you can run VM with -headless (or whatever), but this actually not solving anything, since VM still in much of control, how to deal with squeak window and how to manage messages etc. What i would like to see, is to completely detach windowing functionality into a separate VM plugin, making sure that: a) VM can be built w/o this plugin b) a language side is in total control to decide whether create and use window & display or not. This would require to deprecate some of 'blue book' primitives, which coming as built-in VM features , such as: - displayBits & friends - fullDisplayUpdate - keyboard & mouse event handling The point is, that squeak grew out on many platforms and embedded devices. Some of them don't have a usual input devices, like keyboard & mouse, so it is completely pointless to require VM to support I/O with these devices as mandatory option. Same for display. I would be happy to have full control at language side whether i need display or not , instead of having it 'for free' from a start and then using workarounds to not show/use it using command line (while language side still thinks its present). -- Best regards, Igor Stasenko AKA sig.

5 16

[Pharo-project] Thinking about Pharo distribution
by Damien Cassou Sept. 16, 2008

Sept. 16, 2008

Hi, I've just started writing a wiki page which details the packages we plan to install in all Pharo distributions. In the Universe, the meta-package 'Pharo packages' permit easy installation of these packages. The wiki page is at: http://code.google.com/p/pharo/wiki/Packages. Please tell me what you think -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

6 15