September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] re: Parsing Pharo syntax to C/C++

by Eliot Miranda

Hi Thierry, On Wed, Sep 17, 2014 at 11:46 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Hi Eliot > > Le 17/09/2014 19:18, Eliot Miranda a Ã©crit : > >> Hi Thierry, >> >> Yes, and various dialects have a literal constructor for "compile-time >> expressions" (I did one for VW) that provide a manual (and hence >> fragile) way of doing this. As you pointed out this approach breaks >> when one changes the code previously compiled. Having Sista regenerate >> for you automatically is of course preferrable. But what do you mean >> "do not have any effect in Squeak/Pharo anymore"? >> > > It works but has no effect on performance. Well, this is an optimisation; > you gain in certain circonstances, you loose in others and you turn it off. > > >> I have colleagues in the same department working on localized, >> template based JiT of computational kernels and they do 3 inst of >> JiT for one instruction (and prove that they go faster on some >> matrix math code, including the JiT overhead, than anything >> statically optimised off-line). >> >> >> Sure. My JIT optimizes and cannot be reduced to a template approach. >> But it is still extremely fast. As I said, scanning code to >> relink/compact/GC is what takes the time, not compilation itself. And >> the pause times here are bounded (see below). >> >> At the same time, a one ms pause at 2.2GHz is a hell of a long time >> if your target is a MicroBlaze at 50 Mhz or an embedded powerpc at >> 25 MHz. >> >> >> Sure, there are bound to be contexts in which Cog can't meet the >> required deadlines. But that doesn't imply it can never do real time, >> does it? And processor speeds are climbing. Look at Raspberry Pi, >> 700MHz. Not too shabby. >> > > This is the performance of an old desktop :) And a not so old at that. ARM > started as a desktop processor, after all. > > But, look: Python works very well on the Pi ;) Fast enough, and if not, > you call a C lib. and that's precisely what we want to avoid. IMO that;s one reason why the Python (and e.g. PHP) community has been so slow to implement good VMs. It has deferred to C code for performance-critical code _where it could_ (e.g. regular expressions) at the expense of rigid dependence on that external library. Now that companies such as Dropbox and Facebook are needing Python and PHP to exhibit good performance they are finally implementing faster VMs long after other languages. This has meant that Python libraries have not evolved as fast or as conveniently as could have happened if there was no dependency on C. Of course the situation with Squeak was/is the same, with a proliferation of plugins that would not be necessary if the VM were fast. (of course some plugins exist for good security reasons). The problem is that even a simple JiT is considered too much Jitter :) >> >> >> But some in some contexts. But that doesn't define the entire real time >> world. >> > > Yes. > > >> The Ocaml guys told once they had to do a special, interpreted VM >> for a real-time use case. The problem is not going fast, the problem >> is being predictable. They turn off CPU caches in some cases. >> >> Sure. But if one can show that the JIT's pause times are bounded and >> well spaced then there is no fundamental problem. People have been >> implementing real-time GCs and using GC in real time systems for over 20 >> years now. This is no different. But you seem absolute in denying that >> there is any possibility of using a JIT in real time. I think that >> claim is clearly false. >> > > If we consider that you would have to do a WCET analysis / stack > boundedness analysis to prove that the JIT pauses are deterministic, > bounded and are schedulable for the target times (i.e. suitable for a > significant part of what real time is about), then that claim will hold > true for a while. > Right. If we change and adjust the definition of real-time and the required > processing power needed, then we can consider Cog JIT sufficiently > real-time as long as it is reasonably deterministic. > > This is my opinion on that: for what I have done in the embedded world and > on FPGA so far, any gain on the determinism, performance and portability of > Cog is highly significant(*); but I would really like that the language > running on top of Cog, and Cog, be able to clearly let a programmer specify > bounds / determinism requirements / parallelism so as to ensure that it may > communicate well with real-time programs. And then it would be a really > nice fit, and a huge boost to both Cog and the Embedded/RT community. > > (*) And those benefits would also make it really cool to use everywhere. > > (**) A nice target would be to be able to run Cog on a SoC with a general > purpose CPU core and a FPGA. > > (***) and then I could reuse what I know about synthesizing logic circuits > on a FPGA from smalltalk code :) > I look forward to working with you on this! We may be a few years behind this curve in first getting Sista and the FFI and 64-bits done, but soon enough we will be ready to tackle challenges like this! Regards, > > Thierry -- best, Eliot

