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 think, any proprietary Jitter is a design fault ... just my 2 ct. Have fun, Guido Stepken _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Hi Guido,
since the oracle adquisition of sun in april 20, don't forget to add to the list something like: the only one that can say anything about its future is the Oracle board. Is obvious that oracle is only interested in java. Who can now say anything about valuable sun projects just vaporized by this adquisition? the industry will get stronger or weaker? for those products we can only wait and see. Right now there are plenty of scared sun consumers (not to mention mysql in pain pre-ex-users) sebastian > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En > nombre de stepken > Enviado el: Wednesday, May 06, 2009 21:16 > Para: [hidden email] > Asunto: [Pharo-project] Thoughts about Pharo GUI > > 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 think, any proprietary Jitter is a design fault ... > > just my 2 ct. > > Have fun, Guido Stepken > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by stepken
2009/5/7 stepken <[hidden email]>:
> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
just found
http://code.google.com/p/libjit-linear-scan-register-allocator/wiki/LLVM_and_GNU_Lightning 2009/5/7 Igor Stasenko <[hidden email]>: > 2009/5/7 stepken <[hidden email]>: >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by stepken
where is your code?
I have a huge list of pretty cool ideas but only two hands and one life. Stef On May 7, 2009, at 2:15 AM, stepken wrote: > 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 think, any proprietary Jitter is a design fault ... > > just my 2 ct. > > Have fun, Guido Stepken > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |