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

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

by kilon alios

The problem with relying for everything on smalltalk code and not using existing technology is two fold a) You cannot compete with existing solution, they come with more manpower , have more features, better documention, more bug fixes, more, more ...... more b) One day the authors of the library decide to give up on the library because they went off to other things and of course it falls to the shoulders of others that are much less motivated and have other things in their plate too with higher priority for them. The library continues to improve but at a glacial pace. Its perfectly ok to try your own things and follow your own road. Everyone loves to experiment and do things his own way and that has many positive. But the general refusal to embrace existing technologies even problematic ones make the job of spreading the Smalltalk appeal much harder. Makes it harder for people to transition from other languages too. This smalltalk mentality is wrong. The end. On Tue, Sep 16, 2014 at 12:11 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Craig, > > On Mon, Sep 15, 2014 at 1:40 PM, Craig Latta <craig(a)netjam.org> wrote: > >> >> > I don't think anybody ever even reported trying [Ffenestri]. >> >> I did; it worked. And I just said so again a few messages ago. Hm. >> > > OK. It opens windows. But a snippet in a workspace can do that. It does > not constitute a replacement for the current window system though does it? > But Vassili's work can be. We had it in production at customer sites. We > could use it for development. It was complete, in the sense that one could > open arbitrary system windows as native windows, switch them back to > "virtual" windows, snapshot etc and everything would keep working. That's > "working". With great respect to Tim and John, their work in Ffenestri is > not the same thing, is it? By the same criteria I don't think what Qwaq > did constituted a real system; it allowed the login WIndow to be displayed > natively, but it didn't support development tools and it certainly didn't > support snapshot or dynamic switching. Being critical is not being > insulting. It's merely being objective. At least I hope I'm being > objective and not insulting anyone. It is not my intent. > > -- > best, > Eliot >

Sept. 16, 2014

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

by Thierry Goubier

2014-09-16 14:19 GMT+02:00 kilon alios <kilon.alios(a)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. Thierry

Sept. 16, 2014

Re: [Pharo-dev] Pharo Launcher Impressions

by kilon alios

Nope the default way is not to store anything in Documents, thats a folder completely controlled by the user the Default way to shared data between applications which is what pharo images are is exactly where PharoLauncher Stores its Images in MacOS. The folder is invisible because it is... well ... invisible, you can use this instruction to reveal your hidden folders https://www.mikesel.info/show-hidden-files-mac-os-x-10-7-lion/ I definitely do not want for any App to pollute my Documents folder, Doc folder is for me and me alone. I tried to port PharoLauncher to the terminal but I failed miserably understanding the code, but no creating arguments for the command line is not hard at all. On Tue, Sep 16, 2014 at 2:52 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Pretty cool! And the installers are a great touch. > > A few ideas: > 1. Wouldn't it make sense to cache the latest e.g. Pharo stable? > 2. I often like to launch my images from Mac Terminal windows so I can see > stdout. Would that be difficult to add? > > I still think the default Mac image location is wrong in principle - user > images belong under Documents, not Library - but at least it's changeable > now! For example, I can't use my pharo-ui script to launch via terminal > because ~/Library does not show up in the dialog to chose an image /because > it's not for documents/. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Pharo-Launcher-Impressions-tp4778314.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Sept. 16, 2014

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

by kilon alios

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.... On Tue, Sep 16, 2014 at 2:48 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-09-16 13:14 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > >> >> Don't worry/don't bother with thoses: you will never use Smalltalk or a >> VM :) It will never be certified by authorities, and the industry will >> never accept it. >> >> >> You are probably right for those two examples, but there are other >> not-so-regulated domains where real-time is useful - e.g. industrial >> automation and robotics. >> > > Real-time is usefull there, yes. But Smalltalk and Cog will never get > there. Except as a DSL / code generator tool (which means a MDE approach, > more or less). > > (And code generation is where Pharo to C or LLVM-IR gets us interested) > > Dynamic optimisations, lack of static typing: they will laugh you out in > any of those fields. > > Even if their developpers use Python behind their back. > > Thierry >

Sept. 16, 2014

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

by kilon alios

