Re: search for better regtest comparison algorithm

2024-07-30 Thread Luca Fascione
rd to realign by a subpixel amount. And mind you: we need _tests_ not just the images, I want to investigate if making the images in a different format helps (with/withou aa, messing with resolution, ... whatever the case might be) L On Tue, Jul 30, 2024 at 11:47 AM Luca Fascione wrote: > Yes we do

Re: search for better regtest comparison algorithm

2024-07-30 Thread Luca Fascione
Yes we do need a few tests set aside for this. Agreed. I was thinking about antialiasing and such, it's possible a different approach might work: render at a somewhat higher resolution, then backshift and blur everything a bit (say a gaussian of 2 pixels or so, just a touch). That might make

Re: search for better regtest comparison algorithm

2024-07-29 Thread Luca Fascione
On Mon, Jul 29, 2024 at 4:54 PM Werner LEMBERG wrote: > Please don't change the topic in this thread > yeah fair enough -- Luca Fascione

Re: search for better regtest comparison algorithm

2024-07-29 Thread Luca Fascione
On Mon, Jul 29, 2024 at 3:32 PM Han-Wen Nienhuys wrote: > On Mon, Jul 29, 2024 at 12:10 PM Luca Fascione > wrote: > > So once you have the above, you add hierarchies to the above so you can > deploy a branch-and-bound strategy > > > > Make bigger tests that c

Re: search for better regtest comparison algorithm

2024-07-29 Thread Luca Fascione
because more of the community working on lilypond will be able to update this part of the code as well, which seems of paramount importance. But still, at least as curiosity, I figured I would mention it. -- Luca Fascione

Re: search for better regtest comparison algorithm

2024-07-29 Thread Luca Fascione
Hi Han-Wen, I was actually thinking about this situation upside-down from how you're seeing it, details below On Mon, Jul 29, 2024 at 10:30 AM Han-Wen Nienhuys wrote: > On Mon, Jul 29, 2024 at 8:56 AM Luca Fascione > wrote: > > [shifts are] going to be some random, non-integer qua

Re: search for better regtest comparison algorithm

2024-07-29 Thread Luca Fascione
Werner, Could you write me a line or two about these shifts we get? Like: they're going to be some random, non-integer quantity, right? Also, the rasterization that gets performed, is it anti aliased? It would seem that though shifts and changes in the lengths of the staves are "common", small and

Re: search for better regtest comparison algorithm

2024-07-27 Thread Luca Fascione
Ok awesome On Sat, 27 Jul 2024, 21:35 Werner LEMBERG, wrote: > > > Yes, I might be a moment due to friends visiting and such, but > > definitely can. > > Great! > > > Could you get me going pointing me to a few image pairs and an > > indication (like you did on SE) of the defect you see? > >

Re: search for better regtest comparison algorithm

2024-07-27 Thread Luca Fascione
/NumPy/SciPy ok, yes? I'll pick a random version to show the concept, and then we can adapt to whatever dependencies lily is comfortable with. Importantly: is it ok to make lilypond's test suite depend on NumPy? It's not a small package (although it is easy and rock-solid to install) Cheers, Luca --

Re: search for better regtest comparison algorithm

2024-07-27 Thread Luca Fascione
At my previous work I had written the image comparison framework for our regression test suite, it worked very well for us and it was in python/numpy/scipy (which threads well internally). Werner the case you have on SE seems to indicate you need a translation invariant test, I think. Another

Re: clang compiler warnings

2024-02-27 Thread Luca Fascione
; >> inline constexpr auto VPOS = vsize (-1); > >> > > > > Well. To that, yes and no. I read it better in the original way, > > [...] > > I'm on Dan's side here: Using 'auto' tells me that the right-hand > side's type is exactly the one on the left-ha

Re: clang compiler warnings

2024-02-27 Thread Luca Fascione
On Tue, Feb 27, 2024 at 4:55 AM Dan Eble wrote: > On 2024-02-27 07:14, Luca Fascione wrote: > > inline constexpr vsize VPOS (vsize(-1)); > > OK, but don't repeat the type. > > inline constexpr auto VPOS = vsize (-1); > Well. To that, yes and no. I read it be

Re: clang compiler warnings

