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

Re: [Pharo-dev] GPU accelerated GUI

by Esteban A. Maringolo

2014-06-02 16:51 GMT-03:00 stepharo <stepharo(a)free.fr>: > It depends what you measure. > If you measure classBrowser opening then nautilus is slower because it is > doing more stuff. If adding more features degrades performance in a human perceivable way then it's slowing down. (I mean, if slowdown is linear as extra features are added). The trade-offs might be worth it (as indeed they are). > So if you really want to help > make a benchmark showing the difference between 1.4 and 3.0 on a > **concrete** case. Without that we cannot make progress. Fair enough. I'll do so :) Next time I won't say it feels slower (but not slow) until I get an appropriate benchmark. Regards, -- Esteban.

June 2, 2014

[OT] Swift - Apple Developer

by Sven Van Caekenberghe

So Apple has a new language https://developer.apple.com/swift/ which is quite interesting since it works on top of their Objective-C runtime, which is pretty similar to what we are used to. There is of course lots of syntactic sugar to make things look easy, and more typing. I am still digesting it, but one thing that I wonder is how they implement the literal syntax for simple collections: [ 1, 2, 3 ] for an Array and [ "x" : 1, "y" : 2 ] for a Dictionary how do they differentiate between the two ? Maybe if we knew, it could be a solution to our 'missing' dictionary literals. Sven

June 2, 2014

[pharo-project/pharo-core] 516c28: 40012

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 516c28085be219cbf7ac535d92c49068e6e3e5fc https://github.com/pharo-project/pharo-core/commit/516c28085be219cbf7ac535d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-02 (Mon, 02 Jun 2014) Changed paths: R Morphic-Core.package/Morph.class/instance/button/firedMouseUpCode.st R Morphic-Core.package/Morph.class/instance/debug and other/addMouseActionIndicatorsWidth_color_.st R Morphic-Core.package/Morph.class/instance/debug and other/addMouseUpAction.st R Morphic-Core.package/Morph.class/instance/debug and other/addMouseUpActionWith_.st R Morphic-Core.package/Morph.class/instance/debug and other/deleteAnyMouseActionIndicators.st R Morphic-Core.package/Morph.class/instance/debug and other/mouseUpCodeOrNil.st R Morphic-Core.package/Morph.class/instance/debug and other/programmedMouseDown_for_.st R Morphic-Core.package/Morph.class/instance/debug and other/programmedMouseEnter_for_.st R Morphic-Core.package/Morph.class/instance/debug and other/programmedMouseLeave_for_.st R Morphic-Core.package/Morph.class/instance/debug and other/programmedMouseUp_for_.st R Morphic-Core.package/Morph.class/instance/debug and other/removeMouseUpAction.st R Morphic-Core.package/Morph.class/instance/drawing/drawRolloverBorderOn_.st R Morphic-Core.package/Morph.class/instance/drop shadows/hasRolloverBorder.st R Morphic-Core.package/Morph.class/instance/drop shadows/hasRolloverBorder_.st M Morphic-Core.package/Morph.class/instance/menus/addMiscExtrasTo_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script12.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40012.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40012 12858 Remove hasRolloverBorder - Second part https://pharo.fogbugz.com/f/cases/12858 http://files.pharo.org/image/40/40012.zip

June 2, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40012 Home: https://github.com/pharo-project/pharo-core

June 2, 2014

Re: [Pharo-dev] [Vm-dev] Rebound Home and End keys are non-functional on Mac

by Eliot Miranda

On Mon, Jun 2, 2014 at 1:10 PM, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > > Hi Eliot: > > On 02 Jun 2014, at 22:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > I've added those entries with this pull request: > https://github.com/pharo-project/pharo-vm/pull/49 > > > > What's the easiest way to convert a pull request into either > > a) a diff which can be used with patch? > > GitHub magic: > > https://github.com/pharo-project/pharo-vm/pull/49.diff > > or > > https://github.com/pharo-project/pharo-vm/pull/49.patch > > as you like. > fab, thanks! -- best, Eliot

