November 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: MouseOverHandler

by Hernan Wilkinson

Hi Adrian, the current implementation has problems, ie. send messages to nil, and it bothers a lot when that happens because it comes from nowhere... I've been using this implementation for a long time in my images and I did not get those problems anymore (and it is more readable...) On Sat, Oct 31, 2009 at 2:41 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Hernan, > > The reason this was not integrated is that nobody marked it as 'fixed' > nor tagged it as 1.0. > > Is this critical for 1.0? > > Cheers, > Adrian > > BTW, if anybody sees changes/fixes not being integrated please ask on > the mailing list. > > > On Oct 31, 2009, at 14:29 , StÃ©phane Ducasse wrote: > > > > > > > Begin forwarded message: > > > >> From: Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > >> Date: October 29, 2009 2:02:32 PM GMT+01:00 > >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> Subject: MouseOverHandler > >> > >> Hi Stef, > >> do you know why the MouseOverHandler version I made is not in the > >> main image? the current version is not working well, under heavy > >> use it generates exceptions... > >> I'm attaching the version I wrote that I'm using without problem... > >> > >> Hernan. > > <MouseOverHandler.st> > > > > _______________________________________________ > > 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 >

Nov. 2, 2009

Re: [Pharo-project] http://www.pharo-project.org/ seems to be down

by Adrian Lienhard

We had a scheduled maintenance downtime of 1h last night. Adrian On Nov 2, 2009, at 00:23 , Mariano Martinez Peck wrote: > http://downforeveryoneorjustme.com/http://www.pharo-project.org/ > > best, > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 2, 2009

Re: [Pharo-project] RB now supports code formatting ;)

by Schwab,Wilhelm K

This is great news!! When will it appear in the downloadable Pharo images? Many thanks!!! Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Monday, November 02, 2009 12:02 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] RB now supports code formatting ;) cool! and thanks for your time. I like that we move. Stef >> Apparently lukas ported some new code from john (thanks john) that >> supports keeping code formatting.... cool thanks both. > > That new code is actually very old. The code we had up to now was from > 1998, the code I ported and integrated this weekend is from 2002. We > finally made it to the next century :-) > > The changes I integrated from John Brant: > > - Renaming classes, renaming methods, inlining and extracting code > does not necessarily reformat the code anymore. In some complicated > situations it still does, but for most common cases this should give > much better results. > > - Also there is a configurable formatter that allows users to > customize how the code is formatted, in the cases where this > necessary. > > The changes I implemented myself: > > - The refactoring browser now has a first-class representation of > pragmas. > > - Improved the parser to be able to read the complete standard image. > > - Added new tests and fixed many old tests. > > - And many other things I forgot ... > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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

Nov. 2, 2009

Re: [Pharo-project] RB now supports code formatting ;)

by HernÃ¡n Morales Durand

Hi Lukas, thanks for this update, I will take a look. Cheers, HernÃ¡n 2009/11/2 Lukas Renggli <renggli(a)gmail.com> > > Apparently lukas ported some new code from john (thanks john) > > that supports keeping code formatting.... cool thanks both. > > That new code is actually very old. The code we had up to now was from > 1998, the code I ported and integrated this weekend is from 2002. We > finally made it to the next century :-) > > The changes I integrated from John Brant: > > - Renaming classes, renaming methods, inlining and extracting code > does not necessarily reformat the code anymore. In some complicated > situations it still does, but for most common cases this should give > much better results. > > - Also there is a configurable formatter that allows users to > customize how the code is formatted, in the cases where this > necessary. > > The changes I implemented myself: > > - The refactoring browser now has a first-class representation of pragmas. > > - Improved the parser to be able to read the complete standard image. > > - Added new tests and fixed many old tests. > > - And many other things I forgot ... > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 2, 2009

[Pharo-project] Problem with low-space watcher

by Gary Chambers

