Re: [Pharo-project] Athens OpenGL backend - what does it mean?
Ephestos as a project is not new . It started as blender addon details can be found here --> http://blenderartists.org/forum/showthread.php?250375-A-Visual-Programming-L... Because the thread is kinda huge to sum it up what I and another blender developer did was to take morphic for python ( http://www.chirp.scratchr.org/blog/?p=30 ) which was written for python 2 and pygame and port it to python 3 , bgl (its a thin wrapper for opengl 1 blender library ) and as a blender addon. 240 commits later we had a morphic interface for blender written in python and ported to bgl so it could run from inside the blender window. Suprisingly we did not have so much problem with out own bugs but bgl proven too slow , buggy and unreliable so I had to abandon because I could only solve that problem with hacking blender source which is written in C and is almost not commented at all. Lets say here I am no big fan of C language of Blender source. Here you can find if you are interested the final blender python code ---> https://github.com/kilon/EphestosOld
From there on I was just searching for a home for Ephestos. I has quite reluctant to join pharo because of the lack of developers and because I am not that familiar with smalltalk as much I am with python. To be frank I am not that motivated to join a language that is has a very small community because of bug fixes and library support. I actually even looked into common lisp and emacs very recently as well since I really like lisp as a language and I prefer from smalltalk.
But it has become obvious to me that what I am trying to do for Ephestos is synonymous to what smalltalk is trying to do, to offer a live visual environment that makes code , fun , flexible and efficient. So I decided to take the deep dive into pharo. Smalltalk may not be super popular as python but porting all smalltalk stuff or even just little to python is just insane amount of work so I think I made the sensible choice to port my project to Pharo because it was already based on pharo libraries anyway. Saying that I am still interested in offering some Blender support for Ephestos and thus making pharo able to quickly communicate with blender probably via a socket bridge. I got all these crazy ideas but I am willing to take them a step at a time , so that is why I talked about "decades". ________________________________ From: Sebastian Nozzi <sebnozzi@gmail.com> To: dimitris chloupis <thekilon@yahoo.co.uk> Cc: "Pharo-project@lists.gforge.inria.fr" <Pharo-project@lists.gforge.inria.fr> Sent: Sunday, 25 November 2012, 20:43 Subject: Re: [Pharo-project] Athens OpenGL backend - what does it mean? Wow!!! You have no idea how incredible I found to be reading something like this: "I am willing to invest years and if all goes well even decades of efforts since its an area that I love to code for". It definitely made my day! :-) Especially the last part, that you really *love* to code in this area (something I cannot but admire). I always found the Squeak/Pharo environment so cool to code in, the "aliveness" of the image, but also had the feeling that the graphics system was a little outdated. Unfortunately being unable to do something about it, first because I have no expertise in the area, and second, because... well... I guess I'm lazy and not patient/talented enough for graphics programming ;-). It is therefor great that Igor and now you showed up, able to improve in this area, and also willing :-) To sum it up: I always thought that open-source Smalltalk should *look* as great from the "outside" as it is cool on the "inside" (the semantics). It simply deserves no less. So I am really grateful for any effort put in this. Pharo already looks great, much has been archived, and I can't wait to see what you guys will come up with next... Best regards, Sebastian 2012/11/25 dimitris chloupis <thekilon@yahoo.co.uk>:
"eye candy" wise this is exactly the focus of my Ephestos project , Morpheas
section. A custom gui , gui designers for easy creating of GUIs by the user and additional moprh widget with customized look including eye candy.
I can't make any promises, as I have no clue what kind of obstacles and technical limitations I am going to find in the process but I can tell you I am willing to invest years and if all goes well even decades of efforts since its an area that I love to code for.
As a first part I am in the process of creating a tutorial generator which will be ProfStef on steroids for at first offering tutorial for Athens and later used for any kind of Pharo tutorial.
I am also interested in helping Athens porting to OpenGL and generally using NBOpenGL as the next step for Morphic. Excitting stuff the only thing it worries me is the type of technical blocks / obstacles I may come across but trying is certainly well worths it.
________________________________ From: Sebastian Nozzi <sebnozzi@gmail.com> To: Pharo Development <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, 24 November 2012, 17:06 Subject: [Pharo-project] Athens OpenGL backend - what does it mean?
Hello Pharo Devs,
I am really excited about the direction Pharo is taking regarding many areas - one of them being the graphics. I played with Athens a bit and it's cool to see anti-aliased vectror graphics coming to Pharo.
I keep reading about a possible OpenGL back-end in the future... what
would this mean exactly?
For years I have been "dreaming" about graphic-accelerated "eye-candy" effects inside of the Smalltalk environment. Like compiz-fusion effects in Linux, or Quartz-Extreme powerded in OS-X (Exposé, etc.).
Would this be possible with such a back-end? Or am I misinterpreting things? I'm not a graphic-dev expert.
Best regards,
Sebastian
2012/11/25 dimitris chloupis <thekilon@yahoo.co.uk>:
240 commits later we had a morphic interface for blender written in python and ported to bgl so it could run from inside the blender window.
I'm trying to understand... was it an alternative interface for Blender, or an interface toolkit just happening to sit on top of Blender? (or both?)
Suprisingly we did not have so much problem with out own bugs but bgl proven too slow , buggy and unreliable so I had to abandon because I could only solve that problem with hacking blender source which is written in C and is almost not commented at all. Lets say here I am no big fan of C language of Blender source.
I begin to understand what you meant with "only thing it worries me is the type of technical blocks / obstacles I may come across".
Here you can find if you are interested the final blender python code ---> https://github.com/kilon/EphestosOld
What really would interest me is your personal opinion on Smalltalk as somebody coming from a Python background. That is, once you have more experience with it (Smalltalk). I don't know much Python, but considered it more than once because of something I didn't find in other mainstream languages that I would miss from Smalltalk: named parameters. Of course in Smalltalk you don't have that, since the method signatures give you that for free ;-)
From there on I was just searching for a home for Ephestos. I has quite reluctant to join pharo because of the lack of developers and because I am not that familiar with smalltalk as much I am with python. To be frank I am not that motivated to join a language that is has a very small community because of bug fixes and library support.
I understand you completely and it is good to read this loud and clear. For every person like you that communicates this in a clear way there must be hundreds that consider Smalltalk and then discard it for the same (or other) reasons; the input never reaching the community. I would be tempted to tell you that being such a small community also has its advantages ;-) but I don't want to trivialize the issue. Smalltalk's community *is* very small, and the library support... well... could (and hopefully will) be better. In some areas, let's be honest, we are years behind other platforms/environments/languages. But why does a Smalltalk community still exists at all, then? Because yet in many other areas, Smalltalk is still *ahead* of anything else out there also for years if not for decades. Yes, I think this is a vital issue, and kind of a chicken-egg problem that needs to be solved (I know, it *is* being solved). In fact, I think I will write another mail asking this "small" (?) community what they think about it.
I actually even looked into common lisp and emacs very recently as well since I really like lisp as a language and I prefer from smalltalk.
Conceptually I find Lisp also very interesting. But anytime I evaluate going the Lisp route I find myself planning to reach first some Lisp-based-Smalltalk syntax & semantics and then I say: why waste my time if there *is* already Smalltalk, waiting to be used? :-) At the end, I think the right approach to DSL (domain-specific-languages) nirvana will be the idea presented by the Helvetia project, incidentally also Smalltalk-based: http://scg.unibe.ch/research/helvetia
But it has become obvious to me that what I am trying to do for Ephestos is synonymous to what smalltalk is trying to do, to offer a live visual environment that makes code , fun , flexible and efficient.
Cool :-)
So I decided to take the deep dive into pharo. Smalltalk may not be super popular as python
Not for a long shot, unfortunately. We as the Smalltalk community should be very sincere and evaluate, with a cool head, why this is so.
but porting all smalltalk stuff or even just little to python is just insane amount of work so I think I made the sensible choice to port my project to Pharo because it was already based on pharo libraries anyway.
I don't get it... which part will you port from Python to Smalltalk, and which part you don't need/want to port?
Saying that I am still interested in offering some Blender support for Ephestos and thus making pharo able to quickly communicate with blender
And Blender would... render 3d? (whilst the interface would be on the Pharo side?)
probably via a socket bridge.
The idea of (socket) "brides" to other languages / runtimes always made sense to me. At least short-term to break the library/devs cycle. I don't know if this idea was evaluated by the community. Recently there was an announcement of a bridge to a XUL (Mozilla) -based frontend, with Smalltalk back-end, using Seaside's continuations. So it should be easier as ever.
I got all these crazy ideas but I am willing to take them a step at a time , so that is why I talked about "decades".
I very much liked what Stef wrote yesterday, it got me thinking: start small and work steadily... Good to see that you have such long-term plans! :-) Best regards, Sebastian
I'm trying to understand... was it an alternative interface for Blender, or an interface toolkit just happening to sit on top of Blender? (or both?)
No its an alternative interface for blender , bgl is nothing more than opengl stuff, but bare minimum opengl 1 stuff. Note that blender uses opengl for its own GUI API but I did not use that api at all. So it is a separate interface. Its basically Morphic , bare bones Morphic, but still Morphic. I was successful in providing a GUI API that is far more flexible compared to the existing Blender python GUI API and excels at custom made guis that the standard gui does not allow. However bgl is slow and quite buggy.
What really would interest me is your personal opinion on Smalltalk as somebody coming from a Python background. That is, once you have more experience with it (Smalltalk). I don't know much Python, but considered it more than once because of something I didn't find in other mainstream languages that I would miss from Smalltalk: named parameters. Of course in Smalltalk you don't have that, since the method signatures give you that for free ;-)
I dont care about languages any more. I do not care about smalltalk the language. I dont believe language choice matters. There I said it. If smalltalk did not have this amazingly cool environment I would never have left python. I am actually quite happy with python, then one thing I did miss seriously was a good IDE. I used to be a Delphi coder back a decade ago , before being a python coder and Delphi had this amazing IDE in some areas even superior to smalltalk ide and pharo. So I was searching for a very good IDE for python and I found smalltalk, smalltalk has simple syntax like python and the IDE of high quality I came to love in Delphi. So I think it fits like a glove for my needs. Ironically both python and Delphi IDE have been deeply influence by the smalltalk language and enviroment. So it feels kinda of funny after 25 years of messing with coding to go back to the roots of all this. I am sure I am going to miss python's stability and library support but I think I am trading them off for something superior.
Conceptually I find Lisp also very interesting. But anytime I evaluate going the Lisp route I find myself planning to reach first some Lisp-based-Smalltalk syntax & semantics and then I say: why waste my time if there *is* already Smalltalk, waiting to be used? :-)
I dont think its hard to see that Lisp is THE language , well more like a family of languages. Lispers can be snobbish about other languages but they are correct lisp is superior even to smalltalk. There is little doubt in that. But again I do not believe language choice is that important , if it was people would not be making awesome software with other languages which they do. Its ironic because AI an area that lisp dominated is now dominated by python that goes fundamentally against the lisp philosophy and something that lispers quite correctly consider far inferior to lisp. Once again its the environment that attracted me , in this case emacs. Even though I decided to go with Pharo, Emacs is far from being out of the equation. I am still planning bringing emacs like text editing features to pharo for Ephestos. Long term plan but it is there.
I don't get it... which part will you port from Python to Smalltalk, and which part you don't need/want to port? None. This is no longer a python project its pure smalltalk. I may create a python socket bridge for smalltalk to use python libraries and to access programms like Blender and mypaint etc. but is not big priority right now. Ephestos is basically an effort to improve pharo and make it more inviting to newcomers. If I can offer tools also useful to veteran smalltalkers that will be double win for me.
And Blender would... render 3d? (whilst the interface would be on the Pharo side?)
Yes , Ephestos and hence pharo would be able to control blender completely. Â > The idea of (socket) "brides" to other languages / runtimes always
made sense to me. At least short-term to break the library/devs cycle. I don't know if this idea was evaluated by the community. Recently there was an announcement of a bridge to a XUL (Mozilla) -based frontend, with Smalltalk back-end, using Seaside's continuations. So it should be easier as ever.
my bridge already works and have been tested between 2 blenders , blender and cpython 3 , blender and cpython 2 and blender and pypy. Its in the proteas folder in the link I provided. So it just waits for me to port it to pharo XMLRPC library. Its just a matter of me getting familiar with pharo. Â > I very much liked what Stef wrote yesterday, it got me thinking: start
small and work steadily... Yes I agree with Stef of course. I dont plan to do anything very complicated most of the tools that I am planning are small additions to pharo . The only thing that takes time is for me to become familiar with pharo libraries, as soon as I do that I will be able to provide one tool after another in relative quick speed.
 > Good to see that you have such long-term plans! :-) I am not doing this just for pharo, I plan to use these tools for making art. My goal is to become a professional artist and I would love to build my owns tools and find alternative ways of artistic expression. Thus the long term process of the project. To give you a clear idea , I am trying to achieve something similar to this http://openendedgroup.com/field/OverviewBanners2.html At first Ephestos was supposed to be an extension of Field. But their support was non existant (the original developer obviously are busy with art projects ) and I needed help to understand the code, so I chose to go down the pharo route because if I had any problems I had much better chances to get it fixed in pharo than getting it fixed in Field. But Ephestos and Field are two projects with very similar goals. Thank you for your interest I will keep you posted with any significant progress.
participants (2)
-
dimitris chloupis -
Sebastian Nozzi