October 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Measuring width string

by Peter UhnÃ¡k

Note that you shouldn't use 2) or 3) for non-monospace fonts because of kerning. font := StandardFonts defaultFont. font widthOfString: 'eT'. "16" font widthOfString: 'Te'. "15" 'eT' inject: 0 into: [ :width :c | width + (font getGlyphWidth: c) ]. "13.416015625" 'Te' inject: 0 into: [ :width :c | width + (font getGlyphWidth: c) ]. "13.416015625" 4) seems fine font := StandardFonts defaultFont. provider := CairoScaledFont fromFreetypeFont: font realFont. width := [ :string | converter := CairoUTF8Converter new. converter convert: string from: 1 to: string size. stringExtents := CairoTextExtents new. provider getExtentsOf: converter buffer into: stringExtents. stringExtents width ]. width value: 'eT'. "12.463638305664063" width value: 'Te'. "12.561752319335938" On Tue, Oct 27, 2015 at 12:27 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi Alex, > > This is indeed a very useful information. You can also put it on > StackOverflow, then it will be Googlable. > > Cheers. > Uko > > > > On 27 Oct 2015, at 12:02, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hi > > I'm sending it here so that it doesn't get lost. > > > There are multiple ways to measure string width. In the following examples > performance will be tested measuring 10`000 times the width of the > following string: > > *string := 'abcdefghijklmnopqrstuvwxyz 0123456789!@#$%^&*()_+'.* > > 1) The most straightforward way is to send #widthOfString: to the font. > Time to run gives around 250ms. > http://ws.stfx.eu/2Q5YA9DFTRDR > Resulting value is rounded to integer and seems to be not absolutely > correct and precise. > > 2) More complex way is to go deeper on the level of glyphs and manually > summarise the width of each character in the string sending > #getGlyphWidth: character to the font. Time to run gives around 750ms. > http://ws.stfx.eu/ETBEW1EHAAZ8 > Resulting value is float and looks like correct and precise value. > > 3) Even more complex is to use CairoFontMetricsProvider instead of font's > methods. The same as in 2nd case we measure each character. Time to run > around 350ms. > http://ws.stfx.eu/7I89DMD0ZLM3 > Resulting value is exactly the same as in the 2nd case. With almost equal > performance to 1st it is nice alternative. > > 4) One more way is to let native cairo to calculate everything for us. > Calls happen through nativeboost. Time to run around 120ms. > http://ws.stfx.eu/HYD76OMIOM7L <http://ws.stfx.eu/HYD76OMIOM7L> > As result it returns *CairoTextExtents* which allows to calculate width > and height with one call. > > Cheers, > Alex > > >

Oct. 27, 2015

Re: [Pharo-dev] Loading a baseline locally

by Gabriel Cotelli

Maybe something like: Metacello new baseline: 'QualityAssistant'; repository: 'filetree://REPO_LOCATION_IN_DISK'; load On Tue, Oct 27, 2015 at 7:25 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > I inspect `BeselineOfQualityAssistant project` then in versions > presentation I select the one and only baseline version and send `load` to > it. > > On 27 Oct 2015, at 10:52, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > Can you list the command you are using as Metacello code? > > I tried a few fancy things at one point with multiple repositories and > baselines, and Metacello gave me that power, but not in the way I expected > (at all). > > Thierry > > 2015-10-27 9:54 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > >> Hi, >> >> is it possible to load the baseline that is in a local repo? Because when >> I try to do that, I get: Could not resolve: <pakagename>â¦ >> >> I need to test how the configuration works and it looks like a cannot do >> that if I have not committed it. >> >> Uko >> > > >

Oct. 27, 2015

Re: [Pharo-dev] Measuring width string

by Yuriy Tymchuk