Project interruptName: labelString preemptedProcess: theInterruptedProcess sends #offList to the return value of suspend of the preempted process (which answers a LinkedList). The message is not understood but does not cause a debugger to open, Alt-. shows the stack trace in the end. One way to replicate: (Object allSubInstances select: [:o | o dependents notEmpty]) collect: [:o | o dependents size] Was just mulling things in light of Announcement discussions as to whether the dependency could have a single subscriber (most common case) for possible performance gains, a collection if additonal subscribers get added. Regards, Gary

Nov. 2, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Lukas Renggli

>>> I implemented a new announcer, which covers all functionality of the >>> original one >>> (all tests is green) but in addition enables you to subscribe directly via >>> #subscribe: >>> and receive #handle: message in case of announcements. >>> Of course, the decision whether to handle or ignore announcement is up >>> to subscriber. >> >> Can you give an example? I don't get it. > > you can subscribe using: > > announcer subscribe: object. > > and unsubscribe using: > > announcer unsubscribe: object. Ok, now I get it. I wonder why this would be useful? Also it looks to me like very bad programming style, as the specification of what to handle and the handler itself are merged. You can do that also with the original API, but it is less encouraging because you have to hand in twice the same object into #on:do:. Also, have a look at the Exception API. Announcements solve a similar problem and provide a similar API. It would be a pity to break that similarity. I've never seen a single project that extended the exception API, there the simple message #on:do: is enough for everybody. > Please, can you elaborate, what you consider 'broken features' and why? > I am also not a fan of using flawed stuff. Weak objects are flawed in Pharo and Squeak. If you have an unbounded number of weak references it can quickly happen that the system spends 95% or more of the CPU cleaning up the weak references. For Seaside 2.8 we spent quite some time in getting rid of all weak references, afterwards we had a cleaner, easier to understand and much faster solution. > That's why i talking about limitations of weak block subscriptions. > While weak message subscriptions is easy to provide, using > WeakMessageSend. I guess you could copy the BlockClosure, no? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 2, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

2009/11/2 Lukas Renggli <renggli(a)gmail.com>: > On Monday, November 2, 2009, Igor Stasenko <siguctua(a)gmail.com> wrote: >> 2009/11/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> >>>> Oh yeah, i seen that code, and Dependents class var in Object class, >>>> which is a dictionary of dictionaries... >>>> This model, as well as morphic extensions, takes roots from Self's >>>> morphic, where you can easily extend >>>> any object state by adding new slots to it. In smalltalk we don't have >>>> dynamic named slots, and thus we >>>> having such ugly crutches :) >>> >>> >>> No it was before that. >>> It was because any object could have a dependent (even if model was >>> favored) >>> so for object the registration was stored in a large table. >>> >>>>> I hope we don't replicate this scheme, I had understood Announcements >>>>> did not thanks to explicit subscription. >>>>> Anyway, a bit of archeology is always helpfull when cleaning >>>>> Smalltalk... >>>>> >>>> >>>> It is strange, i have a feeling that people think i am being >>>> short-sighted or don't understand things, >>>> while i'm trying to show the potentional bottlenecks of Announcements >>>> framework itself... >>> >>> no continue I like to see arguments. >>> Before consensus arise I like discussions because even lukas can be >>> wrong ;D >>> >> >> I implemented a new announcer, which covers all functionality of the >> original one >> (all tests is green) but in addition enables you to subscribe directly via >> #subscribe: >> and receive #handle: message in case of announcements. >> Of course, the decision whether to handle or ignore announcement is up >> to subscriber. > > Can you give an example? I don't get it. you can subscribe using: announcer subscribe: object. and unsubscribe using: announcer unsubscribe: object. the argument 'object' should be responsible for implementing #handle: message which will receive all announcements from announcer, unfiltered. The rest of Announcer protocol (used by Announcements framework) built on top of it, as a superset. > >> Next thing, which i tried to do is to add weak subscriptions. > > That's cool, however I would never use (or even provide) functionality > depending on broken features. Please, can you elaborate, what you consider 'broken features' and why? I am also not a fan of using flawed stuff. That's why i talking about limitations of weak block subscriptions. While weak message subscriptions is easy to provide, using WeakMessageSend. > One can easily kill images with weak > references on arbitrary objects like subscribers. > true, as well as zillion other ways how you can shoot yourself in own foot. Nobody forcing one to use weak subscriptions, right? And if he does, its his own responsibility to make sure it working ok, not mine. >> The syntax, i suggest is simple. As usual, for strong subscription you writing: >> >> announcer on: Announce do: [:ann | ... Â ]. >> (or any other message pattern) >> >> and for weak ones you writing: >> >> announcer weak on: Announce do: [:ann | ... Â ]. >> >> so, difference is in #weak keyword standing between announcer and >> subscription message. >> I think this is short and elegant, and doesn't forcing developer to >> learn or use different messages to subscribe >> weakly. >> >> The most powerful thing with weak subscriptions is, that we don't care >> about unsubscribing - the framework >> will automatically wipe the subscription entry, once subscriber becomes garbage. >> >> But there is a problem with an implementation of block based >> subscriptions (such as #on:do:). >> since, in block-based subscriptions, the real subscriber is a block >> receiver (a 'self' in block's home context) but not a block itself. >> >> So, we need to reference the block subscription strongly only if >> receiver of block is reachable by other means (not via subscription >> itself). >> The only way how we could do that withotut much hassle is to use ephemerons, but >> unfortunately, Squeak VM doesn't supports ephemerons, so support of >> weak block-based subscriptions is not possible without ugly hacks , >> like getting inside a block closure and patch its home context state >> (to get rid of receiver reference).. which is quite awful and error >> prone.. :( >> >> >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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.