Is there any other documentation for Slang apart from the link in squeak wiki ? Hows Slang deals with manual memory management ? On Tue, Sep 16, 2014 at 12:48 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > 2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> Hi Ronie, >> >> On Mon, Sep 15, 2014 at 2:37 PM, Ronie Salgado <roniesalg(a)gmail.com> >> wrote: >> >>> >>> Hello, >>> >>> I am segmenting this mail in several sections. >>> >>> --------------------------------------------------------------- >>> - On Lowcode and Cog >>> >>> I have been working in the last week with the Cog VM, implementing the >>> Lowcode instructions in Cog. >>> >> >> remember to send me code for integration. I'm eagerly waiting to use >> your code! >> >> Lowcode is currently a spec of new bytecode instructions. These >>> instructions can be used for: >>> - Implementing a C like language compiler. >>> - Making FFI calls >>> >>> I am implementing these instructions using a feature of the new bytecode >>> set for SistaV1, which is called "inline primitives". Because of this, >>> these new instructions can be mixed freely with the standard VM bytecode >>> set. This also allows the Sista adaptive optimizer to inline FFI calls. >>> >>> These instructions provides features for: >>> - Int32 and Int64 integer arithmetic without type checking. >>> - Pointers, with arithmetics. >>> - Memory access and memory manipulation. >>> - Single and double precision floating point arithmetics. >>> - Conversion between primitive types. >>> - Boxing and unboxing of primitive types. >>> - Unchecked comparisons. >>> - Native function call. Direct and indirect calls. >>> - The atomic operation compare and swap. >>> - Object pin/unpin (requires Spur). >>> - VM releasing and grabbing for threaded ffi. >>> >>> Current I have implemented the following backends: >>> - A C interpreter plugin. >>> - A LLVM based backend. >>> >>> Currently I am working in getting this working using the Cog code >>> generator. So far I am already generating code for >>> int32/pointer/float32/float64. I am starting to generate C functions calls >>> and object boxing/unboxing. >>> >>> During this work I learned a lot about Cog. Specially that Cog is >>> missing a better Slang generator, that allows to force better inlining and >>> more code reviews. There is a lot of code duplication in Cog, that can be >>> attributed to limitations of Slang. In my opinion, if we could use Slang >>> not only for building the VM we should end with a better code generator. In >>> addition we, need more people working in Cog. We need people that performs >>> code reviews and documentation of Cog. >>> >>> After these weeks, I learned that working in Cogit it is not that hard. >>> Our biggest problem is lack of documentation. Our second problem could be >>> the lack of documentation about Slang. >>> >> > Lack of documentation ? > > About Cog there are these documentation: > Back to the future <http://ftp.squeak.org/docs/OOPSLA.Squeak.html> > About VMMaker <http://wiki.squeak.org/squeak/2105> > Object engine > <http://www.rowledge.org/resources/tim%27s-Home-page/Squeak/OE-Tour.pdf> > General information <http://squeakvm.org/index.html> > Blue book part 4 > <http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf> > Deep into Pharo part 4 about blocks and exceptions > <http://www.deepintopharo.com/> > VMIL paper about Cogit > <http://design.cs.iastate.edu/vmil/2011/papers/p03-miranda.pdf> > The Cog blog <http://www.mirandabanda.org/cogblog/> > About Spur: summary > <http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-me…> and > object format > <http://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/> > This post <http://clementbera.wordpress.com/2013/08/09/the-cog-vm-lookup/> > > And many useful class and method comments that taught me a lot. > > When I try to work with Pharo frameworks, even recent ones, it is very > rare that I see as much documentation than it exists for Cog. Some > frameworks are documented in the Pharo books and a few other as Zinc have > good documentation, but in general, there are few documentation and *even > fewer people writing documentation*. The website about Cog has existed > for over 6 years now. I think Cog is far from the worst documented part of > Pharo. > > >> Yes, and that's difficult because it's a moving target and I have been >> lazy, not writing tests, instead using the Cog VM as "the test". >> >> It's also difficult because the first tests to write are the hardest to > write. > > I am so happy to have your involvement. You and ClÃ©ment bring such >> strength and competence. >> >> --------------------------------------------------------------- >>> - Smalltalk -> LLVM ? >>> >>> As for having a Smalltalk -> LLVM code generator. The truth is that we >>> will not gain anything. LLVM is a C compiler, which is designed to optimize >>> things such as loops with lot of arithmetics. It is designed to optimize >>> large sections of code. In Smalltalk, most of our code is composed mostly >>> of message sends. LLVM cannot optimize a message send. >>> >>> To optimize a message send, you have to determine which is the method >>> that is going to respond to the message. Then you have to inline the >>> method. And then you can start performing the actual optimizations, such as >>> constant folding, common subexpressions, dead branch elimination, loop >>> unrolling, and a long etc. >>> >>> Because we don't have information in the actual language (e.g. static >>> types a la C/C++/Java/C#) that tells us what is going to be the actual >>> method invoked by a message send, we have the following alternatives to >>> determine it: >>> - Don't optimize anything. >>> - Perform a costly static global analysis of the whole program. >>> - Measure in runtime and hope for the best. >>> - Extend the language. >>> >>> In other words, our best bet is in the work of ClÃ©ment in Sista. The >>> only problem with this bet are real time applications. >>> >> >> Ah! But! Sista has an advantage that other adaptive optimizers don't. >> Because it optimizes from bytecode to bytecode it can be used during a >> training phase and then switched off. >> > >> Real time applications requires an upper bound guarantee in their >>> response time. In some cases, the lack of this guarantee can be just an >>> annoyance, as happens in video games. In some mission critical applications >>> the results can not be good, if this time constraint is not met. An example >>> of a mission critical system could the flight controls of an airplane, or >>> the cooling system of a nuclear reactor. >>> >>> For these application, it is not possible to rely in an adaptive >>> optimizer that can be triggered sometimes. In these application you have to >>> either: >>> - Extend the language to hand optimize some performance critical >>> sections of code. >>> - Use another language to optimize these critical section. >>> - Use another language for the whole project. >>> >> >> The additional option is to "train" the optimizer by running the >> application before deploying and capturing the optimised methods. Discuss >> this with ClÃ©ment and he'll explain how straight-forward it should be. >> This still leaves the latency in the Cogit when it compiles from bytecode >> to machine code. But >> >> a) I've yet to see anybody raise JIT latency as an issue in Cog >> 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. >> >> 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. >> > > The solution of Eliot makes sense. > To write a paper about that I need benchs showing result on real time > applications. > So there's quite some work to do before. > >> >> Greetings, >>> Ronie >>> >>> 2014-09-15 16:38 GMT-03:00 Craig Latta <craig(a)netjam.org>: >>> >>>> >>>> >>>> Hear hear! >>>> >>>> >>>> -C >>>> >>>> [1] http://tinyurl.com/m66fx8y (original message) >>>> >>>> -- >>>> Craig Latta >>>> netjam.org >>>> +31 6 2757 7177 (SMS ok) >>>> + 1 415 287 3547 (no SMS) >>>> >>>> >>> >>> >> >> >> -- >> best, >> Eliot >> >> >

