June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] OpenGL 3.0+

by Darrin Massena

On Sat, May 31, 2014 at 10:00 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > Backward compatibility can be a divisive subject. The disparate views > expressed at [1] will give you a general overview of Pharo's philosophy. > Now your question is slightly different to the usual backward-compatibility > discussion that relates to the existing codebase inherited from Squeak and > before. Here on of Pharo's goal to enhance future maintainability by > elimination of "legacy code", where [1] defines "legacy code" as: > - a code written eons ago > - original authors are gone/not interested in communicating > - no documentation > - a lot of patches and extensions from various authors over ears > - often same functionality implemented using two different ways > - things are completely bizarre, unmaintainable and unable to understand > > So for the existing code, while compatibility is kept as much as possible, > cleaning takes priority. While this might cause some early pain, the mid > to long terms should end up better than otherwise. > Very reasonable and pragmatic. > > Regarding "once something is developed in Pharo will it work unchanged on > _all_ future Pharo versions?" I would hazard to guess, considering the > keyword "all", that the answer is "no". The Pharo team are pragmatic about > what they can achieve with their resources. If something can provide more > (in terms of maintainability and broader usage) for a given effort, then > that is probably the path to be taken. > > [1] > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-December/072196.h… > Thanks for the link. Very illuminating. > > > cheers -ben > > > > Maybe we need a GL3ViewportMorph to live along side GLViewportMorph. > > >> As for plans for OpenGL support, normal and accelerated GUIs, I am >> working in OSWindow. >> > > I have read a little of this -- very exciting! > > >> OSWindow provides support to manage native operating system windows >> purely from image side. With Igor, we made a custom image and VM for Linux >> in which we removed almost everything graphic related from the VM. The only >> support needed in the VM is a small check for event presence in the VM >> heartbeat. >> >> For OSWindow, we made initially a XLib based back-end. To reduce >> maintenance efforts for Windows and Mac OS, I made a new backend based in >> SDL2. It is quite complete and I have tested mostly in Linux. For Windows I >> could make it work, not perfect so it needs more testing and a complete >> removal of the old Win32 drivers. I don't have a Mac for testing, but Alex >> is going to help me there. >> > > If there is something I can do to help with the Mac I would like to. > > I have to tell the CMakeVMMaker to also build SDL2 before building, >> instead of having to build/install it manually. After that I think that we >> can start integrating into Pharo 4. >> >> As for OpenGL, SDL2 gives me a multi-platform abstraction for creating >> a window with an OpenGL context. I already made it work with NBOpenGL, the >> only tricky part is dependency order when loading the stuff in the image. >> > > Yes, SDL2 is the way to go. > > In fact, I already started making a new 3D graphics engine Pharo, to >> rewrite Roassal 3D on top of this one in the near future. Soon I will be >> posting some screen-shots of this engine. >> > > Sounds interesting! > > >> With this graphics engine, I am also going to try to make an Athens >> backend, for accelerated vector graphics. Vectorial graphics with OpenGL >> are very hard to do fast, specially self intersecting bezier curves. >> Stencil based testing is simple, fast, supported and efficient for this job. >> > > Very nice. Is Athens used to render the main UI elements (windows, > buttons, bitmaps, text, etc?). > > It's not clear to me how the OSWindow work will result in a faster Pharo > UI. On OSX, at least, underneath everything is already an OS window that > supports GL and other accelerated calls but the Pharo graphics primitives > don't take advantage of this. Won't they need reworking? > > Greetings, >> Ronie >> >> >> 2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean(a)clipperadams.com>: >> >>> darrinm wrote >>> > Oh, and NBMacGLConstants is lacking necessary constants. Is it manually >>> > created or generated somehow? >>> > >>> > - darrinm >>> >>

June 1, 2014

Re: [Pharo-dev] Improving Pharo By Example

by Damien Cassou

