lilypond-devel
[Top][All Lists]
Advanced

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

[PATCH] Fix 1477: Add (ly:suppress-warning...) to suppress expected warn


From: Reinhold Kainhofer
Subject: [PATCH] Fix 1477: Add (ly:suppress-warning...) to suppress expected warnings
Date: Sun, 18 Sep 2011 02:40:01 +0200
User-agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.0; i686; ; )

This patch adds (ly:suppress-warning ...) to suppress the given warnings from 
the output (i.e. if a regtest is supposed to trigger a warning):

http://codereview.appspot.com/5037046/

I have also updates some regtests as examples to suppress expected warnings.

Usage:
#(ly:suppress-warning (_ "unterminated tie"))
#(ly:suppress-warning (_ "Two simultaneous ~a events, junking this one") "key-
change")
#(ly:suppress-warning (_ "Previous ~a event here") "key-change")


Some issues:

1) Currently, I simply collect all suppressed warnings into a list and compare 
each warning to the suppressed strings (only the beginning of the real warning 
message, since the Input class will append the actual file contents, too). 
This approach has the disadvantage that we can't check if there is really a 
warning or not. 

A better approach might be to understand (ly:suppress-warning ...) for just 
one warning and remove a matched string from the list of suppressed warnings. 
If there are two identical warnings expected, simply call ly:suppress-warning  
twice with the same message.
With that approach, one can then check at the end of a file if each expected 
warning was really triggered or not. In the later case, we could print a 
warning about missing warnings.

2) The suppressed warnings are currently NOT reset after each file. What's the 
best way to reset them after each file? Explicitly call the clear suppressions 
function in the loop lilypond-all in lily.scm? Or is there some better hook 
for end-of-single-file cleanup?

3) Warnings are translated, so ly:suppress-warning also needs to be called on 
the translated message, so it should be used as:
  #(ly:suppress-warning (_ "message text") args)

However, many warnings are called from C++ and use the C sprintf syntax (%s 
rather than ~a placeholder). suppress-warning on the other hand is a function 
with SCM arguments, so we don't have immediate access to _f. My idea was to 
add a second function
  #(ly:suppress-c-warning "Two simultaneous %s events, junking this one" "key-
change")

That function does not get a translated string, but the original English 
sprintf format string, calls ly_scm2string and then _f to translate it in the 
warn-scheme.cc file. Unfortunately, I don't know an easy way to handle the 
optional arguments. As the arguments can have any type, the only way I can 
think of is like the following (ugly) pseudocode:

string msg;
if (argument_count == 0) {
  msg = _ (str);
} else if (argument_count == 1) {
  if (scm_is_string (arg1)) {
    msg = _f (str, ly_scm2string (arg1));
  } else if (scm_is_integer (arg1)) {
    msg = _f (str, robust_scm2int (arg1));
  } else if ....
    ...
} else if (argument_count == 2) {
  // Here we have quadratically many different type combinations!
  if (scm_is_string (arg1)) {
    if (scm_is_string (arg2)) {
      // format string - string
    } else if (scm_is_.... (arg2) {
      ...
    } else ...
      ..
  } else if (scm_is_integer (arg1)) {
    ....
  } 
} else if (argument_count == 3) {
  // Doesn't really make sense effort-wise to handle this case!
}

That's of course insane, but due to the un-typedness of guile, I see no other 
way to pass translate the C++ format string and the arguments from a scheme 
and insert the correct arguments then in C++...

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org



reply via email to

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