April 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)

by Sven Van Caekenberghe

Thanks a lot for actually diving into this, this mysterious issue has been bugging us for a very long time. I do hope you can finally solve this. I am sure many people will be grateful. Sven > On 10 Apr 2019, at 15:38, tesonep(a)gmail.com wrote: > > Hello, > > After checking the problem with Guille, we have the hypothesis of the > source of the problem. > We have seen that accessing Free Type is not thread-safe. > Basically, the FTFace holds a structure that is filled up with the > glyph and its information. As this structure is part of the Font Face > (a font face is a font plus size and attributes), only one request to > a glyph can be executed at the time. As we are sharing the same font > in many places, you will be starting to see the problem. > > Also, we have seen that there many accesses to the glyphs outside the > UI process. > This problem started to appear as we starting to use Calypso (but it > is not limited to it), as Calypso uses lazy tabs. The creation of > these tabs is done outside the UI process. > > This is only a hack to test our hypothesis. > To fix it correctly we will have to rewrite the drawing of the glyphs > and synchronize the access to the glyph data information. Also, we > want to do it in a way that does not penalize the processing in the UI > process. > > I have only patched the code that is used by the rendering of morphic, > other renderings like Athens or any other user using FT should be > correctly rewritten. > > Once we are sure that synchronizing the access to FT fixes the > problem, we will do a real fix not a dirty hack like this. > > I will be testing this new Image to see if there is an improvement. > > I will really love you try to use this image and tell me if you still > find the problem. > > There is a PR generating a Pharo8 image (it is called wrong, but... it > is a Pharo8) > > 32 bits > ===== > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > 64 bits > ===== > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > If somebody is willing to use it in Pharo 7, I can create a PR against > Pharo7 to generate patched P7 images. > > Thanks! > > -- > Pablo Tesone. > tesonep(a)gmail.com >

April 10, 2019

Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)

by Stephan Eggermont

tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > If somebody is willing to use it in Pharo 7, I can create a PR against > Pharo7 to generate patched P7 images. Yes, I want to Stephan

April 10, 2019

Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)

by ducasse

Thanks Nicolas. You know that I appreciate your work. I would appreciate that Eliot does not send me personal emails to tell that Iâm a bad leader :) but at least this is coherent with the violent emails I received in the past - nothing new under the sun. Just anger against me. I cannot do much. I imagine that I cannot avoid the send so I will block the reception :). > On Apr 10, 2019, at 7:08 AM, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: > > Thank you P and G. > It is so annoying. Why can you not include Nicolas Cellier in your thanks? He provided pertinent information. That you only ever thank members of the Pharo team I find annoying. It is bad leadership. > On 10 Apr 2019, at 15:49, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Good find! > The fac tthat FT_Face is not thread-safe is documented > https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html <https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html> > > Le mer. 10 avr. 2019 Ã 15:39, tesonep(a)gmail.com <mailto:tesonep@gmail.com> <tesonep(a)gmail.com <mailto:tesonep@gmail.com>> a Ã©crit : > Hello, > > After checking the problem with Guille, we have the hypothesis of the > source of the problem. > We have seen that accessing Free Type is not thread-safe. > Basically, the FTFace holds a structure that is filled up with the > glyph and its information. As this structure is part of the Font Face > (a font face is a font plus size and attributes), only one request to > a glyph can be executed at the time. As we are sharing the same font > in many places, you will be starting to see the problem. > > Also, we have seen that there many accesses to the glyphs outside the > UI process. > This problem started to appear as we starting to use Calypso (but it > is not limited to it), as Calypso uses lazy tabs. The creation of > these tabs is done outside the UI process. > > This is only a hack to test our hypothesis. > To fix it correctly we will have to rewrite the drawing of the glyphs > and synchronize the access to the glyph data information. Also, we > want to do it in a way that does not penalize the processing in the UI > process. > > I have only patched the code that is used by the rendering of morphic, > other renderings like Athens or any other user using FT should be > correctly rewritten. > > Once we are sure that synchronizing the access to FT fixes the > problem, we will do a real fix not a dirty hack like this. > > I will be testing this new Image to see if there is an improvement. > > I will really love you try to use this image and tell me if you still > find the problem. > > There is a PR generating a Pharo8 image (it is called wrong, but... it > is a Pharo8) > > 32 bits > ===== > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > > 64 bits > ===== > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > > If somebody is willing to use it in Pharo 7, I can create a PR against > Pharo7 to generate patched P7 images. > > Thanks! > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com> >

