- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] New stable VM for Pharo8?

by Guillermo Polito

Just bumping, I've marked with Pablo the VM a838346b1a67712cc28298534dafbd0c26ea34fb <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a838346b1a67712cc2…> as stable for Pharo8. This should fix the directory issues and the primitive ones. For those using the Pharo launcher: - if you use 64 bits, use the VM manager to update your VMs (remove the old 80 VM) [image: image.png] [image: image.png] - If you re using 32 bits, you'll have to wait a bit more. I've found an issue in the middle, fix in progress here (with a test, yay!) https://github.com/pharo-project/pharo/pull/3169 Guille and Pablo On Tue, Apr 2, 2019 at 8:53 PM ducasse <stepharo(a)netcourrier.com> wrote: > Which reminds me > https://www.amazon.com/Scientific-Progress-Goes-Boink-Collection/dp/0836218… > > is about calvin creating a machine to create clones so that they clean his > room. > And after the clones are getting as lazy as him and they fight and the > machine explodes :) > > -- 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 11, 2019

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

by Norbert Hartl

> Am 11.04.2019 um 15:29 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi Esteban, > > We talk this privately a couple of weeks ago, but I thought it was worth writing again here. As for other IDE's being enjoyable, I can only talk about VASmalltalk. If there is ONE thing I enjoy from it, is the stability. May be ugly, may be too-windows, may be full of menus you don't understand what they do, but it's really rock solid. > Pharo has been doing a LOT of progress on so many areas and its expected to decrease a bit on stability. Unless you are Oracle and can hire 100 engineers. > So, my small recommendation to you back then was to make at least ONE release (called LTS or whatever) were you just focus on stability and bugs. No new features. No new framework. Just stability. Make it rock solid. Then after that release, you can keep moving forward, but that would give companies and really really stable Pharo to rely on. > For the provision of an LTS version we need more engineers. If there are enough companies that need a rock solid stable version then the consortium will have enough money to hire engineers for that. I would put a virtual machine that we can control much higher on the list of things we should have. Norbert > Best, > > -- > Mariano Martinez Peck > Email: marianopeck(a)gmail.com > Twitter: @MartinezPeck > LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/

April 11, 2019

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

by Mariano Martinez Peck

Hi Esteban, We talk this privately a couple of weeks ago, but I thought it was worth writing again here. As for other IDE's being enjoyable, I can only talk about VASmalltalk. If there is ONE thing I enjoy from it, is the stability. May be ugly, may be too-windows, may be full of menus you don't understand what they do, but it's really rock solid. Pharo has been doing a LOT of progress on so many areas and its expected to decrease a bit on stability. Unless you are Oracle and can hire 100 engineers. So, my small recommendation to you back then was to make at least ONE release (called LTS or whatever) were you just focus on stability and bugs. No new features. No new framework. Just stability. Make it rock solid. Then after that release, you can keep moving forward, but that would give companies and really really stable Pharo to rely on. Best, -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/

April 11, 2019

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

by tesonep＠gmail.com

I am not shy, the mail of Guille is perfect, I cannot do it! Thanks a lot for all the explanations! On Thu, Apr 11, 2019 at 3:25 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > So, this morning we have been working on validating this hypothesis and > making a meaningful and reproducible test for it. > I'm just the messenger here because Pablo who has done most of the job is > shy. > > ## The main story > > Since we are working with concurrency and non-determinism, we have > designed a test that reproduces the case with an accuracy of ~94%. > Basically the test renders a Rubric morph in concurrent green threads on a > big string, and then we compare that the drawn morphs should be bit > identical. > We have made some measurements and observed that putting three concurrent > processes made the chance of hitting the bug to almost 94%. > So running it more than ~5 times makes it highly reproducible. > > Good thing: this test inside a loop of 10 iterations (to increase the > probability of hitting the bug to >~99%) detects the bug in the stock image > and not in the one with our patch. > Bad thing: this test relies on rubric, we have tried to simplify it (like > just doing a collect on the string to fetch the glyph for each character), > but simpler code produces a tighter loop which makes it far less > reproducible (down from 94 to 33%). > > Still, there are several questions open: > - can we simplify the test? :) > - we have to think about a smart way to serialize Freetype access in the > image (there are several users) > - I'll paste below our math, so if somebody would like to review it would > be good too, our probability is a bit rusty. > - we have been doing benchmarks with Pablo this morning and adding a > mutex does not seem to have any negative impact in rendering. > > Help is super welcome of course!! > The patch that Pablo has done in the PR will just work for the most common > cases (at least for the calypso tabs), but it shows that FT* needs some > love. > Still we would like to be able to backport something like this in Pharo7, > but backporting a big Freetype refactor would not be so good. > Maybe the mutex is a good enough change for Pharo7? > > Any more ideas? input? > > Cheers, > Guille and Pablo > > ## The code > > The code of the test is the following: > > ``` > | sem text canvases blocky | > sem := Semaphore new. > text := (String loremIpsum: 25*1024). > FreeTypeCache current removeAll. > canvases := OrderedCollection new. > > blocky := [ | canvas | > canvas := FormCanvas extent: 1000@1000. > canvases add: canvas. > (RubScrolledTextMorph new) > setText: text; > font: StandardFonts codeFont; > bounds: (0@0 corner: canvas form extent); > fullDrawOn: canvas. > sem signal ]. > blocky forkAt: 39. > blocky forkAt: 39. > blocky forkAt: 39. > sem > wait; > wait; > wait. > > self assert: (((canvases at:1) form bits = (canvases at:2) form bits) and: > [ ((canvases at:2) form bits = (canvases at:3) form bits) ]) > ``` > > ## The math > p := 0.94 asScaledDecimal. > > hittingTheBug := 0. > notHittingTheBug := 1 - hittingTheBug. > 5 timesRepeat: [ > hittingTheBug := hittingTheBug + (notHittingTheBug * p). > notHittingTheBug := 1 - hittingTheBug ]. > hittingTheBug. "after 5 iterations" > "0.99999969s8" > > On Wed, Apr 10, 2019 at 8:04 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> 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 >> > >> >> >> > > -- > > > > 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 > -- Pablo Tesone. tesonep(a)gmail.com

