July 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] SubscriptionRegistry>>#deliver:

by Thierry Goubier

2015-07-03 11:30 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > > On 02 Jul 2015, at 9:40 , Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Hi Henrik, > > > > Le 02/07/2015 10:49, Henrik Johansen a Ã©crit : > >> > >> > >> The whole thread at > >> > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2012-January/057… > is > >> a good read for insight into the thoughts behind the current > implementation. > >> While some of Lukas' complaints that related to artifacts of the live > >> migration has been resolved, many of the decisions made wrt optimization > >> target/robust delivery are still valid. > > > > Very interesting thread, thanks. > > > >> My thoughts are now as they were then wrt. forking delivery, it makes > >> code both harder to debug, and is (imho) not a good tradeoff between > >> performance/clarity and percieved benefit. > >> I'd rather the handler be responsible for the decision of whether it is > >> heavy enough to be forked off in order to not block other delivery, than > >> enforce it as a default. > > > >> I haven't searched for the related thread, but the fork-on-exception > >> behaviour was eventually argued down to only apply for UnhandledErrors. > >> The ifCurtailed: block is still somewhat useful, it lets you do things > >> like put halts in handlers, and still be certain remaining subscribers > >> are notified if you close the debugger, rather than proceed. > > > > Ok, so the behavior on halt (or an error opened on debugger) is to > suspend all other notifications on that announcer? Including on the main > system announcer? > > The behaviour is the same as when suspending any thread. > If said thread is the only source of announcements, then all notifications > are effectively suspended. There is nothing blocking other threads from > delivering new announcements though. > Unlike UnhandledErrors, a debugger raised responding to a halt will not > have forked off in a separate thread, so you can navigate the entire stack, > inspecting announcement source / other subscribers, etc. > The ifCurtailed: merely ensures that if said process is terminated during > delivery (Say, a debugger is closed instead of proceeded), the remaining > subscribers will be processed before termination actually occurs. > Ok. Then this could mean the following is possible: - Debugging an announcement delivery - With, say, system browsers not properly updated since their delivery is among the suspended deliveries. Or: - Debugging an announcement delivery - Have RPackageOrganizer out of sync (because its delivery is next) - And add a class or a method in this out-of-sync RPackageOrganizer. > > > > > I do have some issues in one of the system announcement where strangely > the announcement is received before the real operation is undertaken, and > this makes handling it properly an interesting problem. > > That sounds like a pathological erroneous use of announcements we tried to > make as hard as possible to actually get to work... > There are two facets to this; > > 1. The announcer relies on a subscriber to do work for it. This is just > *wrong*, in that it needlessly complicates things. As per above, this is > the case if the system announcer announces that a method has been added, > but the actual compilation / class installation happens in a subscriber. > Instead, announce that the stuff has been done, at the same place it is > being done, after it's done. (if that makes sense :) ) > Yes, it should be done that way in that particular case, but I believe we haven't solved it. It's the ClassModifiedClassDefinition event which has that behavior. > > 2. You are subscribing to announcements at the wrong abstraction level. > If, for instance, you want to refresh browsers based on updated package > contents after a method has been added, you do not subscribe to a base > system announcement that tells you code has been compiled and installed in > a class. > You subscribe to the PackageManager that announces a method has been added > to a package. > If you work at that abstraction level, then that's fine. But it's not the case. A system browser has to subscribe to the low-level events ;) > > Cheers, > Henry > > *One of the reasons an IdentitySet is used for subscriptions, instead of > an OrderedCollection, was to make it harder to write code that relies on > announcement delivery order without running into cases like the one you > describe > Which leads to the symptom of a random, not repeatable bug triggered by the particular ordering of the instance of the IdentitySet. Or a non-bug, but random behavior of the delivery. Had that in the Keymapping event handling. Hated that. I understand well the concern, but I honestly wonder if triggering random bugs helps. Regards, Thierry

July 3, 2015

Re: [Pharo-dev] Blog post on the new Fast Table

by Esteban Lorenzano

