lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Regtest for issue 5181


From: Thomas Morley
Subject: Re: Regtest for issue 5181
Date: Sun, 24 Sep 2017 00:19:26 +0200

2017-09-23 18:17 GMT+02:00 David Kastrup <address@hidden>:
> David Kastrup <address@hidden> writes:
>
>> Thomas Morley <address@hidden> writes:

>>> Up to now I've only a vage impression what
>>> 'parse-lily-and-compute-lily-string' and #(read-hash-extend ...) does.
>>> I'll currently not dive deeper into it until forced. ;)
>>
>>  -- Scheme Procedure: read-hash-extend chr proc
>>  -- C Function: scm_read_hash_extend (chr, proc)
>>      Install the procedure PROC for reading expressions starting with
>>      the character sequence ‘#’ and CHR.  PROC will be called with two
>>      arguments: the character CHR and the port to read further data
>>      from.  The object returned will be the return value of ‘read’.
>>      Passing ‘#f’ for PROC will remove a previous setting.
>>
>> Basically what is done with those does a similar job as
>> scm/parser-ly-from-scheme.scm does for #{ ... #} in Scheme, just for #[
>> ... #].  Also it doesn't bother to cater for closures or sensible
>> error/expression file locations.

So far I figured already.
I meant more some details.
What exactly does the loop?
Why a quasiquote (let ...)?

Those questions came to my mind. Though, I didn't think it was worth
to research them.

>
> Also it's stupid here: the whole idea for display-lily-test was to
> compare input string and output expression, and the input string is not
> really of interest for _this_ check, so the whole complicated deal does
> not pay off.  I'll try to see whether I can make do without it.
>
> --
> David Kastrup

Meanwhile I convinced myself that a regtest with no pdf-output is the
right one here.
We have others. Ofcourse for midi, but also display-lily-tests.ly (as
mentioned already) and general-scheme-bindings.ly, probably more, I
didn't look through all regression-tests.

I tried to simplify your suggestion:

pitch = c'
note = c'4
chord = <c' g'>
lyr = \lyricmode { foo }

#(define lst
;; create a list with lily-code, variable-call, possible post-event
and expected equality
;; first three need to be strings, last is a boolean
'(
  ("c'4" "\\note" "--" #f)
  ("c-\\single \\slurUp (" "c \\single \\slurUp (" "-1" #f)
  ("<c' g'>" "\\chord" "-1" #f)
  ("{c'4-1}" "{ \\note -1 }" "" #t)
  ("{ \\lyricmode { foo -- } }" "\\lyricmode { \\lyr -- }" "" #t)
  ))

foo =
#(define-void-function (ls)(list?)
(let* ((cases
         (map
           (lambda (arg)
             (string-trim-both
                (with-output-to-string
                  (lambda ()
                   (ly:parse-string-expression
                     (ly:parser-clone)
                     (format #f "\\displayLilyMusic ~a ~a"
                       arg (third ls))
                     )))))
           (take ls 2)))
        (same? (string=? (car cases) (cadr cases))))
  (cond ;; all working
        ((and same? (last ls))
         (ly:message "expressions are equal"))

        ;; expressions are equal, but equality is unexpected
        ((and same? (not (last ls)))
         (ly:input-warning (*location*)
           "Unexpected equality for ~a and ~a"
             (car cases) (cadr cases)))

        ;; expressions are not equal, but equality was expected
        ;; possible bug
        ((and (not same?) (last ls))
         (ly:warning
           "BUG for ~a and ~a possible"
             (car cases) (cadr cases)))

        (else
         (ly:message "expressions are not equal as expected")))))

$(for-each foo lst)

Manually creating 'lst' is *aargh*, though.
Maybe I've a better idea tomorrow, but I thought I should post the idea.


Cheers,
  Harm



reply via email to

[Prev in Thread] Current Thread [Next in Thread]