April 11, 2019

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

by Guillermo Polito

So, this morning we have been working on validating this hypothesis and making a meaningful and reproducible test for it. I'm just the messenger here because Pablo who has done most of the job is shy. ## The main story Since we are working with concurrency and non-determinism, we have designed a test that reproduces the case with an accuracy of ~94%. Basically the test renders a Rubric morph in concurrent green threads on a big string, and then we compare that the drawn morphs should be bit identical. We have made some measurements and observed that putting three concurrent processes made the chance of hitting the bug to almost 94%. So running it more than ~5 times makes it highly reproducible. Good thing: this test inside a loop of 10 iterations (to increase the probability of hitting the bug to >~99%) detects the bug in the stock image and not in the one with our patch. Bad thing: this test relies on rubric, we have tried to simplify it (like just doing a collect on the string to fetch the glyph for each character), but simpler code produces a tighter loop which makes it far less reproducible (down from 94 to 33%). Still, there are several questions open: - can we simplify the test? :) - we have to think about a smart way to serialize Freetype access in the image (there are several users) - I'll paste below our math, so if somebody would like to review it would be good too, our probability is a bit rusty. - we have been doing benchmarks with Pablo this morning and adding a mutex does not seem to have any negative impact in rendering. Help is super welcome of course!! The patch that Pablo has done in the PR will just work for the most common cases (at least for the calypso tabs), but it shows that FT* needs some love. Still we would like to be able to backport something like this in Pharo7, but backporting a big Freetype refactor would not be so good. Maybe the mutex is a good enough change for Pharo7? Any more ideas? input? Cheers, Guille and Pablo ## The code The code of the test is the following: ``` | sem text canvases blocky | sem := Semaphore new. text := (String loremIpsum: 25*1024). FreeTypeCache current removeAll. canvases := OrderedCollection new. blocky := [ | canvas | canvas := FormCanvas extent: 1000@1000. canvases add: canvas. (RubScrolledTextMorph new) setText: text; font: StandardFonts codeFont; bounds: (0@0 corner: canvas form extent); fullDrawOn: canvas. sem signal ]. blocky forkAt: 39. blocky forkAt: 39. blocky forkAt: 39. sem wait; wait; wait. self assert: (((canvases at:1) form bits = (canvases at:2) form bits) and: [ ((canvases at:2) form bits = (canvases at:3) form bits) ]) ``` ## The math p := 0.94 asScaledDecimal. hittingTheBug := 0. notHittingTheBug := 1 - hittingTheBug. 5 timesRepeat: [ hittingTheBug := hittingTheBug + (notHittingTheBug * p). notHittingTheBug := 1 - hittingTheBug ]. hittingTheBug. "after 5 iterations" "0.99999969s8" On Wed, Apr 10, 2019 at 8:04 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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 > > > > > -- 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 11, 2019

Re: [Pharo-dev] About <primitive: 'primitiveCompareString' module: 'MiscPrimitivePlugin'>

by Sophie Kaleba

