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

Re: [Pharo-dev] AppeX

by Tudor Girba

Hi Thierry, Thanks for the feedback. Indeed, the styling part works fine. What I do is have a first level parser that creates commands for styling. When I detect a Smalltalk block, the command delegates further to Shout. I guess that this type of design will be useful also for handling Helvetia multi languages. But, we still cannot have actions that are segment specific :). I would love to be able to have some sort of composite editor where the leaf editors correspond to a segment. Cheers, Doru On Tue, Sep 16, 2014 at 11:10 PM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Hi Doru, > > I'm looking through it. Interestingly simple :) You do have the styler > inside another styler stuff working (smalltalk code styler inside a Pillar > code bloc) which is very neat. > > > > Thierry > > Le 15/09/2014 06:44, Tudor Girba a Ã©crit : > > Hi, > > As you could see in the Pillar highlighting support, Rubric can now > handle any syntax highlighting in a rather straightforward way. You can > also easily embed this in a Glamour browser. > > You can see the example in the GT-InspectorExtensions-Pillar. You can > load the code in a Moose image like this: > Gofer new > smalltalkhubUser: 'Pier' project: 'Pillar'; > configuration; > loadStable. > Gofer new > smalltalkhubUser: 'JanKurs' project: 'PetitParser'; > configurationOf: #PetitParserIslands; > load. > #ConfigurationOfPetitParserIslands asClass loadDevelopment. > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-Pillar'; > load. > > Cheers, > Doru > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 17, 2014

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

by Esteban A. Maringolo

2014-09-16 20:12 GMT-03:00 Torsten Bergmann <astares(a)gmx.de>: > Smalltalk should/could have a place in this (web centric) world: > > 1. As a backend to serve the web > 2. On the client > 3. Combining 1. and 2. 1. This is were I see it stronger today, and I'm sure it is the majority of Pharo based solutions. 2. I can't tell. I really don't know if there are any software products built with Pharo/Squeak that DEPEND on Morphic exclusive features other than Qwac/Teleplace and Pharo/Squeak itself. Unless you're building something crazy/amazing I don't see the advantage of Morphic/Custom drawn UI over traditional widgets, even HTML widgets. > But we should also rethink Smalltalk to find a better place as a scripting language. What > I still would like to see: > > - tiny and fast VM with a command line and REPL The Pharo VM is really fast, and according to all I'm reading here regarding Sista and the CogVM itself is going to get faster. It's startup time is fast even for a 40 MB image, smaller images boot faster. The REPL is doable with today's version, I even think there was a REPL implementation out there. The scripting part needs some tweaks to current CommandLineHandlers, maybe using getops like parameters. > - single small base image but fast loadable binary code components (modules, maybe using the > LoadLibrary trick), similar to what David had with SmallScript or what BeeSmalltalk is doing with SLL's VisualSmalltalk also had SLL's that could load lots of code really fast. And the VM itself was fast too. I developed with VSE and it was really cool being able to deploy "parts" of your app and bind them at demand and/or update only a particular module. As any library, it also introduced some dependency hell, so it had its tradeoffs. > - but still with the ability to bootstrap up to a full saveable image > - ability to serve the web with easy callbacks into Smalltalk for implementing functionality > (especially with this we may catch 90% of the usual UI cases). You mean async I/O? If you look at the HTTP2/SPDY drafts or discussions, what I see is that it is going to speed up communications a lot, it will still be text based, but I think binary data is going to be there too, so the cost of HTTP messaging for intercommunication is going to be cheaper in the future. Regards! Esteban A. Maringolo

Sept. 17, 2014

Re: [Pharo-dev] How production ready is Pharo on SQLServer?

by Sebastian Sastre

I'm trying to follow instructions from here: http://dbxtalk.smallworks.eu/DBXTalkDrivers/compiling-and-installing-opendb… but the link about the binaries for Windows is broken suggestions? from iPad > On 12/09/2014, at 17:21, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > > ok, I'll try dbx and think of odbc as plan b > > from iPad > >> On 12/09/2014, at 17:14, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: >> >> DBXTalk is probably right. If it doesn't work, the old ODBC package will work - I have tried that later one (not against SQLServer, but it's just ODBC, so will work). >> >> -cbc >> >>> On Fri, Sep 12, 2014 at 12:37 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> 2014-09-11 17:48 GMT-03:00 Sebastian Sastre <sebastian(a)flowingconcept.com>: >>> > Hi guys, >>> > >>> > there is a project that needs to connect and extend a system using SQLServer >>> > and Pharo is being considered for the backend. >>> > >>> > Just checking, how ready are we for a production-ready backend using Pharo >>> > on SQLServer? >>> >>> (absent) >>> >>> > and how do we connect to it? >>> >>> DBXTalk, probably, but really can't tell. >>> >>> Database connectivity, other than PostgreSQL seems to be rather >>> infrequent, if used at all. >>> >>> >>> Esteban A. Maringolo >>> >>

Sept. 17, 2014

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

by David T. Lewis