April 10, 2019

Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)

by tesonep＠gmail.com

Ohhh, my fault, it is trying to look up for the commit of the merge. That will never work... Because the commit is only in the CI. On Wed, Apr 10, 2019 at 4:16 PM ducasse <stepharo(a)netcourrier.com> wrote: > > Pablo I tried the file you sent and I imported it in the PharoLauncher and I could not handle file. > I got a File class bad argument and after I could not use iceberg. > > Stef > > > On 10 Apr 2019, at 15:38, tesonep(a)gmail.com wrote: > > > > Hello, > > > > After checking the problem with Guille, we have the hypothesis of the > > source of the problem. > > We have seen that accessing Free Type is not thread-safe. > > Basically, the FTFace holds a structure that is filled up with the > > glyph and its information. As this structure is part of the Font Face > > (a font face is a font plus size and attributes), only one request to > > a glyph can be executed at the time. As we are sharing the same font > > in many places, you will be starting to see the problem. > > > > Also, we have seen that there many accesses to the glyphs outside the > > UI process. > > This problem started to appear as we starting to use Calypso (but it > > is not limited to it), as Calypso uses lazy tabs. The creation of > > these tabs is done outside the UI process. > > > > This is only a hack to test our hypothesis. > > To fix it correctly we will have to rewrite the drawing of the glyphs > > and synchronize the access to the glyph data information. Also, we > > want to do it in a way that does not penalize the processing in the UI > > process. > > > > I have only patched the code that is used by the rendering of morphic, > > other renderings like Athens or any other user using FT should be > > correctly rewritten. > > > > Once we are sure that synchronizing the access to FT fixes the > > problem, we will do a real fix not a dirty hack like this. > > > > I will be testing this new Image to see if there is an improvement. > > > > I will really love you try to use this image and tell me if you still > > find the problem. > > > > There is a PR generating a Pharo8 image (it is called wrong, but... it > > is a Pharo8) > > > > 32 bits > > ===== > > > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > > > 64 bits > > ===== > > > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > > > If somebody is willing to use it in Pharo 7, I can create a PR against > > Pharo7 to generate patched P7 images. > > > > Thanks! > > > > -- > > Pablo Tesone. > > tesonep(a)gmail.com > > > > > -- Pablo Tesone. tesonep(a)gmail.com

April 10, 2019

Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)

by Guillermo Polito

We need a new stable vm... On Wed, Apr 10, 2019 at 4:16 PM ducasse <stepharo(a)netcourrier.com> wrote: > Pablo I tried the file you sent and I imported it in the PharoLauncher and > I could not handle file. > I got a File class bad argument and after I could not use iceberg. > > Stef > > > On 10 Apr 2019, at 15:38, tesonep(a)gmail.com wrote: > > > > Hello, > > > > After checking the problem with Guille, we have the hypothesis of the > > source of the problem. > > We have seen that accessing Free Type is not thread-safe. > > Basically, the FTFace holds a structure that is filled up with the > > glyph and its information. As this structure is part of the Font Face > > (a font face is a font plus size and attributes), only one request to > > a glyph can be executed at the time. As we are sharing the same font > > in many places, you will be starting to see the problem. > > > > Also, we have seen that there many accesses to the glyphs outside the > > UI process. > > This problem started to appear as we starting to use Calypso (but it > > is not limited to it), as Calypso uses lazy tabs. The creation of > > these tabs is done outside the UI process. > > > > This is only a hack to test our hypothesis. > > To fix it correctly we will have to rewrite the drawing of the glyphs > > and synchronize the access to the glyph data information. Also, we > > want to do it in a way that does not penalize the processing in the UI > > process. > > > > I have only patched the code that is used by the rendering of morphic, > > other renderings like Athens or any other user using FT should be > > correctly rewritten. > > > > Once we are sure that synchronizing the access to FT fixes the > > problem, we will do a real fix not a dirty hack like this. > > > > I will be testing this new Image to see if there is an improvement. > > > > I will really love you try to use this image and tell me if you still > > find the problem. > > > > There is a PR generating a Pharo8 image (it is called wrong, but... it > > is a Pharo8) > > > > 32 bits > > ===== > > > > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > > > 64 bits > > ===== > > > > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > > > If somebody is willing to use it in Pharo 7, I can create a PR against > > Pharo7 to generate patched P7 images. > > > > Thanks! > > > > -- > > Pablo Tesone. > > tesonep(a)gmail.com > > > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 10, 2019

Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)

