- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Beacon for Pharo 7

by Henrik Sperre Johansen

Guillermo Polito wrote > Announcements have other problems on their own, as we were talking with > Pablo the other day. They are not reentrant (what happens if an > announcement is raised during the treatment of an announcement? Does it > loop?) What? The new event is delivered, of course. If the complaint is "When I write an infinite loop using announcements, it is an infinite loop", I don't know what to tell you... Guillermo Polito wrote > , they block the caller until all announcements are processed (not so > decoupled, huh :P), Avoiding subscribers who take too long to process the subscription, *should* be the responsibility of each subscriber. If you think announcement overhead is bad now, imagine what happens if you fork of a process for every delivery. Depending on priority, you'd still have a problem in that it either in effect will still block the sender, or not be processed at all until sender completes. Also, good luck debugging. Show me *one* other event registration framework in a green-threaded system that hasn't made the same tradeoff, and I'll buy you a beer. Guillermo Polito wrote > right now without looking at the code it's not clear to > me if they can handle the subscription of arbitrary instances instead of > just Announcement (sub)classes (announcer on: arbitraryObject send: ...). The fact you can easily search for users of a given announcement in a standard browser is one of its big advantages compared to the seaside announcements, if you ask me. However, the only hard requirement should be to implement handlesAnnouncement: on whatever is passed to when: (though, there seems to have been a late addition of #prepareForDelivery, which should be handled by announcement initialization, not the delivery mechanism, at least for the use indicated by its comment...). Which still doesn't make it a good idea to implement on arbitrary objects (though it's implemented on Symbol for backwards compatibility with the old event registration mechanism). Guillermo Polito wrote > Not even mentioning the weak/ephemeron mess :). This I can get behind though, the world would be a better place if everyone unregistered their subscriptions properly. ;) (and/or we had a working ephemeron implementation without the same self-referential pitfalls as the weak one) Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

May 28, 2018

[Pharo 7.0-dev] Build #970: 21997 Cleanup Tool-Diff package

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #970 was: SUCCESS. The Pull Request #1441 was integrated: "21997 Cleanup Tool-Diff package" Pull request url: https://github.com/pharo-project/pharo/pull/1441 Issue Url: https://pharo.fogbugz.com/f/cases/21997 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 28, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #969: 21964-SmalltalkImage-transforming-deprecations-for-old-API

by Marcus Denker

Hello, this puts some transformers on method on âSmalltalkImageâ to force people to use âSmalltalk globalsâ when accessing the global environment. For now these methods are in âDeprecated70â, but we will move them to some compatibility package and not actually remove them for some time. This just forces clients to update the code so we can get rid of them eventually. Marcus > On 28 May 2018, at 13:57, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #969 was: SUCCESS. > > The Pull Request #1422 was integrated: "21964-SmalltalkImage-transforming-deprecations-for-old-API" > Pull request url: https://github.com/pharo-project/pharo/pull/1422 > > Issue Url: https://pharo.fogbugz.com/f/cases/21964 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 28, 2018

Re: [Pharo-dev] IMPORTANT: ML Etiquette

by Guillermo Polito

On Mon, May 28, 2018 at 1:40 PM, Tim Mackinnon <tim(a)testit.works> wrote: > In a world of mobile phones, I think you have to accept top posting, itâs > just too hard to work otherwise on a small screen ... that said, quoting a > small piece to reply to - is doable, and I think we can all try to do that? > Nice example of top-posting xD > > Tim > > >

May 28, 2018

[Pharo 7.0-dev] Build #969: 21964-SmalltalkImage-transforming-deprecations-for-old-API

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #969 was: SUCCESS. The Pull Request #1422 was integrated: "21964-SmalltalkImage-transforming-deprecations-for-old-API" Pull request url: https://github.com/pharo-project/pharo/pull/1422 Issue Url: https://pharo.fogbugz.com/f/cases/21964 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 28, 2018

Re: [Pharo-dev] [Compiler] #bindings: improvement: Global shadowing

by Marcus Denker

> > So what can we do with this? If you develop a compiler, it is always very annoying that any change that you do actually breaks the compiler if you do it wrong. Larger changes over multiple methods get quite hard to do. > > One thing that we will soon have is the âaccept for testâ feature that I posted recently. > Another idea is to use the #bindings: feature of the compiler. > > I did small experiment, I added this method to the OpalCompiler class on the class side: > â¦.. > > And after that, you can put a #halt deep in the compiler (or do some change that needs multiple steps), yet compilation will not be affected. > Most tests (not all) are writing in a way that they use classes from the package directly (they do not go via the global #compilerClass setting). > > So this means that one can now change the compiler as much as one wants, test it by running tests and then be quite sure that it will not break anything. > > Shortcomings: > -> extensions are not treated, only the main package > -> Not used much, for sure needs testing to see if this really works. > -> Can we get rid of the #CompilerOverlay global? > I made a pull request: https://github.com/pharo-project/pharo/pull/1449 Marcus

May 28, 2018

Re: [Pharo-dev] IMPORTANT: ML Etiquette

by Tim Mackinnon

In a world of mobile phones, I think you have to accept top posting, itâs just too hard to work otherwise on a small screen ... that said, quoting a small piece to reply to - is doable, and I think we can all try to do that? Tim Sent from my iPhone > On 28 May 2018, at 07:26, Ben Coman <btc(a)openinworld.com> wrote: > > > >> On 28 May 2018 at 11:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> Dear all, >> >> There were several posts in the "Beacon for Pharo 7" thread which top-posted >> on top of massive unsnipped quotes that were several-previous-posts deep. >> IMHO this made the conversation impossible to follow. This issue has cropped >> up from time to time in other threads. >> >> Please adhere to basic ML etiquette [1] to maximize our effectiveness. Two >> essential guidelines are: >> 1) snip quoted material to just what's necessary to understand what's >> being replied to >> 2) Post reply /after/ the quote from the OP, not before. >> >> 1. >> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/etiqu… > > e.g... > > Because it messes up the order in which people normally read text. > >Why is top-posting such a bad thing? > >>The lost context. > >>>What makes top-posted replies harder to read than bottom-posted? > >>>>Yes. > >>>>>Should I trim down the quoted part of an email to which I'm replying? > > http://www.idallen.com/topposting.html > > > Part of the problem is the way gmail and other clients *hide* the original text behind three ellipses dots, > so its not immediately obvious how much a thread has grown. > Its good to make a habit of clicking those dots immediately after clicking <Reply>. > > cheers -ben