On Mon, Sep 15, 2014 at 11:28:24AM +0200, Santiago Bragagnolo wrote: > I may be wrong, but I think the closest thing out there is Slang. Is the > pseudo smalltalk used to develop the VM. > A bit off topic, but just for clarification: "Slang" is not a language. It is just a casual name to refer to the subset of Smalltalk that can be easily translated to a language such as C. Some of this Smalltalk may be written in awkward ways in order to make sure it can be translated to a lower level language, but it is real Smalltalk nonetheless. The VM is not written in Slang, it is written in Smalltalk. When people talk about running the VM simulator, they are talking about running the VM in its native Smalltalk implementation, as opposed to running the code that is more commonly translated to C and linked to the platform support code. There is no psuedo Smalltalk involved, it is the real thing. Dave

Sept. 17, 2014

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

by Sean P. DeNigris

Eliot Miranda-2 wrote > without losing window > state, and one can switch dynamically, and, IIRC, mix both That /is/ cool :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/The-Dilemma-Building-a-Futuristic-GUI-for-Ephestos-tp… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 17, 2014

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

by Torsten Bergmann

Hi Eliot, Yes - in the past most Smalltalks did not have native widgets and usually emulated the L&F. I remember VW on a Sun Sparc with Windows or Mac look. While it was cool to run 1:1 on another machine it would have been to much manpower for the vendor to reimplement all the nice widgets to really look like the native system. Especially when the L&F changed very often between Win95/96/XP/Win7/Win8 at Microsoft. Even with good looking widgets/icons one could see from the speed and repainting issues (white rectangles for damage areas) that Smalltalk was not native. Also native widgets had other nice features like virtual modes for TreeViews/ListViews used if you want to display many nodes. Java faced the same problem - even with Swing and JavaFX today the Java UIs and especially the ugly JFileDialog never had this "Native look and easy navigation feeling". And yes there is SWT in Java providing native widgets - but how many applications are based on it? Only a few. On the ST side Smalltalk/MT and Dolphin use native widgets but were not portable. And if you look at others like VW, VAST or Smalltalk/X you will see that engineers are good at creating powerfull systems but often fail when it comes to UI design and usability. Squeak was special and flexible with Morphic (even without multiple windows) - but looked too toyish. So yes - customers of commercial Smalltalk vendors asked for "Native" because if you had built a UI in Smalltalk it was part of a rich client application and often people compared it to other native applications or new widgets found in MS Office. But in the past customer also asked for COM/COM+, CORBA and webservices while today it is often much easier to exchange data or call functionality via HTTP, REST, ... So time and expectations have changed a lot meanwhile. Especially for the UI's. Desktop platforms unite with the web and in the web it is also possible to look more like platforms or style to look like a native app. See [1] and [2] for two simple examples. While the browsers and JS engines become faster this will also change more the way we think about applications: no installation, styleable, clear look. The google chrome experiments are a good page to see how this will soon look like. And we will be independent from devices and screen resolution. In fact more and more applications we use today run on a computers webbrowser, tablet or a smartphone (often the same way). With Morphic (even when it has Fenestri) we can not compete agains HTML/CSS on the UI side. The Canvas element and WebGL will also drive this forward. Even if one does not like web technologies - it currently is the platform where you reach people easily. Smalltalk should/could have a place in this (web centric) world: 1. As a backend to serve the web 2. On the client 3. Combining 1. and 2. For the first we have Seaside, TeaPot, Aida, ... For the seond: as it will not happen that browser vendors agree and threw out JavaScript in favour of ST runtimes, maybe we can build on top like Amber or SqueakJS do. But we should also rethink Smalltalk to find a better place as a scripting language. What I still would like to see: - tiny and fast VM with a command line and REPL - one unified and easy to use FFI with callbacks so one can use the platform, maybe others will write the bindings then - single small base image but fast loadable binary code components (modules, maybe using the LoadLibrary trick), similar to what David had with SmallScript or what BeeSmalltalk is doing with SLL's - but still with the ability to bootstrap up to a full saveable image - ability to serve the web with easy callbacks into Smalltalk for implementing functionality (especially with this we may catch 90% of the usual UI cases). Bye T. [1] Metro theme Bootstrap http://talkslab.github.io/metro-bootstrap/components.html [2] jQuery Desktop http://desktop.sonspring.com/ [3] Chrome Experiments http://www.chromeexperiments.com/

Sept. 16, 2014

Re: [Pharo-dev] [Moose-dev] [ANN] Test Coverage with Hapao

by Alexandre Bergel

