- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Debugger layout again

by Tudor Girba

Hi, Even though the current default layout is not my preference, it is not unusable :). But, letâs do it differently. Would you like to take a look at what it takes to build a debugger with your layout? Cheers, Doru > On Jan 27, 2017, at 12:17 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi again, > > there is still no way to change the debugger layout to have it the same way as Mooseâ¦ Why did we change layout in Pharo in the first place? It was so nice: you had the stack with the whole highlighting on the side, so you could see more. > > Why do we have to make things unusable in Pharo? > Uko > > P.S. ok, ok, I guess I will just move to Moose. -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

Jan. 27, 2017

Re: [Pharo-dev] [bloc] addressing the moz2d issue

by Esteban Lorenzano

(I was going to answer a big mail but my observations/concerns are mostly targeted by Norbert and Stef) > On 27 Jan 2017, at 10:49, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Thanks for the detailed analysis. > > In summary, Cairo+Pango+SDL2 provide enough support to get a subset of Sparta working that would be equivalent with the Athens that we already have. In other words, with such a backend, when we would tell Sparta to use a blur effect, it will simply do nothing and the image environment can continue to work as it does now. > > I hope that everyone agrees that this is a reasonable fallback scenario that we can count on. And I think this is in line with what Stef was saying as well. > > With this in mind, we should also remember that the Moz2D backend works now which means that we can now focus on Brick to close the loop and provide a complete stack that more people can start utilizing, and we can come back to the alternative backend later. > > Does this path to action address the worry related to the future of Sparta backends? thanks Doruâ¦. I think having a base system that works in all scenarios (even if we miss some features) and is easy to maintain is important. Then you can have a different backend for complex stuff (is more or less the same about Ronieâs Woodenâ¦ I love to have the possibility of doing the things Ronie do with that, but I would never target to build my UI system on top of it). Even with this simplification, I would like to know why you choose to strip a library from a project instead testing, for example Skia (I know, Skia api is not stable, and is C++ and C bindings are still unstable), but wellâ¦ others maybe. And some precisions: - SDL2 do allow transparent windows and windows without decorations. https://wiki.libsdl.org/SDL_SetWindowOpacity <https://wiki.libsdl.org/SDL_SetWindowOpacity>, https://wiki.libsdl.org/SDL_CreateWindow <https://wiki.libsdl.org/SDL_CreateWindow> (and the flags section) - Cairo do allow acceleration, we need to compile it with right backend. - I disagree is a dead technology. Instead, is a very mature technologyâ¦ thatâs why forum is not too active (even if as far as I see, it was never too active). Yes, maybe is not in the hype, but is cool and allow us to do very nice things. - examples on images are slow because of how they are programmed, not because of cairo :) cheers! Esteban ps: instead ânot doing anythingâ non-suported-operations could throw a notification (a silent one)? > > Cheers, > Doru > > > >> On Jan 26, 2017, at 11:45 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >> Hi >> >> (My previous email was not a joke, I don't try to troll anyone. Let tolls do their job in other places) >> Let's forget Moz2D for a moment :) Imagine that it does not exist. It was done just for fun and is even not in pharo repo. (https://github.com/syrel/Moz2D) We needed something that works and it was made investing just a few months of time of a single anonymous student during summer exams session and vacations. >> >> I would like to start maybe one of the most important discussion that will influence Pharo and will dictate how system will look like in a few years. I invite everyone to join this discussion, especially board and consortium members. Because here is where business starts. >> >> There are some real questions: >> â¢ Do we need Bloc or Morphic2 or %name your favourite framework%? >> â¢ How advanced and modern do you want it to be? >> â¢ What technology stack do we want to use for our new graphical framework? >> â¢ What platforms and operating systems do we want to support? >> â¢ How flexible technology stack should be? (some parts may change in the future) >> â¢ Who will pay for it? >> â¢ How many engineers can community afford? >> â¢ Do you know how much other systems invest in graphical frameworks? >> â¢ It is not a science project, isn't it? >> Let me first put my two cents in. >> >> Low-level UI framework (without widgets) consists of multiple parts: >> â¢ Vector graphics library to render shapes (fill, stroke, path builder, composition and blending operators) >> â¢ Font service library (to support different font formats and collect information about local fonts installed in the system) >> â¢ Text layout engine (this is where glyph positioning magic happens, link above too) >> â¢ Text shaping engine (for high quality text rendering, to understand the problem => http://behdad.org/text/) >> â¢ Complex script library (to support ligatures, split glyphs and other UTF8 stuff, remember https://github.com/minimaxir/big-list-of-naughty-strings) >> â¢ Image processing library (for various image effects, like gaussian blur, morphology filter, gamma, displacement map, just to name a few) >> â¢ Hardware acceleration. Software rendering is nice, however, modern UIs are full of fancy stuff that require hardware acceleration. >> â¢ Window and Event management library. With support of borderless and semi-transparent windows + good support of touchpad. >> â¢ Custom written "Glue" library that allows all components to work together. Since modern libs are implemented in C++ we would need to implement C wrapper and a lot of integration tests. >> â¢ Make the whole beast cross platform. >> >> Did I miss something? >> >> Here are some modern technologies commonly used for mentioned parts: >> â¢ Skia, Direct2D, CoreGraphics, Cairo >> â¢ Fontconfig, Freetype2 >> â¢ HarfBuzz >> â¢ Pango, OpenType >> â¢ Graphite2, FriBidi >> â¢ Imagemagic, SVG filters libraries >> â¢ Vulkan, OpenGL >> â¢ wxWidgets, QT, GTK, SDL2 >> â¢ todo >> â¢ todo >> Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea! >> >> Let's assume that we stop on Cairo + Pango. According to pango.com >> >> The integration of Pango with Cairo (http://cairographics.org/) provides a complete solution with high quality text handling and graphics rendering. >> >> According to the this potential technology stack we will have: >> â¢ Cairo for vector graphics and rendering of basic shapes >> â¢ Pango for text rendering >> â¢ SDL2 for window and events management >> What we will not get: >> â¢ Support of filters; Cairo does not support gaussian blur. 3D transformations, we will not be able to not implement card flip animation. Never reach the same performance if using platform native frameworks (e.g. Direct2D on windows). Cairo will not die, but there is zero progress. >> â¢ Vulkan support. Never with cairo. Pure OpenGL too (try to compile cairo-gl on mac, good luck!) There is a way to compile it with quartz support. As of version 2.7.9, XQuartz does not provide support for high-resolution Retina displays to X11 apps, which run in pixel-doubled mode on high-resolution displays. (https://bugs.freedesktop.org/show_bug.cgi?id=92777) >> â¢ Borderless or transparent window with SDL2. Also, did you notice that sdl2 window turns black/white while resizing? There is no way to get a continuous window resize event with SDL2 (https://bugzilla.libsdl.org/show_bug.cgi?id=2077) The issue is that events stop firing while user is resizing a window because main thread is blocked. Bug is already 3 years old. Indeed SDL2 is used for games, however how often do gamers resize game window? >> â¢ Stateless API. Must have for a graphical framework like Bloc where canvas state is not shared between visual elements. It means that while rendering users must not clean the state of a canvas after every draw call. >> Bloc is not my or Glenn's or Doru's personal property. We suggest, you decide. It would be great if community could invest money and time in a working and appropriate solution. >> >> P.S. If we would not care, we would agree with you instantly and even not bothered ourselves trying to spend time on finding cheap solution for such a complex problem. >> >> P.P.S Sorry for a long email :) >> >> Cheers, >> Alex >> >> On 26 January 2017 at 21:10, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> Hi, >> >> Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 (for fonts) + Graphite (glyphs shaping technology in order to use them within vector graphics engine) + cross platform OpenGL / Vulkan context/device provider for hardware acceleration + implement Filters for effects (blur, lights, color matrix filters, etc...). >> >> Without all those technologies bloc WILL progress, from 80's to 00's. Still decades behind :) >> >> Cheers >> >> On Jan 26, 2017 20:40, "stepharong" <stepharong(a)free.fr> wrote: >> I think that instead of investigating gtk (yet another library to bind and carry around), >> it would be smarter to have Sparta back-end using an accelerated Cairo + pango. >> Why? Because >> - For example Cairo will not disappear in the future (here you will tell me that it does not have all the full >> features.... I think that Bloc should deliver Brick first and focus on this because else it will stay a nice >> experiment.) >> - We do not have bench with an accelerated compiled version so no idea if this is good enough. >> - Cairo is about 1.5 mb vs 20Mb and it is packaged. >> >> I share the concerns of Esteban about the maintenance of such Mozz2d bundling and he was pretty >> clear with me, he will not maintain it nor take any responsibility about pharo using it. >> >> So having a Cairo Sparta back-end would be a smart move. >> Stef >> >> >> >> >> >> Hi, >> >> Thank you for the intensive set of issues you raised during the Bloc presentation. I think it is worthwhile addressing them more thoroughly, so let me start with the issue that seemed to have caused the most worries: Sparta & Moz2D. >> >> Please keep in mind that while I am involved to some extent in Bloc, the real credits for the current state go to Glenn and Alex. >> >> Moz2D (https://github.com/mozilla/moz2d, https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend and using it puts us on par with the rendering speed of a web browser, which is a significant added value over what we have now. >> >> However, as it was noted, it does come with a cost due to the fact that it is not available as standalone with only the features we are interested in. The vector graphics part is actually buildable out of the box. However, the text support needs to be extracted out of Moz2D, and this is where the patching scripts are used. The patches are there only for compilation purposes and not for features and they are applied automatically. You can see it here: >> https://github.com/syrel/Moz2D >> >> Alex updated recently the Moz2D version and it worked without problems. Of course, future changes in Moz2D might imply changes in this script as well, and this implies that we will need to maintain that script. And we could imagine applying these patches on the trunk of Moz2D to see if they work, and we can also imagine engaging with the Moz2D owners to see if we can find a middle ground. >> >> Now, letâs put this into perspective. We are currently using Athens and the Cairo backend. While Cairo is provided as a standalone library it has not seen significant advances since Mozzila shifted its focus towards Moz2D. So, sticking with it might not be an ideal strategy either. >> >> Furthermore, just like Athens, Sparta is an abstraction that allows us to switch the underlying backend should we need to. Until now we did not find a cross-platform backend that is as advanced and complete as Moz2D, but there is no reason to think that none other will appear in the future. Skia is an alternative but it is only a vector graphic engine without text support, so using it would imply to have another library for the text support. >> >> Sparta also comes with a reasonable set of tests that is aimed at testing the basic Moz2D functionality to make sure that the assumptions on top of which Sparta is built are correct. >> >> All in all, I think that the current situation is not ideal, but there is already enough engineering in place to actually make it work. And I definitely think that the potential it opens is rather significant. >> >> And, if more people look at the scripts, we might find even better and cheaper ways to express it. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "We cannot reach the flow of things unless we let go." >> >> >> >> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing should have the right to be different." > > > > >

