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

Regular Hangouts

by stepharo

Hi guys I would really like to launch regular hangouts because I would like to build more contacts inside the community. I was thinking about every two weeks around 17h-18h What do you think? Stef

May 31, 2014

Re: [Pharo-dev] OpenGL 3.0+

by stepharo

Ronie what would be good is to build milestones so that other people can play with it and demo it. So a solution even not working perfectly is better than a not working one. Stef On 31/5/14 01:06, Ronie Salgado 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. > > 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. > > As for plans for OpenGL support, normal and accelerated GUIs, I am > working in OSWindow. > > 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. > > 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. > > 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. > > 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. > > Greetings, > Ronie > > > 2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>>: > > darrinm wrote > > Oh, and NBMacGLConstants is lacking necessary constants. Is it > manually > > created or generated somehow? > > > > - darrinm > > > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/OpenGL-3-0-tp4760914p4761009.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

May 31, 2014

Re: [Pharo-dev] RBSmalllintChecker>>checkClass:

by stepharo

> Hi guys. > > I have 1 important question about RBSmalllintChecker>>checkClass: > > In Pharo 2, implementation performs: > > environment definesClass: aClass > > while in Pharo 3 itâs: > > environment includesClass: aClass > > This means that in Pharo 3 we check classes that are not defined in the environment but only contain classes which environment extends. Is this correct? No idea. Did you check the implementation of defines and includes?

May 31, 2014

RBSmalllintChecker>>checkClass:

by Yuriy Tymchuk

Hi guys. I have 1 important question about RBSmalllintChecker>>checkClass: In Pharo 2, implementation performs: environment definesClass: aClass while in Pharo 3 itâs: environment includesClass: aClass This means that in Pharo 3 we check classes that are not defined in the environment but only contain classes which environment extends. Is this correct? Uko

May 31, 2014

Re: [Pharo-dev] OpenGL 3.0+

by Darrin Massena

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. 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. 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 >> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/OpenGL-3-0-tp4760914p4761009.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

May 31, 2014

Re: [Pharo-dev] Change list background color in Pharo with Spec

by Nicolai Hess

Thank you! 2014-05-30 17:15 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Nicolai Hess wrote > > (I am not registered at stackoverlfow, please forward). > > Done. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Change-list-background-color-in-Pharo-with-Spec-tp476… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

May 30, 2014

Re: [Pharo-dev] OpenGL 3.0+

by Ronie Salgado

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. 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. As for plans for OpenGL support, normal and accelerated GUIs, I am working in OSWindow. 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. 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. 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. 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. 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 > > > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/OpenGL-3-0-tp4760914p4761009.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

May 30, 2014

Gravatar improvement Smalltalkhub

by Torsten Bergmann

Hi Mathias, Â thanks for the contribution. As you intended it for me updating Gravatar on STHub I consider it in agreement with MIT license and just uploaded. I also changed the repo to public write access now. Â Change is reflected in ConfigurationOfGravatar-TorstenBergmann.3 also, copied it to the MetaRepoForPharo30 as well - so one just can load simply from the config browser in Pharo 3.0 again. Â Thx T. Â Gesendet:Â Freitag, 30. Mai 2014 um 14:30 Uhr Von:Â "Biard Mathias" <....> An:Â ... Betreff:Â Gravatar improvement Smalltalkhub Hi, Â I just add possibility to choose default image in case of 404 on your Gravatar. Â Here are the files if you want to update Smalltalkhub. Â Regards. Â Mathias

May 30, 2014

Re: [Pharo-dev] TilingWindowManager -- WorldManager? [Pharo3.0]

by Laurent Laffont

That's: TWMWorldManager instance createOrSwitchToWorldNamed: 'JustAnotherWorld'. TWMWorldManager instance createOrSwitchToWorldNamed: 'Pharo'. Cheers, Laurent Le vendredi 30 mai 2014, 06:27:39 H. Hirzel a Ã©crit : > Hello > > I installed TilingWindowManager through the > MetacelloConfigurationBrowser in Pharo 3.0. > > The class comment of TWMWorldManager says > > I provide an unlimited number of blank canvases on which to create... > > "Add a world:" > WorldManager instance createOrSwitchToWorldNamed: 'JustAnotherWorld'. > > "Return to the default world:" > WorldManager instance createOrSwitchToWorldNamed: 'Pharo'. > > > However the global WorldManager is not known anymore. What do I need > to use instead? > > Thank you for the answer in advance > > Hannes >

May 30, 2014

Re: [Pharo-dev] Change list background color in Pharo with Spec

by Sean P. DeNigris

Nicolai Hess wrote > (I am not registered at stackoverlfow, please forward). Done. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Change-list-background-color-in-Pharo-with-Spec-tp476… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 30, 2014