April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by StÃ©phane Ducasse

tx! and yes we should continue On Apr 3, 2011, at 9:36 AM, Marcus Denker wrote: > > On Apr 3, 2011, at 9:35 AM, Marcus Denker wrote: > >> >> https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip >> > > > .. the all green image of today from Hudson. Yes, this is not repeatable and tomorrow > the hudson one might be different. But we need to move on. 1.1 was build just once, too. > So we can continue to build the perfect fully automatic process for 1.3... > > Next: > -> Make a one-click. > -> Make a cog one-click. > -> push all open reports in the tracker to 1.2.2 > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

April 3, 2011

Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)

by StÃ©phane Ducasse

On Apr 2, 2011, at 9:10 PM, Toon Verwaest wrote: > Hi all, > > as you know I'm working on stateful traits using my new classbuilder no Are you? > etc... Now I noticed that methods are highlighted always inside of the context of the class that's active in the class browser. How can I change this? There is already a useful method around to figure out which object it belongs to: > > SomeClass traitOrClassOfSelector: #aMethod > > This actually will tell me which trait it comes from. So now I could apply syntax coloring in the context of the trait rather than the class. Since in my implementation state is all private to the trait / class, they should be able to access their own state but not see the state of the other class. This obviously also means that coloring should happen in the correct scope, rather than always in the scope of the class. > > At the moment the coloring doesn't really make sense ... but then it didn't really matter that much until now. Although if you try to access state in a method coming from a trait, while coding in your IDE you'll probably have the impression you can access your local instvars. I don't really know what the semantics are there... but it seems a bit broken :) > > cheers, > Toon >

April 3, 2011

Re: [Pharo-project] Participating to a cool project

by StÃ©phane Ducasse