Nov. 2, 2009

Re: [Pharo-project] RB now supports code formatting ;)

by StÃ©phane Ducasse

cool! and thanks for your time. I like that we move. Stef >> Apparently lukas ported some new code from john (thanks john) >> that supports keeping code formatting.... cool thanks both. > > That new code is actually very old. The code we had up to now was from > 1998, the code I ported and integrated this weekend is from 2002. We > finally made it to the next century :-) > > The changes I integrated from John Brant: > > - Renaming classes, renaming methods, inlining and extracting code > does not necessarily reformat the code anymore. In some complicated > situations it still does, but for most common cases this should give > much better results. > > - Also there is a configurable formatter that allows users to > customize how the code is formatted, in the cases where this > necessary. > > The changes I implemented myself: > > - The refactoring browser now has a first-class representation of > pragmas. > > - Improved the parser to be able to read the complete standard image. > > - Added new tests and fixed many old tests. > > - And many other things I forgot ... > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 2, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Lukas Renggli

On Monday, November 2, 2009, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2009/11/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>> Oh yeah, i seen that code, and Dependents class var in Object class, >>> which is a dictionary of dictionaries... >>> This model, as well as morphic extensions, takes roots from Self's >>> morphic, where you can easily extend >>> any object state by adding new slots to it. In smalltalk we don't have >>> dynamic named slots, and thus we >>> having such ugly crutches :) >> >> >> No it was before that. >> It was because any object could have a dependent (even if model was >> favored) >> so for object the registration was stored in a large table. >> >>>> I hope we don't replicate this scheme, I had understood Announcements >>>> did not thanks to explicit subscription. >>>> Anyway, a bit of archeology is always helpfull when cleaning >>>> Smalltalk... >>>> >>> >>> It is strange, i have a feeling that people think i am being >>> short-sighted or don't understand things, >>> while i'm trying to show the potentional bottlenecks of Announcements >>> framework itself... >> >> no continue I like to see arguments. >> Before consensus arise I like discussions because even lukas can be >> wrong ;D >> > > I implemented a new announcer, which covers all functionality of the > original one > (all tests is green) but in addition enables you to subscribe directly via > #subscribe: > and receive #handle: message in case of announcements. > Of course, the decision whether to handle or ignore announcement is up > to subscriber. Can you give an example? I don't get it. > Next thing, which i tried to do is to add weak subscriptions. That's cool, however I would never use (or even provide) functionality depending on broken features. One can easily kill images with weak references on arbitrary objects like subscribers. > The syntax, i suggest is simple. As usual, for strong subscription you writing: > > announcer on: Announce do: [:ann | ... Â ]. > (or any other message pattern) > > and for weak ones you writing: > > announcer weak on: Announce do: [:ann | ... Â ]. > > so, difference is in #weak keyword standing between announcer and > subscription message. > I think this is short and elegant, and doesn't forcing developer to > learn or use different messages to subscribe > weakly. > > The most powerful thing with weak subscriptions is, that we don't care > about unsubscribing - the framework > will automatically wipe the subscription entry, once subscriber becomes garbage. > > But there is a problem with an implementation of block based > subscriptions (such as #on:do:). > since, in block-based subscriptions, the real subscriber is a block > receiver (a 'self' in block's home context) but not a block itself. > > So, we need to reference the block subscription strongly only if > receiver of block is reachable by other means (not via subscription > itself). > The only way how we could do that withotut much hassle is to use ephemerons, but > unfortunately, Squeak VM doesn't supports ephemerons, so support of > weak block-based subscriptions is not possible without ugly hacks , > like getting inside a block closure and patch its home context state > (to get rid of receiver reference).. which is quite awful and error > prone.. :( > > >> _______________________________________________ >> 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 2, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

