Re: [Pharo-dev] String deduplication
On 30.05.14 17:12, Chris Muller wrote: I hope you're only considering this one-time for your Pharo release image, and not something that will _continue_ to operating on an on-going basis. Of course. Besides all the problems it's also way too slow. Cheers Philippe
Re: [Pharo-dev] WhatsUp from: 2014-06-02 until: 2014-06-15
seas...@rmod.lille.inria.fr wrote: Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: * PharoLaserGame tutorial. * Fine tuning some things is Pillar. ### What's next, until 2014-06-15 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION * Just the same.
Re: [Pharo-dev] ExternalPipemakePipe error
On Mon, Jun 2, 2014 at 7:34 AM, Max Leske maxle...@gmail.com wrote: @Damien That means your answer on SO won't work. And since the VM doesn't come with the OSProcess plugin (at least it's not in the Plugins directory), there's no easy way of solving this other than updating ConfigurationOfPythonParser, I guess. I will see if I can make a stable configuration that does not use gitfiletree -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] Pharo and Amber
On Sun, Jun 1, 2014 at 11:19 AM, Torsten Bergmann asta...@gmx.de wrote: Is there an Amber-Pharo one click built with CI to allow development with both (amber for client, pharo on server). https://ci.inria.fr/pharo-contribution/job/Tide/ -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] String deduplication
Le 30 mai 2014 à 09:39, Philippe Marschall a écrit : Hi This is an idea I stole from somebody else. The assumption is that you have a lot of Strings in the image that are equal. We could therefore remove the duplicates and make all the objects refer to the same instance. I worked on a String optimisation for a Java virtual machine dedicated to small hardwares. A string was represented by an array of bytes (UTF8 or ASCII encoding), a start position, and the number of characters of the string. It allows to reuse the internal byte array for different strings but the String object was different for each String. With this approach, you are able to save a lot of memory (but with some CPU overhead) and you don't have a problems because you have different String objects for each String. ex: b1: 'Hello World! It's a sunny day' 'Hello World! It's a sunny day' : start = 0, count = 29, value b1 'Hello' : start = 0, count = 5, value b1 'Hello World!' : start = 0, count = 12, value b1 'World': start = 6, count = 5, value b1 I don't see how it may be applied to Smalltalk and it makes sense. Christophe. smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] GPU accelerated GUI
Hi Darrin, Quoting darrinm dar...@massena.com: You get a Cuis image and it's super fast. What machine are you running on? I just gave the 2009 image of Cuis a try on my current-model Mac Pro (3.6 GHz, 6 cores, tons of RAM) and honestly just dragging a window around was terribly slow. Just guessing, I'd say 10 FPS or less which probably half what I see with Pharo. Is the VM a factor? Should I try a different one? Thanks. I don't have a Mac at hand right now, but on this I5 Windows 7 notebook, dragging Cuis windows (full content, not just a frame) is smoother and more free of artifacts than doing the same with native Windows windows (for example, file explorers). You might try with the latest Cog VM. In any case, the speed advantage of Cuis morphic can better be seen by opening a FileList on a very large file and scrolling, or scrolling very large lists, or resizing browser windows (with all layout being recalculated 'live'). In any case, you are welcome to continue this discussion at http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org , the Cuis mail list. Cheers, Juan Vuletich
Re: [Pharo-dev] GPU accelerated GUI
Hi Esteban, Quoting Esteban A. Maringolo emaring...@gmail.com: I couldn't tell exactly, I haven't used Cuis in the last year or so, but at that time (Pharo 2 was new) it was the faster of the three brothers (Pharo/Squeak/Cuis). Maybe that changed lately and Cuis got slower too. Apparently it is very easy to bloat Morphic. Regards, Esteban A. Maringolo We are _not_ bloating Morphic in Cuis. Just download a recent image and see for yourself. 2014-06-01 21:07 GMT-03:00 darrinm dar...@massena.com: You get a Cuis image and it's super fast. What machine are you running on? I just gave the 2009 image of Cuis a try on my current-model Mac Pro (3.6 GHz, 6 cores, tons of RAM) and honestly just dragging a window around was terribly slow. Just guessing, I'd say 10 FPS or less which probably half what I see with Pharo. Is the VM a factor? Should I try a different one? Thanks. -- View this message in context: http://forum.world.st/GPU-accelerated-GUI-tp4760898p4761231.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. Cheers, Juan Vuletich
Re: [Pharo-dev] String deduplication
This is a normal pattern in application-development. For example, Todd Blanchard's HTML validating parser grabs a huge chunk of HTML, and all the parts are simply referenced by position within that big String. On Mon, Jun 2, 2014 at 8:26 AM, Christophe Demarey christophe.dema...@inria.fr wrote: Le 30 mai 2014 à 09:39, Philippe Marschall a écrit : Hi This is an idea I stole from somebody else. The assumption is that you have a lot of Strings in the image that are equal. We could therefore remove the duplicates and make all the objects refer to the same instance. I worked on a String optimisation for a Java virtual machine dedicated to small hardwares. A string was represented by an array of bytes (UTF8 or ASCII encoding), a start position, and the number of characters of the string. It allows to reuse the internal byte array for different strings but the String object was different for each String. With this approach, you are able to save a lot of memory (but with some CPU overhead) and you don't have a problems because you have different String objects for each String. ex: b1: 'Hello World! It's a sunny day' 'Hello World! It's a sunny day' : start = 0, count = 29, value b1 'Hello' : start = 0, count = 5, value b1 'Hello World!' : start = 0, count = 12, value b1 'World': start = 6, count = 5, value b1 I don't see how it may be applied to Smalltalk and it makes sense. Christophe.
[Pharo-dev] Fwd: [Pharo-users] [SummerTalk] Refactoring in Pharo
-- Forwarded message -- From: Mark Rizun mri...@gmail.com Date: Mon, Jun 2, 2014 at 4:19 PM Subject: [Pharo-users] [SummerTalk] Refactoring in Pharo To: Any question about pharo is welcome pharo-us...@lists.pharo.org Hi guys! I'm happy to announce you, that I will be working on SummerTalk project entitled Refactoring in Pharo with RMoD. Obviously, it's about refactoring system in Pharo. The goal of this project is to improve existing refactrings in Pharo and add some new ones. If you are interested in this topic please visit my blog for more details: http://myfuncoding.blogspot.com/ After some work is done, I'll publish info here and on my blog. Also, source code will be available on my smalltalkhub, and it's going to be soon ;) Thoughts and feedback are welcome. Cheers, Mark -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] Zero Conf in windows CI
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 lt 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=30,Platform=dbxtalk-windows-32bit,VERSION=bleedingEdge/59/console 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. smime.p7s Description: S/MIME cryptographic signature
[Pharo-dev] repackage morphic - introduction of morphic-widgets
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
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40011 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] 52b519: 40011
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 52b51942b940eec2b5e0b4eea1d6ce76d5b9adf6 https://github.com/pharo-project/pharo-core/commit/52b51942b940eec2b5e0b4eea1d6ce76d5b9adf6 Author: Jenkins Build Server bo...@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
Re: [Pharo-dev] GPU accelerated GUI
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#touchevents) 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!
Re: [Pharo-dev] Initial versions for OSWindow and Woden
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
Re: [Pharo-dev] OpenGL 3.0+
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 b...@openinworld.com mailto:b...@openinworld.com: Darrin Massena wrote: Thanks for all the great info Ronie! On Fri, May 30, 2014 at 4:06 PM, Ronie Salgado ronies...@gmail.com mailto:ronies...@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
Re: [Pharo-dev] OpenGL 3.0+
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 steph...@free.fr mailto:steph...@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 s...@clipperadams.com mailto:s...@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.
Re: [Pharo-dev] Regular Hangouts
On 31/5/14 10:53, p...@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 steph...@free.fr mailto:steph...@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
[Pharo-dev] [pharo-project/pharo-core] 516c28: 40012
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 516c28085be219cbf7ac535d92c49068e6e3e5fc https://github.com/pharo-project/pharo-core/commit/516c28085be219cbf7ac535d92c49068e6e3e5fc Author: Jenkins Build Server bo...@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
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40012 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [OT] Swift - Apple Developer
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
Re: [Pharo-dev] GPU accelerated GUI
2014-06-02 16:51 GMT-03:00 stepharo steph...@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.
Re: [Pharo-dev] Rebound Home and End keys are non-functional on Mac
You're welcome. I'm new to Smalltalk so I'm glad it wasn't very difficult. On Mon, Jun 2, 2014 at 12:59 PM, stepharo steph...@free.fr wrote: 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-functional-on-Mac 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-tp4761220.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [OT] Swift - Apple Developer
Maybe they don’t have a standalone thing like “x” : y, and so array-like definition with colons becomes a dict Uko On 03 Jun 2014, at 03:22, Sven Van Caekenberghe s...@stfx.eu wrote: 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
Re: [Pharo-dev] GPU accelerated GUI
I'm learning and would love to hear ideas about how best to benchmark Smalltalk rendering. I tried this very crude test in a Workspace: loops := 100. rect := Display boundingBox. a := Time millisecondsToRun: [ loops timesRepeat: [ Display forceToScreen: rect. ]. ]. Transcript show: a / loops asFloat; cr. With a full-screen window on a current model Mac Pro with stock Pharo 3 image and VM it reports 47 ms/update. On my Surface Pro 2 (Windows 8) it is takes only 1.1 ms. I'm kind of shocked by that number in comparison. It's a lower resolution screen but still. I know full screen updates are not the norm for many applications but they're still very important. Also keep in mind this is just the low level screen update, no Morphic overhead. Ideally the display update takes less than a millisecond to leave time for all the higher level rendering. For performance assessment I'd like to have a nice Frames Per Second graph running in the corner as well as repeatable test cases matching common uses (scrolling, full updates, partial updates, empty window, densely packed grid, text editor, etc) that could be run across platforms. After that I wonder about profiling. Can accurate timed traces be done from top to bottom? I imagine it would at least get murky at the VM boundary. I also noticed logic to limit display updates to 50 times a second, presumably to minimize CPU usage. CPU usage would also be reduced by optimizing rendering but in any case I'd like to see an update rate synchronized with the video rate or faster (60 or more). That would minimize tearing and allow for no perceivable UI lag. On Mon, Jun 2, 2014 at 3:48 PM, Esteban A. Maringolo emaring...@gmail.com wrote: 2014-06-02 16:51 GMT-03:00 stepharo steph...@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.
Re: [Pharo-dev] Dangling process related with styling
Yeah, I see them regularly as well, it has been like that for quite some time... On 03 Jun 2014, at 01:19, Esteban A. Maringolo emaring...@gmail.com wrote: While looking at the Process Monitor, from time to time I find processes, apparently waiting on a Semaphore, related with the syling of the Pharo UI (see attached picture). I'm killing those as I spot them, but I guess they shouldn't be there in the first place. Is it a bug? Esteban A. Maringolo pharo-procs.png
