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

Re: [Pharo-dev] #doSemanticAnalysisIn: error

by Esteban A. Maringolo

Well... I have all the sources and changes. But when this happens it seems the image/vm gets in a limbo, saying PharoV30.sources wasn't found, etc. My error was raised by a infinite recursion involving a #halt sent during the printOn: (which sends #javascriptOn: in this case). This is the offending call stack that got recursive. Halt DTAjax>>javascriptOn: LimitedWriteStream(Stream)>>javascript: DTAjax(JSObject)>>printOn: DTAjax(Object)>>printStringLimitedTo: in Block: [ :s | self printOn: s ] String class(SequenceableCollection class)>>streamContents:limitedTo: DTAjax(Object)>>printStringLimitedTo: MethodContext>>printDetails: in Block: [ receiver printStringLimitedTo: 90 ] BlockClosure>>on:do: BlockClosure>>ifError: MethodContext>>printDetails: MethodContext(ContextPart)>>errorReportOn: SmalltalkImage>>logError:inContext: in Block: [ :logger | ... SmalltalkImage>>logDuring: in Block: [ ... BlockClosure>>ensure: SmalltalkImage>>logDuring: SmalltalkImage>>logError:inContext: MorphicUIManager>>openDebuggerOn:context:label:contents:fullView: in Block: [ ... BlockClosure>>on:do: MorphicUIManager>>openDebuggerOn:context:label:contents:fullView: SpecDebugger class>>openOn:context:label:contents:fullView: SpecDebugger class>>debugError: MorphicUIManager>>unhandledErrorDefaultAction: Halt>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: Halt (starts over...) Esteban A. Maringolo 2014-09-15 15:47 GMT-03:00 Damien Cassou <damien.cassou(a)gmail.com>: > On Mon, Sep 15, 2014 at 8:01 PM, Esteban A. Maringolo > <emaringolo(a)gmail.com> wrote: >> Why is this? Is it a know bug? > > > is it possible that you don't have the source code of your image? Both > the .changes and .sources must be available > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

Sept. 15, 2014

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

by Eliot Miranda