2024-02-27 Thread Luca Fascione
ropriate value, as it's not covariant with the definition of vsize. This is just going from one bug today to a bug tomorrow. L -- Luca Fascione

Re: clang compiler warnings

2024-02-27 Thread Luca Fascione
I'd just make the cast explicit: inline constexpr vsize VPOS (vsize(-1)); It's cleaner and requires less updates as the code evolves. However, I can't reproduce it, what compiler flags are you using? I'm using -Wall and clang is quiet about this use case */tmp %* g++ -Wall -std=c++17 xxx.cc

Re: fetaBraces

2023-03-15 Thread Luca Fascione
mardi 14 mars 2023 à 15:46 +0100, Luca Fascione a écrit : > > This discussion makes me wonder whether something similar to LaTeX's > virtual fonts system wouldn't be useful here. > A virtual font is effectively a lookup table that says "for code point X > pick up font Y code po

Re: fetaBraces

2023-03-14 Thread Luca Fascione
tation font, no? I mean, aside from demonstrating typographical capabilities, is there an honest use case for a flurry of different fonts continuously jumping here and there in a single score? L -- Luca Fascione

Re: Ghostscript and new PDF interpreter

2023-02-23 Thread Luca Fascione
Wow. Congratulations! On Fri, 24 Feb 2023, 08:02 Werner LEMBERG, wrote: > > Six weeks ago I wrote about a very unpleasant size increase of > `notation.pdf` from 8MByte to 27MByte with the new PDF engine of `gs`: > > >>> I'll soon file a bug report for GS regarding the size issue. > >> > >> This

Re: RFC: stop doing "grand replace" updates to copyright years

2023-02-15 Thread Luca Fascione
> > > I prefer not postponing decisions. > > My preferred route is to just remove those copyright headers or > at least the years; they have little significance legally anyway (as > David explained). > -- Luca Fascione

Re: RFC: stop doing "grand replace" updates to copyright years

2023-02-14 Thread Luca Fascione
MHO, it's simple: Just follow the GNU guidelines. > -- Luca Fascione

Re: RFC: stop doing "grand replace" updates to copyright years

2023-02-14 Thread Luca Fascione
houses and bodies investing big money in software in a variety of ways. Disclaimer: Whatever I say here shall not be taken as me representing the opinions, views or will of any of them and I am not a lawyer L -- Luca Fascione

Re: Explicit default duration?

2023-01-26 Thread Luca Fascione
prefer > x. > > Cf > > c'' p2 > > c'' x2 > > For some reason, p looks more like a particular pitch to me than x . > Now I am not the greatest fan of q either but that ship has sailed. > > And I guess there is little utility in > >c'' ibid2 > -- Luca Fascione

Re: Explicit default duration?

2023-01-23 Thread Luca Fascione
Of course. Forgive me I got distracted with Mats's message (for which I suspect 'p' could be a viable suggestion? p -> last sound (or last pitch?), q -> last chord) For your case I'm warming up to the 0, actually L On Mon, Jan 23, 2023 at 6:01 PM David Kastrup wrote: > Luca Fascion

Re: Explicit default duration?

2023-01-23 Thread Luca Fascione
; bush. > > I am not saying that 0 is the best choice here. It merely appears to be > rather cheap. I thought of * and / but the first renders sequences like > c4*2 ambiguous and the second would at least become a mess in chord > mode. > > -- > David Kastrup > > -- Luca Fascione

Re: Inactive translations

2023-01-22 Thread Luca Fascione
Jonas, Would it makes sense to automatically reset this at every release round? I'm thinking it should be the translators that certify the liveness of their work. So I'm wondering what if when 2..0 is getting close, all translations that don't have a commit since 3months (say, or that miss

Re: updating merge request

2023-01-20 Thread Luca Fascione
slices of the task more cleanly > delineated. In a sense, there is some "history" to the process that > might be worth preserving during this stage. > > > -- Aaron Hill > > -- Luca Fascione

Re: Turkish makam

2023-01-18 Thread Luca Fascione
Jan 16, 2023 at 4:30 AM Luca Fascione > wrote: > >> All this being said, I just read there are hundreds of makams, which >> makes me wonder whether it >> wouldn't be more effective to provide a simple method to indicate the >> makam of a piece at the start >>