tx hilaire keep pushing. stef On Apr 2, 2011, at 8:55 PM, Hilaire Fernandes wrote: > Dr. Geo (http://www.ofset.org/drgeo) is becoming better release after > release. It is proposed for all three major systems and the XO OLPC > laptop for kid. > > It has been downloaded several thousand of times, it is used in several > place in the world, we even get a TV show only for DrGeo > http://www.youtube.com/watch?v=wdx7vJwPmcA > > Yet it is a neat way to promote Smalltalk as DrGeo scripting feature > expose the user to the Smalltalk language and environment. > Far beyond my expectation, teachers are exploring DrGeo to use it as an > environment to teach programming, see this nice French article: > http://revue.sesamath.net/spip.php?article330 > > I hope more will come. > > If you are interested to participate to a cool project, for coding, > documenting, testing, promoting; come and join, there are many stuff to do: > > * test > * report defects > * translate the user interface of the software > * document and translate the documentation > * design DrGeo courses > * design graphics > * learn from DrGeo design and fix bugs > * learn from DrGeo design and implement new features > > More to read at > http://community.ofset.org/index.php/Community_DrGeo#Participating_to_the_P… > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

April 3, 2011

Re: [Pharo-project] Announcement real problems - please read and comment.

by StÃ©phane Ducasse

> >>> PPS. There's a neat method called #on:send:to:, which would be perfect for the different actions in RPackage-SystemIntegration. >> I'm trying to understand how this on:send:to: would help us. >> Because >> Nautilus registered to system announcer >> Now I do not understand why RPackageOrganizer should not register to systemAnnouncer too. >> And even if we use on:send:to: who can garantee that the on:send:to: will notify first the RPackageOrganizer and >> not that an announcement will reach the browser before. >> >> What was your idea? >> >> Stef > It has nothing to do with registration ordering, but using the proper API. > If you look at the RPackageOrganizer registrations in RPackage-SystemIntegration, all they do in the action block is send self a message. > Instead of: > anAnnouncer > when: SystemCategoryAddedAnnouncement do: [ :ann | self systemCategoryAddedActionFrom: ann ]; > you write: > announcer on: SystemCategoryAddedAnnouncement send: #systemCategoryAddedActionFrom: to: self I do not get what is the difference. Can you explain how this would solve my problem? I was discussing with luc and noury yesterday and we thought about the following: The system should be layered in two layers system (Rename) should emit annoucement to system objects (like RPakcageOrganizer) UI tools should register not to system but to RPackageOrganizer. So this is probably the solution but I'm thinking that in the long turn may be pushing packages inside the system wiuthout annoucement would be better. > It also has the added benefit you can make them weak if you want :) > > Cheers, > Henry > > And ugh, why the Announcement at the end of the Announcement names? :/ Who cares for now we have a system on its knees if one annoucnement breaks so to me this is totally useless. Stef

April 3, 2011

Re: [Pharo-project] Issue 3709 in pharo: Clean OB**WithShout in omnibrowser

by pharo＠googlecode.com

Comment #1 on issue 3709 by renggli: Clean OB**WithShout in omnibrowser http://code.google.com/p/pharo/issues/detail?id=3709 This is pretty much cleaned up in http://source.lukas-renggli.ch/omnibrowser/ and http://source.lukas-renggli.ch/unsorted/.

April 3, 2011

Re: [Pharo-project] Announcement real problems - please read and comment.

by StÃ©phane Ducasse

On Apr 2, 2011, at 5:14 PM, Henrik Sperre Johansen wrote: > On 02.04.2011 09:16, StÃ©phane Ducasse wrote: >> Henrik what is your answer to problem 1 >> >> Problem 1 >> - the second announcement was never sent, because the first one broke the second was blocked. >> >> we should make sure that if an announcement leads to an error, other annoucements on the same emit should pass >> >> Because we can get the system down just because one guy can register a bug. > http://forum.world.st/Another-finalization-concern-error-handling-td2989615… > > It's basically the same. ?? > > Cheers, > Henry >

April 3, 2011

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by Marcus Denker

On Apr 3, 2011, at 10:22 AM, Lukas Renggli wrote: > A pity that broken OB code is used, nevertheless it is quite usable. > Yes, and I added a bug report on March 22: http://code.google.com/p/pharo/issues/detail?id=3842 But nobody cared to react. So how important can it be? There are two possibilities: -> Postponing the release because it's not perfect. (We are doing this for *3 Months* already) -> Not release and wait another 3 Months. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 3, 2011

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by Lukas Renggli

A pity that broken OB code is used, nevertheless it is quite usable. Lukas On 3 April 2011 09:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 3, 2011, at 9:41 AM, Tudor Girba wrote: > >> Excellent! >> >>>> Â Â https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip >>>> >>> >>> >>> .. the all green image of today from Hudson. Yes, this is not repeatable and tomorrow >>> the hudson one might be different. But we need to move on. 1.1 was build just once, too. >> >> Exactly. >> >>> So we can continue to build the perfect fully automatic process for 1.3... >>> >>> Next: >>> Â Â Â -> Make a one-click. >>> Â Â Â -> Make a cog one-click. >>> Â Â Â -> push all open reports in the tracker to 1.2.2 >> >> Why still work on 1.2.2. Why not moving them to 1.3? >> > Yes, you are right... > > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Lukas Renggli www.lukas-renggli.ch

April 3, 2011

Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar

by pharo＠googlecode.com

Comment #8 on issue 3754 by renggli: Omnibrowser's an extra horizontal scrollbar http://code.google.com/p/pharo/issues/detail?id=3754 FYI: I cannot reproduce this problem in Pharo 1.2

April 3, 2011

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by Marcus Denker

On Apr 3, 2011, at 9:41 AM, Tudor Girba wrote: > Excellent! > >>> https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip >>> >> >> >> .. the all green image of today from Hudson. Yes, this is not repeatable and tomorrow >> the hudson one might be different. But we need to move on. 1.1 was build just once, too. > > Exactly. > >> So we can continue to build the perfect fully automatic process for 1.3... >> >> Next: >> -> Make a one-click. >> -> Make a cog one-click. >> -> push all open reports in the tracker to 1.2.2 > > Why still work on 1.2.2. Why not moving them to 1.3? > Yes, you are right... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 3, 2011