- Pharo-dev - lists.pharo.org

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

by kilon alios

"Nope. As a C/C++ advocate you are in denial about how unproductive your tools are and about the fact that it takes industrial scale organization to achieve even the most trivial of achievements." C/C++ , I don't code in those languages. Currently I use pharo, before that I was coding in python and still do, before that I was a Delphi developer. I hate C++ with a vengeance.I am now learning C for my first time. I dont see the industry having any problem achieving what it wants with C/C++ because if it did then the software industry would be overrun by smalltalk , which we all know how superior better it is . Actually you will be lucky if a coder was even aware what smalltalk is. I did not know what smalltalk is like a few years ago. I never even saw it mentioned in coding forums or in chat channels until one day someone mentioned squeak to me in #emacs. "By recently I mean within the last 10 years or so. The HotSpot Smalltalk VM is already 19 years old, and Self 3 over 20. PS, the first truly fast VM for a dynamic object oriented language is 32 years old. Python could have started an implementation effort at a faster VM much sooner and it would have shaped Python, IMO positively. There are reasons Java has been much more popular until recently, performance being a very important one. (There's reasons it's no longer popular, IMO the most important being it being statically typed). Further if you read what the Dropbox guys (and many others) are saying about Pyston vs PyPy is that tracing JITs fail to deliver good performance except in synthetic benchmarks where they shine, and hence Pyston is a method-at-a-time JIT. So PyPy is a so-so VM, hardly in the same league as HotSpot or V8 (and Pyston will have a ways to go before i can compete on that level), just as Cog is a so-so VM and needs Sista to reach or exceed static language performance for non-symbolic codes. And the lack of good support for C/C++ in PyPy is not a technical limitation. It is an organizational one. There's nothing intrinsic in a fast VM that makes it more difficult to interface to C. An execution engine is an execution engine, and it is the object representation that determines how easy it is to interface to other languages." Bottom line is clear, do optimised VMs are likely to really interest people, from the looks of it does not seem so. I don't care whether PyPy has technical limitations what matters is that I cannot use my favorite cpython libraries with it. " And that pure python libraries are a rarity is of course a result of the fact that Python has run to C whenever it needed performance. Hence when one comes to measure the speedup of a fast python against cpython it is difficult to see speedups because lots of benchmarks (e.g. many of the computer language shootout benchmarks) are spending much of their time running C code. Hint, if an app spends 50% of its time in C then it can never be more than twice as fast on a faster execution engine." no python needs to run C libraries because it wants to run C libraries , because they are so many out there and many of them are so damn good at what they are doing. Actually nowadays it becomes increasingly difficult not to find python wrappers for a C/C++ library. It comes down to C/C++ coders needing a simpler language that can easily port their code a lot more than a python coder would need C for speed. "You contradicted yourself in claiming that Pythoners dont yse faster VMs. Java has good C integration and provides much better performance than PyPy so if you were correct Pythoners would be using Jython + C but you claim they're not. (Personally I'm dubious about blanket claims about what people do and don't do; my experience since I've been involved with commercial Smalltalk deployment is that the world is incredibly varied and different people with different requirements do different things, often for good reason)." First of all Java has had crappy C integration like for ages , people were complaining about it for a long long time. Second I dont see how I contradict myself , I claimed that python people don't care so much about how fast a VM is when they can fall back to C and you bring up Java speed. What am I missing her ? Why not use Jython ? simple same reason why people dont use PyPy lack of support for cpython libraries, which by the way are based partly if not largely in C and if Java had so cool support of C then jython would have supported cpython libraries out of the box , which it does not. We can run this in circles but in the end I find it highly suspicious how some smalltalkers find smalltalk so awesome in every level yet they fail to justify why its so unpopular. And just for the record , so people dont think I talk out of random, this is Guido , the creator of python , says about PyPy and why is not integrated to cpython and the main goal of cpython --> http://youtu.be/EBRMq2Ioxsc?t=12m29s And yes python does not care about innovation at all, and this is one of the reason of its immense success as a language. Actually if you take into consideration that python is not tied to platform like javascript , or is not backed up by a huge company like C++ , Java , C# I dont think its an exaggeration at all that to say that it has been by far the most successful language at least in terms of people actually using it. Personally I find python as well completely unoriginal , not that well implemented, very slow and unimaginative. Still its the language, my number one choice, I would recommend to any one in terms of practicality alone. I don't want to debate this to death, I stated my opinion and the my view on things, you can call me advocate , fanboy or plain blind. Thats your right. I think however its good to hear the other side of story , the other opinion to make the discussion a bit more spherical. Saying that I love smalltalk and especially pharo and I hope it keeps being practical enough for me to keep using it.

