Re: On Frescobaldi
Hi David, Was meant to be offlist to Urs, but never mind. Frescobaldi always used to update just fine, with no manual intervention. The behaviour has changed, and it si only when you have two separate files involved. It's only been happening since say, Ubuntu 18.04 or so (but don't ask me to certify that). We went through this on the list before, to no avail. I am using the popppler view in F. not xpdf, although I understand the poppler code is based on xpdf. Andrew On Mon, 22 Apr 2019 at 13:32, David Wright wrote: > > I've no idea if this is relevant, but one of my working practices > depends on the fact that xpdf does not update the display when the > underlying PDF changes unless you either (a) type r in the window > or (b) change page, zoom factor, or anything that requires consulting > the PDF file again. > > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: On Frescobaldi
On Mon 22 Apr 2019 at 12:31:54 (+1000), Andrew Bernard wrote: > Dear Urs, > > On a different tack altogether, with the oll work, you have a usage file > and a module.ily, so two files. In my Frescobaldi 3 on a brand new Ubuntu > 19 installation (the latest release as of last week) it still shows the > problem I mentioned a while ago where the output PDF is not updated after > changes. This slowed me down a lot as I could not understand why my outline > list code was not working. Reverting to my tried and true Gvim and PDF > point and click works perfectly. Previously I worked around this by > putting all the work in one file. > > I'd like to file a bug report on, this, but I can't see a simple way to > reprpduce the problem. > > Sounds like a really hard issue to me. I am very sorry to tell you that > with the huge slowdown I see in my complex scores - metioned in the past as > you know - and with this non-updating issue, I myself can no longer use > Frescobaldi. it's a shame, as it is such a brilliant development > environment. > > Hmm. What to do? I would not know how to solve this, even though I know > Python very well. > > [I wonder if this is some sort of a buig with the PDF display not updating, > perhaps some poppler file modification time issue?] I've no idea if this is relevant, but one of my working practices depends on the fact that xpdf does not update the display when the underlying PDF changes unless you either (a) type r in the window or (b) change page, zoom factor, or anything that requires consulting the PDF file again. Cheers, David. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
On Frescobaldi
Dear Urs, On a different tack altogether, with the oll work, you have a usage file and a module.ily, so two files. In my Frescobaldi 3 on a brand new Ubuntu 19 installation (the latest release as of last week) it still shows the problem I mentioned a while ago where the output PDF is not updated after changes. This slowed me down a lot as I could not understand why my outline list code was not working. Reverting to my tried and true Gvim and PDF point and click works perfectly. Previously I worked around this by putting all the work in one file. I'd like to file a bug report on, this, but I can't see a simple way to reprpduce the problem. Sounds like a really hard issue to me. I am very sorry to tell you that with the huge slowdown I see in my complex scores - metioned in the past as you know - and with this non-updating issue, I myself can no longer use Frescobaldi. it's a shame, as it is such a brilliant development environment. Hmm. What to do? I would not know how to solve this, even though I know Python very well. [I wonder if this is some sort of a buig with the PDF display not updating, perhaps some poppler file modification time issue?] a ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: scheme-question about accumulating lists of lists
Hi Thomas, > ... > Thanks again! You're welcome. I used 'funny' (weird) procedure and variable names, but if the procedure is to be exposed to your users, and with the objective of making it simple to use, read and maintain, as you described later in your answer, you could write it as - using (ice-9 match): (define (lp-map proc lp-list) "Apply PROC to each element of LP-LIST. An LP-LIST must be a list of lists of items - (cons '(a b c) (cons '(d e f) (cons '(g h i) '( - or a list of lists of items plus a pair of list of items - (cons '(a b c) (cons '(d e f) '(g h i))). Each sublist item must statisfy (not (pair? item)). The result(s) of the procedure applications are saved and returned in a list." (let loop ((lp-list lp-list) (result '())) (match lp-list ((elt . rest) (if (pair? elt) (loop rest (cons (proc elt) result)) (reverse! (cons (proc lp-list) result (() (reverse! result) This version also matches the built-in map argument order. If you need an lp-map that accepts more then an lp-list, let me know: "lp-map proc lp-list1 lp-list2 ..." Now, it is worth pointing that if the above code is ok, it is not very robust: it strongly depends on well formed LP-LIST, and will fail otherwise, as (not very well) described in the procedure comment, consider this example: (define bad-lp-list (cons '(a b c) (cons '(1 2 3) '((x) y z scheme@(guile-user)> (lp-map car bad-lp-list) $2 = (a 1 x y) > I think you're wrong. > It's not in the guile-1.8-docs, but below worked: Oh, great. > ... > Among keeping things simple is the attempt to use very little > additional guile-modules. I am all in favor of simplicity (who would not?), though I don't agree that not using additional Guile modules does (always) help to achieve that goal. > Whether 'pattern matching' will be useful to hide complexity to make > life easier for our users or whether it adds an abstraction layer, > which would make it even harder for users to write their own > guile-code, I can't judge currently. Ok, I believe it does help a lot, maybe even more scheme beginners actually, and so do our maintainers, here is an extract of the (latest) manual, section "6.6.8 Pairs": ... Since a very common operation in Scheme programs is to access the car of a car of a pair, or the car of the cdr of a pair, etc., the procedures called caar, cadr and so on are also predefined. However, using these procedures is often detrimental to readability, and error-prone. Thus, accessing the contents of a list is usually better achieved using pattern matching techniques (see Pattern Matching). ... But of course do as you wish, there is nothing 'wrong' writing good scheme code using 'old' destructuring techniques, but it will, always imo, be more difficult to read and maintain. David. pgpWdxXCqa_hL.pgp Description: OpenPGP digital signature ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Edition Engraver master vs refactor override branch: changing bound-details
Hi all, long time since I posted here, hope you all have been well!
While using the Edition Engraver today I noticed that the following
override works in the old refactor override branch, while on the current
master it prints a textless spanner and a warning:
\version "2.19.80"
\include "oll-core/package.ily"\loadPackage edition-engraver
\consistToContexts #edition-engraver Voice\addEdition test
\editionMod test 1 0 Voice.A {
\override TextSpanner.bound-details.left.text = "span this"
<>\startTextSpan}\editionMod test 2 3/4 Voice.A \stopTextSpan
\new Staff {
\new Voice \relative {
c' d e f g a b c
}
}
Said warning is
warning: type check for `bound-details' failed; value `"span this"' must be
of type `list'
In the current master I could set this like this:
\override TextSpanner.bound-details = #'((left . ((text . "span this"
but this has the undesirable effect of resetting all the other settings of
the bound-details alist
Without having been able to dive down into the code, this looks like a
simple issue with type checking, but I realize this may have been
implemented this way to circumvent other problems.
So, how can I achieve this with the current master? Or should I go back to
using the earlier branch until this is solved?
Thanks for your help,
Stéfano
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: scheme-question about accumulating lists of lists
Am So., 21. Apr. 2019 um 02:34 Uhr schrieb David Pirotte : > > Hi Thomas, > > > ... > > Thanks pointing me to this possibility, in my use-case I then could do: > > (define (p) (cons '(1 2 3) '(4 5 6))) > > (define l1 '(a b c)) > > (define l2 '(x y z)) > > (cons* l1 l2 (car (p)) (cdr (p)) '()) > > => > > ((a b c) (x y z) (1 2 3) (4 5 6)) > > Yes, if you can (you mentioned the code was not yours and couldn't be > changed ...) that would be a lot cleaner, imo, and will let you use 'built-in' > scheme, guile and srfi-1 procedures that work on lists, as mentioned in my > first > answer. Yep, I can't change the 'consing' built-in procedure, (I tried to patch it but it gives an unexpected error at on first sight absolutely unrelated location, should investigate ...). > > > (define (blue-walk blue proc) > > > (let loop ((blue blue) > > > (result '())) > > > (match blue > > > ((a . rest) > > >(if (pair? a) > > >(loop rest > > > (cons (proc a) result)) > > >(reverse! (cons (proc (cons a rest)) > > >result > > > (() > > >(reverse! result) > > In the above code, I am performing an extra and therefore useless cons, here > is a correction (not a bug, but one should _always_ avoid consing whenever > possible): > > (define (blue-walk blue proc) > (let loop ((blue blue) > (result '())) > (match blue > ((a . rest) >(if (pair? a) >(loop rest > (cons (proc a) result)) > -> (reverse! (cons (proc blue) >result > (() >(reverse! result) Thanks again! > > My guile-knowledge is mostly limited to what LilyPond needs. > > As far as I can tell (ice-9 match) isn't used in our source. > > So I need to study your `blue-walk´ from scratch. > > In this particular case, match is 'convenient', but not really indispensable > - and I > see now it's not in guile-1.8. I think you're wrong. It's not in the guile-1.8-docs, but below worked: ~$ guile guile> (version) "1.8.8" guile> (use-modules (ice-9 match)) guile> (define blue (cons '(a b c) (cons '(1 2 3) '(x y z guile> (define fox (cons '(a b c) (cons '(1 2 3) (cons '(x y z) '() guile> (define (blue-walk blue proc) (let loop ((blue blue) (result '())) (match blue ((a . rest) (if (pair? a) (loop rest (cons (proc a) result)) (reverse! (cons (proc blue) result (() (reverse! result) guile> (blue-walk blue cdr) ((b c) (2 3) (y z)) guile> (blue-walk fox cdr) ((b c) (2 3) (y z)) guile> > Here is a version that does not need match (though > you might not even need it if you can (cons* a b c ... '()) as you mentioned > here > above): > > (define (fox-walk fox proc) > (let loop ((fox fox) > (result '())) > (if (null? fox) > (reverse! result) > (let ((a (car fox))) > (if (pair? a) > (loop (cdr fox) > (cons (proc a) result)) > (reverse! (cons (proc fox) > result))) > > Now, if/when you (lily devs I mean, not just you of course) plan to use 2.0, > 2.2 or > 3.0 (2.9.1 is it is ...) [*], it is highly recommended to use match > 'everywhere' > you'd use car, cdr, cadr ... but not only, look at the "7.7 Pattern Matching" > section of a recent manual for more ... the code is/becomes a lot more > readable, > and match is not only extremely powerful, but also extremely fast (no > figures, but > it's being said there is no penalty compared to using 'older' destructuring > techniques ... (referred to, among guilers, 'the car cdr hell' :)) Other devs may drop in here, but this is my very basic understanding about LilyPond/guile-relationship: LilyPond uses guile as it's extending language. Among LilyPond users there are musicians with little or even no programming background up to experienced programmers with interests in type-setting music. (Actually I was one of those musicians with no programming background. Ok, probably one could say I had some ambitions.) To give the former the possibility to extend LilyPond with guile we try to keep things as simple as possible (it's sometimes scaring enough), give the users strong tools at hand which hide complexity, and do things in a modular way so they can be changed in detail without affecting other stuff, if possible. David Kastrup did wagonloads of work in this regard (and the C++ layer as well). Among keeping things simple is the attempt to use very little additional guile-modules. So far my general basic understanding. Whether 'pattern matching' will be useful to hide complexity to make life easier for our users or whether it adds an abstraction layer, which would make it even harder for users to write their own guile-code, I can't judge currently.
Re: Multi non static substition
"E Appeldoorn" writes:
> I have defined this function in an include.ly file
>
> MyMarkup = {
> \markup
> \override #'(adjust-x-pos . 1.0)
>\override #'(adjust-length . 1.5)
> }
Unlikely.
> How can I extend that example so I can use one call to the function
> passing both pos and length variable in the callout. Something like:
>
> \MyMarkup #1.0 #1.5
Before extending that example, make it work in the first place. It's
not clear to me what you want here.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Multi non static substition
Andrew Bernard writes: > Hi Ursus, > > Apologies, you most likely want to define a new markup function. Markup command. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