Re: Turkish makam

2023-01-16 Thread Luca Fascione
"this kind": - effectively a big long list/dictionary of values - clearly the case that the values will never change (beyond what will be bugfixes of the "clerical error" kind) L -- Luca Fascione

Re: Turkish makam

2023-01-16 Thread Luca Fascione
orget the Arabic term...iqa?) > balkan-keysigs.ly > balkan-rhythms.ly > greek-byzantine.ly > > FWIW, I feel this is a very good naming pattern, it's concise and super clear about what's up. Loveit L -- Luca Fascione

Re: RFC: require librsvg to implement SVG image support

2023-01-15 Thread Luca Fascione
On Sun, 15 Jan 2023, 12:25 Jonas Hahnfeld via Discussions on LilyPond development, wrote: > PDF is the more "logical" > successor to the inclusion of EPS. > It never occured to me we wouldn't support PDF. I always heard the discussion as "do we actually really need SVG inclusion when emitting

Re: The hel-arabic.ly file story...

2023-01-13 Thread Luca Fascione
with the old name which warns of the deprecation and includes the new file, to maintain compatibility. I'll now stop saying things everybody else already knows. L -- Luca Fascione

Re: The hel-arabic.ly file story...

2023-01-13 Thread Luca Fascione
po, it seems like we could easily find a better name for this file, more descriptive of its purpose and less related to the original author. L -- Luca Fascione

Re: The hel-arabic.ly file story...

2023-01-13 Thread Luca Fascione
signatures for the various maqams simply go only into > hel-arabic.ly > (if not modified, as recently proposed) > If you want examples I can provide them. > This is why I did not want to link hel-arabic.ly to arabic.ly > Best regard > > -- Luca Fascione

Re: The hel-arabic.ly file story...

2023-01-11 Thread Luca Fascione
Hassan: Even if self sufficient was a good goal (sometimes it is, some times it isn't) it should be achieved by inclusion of other content, in this case probably arabic.ly, so that fixes only need to happen in one place. The objection here is to the duplication of the code, not to the

Re: Missing items to make Cairo ready

2023-01-07 Thread Luca Fascione
s your proposal to implement \epsfile by using gs to render EPS into a PNG, and embed that into the resulting PDF. I seem to have misunderstood something you said. L -- Luca Fascione

Re: Missing items to make Cairo ready

2023-01-07 Thread Luca Fascione
by the packages, arguably, at least in LaTeX). L -- Luca Fascione

Re: Missing items to make Cairo ready

2023-01-01 Thread Luca Fascione
ll a user control it? L -- Luca Fascione

Re: Missing items to make Cairo ready

2023-01-01 Thread Luca Fascione
n 1, 2023 at 8:19 PM Jean Abou Samra wrote: > Le 01/01/2023 à 19:30, Luca Fascione a écrit : > > Also, how does ImageMagick implement PS to PNG conversion? > > Through Ghostscript, just like LilyPond does now. > -- Luca Fascione

Re: Missing items to make Cairo ready

2023-01-01 Thread Luca Fascione
What if you use GS to do PS to PDF instead and embed that? Would Cairo let you? (For the PDF backend I mean) Also, how does ImageMagick implement PS to PNG conversion? I wonder if their approach might inspire us, or whether having an optional dependency would be an idea to consider (if you have

Re: Thoughts on GLib regexes

2022-11-30 Thread Luca Fascione
Given a chance I would always pick PCRE. On Wed, 30 Nov 2022, 07:18 Werner LEMBERG, wrote: > > > As shown by https://gitlab.com/lilypond/lilypond/-/issues/6463, > > Guile regular expressions are a trap when it comes to Unicode. > > Under a non-Unicode locale, characters that can't be expressed

Re: Prefer luatex for documentation

2022-11-29 Thread Luca Fascione
That last statement is terrifying. Is it sustainable to build a 2D dictionary keyed by platform and a name of our choosing for the locale to use as a map and fill it gradually as we discover new holes? Or would it be too much hassle? I'm thinking new platforms or new translations are events that

Re: Prefer luatex for documentation

2022-11-29 Thread Luca Fascione
I'd have thought au jour d'ui 227MB qualifies as small, no? It's averaging at 500kB/package which is bigger than I thought (I'd have thought more like 50k tops, tbh) but it seems like it'd be a relatively manageable size for a one-off setup... A compiler or browser release or a couple weeks worth