On Sun, Sep 14, 2014 at 10:07 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-09-14 18:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > >> Plenty ? no >> >> A few ? yes >> >> Woden is certainly a project that I want it to be successful and keep >> going forward but at the moment I can't say its usable when each time I >> resize the window it corrupts the viewport. >> >> No offense intended but lately the more I dive inside Pharo the more I >> feel I waste my time, I love the IDE and the environment and live coding >> but using the libraries is a never ending struggle for me. I agree with >> Nicolai the landscape is not good, Pharo really lacks mature libraries . >> Sure we like to bash Java but Java libs are rock solid and very well >> documented. I bring Java as example. Again I am not complaining at all, I >> knew when I came to Pharo that I will have to face these limitations. I >> also don't feel comfortable asking questions all the time as if I want >> others to do my code but I did not have much of a choice. I just cant deal >> with the lack of documentation any more. >> >> I think Pharo as a general idea is great , you definitely have taken the >> Squeak fork one big step further but you have a very long road ahead of you >> to make Pharo a modern environment. Asking for animating a window with good >> performance is one of the very basics of a good GUI API. I know you have >> limited resources and once again I am not complaining at all I just present >> my opinion. Its clear that Pharo needs a lot more people to contribute and >> bring the system forward at least to solve the basic problems. >> > > This is definitly wrong :) > Especially the older squeak versions were ahead of its time with > (animated) interactive UI elements. > Java (Swing) does not come with an animation framework for the UI (JavaFX, > yes but that took its time). > There was a timing/animation framework used by Roman Guy for its > FilthyRich clients, that did really look great. > He created UIs that never looked like ordinary Java UIs. But I think that > was done by few people only. > So, doing this for pharo should be doable. (I do remember something like > that was done for > Morphic (maybe this one: > https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki… > )) > > yoiu can do great thinks with Qt for C++ simple animation with the good > old qwidget and > the newer qml-framework. That's what I would call feature UIs (mostly what > is done nowadays on mobile devices and other > "platforms" have their own frameworks (java)android and Object-C (IPhone). > > And I think we will see more "feature"-UI on the web with > HTML5/Canvas/Web-GL. > > Do we need a good new UI framework for pharo? Yes. > Do we need many developers for working on this ? No, I think a handfull > (2-4) people would be enough. > What pharo really needs are: > Many more developers *using* pharo as a platform. > Agreed. But one real problem with the Squeak/Pharo UI is the lack of native windows. There is an old project Graphics-External-Ffenestri but AFAICT it isn't being used. But there /is/ a really good prototype of a native window system above Squeak done by Vassili Bykov in Newspeak. The native windows contain morphs, but anything, including MVC, can be present. This provides native Win32 Windows (doing other platforms is merely work) /and/ the ability to snapshot and bring back up windows on a different platform (e.g. open in win32, snapshot and bring up in Squeak/Pharo Morphic windows, or vice verse), and the ability to do this dynamically. Is anyone motivated to port the Newspeak code back to Squeak/Pharo? If you're interested, contact me, or Vassili, or Bob Westergaard and ask about Brazil (think plumbing). nicolai > > > > >> >> Thank you all people who helped me. But I don't think it worths to make >> my project in Pharo, too many problems. I feel privileged to have helped >> you with my contributions , I wish the Pharo the best. >> >> I could return back to Python but I think its time for me to bite the >> bullet and learn C/C++, since graphics is an area that deeply interest me >> (more as an artist less as a coder), so I don't have much of choice. Maybe >> I can brings some of my code back to Pharo with NB wrappers , I definitely >> will keep a close eye on Pharo. >> >> In a few months I will also present to the Pharo community a secret last >> contribution ;) >> >> On Sun, Sep 14, 2014 at 6:26 PM, phil(a)highoctane.be <phil(a)highoctane.be> >> wrote: >> >>> Do you know anything better for futuristic UIs at the moment? >>> >>> I guess that we aren't talking about commercial dev here. And if we >>> would rely on everything being documented in Pharo, errr, we wouldn't go >>> too far. >>> >>> That being said, there are plenty of examples in the Woden code. >>> >>> Phil >>> Le 14 sept. 2014 16:28, "Nicolai Hess" <nicolaihess(a)web.de> a Ã©crit : >>> >>> Why should he use it, now? >>>> I mean, is there a stable API? Or a roadmap ? >>>> >>>> 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 :) >>>> >>>> >>>> >>>> >>>> >>>> 2014-09-14 14:13 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>>> >>>>> Why not use Woden? >>>>> >>>>> Phil >>>>> Le 14 sept. 2014 12:51, "kilon alios" <kilon.alios(a)gmail.com> a >>>>> Ã©crit : >>>>> >>>>> yeah I am afraid transparency is very important to me >>>>>> >>>>>> On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess <nicolaihess(a)web.de> >>>>>> wrote: >>>>>> >>>>>>> 2014-09-14 11:32 GMT+02:00 stepharo <stepharo(a)free.fr>: >>>>>>> >>>>>>>> I remember that there was an animated gif support. >>>>>>>> Now I do not remember exactly. >>>>>>>> >>>>>>> >>>>>>> At least in squeak there is an AnimatedImageMorph, that can load and >>>>>>> display animated gifs. >>>>>>> That works and is quite fast even for multiple instances. But of >>>>>>> course no (alpha-)transparency >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> for roassal2 have a look at the viva classes: this is the animation >>>>>>>> frameworks that igor designed. >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 14/9/14 10:22, kilon alios 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) . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> > -- best, Eliot

Sept. 15, 2014

Re: [Pharo-dev] #doSemanticAnalysisIn: error

by Damien Cassou

On Mon, Sep 15, 2014 at 8:01 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Why is this? Is it a know bug? is it possible that you don't have the source code of your image? Both the .changes and .sources must be available -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Sept. 15, 2014

Re: [Pharo-dev] GToolkit

by Esteban A. Maringolo