Sept. 18, 2014

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

by Alexandre Bergel

Wellâ¦ Porting Roassal3d to Woden is almost straightforward :-) We can help on this. Effort behind Woden, Roassal, GraphET are not to simply tools. But instead producing an effective solution for a given problem. So, they will always be changing :-) Cheers, Alexandre On Sep 14, 2014, at 7:28 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Sometimes it is a bit dangerous to trust on "bleeding edge" pharo frameworks. > I did some work based on Roassal3D just to found out there won't be any further development. > The same happens with Roassal and GraphET. > The same can happen with Woden too :) -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 18, 2014

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

by Alexandre Bergel

Hi Kilon, Not sure what you are trying to do. Try this: -=-=-=-=-=-=-=-=-=-=-=-= forms := Form allInstances. v := RTView new. t := 1. e := (RTBitmap new form: [ :index | forms at: index ]) elementOn: t. v add: e. v open. [ 50 timesRepeat: [ t := t + 1. e model: t. e updateShape. (Delay forMilliseconds: 500) wait. v signalUpdate ] ] fork. -=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre On Sep 14, 2014, at 1:22 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code > > form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. > form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. > v := RTView new. > c := v canvas. > s := TRBitmapShape new. > s form: form1. > c addShape: s. > v open. > > (1 to: 100) do: [ :index| > s form: form1. > s signalUpdate . > "(Delay forMilliseconds: 1000 ) wait." > s form: form2. > s signalUpdate . > (Delay forMilliseconds: 1000) wait.]. > > I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ? > > if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect. > > On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo(a)free.fr> wrote: > Ronie when you ready I can help writting a chapter for the nex book. > > Stef > > > On 13/9/14 21:42, Ronie Salgado wrote: >> Hello, >> >> On 13/9/14 20:11, Enrico Schwass wrote: >>> Hi >>> >>> another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work. >> >> There is Wig like wrapper for Pharo done by ronie salgado. >> >> I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig >> >> Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. >> I still have to improve more my Swig generator, by writing documentation and fixing some bugs. >> >> Greetings, >> Ronie >> >> 2014-09-13 16:11 GMT-03:00 stepharo <stepharo(a)free.fr>: >> >> On 13/9/14 20:11, Enrico Schwass wrote: >>> Hi >>> >>> another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work. >> >> There is Wig like wrapper for Pharo done by ronie salgado. >> >> Stef >> >> >>> >>> http://youtu.be/c_D2YJSNj8I >>> >>> Almost a decade ago I did some ruby bindings by hand. It was working out of the box >>> >>> Bye >>> Enno >>> >>> Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios(a)gmail.com>: >>> >>>> >>>> " I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? " >>>> >>>> yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file. >>>> >>>> So basically its a lot like the average games out there. >>>> >>>> "I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing." >>>> >>>> ok >>>> >>>> "For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result." >>>> >>>> I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things. >>>> >>>> "Sure. The downpoint, you will depend on one additional layer." >>>> >>>> dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large. >>>> >>>> "Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious." >>>> >>>> Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically. >>>> >>>> So basically you will be using Blender as a GUI designer. >>>> >>>> "Use fuel to store the state of your application objects." >>>> >>>> ah nice so fuel is a good candidate. >>>> >>>> I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) . >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 18, 2014

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

by Eliot Miranda