Sept. 16, 2014

Pharo Launcher Impressions

by Sean P. DeNigris

Pretty cool! And the installers are a great touch. A few ideas: 1. Wouldn't it make sense to cache the latest e.g. Pharo stable? 2. I often like to launch my images from Mac Terminal windows so I can see stdout. Would that be difficult to add? I still think the default Mac image location is wrong in principle - user images belong under Documents, not Library - but at least it's changeable now! For example, I can't use my pharo-ui script to launch via terminal because ~/Library does not show up in the dialog to chose an image /because it's not for documents/. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-Launcher-Impressions-tp4778314.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 16, 2014

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

by Thierry Goubier

2014-09-16 13:14 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > Don't worry/don't bother with thoses: you will never use Smalltalk or a VM > :) It will never be certified by authorities, and the industry will never > accept it. > > > You are probably right for those two examples, but there are other > not-so-regulated domains where real-time is useful - e.g. industrial > automation and robotics. > Real-time is usefull there, yes. But Smalltalk and Cog will never get there. Except as a DSL / code generator tool (which means a MDE approach, more or less). (And code generation is where Pharo to C or LLVM-IR gets us interested) Dynamic optimisations, lack of static typing: they will laugh you out in any of those fields. Even if their developpers use Python behind their back. Thierry