2014-09-15 14:50 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Estaban, > > On Mon, Sep 15, 2014 at 3:30 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: >> >> 2014-09-14 15:53 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: >> > Hi Phil, >> >> > It would be cool to know the reasons why people have to use other tools. >> > Perhaps we can do something about it. >> >> If it involves text edition or manipulation, I use external tools >> because of the lack of certain features in Pharo workspaces (or even >> syntax highlighting limits) or due to the comfort I find in using the >> same key bindings/shortcuts I use everywhere to edit a csv file, SQL >> script, chunk or whatever. That's one of the reasons. :) > Could we go into details here? I am genuinely interested in collected these > use cases. Sure. > As noted before, syntax highlighting is now supported in GToolkit via > Rubric. I haven't used Rubric. So I can't really talk about it. But text editing speed in Pharo is perceivable slower than, ej, Notepad++ or gVim. It won't affect the normal use, because most methods are small, but as the code gets larger it slows down (exponentially?). > What kind of keybindings are we talking about? I'm referring to common Windows keybindings: Ctrl+arrow, Ctrl+Home, Ctrl+Shift+End, Ctrl+F, Ctrl+H, Ctrl+A, etc. Some are supported by Pharo, others don't. Regards! Esteban A. Maringolo

Sept. 15, 2014

Re: [Pharo-dev] TestCoverage magic?

by Yuriy Tymchuk

Thanks, because I started to think that this are things beyond my OO knowledge :) Uko > On 15 Sep 2014, at 18:42, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > It might be that it just does not work right now... > > On Mon, Sep 15, 2014 at 5:53 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Hi everyone, > > Iâm trying to understand how current coverage works and executing "TestCoverage new" returns nilâ¦ and "TestCoverage class>>#on:â sends #initializeOn: to that nil. > > Iâll be very thankful for explanation. > Uko > > > > -- > -- > Marcus Denker -- denker(a)acm.org <mailto:denker@acm.org> > http://www.marcusdenker.de <http://www.marcusdenker.de/>

Sept. 15, 2014

#doSemanticAnalysisIn: error

by Esteban A. Maringolo

>From time to time when I halt the execution (or try to halt it) I get walkbacks reporting a MNU in nil #doSemanticAnalaysisIn: nil Now after hiting Alt+. for a while I was able to recover the control of the image, but when selecting the "Morphic UI process" in the process explorer I get a similar walkback (see screenshot). Why is this? Is it a know bug? Esteban A. Maringolo

Sept. 15, 2014

Re: [Pharo-dev] GToolkit

by Tudor Girba

Hi Estaban, On Mon, Sep 15, 2014 at 3:30 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-09-14 15:53 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi Phil, > > > It would be cool to know the reasons why people have to use other tools. > > Perhaps we can do something about it. > > If it involves text edition or manipulation, I use external tools > because of the lack of certain features in Pharo workspaces (or even > syntax highlighting limits) or due to the comfort I find in using the > same key bindings/shortcuts I use everywhere to edit a csv file, SQL > script, chunk or whatever. That's one of the reasons. :) > Could we go into details here? I am genuinely interested in collected these use cases. As noted before, syntax highlighting is now supported in GToolkit via Rubric. What kind of keybindings are we talking about? Another one is that I found the option to do things externally to be > "safer" than relying on a unique tool to do all the tasks. > "Rule of Composition" and "Rule of Modularity" according to the Unix > Philosophy. Not to mention the "Rule of Parsimony": Write a big program only when > it is clear by demonstration that nothing else with do. :) > I think we should not mistaken big for powerful and neither should we do it the other way around. If there is anything we show in Pharo is that we can do small and powerful. But, please keep in mind that I am referring to activities that you would like to do without leaving your objects. Cheers, Doru > Regards! > > Esteban A. Maringolo > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 15, 2014

Re: [Pharo-dev] TestCoverage magic?

by Marcus Denker

Hi, It might be that it just does not work right now... On Mon, Sep 15, 2014 at 5:53 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi everyone, > > Iâm trying to understand how current coverage works and executing > "TestCoverage new" returns nilâ¦ and "TestCoverage class>>#on:â sends > #initializeOn: to that nil. > > Iâll be very thankful for explanation. > Uko > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Sept. 15, 2014

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

by phil＠highoctane.be

