- Pharo-dev - lists.pharo.org

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

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

by stepharo

Thanks a lot. Esteban is travelling/on holiday so he will check that soon I imagine. Stef On 1/6/14 23:38, darrinm wrote: > https://pharo.fogbugz.com/f/cases/13292/Rebound-Home-and-End-keys-non-funct… > > 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 > > > > -- > View this message in context: http://forum.world.st/Rebound-Home-and-End-keys-are-non-functional-on-Mac-t… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > >

June 2, 2014

Re: [Pharo-dev] Initial versions for OSWindow and Woden

by stepharo

Hi ronie I should sync with igor to understand what is the path to integrate what you did with him. Because I want new events and what you and igor did (or at least I do not want to lose all the event cleaning I did long time ago). I wish a lot of success to Woden :) Stef On 31/5/14 11:54, Ronie Salgado wrote: > Hello There, > > I have been working in OSWindow, which is a cross platform API for > dealing with native operating system windows. This API requires using > a custom VM and the library SDL2. > > With this API, even the main Pharo window is handled almost completely > in image side using NativeBoost. > > The only support required from the VM is a small periodical check in > the heartbeat about the presence of events. This no more than 10 lines > of code. > > This is currently working very well in my Linux machine, so I need to > start testing this stuff. > > For Windows, soon I will be building the custom VM. My last built was > very dirty and I want to do something more clean. > > For Mac OS X, I don't have one for testing. But Alex is going allow me > to borrow one for some time. So be patience. > > As for Woden, it is a new 3D graphics engine that I started making. > This one requires currently support of OSWindow and also shows some > cool stuffs. > > As for prebuilt versions of the VM with OSWindow support along with > preloaded images for both, OSWindow and Woden. And screenshots. > > Well, I am putting them here: http://ronie.cl/OSWindow/ > > Greetings, > Ronie

June 2, 2014

Re: [Pharo-dev] GPU accelerated GUI

by stepharo

It depends what you measure. If you measure classBrowser opening then nautilus is slower because it is doing more stuff. Now we invested a lot in - cleaning morphic and we will continue. We fixed broken rectangles (around 150 creation), added Margin to avoid ifTrue: removed many of the totally useless extensions. Now we do it step by step because it takes time and we try to understand what we remove!!! - in Spec, spec is a MVP like system. Now building one takes time and ben did a great job. Now we should check if he will continue or not (it depends on him and his job). We should probably do a pass on Spec. Alain Plantec is rewriting core morphic from scratch and it is quite fast. He just shows me this after how he can package halos as a separate package. Now the risk is high because Alain does not have the amount of time he would like to work on that. 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. Stef >> 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. > It has ups and downs, if you get a Squeak 3.8 image and run it in a > 2Ghz computer, the UI will be fast, even Pharo 1.4 had a faster > interface that 3.0. You get a Cuis image and it's super fast. > > I find Pharo 3.0 UI to be slower than before, but not slow. It feels > like if Pharo had the mobile browsers 300ms tap delay too > (https://developers.google.com/mobile/articles/fast_buttons?hl=de-DE#touchev…) > > As said before, Morphic is slower than MVC too. > I always wondered why more money is put into Morphic, instead of > trying something else (MVC, MVP, MVVM, etc.). Maybe it's cheaper to > fix it than to make it again. > > Regards! > >

June 2, 2014

[pharo-project/pharo-core]

by GitHub

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

June 2, 2014

[pharo-project/pharo-core] 52b519: 40011

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 52b51942b940eec2b5e0b4eea1d6ce76d5b9adf6 https://github.com/pharo-project/pharo-core/commit/52b51942b940eec2b5e0b4ee… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-02 (Mon, 02 Jun 2014) Changed paths: M Morphic-Core.package/Morph.class/instance/drawing/fullDrawOn_.st M Morphic-Core.package/Morph.class/instance/geometry/outerBounds.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script11.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40011.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40011 12858 Remove hasRolloverBorder (Part 0) https://pharo.fogbugz.com/f/cases/12858 http://files.pharo.org/image/40/40011.zip

June 2, 2014

repackage morphic - introduction of morphic-widgets

by stepharo

Hi Pavel I'm about to perform the following https://pharo.fogbugz.com/default.asp?11825 This is what we brainstormed when I visited you but I prefer to double check. Morphic-Widgets-Basic SimpleSwitchMorph MulticolumnLazyListMorph SimpleButtonMorph LazyListMorph IconicButton ThreePhaseButtonMorph CalendarMorph Morphic-Widgets-Pluggable PluggableTabButtonMorph PluggableButtonMorph PluggableTextMorph PluggableMultiColumnListMorph PluggableTextMorphWithLimits PluggableTabBarMorph PluggableListMorph Morphic-Widgets-NewList NewList NewListRenderer NewListAdapter Morphic-Widgets-Tab Morphic-Widget-MorphTreeWidget Morphic-Widget-MorphTreeWidget-Pagination I would promote Morphic-Base-ProgressBar -> Morphic-ProgressBar

June 2, 2014

Re: [Pharo-dev] Zero Conf in windows CI

by Christophe Demarey

Le 31 mai 2014 Ã 09:55, Guillermo Polito a Ã©crit : > Hi guys! > > I'm trying to configure a windows (7-32bits) slave to run DBXTalk tests :). I've had a loooot of troubles already trying to configure right mingw and get it to compile C, but I succeeded. > > Now, I'm trying to get it run tests in Pharo, but I have problems with ZeroConf and probably temp directories. The log is here: > > https://ci.inria.fr/dbxtalk/job/DBXTalk-OpenDBXDriver-Mysql/PHARO_VERSION=3… > > In summary, I have the following output: > > Downloading the latest 30 Image: > http://files.pharo.org/image/30/latest.zip > Access denied - IMAGE.QGJEMX > File not found - -NAME > > The access denied I think is from the rm -rf of the temp directory, because the temp directory is created in the workspace and the image file is there and unzipped. The File not found looks like coming from the find. > > Maybe I'm lacking some environment variables I didn't configure... I tried comparing my slaves with the ones used in Pharo and I didn't take it much further. Additionally, if I connect to the slave through remote desktop (:puke:), and try to execute the zero conf script with the same user, on the same folder from a msys console, I have no errors. > > Maybe someone has an idea? :) Indeed. Very strange. You can find all environment variables available to your jenkins job for this slave here: https://ci.inria.fr/dbxtalk/computer/dbxtalk-windows-32bit/systemInfo There are some other variable added on the fly, depending on your job config (values of axis in matrix jobs for example). I defined a test job to debug that: https://ci.inria.fr/dbxtalk/job/test-zeroconf/8/console The error comes from the http://get.pharo.org/vm. It looks like a permission problem to write in the workspace of your slave. Hope this helps, Christophe.

June 2, 2014