by ducasse

Pablo I tried the file you sent and I imported it in the PharoLauncher and I could not handle file. I got a File class bad argument and after I could not use iceberg. Stef > On 10 Apr 2019, at 15:38, tesonep(a)gmail.com wrote: > > Hello, > > After checking the problem with Guille, we have the hypothesis of the > source of the problem. > We have seen that accessing Free Type is not thread-safe. > Basically, the FTFace holds a structure that is filled up with the > glyph and its information. As this structure is part of the Font Face > (a font face is a font plus size and attributes), only one request to > a glyph can be executed at the time. As we are sharing the same font > in many places, you will be starting to see the problem. > > Also, we have seen that there many accesses to the glyphs outside the > UI process. > This problem started to appear as we starting to use Calypso (but it > is not limited to it), as Calypso uses lazy tabs. The creation of > these tabs is done outside the UI process. > > This is only a hack to test our hypothesis. > To fix it correctly we will have to rewrite the drawing of the glyphs > and synchronize the access to the glyph data information. Also, we > want to do it in a way that does not penalize the processing in the UI > process. > > I have only patched the code that is used by the rendering of morphic, > other renderings like Athens or any other user using FT should be > correctly rewritten. > > Once we are sure that synchronizing the access to FT fixes the > problem, we will do a real fix not a dirty hack like this. > > I will be testing this new Image to see if there is an improvement. > > I will really love you try to use this image and tell me if you still > find the problem. > > There is a PR generating a Pharo8 image (it is called wrong, but... it > is a Pharo8) > > 32 bits > ===== > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > 64 bits > ===== > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > If somebody is willing to use it in Pharo 7, I can create a PR against > Pharo7 to generate patched P7 images. > > Thanks! > > -- > Pablo Tesone. > tesonep(a)gmail.com >

April 10, 2019

Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)

by ducasse

Thank you P and G. It is so annoying. Stef > On 10 Apr 2019, at 15:38, tesonep(a)gmail.com wrote: > > Hello, > > After checking the problem with Guille, we have the hypothesis of the > source of the problem. > We have seen that accessing Free Type is not thread-safe. > Basically, the FTFace holds a structure that is filled up with the > glyph and its information. As this structure is part of the Font Face > (a font face is a font plus size and attributes), only one request to > a glyph can be executed at the time. As we are sharing the same font > in many places, you will be starting to see the problem. > > Also, we have seen that there many accesses to the glyphs outside the > UI process. > This problem started to appear as we starting to use Calypso (but it > is not limited to it), as Calypso uses lazy tabs. The creation of > these tabs is done outside the UI process. > > This is only a hack to test our hypothesis. > To fix it correctly we will have to rewrite the drawing of the glyphs > and synchronize the access to the glyph data information. Also, we > want to do it in a way that does not penalize the processing in the UI > process. > > I have only patched the code that is used by the rendering of morphic, > other renderings like Athens or any other user using FT should be > correctly rewritten. > > Once we are sure that synchronizing the access to FT fixes the > problem, we will do a real fix not a dirty hack like this. > > I will be testing this new Image to see if there is an improvement. > > I will really love you try to use this image and tell me if you still > find the problem. > > There is a PR generating a Pharo8 image (it is called wrong, but... it > is a Pharo8) > > 32 bits > ===== > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > 64 bits > ===== > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > If somebody is willing to use it in Pharo 7, I can create a PR against > Pharo7 to generate patched P7 images. > > Thanks! > > -- > Pablo Tesone. > tesonep(a)gmail.com >