On Mon, Sep 15, 2014 at 6:23 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > On Mon, Sep 15, 2014 at 6:01 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2014-09-15 14:39 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >>> Hello, >>> >>> Note that slang is a subset of smalltalk. The Slang compiler does not >>> allow to compile smalltalk to C. It allows to compile a smalltalk with >>> restricted message sends and classes to C. >>> >> >> Yes, I am aware of that. I remember that from the very beginnings of >> Squeak. >> >> Wasn't Smalltalk/X the one which had a more complete version of that C >> translation? I did an internship in a French company who had a Smalltalk to >> C translator done for them a long time ago. >> >> >>> >>> 2014-09-15 13:28 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >>> >>>> Hi Phil, >>>> >>>> thanks for the update on Slang to C. Allways significant to have that. >>>> >>> >>>> Two open questions: >>>> >>>> - would a slang to x86 asm via NativeBoost be doable / a nice target? >>>> >>> >>> Yes it would be interesting. However, by having a Slang to C compiler, >>> we're platform-independent, we can compile the C code to x86, x86_64 and >>> ARM quite easily (some part of the VM are already processor dependent, but >>> not so much). Targeting direct machine code implies evolving the Slang >>> compiler for each new assembly code we support. It sounds like a lot of >>> engineering work compared to our resources and the gain. >>> >> >> It would allow JIT-type compilation experiments than a Slang-to-C chain >> isn't designed for :) With a lot more work doing the various NB ports, of >> course. >> >> >>> >>>> - would targetting LLVM-IR be of interest? >>>> >>>> If you compile the C code with Clang instead of gcc, which starts to be >>> the case because of the lack of support for gcc in the latest Mac OS X, you >>> are already using LLVM IR because Clang uses it. As the VM use the GNU C >>> extensions to improve performance, I do not think that targeting directly >>> the LLVM IR would greatly improve performance. So it sounds like quite some >>> engineering work for no gain. >>> >> >> I would not suggest replacing C by LLVM-IR for VM work, in part because >> LLVM-IR is not what I would call a readable source code format... But I do >> know that even when doing C to C rewritting for embedded compilation, there >> is some low-level code that you can't write in C. >> > > I find this whole discussion depressing. It seems people would rather put > their energy in chasing quick fixes or other technologies instead of > contributing to the work that is being done in the existing VM. > Why so? I am all in for using the VM based technology. Slang is great. Now, we need to interface with the outside world, and then it is C-based at one point. > People discuss using LLVM as if the code generation capabilities inside > Cog were somehow poor or have no chance of competing. Spur is around twice > as fast as the current memory manager, has much better support for the FFI. > ClÃ©ment and I, now with help from Ronie, are making excellent progress > towards an adaptive optimizer/speculative inliner that will give us similar > performance to V8 (the Google JavaScript VM, lead by Lars Bak, who > implemented the HotSpot VM (Smalltalk and Java)) et al. > Super, that's why I bet my company business on Pharo for software development. I trust you guys. > We are trying to get person-power for a high-quality FFI and have a > prototype for a non-blocking VM. When we succeed C won't be any better and > so it won't be an interesting target. One will be able to program entirely > in Smalltalk and get excellent performance. But we need effort. > Collaboration. > Ah, non blocking VM, a super cool thing to have. I am going through hoops at the moment to avoid doing direct SNMP calls to devices from Pharo... > > Personally I feel so discouraged when people talk about using LLVM or > libffi or whatever instead of having the courage and energy to make our > system world-class. I have the confidence in our abilities to compete with > the best and am saddened that people in the community don't value the > technology we already have and can't show faith in our abilities to improve > it further. Show some confidence and express support and above all get > involved. > That's well said. Let's race to the top! > > Collaborators <http://www.mirandabanda.org/cogblog/collaborators/> > Cog Projects <http://www.mirandabanda.org/cogblog/cog-projects/> > Spur 1/3 > <https://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyR…> > Spur, a new object representa... > <http://www.slideshare.net/esug/spur-a-new-object-representation-for-cog> > Sista: Improving Cog's JIT performance 1/2 > <https://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Y…> > Sista: Improving Cogâs JIT pe > <http://www.slideshare.net/esug/sista-talkesug2>.. > Lowcode: Redoing NativeBoost ... > <http://www.slideshare.net/esug/03-lowcodeslides> > All very interesting things indeed. Now, doing application level code at the moment, I can't really dig into these. But I can use them and kick ass! > > > However, I think Ronie was interested in doing such work. If he succeeds >>> and reports performance improvement, then we can consider using his >>> compiler to compile the VM. >>> >> >> Keep us posted! >> >> Thierry >> > > -- > in hope, > > Eliot >