Re: Prefer luatex for documentation

2022-11-29 Thread Luca Fascione
Question: I would have thought locales would be a) largely present, b) small and easy to install as dependencies, like many other dependencies we have (and substantially less prone to change than any software dependency) Where does the concern with locales not being available on a system come

Re: Color variables/symbols

2022-11-26 Thread Luca Fascione
Indeed, you even had said before. Thanks Werner L On Sat, 26 Nov 2022, 21:55 Werner LEMBERG, wrote: > > > Why the difference in value? Red is 10% off, green more like 30%? > > Different standards (terminal colors vs. X11/CSS): identical names but > different colours. > > >Werner >

Re: Color variables/symbols

2022-11-26 Thread Luca Fascione
Why the difference in value? Red is 10% off, green more like 30%? What's up with that? L On Sat, 26 Nov 2022, 19:21 Werner LEMBERG, wrote: > > >>> lukas@Aquarium:~/git/lilypond/scm(master)$ git grep darkred > >>> color.scm:(darkred 0.54509803921568623 0 0) > >>>

Re: pygment regex question

2022-11-25 Thread Luca Fascione
On Fri, 25 Nov 2022, 18:11 Jean Abou Samra, wrote: > What makes you think Pygments can’t do this? You can do > > (?<=\w+)\d+ > Nothing but my not remembering lookaheads/lookbehinds, which I may argue aren't very commom constructs. In fact aside from PERL I'm not even sure what precedent they

Re: pygment regex question,Re: pygment regex question

2022-11-25 Thread Luca Fascione
I agree this would be a better regex, yes. (You still have that double re: thing in the subject going on, Werner) L On Fri, 25 Nov 2022, 17:55 Werner LEMBERG, wrote: > >> Note that at the time this regex is active, numbers are taken care > >> of. > > > > Floats are, integers not. > > OK, but

Re: pygment regex question

2022-11-25 Thread Luca Fascione
It's not a validation, it's an anchor, it avoids it matching other numbers. That's why the capture. If pygments was better designed it'll let you do semi-context-sensitive stuff like this, so you could say "numbers, but only if the follow a note name" -> durations L On Fri, 25 Nov 2022, 17:52

Re: pygment regex question

2022-11-25 Thread Luca Fascione
at the time this regex is active, > numbers are taken care of. > > > Werner > > -- Luca Fascione

Re: Prefer luatex for documentation

2022-11-21 Thread Luca Fascione
gress, make their planning invalid (possibly because we're not delivering to what we promised), we are behaving poorly to them. I share that concern, and I think it's a very ethically sound concern to have, it's an important thing to worry about, I'd say. I'd characterize it as a user-focused concern, no? L -- Luca Fascione

Re: Prefer luatex for documentation

2022-11-21 Thread Luca Fascione
ful answer, AFAICS. > Au contraire: it means you can ask anybody that builds our docs to upgrade their tex distro to a new one, and they'll have a working LuaTeX "no matter what system they use othrwise". Which seems to me it's a very useful answer (it removes one constraint I guess). -- Luca Fascione

Re: Prefer luatex for documentation

2022-11-21 Thread Luca Fascione
On Mon, Nov 21, 2022 at 2:05 PM Jean Abou Samra wrote: > > Le 21 nov. 2022 à 13:46, Luca Fascione a écrit : > > Sorry, luatex is like 10yrs old, what's the need for xetex again? > Are you asking this to me (judging from To:/Cc:)? I don’t see one. > No, I was asking th

Re: Prefer luatex for documentation

2022-11-21 Thread Luca Fascione
Sorry, luatex is like 10yrs old, what's the need for xetex again? Maybe I could justify pdftex (I really don't quite see it, but maybe) but xetex seems just arbitrary... Or do you mean for a transition period? What's the oldest system that this Lilypond would be used on? What's the youngest

Re: Prefer luatex for documentation