On Sun, Jun 1, 2014 at 8:54 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Whats the verdict with the Squeksource section ? Do I covert it to a > SmalltalkHub section or do I continue to chapter 4 ? I think you can keep the section about squeaksource and replace it with ss3 and smalltalkhub instead. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 1, 2014

Re: [Pharo-dev] Improving Pharo By Example

by stepharo

I fixed that! On 10/5/14 18:06, Damien Cassou wrote: > > On Sat, May 10, 2014 at 5:01 PM, kilon alios <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>> wrote: > > when I type 3 + 4 , it seems like it takes + as part of the > pillar syntax and uses latex syntax and when it tries to generate > the pdf it fails so I am forced now to type it as raw text like > this : {{{3+4}}} > > > you can use eith ==3 + 4== for fixed-width font or 3 \+ 4 for normal text > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill

June 1, 2014

Re: [Pharo-dev] Improving Pharo By Example

by stepharo

I did a full pass on Syntax in nutshell and I fixed tons of glitches. Stef

June 1, 2014

Re: [Pharo-dev] Improving Pharo By Example

by kilon alios

Thanks Stef , I will try to take account all you mentioned from now on to anything I port. I used spaces because it makes it much easier for me to read. I have not added more screenshots because you told me you wanted less. Obviously less screenshots is less work for me. I have tried to add all the basic ones like system browser, inspector etc. In any case I like to note here that my work need a lot of proof reading. I am fully aware there will be problems with my work and I don't read line by line everything I port because that would be extremely time consuming and would slow me down severely. But I do always make sure the pdf renders properly and the text looks readable. So please if you find any problems with the pdf/html , either fix it yourselves or if you dont have access to github / dont have the time to fix it , please report here and I will fix it for you. Whats the verdict with the Squeksource section ? Do I covert it to a SmalltalkHub section or do I continue to chapter 4 ? "Thanks kilon. Thats an important effort. I would vote for changing it to SmalltalkHub. The Squeaksource home page says its disabled creation of new projects. " well last time I checked the old Squeaksource was dead, there was something like Squeaksource3 that can be found here that allows the creation of new projects and I think its what squeakers use for their projects http://ss3.gemstone.com/ but I have not used it since I left Squeak for Pharo a year ago. I dont have an issues making a similar size section about Smalltalkhub , I agree its the most sensible solution but I would like to check it our first with Stef and the rest of the team because I know its extra work for people doing the translations and such. On Sun, Jun 1, 2014 at 9:13 PM, stepharo <stepharo(a)free.fr> wrote: > I also fixed > > kjhjkhjh . -> lkjlkjklj. > > lkjkl , kkklj -> lkjkl, kkklj > > there is no space because diacritics in english so > > Pharo ? -> Pharo? > > And I suggest to add some screen shots in the tour on pharo. > > > I converted also extra bold into == == because code should be in == == > > > I think that we should have a special tag for the "exercises" right now I > put a bullet. > Stef > >

June 1, 2014

Re: [Pharo-dev] Improving Pharo By Example

by stepharo

I also fixed kjhjkhjh . -> lkjlkjklj. lkjkl , kkklj -> lkjkl, kkklj there is no space because diacritics in english so Pharo ? -> Pharo? And I suggest to add some screen shots in the tour on pharo. I converted also extra bold into == == because code should be in == == I think that we should have a special tag for the "exercises" right now I put a bullet. Stef

June 1, 2014

Re: [Pharo-dev] OpenGL 3.0+

by Darrin Massena

