Re: Reading files as byte array
Am Sonntag, dem 05.09.2021 um 23:22 +0200 schrieb Valentin Petzel: > Hello Jonas. Ly:gulp-file handles Unicode, so probably no. But even though it > would be possible to work around this (for example by parsing each char and > counting the bits) this does seem like a very messy solution for me, as it > goes bit stream (file) → string → bit stream, with a completely unnescessary > (and potentially risky) conversion in between. No, ly:gulp-file should not perform any conversion, it should just read the file and create a latin1 string IIRC. ly:gulp-file-utf8 does what its name implies. signature.asc Description: This is a digitally signed message part
Re: Reading files as byte array
Would it be considered okay if we included a scheme function to read a binary file to a byte array? GUILE already supports this out of the box. Have you seen https://www.gnu.org/software/guile/manual/html_node/Binary-I_002fO.html ? Yes, of course GUILE supports this. But the problem is that this does not go through Lilypond’s path handling. So I really do not think this would be a good thing to use (of course one can use that internally, but I’m talking about a Lilypond friendly interface). Just from comparing those statements: Would it be reasonable (and maybe generally useful) to make global_path.find (used in gulp_file_to_string, lily-guile.cc) available at scheme level? Lukas
Re: Guile 2 (was: Cairo plans)
Le 05/09/2021 à 22:46, Jonas Hahnfeld via Discussions on LilyPond development a écrit : Hm, when Harm brought up this point in the previous thread in May, I did not understand this to be a critical showstopper for adoption of Guile 2.2 (is it?) or I would have prioritized this over working on the new infrastructure to compile binaries. Not critical: it's not like Guile 1 is good at error locations either or errors in general. But one does encounter a number of cases where using Guile 1 in LilyPond yields better errors -- at least this has been my main source of frustration since starting to build with Guile 2. I guess everybody has their particular point they would want to see improved before switching to Guile 2. IIRC Harm's comments were mostly about not confusing the average user with ugly backtraces of Scheme internals - which was solved some time ago by only enabling them in debug mode. For the error locations, I had some WIP solution for ~80% of the cases (typos and wrong argument types) by installing a custom exception handler and manually adding the location information of where the parsed code came from. I had hoped to revisit this approach over the weekend, but it didn't happen. I cannot foresee when I will have time for this, but just to let people know that I don't think all hope is lost here. Nice to hear! Best, Jean
Re: Reading files as byte array
Hello Jonas. Ly:gulp-file handles Unicode, so probably no. But even though it would be possible to work around this (for example by parsing each char and counting the bits) this does seem like a very messy solution for me, as it goes bit stream (file) → string → bit stream, with a completely unnescessary (and potentially risky) conversion in between. signature.asc Description: This is a digitally signed message part.
Re: Guile 2 (was: Cairo plans)
Am Montag, dem 30.08.2021 um 20:01 +0200 schrieb Jean Abou Samra: > > I would highly prefer to not mix switching the default backend with > > switching to Guile 2.2 that will already be disruptive enough (yes, > > it's going slower than I had hoped...). > > > At the moment, I have trouble seeing how Guile 2 could be made to > work well. The absence of error locations is a source of frustration. > My understanding is that this is a design limitation of Guile 2 and > later when interpreting code (as opposed to byte-compiling). Hm, when Harm brought up this point in the previous thread in May, I did not understand this to be a critical showstopper for adoption of Guile 2.2 (is it?) or I would have prioritized this over working on the new infrastructure to compile binaries. IIRC Harm's comments were mostly about not confusing the average user with ugly backtraces of Scheme internals - which was solved some time ago by only enabling them in debug mode. For the error locations, I had some WIP solution for ~80% of the cases (typos and wrong argument types) by installing a custom exception handler and manually adding the location information of where the parsed code came from. I had hoped to revisit this approach over the weekend, but it didn't happen. I cannot foresee when I will have time for this, but just to let people know that I don't think all hope is lost here. Jonas signature.asc Description: This is a digitally signed message part
Re: Reading files as byte array
Am Sonntag, dem 05.09.2021 um 10:23 +0200 schrieb Valentin Petzel: > Hello, > > Would it be considered okay if we included a scheme function to read a binary > file to a byte array? > > This would be useful for correct handling of eps-files (which currently does > not support the actual eps specification). > > Basically an eps-file appears to be mixed content, with some binary > information and some simple text. This seems to serve the purpose of > embedding > previews into the eps file. So an eps-file might have a binary header that > specifies the byte location of the PS content. ly:gulp-file should read the contents of a file and return it as a latin1 (basically binary) string, no? I know that it is at least used to read binary resources into the PS backend... signature.asc Description: This is a digitally signed message part
Re: Reading files as byte array
Yes, of course GUILE supports this. But the problem is that this does not go through Lilypond’s path handling. So I really do not think this would be a good thing to use (of course one can use that internally, but I’m talking about a Lilypond friendly interface). Am Sonntag, 5. September 2021, 19:45:31 CEST schrieb Han-Wen Nienhuys: > On Sun, Sep 5, 2021 at 3:10 PM Valentin Petzel wrote: > > Would it be considered okay if we included a scheme function to read a > > binary file to a byte array? > > GUILE already supports this out of the box. Have you seen > > https://www.gnu.org/software/guile/manual/html_node/Binary-I_002fO.html > > ? signature.asc Description: This is a digitally signed message part.
Re: Reading files as byte array
On Sun, Sep 5, 2021 at 3:10 PM Valentin Petzel wrote: > Would it be considered okay if we included a scheme function to read a binary > file to a byte array? GUILE already supports this out of the box. Have you seen https://www.gnu.org/software/guile/manual/html_node/Binary-I_002fO.html ? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Reading files as byte array
Hello, Would it be considered okay if we included a scheme function to read a binary file to a byte array? This would be useful for correct handling of eps-files (which currently does not support the actual eps specification). Basically an eps-file appears to be mixed content, with some binary information and some simple text. This seems to serve the purpose of embedding previews into the eps file. So an eps-file might have a binary header that specifies the byte location of the PS content. Cheers, Valentin signature.asc Description: This is a digitally signed message part.
Re: Cairo plans
> I analyzed more closely in the issue > https://gitlab.com/lilypond/lilypond/-/issues/6172 The garbling sample I have shown has two different issues. #6172 is one of them. I created #6173 for the other one. https://gitlab.com/lilypond/lilypond/-/issues/6173
