[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
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] En nombre de stepken Enviado el: Wednesday, May 06, 2009 21:16 Para: pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/5/7 stepken <stepken@web.de>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
just found http://code.google.com/p/libjit-linear-scan-register-allocator/wiki/LLVM_and... 2009/5/7 Igor Stasenko <siguctua@gmail.com>:
2009/5/7 stepken <stepken@web.de>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Igor Stasenko -
Sebastian Sastre -
stepken -
Stéphane Ducasse