May 28, 2018

[Pharo 7.0-dev] Build #968: 21990-isProbablyPrime-and-friends-should-not-refer-to-Transcript

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #968 was: FAILURE. The Pull Request #1435 was integrated: "21990-isProbablyPrime-and-friends-should-not-refer-to-Transcript" Pull request url: https://github.com/pharo-project/pharo/pull/1435 Issue Url: https://pharo.fogbugz.com/f/cases/21990 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 28, 2018

[Pharo 7.0-dev] Build #967: 22001 Cleanup System-Object Events package

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #967 was: FAILURE. The Pull Request #1444 was integrated: "22001 Cleanup System-Object Events package" Pull request url: https://github.com/pharo-project/pharo/pull/1444 Issue Url: https://pharo.fogbugz.com/f/cases/22001 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 28, 2018

Re: [Pharo-dev] [Compiler] #bindings: improvement: Global shadowing

by Marcus Denker

> > Shortcomings: > -> extensions are not treated, only the main package > -> Not used much, for sure needs testing to see if this really works. â> there might be other places in addition global #compilerClass: where we need to point to the overlay version For the complete âcompile a methodâ it works, but I think there are other cases where it is not enough. > -> Can we get rid of the #CompilerOverlay global? > I think it can be a class variable of OpalCompiler, this way we can turn the whole thing into a Setting (if it turns out to be usable) Marcus

May 28, 2018