2022-11-21 Thread Luca Fascione
On Mon, 21 Nov 2022, 13:34 Jean Abou Samra, wrote: > > build problems are fixed by developers, not users, sometimes very > painfully, and using time that they could spend on other tasks. > If Werner's change breaks the build, surely he'll be the first one to argue it's on him to fix it

Re: Prefer luatex for documentation, Re: Prefer luatex for documentation

2022-11-21 Thread Luca Fascione
dling, it often makes sense to > replace `pdftex` with `xetex` or `luatex` since the latter two > programs usually produce *much* smaller PDF files. > > > Werner > > -- Luca Fascione

Re: Prefer luatex for documentation

2022-11-20 Thread Luca Fascione
moderately recent TeX distribution. Sorry for spreading misinformation L On Sun, Nov 20, 2022 at 6:28 AM Werner LEMBERG wrote: > > > Luatex is always available with modern tex distros (say at least 5 > > yrs probably more). In fact pdftex _is_ luatex... > > ??? Definitely not. > > > -- Luca Fascione

Re: Prefer luatex for documentation

2022-11-19 Thread Luca Fascione
Luatex is always available with modern tex distros (say at least 5 yrs probably more). In fact pdftex _is_ luatex... I feel texlive is a stable enough bet for people... L On Sat, 19 Nov 2022, 22:15 Jonas Hahnfeld via Discussions on LilyPond development, wrote: > On Sat, 2022-11-19 at 10:19

Re: procedure to check equality of list-elements

2022-11-06 Thread Luca Fascione
Good to know thanks Jean! L >

Re: procedure to check equality of list-elements

2022-11-06 Thread Luca Fascione
Note the detail that + a b c and eq? a b c don't do the exact same thing: + a b c is equivalent to (a + b) + c eq? a b c is equivalent to (a == b) && (b == c) The list form has short circuiting if I remember right (eq? bails out on the first false it finds), but I don't remember how evaluation

Re: Potential LSR licensing violations

2022-10-21 Thread Luca Fascione
On Fri, Oct 21, 2022 at 1:00 PM Jean Abou Samra wrote: > Le 20/10/2022 à 15:46, Luca Fascione a écrit : > > To be clear: the potential issue I see is when the score or some of > > the headers it includes are GPL licensed, of course. > > Now of course the boundary between

Re: Potential LSR licensing violations

2022-10-20 Thread Luca Fascione
On Thu, Oct 20, 2022 at 1:47 PM Jean Abou Samra wrote: > > Le 20/10/2022 12:59 CEST, Luca Fascione a écrit : > > I think having GPL content in the lsr is the least desirable in the long > term, because either folks using it won't notice, or they might find > themselves u

Re: Potential LSR licensing violations

2022-10-20 Thread Luca Fascione
On Thu, Oct 20, 2022 at 1:56 PM Luca Fascione wrote: > Hum. It seems to me this is greyer that what you say. > > gcc transforms program.c into a.out > > Your access to a.out gives you rights to access program.c > > s/gcc/lilypond/; s/program.c/score.ly/; s/a.out/out.pdf/;

Re: Potential LSR licensing violations

2022-10-20 Thread Luca Fascione
9 CEST, Luca Fascione a écrit : > > > > > > Or you remove it, or you reimplement it > > > Well yes. > > > > I think having GPL content in the lsr is the least desirable in the long > term, because either folks using it won't notice, or they might find >

Re: Potential LSR licensing violations

2022-10-20 Thread Luca Fascione
Or you remove it, or you reimplement it I think having GPL content in the lsr is the least desirable in the long term, because either folks using it won't notice, or they might find themselves unable or unwilling to use GPL as part of their content. I'm not clear what it means to have GPL source

Re: Potential LSR licensing violations

2022-10-20 Thread Luca Fascione
going, is it? One thing that seems certain to me is that doing nothing guarantees there will be no change. L -- Luca Fascione

Re: Potential LSR licensing violations

2022-10-20 Thread Luca Fascione
the project managers and owners to try and insulate the contributors from potential unpleasantness. I repeat my disclaimer: Although I have been part of extensive discussions on this topic, I am not a lawyer, and my words do not constitute legal advice. Luca -- Luca Fascione

Re: Potential LSR licensing violations