Sept. 18, 2014

Re: [Pharo-dev] Spec-Morphic tab manager broken

by Yuriy Tymchuk

Weâve already fixed that. Nicolai Hess helped to identify the problem. Uko > On 18 Sep 2014, at 21:19, stepharo <stepharo(a)free.fr> wrote: > > yuriy can you check with a version before esug because may be we broke it with glenn because he was blocked > by something else. > > Setf > > On 17/9/14 11:01, Yuriy Tymchuk wrote: >> Hi. >> >> If you have any knowledge on how Spec adapters work, maybe you can take a look. >> To reproduce the bug: >> >> execute: "TabsExample open" and select one of (non-active) the tabs. >> >> >> Case here: https://pharo.fogbugz.com/f/cases/14030/MorphicTabManagerAdapter-doesNotUnd… <https://pharo.fogbugz.com/f/cases/14030/MorphicTabManagerAdapter-doesNotUnd…> >> >> Uko >

Sept. 18, 2014

[Review: 13229] Year arithmetic broken

by Max Leske

Another issue for cleanup review. https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken Ported from Pharo 30. Made a few additional changes to #hash and #printOn: methods that no longer worked, added class comment to AnnualDuration. NOTE: I haven't done a full review on this and the change of seconds from integer to floats can have quite serious implications. Please look at this carefully. Name: SLICE-Issue-13229-Year-arithmetic-broken-MaxLeske.1 Author: MaxLeske Time: 18 September 2014, 9:50:41.500402 pm UUID: 44e5effc-4344-4aec-8cf5-3cb5d92ad73e Ancestors: Dependencies: Kernel-MaxLeske.1827, KernelTests-MaxLeske.678 Port from Pharo 30. - Added class comment to AnnualDuration. - adapted #hash and #printOn: methods that no longer worked because of seconds being floats

Sept. 18, 2014

Re: [Pharo-dev] csv2html the Pharo version

by stepharo

sven I love this because to me it shows that we can really nicely manipulate data. On 18/9/14 10:28, Sven Van Caekenberghe wrote: > Hi, > > Today I came across some bash code on a web page that loves Smalltalk, > ah the horror ;-) > > http://car.mines-douai.fr/2014/09/csv2html/ > > The goal is to make it easier to look at CSV data, for which a > conversion to HTML was done. To just look at CSV data in a nice > tabular form, we do not have to leave Pharo at all. > > MultiColumnListModel new > items: (FileLocator desktop / 'test.csv' readStreamDo: [ :in | > (NeoCSVReader on: in) emptyFieldValue: ''; upToEnd ]); > displayBlock: [ :x | x ]; > title: 'CSV Data'; > openWithSpec. > > Which results in this nice window: > > > To do a conversion to HTML, debugging the code in Pharo should be > preferable to doing the same with bash & sed (for most of us anyway). > > FileLocator desktop / 'csv.html' writeStreamDo: [ :out | | reader | > out << '<html><head><title>CSV Data</title></head><body><table > border=1>'. > reader := NeoCSVReader on: (FileLocator desktop / 'test.csv') > readStream. > reader emptyFieldValue: ''. > out << '<tr bgcolor=silver>'. > reader readHeader do: [ :each | out << '<th>'; << each; << '</th>' ]. > out << '</tr>'. > reader do: [ :each | > out << '<tr>'. > each do: [ :td | out << '<td>'; << td; << '</td>' ]. > out << '</table></body></html>'. > reader close ]. > > Which gives the following output: > > NeoCSVReader is way more powerful in interpreting CSV files than a > simple sed one-liner. Doing the same for a collection of files is > easy. Maybe a little browser could even be written. Who knows, maybe > Doru will add another tool to GT (TableViewer > class>>#openStructuredOn: would do the trick I guess) ;-) > > Sven > > PS: The bash script was actually quite well written, even I could > read/understand it. Thanks for sharing, it was the inspiration to do > this little hack. >

Sept. 18, 2014

Re: [Pharo-dev] csv2html the Pharo version

by stepharo