HI, We actually talked about this very primitive with Cyril not that long ago. I'll have a look at it with him this week so it can be used ! Sophie Le mer. 10 avr. 2019 Ã 14:10, ducasse <stepharo(a)netcourrier.com> a Ã©crit : > Thanks I did not know it was on a mailing-list. > > > On 10 Apr 2019, at 14:02, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Hi Stephane, > If you google 'vm-dev VMMaker.oscog-sk.2367' > and click one of the first hits > https://marc.info/?l=squeak-vm-dev&m=152413936110744&w=2 > > you'll see the changes from Sophie: > The new InterpreterPrimitives>>primitiveCompareWith should be linked to > primitive 158. > (and only for ByteString comparison). > > I did not try it, I have not much time to invest at the moment. > > Le mer. 10 avr. 2019 Ã 13:52, ducasse <stepharo(a)netcourrier.com> a Ã©crit : > >> Nicolas >> >> I tried to find the new primitive and I did not find it here >> >> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/Misc… >> >> I found the old one. >> Did I look in the wrong place? >> >> Stef >> >> On 10 Apr 2019, at 13:46, ducasse <stepharo(a)netcourrier.com> wrote: >> >> Thanks nicolas so we can use them then. >> >> On 10 Apr 2019, at 11:59, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> VMMaker.oscog-sk.2367 >> Author: sk >> Time: 19 April 2018, 12:02:35.661622 pm >> UUID: 0c2401e3-1450-4f73-8e81-958f50171595 >> Ancestors: VMMaker.oscog- nice.2366 >> >> ** new primitive to compare strings (slang + JIT) >> answers negative smi, 0 or positive smi (instead of 1, 2 or 3 in the >> MiscPlugin) >> >> * Slang (primitiveCompareWith) >> order is optionnal. >> comparison loop performed in rawCompare: string1 length: strLength1 with: >> string2 length: strLength2 accessBlock: accessBlock >> >> * JIT (genPrimitiveStringCompareWith) >> the JIT primitive does not take order as parameter (assumed asciiOrder) >> quick jump if one of the strings is empty >> >> Le mer. 10 avr. 2019 Ã 11:56, ducasse <stepharo(a)netcourrier.com> a >> Ã©crit : >> >>> >>> >>> On 10 Apr 2019, at 11:42, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> >>> wrote: >>> >>> On Wed, Apr 10, 2019 at 10:42 AM StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>> >>> >>> Hi >>> >>> I recall that clement told me that returning 1,2 or 3 instead of >>> negative, zero, positive was slow. >>> And I wonder if the primitive got change to the logic clement proposed? >>> >>> Could we not introduce another primitive and use it from the image? >>> >>> >>> Hi, >>> >>> I think Sophie already did most of the work to introduce a new >>> primitive. The missing steps to use the new optimized way to compare >>> strings are: >>> - Add the primitive to the primitive table VM side for Pharo/Squeak and >>> Newspeak >>> >>> >>> If you know that it is done from the VM side let us know. >>> >>> - Use the new primitive in the image and call this one for string >>> comparison >>> >>> With this new primitive performances on string comparison can be >>> improved around x2.5 to x5 times faster. >>> >>> >>> compare: string1 with: string2 collated: order >>> "Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating >>> order of characters given by the order array." >>> >>> | len1 len2 c1 c2 | >>> <primitive: 'primitiveCompareString' module: 'MiscPrimitivePlugin'> >>> <var: #string1 declareC: 'unsigned char *string1'> >>> <var: #string2 declareC: 'unsigned char *string2'> >>> <var: #order declareC: 'unsigned char *order'> >>> >>> len1 := string1 size. >>> len2 := string2 size. >>> 1 to: (len1 min: len2) do: >>> [:i | >>> c1 := order at: (string1 basicAt: i) + 1. >>> c2 := order at: (string2 basicAt: i) + 1. >>> c1 = c2 ifFalse: >>> [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]]. >>> len1 = len2 ifTrue: [^ 2]. >>> len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3]. >>> >>> -------------------------------------------- >>> StÃ©phane Ducasse >>> http://stephane.ducasse.free.fr >>> http://www.synectique.eu / http://www.pharo.org >>> 03 59 35 87 52 >>> Assistant: Julie Jonas >>> FAX 03 59 57 78 50 >>> TEL 03 59 35 86 16 >>> S. Ducasse - Inria >>> 40, avenue Halley, >>> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >>> Villeneuve d'Ascq 59650 >>> France >>> >>> >>> >>> -- >>> Cyril Ferlicot >>> https://ferlicot.fr >>> >>> >>> >> >> >

April 11, 2019

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

by StÃ©phane Ducasse

> On 10 Apr 2019, at 15:19, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > 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. this was never the case. Now we could also spend our time in python and you will see how the smalltalk world would feel. Some time you need to be concentrated. > > 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 > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

April 10, 2019

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