2022-10-20 Thread Luca Fascione
. Cee, and he hereby placed in the public domain". Disclaimer: Although I have been part of extensive discussions on this topic, I am not a lawyer, and my words do not constitute legal advice. L -- Luca Fascione

Re: MacOS release help

2022-10-18 Thread Luca Fascione
I agree strongly with this, yes On Tue, 18 Oct 2022, 18:14 Jean Abou Samra, wrote: > Le 18/10/2022 à 08:12, Alex Harker a écrit : > > > > > >> On 18 Oct 2022, at 00:05, Carl Sorensen > >> wrote: > >> > >> IMO, what we most want is an app bundle that can be easily relocated > >> anywhere and

Re: MacOS release help

2022-10-18 Thread Luca Fascione
Besides whereas Frescobaldi is a Lilypond editor (thereby requires is and depends on it), Lilypond is not a Frescobaldi compiler, they're not dependent in the other direction. So the Lilypond installer shouldn't know about Frescobaldi Further, a package with no GUI elements doesn't bump me at

Re: Replacing fixcc.py with clang-format?

2022-09-06 Thread Luca Fascione
Side thought: if your CPP code is complex, indenting it helps readability a lot, here's a goofy example #if CONDITION # define AMACRO 6 # include "some/file.h" #else # if WIN32 #include "something/else.h" # elif MACOSX #include "the/darwin/version.h" # endif #endif I haven't seen

Re: Fonts missing in development environment

2022-07-27 Thread Luca Fascione
for your system Cheers L On Wed, Jul 27, 2022 at 8:29 AM Luca Fascione wrote: > Hi Walter, > here's a couple more direct pointers for you: > > The TeX fonts (Gyre) will be in a place like > > .../texmf-dist/opentype/public/tex-gyre/texgyreschola-regular.otf > > the '

Re: Fonts missing in development environment

2022-07-27 Thread Luca Fascione
://gitlab.com/lilypond/lilypond/-/blob/master/docker/base/Dockerfile.ubuntu-18.04 > > The build passes with it everyday, so it’s guaranteed to work. > > Either you use Docker, or you look at the list of packages it installs and > mimick it. > > Best, > Jean > > -- Luca Fascione

Re: Should we be touching goops?

2022-06-05 Thread Luca Fascione
On Sun, 5 Jun 2022, 17:39 David Kastrup, wrote: > Luca Fascione writes: > > > Oh yes absolutely, the growth is normally much slower than worse case > > unless the addends come from really weird-ass distributions, no doubt. > > Round to even helps a lot with that > &

Re: Should we be touching goops?

2022-06-05 Thread Luca Fascione
5 Jun 2022, 16:42 David Kastrup, wrote: > Luca Fascione writes: > > > On Sun, Jun 5, 2022 at 2:12 PM Jean Abou Samra > wrote: > > > >> As David already said, the part of LilyPond we're discussing is using > >> rationals. Furthermore, (a + b) + c being c

Re: Should we be touching goops?

2022-06-05 Thread Luca Fascione
out it causes significant savings. The > order of the most worthy optimizations is more high-level. > Yes, that'd be my expectation too. I think we all agree that these are good things in > any software projects. The question is whether a > given change will contribute enough to the

Re: Should we be touching goops?

2022-06-05 Thread Luca Fascione
as possible, it seems it's good that decision are carefully analyzed, so we keep the thing as a whole cleaner and easier to grow. I won't hide that I enjoy discussing design matters in Computer Science :-) L -- Luca Fascione

Re: Should we be touching goops?

2022-06-04 Thread Luca Fascione
to you? Cheers L -- Luca Fascione

Re: Should we be touching goops?

2022-06-04 Thread Luca Fascione
s. Leaving it to the compiler to find bugs for you is table stakes, it'll only find the easy stuff anyways. That should be your assumed starting point, not your goal: your goal is attending to the community that does what's hard, so that you make it less hard. HTH, L [1] https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong -- Luca Fascione

Re: Nested segno and volta repeats