> On 02 Jul 2015, at 23:12, stepharo <stepharo(a)free.fr> wrote: > > The really first time it lags a bit (probably because the icons are computed). mmmâ¦ it shouldnât :) > But after it is a real pleasure. > I'm sorry esteban but we will enable it :) > We should not keep this little diamond in the safe better to use it in a necklace and shine. but there are still some bugs there, so I would prefer to wait a bitâ¦ check the tests of PackageTreeNautilusTest when activatedâ¦ of courseâ¦ you can help me fix it :) Esteban > > > Stef > > Le 2/7/15 14:56, Esteban Lorenzano a Ã©crit : >>> On 02 Jul 2015, at 14:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> >>>> On 02 Jul 2015, at 14:32, phil(a)highoctane.be wrote: >>>> >>>> Yes, very interesting work. >>>> >>>> We need to get the "slow feel" of the environment go away, thanks for working on that, Esteban. >>>> >>>> Is this something that would also address the slowness when we click on "Object" in Nautilus? >>>> >>> Yes. If you enable it in Pharo5, Itâs very fast. >>> >>> Just do: >>> >>> Nautilus useExperimentalFastTable: true. >>> >>> >>> Object browse. >> yep :) >> it reduces (in my machine) load times from ~4s to ~200ms :) >> butâ¦ is still not complete and there are some bugs around, so we need to work on it before make it default :( >> >> Esteban >> >>> >>> Marcus >> >> > >

July 3, 2015

Re: [Pharo-dev] SubscriptionRegistry>>#deliver:

by Henrik Johansen

> On 02 Jul 2015, at 9:40 , Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Henrik, > > Le 02/07/2015 10:49, Henrik Johansen a Ã©crit : >> >> >> The whole thread at >> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2012-January/057… is >> a good read for insight into the thoughts behind the current implementation. >> While some of Lukas' complaints that related to artifacts of the live >> migration has been resolved, many of the decisions made wrt optimization >> target/robust delivery are still valid. > > Very interesting thread, thanks. > >> My thoughts are now as they were then wrt. forking delivery, it makes >> code both harder to debug, and is (imho) not a good tradeoff between >> performance/clarity and percieved benefit. >> I'd rather the handler be responsible for the decision of whether it is >> heavy enough to be forked off in order to not block other delivery, than >> enforce it as a default. > >> I haven't searched for the related thread, but the fork-on-exception >> behaviour was eventually argued down to only apply for UnhandledErrors. >> The ifCurtailed: block is still somewhat useful, it lets you do things >> like put halts in handlers, and still be certain remaining subscribers >> are notified if you close the debugger, rather than proceed. > > Ok, so the behavior on halt (or an error opened on debugger) is to suspend all other notifications on that announcer? Including on the main system announcer? The behaviour is the same as when suspending any thread. If said thread is the only source of announcements, then all notifications are effectively suspended. There is nothing blocking other threads from delivering new announcements though. Unlike UnhandledErrors, a debugger raised responding to a halt will not have forked off in a separate thread, so you can navigate the entire stack, inspecting announcement source / other subscribers, etc. The ifCurtailed: merely ensures that if said process is terminated during delivery (Say, a debugger is closed instead of proceeded), the remaining subscribers will be processed before termination actually occurs. > > I do have some issues in one of the system announcement where strangely the announcement is received before the real operation is undertaken, and this makes handling it properly an interesting problem. That sounds like a pathological erroneous use of announcements we tried to make as hard as possible to actually get to work... There are two facets to this; 1. The announcer relies on a subscriber to do work for it. This is just *wrong*, in that it needlessly complicates things. As per above, this is the case if the system announcer announces that a method has been added, but the actual compilation / class installation happens in a subscriber. Instead, announce that the stuff has been done, at the same place it is being done, after it's done. (if that makes sense :) ) 2. You are subscribing to announcements at the wrong abstraction level. If, for instance, you want to refresh browsers based on updated package contents after a method has been added, you do not subscribe to a base system announcement that tells you code has been compiled and installed in a class. You subscribe to the PackageManager that announces a method has been added to a package. Cheers, Henry *One of the reasons an IdentitySet is used for subscriptions, instead of an OrderedCollection, was to make it harder to write code that relies on announcement delivery order without running into cases like the one you describe

July 3, 2015

Re: [Pharo-dev] Blog post on the new Fast Table

by Hilaire

Sooooo great! Thanks a lot Hilaire Le 02/07/2015 12:07, Esteban Lorenzano a Ã©crit : > Hi, > > I made a small blog post explaining a bit of the new fast table. > This is to encourage you to start using it and help me finish it :) > > http://smallworks.eu/web/blog/2015-07-02-fast-table-for-pharo > > cheers, > Esteban -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

July 3, 2015

[Pharo5] Review needed: 7008 Shared Pools to be treated like dictionaries still necessary?

by Marcus Denker

7008 Shared Pools to be treated like dictionaries still necessary? https://pharo.fogbugz.com/f/cases/7008

July 3, 2015

[Pharo 5] review needed: 15871 enable ProcessList

by Marcus Denker

15871 enable ProcessList https://pharo.fogbugz.com/f/cases/15871

July 3, 2015

Re: [Pharo-dev] [Pharo-users] [Pharo5] Update 150!

by Marcus Denker

> On 03 Jul 2015, at 09:30, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Cool, > > is there a current roadmap or plans for upcoming months? > Good ideaâ¦ I will put one together. Marcus

