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

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

by Eliot Miranda

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. > 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

Sept. 17, 2014

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

by Max Leske

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? 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

Sept. 17, 2014

[Review: 12111] (Date readFrom: '4.2.2013' readStream pattern: 'd.m.yy') ==>> 4 February 2020

by Max Leske

In the spirit of Markusâ cleanup please review this suggested fix to date parsing (from november 2013 originallyâ¦). Iâve ported the fix forward to 40 (which has the same issue). https://pharo.fogbugz.com/f/cases/12111/Date-readFrom-4-2-2013-readStream-p… Cheers, Max

Sept. 17, 2014

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

by Torsten Bergmann

Eliot wrote: >We're getting there with fast. Â Tiny needs more definition, but the core Cog/Spur VM on Mac minus plugins and GUI >code is 568k, 506k code, 63k data; the newspeak VM which has fewer primitives but support for two bytecode sets is >453k, 386k code, 68k data. Â That includes the interpreter, JIT, core primitives and memory manager/GC. Add on >several k for the FFI, C library et al and a VM in a megabyte is realistic. Â Is that in the right ball park? Yes, wet's my appetite :) Tiny means easy to download and use for scripting, no other dependencies for the out of the box REPL experience. But still powerfull to built one on another and scale up to large programs. Initially you provide just a simple VM executable for a "tiny smalltalk" (ts), for simple things like: c:\myscripts\ts.exe -e 3+4 7 where ts.exe is the VM in a few kB including a small initial kernel image (as part of the PE DATA section). It should be able to run scripts: c:\myscripst\ts.exe automate.st It should be possible to easily build components (either with or without the sources): ts.exe sunit.st -o sunit.sll ts.exe sunit.st -noSource -o sunit.sll So you can either include other scripts ts.exe -i sunit.st mytests.st or link the previously built binary components to form something new. ts.exe -l junit.sll mytests.st But it should be possible to build another vm+image easily: ts.exe -i mykillerapp.st -o killerapp.exe or ts.exe -l mykillerapp.sll -o killerapp.exe by writing a new PE file for Windows either including a new kernel image or a combined one based on the already built-in initial kernel of the previous one. So I can deploy a killerapp or reassemble it to form the next language version. SmallScript was very close to that and it was a nice thing to work with. Especially since usually Smalltalk usually throws things out at the end - but one never builds a house by carving it out of a rock. We need bricks to assemble. With the above scheme you could build components, some of them portable, others explicitly non-portable as the code includes native calls. The later have to be rebuilt on the other platform - so if you have good design abstractions you can implement a UI lib on Windows and one on Mac. Some of the components are with the source code packaged in for debugging (but not changeable), for closed source components you leave it out. And still it should support pinnable objects (not moved by GC for callouts), sandboxing, Classes with UUIDs to allow for side by side loading/migration and an extensible meta-scheme as this is where Smalltalk is still the hero of all und metaprogramming will be our future. Also the VM should be available as a shared component - so it can run in-process in other programs like a web browser. Always wished to write: <script type="text/tinyscript"> BrowserLog write: 'HelloWorld'. </script> directly in HTML. And this is only the beginning of the wish list... >Yep. Â But personally I think Fuel is better and just as fast. Â Certainly that's the parcels experience. >Â Â - but still with the ability to bootstrap up to a full saveable image Yes, Fuel would be an option. At least it would be platform independent. Not sure about other options (quick loading by mapping component using memory mapped files etc.) Â Â >This we'll leave to the web framework designers, but it seems eminently doable no? For sure. Bye Torsten

Sept. 17, 2014

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

by Thierry Goubier

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. > 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. 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 :) Regards, Thierry

Sept. 17, 2014

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

by Esteban A. Maringolo

2014-09-17 14:07 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> - tiny and fast VM with a command line and REPL > We're getting there with fast. Tiny needs more definition, but the core > Cog/Spur VM on Mac minus plugins and GUI code is 568k, 506k code, 63k data; > the newspeak VM which has fewer primitives but support for two bytecode sets > is 453k, 386k code, 68k data. That includes the interpreter, JIT, core > primitives and memory manager/GC. Add on several k for the FFI, C library et > al and a VM in a megabyte is realistic. Is that in the right ball park? Those sizes are impressively small! All those features in less than a megabyte are small even if we go back in time ten years from now. I'm eager to see and use those futuristic VMs even for mundane tasks. Esteban A. Maringolo

Sept. 17, 2014

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

by Eliot Miranda