On Sat, May 31, 2014 at 1:21 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hello, > > > OK. Where is the old generator? I will look into it if nobody is already >> doing so. > > > The old generator is in the NBOpenGL Smalltalk Hub repository. It does a > lot of magic so working with it can be very frustrating. Also, you are > going to want to read about the fileout format( > http://www.inf.ufsc.br/poo/smalltalk/stx/english/programming/fileoutFormat.… > ). > Thanks, I'll read up. > > Ask all the details to Igor or Jean Baptiste, they are more familiar with > NBOpenGL itself. > > > If there is something I can do to help with the Mac I would like to. >> > > In my other post a published a bit of OSWindow. You can try to play with > it or making it work on Mac. Apart from the VM changes, for Mac is missing > testing for loading the SDL2 library. > I'll give it a try and let you know if I can get something working. > > Very nice. Is Athens used to render the main UI elements (windows, >> buttons, bitmaps, text, etc?). >> > > I believe that most of them not, because they rely on older raster > operations. I think that accelerating Morphic requires refactoring it to > use Athens all the time. > As for myself, I need an Athens backend for Roassal2 to avoid having > cairo->form->texture transfers. > On the Mac I have measured that the lowest level primitive for updating the screen (primShowRectLeft:right:top:bottom) is quite slow (48ms for a full screen update on my super-fast Mac Pro). It is doing pixel format conversion, creating a screen sized bitmap, copying the bits in, drawing the bitmap to the screen context, and then converting the pixels back. So, even without Morphic overhead it is very slow. I'll check your sources but are you reimplementing this on Linux (it was probably different to begin with)? > > Greetings, > Ronie > > > 2014-05-31 13:00 GMT-04:00 Ben Coman <btc(a)openinworld.com>: > > Darrin Massena wrote: >> >> Thanks for all the great info Ronie! >> >> >> On Fri, May 30, 2014 at 4:06 PM, Ronie Salgado <roniesalg(a)gmail.com> >> wrote: >> >>> Hello, >>> >>> I am also interested on this topic. For what I saw from NBOpenGL, Igor >>> was generating the bindings from older specifications of the OpenGL API. >>> Those older specifications are in a deprecated DSL. >>> >>> The newer versions of the OpenGL APIs are available in some XML files >>> provided by Khronos Group. In this link >>> http://www.opengl.org/registry/#specfiles another link for a subversion >>> repository( >>> https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ ) >>> with those XML files is available, along with the formal OpenGL specs. >>> >>> Because they are now in those XML files, we need new generator for >>> OpenGL 3.3-4.0. >>> >> >> OK. Where is the old generator? I will look into it if nobody is >> already doing so. >> >> I am not involved so cannot answer directly, but I see something similar >> discussed here.. >> http://jeanbaptiste-arnaud.eu/opengl/ >> >> >> >> Another question, a core profile context is really needed? Why not >>> starting working with a compatibility profile?. OpenGL API deprecation does >>> not depend on us, it depends on what the Khronos Group and the graphics >>> card maker decide to do. In the x86 Desktop, the three big companies cannot >>> remove the compatibility profile, otherwise lot of older video-games will >>> stop working. >>> >>> Also, there are lots of graphic cards, specially older integrated in >>> laptops that are only OpenGL 2.x. A better bet is to support at least the >>> subset available in OpenGL 2.x that is also available in the core profile. >>> >> >> Good points. Nevertheless, as I understand it, OSX does not provide a >> compatibility profile. You get core 2.1, 3.2, or 4.1 with OSX 10.7 or >> greater (released 3 years ago). Currently Pharo always gets OpenGL 2.1 >> core. So we are working with an API that was deprecated 6 years ago that >> can only take advantage of a fraction of the power of our GPUs and is >> discouraged/unavailable on mobile platforms. Maybe that is enough for some >> things but I'd like to see the door opened for more. >> >> This makes me wonder what the compatibility philosophy of Pharo is. Is >> it a goal that once something is developed in Pharo it will work unchanged >> on all future Pharo versions? I imagine one of the liberating aspects of >> VMs is that they can evolve, even incompatibility, because old software can >> continue to run on old VMs. But I am new to Smalltalk/Pharo culture so >> please educate me. >> >> Backward compatibility can be a divisive subject. The disparate views >> expressed at [1] will give you a general overview of Pharo's philosophy. >> Now your question is slightly different to the usual backward-compatibility >> discussion that relates to the existing codebase inherited from Squeak and >> before. Here on of Pharo's goal to enhance future maintainability by >> elimination of "legacy code", where [1] defines "legacy code" as: >> - a code written eons ago >> - original authors are gone/not interested in communicating >> - no documentation >> - a lot of patches and extensions from various authors over ears >> - often same functionality implemented using two different ways >> - things are completely bizarre, unmaintainable and unable to understand >> >> So for the existing code, while compatibility is kept as much as >> possible, cleaning takes priority. While this might cause some early pain, >> the mid to long terms should end up better than otherwise. >> >> Regarding "once something is developed in Pharo will it work unchanged >> on _all_ future Pharo versions?" I would hazard to guess, considering the >> keyword "all", that the answer is "no". The Pharo team are pragmatic about >> what they can achieve with their resources. If something can provide more >> (in terms of maintainability and broader usage) for a given effort, then >> that is probably the path to be taken. >> >> [1] >> http://lists.gforge.inria.fr/pipermail/pharo-project/2012-December/072196.h… >> >> cheers -ben >> >> >> >> Maybe we need a GL3ViewportMorph to live along side GLViewportMorph. >> >> >>> As for plans for OpenGL support, normal and accelerated GUIs, I am >>> working in OSWindow. >>> >> >> I have read a little of this -- very exciting! >> >> >>> OSWindow provides support to manage native operating system windows >>> purely from image side. With Igor, we made a custom image and VM for Linux >>> in which we removed almost everything graphic related from the VM. The only >>> support needed in the VM is a small check for event presence in the VM >>> heartbeat. >>> >>> For OSWindow, we made initially a XLib based back-end. To reduce >>> maintenance efforts for Windows and Mac OS, I made a new backend based in >>> SDL2. It is quite complete and I have tested mostly in Linux. For Windows I >>> could make it work, not perfect so it needs more testing and a complete >>> removal of the old Win32 drivers. I don't have a Mac for testing, but Alex >>> is going to help me there. >>> >> >> If there is something I can do to help with the Mac I would like to. >> >> I have to tell the CMakeVMMaker to also build SDL2 before building, >>> instead of having to build/install it manually. After that I think that we >>> can start integrating into Pharo 4. >>> >>> As for OpenGL, SDL2 gives me a multi-platform abstraction for creating >>> a window with an OpenGL context. I already made it work with NBOpenGL, the >>> only tricky part is dependency order when loading the stuff in the image. >>> >> >> Yes, SDL2 is the way to go. >> >> In fact, I already started making a new 3D graphics engine Pharo, to >>> rewrite Roassal 3D on top of this one in the near future. Soon I will be >>> posting some screen-shots of this engine. >>> >> >> Sounds interesting! >> >> >>> With this graphics engine, I am also going to try to make an Athens >>> backend, for accelerated vector graphics. Vectorial graphics with OpenGL >>> are very hard to do fast, specially self intersecting bezier curves. >>> Stencil based testing is simple, fast, supported and efficient for this job. >>> >> >> Very nice. Is Athens used to render the main UI elements (windows, >> buttons, bitmaps, text, etc?). >> >> It's not clear to me how the OSWindow work will result in a faster >> Pharo UI. On OSX, at least, underneath everything is already an OS window >> that supports GL and other accelerated calls but the Pharo graphics >> primitives don't take advantage of this. Won't they need reworking? >> >> Greetings, >>> Ronie >>> >>> >>> 2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>> >>>> darrinm wrote >>>> > Oh, and NBMacGLConstants is lacking necessary constants. Is it >>>> manually >>>> > created or generated somehow? >>>> > >>>> > - darrinm >>>> >>> >

June 1, 2014

Re: [Pharo-dev] GPU accelerated GUI

by Darrin Massena

If nobody has time to curate the information then an issue tracker is probably the way to go. At least then tidbits of information would be gathered in one stream with timestamps so one can gauge relevance. For example, I'm doing some performance measurements and would post them to a GUI performance issue if there was one and others were following/contributing to it. When people ask about a topic in the forums they could be directed toward the relevant issue. On Sat, May 31, 2014 at 6:01 AM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > Can we collect somewhere in the web the information you mentioned and > other more accurate? Ideally a wiki. Is there a dedicated place for > Pharo? The wiki bugtracker? > I guess most of us does not know where to look at for improvement. > Asking to a newbie to contribute does not really help if we can't > provide direction. > > Hilaire > > > > Le 31/05/2014 10:48, ClÃ©ment Bera a Ã©crit : > > One is that the Morphic-based UI is slow. You can see it by using the > > old MVC instead of Morphic which goes faster. Recently Morphic got > > slower on Pharo and it is now slower than in Squeak. It may be due to > > refactoring on Morphic in order to get it better, it may not be. I guess > > this is temporary. > > > > The second thing is that BitBlt is slow for 2 reasons: it is bit based > > and not vector based and its implementation half in the VM half in the > > image forces to copy a huge number of bits that could be avoided > > > > So the answer is that you need to contribute to the refactoring of > > Morphic or to Athens. > > > > -- > Dr. Geo http://drgeo.eu > > >

June 1, 2014

Re: [Pharo-dev] GPU accelerated GUI

by Darrin Massena

On Sat, May 31, 2014 at 4:13 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > Its not about having issues or not having issues, its about how much > performance you consume for the GUI alone. > > I have installed both CPU performance monitor for 2.0GHZ Core2Duo iMac and > my new i5 3.2 Ghz iMac. Moving a system browser window in the old iMac > spikes the CPUs to 50-70% while moving the window in the new iMac is down > to 20%. Of course the old imac is 7 years old the new one is 5 months old. > > The question here is "does it really worth doing something about it ?" . > It is true that I can write all the words I want to say with a dull pencil but I prefer a nice sharp one :). How the interface feels is important. > Sure if you a creating the new CryEngine in Pharo it would be a major > problem or any 3d game app that taxes even modern CPUs. But for non > demanding usage even if pharo community does absolutely nothing this 20% > will shrink down to 10% then 5% , 2.5% and eventually 1%. This has been > also a major argument point for cpython. People used to complain A LOT > about cpython's performance in old cpus, cause lets face it in some > scenarios and many scenarios it was a BIG problem BUT nowday those voices > are getting more and more quieter because CPUs have become insanely fast > and there is no indication this will stop now. > Today's machines are thousands of times faster than the ones Smalltalk originally ran on. How much faster is its UI now? I don't think Moore's Law is going to fix the problem. So on the subject of whether we need GPU accelerated GUI at large as a > community I would say "Definetly Not" ,Morphic is messy enough as it is, > lets not make it more complex..... please ! > I agree. It should become less complex. Complexity makes it hard to improve performance. I am not saying that GPU acceleration does not have its merits, I am using > Blender for 3d modeling and its new render engine Cycles makes uses of CUDA > and its SWEET , I can almost have real time rendering, not final quality , > but still good enough to see how it would look in the final render. Real > time rendering to a 3d artist is like live coding to a coder. Its like > Christmas vacation in Santa Claus Toy Factory. > Sounds awesome. But on the other hand none stops anyone from implementing a third party > library that runs pharo headless and then uses the OS to open a new window > completely bypassing morphic and taking advantage of GPU. I don't think we > need to make Morphic more complex than it already is. Pharo should be first > about simplicity and then performance. But then if you can improve > performance of Morphic and yet keep it simple enough please be my guest. > Fast new windows for 3D would be great and I want my development environment to be fluid, responsive, and powerful too. Today it feels sluggish and weighs on me. > On Sat, May 31, 2014 at 1:47 PM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> On Sat, May 31, 2014 at 11:33 AM, Hilaire Fernandes < >> hilaire.fernandes(a)gmail.com> wrote: >> >>> We could try to organize a task force on that matter. I will try to >>> submit some proposals later, but now I want to prepare a delicious cake. >>> >> >> Ha, cool. I am cleaning the home :-) >> >> Jokes aside, it is true that the Pharo UI is quite slow. >> I do not have issues on my Core i7 PC but on my Core2Duo Mac it shows... >> >> There are enough benefits to having a software UI (flexibility etc) to >> suffer that. >> >> But there is for sure room for improvement. >> >> As resolutions go higher, this problem will only get worse. >> >> Where would one have to start looking for performance improvements? >> >> Phil >> >> >>> Hilaire >>> >>> Le 31/05/2014 10:48, ClÃ©ment Bera a Ã©crit : >>> > The second thing is that BitBlt is slow for 2 reasons: it is bit based >>> > and not vector based and its implementation half in the VM half in the >>> > image forces to copy a huge number of bits that could be avoided >>> > >>> > So the answer is that you need to contribute to the refactoring of >>> > Morphic or to Athens. >>> > >>> > GUI hardware acceleration is clearly not the problem yet. >>> > >>> >>> -- >>> Dr. Geo http://drgeo.eu >>> >>> >>> >> >

