On 24 June 2013 11:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Igor,
On 21 Jun 2013, at 13:27, Igor Stasenko <siguctua@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.denker@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.clement@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 <goonsh@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.