July 3, 2015

Re: [Pharo-dev] [Pharo-users] [Pharo5] Update 150!

by Pavel Krivanek

Cool, is there a current roadmap or plans for upcoming months? Cheers, -- Pavel 2015-07-02 14:18 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > We have update 150! > > https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-5-Publish/ > > On the issue tracker, we already closed 451 issues for Pharo5. > > > Marcus >

July 3, 2015

Re: [Pharo-dev] Stack

by Igor Stasenko

Its interesting, since in many places i using in-line linked list implementation, without troubling subclassing from "certified" LinkedList (or friends). This thing is a good case for stateful trait ('next' ivar + accessors and some logic for iterating etc). Unfortunately, for efficiency reasons, and since we're lacking stateful trait support, it is cheaper to simply implement such pattern in place rather than reusing existing implementation. In most cases i simply using key part - links between items, and don't see a need of inheriting hundreds of methods (sure sure, each time you inherit, it gives you 1000+1 way of (re)using that toy without writing a code, right?). Less is more :) I wonder, if i would be tempted to reuse LinkedList , if its implementation would be less horrible than it is now :) === As for difference between stack and linked list implementation, apart from being different paradigms, i see it as following: linked list basically 'declares' that items can easily access neighboring ones through direct reference (hence links), in stack, there's no any assumption whether items be able to see each other or not. For single linked list, it requires tracking only head. For efficiency, one might track tail pointer as well, but it is not necessary for correct implementation. Also, linked list structure allows very quick (O(1)) implementation for insertion/deletion items in the middle of it. While for stack, inserting/deleting in the middle is a nonsense. And i would really execute anyone who using such behavior simply because Stack is a subclass of LinkedList :) IMO, for stack a more efficient memory structure would be [ buffer array of items ] + stack pointer. As benefit, accessing items down the stack will be a simple indexing O(1) procedure, which is sometimes useful. Apparently, linked list is less efficient in this regard, since it will require interation. The (ever) growing array size is not an issue here, since by its purpose, stack serves as a special data exchange structure, that dynamically pipes things through itself, and always consumed fully at the end. So we can expect that most algorithms is normally very quickly settling down with stack max size, and then there's no need for frequent reallocation of stack buffer. I would also expect that stacks are never too deep: if it is, this might be an indication of using wrong data structure. On 2 July 2015 at 23:26, stepharo <stepharo(a)free.fr> wrote: > > > Le 30/6/15 20:25, Thierry Goubier a Ã©crit : > >> Le 30/06/2015 19:27, stepharo a Ã©crit : >> >>> alain fixed in place edit for string morph so we could even rename a >>> protocol simply by double clicking on it. >>> >> >> I noticed years ago that I could get that for free in a MorphTreeMorph by >> using a text instead of a string in the node description: would give you >> many, many types of renames, not only protocols. >> >> But this is another story >>> >> >> Yes and no. There are complaints about the model, and when you see the >> state of the tools... you can't be impressed by the fact it wasn't improved >> a long time ago. >> > > Indeed this is several weeks that we are with Franck fighting with > Nautilus and others. But day after day we are making progress. > > >> But maybe like that it makes some tools look better. >> >> Thierry >> >> >> > > -- Best regards, Igor Stasenko.

July 3, 2015

ESUG 2015, 12th Innovation Technology Awards

by jdelgado＠lsi.upc.edu

Apologies if you receive this message more than once... ESUG 2015, 12th Innovation Technology Awards Have you written innovative Smalltalk? The developers of any Smalltalk-based software can enter by submitting a 3-5min video of their software. Entrants demo their systems in a session at the end of Monday July 13th 2015, after which the conference attendees vote. (A vote consists in providing a sorted list of 3 preferred pieces of software.) The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros. The results are announced in the Awards ceremony that is held during the social event. Applicants should provide the following information on the conference registration server. Once you have registered your personal info, an 'Awards' menu allows submitting your software. You can provide this information when you first register, or login again later and update your details. Info to provide: Name of the software Licence information (free, shareware, or commercial) Name of the Smalltalk dialect used Name, Affiliation and Country of developers Besides, it would be great if the submission could include: URL for a video (3-5 min) showing a screencast / demo of the software URL for downloading the software or at least a runnable demo Deadline: July 12 Any Smalltalker can apply (students, companies, ...). The presented piece of code/software should be written in Smalltalk or directly support Smalltalk (e.g. Smalltalk VM). All Smalltalk dialects are accepted. The applicant should be "strongly related" to the presented code, be it as an author, as owner of the copyright/copyleft, or as an official representative of the copyright/copyleft owner. Bests, Jordi

July 3, 2015