Thoughts about Pharo GUI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Thoughts about Pharo GUI

stepken
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts about Pharo GUI

Sebastian Sastre-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts about Pharo GUI

Igor Stasenko
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts about Pharo GUI

Igor Stasenko
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts about Pharo GUI

Stéphane Ducasse
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