On 24 June 2013 11:12, Sven Van Caekenberghe <s...@stfx.eu> wrote: > Igor, > > On 21 Jun 2013, at 13:27, Igor Stasenko <siguc...@gmail.com> wrote: > >> Yes, the only thing i hate in this code is references to many different >> classes. >> These processes actually represent various basic services of the system. >> so i would prefer that these services register themselves somewhere, >> like that we could have a clean code, something like: >> >> services collect: [:each | each process ] >> >> like that, you don't need to modify this method evry time you changing >> the list/implementation etc. > > I implemented this on ReleaseTest, with a fixed list, for now. > > I understand your remark: some form of dependency injection is cleaner and > more extensible/scaleable indeed. > > However, in this particular case, I am not 100% convinced: your dynamic list > based on registration can only be as good as the registrars, if they make a > mistake (failing to unregister), the list will become bad. > there can be a compromise :) a) make method, which contains list of exact class names (services) b) make sure that these classes understand same protocol, so that in other method you do: self services collect: [:each | each processThatIsValidWhatever ]
> Sven > >>> Sven >>> >>>> and get 6 processes remain: >>>> (80) 745275392: Delay class>>handleTimerEvent >>>> (60) Input events fetching process: InputEventFetcher>>waitForInput >>>> (60) 1061945344: SmalltalkImage>>lowSpaceWatcher >>>> (50) 946339840: WeakArray class>>finalizationProcess >>>> (40s) Morphic UI process: nil >>>> (10) 845938688: ProcessorScheduler class>>idleProcess >>>> >>>> is this OK? >>>> >>>> regards. >>>> >>>> >>>> 2013/6/20 Marcus Denker <marcus.den...@inria.fr> >>>> Hi, >>>> >>>> I think we should for now just kill them when building the image, I will >>>> check. >>>> >>>> On Jun 20, 2013, at 9:56 AM, Clément Bera <bera.clem...@gmail.com> wrote: >>>> >>>>> Hello, >>>>> >>>>> These processes are due to the new integration testing process. This new >>>>> process was introduced in Pharo 3.0 alpha, and we found the bug and fixed >>>>> it. >>>>> Recently we backport the new integration process to Pharo 2.0 and >>>>> seemingly it created the same bug but since we read your mail we were not >>>>> aware of it. We need to backport the fix. >>>>> We will fix that within a few days. >>>>> >>>>> As a workaround, you can just kill these processes in your image for now >>>>> ... >>>>> >>>>> Thanks for reporting the issue, >>>>> >>>>> >>>>> >>>>> >>>>> 2013/6/20 NISHIHARA Satoshi <goo...@gmail.com> >>>>> There are 30 over processes are running at startup, Pharo-20607.image. >>>>> >>>>> <NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png> >>>>> >>>>> regards. >>>>> >>>>> -- >>>>> -- >>>>> "NISHIHARA Satoshi" >>>>> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] >>>>> >>>>> >>>>> >>>>> -- >>>>> Clément Béra >>>>> Mate Virtual Machine Engineer >>>>> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq >>>> >>>> >>>> >>>> >>>> -- >>>> -- >>>> "NISHIHARA Satoshi" >>>> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] >>> >>> >> >> >> > > -- Best regards, Igor Stasenko.