Hi Thierry, On Wed, Sep 17, 2014 at 9:57 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Eliot, > > Le 17/09/2014 00:12, Eliot Miranda a Ã©crit : > >> Hi Thierry, >> >> On Tue, Sep 16, 2014 at 1:06 AM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> There is no "outside" in Sista. It is an image-level optimizer, so >> you'll be able to interact with it at the same level one interacts with >> the Opal compiler. Of course doing this kind of strength-reduction is >> possible. >> > > Ok. I'll have a look and maybe profile a bit; SmaCC has plenty of those > optimisations that I had to remove in the Pharo port, and I should have a > look on the cost of doing all thoses Character value: XXX and ^ Dictionary > new... > > I also had nice optimisations in VW for my trace tool (like replacing a > class lookup by a Literal which was then replaced by the singleton instance > in the method bytecode) which do not have any effect in Squeak/Pharo > anymore. 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"? I have no idea. All I know is that the code generation side of the >> Cogit is extremely cheap, dwarfed by the costs of relinking when code is >> recompiled. But the cost is vanishingly small. The costs that do show >> up in the Cogit are the cost of discarding, compacting and relinking >> code when the working set grows (e.g. Compiler recompileAll), and pause >> times here are ~ 1ms on my 2.2GHz MBP; thats about twice the cost of a >> scavenge, at about 1/20th the frequency (these times are for Spur). If >> you open up the system reporter you'll be able to see for yourself. And >> if you use the VMProfiler you can see exactly here the time goes for >> your favourite synthetic benchmark. See if you can figure out how to >> create bytecoded methods cheaper than the JIT can compile them and >> profile it. >> > > 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. If you've got a tool that can count instructions let me know and I may >> measure. I could could bytecodes per instruction generated in the >> simulator ;-). >> > > I used some of the intel cycle CPU counters in the past to benchmark code. > I'll ask around for accessing Intel's cycle count registers. I'm sure the > Bochs x86 simulator has those. > > b) it would be easy to extend the VM to cause the Cogit to >> precompile specified methods. We could easily provide a >> "lock-down" facility that would prevent Cog from discarding >> specific machine code methods. >> >> >> That one is interesting. It sounds like a great benefit would be to >> have a limited API to the Cog JIT for that sort of requirements. >> >> And of course, you have to perform lot of profiling. >> >> >> Early and often :-). >> >> Because we can have complete control over the optimizer, and >> because Sista is byetcode-to-bytecode and can hence store its >> results in the image in the form of optimized methods, I believe >> that Sista is well-positioned for real-time since it can be used >> before deployment. In fact we should emphasise this in the >> papers we write on Sista. >> >> >> I'm not sure of that "real-time" aspect is a good idea. More >> real-time than others dynamic optimisers, maybe. Note that Java >> Real-Time suggest turning off JIT and switch to ITC. >> >> >> But thats because in Java VMs the adaptive optimizer is in the VM where >> one has limited control over it. Sista is different. >> > > 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. 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. -- best, Eliot

Sept. 17, 2014

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

by Thierry Goubier

Le 17/09/2014 00:27, Eliot Miranda a Ã©crit : > > > On Tue, Sep 16, 2014 at 5:33 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > > 2014-09-16 14:19 GMT+02:00 kilon alios <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>>: > > Python is a great language why one would use it behind anyone's > back ? > > Python has several ways to deal with static typing, performance > and optimization, cython, shedskin , pypy and lately its > creators linked a new kind of python that allows for static > types in his twitter feed. > > There are also ways for python to take advantage LLVM one such > project is by Dropbox people (Where the creators of Python > currently works for) called "pyston" for high performance python > --> > https://tech.dropbox.com/2014/04/introducing-pyston-an-upcoming-jit-based-p… > > > and the list goes on.... and on..... and on.... > > > Everything you describe are partial solutions which suits the Python > community well for their needs. If python was suited for RT, > embedded work, it would be an horror to work with. The same goes > with Smalltalk. > > You're not supposed to have fun when you do embedded, RT work. You > are supposed to suffer :( This is no place for the creative spirit. > > > I think you need therapy ;-) Why not be positive and think about how > you could make these technologies work? I'm sure Smalltalk and Cog can > do soft real-time. People have been using it to do music for as long as > its been in existence. If you could get beyond your "it can't be done" > mind set and get into a "how might this be done" mindset you might make > a real contribution. Right now you're being a real downer. Been there, done that. You do it once, after you dump the people in that field and you do more valuable stuff :) I really needed that Smalltalk therapy ;) Thierry

Sept. 17, 2014

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

by Eliot Miranda