Sept. 16, 2014

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

by Ben Coman

Sept. 16, 2014

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

by ClÃ©ment Bera

2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Ronie, > > On Mon, Sep 15, 2014 at 2:37 PM, Ronie Salgado <roniesalg(a)gmail.com> > wrote: > >> >> Hello, >> >> I am segmenting this mail in several sections. >> >> --------------------------------------------------------------- >> - On Lowcode and Cog >> >> I have been working in the last week with the Cog VM, implementing the >> Lowcode instructions in Cog. >> > > remember to send me code for integration. I'm eagerly waiting to use your > code! > > Lowcode is currently a spec of new bytecode instructions. These >> instructions can be used for: >> - Implementing a C like language compiler. >> - Making FFI calls >> >> I am implementing these instructions using a feature of the new bytecode >> set for SistaV1, which is called "inline primitives". Because of this, >> these new instructions can be mixed freely with the standard VM bytecode >> set. This also allows the Sista adaptive optimizer to inline FFI calls. >> >> These instructions provides features for: >> - Int32 and Int64 integer arithmetic without type checking. >> - Pointers, with arithmetics. >> - Memory access and memory manipulation. >> - Single and double precision floating point arithmetics. >> - Conversion between primitive types. >> - Boxing and unboxing of primitive types. >> - Unchecked comparisons. >> - Native function call. Direct and indirect calls. >> - The atomic operation compare and swap. >> - Object pin/unpin (requires Spur). >> - VM releasing and grabbing for threaded ffi. >> >> Current I have implemented the following backends: >> - A C interpreter plugin. >> - A LLVM based backend. >> >> Currently I am working in getting this working using the Cog code >> generator. So far I am already generating code for >> int32/pointer/float32/float64. I am starting to generate C functions calls >> and object boxing/unboxing. >> >> During this work I learned a lot about Cog. Specially that Cog is missing >> a better Slang generator, that allows to force better inlining and more >> code reviews. There is a lot of code duplication in Cog, that can be >> attributed to limitations of Slang. In my opinion, if we could use Slang >> not only for building the VM we should end with a better code generator. In >> addition we, need more people working in Cog. We need people that performs >> code reviews and documentation of Cog. >> >> After these weeks, I learned that working in Cogit it is not that hard. >> Our biggest problem is lack of documentation. Our second problem could be >> the lack of documentation about Slang. >> > Lack of documentation ? About Cog there are these documentation: Back to the future <http://ftp.squeak.org/docs/OOPSLA.Squeak.html> About VMMaker <http://wiki.squeak.org/squeak/2105> Object engine <http://www.rowledge.org/resources/tim%27s-Home-page/Squeak/OE-Tour.pdf> General information <http://squeakvm.org/index.html> Blue book part 4 <http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf> Deep into Pharo part 4 about blocks and exceptions <http://www.deepintopharo.com/> VMIL paper about Cogit <http://design.cs.iastate.edu/vmil/2011/papers/p03-miranda.pdf> The Cog blog <http://www.mirandabanda.org/cogblog/> About Spur: summary <http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-me…> and object format <http://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/> This post <http://clementbera.wordpress.com/2013/08/09/the-cog-vm-lookup/> And many useful class and method comments that taught me a lot. When I try to work with Pharo frameworks, even recent ones, it is very rare that I see as much documentation than it exists for Cog. Some frameworks are documented in the Pharo books and a few other as Zinc have good documentation, but in general, there are few documentation and *even fewer people writing documentation*. The website about Cog has existed for over 6 years now. I think Cog is far from the worst documented part of Pharo. > Yes, and that's difficult because it's a moving target and I have been > lazy, not writing tests, instead using the Cog VM as "the test". > > It's also difficult because the first tests to write are the hardest to write. I am so happy to have your involvement. You and ClÃ©ment bring such > strength and competence. > > --------------------------------------------------------------- >> - Smalltalk -> LLVM ? >> >> As for having a Smalltalk -> LLVM code generator. The truth is that we >> will not gain anything. LLVM is a C compiler, which is designed to optimize >> things such as loops with lot of arithmetics. It is designed to optimize >> large sections of code. In Smalltalk, most of our code is composed mostly >> of message sends. LLVM cannot optimize a message send. >> >> To optimize a message send, you have to determine which is the method >> that is going to respond to the message. Then you have to inline the >> method. And then you can start performing the actual optimizations, such as >> constant folding, common subexpressions, dead branch elimination, loop >> unrolling, and a long etc. >> >> Because we don't have information in the actual language (e.g. static >> types a la C/C++/Java/C#) that tells us what is going to be the actual >> method invoked by a message send, we have the following alternatives to >> determine it: >> - Don't optimize anything. >> - Perform a costly static global analysis of the whole program. >> - Measure in runtime and hope for the best. >> - Extend the language. >> >> In other words, our best bet is in the work of ClÃ©ment in Sista. The only >> problem with this bet are real time applications. >> > > Ah! But! Sista has an advantage that other adaptive optimizers don't. > Because it optimizes from bytecode to bytecode it can be used during a > training phase and then switched off. > > Real time applications requires an upper bound guarantee in their response >> time. In some cases, the lack of this guarantee can be just an annoyance, >> as happens in video games. In some mission critical applications the >> results can not be good, if this time constraint is not met. An example of >> a mission critical system could the flight controls of an airplane, or the >> cooling system of a nuclear reactor. >> >> For these application, it is not possible to rely in an adaptive >> optimizer that can be triggered sometimes. In these application you have to >> either: >> - Extend the language to hand optimize some performance critical sections >> of code. >> - Use another language to optimize these critical section. >> - Use another language for the whole project. >> > > The additional option is to "train" the optimizer by running the > application before deploying and capturing the optimised methods. Discuss > this with ClÃ©ment and he'll explain how straight-forward it should be. > This still leaves the latency in the Cogit when it compiles from bytecode > to machine code. But > > a) I've yet to see anybody raise JIT latency as an issue in Cog > 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. > > 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. > The solution of Eliot makes sense. To write a paper about that I need benchs showing result on real time applications. So there's quite some work to do before. > > Greetings, >> Ronie >> >> 2014-09-15 16:38 GMT-03:00 Craig Latta <craig(a)netjam.org>: >> >>> >>> >>> Hear hear! >>> >>> >>> -C >>> >>> [1] http://tinyurl.com/m66fx8y (original message) >>> >>> -- >>> Craig Latta >>> netjam.org >>> +31 6 2757 7177 (SMS ok) >>> + 1 415 287 3547 (no SMS) >>> >>> >> >> > > > -- > best, > Eliot > >