2022-05-29 Thread Luca Fascione
Oh yes. I was taught aaba as well, definitely. Sorry, somehow I heard you were saying you'd read it aab, you see L On Sun, 29 May 2022, 13:33 Thomas Morley, wrote: > Am So., 29. Mai 2022 um 13:25 Uhr schrieb Luca Fascione < > l.fasci...@gmail.com>: > > > > What

Re: Nested segno and volta repeats

2022-05-29 Thread Luca Fascione
What do you mean Thomas? When the sheet clearly indicates DC al Fine (Da Capo, from the beginning) why would it be normal to ignore such an explicit direction? I wasn't aware of \repeat segno, neat thing, I've always had to do it by hand with cadenza trickeries... L On Sun, 29 May 2022, 10:45

Re: PATCHES - Countdown to May 26

2022-05-25 Thread Luca Fascione
to download a Python > > 3.10.4 from the Microsoft Store, onto a tablet running Win 10. > > > > Yes, the script requires the requests package, which > is not part of the Python standard library. This > should probably do: > > python -m pip install --user requests > > Jean > > > > -- Luca Fascione

Re: RFC on MR 1368

2022-05-25 Thread Luca Fascione
There! Thanks Aaron! L On Wed, 25 May 2022, 15:34 Aaron Hill, wrote: > On 2022-05-25 1:31 am, Luca Fascione wrote: > > (*) is there really no way to cross reference/link a commit comment > > from > > gitlab? gah. > > The post's relative time (e.g. "9 hours ago&

Re: RFC on MR 1368

2022-05-25 Thread Luca Fascione
ion where to > > add kerning data. I want to hear more opinions whether I should go > > 'route one' (which I prefer) or 'route two' (which Jonas prefers). > > > > Please have a look at MR 1368 > > > > https://gitlab.com/lilypond/lilypond/-/merge_requests/1368 > > > > and chime in. > > > > > > Werner > > > > > -- > Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen > > -- Luca Fascione

Re: Guile 3.0

2022-05-23 Thread Luca Fascione
noying for maintainers and CI, both of which I completely agree would be undesirable burdens. Cheers, L -- Luca Fascione

Re: Guile 3.0

2022-05-23 Thread Luca Fascione
This also makes a lot of sense to me, yes. L On Mon, 23 May 2022, 13:12 Jean Abou Samra, wrote: > > > Le 22/05/2022 à 21:52, Luca Fascione a écrit : > > > > On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld wrote: > > > > On Sun, 2022-05-22 at 20:14 +0200,

Re: Guile 3.0

2022-05-22 Thread Luca Fascione
On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld wrote: > On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote: > > So at the cost of rocking the cage a bit hard, I came asking the > > uncomfortable question: > > what would happen if (for this unique circumstance) we'd

Re: Guile 3.0

2022-05-22 Thread Luca Fascione
rue current, but we'd have to patch it, then again we'd be in a position where we _can_ patch it. So at the cost of rocking the cage a bit hard, I came asking the uncomfortable question: what would happen if (for this unique circumstance) we'd do what one would normally consider poor practice? L -- Luca Fascione

Re: Guile 3.0

2022-05-22 Thread Luca Fascione
etely? > > Current LilyPond master works with Guile 3.0. > > That's essentially all. I wasn't sure of that from the discussion and > from what I remembered from previous exchanges. > > > Do you want to add it to the CI? > > I am afraid that I am not tracking the development of Guile and the CI > resources of LilyPond well enough to venture any opinion that would be > more qualified than that of the current developers. > > -- > David Kastrup > > -- Luca Fascione

Re: Building lilypond on osx

2022-05-22 Thread Luca Fascione
, wrote: > Le 21/05/2022 à 07:49, Luca Fascione a écrit : > > I do follow the rationale for shipping one of the sets, what I'm > > confused about is why _both_, they're the same font set, afaiu > > (semantically, at least) > > > > Cf. > > commit 500febd2a5fe0ebdf0

Re: Point an Click & emacs

2022-05-22 Thread Luca Fascione
Maybe we could see if we can rope Immanuel to contribute a short segment to the user docs? L On Sun, 22 May 2022, 14:17 Jean Abou Samra, wrote: > Le 21/05/2022 à 22:38, Luca Fascione a écrit : > > Jean, I think this is a BWV1079... > > > :-) > > If the goal is t

Re: Point an Click & emacs

