2009/5/7 stepken <[email protected]>: > Hi! > > Connecting Pharo to SUN Lively Morphic GUI: > > http://research.sun.com/projects/lively/ > > has lots of advantages: > > * decoupling of GUI and steering engine in hardware, like X-Server > from X.org > * independance of hardware and OS. > * speed - drawing canvas in SVG is implemented in C, steeting in > JAVA-Script. Google Chrome engine V8 is a ActionScript Jitter > (http://llvm.org/) and even offers OpenGL as C-lib (Khronos) -> No > more plugin's into VM necessary for graphics, same with > vector-font libraries. > * comfort - You can develop your smalltalk software from everywhere, > e.g. pharo vm installed at a webhoster ... or local over loopback > interface. > * Lively and Squeak Morphic mental models fit perfectly, adaption > should be really easy. Dan Ingall being one of the designers of > Lively... > * Pharo's killer applications seaside and pier also are remote > applications, also using ActionScript and browser -> why not for > graphics, morphic and etoys? > * Chrome/FireFox tends to become the standard universal > visualisation and I/O toolkit for all OS, so why not being > lightyears ahead by consequently implementing the GUI in Chrome/FF? > > few disadvantages: > > * sound, videostreaming, printing problematic, but easily solvable, > because FF/Chrome already have that features built in ;-) > > I'm a bit disappointed by the fact, that the squeak / pharo jitter still > has not the expected performance impact. Elliot does a good work, but > Frank Lesser with its DNG engine is showing actually, what is > technically possible ...C-Speed for Smalltalk and ! Apple is behind LLVM > and JAVA 6 is showing also, that C-Speed can be reached in full > OO-Languages, see the "language shootout". By the way: ActionScript is a > full OO-language, like Smalltalk. > > I really wondered, why not LLVM has become the standard jitter in Pharo. > Power/ARM/Sparc/Intel ... processors are already supported!
I studied LLVM functionality some time ago. And i don't remember what exactly turns my nose off from it. Maybe because its too C-centric approach: they care much about Globals, Linkage, custom-defined data types, dynamic C code compilation which is totally have no use for smalltalk. I didn't found the ways how i could define own calling convention(s) , other than cdecl. And to make smalltalk contexts efficient, IMO, you have to change it. From what i have seen, in examples like this http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html .. LLVM is like a replacement of GCC compiler with mix of useful and not so enhancements (in terms of smalltalk VM needs). Not sure how this could help with making VM which could run smalltalk code - you're still need to write it from scratch. Mainly, what i would like to reuse from LLVM is native code generator. But again, from what i have seen, the code generator is focused to be a backend for C compiler only. That's only an impression, i could be wrong. > > I think, any proprietary Jitter is a design fault ... > > just my 2 ct. > > Have fun, Guido Stepken > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