Hi Alex, This is indeed a very useful information. You can also put it on StackOverflow, then it will be Googlable. Cheers. Uko > On 27 Oct 2015, at 12:02, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hi > > I'm sending it here so that it doesn't get lost. > > There are multiple ways to measure string width. In the following examples performance will be tested measuring 10`000 times the width of the following string: > > string := 'abcdefghijklmnopqrstuvwxyz 0123456789!@#$%^&*()_+'. > > 1) The most straightforward way is to send #widthOfString: to the font. Time to run gives around 250ms. > http://ws.stfx.eu/2Q5YA9DFTRDR <http://ws.stfx.eu/2Q5YA9DFTRDR> > Resulting value is rounded to integer and seems to be not absolutely correct and precise. > > 2) More complex way is to go deeper on the level of glyphs and manually summarise the width of each character in the string sending #getGlyphWidth: character to the font. Time to run gives around 750ms. > http://ws.stfx.eu/ETBEW1EHAAZ8 <http://ws.stfx.eu/ETBEW1EHAAZ8> > Resulting value is float and looks like correct and precise value. > > 3) Even more complex is to use CairoFontMetricsProvider instead of font's methods. The same as in 2nd case we measure each character. Time to run around 350ms. > http://ws.stfx.eu/7I89DMD0ZLM3 <http://ws.stfx.eu/7I89DMD0ZLM3> > Resulting value is exactly the same as in the 2nd case. With almost equal performance to 1st it is nice alternative. > > 4) One more way is to let native cairo to calculate everything for us. Calls happen through nativeboost. Time to run around 120ms. > http://ws.stfx.eu/HYD76OMIOM7LÂ <http://ws.stfx.eu/HYD76OMIOM7L> > As result it returns CairoTextExtents which allows to calculate width and height with one call. > > Cheers, > Alex

Oct. 27, 2015

Measuring width string

by Aliaksei Syrel

Hi I'm sending it here so that it doesn't get lost. There are multiple ways to measure string width. In the following examples performance will be tested measuring 10`000 times the width of the following string: *string := 'abcdefghijklmnopqrstuvwxyz 0123456789!@#$%^&*()_+'.* 1) The most straightforward way is to send #widthOfString: to the font. Time to run gives around 250ms. http://ws.stfx.eu/2Q5YA9DFTRDR Resulting value is rounded to integer and seems to be not absolutely correct and precise. 2) More complex way is to go deeper on the level of glyphs and manually summarise the width of each character in the string sending #getGlyphWidth: character to the font. Time to run gives around 750ms. http://ws.stfx.eu/ETBEW1EHAAZ8 Resulting value is float and looks like correct and precise value. 3) Even more complex is to use CairoFontMetricsProvider instead of font's methods. The same as in 2nd case we measure each character. Time to run around 350ms. http://ws.stfx.eu/7I89DMD0ZLM3 Resulting value is exactly the same as in the 2nd case. With almost equal performance to 1st it is nice alternative. 4) One more way is to let native cairo to calculate everything for us. Calls happen through nativeboost. Time to run around 120ms. http://ws.stfx.eu/HYD76OMIOM7L <http://ws.stfx.eu/HYD76OMIOM7L> As result it returns *CairoTextExtents* which allows to calculate width and height with one call. Cheers, Alex

Oct. 27, 2015

Re: [Pharo-dev] Loading a baseline locally

by Yuriy Tymchuk

I inspect `BeselineOfQualityAssistant project` then in versions presentation I select the one and only baseline version and send `load` to it. > On 27 Oct 2015, at 10:52, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Can you list the command you are using as Metacello code? > > I tried a few fancy things at one point with multiple repositories and baselines, and Metacello gave me that power, but not in the way I expected (at all). > > Thierry > > 2015-10-27 9:54 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > Hi, > > is it possible to load the baseline that is in a local repo? Because when I try to do that, I get: Could not resolve: <pakagename>â¦ > > I need to test how the configuration works and it looks like a cannot do that if I have not committed it. > > Uko >

Oct. 27, 2015

Re: [Pharo-dev] Loading a baseline locally

by Thierry Goubier