Sept. 16, 2014

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

by phil＠highoctane.be

On Tue, Sep 16, 2014 at 9:52 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > Dne pondÄlÃ 15. zÃ¡ÅÃ 2014 phil(a)highoctane.be <phil(a)highoctane.be> > napsal(a): > >> Slang has been externalized by Pavel. So, Smalltalk to C works. >> >> Works nicely, even if there were a few glitches (like code generated >> twice at one point). >> Nothing unfixable, I got the beast working. >> >> Allows for things like: write Slang, generate C, compile into DLL, load >> DLL, run C code. All in a single shot. >> >> PavelKrivanek/CCodeGenerator on SmalltalkHub (which looks like super >> slow/zombified). >> >> Phil >> >> > I hope only super slow :-) I simply have no time for this project now. > Help is welcome. > > I was speaking about Smalltalkhub, not your project :-) Phil > -- Pavel > > > >> >> >> >> >> >> >> On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo < >> santiagobragagnolo(a)gmail.com> wrote: >> >>> I may be wrong, but I think the closest thing out there is Slang. Is >>> the pseudo smalltalk used to develop the VM. >>> >>> Also there is a project for generating C for arduino, (a project related >>> with EToys), but i am not sure about how complete is. >>> >>> >>> >>> 2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >>> >>>> Is there a way to convert code from pharo to c or c++ ? Does pettit >>>> parser or other parsers offer such support ? >>>> >>> >>> >>

Sept. 16, 2014