On 18/9/14 11:19, Serge Stinckwich wrote: > Excellent Sven ! > > Maybe the Douai guys have some really huge cvs that could not be > processed by Pharo. and could be processed by bash.... Moose manages MB of objects so I do not see why :) Serge you should trust Pharo more :) > > > On Thu, Sep 18, 2014 at 10:28 AM, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > Hi, > > Today I came across some bash code on a web page that loves > Smalltalk, ah the horror ;-) > > http://car.mines-douai.fr/2014/09/csv2html/ > > The goal is to make it easier to look at CSV data, for which a > conversion to HTML was done. To just look at CSV data in a nice > tabular form, we do not have to leave Pharo at all. > > MultiColumnListModel new > items: (FileLocator desktop / 'test.csv' readStreamDo: [ :in | > (NeoCSVReader on: in) emptyFieldValue: ''; upToEnd ]); > displayBlock: [ :x | x ]; > title: 'CSV Data'; > openWithSpec. > > Which results in this nice window: > > > To do a conversion to HTML, debugging the code in Pharo should be > preferable to doing the same with bash & sed (for most of us anyway). > > FileLocator desktop / 'csv.html' writeStreamDo: [ :out | | reader | > out << '<html><head><title>CSV Data</title></head><body><table > border=1>'. > reader := NeoCSVReader on: (FileLocator desktop / 'test.csv') > readStream. > reader emptyFieldValue: ''. > out << '<tr bgcolor=silver>'. > reader readHeader do: [ :each | out << '<th>'; << each; << > '</th>' ]. > out << '</tr>'. > reader do: [ :each | > out << '<tr>'. > each do: [ :td | out << '<td>'; << td; << '</td>' ]. > out << '</table></body></html>'. > reader close ]. > > Which gives the following output: > > NeoCSVReader is way more powerful in interpreting CSV files than a > simple sed one-liner. Doing the same for a collection of files is > easy. Maybe a little browser could even be written. Who knows, > maybe Doru will add another tool to GT (TableViewer > class>>#openStructuredOn: would do the trick I guess) ;-) > > Sven > > PS: The bash script was actually quite well written, even I could > read/understand it. Thanks for sharing, it was the inspiration to > do this little hack. > > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/

Sept. 18, 2014

Re: [Pharo-dev] csv2html the Pharo version

by stepharo

debugging bash is soooooo boring and tedious. I would prefer to debug 100 times in Pharo. Stef On 18/9/14 11:17, Luc Fabresse wrote: > Hi Sven, > > Arg, you got us :-P > Shame on us! > You are completely right that we could have done that in Pharo. > But, Zhi is working since mont on doing realistic robotics simulation > on the cluster of the EMD. > The goal is to use the SAME code both in simulation and in the real > robots. > For doing this, he is writing a lot (a LOT) of BASH scripts to > automatically prepare simulations on the cluster nodes. > Since he is not really fluent in Pharo and since it involves so much > system scripting, he is doing it in BASH. > I suspect that he took the least resistant path to code the csv to > html ... > > Anyway, at some point we will move from this first prototype to > another one so involve Pharo deeper using PhaROS and then we will have > more Pharo in the loop ;-) > > Cheers, > > #Luc > > 2014-09-18 10:28 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>>: > > Hi, > > Today I came across some bash code on a web page that loves > Smalltalk, ah the horror ;-) > > http://car.mines-douai.fr/2014/09/csv2html/ > > The goal is to make it easier to look at CSV data, for which a > conversion to HTML was done. To just look at CSV data in a nice > tabular form, we do not have to leave Pharo at all. > > MultiColumnListModel new > items: (FileLocator desktop / 'test.csv' readStreamDo: [ :in | > (NeoCSVReader on: in) emptyFieldValue: ''; upToEnd ]); > displayBlock: [ :x | x ]; > title: 'CSV Data'; > openWithSpec. > > Which results in this nice window: > > > To do a conversion to HTML, debugging the code in Pharo should be > preferable to doing the same with bash & sed (for most of us anyway). > > FileLocator desktop / 'csv.html' writeStreamDo: [ :out | | reader | > out << '<html><head><title>CSV Data</title></head><body><table > border=1>'. > reader := NeoCSVReader on: (FileLocator desktop / 'test.csv') > readStream. > reader emptyFieldValue: ''. > out << '<tr bgcolor=silver>'. > reader readHeader do: [ :each | out << '<th>'; << each; << > '</th>' ]. > out << '</tr>'. > reader do: [ :each | > out << '<tr>'. > each do: [ :td | out << '<td>'; << td; << '</td>' ]. > out << '</table></body></html>'. > reader close ]. > > Which gives the following output: > > NeoCSVReader is way more powerful in interpreting CSV files than a > simple sed one-liner. Doing the same for a collection of files is > easy. Maybe a little browser could even be written. Who knows, > maybe Doru will add another tool to GT (TableViewer > class>>#openStructuredOn: would do the trick I guess) ;-) > > Sven > > PS: The bash script was actually quite well written, even I could > read/understand it. Thanks for sharing, it was the inspiration to > do this little hack. > >