Excellent! Alexandre > Le 16-09-2014 Ã 16:15, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > Great! > > I will go over it more thoroughly in the following weeks and get back to you with feedback. > > Cheers, > Doru > > > >> On Tue, Sep 16, 2014 at 6:03 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Dear all, >> >> We are happy to release Hapao2 for Pharo. Ricard Jacas and Alejandro Infante put quite some work on Spy2 (an Ã¼ber cool profiling framework for Pharo) and Hapao2. >> Hapao2 is about assessing the test coverage of your code and is a major revamp of Hapao1, which was presented a couple of years ago by Vanessa. >> Hapao2 does not only list covered and uncovered methods, as most test coverage tool on Earth will do. Hapao gives a great visualization to easily navigate in your code, assess its complexity, and give you a great visual output telling its coverage. >> >> You need Roassal in your image: >> >> Gofer new smalltalkhubUser: 'ObjectProfile' >> project: 'Roassal2'; >> package: 'ConfigurationOfRoassal2'; >> load. >> (Smalltalk at: #ConfigurationOfRoassal2) load >> >> >> and you need S2py: >> MCHttpRepository >> location: 'http://smalltalkhub.com/mc/ObjectProfile/S2py/main' >> user: '' >> password: '' >> >> >> New entries will appear in the world menu: >> <Screen Shot 2014-09-16 at 11.49.06 AM.png> >> >> You can run the test coverage on : >> - the class classes you have modified, >> - on a particular >> - on a particular class category >> - on the last class categories you have modified >> - on the last packages you have modified >> >> Here is a portion of a large coverage: >> >> <Screen Shot 2014-09-16 at 12.00.11 PM.png> >> >> A technical description of Hapao may be found on http://bergel.eu/download/papers/Berg12c-HapaoSCP.pdf >> >> We are daily using Hapao to help us understand our tests. >> >> Cheers, >> Ricardo, Alejandro & Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Sept. 16, 2014

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

by Eliot Miranda

On Tue, Sep 16, 2014 at 5:33 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 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. > I think you need therapy ;-) Why not be positive and think about how you could make these technologies work? I'm sure Smalltalk and Cog can do soft real-time. People have been using it to do music for as long as its been in existence. If you could get beyond your "it can't be done" mind set and get into a "how might this be done" mindset you might make a real contribution. Right now you're being a real downer. -- best, Eliot

Sept. 16, 2014

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

by Eliot Miranda

Hi Kilon, On Tue, Sep 16, 2014 at 5:07 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > Is there any other documentation for Slang apart from the link in squeak > wiki ? > Read the VM sources; they're the best example of what it does. But alas documentation is poor here. You might read Lazy Become and Primitives <http://www.mirandabanda.org/cogblog/2014/02/08/primitives-and-the-partial-r…> as an example of what one can do. > Hows Slang deals with manual memory management ? > Poorly. Essentially one uses cCode: [.....] inSmalltalk: [...] to separate the solutions used in each realm. For example, in the Cog JIT arrays of instructions, branch fixups and stack entry descriptors are the key data structures in code generation. In the Simulator these are Smalltalk objects, and the Smalltalk GC reclaims memory. In the C VM these are stack allocated via alloca and reclaimed on return. Further, Spur supports pinned objects on the heap which the system can use to allocate memory in place of malloc (the advantage being that the Simulator can use this memory also). The simulator *could* use malloc if it contained a malloc simulation, but as yet I haven't needed it, and given Spur's support for pinned objects it is not compelling to implement a malloc simulation. > > 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 >>> >> -- best, Eliot

Sept. 16, 2014

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

by Eliot Miranda

On Tue, Sep 16, 2014 at 4:14 AM, Ben Coman <btc(a)openinworld.com> wrote: > Thierry Goubier wrote: > > Hi Ronie, > > Le 15/09/2014 23:37, Ronie Salgado a Ã©crit : > > 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. > > 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. > > Will you provide SSE-type vector arithmetic or will you rely on the > compiler to generate those? > > - 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. > > Lot of very significant stuff :) > > > Current I have implemented the following backends: > - A C interpreter plugin. > - A LLVM based backend. > > Do you mean a LLVM-IR to Lowcode backend compiler ? > > > 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. > > So there is a path there about improving Slang to C generation. > > > 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 > > > --------------------------------------------------------------- > - 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. > > Do gradual typing of performance sensitive parts of the code. > > > 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. > > 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. > > 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. > +100. And Smalltalk is being used in real-time applications already, e.g. semiconductor fab machines. It used to be in all of Tektronix's oscilloscaopes. > Anyway, they are not even talking of coding anymore these days in there. > They do MDE. > > Consider that the target can be named performance critical applications, > and those are significant but have different approaches to performance: > use highly tuned libraries (Intel mkl); > perform source to source analysis to extract performance; > vectorize code (via gcc intrinsics, SSE inline, OpenCL, ICC); > use inline asm; > use totally non-obvious algorithms (bitonic sort, bit slicing); > use GPUs; > use massively parallel computing resources; > load pre-optimised code generators in your code (compilette: a > minimized Jit which generate asm at a cost of 3 inst for one generated) > > Adaptative optimisation is a very impressive technique, but it goes only > that far. When you consider that some compilation phases may require a 64 > CPU cores machine to shorten the compilation time, then you don't do it on > the fly. > > > 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. > > And of course, you have to perform lot of profiling. > > Allways! > > Thierry > > > 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 <%2B31%20%20%206%202757%207177> (SMS ok) >> + 1 415 287 3547 <%2B%201%20415%20%20287%203547> (no SMS) >> > -- best, Eliot

Sept. 16, 2014