Jan. 27, 2017

Debugger layout again

by Yuriy Tymchuk

Hi again, there is still no way to change the debugger layout to have it the same way as Mooseâ¦ Why did we change layout in Pharo in the first place? It was so nice: you had the stack with the whole highlighting on the side, so you could see more. Why do we have to make things unusable in Pharo? Uko P.S. ok, ok, I guess I will just move to Moose.

Jan. 27, 2017

[pharo-project/pharo-core] 2826e1: 60360

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 2826e17146a93f9bc19312c213f68a1a19c5ac94 https://github.com/pharo-project/pharo-core/commit/2826e17146a93f9bc19312c2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-27 (Fri, 27 Jan 2017) Changed paths: M Network-Kernel.package/Socket.class/instance/accessing/localAddress.st M Network-Kernel.package/Socket.class/instance/accessing/localPort.st M Network-Kernel.package/Socket.class/instance/accessing/remoteAddress.st M Network-Kernel.package/Socket.class/instance/accessing/remotePort.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60359.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60360.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60359.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60360.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60360 19568 Socket local host/port has incorrect guard https://pharo.fogbugz.com/f/cases/19568 http://files.pharo.org/image/60/60360.zip

Jan. 27, 2017

[pharo-project/pharo-core]

by GitHub

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

Jan. 27, 2017