April 10, 2019

Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)

by Nicolas Cellier

Good find! The fac tthat FT_Face is not thread-safe is documented https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html Le mer. 10 avr. 2019 Ã 15:39, tesonep(a)gmail.com <tesonep(a)gmail.com> a Ã©crit : > Hello, > > After checking the problem with Guille, we have the hypothesis of the > source of the problem. > We have seen that accessing Free Type is not thread-safe. > Basically, the FTFace holds a structure that is filled up with the > glyph and its information. As this structure is part of the Font Face > (a font face is a font plus size and attributes), only one request to > a glyph can be executed at the time. As we are sharing the same font > in many places, you will be starting to see the problem. > > Also, we have seen that there many accesses to the glyphs outside the > UI process. > This problem started to appear as we starting to use Calypso (but it > is not limited to it), as Calypso uses lazy tabs. The creation of > these tabs is done outside the UI process. > > This is only a hack to test our hypothesis. > To fix it correctly we will have to rewrite the drawing of the glyphs > and synchronize the access to the glyph data information. Also, we > want to do it in a way that does not penalize the processing in the UI > process. > > I have only patched the code that is used by the rendering of morphic, > other renderings like Athens or any other user using FT should be > correctly rewritten. > > Once we are sure that synchronizing the access to FT fixes the > problem, we will do a real fix not a dirty hack like this. > > I will be testing this new Image to see if there is an improvement. > > I will really love you try to use this image and tell me if you still > find the problem. > > There is a PR generating a Pharo8 image (it is called wrong, but... it > is a Pharo8) > > 32 bits > ===== > > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > 64 bits > ===== > > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > If somebody is willing to use it in Pharo 7, I can create a PR against > Pharo7 to generate patched P7 images. > > Thanks! > > -- > Pablo Tesone. > tesonep(a)gmail.com > >

April 10, 2019

FreeType and the over amorous glyphs (overlapping)

by tesonep＠gmail.com

Hello, After checking the problem with Guille, we have the hypothesis of the source of the problem. We have seen that accessing Free Type is not thread-safe. Basically, the FTFace holds a structure that is filled up with the glyph and its information. As this structure is part of the Font Face (a font face is a font plus size and attributes), only one request to a glyph can be executed at the time. As we are sharing the same font in many places, you will be starting to see the problem. Also, we have seen that there many accesses to the glyphs outside the UI process. This problem started to appear as we starting to use Calypso (but it is not limited to it), as Calypso uses lazy tabs. The creation of these tabs is done outside the UI process. This is only a hack to test our hypothesis. To fix it correctly we will have to rewrite the drawing of the glyphs and synchronize the access to the glyph data information. Also, we want to do it in a way that does not penalize the processing in the UI process. I have only patched the code that is used by the rendering of morphic, other renderings like Athens or any other user using FT should be correctly rewritten. Once we are sure that synchronizing the access to FT fixes the problem, we will do a real fix not a dirty hack like this. I will be testing this new Image to see if there is an improvement. I will really love you try to use this image and tell me if you still find the problem. There is a PR generating a Pharo8 image (it is called wrong, but... it is a Pharo8) 32 bits ===== https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… 64 bits ===== https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… If somebody is willing to use it in Pharo 7, I can create a PR against Pharo7 to generate patched P7 images. Thanks! -- Pablo Tesone. tesonep(a)gmail.com

April 10, 2019

Re: [Pharo-dev] [Pharo-users] [OT] (slightly) What makes other dialects "enjoyable" for you? (WAS: difference between double dispatch...)

by Esteban Maringolo