June 2, 2014

Re: [Pharo-dev] Regular Hangouts

by stepharo

On 31/5/14 10:53, phil(a)highoctane.be wrote: > > Plan them in google+ pharo community. > yes I was thinking about that. Now is there a way to announce them via Google+ ? or should I announce them via this list? I'm a newbies in hangouts :) Stef > It worked well with the Squeak mondays. > > Phil > > Le 31 mai 2014 08:11, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> a Ã©crit : > > 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 >

June 2, 2014

Re: [Pharo-dev] OpenGL 3.0+

by stepharo

Ronie this is excellent! :) I love when people deeply understand: Pharo is yours :). Let us build together a cool future :). Stef > Hi Stef, > > I also want to do that. I think that for Linux it is quite stable. In > those last days I have been messing a lot with Roassal 3D and > WODEN(WOrld Dynamic ENgine). > > Tomorrow I will try make a clean build of the OSWindow VM(My last try > required lot of manual tweaking). For Linux, I just finally added the > code to also build SDL2 with the VM automatically and I want to try it > on Windows. > > As for the next milestone, see the next post. I think that deserves > his own thread. > > Greetings, > Ronie > > > 2014-05-31 1:57 GMT-04:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > 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. >> >> > >

June 2, 2014

Re: [Pharo-dev] [Vm-dev] Rebound Home and End keys are non-functional on Mac

by Stefan Marr

Hi Eliot: On 02 Jun 2014, at 22:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > I've added those entries with this pull request: https://github.com/pharo-project/pharo-vm/pull/49 > > What's the easiest way to convert a pull request into either > a) a diff which can be used with patch? GitHub magic: https://github.com/pharo-project/pharo-vm/pull/49.diff or https://github.com/pharo-project/pharo-vm/pull/49.patch as you like. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/

June 2, 2014

Re: [Pharo-dev] OpenGL 3.0+

by stepharo

Hi darrin > 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. > Yes this is the plan. Use the athensDrawOn:, rewrite most of the drawOn: methods using Athens and having one API (Athens) with multiple back-ends. The future is what ronie and igor are doing :) and we need forces on that. Because it can change the face of Pharo for real :). > As for myself, I need an Athens backend for Roassal2 to avoid > having cairo->form->texture transfer > > > 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. Thanks for your points. We share them. This is why igor worked to have a vector graphics solution. You should look at Athens (this is just an API but a nice one and for now it has two back-ends). Igor is working a new texteditor and after we should convert the drawing of morph to use the Athens API. We want Pharo to be a modern and fast system (so this should answer your backward compatibility questions). Better moving than dead. Stef > > 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 > <mailto:btc@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 <mailto:roniesalg@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 <mailto:sean@clipperadams.com>>: >> >> darrinm wrote >> > Oh, and NBMacGLConstants is lacking necessary >> constants. Is it manually >> > created or generated somehow? >> > >> > - darrinm >> > >

June 2, 2014

Re: [Pharo-dev] [Vm-dev] Rebound Home and End keys are non-functional on Mac

by Eliot Miranda

Hi Darrin, thanks. On Sun, Jun 1, 2014 at 2:40 PM, Darrin Massena <darrin(a)massena.com> wrote: > > Rebound Home and End keys don't work on Macs except when used in > conjunction with the Command key. > > Fortunately the VM already has code to handle rebound keys and is just > missing entries for moveToBeginningOfLine and moveToEndOfLine, which the > Home/End keys are commonly rebound to. > > I've added those entries with this pull request: > https://github.com/pharo-project/pharo-vm/pull/49 > What's the easiest way to convert a pull request into either a) a diff which can be used with patch? b) a set of modified files? It would be great if there was a tool which avoided having to clone the repository, etc, etc, etc https://pharo.fogbugz.com/f/cases/13292/Rebound-Home-and-End-keys-non-funct… > -- best, Eliot

June 2, 2014