2022-05-21 Thread Luca Fascione
>(forward-line (1- line)) > >(forward-char pos > > > > > > (setq pdf-links-browse-uri-function > 'lilypond-pdf-links-browse-uri-function) > > 3. Open a lilypond generated pdf with \PointAndClickOn and click away. > > > > The code might need some refining but it does work here quite well. > > Immanuel > > > Hello, > > What kind of answer to this post do you await? > > Best, > Jean > > > -- Luca Fascione

Re: Building lilypond on osx

2022-05-20 Thread Luca Fascione
On Fri, May 20, 2022 at 4:31 PM Jonas Hahnfeld wrote: > On Thu, 2022-05-19 at 21:50 +0200, Luca Fascione wrote: > > So I can rely on the build system capturing the resolved path to > > bison during configure, like it would for CXX/CXXFLAGS? > > [...] you can s

Re: Building lilypond on osx

2022-05-19 Thread Luca Fascione
18:18 /usr/local/opt/guile@2 -> ../Cellar/guile@2/2.2.7_1 lrwxr-xr-x 1 x x 21 Feb 27 18:37 /usr/local/opt/guile@3 -> ../Cellar/guile/3.0.8 ) Where is the testing/detection for Guile set up, roughly? Thanks again, L -- Luca Fascione

Building lilypond on osx

2022-05-19 Thread Luca Fascione
to pass to configure I was wondering what the recommended approach is to tell the current build system to use (for example) /usr/local/Cellar/bison/3.8.2/bin/bison in lieu of /usr/bin/bison (I also need to repoint flex and maybe gettext, gettext is strange) Thanks for your help Luca -- Luca

Re: GDB giving immediate segfault on LilyPond startup?

2022-05-18 Thread Luca Fascione
On Wed, May 18, 2022 at 9:59 PM Jean Abou Samra wrote: > Le 18/05/2022 à 13:54, Luca Fascione a écrit : > > > > Quoting from that page: > > [...] > > The collector will call abort if the signal > > had another cause, and there was not other han

Re: GDB giving immediate segfault on LilyPond startup?

2022-05-18 Thread Luca Fascione
; Hi, > > > > After upgrading to Ubuntu 22.04 LTS, I can no longer use GDB > > with LilyPond, although it runs fine outside of GDB. > > [...] > > > Thanks to private replies, I have learnt that this is apparently > expected, and it works to type "continue" when this segfault > appears. > > > -- Luca Fascione

Re: LSR and Documentation/snippets/new

2022-05-07 Thread Luca Fascione
Fwiw, I like it, there's all sorts of weird edge cases in there that on occasion are quite handy L On Sat, 7 May 2022, 11:45 Sebastiano Vigna, wrote: > > > On 7 May 2022, at 09:30, Jean Abou Samra wrote: > > > > - What is the LSR's bus factor? As far as I can see, 1, > > since while

Re: Quotes around \consists argument?

2022-04-25 Thread Luca Fascione
*understood, of course On Mon, 25 Apr 2022, 14:14 Luca Fascione, wrote: > Yes I underground that, I was meaning for person's mental parsers, it > helps that tokens (in an informal sense) always look the same > > L > > On Mon, 25 Apr 2022, 14:01 David Kastrup, wrote: > >

Re: Quotes around \consists argument?

2022-04-25 Thread Luca Fascione
Yes I underground that, I was meaning for person's mental parsers, it helps that tokens (in an informal sense) always look the same L On Mon, 25 Apr 2022, 14:01 David Kastrup, wrote: > Luca Fascione writes: > > > I think this is because it being an unquoted string (P

Re: Quotes around \consists argument?

2022-04-25 Thread Luca Fascione
rting barewords. L -- Luca Fascione Distinguished Engineer - Ray Tracing - NVIDIA

Re: C++ question on wrapper API for setting Guile fluids

2022-04-22 Thread Luca Fascione
On Thu, Apr 21, 2022 at 11:46 PM Jean Abou Samra wrote: > Well, the C++ and Scheme interfaces can feel different and idiomatic > in their respective languages as long as they share the same > underlying implementation. > I think this is a super important goal. In fact, I'd upgrade 'can' to

  1   2   >