I love this attitude coming from the very core of the Pharo dev-team, which felt to me as being blind to what other dialects were doing or did in the past, and these is days seems to be catching up quite quickly. Dolphin Smalltalk: Practically all "widgets" (aka "views") are the native ones, and they behave as expected by a Windows user, both in terms of shortcuts, styling, etc. It feels like a Smalltalk built by Microsoft itself. The MVP approach to build GUIs is, in my experience, the best of all available options, and the way the Presenters and Views are factored is great, for what I could see, Spec 2.0 is going in that direction and I like. Some could say this would restrict you from building "different" apps, but IMO that is another layer that must be built on top of the basic building blocks. It doesn't use pragmas (I particularly don't like them much), but there are "hooks" everywhere to add items to tooling menus, etc. The consistency and coherence of the whole system is outstanding, not only in terms of UI, and I think it is the result of two great developers (and I would argue only one in terms of UI), working for over a decade in refining, trimming and polishing every corner of the app while also using it for their own personal and business developments. Dolphin had both a commercial purpose and a utility purpose, the first as a vendor to fulfill developer needs, but the others for them as a business to develop their own applications. So in the end they were profiting from scratching their own itch. So what I would love to have in Pharo from Dolphin? The UX consistency that a workspace context menu is as similar as the one in the browser code or the one in the Debugger (e.g. Why I can't do an "extract method" refactoring within the debugger?). The concept of a SessionManager is great also, you could "deploy" your image to have a session manager that will handle headless command line application, a full blown UI or even be used an out of process COM server. There are many cons, but we're focusing only in what I'd like. I developed with Dolphin for more than +10 years , building business critical application with it. VisualWorks I use it every day and don't miss much from it, except that the UI is snappier than the current in Pharo. There is no lag the interaction with most widgets. Certain things such as breakpoints and bread and butter things "just work". What I would like in Pharo from VW?: Multiple windows, robust tooling and snappier UI. I don't miss the namespacing, because I understand there are better things in the makings for Pharo :) VisualAge/VAST: I have only used it up to v5.5, but the "Interrupt" button it has worked, I never understood how it was implemented, but no matter how tight the recursion loop was, you hit that "stop everything" button, and everything stopped. For those that don't know, the VAST IDE had an external small window that just had a button, that worked as a panic button to halt the execution of the image. Very much like the [Alt]+[.] of Pharo, but, again, it worked magically. What I would like in Pharo from VAST?: THAT BUTTON. :D Smalltalk/X It always feelt alien to me and it is more an "utility" dialect for themselves that they happened to make public. The nicest thing I found is that it had multiple windows where each window has it's own process! This is very much like Chromium/Chrome works, where you can kill a single tab and keep the other tabs working. What I would like: That capability, although I think this would require an overhaul of the current VM. Cuis Smalltalk: It is the most "approachable" of the Squeak spin-offs, it feels like the most "Dolphin like" of the them as in it is the only that can be understood as a whole by a single person and whose tools can be learnt by inference. They recently added LiveTyping and other "live info" capabilities <https://twitter.com/HernanWilkinson/status/1087325709289357312> than, AFAIU, can be easily added to Pharo as well as long as they add a few extensions to the VM. What I would like: LiveTyping and friends. Summarizing: There are many things out there, but even so, I find Pharo the most enjoyable of all existing dialects, and everyday when I come back to it to work on some personal project I notice how far it has gone from most of the above. But sometimes I enjoy it as I enjoy working out or playing golf: I enjoy it but not without effort and some pain from my side, maybe I finish the day saying I need to find an alternative and then the next day I'm there wanting to use it again. :) Regards, Esteban A. Maringolo El miÃ©., 10 abr. 2019 a las 3:26, Esteban Lorenzano (<estebanlm(a)gmail.com>) escribiÃ³: > > Hi, > > Time to time I hear people like Richard saying âDolphin is the dialect most beautiful Smalltalk he usedâ and others praising it in different levels. > As Pharo âarchitectâ (or whatever I am, but at least Iâm sure I have to pay attention to the IDE :P), Iâm interested to know what elements of Dolphin dialect you find âbeautifulâ, âenjoyableâ and productive. > What it is? > > - the MVP? > - integration with Windows? The way this integration is done? (If soâ¦ how is it done?) > â¦ > > I am very interested on knowing this with some detail level. That doesnât mean I will react and do something, but I want to have a better understanding and put it in my radar to take inspiration to enhance the Pharo experience :P

April 10, 2019