Re: Musings on the font-encoding property

Le lundi 03 avril 2023 à 01:30 +0200, Jean Abou Samra a écrit : > Le mercredi 29 mars 2023 à 15:56 +0200, Jean Abou Samra a écrit : > > The practical impact of the change is mostly a syntax modification that is > > not easy to convert-ly (the removal of \text, which should be replaced with > > \r

Re: Musings on the font-encoding property

Le mercredi 29 mars 2023 à 15:56 +0200, Jean Abou Samra a écrit : > The practical impact of the change is mostly a syntax modification that is > not easy to convert-ly (the removal of `\text`, which should be replaced with > `\roman`, `\sans` or `\typewriter` depending on the case). I missed th

Re: Musings on the font-encoding property

Le mercredi 29 mars 2023 à 17:05 +0200, David Kastrup a écrit : > A default conversion of \text to \roman would likely match more than 90% > of the current uses. Yes, agreed. We could make convert-ly change \text to \roman, and emit a warning that this might be wrong in a few cases. signature

Re: Musings on the font-encoding property

Werner LEMBERG writes: >> >>>  AFAICS, the only limitation is that an ordinary text font with a >>> family name 'music' cannot be used. >> >> No :-) unlike what its name suggests, the `font-family` property is >> a family symbol, not a font string (yes, it's another misnamed thing >> in font h

Re: Musings on the font-encoding property

> >>  AFAICS, the only limitation is that an ordinary text font with a >> family name 'music' cannot be used. > > No :-) unlike what its name suggests, the `font-family` property is > a family symbol, not a font string (yes, it's another misnamed thing > in font handling). The `font-family` valu

Re: Musings on the font-encoding property

Le mercredi 29 mars 2023 à 13:46 +, Werner LEMBERG a écrit : >  AFAICS, the only limitation is that an > ordinary text font with a family name 'music' cannot be used. No :-) unlike what its name suggests, the `font-family` property is a family symbol, not a font string (yes, it's another mi

Re: Musings on the font-encoding property

> 1. Look up `font-family`. If it's `music`, then use the music font, >otherwise use a text font as appropriate for the `font-family`. I'm all for your changes. AFAICS, the only limitation is that an ordinary text font with a family name 'music' cannot be used. I think we can live with tha

Musings on the font-encoding property

Hi, Warning: start by taking a cup of coffee, this is all a bit headache-giving. Sorry for the long post. Currently, the algorithm to select a font for normal markup (i.e., I'm not talking about music glyphs here) is roughly this: 1. Check the `font-encoding` property. If it's `feta

Re: GSoC 2020: Shape-note notehead encoding

On 24/07/2020 01:17, Aaron Hill wrote: On 2020-07-23 4:28 pm, Owen Lamb wrote: (It starts to get confusing to keep track of diagonal directions after a while, so for the sake of clarity, I'll be talking about diamonds with thick NE and SW sides as Calimaine, and those with thick NW and SE sid

Re: GSoC 2020: Shape-note notehead encoding

On Thu, Jul 23, 2020 at 9:00 PM Karlin High wrote: > The four-shape communities... I gather these folks would be more likely to > care If anyone wants more input on these questions, maybe a post on lilypond-user would be in order? There have been people from the four-shapes scene active there in

Re: GSoC 2020: Shape-note notehead encoding

On Thu, Jul 23, 2020 at 6:29 PM Owen Lamb wrote: > Aha! Apparently all the old issue conversations have been migrated to GitLab. The links and attachments work fine here: https://gitlab.com/lilypond/lilypond/-/issues/1060 Brilliant! I had clean missed how that's worked out. > This book being the

Re: GSoC 2020: Shape-note notehead encoding

Hmm... Washida is already a Japanese surname, which might cause confusion. If you'd really like to dissociate your area from Florida, all I can offer is going further northwest: Alaskida or Floraska. But then to be consistent we'd have to take Hawaii into account, and it doesn't play well with such

Re: GSoC 2020: Shape-note notehead encoding

On 2020-07-23 4:28 pm, Owen Lamb wrote: (It starts to get confusing to keep track of diagonal directions after a while, so for the sake of clarity, I'll be talking about diamonds with thick NE and SW sides as Calimaine, and those with thick NW and SE sides as Florington, after the states roughl

Re: GSoC 2020: Shape-note notehead encoding

Aha! Apparently all the old issue conversations have been migrated to GitLab. The links and attachments work fine here: https://gitlab.com/lilypond/lilypond/-/issues/1060 (It starts to get confusing to keep track of diagonal directions after a while, so for the sake of clarity, I'll be talking abo

Re: GSoC 2020: Shape-note notehead encoding

On Wed, Jul 22, 2020 at 4:31 PM Owen Lamb wrote: > Firstly, none of the corpora (aha!) you provided or ones I found myself > seemed to present both mirrored versions of mi in the same document, as > Massive Lion claimed on the original Google Code archive should be the case > depending on stem dir

Re: GSoC 2020: Shape-note notehead encoding

Wow! Thanks for all the sources--and the enlightening Latin discussion! I was able to find examples of the missing Funk and Walker do, re, and ti heads, so that's the most pressing issue done with. I'll begin writing the proposal for those ones, but I'll hold out sending it before we get the other

Re: GSoC 2020: Shape-note notehead encoding

Jean Abou Samra writes: > Le 22/07/2020 à 03:32, Aaron Hill a écrit : > >> On 2020-07-21 5:39 pm, Owen Lamb wrote: >>> corpuses (corpori?) >> >> Off-topic: "corpora" is the plural in English.  Though while >> "corpuses" is not technically correct, I would have no problem >> understanding it. > >

Re: GSoC 2020: Shape-note notehead encoding

Le 22/07/2020 à 03:32, Aaron Hill a écrit : On 2020-07-21 5:39 pm, Owen Lamb wrote: corpuses (corpori?) Off-topic: "corpora" is the plural in English.  Though while "corpuses" is not technically correct, I would have no problem understanding it. Yes, Latin would prescribe corpora as the p

Re: GSoC 2020: Shape-note notehead encoding

On 7/22/2020 12:09 PM, Carl Sorensen wrote: We have it in our university library.  Would you like me to get it and make some page scans? I expect there are editions of that one with both shaped and unshaped notes. If it's shaped notes, and it's not too much bother, and it's felt to be helpful

Re: GSoC 2020: Shape-note notehead encoding

On Wed, Jul 22, 2020 at 11:00 AM Karlin High wrote: > On 7/22/2020 11:15 AM, Carl Sorensen wrote: > > But to my eye, the Mennonite Hymnal from 1969 has the best aesthetics of > > all the scans you shared. > > Much of the shape-note tradition is aimed at amateurs. It's trying to > get a strong com

Re: GSoC 2020: Shape-note notehead encoding

On 7/22/2020 11:15 AM, Carl Sorensen wrote: But to my eye, the Mennonite Hymnal from 1969 has the best aesthetics of all the scans you shared. Much of the shape-note tradition is aimed at amateurs. It's trying to get a strong community-wide music tradition from minimal educational resources.

Re: GSoC 2020: Shape-note notehead encoding

On Wed, Jul 22, 2020 at 9:54 AM Karlin High wrote: > On Tue, Jul 21, 2020 at 7:40 PM Owen Lamb wrote: > > Are there any corpuses (corpori?) of shape-note repertoire that I can > > cite for my proposal (perhaps what was once used to determine our own > > set)? > > (Re-sending to list without 4

Re: GSoC 2020: Shape-note notehead encoding

On Tue, Jul 21, 2020 at 7:40 PM Owen Lamb wrote: > Are there any corpuses (corpori?) of shape-note repertoire that I can > cite for my proposal (perhaps what was once used to determine our own > set)? (Re-sending to list without 4 PDF attachments, ~2 MB. Instead, a Google Drive link is given

Re: GSoC 2020: Shape-note notehead encoding

Werner LEMBERG writes: >> Heartland Hymns, 2005 (PDF attached. Yes, Fraktur in 2005. The >> German-speaking Mennonite communities were in the USA since 1710 or >> so and didn't get the memo that Antiqua has won. The remaining >> German speakers are stuck HARD on Fraktur.) >>

Re: GSoC 2020: Shape-note notehead encoding

> Heartland Hymns, 2005 (PDF attached. Yes, Fraktur in 2005. The > German-speaking Mennonite communities were in the USA since 1710 or > so and didn't get the memo that Antiqua has won. The remaining > German speakers are stuck HARD on Fraktur.) > And they d

Re: GSoC 2020: Shape-note notehead encoding

On Tue, Jul 21, 2020 at 6:40 PM Owen Lamb wrote: > > > Are there any corpuses (corpori?) of shape-note repertoire that I can cite > for my proposal (perhaps what was once used to determine our own set)? > The originals were developed in consultation with the shape note community. You can see a

Re: GSoC 2020: Shape-note notehead encoding

On 2020-07-21 5:39 pm, Owen Lamb wrote: SMuFL needs to define the following: - Whole noteheads separately from half noteheads (SMuFL only distinguishes between white, black, and doubleWhole), "noteheadWhole" (U+E0A2) exists distinct from "noteheadHalf" (U+E0A3). And there is "noteheadB

Re: GSoC 2020: Shape-note notehead encoding

On Mon, Jul 20, 2020 at 8:25 PM Werner LEMBERG wrote: > > > [...] This will allow other programs to throw an error when, e.g., > > noteShapeKeystoneBlack isn't found in the font, notifying the user > > that something's wrong. If the correct styleset is used, the > > program will correctly displa

Re: GSoC 2020: Shape-note notehead encoding

> LilyPond's catalog of shape-note noteheads is unique because it > contains three full sets of noteheads--Aikin (default), Funk, and > Walker. [...] > > My current plan is to define the Aikin noteheads as described in the > SMuFL specs, while the other two sets will be stylistic alternates > wi

GSoC 2020: Shape-note notehead encoding

Hi all, LilyPond's catalog of shape-note noteheads is unique because it contains three full sets of noteheads--Aikin (default), Funk, and Walker. Even if some noteheads are similar between the three sets, they are deliberately defined separately and have slightly different looks.* SMuFL has no pro

Re: midi: convert data to bigendian encoding directly (issue 565920043 by hanw...@gmail.com)

commit f51b4dbe635670cc08789daa0d9670f60fa47423 Author: Han-Wen Nienhuys Date: Fri Apr 17 14:23:58 2020 +0200 midi: convert data to bigendian encoding directly https://codereview.appspot.com/565920043/

Re: midi: convert data to bigendian encoding directly (issue 565920043 by hanw...@gmail.com)

On 2020/04/17 17:11:59, Dan Eble wrote: > You're not doing this for performance, just for simplicity, correct? yes. The data -> hex string -> bin makes my eyes bleed. https://codereview.appspot.com/565920043/

Re: midi: convert data to bigendian encoding directly (issue 565920043 by hanw...@gmail.com)

You're not doing this for performance, just for simplicity, correct? https://codereview.appspot.com/565920043/

Re: midi: convert data to bigendian encoding directly (issue 565920043 by hanw...@gmail.com)

LGTM Makes the code much easier to read. Carl https://codereview.appspot.com/565920043/

Re: midi: convert data to bigendian encoding directly (issue 565920043 by hanw...@gmail.com)

LGTM https://codereview.appspot.com/565920043/

Re: weblinks: Fix encoding of link texts (issue 563860043 by jonas.hahnf...@gmail.com)

Reviewers: hanwenn, Message: On 2020/04/12 12:36:22, hanwenn wrote: > LGTM > > shortcut push? I can update the scripts afterwards. commit 23dbc2090b1f45ae26c7f88af6945bde00cb2ddd Author: Jonas Hahnfeld Date: Sun Apr 12 14:11:37 2020 +0200 weblinks: Fix encoding of link

weblinks: Fix encoding of link texts (issue 563860043 by jonas.hahnf...@gmail.com)

LGTM shortcut push? I can update the scripts afterwards. https://codereview.appspot.com/563860043/

Re: Fix most encoding problems with Guile 2.x (issue 555420043 by jonas.hahnf...@gmail.com)

On 2020/03/08 09:37:23, hanwenn wrote: > On 2020/03/08 09:33:24, hahnjo wrote: > > On 2020/03/07 23:15:09, hanwenn wrote: > > > > https://codereview.appspot.com/555420043/diff/549710049/lily/text-interface.cc > > > File lily/text-interface.cc (right): > > > > > > > > > https://codereview.appspot.c

Re: Fix most encoding problems with Guile 2.x (issue 555420043 by jonas.hahnf...@gmail.com)

On 2020/03/08 09:33:24, hahnjo wrote: > On 2020/03/07 23:15:09, hanwenn wrote: > > https://codereview.appspot.com/555420043/diff/549710049/lily/text-interface.cc > > File lily/text-interface.cc (right): > > > > > https://codereview.appspot.com/555420043/diff/549710049/lily/text-interface.cc#newcod

Re: Fix most encoding problems with Guile 2.x (issue 555420043 by jonas.hahnf...@gmail.com)

On 2020/03/07 23:15:09, hanwenn wrote: > https://codereview.appspot.com/555420043/diff/549710049/lily/text-interface.cc > File lily/text-interface.cc (right): > > https://codereview.appspot.com/555420043/diff/549710049/lily/text-interface.cc#newcode70 > lily/text-interface.cc:70: SCM ligature = ly

Re: Fix most encoding problems with Guile 2.x (issue 555420043 by jonas.hahnf...@gmail.com)

LGTM maybe add a TODO for the clumsy thing. https://codereview.appspot.com/555420043/diff/549710049/lily/text-interface.cc File lily/text-interface.cc (right): https://codereview.appspot.com/555420043/diff/549710049/lily/text-interface.cc#newcode70 lily/text-interface.cc:70: SCM ligature = ly_a

Fix most encoding problems with Guile 2.x (issue 555420043 by jonas.hahnf...@gmail.com)

`, `input/regression/song-repetition.log` * print of internal structures `input/regression/scheme-engraver.log` * and an encoding problem in `input/regression/song-basic-nonenglish.log` I guess all except the last are acceptable. If somebody has an idea for that please let me know: @@ -5,7 +5,7

Re: GUILE 2/3 and string encoding cost

Han-Wen Nienhuys writes: > Both your hunches were correct: > > the code below works, but it makes the GC time go from 2s to 5s. Have you disabled the call of scm_set_smob_mark in lily/include/smobs.tcc ? I mean, not having to use it is what should be the advantage of this change. > // GUILE v2

Re: GUILE 2/3 and string encoding cost

On Fri, Jan 24, 2020 at 6:09 PM Han-Wen Nienhuys wrote: > Both your hunches were correct: > > the code below works, but it makes the GC time go from 2s to 5s. Probably a lot of overhead would go away if we could properly pair up GC_FREE with GC_MALLOC from libgc, but I can't get this to pass GUIL

Re: GUILE 2/3 and string encoding cost

Both your hunches were correct: the code below works, but it makes the GC time go from 2s to 5s. // GUILE v2 uses the Boehm GC. By allocating all memory through // scm_gc_malloc, we ensure that all our data structures are traced // for SCM values. As a performance optimization, we could define /

Re: GUILE 2/3 and string encoding cost

David Kastrup writes: > Han-Wen Nienhuys writes: > >> On Fri, Jan 24, 2020 at 12:45 PM David Kastrup wrote: >>> >> No. Since much of LilyPond's data containing SCM values is stored in >>> >> STL containers, it would require serious messing with allocators to get >>> >> there. >>> > >>> > Good

Re: GUILE 2/3 and string encoding cost

Han-Wen Nienhuys writes: > On Fri, Jan 24, 2020 at 12:45 PM David Kastrup wrote: >> >> No. Since much of LilyPond's data containing SCM values is stored in >> >> STL containers, it would require serious messing with allocators to get >> >> there. >> > >> > Good point! And I'd agree with you, bu

Re: GUILE 2/3 and string encoding cost

On Fri, Jan 24, 2020 at 12:45 PM David Kastrup wrote: > >> No. Since much of LilyPond's data containing SCM values is stored in > >> STL containers, it would require serious messing with allocators to get > >> there. > > > > Good point! And I'd agree with you, but if I look at the source code, >

Re: GUILE 2/3 and string encoding cost

Han-Wen Nienhuys writes: > On Fri, Jan 24, 2020 at 10:51 AM David Kastrup wrote: > >> >> > What do you mean with "heap is collected"? >> >> "Collected" is probably the wrong expression. Sweeped and marked. The >> proposed behavior by Guile developers is not to bother with individual >> mark ho

Re: GUILE 2/3 and string encoding cost

On Fri, Jan 24, 2020 at 10:51 AM David Kastrup wrote: > > > What do you mean with "heap is collected"? > > "Collected" is probably the wrong expression. Sweeped and marked. The > proposed behavior by Guile developers is not to bother with individual > mark hooks and just let the whole heap be m

Re: GUILE 2/3 and string encoding cost

Han-Wen Nienhuys writes: > On Fri, Jan 24, 2020 at 11:30 AM David Kastrup wrote: >> >> >> On a 64bit application, this would be somewhat more tenable, but we'd >> >> >> need to override operator new for smobs. >> >> >> >> >> >> Or do we? Maybe the heap is collected by default, and we need to >

Re: GUILE 2/3 and string encoding cost

On Fri, Jan 24, 2020 at 11:30 AM David Kastrup wrote: > >> >> On a 64bit application, this would be somewhat more tenable, but we'd > >> >> need to override operator new for smobs. > >> >> > >> >> Or do we? Maybe the heap is collected by default, and we need to switch > >> >> that off? > >> >> >

Re: GUILE 2/3 and string encoding cost

Han-Wen Nienhuys writes: > On Fri, Jan 24, 2020 at 10:51 AM David Kastrup wrote: > >> >> >> On a 64bit application, this would be somewhat more tenable, but we'd >> >> need to override operator new for smobs. >> >> >> >> Or do we? Maybe the heap is collected by default, and we need to switch >>

Re: GUILE 2/3 and string encoding cost

Han-Wen Nienhuys writes: > On Fri, Jan 24, 2020 at 10:22 AM Hans Åberg wrote: > >> >> Boehm GC can work in a background thread I think. And Guile-v2 >> >> applications typically just let all their data be treated as pointers >> >> rather than using a smob-marking algorithm like we do, and it is

Re: GUILE 2/3 and string encoding cost

On Fri, Jan 24, 2020 at 10:51 AM David Kastrup wrote: > > >> On a 64bit application, this would be somewhat more tenable, but we'd > >> need to override operator new for smobs. > >> > >> Or do we? Maybe the heap is collected by default, and we need to switch > >> that off? > >> > >> > > What do

Re: GUILE 2/3 and string encoding cost

On Fri, Jan 24, 2020 at 10:22 AM Hans Åberg wrote: > >> Boehm GC can work in a background thread I think. And Guile-v2 > >> applications typically just let all their data be treated as pointers > >> rather than using a smob-marking algorithm like we do, and it is > >> conceivable that Boehm GC's

Re: GUILE 2/3 and string encoding cost

Han-Wen Nienhuys writes: > On Thu, Jan 23, 2020 at 10:39 PM David Kastrup wrote: > >> >> > on mozart-hrn-3, over 3 runs, we get >> > >> > 2.0.14 - avg 2.1s >> > 1.8.8 - avg 0.31s >> > >> > so the new GC is about 5-10x slower than the old one. With GUILE 1.8, >> > garbage collection covers typic

Re: GUILE 2/3 and string encoding cost

> On 24 Jan 2020, at 10:03, Han-Wen Nienhuys wrote: > > On Thu, Jan 23, 2020 at 10:39 PM David Kastrup wrote: > >> >>> on mozart-hrn-3, over 3 runs, we get >>> >>> 2.0.14 - avg 2.1s >>> 1.8.8 - avg 0.31s >>> >>> so the new GC is about 5-10x slower than the old one. With GUILE 1.8, >>> gar

Re: GUILE 2/3 and string encoding cost

On Thu, Jan 23, 2020 at 10:39 PM David Kastrup wrote: > > > on mozart-hrn-3, over 3 runs, we get > > > > 2.0.14 - avg 2.1s > > 1.8.8 - avg 0.31s > > > > so the new GC is about 5-10x slower than the old one. With GUILE 1.8, > > garbage collection covers typically is 10% of the runtime, so all thi

Re: GUILE 2/3 and string encoding cost

Han-Wen Nienhuys writes: > On Wed, Jan 22, 2020 at 10:53 PM Han-Wen Nienhuys wrote: > >> The GUILE 2.0 release >> >> https://lwn.net/Articles/428288/ >> >> has one big red flag for me. >> >> * Switch to the Boehm-Demers-Weiser garbage collector >> > > We can easily measure this, by adding th

Re: GUILE 2/3 and string encoding cost

On Wed, Jan 22, 2020 at 10:53 PM Han-Wen Nienhuys wrote: > The GUILE 2.0 release > > https://lwn.net/Articles/428288/ > > has one big red flag for me. > > * Switch to the Boehm-Demers-Weiser garbage collector > We can easily measure this, by adding the following to #(display (version)) #(di

Re: GUILE 2/3 and string encoding cost

Han-Wen Nienhuys writes: > On Wed, Jan 22, 2020 at 11:43 PM David Kastrup wrote: > >> > Actually, the I was comparing the -O2 build with the -O0 build. >> > >> > When recompiling, the Scheme init (reading .scm files) takes 0.31s in 1.8 >> > vs. 2.7s in 2.0, a 9x slowdown. >> >> The Guile-2 compi

Re: GUILE 2/3 and string encoding cost

On Wed, Jan 22, 2020 at 11:43 PM David Kastrup wrote: > > Actually, the I was comparing the -O2 build with the -O0 build. > > > > When recompiling, the Scheme init (reading .scm files) takes 0.31s in 1.8 > > vs. 2.7s in 2.0, a 9x slowdown. > > The Guile-2 compiler is doing a lot of optimisations,

Re: GUILE 2/3 and string encoding cost

Am Mi., 22. Jan. 2020 um 22:32 Uhr schrieb Thomas Morley : > > Am Mi., 22. Jan. 2020 um 12:12 Uhr schrieb Thomas Morley > : > > > > Am Mi., 22. Jan. 2020 um 12:02 Uhr schrieb David Kastrup : > > > > > > Han-Wen Nienhuys writes: > > > > > > So, what hard data do we have on GUILE 2/3 slowness, and w

Re: GUILE 2/3 and string encoding cost

Han-Wen Nienhuys writes: > On Wed, Jan 22, 2020 at 10:53 PM Han-Wen Nienhuys wrote: > >> >> >> On Wed, Jan 22, 2020 at 12:01 PM David Kastrup wrote: >> >>> >>> > So, what hard data do we have on GUILE 2/3 slowness, and what does >>> > that data say? >>> >>> That data says "humongous slowdown".

Re: GUILE 2/3 and string encoding cost

On Wed, Jan 22, 2020 at 10:53 PM Han-Wen Nienhuys wrote: > > > On Wed, Jan 22, 2020 at 12:01 PM David Kastrup wrote: > >> >> > So, what hard data do we have on GUILE 2/3 slowness, and what does >> > that data say? >> >> That data says "humongous slowdown". There is not much more than >> specula

Re: GUILE 2/3 and string encoding cost

On Wed, Jan 22, 2020 at 12:01 PM David Kastrup wrote: > > > So, what hard data do we have on GUILE 2/3 slowness, and what does > > that data say? > > That data says "humongous slowdown". There is not much more than > speculation what this is caused by as far as I know. > I can see the 2x slowdo

Re: GUILE 2/3 and string encoding cost

Am Mi., 22. Jan. 2020 um 22:36 Uhr schrieb Thomas Morley : > > Am Mi., 22. Jan. 2020 um 21:52 Uhr schrieb Karlin High : > > > > On 1/22/2020 2:07 PM, Han-Wen Nienhuys wrote: > > > Do we have a standardized test file for benchmarking performance? > > > > I can't speak to "standardized," but I do rem

Re: GUILE 2/3 and string encoding cost

Am Mi., 22. Jan. 2020 um 21:52 Uhr schrieb Karlin High : > > On 1/22/2020 2:07 PM, Han-Wen Nienhuys wrote: > > Do we have a standardized test file for benchmarking performance? > > I can't speak to "standardized," but I do remember some threads that had > benchmarking going on by various users, usi

Re: GUILE 2/3 and string encoding cost

Am Mi., 22. Jan. 2020 um 12:12 Uhr schrieb Thomas Morley : > > Am Mi., 22. Jan. 2020 um 12:02 Uhr schrieb David Kastrup : > > > > Han-Wen Nienhuys writes: > > > > So, what hard data do we have on GUILE 2/3 slowness, and what does > > > that data say? > > > > That data says "humongous slowdown". T

Re: GUILE 2/3 and string encoding cost

On 1/22/2020 2:07 PM, Han-Wen Nienhuys wrote: Do we have a standardized test file for benchmarking performance? I can't speak to "standardized," but I do remember some threads that had benchmarking going on by various users, using large LilyPond projects. The Robert Carver "Missa Dum Sacrum

Re: GUILE 2/3 and string encoding cost

t; >> > conversion checks if there are any code points over 255 > >> > > >> > > >> > > >> > https://git.savannah.nongnu.org/cgit/guile.git//tree/libguile/strings.c/?id=1b8e9ca0e37fab366435436995248abdfc780a10#n1620 > &

Re: GUILE 2/3 and string encoding cost

ode, you can see that the UTF-8 -> SCM >> > conversion checks if there are any code points over 255 >> > >> > >> > >> https://git.savannah.nongnu.org/cgit/guile.git//tree/libguile/strings.c/?id=1b8e9ca0e37fab366435436995248abdfc780a10#n

Re: GUILE 2/3 and string encoding cost

> > >> > >> > >> https://git.savannah.nongnu.org/cgit/guile.git//tree/libguile/strings.c/?id=1b8e9ca0e37fab366435436995248abdfc780a10#n1620 >> > >> > if there aren't, it uses Latin1 encoding ("narrow == 1") to encode the >> > string as a normal byte a

Re: GUILE 2/3 and string encoding cost

strings.c/?id=1b8e9ca0e37fab366435436995248abdfc780a10#n1620 > > > > if there aren't, it uses Latin1 encoding ("narrow == 1") to encode the > > string as a normal byte array. This code walks the string twice, but that > > is very cheap due to CPU cache locality, so

Re: GUILE 2/3 and string encoding cost

Am Mi., 22. Jan. 2020 um 12:02 Uhr schrieb David Kastrup : > > Han-Wen Nienhuys writes: > > So, what hard data do we have on GUILE 2/3 slowness, and what does > > that data say? > > That data says "humongous slowdown". There is not much more than > speculation what this is caused by as far as I

Re: GUILE 2/3 and string encoding cost

e, you can see that the UTF-8 -> SCM > conversion checks if there are any code points over 255 > > > https://git.savannah.nongnu.org/cgit/guile.git//tree/libguile/strings.c/?id=1b8e9ca0e37fab366435436995248abdfc780a10#n1620 > > if there aren't, it uses Latin1 encoding ("

Re: Encoding changes for Python 3 (issue 571280043 by jonas.hahnf...@gmail.com)

Reviewers: lemzwerg, Message: Closing as the change got smaller and smaller as I discovered more edge cases where the current code matters with Python 2.x Description: Encoding changes for Python 3 This is required to eventually make the scripts work with Python 3. The change happens to also

GUILE 2/3 and string encoding cost

if there are any code points over 255 https://git.savannah.nongnu.org/cgit/guile.git//tree/libguile/strings.c/?id=1b8e9ca0e37fab366435436995248abdfc780a10#n1620 if there aren't, it uses Latin1 encoding ("narrow == 1") to encode the string as a normal byte array. This code walks the

Encoding changes for Python 3 (issue 571280043 by jonas.hahnf...@gmail.com)

LGTM https://codereview.appspot.com/571280043/

Re: Prepare for encoding changes in Python 3 (issue 573280043 by jonas.hahnf...@gmail.com)

On 2019/11/25 02:44:20, Dan Eble wrote: On 2019/11/24 11:47:01, hahnjo wrote: > On 2019/11/23 16:45:17, Dan Eble wrote: > > If an XML file is opened as a binary file, will the treatment of > > platform-specific line endings become inconvenient for some people? > > I hope it does not: Once we kn

Re: Prepare for encoding changes in Python 3 (issue 573280043 by jonas.hahnf...@gmail.com)

On 2019/11/24 11:47:01, hahnjo wrote: On 2019/11/23 16:45:17, Dan Eble wrote: > If an XML file is opened as a binary file, will the treatment of > platform-specific line endings become inconvenient for some people? I hope it does not: Once we know it's really text, the code will call decode('u

Re: Prepare for encoding changes in Python 3 (issue 573280043 by jonas.hahnf...@gmail.com)

k + doc. Description: Prepare for encoding changes in Python 3 This is most of the remaining diff for porting to Python 3, but this also works in Python 2.4 already (even though not strictly needed). Individual changes: 1. Encode strings before hashing Python 3 requires "bytes-like objects".

Re: Prepare for encoding changes in Python 3 (issue 573280043 by jonas.hahnf...@gmail.com)

3. Open midi and musicxml files in binary mode Only decode once we are sure that the content is not compressed. If an XML file is opened as a binary file, will the treatment of platform-specific line endings become inconvenient for some people? https://codereview.appspot.com/573280043/

Prepare for encoding changes in Python 3 (issue 573280043 by jonas.hahnf...@gmail.com)

LGTM, thanks! https://codereview.appspot.com/573280043/

Re: Fix the encoding of the PDF metadata when using guile-2.0 (issue 322930043 by thomasmorle...@gmail.com)

Thanks for review. https://codereview.appspot.com/322930043/diff/1/scm/framework-ps.scm File scm/framework-ps.scm (right): https://codereview.appspot.com/322930043/diff/1/scm/framework-ps.scm#newcode604 scm/framework-ps.scm:604: ;; could be replaced with the followng code: On 2017/05/01 18:39:2

Re: Fix the encoding of the PDF metadata when using guile-2.0 (issue 322930043 by thomasmorle...@gmail.com)

LGTM https://codereview.appspot.com/322930043/diff/1/scm/framework-ps.scm File scm/framework-ps.scm (right): https://codereview.appspot.com/322930043/diff/1/scm/framework-ps.scm#newcode604 scm/framework-ps.scm:604: ;; could be replaced with the followng code: s/followng/following/ https://code

Fix the encoding of the PDF metadata when using guile-2.0 (issue 322930043 by thomasmorle...@gmail.com)

escription: Fix the encoding of the PDF metadata when using guile-2.0 Postscript files are encoded in Latin1, but PDF metadata has to be encoded in UTF-16BE. ly:encode-string-for-pdf takes care of that but it was not working properly with guile-2.0 because the internal representation of strings i

Re: PDF is broken for @notation{} encoding

"Phil Holmes" writes: > From: "David Kastrup" >> >> Let's cut this short. Test this patch first. If it fixes the problem, >> the bisection is pointless. > > > That fixes it. Can you push the patch to staging? I pushed a variant of it to staging (one without the change in version/timestamp th

Re: PDF is broken for @notation{} encoding

- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: "James Lowe" ; Sent: Tuesday, May 26, 2015 12:43 PM Subject: Re: PDF is broken for @notation{} encoding "Phil Holmes" writes: - Original Message - From: "David

Re: PDF is broken for @notation{} encoding

"Phil Holmes" writes: > - Original Message - > From: "David Kastrup" > To: "Phil Holmes" > Cc: "James Lowe" ; > Sent: Tuesday, May 26, 2015 11:57 AM > Subject: Re: PDF is broken for @notation{} encoding >> Huh. Git bi

Re: PDF is broken for @notation{} encoding

- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: "James Lowe" ; Sent: Tuesday, May 26, 2015 11:57 AM Subject: Re: PDF is broken for @notation{} encoding Huh. Git bisect would have heeded the _topological_ order and would have made it mo

Re: PDF is broken for @notation{} encoding

"Phil Holmes" writes: > From: "David Kastrup" > >> I'm still flabbergasted at the supposed faulty commit. Here is one >> theory I'd consider more plausible: >> >> commit 5eca56fae0faa2db9cf7f12903e1a06c42b2af0d >> Author: Walter Garcia-Fontes >> Date: Sat Feb 7 20:00:15 2015 +0100 >> >>D

Re: PDF is broken for @notation{} encoding

- Original Message - From: "David Kastrup" To: "James Lowe" Cc: Sent: Tuesday, May 26, 2015 10:07 AM Subject: Re: PDF is broken for @notation{} encoding James Lowe writes: On 26/05/15 08:35, David Kastrup wrote: James Lowe writes: On 25/05/15 16:08, Phil

Re: PDF is broken for @notation{} encoding

James Lowe writes: > On 26/05/15 08:35, David Kastrup wrote: >> James Lowe writes: >> >>> On 25/05/15 16:08, Phil Holmes wrote: I can try again, but it was consistent. James might want to try? >>> >>> If it helps. >>> >>> I get the same thing too. >> >> How much effort is it to do one it

Re: PDF is broken for @notation{} encoding

"Phil Holmes" writes: > - Original Message - > From: "David Kastrup" > To: "James Lowe" > Cc: "Phil Holmes" ; > Sent: Tuesday, May 26, 2015 9:02 AM > Subject: Re: PDF is broken for @notation{} encoding > > >

Re: PDF is broken for @notation{} encoding

- Original Message - From: "David Kastrup" To: "James Lowe" Cc: "Phil Holmes" ; Sent: Tuesday, May 26, 2015 9:02 AM Subject: Re: PDF is broken for @notation{} encoding James Lowe writes: On 26/05/15 08:35, David Kastrup wrote: James Lowe wri

Re: PDF is broken for @notation{} encoding

James Lowe writes: > On 26/05/15 08:35, David Kastrup wrote: >> James Lowe writes: >> >>> On 25/05/15 16:08, Phil Holmes wrote: I can try again, but it was consistent. James might want to try? >>> >>> If it helps. >>> >>> I get the same thing too. >> >> How much effort is it to do one it

Re: PDF is broken for @notation{} encoding

On 26/05/15 08:35, David Kastrup wrote: > James Lowe writes: > >> On 25/05/15 16:08, Phil Holmes wrote: >>> I can try again, but it was consistent. James might want to try? >> >> If it helps. >> >> I get the same thing too. > > How much effort is it to do one iteration on one affected file? I

Re: PDF is broken for @notation{} encoding

James Lowe writes: > On 25/05/15 16:08, Phil Holmes wrote: >> I can try again, but it was consistent. James might want to try? > > If it helps. > > I get the same thing too. How much effort is it to do one iteration on one affected file? I have absolutely no clue how this may come about so if

  1   2   >