Sept. 15, 2014

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

by Eliot Miranda

Hi All, On Mon, Sep 15, 2014 at 6:01 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-09-15 14:39 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> Hello, >> >> Note that slang is a subset of smalltalk. The Slang compiler does not >> allow to compile smalltalk to C. It allows to compile a smalltalk with >> restricted message sends and classes to C. >> > > Yes, I am aware of that. I remember that from the very beginnings of > Squeak. > > Wasn't Smalltalk/X the one which had a more complete version of that C > translation? I did an internship in a French company who had a Smalltalk to > C translator done for them a long time ago. > > >> >> 2014-09-15 13:28 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >>> Hi Phil, >>> >>> thanks for the update on Slang to C. Allways significant to have that. >>> >> >>> Two open questions: >>> >>> - would a slang to x86 asm via NativeBoost be doable / a nice target? >>> >> >> Yes it would be interesting. However, by having a Slang to C compiler, >> we're platform-independent, we can compile the C code to x86, x86_64 and >> ARM quite easily (some part of the VM are already processor dependent, but >> not so much). Targeting direct machine code implies evolving the Slang >> compiler for each new assembly code we support. It sounds like a lot of >> engineering work compared to our resources and the gain. >> > > It would allow JIT-type compilation experiments than a Slang-to-C chain > isn't designed for :) With a lot more work doing the various NB ports, of > course. > > >> >>> - would targetting LLVM-IR be of interest? >>> >>> If you compile the C code with Clang instead of gcc, which starts to be >> the case because of the lack of support for gcc in the latest Mac OS X, you >> are already using LLVM IR because Clang uses it. As the VM use the GNU C >> extensions to improve performance, I do not think that targeting directly >> the LLVM IR would greatly improve performance. So it sounds like quite some >> engineering work for no gain. >> > > I would not suggest replacing C by LLVM-IR for VM work, in part because > LLVM-IR is not what I would call a readable source code format... But I do > know that even when doing C to C rewritting for embedded compilation, there > is some low-level code that you can't write in C. > I find this whole discussion depressing. It seems people would rather put their energy in chasing quick fixes or other technologies instead of contributing to the work that is being done in the existing VM. People discuss using LLVM as if the code generation capabilities inside Cog were somehow poor or have no chance of competing. Spur is around twice as fast as the current memory manager, has much better support for the FFI. ClÃ©ment and I, now with help from Ronie, are making excellent progress towards an adaptive optimizer/speculative inliner that will give us similar performance to V8 (the Google JavaScript VM, lead by Lars Bak, who implemented the HotSpot VM (Smalltalk and Java)) et al. We are trying to get person-power for a high-quality FFI and have a prototype for a non-blocking VM. When we succeed C won't be any better and so it won't be an interesting target. One will be able to program entirely in Smalltalk and get excellent performance. But we need effort. Collaboration. Personally I feel so discouraged when people talk about using LLVM or libffi or whatever instead of having the courage and energy to make our system world-class. I have the confidence in our abilities to compete with the best and am saddened that people in the community don't value the technology we already have and can't show faith in our abilities to improve it further. Show some confidence and express support and above all get involved. Collaborators <http://www.mirandabanda.org/cogblog/collaborators/> Cog Projects <http://www.mirandabanda.org/cogblog/cog-projects/> Spur 1/3 <https://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyR…> Spur, a new object representa... <http://www.slideshare.net/esug/spur-a-new-object-representation-for-cog> Sista: Improving Cog's JIT performance 1/2 <https://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Y…> Sista: Improving Cogâs JIT pe <http://www.slideshare.net/esug/sista-talkesug2>.. Lowcode: Redoing NativeBoost ... <http://www.slideshare.net/esug/03-lowcodeslides> However, I think Ronie was interested in doing such work. If he succeeds >> and reports performance improvement, then we can consider using his >> compiler to compile the VM. >> > > Keep us posted! > > Thierry > -- in hope, Eliot

Sept. 15, 2014