Hi Torsten, On Tue, Sep 16, 2014 at 4:12 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Eliot, > > Yes - in the past most Smalltalks did not have native widgets and usually > emulated > the L&F. I remember VW on a Sun Sparc with Windows or Mac look. While it > was cool > to run 1:1 on another machine it would have been to much manpower for the > vendor > to reimplement all the nice widgets to really look like the native system. > Especially > when the L&F changed very often between Win95/96/XP/Win7/Win8 at Microsoft. > > Even with good looking widgets/icons one could see from the speed and > repainting issues > (white rectangles for damage areas) that Smalltalk was not native. Also > native widgets had > other nice features like virtual modes for TreeViews/ListViews used if you > want to display > many nodes. > > Java faced the same problem - even with Swing and JavaFX today the Java > UIs and especially > the ugly JFileDialog never had this "Native look and easy navigation > feeling". And yes > there is SWT in Java providing native widgets - but how many applications > are based on > it? Only a few. > > On the ST side Smalltalk/MT and Dolphin use native widgets but were not > portable. And if > you look at others like VW, VAST or Smalltalk/X you will see that > engineers are good at > creating powerfull systems but often fail when it comes to UI design and > usability. Squeak > was special and flexible with Morphic (even without multiple windows) - > but looked too toyish. > > So yes - customers of commercial Smalltalk vendors asked for "Native" > because if you had > built a UI in Smalltalk it was part of a rich client application and often > people compared > it to other native applications or new widgets found in MS Office. > That's a great summary. +1. > But in the past customer also asked for COM/COM+, CORBA and webservices > while today > it is often much easier to exchange data or call functionality via HTTP, > REST, ... > Sure, but that's invisible glue; not the same as UI components for the user. So there's a bit of a non-sequitur extrapolating from UI (user to system) to system to system connectivity. > So time and expectations have changed a lot meanwhile. Especially for the > UI's. > Desktop platforms unite with the web and in the web it is also possible to > look more > like platforms or style to look like a native app. See [1] and [2] for two > simple examples. > > While the browsers and JS engines become faster this will also change more > the way > we think about applications: no installation, styleable, clear look. The > google > chrome experiments are a good page to see how this will soon look like. > And we will > be independent from devices and screen resolution. In fact more and more > applications > we use today run on a computers webbrowser, tablet or a smartphone (often > the same way). > > With Morphic (even when it has Fenestri) we can not compete agains > HTML/CSS on the > UI side. The Canvas element and WebGL will also drive this forward. > Even if one does not like web technologies - it currently is the platform > where > you reach people easily. > > Smalltalk should/could have a place in this (web centric) world: > > 1. As a backend to serve the web > 2. On the client > 3. Combining 1. and 2. > > For the first we have Seaside, TeaPot, Aida, ... > For the seond: as it will not happen that browser vendors agree and threw > out JavaScript in > favour of ST runtimes, maybe we can build on top like Amber or SqueakJS do. > > But we should also rethink Smalltalk to find a better place as a scripting > language. What > I still would like to see: > > - tiny and fast VM with a command line and REPL > We're getting there with fast. Tiny needs more definition, but the core Cog/Spur VM on Mac minus plugins and GUI code is 568k, 506k code, 63k data; the newspeak VM which has fewer primitives but support for two bytecode sets is 453k, 386k code, 68k data. That includes the interpreter, JIT, core primitives and memory manager/GC. Add on several k for the FFI, C library et al and a VM in a megabyte is realistic. Is that in the right ball park? - one unified and easy to use FFI with callbacks so one can use the > platform, maybe > others will write the bindings then > +1. Again that's central to our efforts. > - single small base image but fast loadable binary code components > (modules, maybe using the > LoadLibrary trick), similar to what David had with SmallScript or what > BeeSmalltalk is doing with SLL's > Yep. But personally I think Fuel is better and just as fast. Certainly that's the parcels experience. > - but still with the ability to bootstrap up to a full saveable image > +1. > - ability to serve the web with easy callbacks into Smalltalk for > implementing functionality > (especially with this we may catch 90% of the usual UI cases). > This we'll leave to the web framework designers, but it seems eminently doable no? > > Bye > T. > > [1] Metro theme Bootstrap > http://talkslab.github.io/metro-bootstrap/components.html > [2] jQuery Desktop http://desktop.sonspring.com/ > [3] Chrome Experiments http://www.chromeexperiments.com/ I love the circle game but oh boy does the implementation show through in the pauses. My old 5.x Safari pauses noticeably every two seconds or so. Chrome is smooth. -- best, Eliot

Sept. 17, 2014

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

by Thierry Goubier

Le 17/09/2014 00:13, Eliot Miranda a Ã©crit : > > > +100. And Smalltalk is being used in real-time applications already, > e.g. semiconductor fab machines. It used to be in all of Tektronix's > oscilloscaopes. And I remember a HP network analyser whose GUI was written with Digitalk/V. But this is work where you go dual: you put your real-time control loop on a core, making sure it will never be interrupted, and you let the soft stuff (GUI and all) outside of the RT loop. There I can see Cog and Smalltalk, not in the inner loop. Thierry

Sept. 17, 2014