Sept. 18, 2014

Re: [Pharo-dev] Spec-Morphic tab manager broken

by stepharo

yuriy can you check with a version before esug because may be we broke it with glenn because he was blocked by something else. Setf On 17/9/14 11:01, Yuriy Tymchuk wrote: > Hi. > > If you have any knowledge on how Spec adapters work, maybe you can > take a look. > To reproduce the bug: > > execute: "TabsExample open" and select one of (non-active) the tabs. > > > Case here: > https://pharo.fogbugz.com/f/cases/14030/MorphicTabManagerAdapter-doesNotUnd… > > Uko

Sept. 18, 2014

Re: [Pharo-dev] I'm confused about Process>>isTerminated

by Eliot Miranda

Hi Max, phhh, time zone differences suck ;-) On Thu, Sep 18, 2014 at 3:50 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi Eliot, > > On 18.09.2014, at 01:18, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Max, > > On Wed, Sep 17, 2014 at 1:59 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> Hi Eliot >> >> >> On 16.09.2014, at 20:18, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Max, >> >> On Tue, Sep 16, 2014 at 11:05 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> Hi >>> >>> As always when I want to check if a process has died I get very confused >>> by #isTerminated and Iâm wondering if I just donât get how itâs supposed to >>> work or if there are others that share my confusion. >>> >>> Old implementation: >>> >>> isTerminated >>> >>> self isActiveProcess ifTrue: [^ false]. >>> ^suspendedContext isNil >>> or: ["If the suspendedContext is the bottomContext it is the >>> block in Process>>newProcess. >>> If so, and the pc is greater than the startpc, the >>> bock has alrteady sent and returned >>> from value and there is nothing more to do." >>> suspendedContext isBottomContext >>> and: [ suspendedContext pc > suspendedContext startpc ] >>> ] >>> >>> >>> Pharo 4 implementation: >>> >>> isTerminated >>> self isActiveProcess ifTrue: [^ false]. >>> ^suspendedContext isNil >>> or: ["If the suspendedContext is the bottomContext it is the >>> block in Process>>newProcess. >>> If so, and the pc is greater than the startpc, the >>> bock has alrteady sent and returned >>> from value and there is nothing more to do.â >>> suspendedContext isBottomContext >>> and: [ suspendedContext isDead not >>> â<âââââââââââââââââââââââââ new" >>> and: [ suspendedContext pc > suspendedContext startpc ] >>> ] ] >>> >>> >>> The old implementation would break if the suspended context was dead >>> (i.e. the pc was nil) because the send of #> would produce an MNU. >>> The new implementation doesnât fix that, even though it looks like it at >>> first glance: if the pc is nil, the #> send will still happen -> MNU. >>> >> >> Off the top of my head it would seem that it should be isDead or: [] not >> isDead not and: >> >> isTerminated >> self isActiveProcess ifTrue: [^ false]. >> ^suspendedContext isNil >> or: ["If the suspendedContext is the bottomContext it is the >> block in Process>>newProcess. >> If so, and the pc is greater than the startpc, the >> bock has alrteady sent and returned >> from value and there is nothing more to do.â >> suspendedContext isBottomContext >> and: [ suspendedContext isDead >> or: [ suspendedContext pc > suspendedContext >> startpc ] ] ] >> >> >> Phew. Glad you see that the same way. >> >> isDead >>> ^ pc isNil >>> >> >> and maybe (suspendedContext pc ifNil: [true] ifNotNil: [:pc| pc > >> suspendedContext startpc]) is more obvious. >> >> Anyway, neither implementation will reliably tell me if the process has >>> been terminated: >>> - an inactive process will be suspended when #terminate is sent and >>> report that it has not been terminated (#isSuspended -> true, #isTerminated >>> -> false) >>> >> >> except that it *hasn't* been terminated, it is merely in the process of >> termination. It isn't terminated until all unwind blocks have run, right? >> >> >> True. Easy to forget when you can just kill -9 on the consoleâ¦ :) >> >> >> >>> - a properly terminated process will raise an MNU (although apparently >>> not alwaysâ¦?) >>> >> >> but that's a bug the change I suggested will fix. >> >> >>> - all the states in between: no clue >>> >>> I would like to know two things: >>> 1. how can I check if a process has already *received* a #terminate? (I >>> would then assume that the process will die eventually) >>> >> >> I don't think you can without putting a critical section around terminate >> and adding some process-specific variable that is set when you send >> terminate. termination is not instantaneous (unwind blocks have to be >> run), so it is potentially interruptible. >> >> >> Iâve thought about this a bit. I wouldnât really care if I donât get a >> correct answer about the termination status immediately but I want to have >> it before the process terminates. In case of something like the following: >> >> ([ 10 seconds asDelay wait ] forkAt: 11) terminate >> >> it can (potentially) take a very long time for the process to terminate. >> So if I have to poll 3 or 4 times thatâs ok but I donât want to wait for >> minutes. >> One solution would be to take your idea of the variable, but without the >> critical block: >> >> terminate >> "Stop the process that the receiver represents forever. Unwind to >> execute pending ensure:/ifCurtailed: blocks before terminating." >> >> | ctxt unwindBlock oldList | >> terminating := true. â<âââââââââââââââââââââââââââââââââââ changed" >> self isActiveProcess >> ifTrue: [ >> ctxt := thisContext. >> [ ctxt := ctxt findNextUnwindContextUpTo: nil. >> ctxt isNil ] whileFalse: >> [ (ctxt tempAt: 2) ifNil: >> [ ctxt tempAt: 2 put: nil. >> unwindBlock := ctxt tempAt: 1. >> thisContext terminateTo: ctxt. >> unwindBlock value ]]. >> thisContext terminateTo: nil. >> self suspend ] >> ifFalse: [ >> "Always suspend the process first so it doesn't accidentally get woken up" >> oldList := self suspend. >> suspendedContext ifNotNil:[ >> "Figure out if we are terminating the process while waiting in >> Semaphore>>critical: >> In this case, pop the suspendedContext so that we leave the ensure: block >> inside >> Semaphore>>critical: without signaling the semaphore." >> (oldList class == Semaphore and:[ >> suspendedContext method == (Semaphore compiledMethodAt: #critical:)]) >> ifTrue:[ >> suspendedContext := suspendedContext home.]. >> "If we are terminating a process halfways through an unwind, try to >> complete that unwind block first." >> (suspendedContext findNextUnwindContextUpTo: nil) ifNotNil: [ :outer | >> (suspendedContext findContextSuchThat: [ :c | c closure == (outer tempAt: >> 1)]) >> ifNotNil: [ :inner | >> "This is an unwind block currently under evaluation" >> suspendedContext runUntilErrorOrReturnFrom: inner ]]. >> ctxt := self popTo: suspendedContext bottomContext. >> ctxt == suspendedContext bottomContext ifFalse: [ >> self debug: ctxt title: 'Unwind error during termination']] ]. >> >> >> >> isTerminating >> ^ terminating ifNil: [ ^ false ] >> >> >> With this small modification I can run the example from above and >> immediately see that it will die eventually. >> >> Iâm aware that one process might not see the change to the variable >> immediately but as I said, I wouldnât really care. >> >> >> What do you think? >> > > Yes that looks good. But given that branches are atomic (ifTrue: is not > a send) why not do > > Process>>initialize > terminating := false. > > terminate > "Stop the process that the receiver represents forever. Unwind to execute > pending ensure:/ifCurtailed: blocks before terminating." > > | ctxt unwindBlock oldList | > terminating > ifTrue: [self error: 'Process is already terminated, or being terminated'] > ifFalse: [terminating := true]. > self isActiveProcess > ifTrue: > ... > > ? > > I would suggest a status inst var, as in > > Process>>initialize > status := nil > > terminate > "Stop the process that the receiver represents forever. Unwind to execute > pending ensure:/ifCurtailed: blocks before terminating." > > | ctxt unwindBlock oldList | > status == #terminating > ifTrue: [self error: 'Process is already terminated, or being terminated'] > ifFalse: [status := terminating]. > self isActiveProcess > ifTrue: > ... > > but the temptation then is to have lots of different status values and I'm > leery of introducing that kind of complication without a strong > justification. > > > > Iâve worked a bit on an implementation along your suggestions. I wrote a > test which looks like this: > > testIsTerminated > | proc | > proc := [ Semaphore new wait ] forkAt: 30. > self deny: proc isSuspended. > self deny: proc isTerminating. > self deny: proc isTerminated. > proc terminate. > self deny: proc isTerminated. > self assert: proc isSuspended. > self assert: proc isTerminating. > [ proc isTerminated ] whileFalse: [ 1 second asDelay wait ]. > â<âââââââââââ ???" > > self assert: proc isTerminated. > self assert: proc isTerminating > > The test works AFAICT (apart from the loopâ¦) but I want to also have a > check after the process has terminated. Is there some reliable way to wait > for a process to die? I tried something like this for example: > > proc run. > self assert: proc isTerminated. > > But that locks up the active process (obviously) until I interrupt it > manually. If there is such a way, I could also add a method that lets a > process x wait for the completion of a process y for example (or not, > depending on how difficult it is :) ) > I can't see anything to do other than waiting. One thing is to run the process at as close to user priority as possible, so I would say proc := [ Semaphore new wait ] forkAt: Processor activePriority - 1. Another important thing is that you're not giving your process a chance to run before you test for it not terminating. So adding a yield after the first set of asserts and then repeating them is good: started := false. proc := [ started := true. Semaphore new wait ] forkAt: 30. self deny: proc isSuspended. self deny: proc isTerminating. self deny: proc isTerminated. (Delay forMilliseconds: 10) wait. self assert: started. self deny: proc isSuspended. self deny: proc isTerminating. self deny: proc isTerminated. Another thing might be to boost its priority to make sure it finishes (except that that'll probably have no effect because IIRC right now the terminator runs the termination). So you could say proc terminate. self deny: proc isTerminated. self assert: proc isSuspended. self assert: proc isTerminating. process priority: Processor activePriority + 1. [ proc isTerminated ] whileFalse: [ 1 second asDelay wait ]. Further I'd want to test that unwind blocks have been run so I'd say testIsTerminated | proc started unwound terminator | unwound := false. proc := [ started := true. [Semaphore new wait] ensure: [terminator := Processor activeProcess. unwound := true] ] forkAt: Processor activePriority - 1. self deny: proc isSuspended. self deny: proc isTerminating. self deny: proc isTerminated. (Delay forMilliseconds: 10) wait. "Alloc proc to run; there shouldnt be too much else going on so this delay should suffice" self assert: started. self deny: proc isSuspended. self deny: proc isTerminating. self deny: proc isTerminated. proc terminate. proc priority: Processor activePriority + 1. "This may have no effect; termination may be executed by the terminator rather than the terminatee; ys, this is a bug" self deny: proc isTerminated. self assert: proc isSuspended. self assert: proc isTerminating. (Delay forMilliseconds: 10) wait. "Allow proc to terminate; there shouldnt be too much else going on so this delay should suffice" self assert: proc isTerminated. self assert: proc isTerminating. self assert: unwound. self assert: terminator == proc. "But this should be made an expected failure; I don't know how to do that in SUnit..." and google's mail text editor *SUCKS*!!!! Cheers, > Max > > Cheers, >> Max >> >> 2. how can I check if a process is *actually* dead? (in case a âhalf >>> deadâ process will still unwind or whatever) >>> >> >> see above. >> >> What would be necessary to make those tests (or better ones) possible >>> (rewrite the whole process implementation?)? >>> >>> Cheers, >>> Max >> >> -- >> best, >> Eliot >> >> -- > best, > Eliot > > -- best, Eliot

Sept. 18, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40233 Home: https://github.com/pharo-project/pharo-core

Sept. 18, 2014

[pharo-project/pharo-core] 94972d: 40233

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 94972d1cae638706ec256c4625f71c9532c7ff50 https://github.com/pharo-project/pharo-core/commit/94972d1cae638706ec256c46… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-18 (Thu, 18 Sep 2014) Changed paths: M Morphic-Widgets-Basic.package/IconicButton.class/definition.st M Morphic-Widgets-Basic.package/IconicButton.class/instance/mouse events/mouseEnter_.st M Morphic-Widgets-Basic.package/IconicButton.class/instance/mouse events/mouseLeave_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script233.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40233.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40233 12873 IconicButton should absord property as instance variable https://pharo.fogbugz.com/f/cases/12873 http://files.pharo.org/image/40/40233.zip

Sept. 18, 2014