[pharo-project/pharo-core] 7521fc: 60359

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 7521fce5d465db73b2a6dfe478a38042792a57d2 https://github.com/pharo-project/pharo-core/commit/7521fce5d465db73b2a6dfe4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-27 (Fri, 27 Jan 2017) Changed paths: M HudsonBuildTools20.package/TestCommandLineHandler.class/instance/private/runPackages.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60358.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60359.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60358.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60359.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60359 19588 TestCommandLineHandler should not call exitSuccess https://pharo.fogbugz.com/f/cases/19588 http://files.pharo.org/image/60/60359.zip

Jan. 27, 2017

[pharo-project/pharo-core]

by GitHub

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

Jan. 27, 2017

Re: [Pharo-dev] [bloc] addressing the moz2d issue

by Tudor Girba

Hi, Thanks for the detailed analysis. In summary, Cairo+Pango+SDL2 provide enough support to get a subset of Sparta working that would be equivalent with the Athens that we already have. In other words, with such a backend, when we would tell Sparta to use a blur effect, it will simply do nothing and the image environment can continue to work as it does now. I hope that everyone agrees that this is a reasonable fallback scenario that we can count on. And I think this is in line with what Stef was saying as well. With this in mind, we should also remember that the Moz2D backend works now which means that we can now focus on Brick to close the loop and provide a complete stack that more people can start utilizing, and we can come back to the alternative backend later. Does this path to action address the worry related to the future of Sparta backends? Cheers, Doru > On Jan 26, 2017, at 11:45 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hi > > (My previous email was not a joke, I don't try to troll anyone. Let tolls do their job in other places) > Let's forget Moz2D for a moment :) Imagine that it does not exist. It was done just for fun and is even not in pharo repo. (https://github.com/syrel/Moz2D) We needed something that works and it was made investing just a few months of time of a single anonymous student during summer exams session and vacations. > > I would like to start maybe one of the most important discussion that will influence Pharo and will dictate how system will look like in a few years. I invite everyone to join this discussion, especially board and consortium members. Because here is where business starts. > > There are some real questions: > â¢ Do we need Bloc or Morphic2 or %name your favourite framework%? > â¢ How advanced and modern do you want it to be? > â¢ What technology stack do we want to use for our new graphical framework? > â¢ What platforms and operating systems do we want to support? > â¢ How flexible technology stack should be? (some parts may change in the future) > â¢ Who will pay for it? > â¢ How many engineers can community afford? > â¢ Do you know how much other systems invest in graphical frameworks? > â¢ It is not a science project, isn't it? > Let me first put my two cents in. > > Low-level UI framework (without widgets) consists of multiple parts: > â¢ Vector graphics library to render shapes (fill, stroke, path builder, composition and blending operators) > â¢ Font service library (to support different font formats and collect information about local fonts installed in the system) > â¢ Text layout engine (this is where glyph positioning magic happens, link above too) > â¢ Text shaping engine (for high quality text rendering, to understand the problem => http://behdad.org/text/) > â¢ Complex script library (to support ligatures, split glyphs and other UTF8 stuff, remember https://github.com/minimaxir/big-list-of-naughty-strings) > â¢ Image processing library (for various image effects, like gaussian blur, morphology filter, gamma, displacement map, just to name a few) > â¢ Hardware acceleration. Software rendering is nice, however, modern UIs are full of fancy stuff that require hardware acceleration. > â¢ Window and Event management library. With support of borderless and semi-transparent windows + good support of touchpad. > â¢ Custom written "Glue" library that allows all components to work together. Since modern libs are implemented in C++ we would need to implement C wrapper and a lot of integration tests. > â¢ Make the whole beast cross platform. > > Did I miss something? > > Here are some modern technologies commonly used for mentioned parts: > â¢ Skia, Direct2D, CoreGraphics, Cairo > â¢ Fontconfig, Freetype2 > â¢ HarfBuzz > â¢ Pango, OpenType > â¢ Graphite2, FriBidi > â¢ Imagemagic, SVG filters libraries > â¢ Vulkan, OpenGL > â¢ wxWidgets, QT, GTK, SDL2 > â¢ todo > â¢ todo > Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea! > > Let's assume that we stop on Cairo + Pango. According to pango.com > > The integration of Pango with Cairo (http://cairographics.org/) provides a complete solution with high quality text handling and graphics rendering. > > According to the this potential technology stack we will have: > â¢ Cairo for vector graphics and rendering of basic shapes > â¢ Pango for text rendering > â¢ SDL2 for window and events management > What we will not get: > â¢ Support of filters; Cairo does not support gaussian blur. 3D transformations, we will not be able to not implement card flip animation. Never reach the same performance if using platform native frameworks (e.g. Direct2D on windows). Cairo will not die, but there is zero progress. > â¢ Vulkan support. Never with cairo. Pure OpenGL too (try to compile cairo-gl on mac, good luck!) There is a way to compile it with quartz support. As of version 2.7.9, XQuartz does not provide support for high-resolution Retina displays to X11 apps, which run in pixel-doubled mode on high-resolution displays. (https://bugs.freedesktop.org/show_bug.cgi?id=92777) > â¢ Borderless or transparent window with SDL2. Also, did you notice that sdl2 window turns black/white while resizing? There is no way to get a continuous window resize event with SDL2 (https://bugzilla.libsdl.org/show_bug.cgi?id=2077) The issue is that events stop firing while user is resizing a window because main thread is blocked. Bug is already 3 years old. Indeed SDL2 is used for games, however how often do gamers resize game window? > â¢ Stateless API. Must have for a graphical framework like Bloc where canvas state is not shared between visual elements. It means that while rendering users must not clean the state of a canvas after every draw call. > Bloc is not my or Glenn's or Doru's personal property. We suggest, you decide. It would be great if community could invest money and time in a working and appropriate solution. > > P.S. If we would not care, we would agree with you instantly and even not bothered ourselves trying to spend time on finding cheap solution for such a complex problem. > > P.P.S Sorry for a long email :) > > Cheers, > Alex > > On 26 January 2017 at 21:10, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 (for fonts) + Graphite (glyphs shaping technology in order to use them within vector graphics engine) + cross platform OpenGL / Vulkan context/device provider for hardware acceleration + implement Filters for effects (blur, lights, color matrix filters, etc...). > > Without all those technologies bloc WILL progress, from 80's to 00's. Still decades behind :) > > Cheers > > On Jan 26, 2017 20:40, "stepharong" <stepharong(a)free.fr> wrote: > I think that instead of investigating gtk (yet another library to bind and carry around), > it would be smarter to have Sparta back-end using an accelerated Cairo + pango. > Why? Because > - For example Cairo will not disappear in the future (here you will tell me that it does not have all the full > features.... I think that Bloc should deliver Brick first and focus on this because else it will stay a nice > experiment.) > - We do not have bench with an accelerated compiled version so no idea if this is good enough. > - Cairo is about 1.5 mb vs 20Mb and it is packaged. > > I share the concerns of Esteban about the maintenance of such Mozz2d bundling and he was pretty > clear with me, he will not maintain it nor take any responsibility about pharo using it. > > So having a Cairo Sparta back-end would be a smart move. > Stef > > > > > > Hi, > > Thank you for the intensive set of issues you raised during the Bloc presentation. I think it is worthwhile addressing them more thoroughly, so let me start with the issue that seemed to have caused the most worries: Sparta & Moz2D. > > Please keep in mind that while I am involved to some extent in Bloc, the real credits for the current state go to Glenn and Alex. > > Moz2D (https://github.com/mozilla/moz2d, https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend and using it puts us on par with the rendering speed of a web browser, which is a significant added value over what we have now. > > However, as it was noted, it does come with a cost due to the fact that it is not available as standalone with only the features we are interested in. The vector graphics part is actually buildable out of the box. However, the text support needs to be extracted out of Moz2D, and this is where the patching scripts are used. The patches are there only for compilation purposes and not for features and they are applied automatically. You can see it here: > https://github.com/syrel/Moz2D > > Alex updated recently the Moz2D version and it worked without problems. Of course, future changes in Moz2D might imply changes in this script as well, and this implies that we will need to maintain that script. And we could imagine applying these patches on the trunk of Moz2D to see if they work, and we can also imagine engaging with the Moz2D owners to see if we can find a middle ground. > > Now, letâs put this into perspective. We are currently using Athens and the Cairo backend. While Cairo is provided as a standalone library it has not seen significant advances since Mozzila shifted its focus towards Moz2D. So, sticking with it might not be an ideal strategy either. > > Furthermore, just like Athens, Sparta is an abstraction that allows us to switch the underlying backend should we need to. Until now we did not find a cross-platform backend that is as advanced and complete as Moz2D, but there is no reason to think that none other will appear in the future. Skia is an alternative but it is only a vector graphic engine without text support, so using it would imply to have another library for the text support. > > Sparta also comes with a reasonable set of tests that is aimed at testing the basic Moz2D functionality to make sure that the assumptions on top of which Sparta is built are correct. > > All in all, I think that the current situation is not ideal, but there is already enough engineering in place to actually make it work. And I definitely think that the potential it opens is rather significant. > > And, if more people look at the scripts, we might find even better and cheaper ways to express it. > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "We cannot reach the flow of things unless we let go." > > > > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > > -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."

Jan. 27, 2017

[pharo-project/pharo-core]

by GitHub

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

Jan. 27, 2017

[pharo-project/pharo-core] 9ec797: 60358

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 9ec797777a0c91797f3111e43511e5629b6df34a https://github.com/pharo-project/pharo-core/commit/9ec797777a0c91797f3111e4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-27 (Fri, 27 Jan 2017) Changed paths: M FreeType.package/FT2Handle.class/class/private-handle registry/register_.st M FreeType.package/FT2Handle.class/instance/private/pvtDestroyHandle.st M NECompletion.package/NECUntypedModel.class/instance/private/initializeSelectors.st M Nautilus.package/MethodWidget.class/instance/icon/methodIconFor_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60357.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60358.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60357.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60358.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60358 19315 Freetype2 primitive failed [error 2][unknown file format] https://pharo.fogbugz.com/f/cases/19315 19610 NEC has unacceptable performance when selectors == false https://pharo.fogbugz.com/f/cases/19610 18232 Breakpoints cannot be toggled in Nautilus method pane https://pharo.fogbugz.com/f/cases/18232 http://files.pharo.org/image/60/60358.zip

Jan. 27, 2017