Can you list the command you are using as Metacello code? I tried a few fancy things at one point with multiple repositories and baselines, and Metacello gave me that power, but not in the way I expected (at all). Thierry 2015-10-27 9:54 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi, > > is it possible to load the baseline that is in a local repo? Because when > I try to do that, I get: Could not resolve: <pakagename>â¦ > > I need to test how the configuration works and it looks like a cannot do > that if I have not committed it. > > Uko >

Oct. 27, 2015

Loading a baseline locally

by Yuriy Tymchuk

Hi, is it possible to load the baseline that is in a local repo? Because when I try to do that, I get: Could not resolve: <pakagename>â¦ I need to test how the configuration works and it looks like a cannot do that if I have not committed it. Uko

Oct. 27, 2015

Re: [Pharo-dev] Finding the reason of merge

by Yuriy Tymchuk

I think that I finally got it. Here is the scenario Project A depends on project B. A 1.0 depends on B 1.0 A 2.0 depends on B 2.0 A 1.0 provides extensions to a class which is present in B 1.0 but removed in B 2.0. If A 1.0 is present in the image, and A 2.0 is loaded, packages from B 2.0 are loaded before the ones of A 2.0. To the class getâs removed, and the extension methods that disappeared with its removal are considered as local changes. This means that there is no way to do a clean update via catalog browser? Uko > On 27 Oct 2015, at 07:23, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 27/10/2015 03:40, Chris Cunningham a Ã©crit : >> you could try Merging instead of loading, and then look at the >> difference between the newly merged in-image package and version 74. >> >> Or, you could open the Monticello browser, highlight the package (which >> you've already done),and click on Changes to see what you've changed >> since version 73. >> >> Or, maybe gitfiletree has so changed Monticello behaviour that neither >> of these work anymore? > > In that, GitFileTree has not changed Monticello behavior, so those operations should work. > > Thierry > >> In any case, if you try to load over your changes, it doesn't give you >> any hint as to what it is loading over. >> >> -cbc >> >> On Mon, Oct 26, 2015 at 6:14 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >> <mailto:yuriy.tymchuk@me.com>> wrote: >> >> Ok, Iâm completely exhausted, I have no clue whatâs the problem. >> >> I have version 73 of my package, I load version 74 an then it says: >> âIf you continue, you will loose these changes: â and there is >> nothing more, there are no changes that Iâm going to loose. Is there >> any way to identify why the merge is happening. Yes, maybe it is >> because I am using gitfiletree, but how do I find out the reason of >> merge? Monticello is an amazing tool because it keeps my hands tied, >> as I cannot really debug why there is a merge (itâs too complex at >> least for me). >> >> Uko >> >> > >

Oct. 27, 2015

[pharo-project/pharo-core] 433393: 50407

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 43339304094c660e251b06951a1e18b00b310103 https://github.com/pharo-project/pharo-core/commit/43339304094c660e251b0695… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-27 (Tue, 27 Oct 2015) Changed paths: M Morphic-Core.package/HandMorph.class/instance/caching/releaseCachedState.st M Morphic-Core.package/HandMorph.class/instance/focus handling/keyboardFocus_.st M Morphic-Core.package/HandMorph.class/instance/focus handling/newKeyboardFocus_.st R Morphic-Core.package/HandMorph.class/instance/focus handling/releaseAllFoci.st A Morphic-Core.package/HandMorph.class/instance/focus handling/releaseAllFocus.st M Morphic-Core.package/HandMorph.class/instance/initialization/interrupted.st M Refactoring-Critics.package/RBRefersToClassRule.class/instance/running/basicCheck_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50406.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50407.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50406.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50407.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50407 16874 RBRefersToClassRule should handle classes that are not in method dict https://pharo.fogbugz.com/f/cases/16874 16856 Any KeyboardFocus change in the HandMorph should be announced https://pharo.fogbugz.com/f/cases/16856 http://files.pharo.org/image/50/50407.zip

Oct. 27, 2015

[pharo-project/pharo-core]

by GitHub

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

Oct. 27, 2015