June 1, 2014

Re: [Pharo-dev] Improving Pharo By Example

by stepharo

Nice to see some progress on that front. I checked a bit and just a remark: pay attention to the coherent of word uppercasing in titles. A quick tour of Pharo vs. A Quick tout of Pharo. In PBE we do not use uppercase in title except for names. I read fast the QuickTour and fix them all. Also use '' '' for italic. Because this is nice to have stress in the text. Keep pushing. Stef On 1/6/14 17:54, kilon alios wrote: > So I have finished the second chapter , but, there is a sub section > about Squeaksource which I don't think many people use anymore , will > you keep this as it is ? Cause I was thinking maybe deleting that part > and talk instead about Smalltalkhub. > > For the time being I have ported Squeaksource part as it is. > > > On Sat, May 24, 2014 at 11:44 AM, kilon alios <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>> wrote: > > Finished Chapter 3 , no errors or warnings reporting with pdf > generation. > > I am moving to Chapter 2 now, which for some strange reason I > skipped. > > > On Thu, May 22, 2014 at 11:19 AM, kilon alios > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > oh yes I completely missed the "examples" option. Great ! One > thing less to worry about , thanks Ben :) > > > On Thu, May 22, 2014 at 1:42 AM, Ben Coman > <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > > kilon alios wrote: >> In section 1.9 page 18 there is this text >> >> "At other times you may have a good idea that a method >> exists, but will have no idea what it might be called. >> The method finder can still help! For example, suppose >> that you would like to find a method that turns a string >> into upper case, for example, it would translate 'eureka' >> into 'EUREKA'. >> >> The method finder will suggest a method that does what >> you want.8 >> >> An asterisk at the beginning of a line in the right pane >> of the method finder indicates that this method is the >> one that was actually used to obtain the requested >> result. So, the asterisk in front of String asUppercase >> lets us know that the method asUppercase defined on the >> class String was executed and returned the result we >> wanted. The methods that do not have an asterisk are just >> the other methods that have the same name as the ones >> that returned the expected result. So >> CharacterÂ»asUppercase was not executed on our example, >> because 'eureka' is not a Character object. >> >> You can also use the method finder for methods with >> arguments; for example, if you are looking for a method >> that will find the greatest common factor of two >> integers, you might try 25. 35. 5 as an example. You can >> also give the method finder multiple examples to narrow >> the search space; the help text in the bottom pane >> explains how. " >> >> I tried " 'eureka' . 'EUREKA '" and the other suggestion >> it does not seem to work , should I remove this section ? >> > It works for me... > * World > Tools > Finder > * Type... 'eureka' . 'EUREKA' > * Change [Selectors] to [Examples] > > > > >

June 1, 2014