On Thu, Sep 18, 2014 at 2:25 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > " 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. " > > nope , you are close but you got it the other way around. As a smalltalker > you see it from purist way of view. For you Python is that language that > got caught up on too reliance on C/C++ libraries. > Nope. As a C/C++ advocate you are in denial about how unproductive your tools are and about the fact that it takes industrial scale organization to achieve even the most trivial of achievements. > What you see as side effect is actually the central goal of python. The > central goal of python was and still is to a great extend today to serve as > scripting language for C and C++ code. This what made python so successful > that a C/C++ coder could use on top of its app embedded inside its app. > This why so many people use it even today. > Nope. What you claim as a central goal of Python is merely a supine acceptance of massive failure to innovate. Bourne shell has been doing this for years and years. It's not a new thing. And GVR seems to have conceived it as a better shell. Well, that's not innovative; useful, yes, innovative no. But seriously, look at something innovative written in Python such as BitTorrent et al. How much of that is system calls, C or Python? t is basically Python an socket calls. C doesn't play a significant part in the architecture. The important thing is a dynamic OOPL being able to express a novel architecture. I'd wager that torrent clients are amongst the most popular Python apps. You also again wrong to assume that its a late thing that new VMs are > developed for Python , PyPy which is very well known inside the python > community has been around more than 12 years. Its a very performant JIT VM > 2-10 faster than cpython. Why cpython has not ported to it ? because of not > so good support for C/C++ , zero support for cpython libraries and of > course because as they say it would complicate the development of cpython > quite a lot . Its that situation that only a couple of people can decypher > the magic of the VM and the rest of developer only hope for the best. > By recently I mean within the last 10 years or so. The HotSpot Smalltalk VM is already 19 years old, and Self 3 over 20. PS, the first truly fast VM for a dynamic object oriented language is 32 years old. Python could have started an implementation effort at a faster VM much sooner and it would have shaped Python, IMO positively. There are reasons Java has been much more popular until recently, performance being a very important one. (There's reasons it's no longer popular, IMO the most important being it being statically typed). Further if you read what the Dropbox guys (and many others) are saying about Pyston vs PyPy is that tracing JITs fail to deliver good performance except in synthetic benchmarks where they shine, and hence Pyston is a method-at-a-time JIT. So PyPy is a so-so VM, hardly in the same league as HotSpot or V8 (and Pyston will have a ways to go before i can compete on that level), just as Cog is a so-so VM and needs Sista to reach or exceed static language performance for non-symbolic codes. And the lack of good support for C/C++ in PyPy is not a technical limitation. It is an organizational one. There's nothing intrinsic in a fast VM that makes it more difficult to interface to C. An execution engine is an execution engine, and it is the object representation that determines how easy it is to interface to other languages. And PyPy is not the only JIT VM for python , there is also Jython that runs > of JVM and ironpython that runs on .NET and Mono. What those 3 have in > common ?that are used by a tiny crowd compared to people using cpython. > That could be because foreign VMs don't provide the support that users of a VM designed for a language expect, could it not? IMO this is a really important issue, especially for Smalltalk where we expect instance migration, contexts, etc, all of which one has to say goodbye to when hosted on a foreign VM. And this is a major reason for putting effort into one's own infrastructure. The truth is pure python libraries are a rarity . Why you think the most > popular , by far, implementation of python is called cpython ? I will give > you a hint, 50% of its source code is written in C. No thats not just the > VM its libraries and cpython comes with a lot of libraries included. > And that pure python libraries are a rarity is of course a result of the fact that Python has run to C whenever it needed performance. Hence when one comes to measure the speedup of a fast python against cpython it is difficult to see speedups because lots of benchmarks (e.g. many of the computer language shootout benchmarks) are spending much of their time running C code. Hint, if an app spends 50% of its time in C then it can never be more than twice as fast on a faster execution engine. Frankly I dont believe that any VM ever however fast will ever beat smooth > integration of C/C++ code unless you have a huge company to back you up > with an insane amount of libraries. Java had Sun , .NET has still > Microsoft. > Seriously, what do you mean "beat"? The world is infinitely varied. COBOL is still important and yet you seem to portray the entire programming field as reducing to some kind of horse race. What's the content here? Also what's the intent behind pissing contests? Seems rather teenage. Whereas being positive, doing good engineering and innovating can invent the future. Seem much more fun than doling out endless negativity. > For people that speed is a serious matter even if a VM is a mere 30% > slower than optimised C code, they will take the C code any day. > You contradicted yourself in claiming that Pythoners dont yse faster VMs. Java has good C integration and provides much better performance than PyPy so if you were correct Pythoners would be using Jython + C but you claim they're not. (Personally I'm dubious about blanket claims about what people do and don't do; my experience since I've been involved with commercial Smalltalk deployment is that the world is incredibly varied and different people with different requirements do different things, often for good reason). Speed is pretty meaningless unless you qualify it. In applications where performance can really matter theres always assembler (e.g. video decoders) or DSPs or... and often optimized C just doesn't hack it. But so what? There is another context where using Scheme to automatically generate Java VMs is critical to performance. And one can cite example after example where high performance does /not/ equal C/C++ plus an insane number of libraries. Computing is a broad church. There are plenty of contexts where time to market is the dominant factor and that can force one to reject performant and difficult to configure solutions (such as Jython, or Smalltalk + C), but equally there are contexts where time to market is the dominant factor and that can "force" one to use pure dynamic OOPLs because the world changes too fast to do anything else (e.g. finance). Anyway, keep those "nope"s coming. I love them. Time to patent your new way of proving a negative I think. -- best, Eliot

Sept. 18, 2014

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

by kilon alios

" 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. " nope , you are close but you got it the other way around. As a smalltalker you see it from purist way of view. For you Python is that language that got caught up on too reliance on C/C++ libraries. What you see as side effect is actually the central goal of python. The central goal of python was and still is to a great extend today to serve as scripting language for C and C++ code. This what made python so successful that a C/C++ coder could use on top of its app embedded inside its app. This why so many people use it even today. You also again wrong to assume that its a late thing that new VMs are developed for Python , PyPy which is very well known inside the python community has been around more than 12 years. Its a very performant JIT VM 2-10 faster than cpython. Why cpython has not ported to it ? because of not so good support for C/C++ , zero support for cpython libraries and of course because as they say it would complicate the development of cpython quite a lot . Its that situation that only a couple of people can decypher the magic of the VM and the rest of developer only hope for the best. And PyPy is not the only JIT VM for python , there is also Jython that runs of JVM and ironpython that runs on .NET and Mono. What those 3 have in common ?that are used by a tiny crowd compared to people using cpython. The truth is pure python libraries are a rarity . Why you think the most popular , by far, implementation of python is called cpython ? I will give you a hint, 50% of its source code is written in C. No thats not just the VM its libraries and cpython comes with a lot of libraries included. Frankly I dont believe that any VM ever however fast will ever beat smooth integration of C/C++ code unless you have a huge company to back you up with an insane amount of libraries. Java had Sun , .NET has still Microsoft. For people that speed is a serious matter even if a VM is a mere 30% slower than optimised C code, they will take the C code any day.

Sept. 18, 2014

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

by Bob Westergaard

Why not use #waitTimeoutMsecs:? Something like: greenLight := Semaphore new. process := [started := true. [Semaphore new wait] ensure: [terminator := Processor activeProcess. unwound := true]. greenLight signal] forkAt: Processor activeProcess priority -1. expired := greenLight waitTimeoutMSecs: 1000. "or whatever suits you" deny: expired. assert: process isTerminated. " and so on" -- Bob

Sept. 18, 2014

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

by Eliot Miranda

Hi Torsten, wow, what a great summary. Thanks. See below. On Wed, Sep 17, 2014 at 12:09 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > 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. > +1000. 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. > So so far I have pinning. But I'd love to hear more detail on sandboxing. I'm not sure about UUIDs. What about other mechanisms, namespaces, ClassBoxes? UUID sounds too much like an implementation to me. No one is proposing qualifying class names with UUIDs (Array:c5c09212-0c7d-44f3-81b7-18ae5d7f14d9 new: 5 ????). How about reitierating this more abstractly? 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... > Please, I'd love to have you write a fuller list. We could add it to the list at Cog Projects <http://www.mirandabanda.org/cogblog/cog-projects/> or add it to a "Directions" page or some such. But capturing these ideas is importasnt. >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.) > Well, mapping finished images a la VW's PermSpace is probably easier. The memory mapping in .Nt is extremely complex. But I get the requirement; ultra-fast start-up of small components. > >This we'll leave to the web framework designers, but it seems eminently > doable no? > > For sure. > > Bye > Torsten > thanks again. And give serious thought to carefully enunciating these requirements/this design sketch? -- best, Eliot

Sept. 18, 2014

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