On 20 June 2013 19:50, Sven Van Caekenberghe <[email protected]> wrote: > Hi Satoshi, > > On 20 Jun 2013, at 12:18, NISHIHARA Satoshi <[email protected]> wrote: > >> thx. >> >> I run a cleaning processes script such as: >> (Process allInstances >> reject: [ :p | >> {(InputEventFetcher default fetcherProcess). >> (Processor activeProcess). >> (WeakArray runningFinalizationProcess). >> (Processor backgroundProcess). >> (SmalltalkImage current lowSpaceWatcherProcess). >> (UIManager default uiProcess). >> (Delay schedulingProcess)} includes: p ]) >> do: [ :p | >> p suspend; terminate ] > > This code looks like a nice start for writing a unit test that could verify > that there are no bogus processes in delivered images. > > We already have a number of tests that do global quality checks (like > Undeclared, bogus instances, ..), we need this as well. > > Any opinions, comments ? >
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. > 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>> 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.