2009/11/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >> Oh yeah, i seen that code, and Dependents class var in Object class, >> which is a dictionary of dictionaries... >> This model, as well as morphic extensions, takes roots from Self's >> morphic, where you can easily extend >> any object state by adding new slots to it. In smalltalk we don't have >> dynamic named slots, and thus we >> having such ugly crutches :) > > > No it was before that. > It was because any object could have a dependent (even if model was > favored) > so for object the registration was stored in a large table. > >>> I hope we don't replicate this scheme, I had understood Announcements >>> did not thanks to explicit subscription. >>> Anyway, a bit of archeology is always helpfull when cleaning >>> Smalltalk... >>> >> >> It is strange, i have a feeling that people think i am being >> short-sighted or don't understand things, >> while i'm trying to show the potentional bottlenecks of Announcements >> framework itself... > > no continue I like to see arguments. > Before consensus arise I like discussions because even lukas can be > wrong ;D > I implemented a new announcer, which covers all functionality of the original one (all tests is green) but in addition enables you to subscribe directly via #subscribe: and receive #handle: message in case of announcements. Of course, the decision whether to handle or ignore announcement is up to subscriber. Next thing, which i tried to do is to add weak subscriptions. The syntax, i suggest is simple. As usual, for strong subscription you writing: announcer on: Announce do: [:ann | ... ]. (or any other message pattern) and for weak ones you writing: announcer weak on: Announce do: [:ann | ... ]. so, difference is in #weak keyword standing between announcer and subscription message. I think this is short and elegant, and doesn't forcing developer to learn or use different messages to subscribe weakly. The most powerful thing with weak subscriptions is, that we don't care about unsubscribing - the framework will automatically wipe the subscription entry, once subscriber becomes garbage. But there is a problem with an implementation of block based subscriptions (such as #on:do:). since, in block-based subscriptions, the real subscriber is a block receiver (a 'self' in block's home context) but not a block itself. So, we need to reference the block subscription strongly only if receiver of block is reachable by other means (not via subscription itself). The only way how we could do that withotut much hassle is to use ephemerons, but unfortunately, Squeak VM doesn't supports ephemerons, so support of weak block-based subscriptions is not possible without ugly hacks , like getting inside a block closure and patch its home context state (to get rid of receiver reference).. which is quite awful and error prone.. :( > _______________________________________________ > 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.

Nov. 2, 2009