bug-lilypond
[Top][All Lists]
Advanced

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

Re: New read/eval Scheme syntax inconsistent in handling existing code


From: David Kastrup
Subject: Re: New read/eval Scheme syntax inconsistent in handling existing code
Date: Fri, 02 Dec 2011 01:05:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

Valentin Villenave <address@hidden> writes:

> On Thu, Dec 1, 2011 at 9:57 PM, Valentin Villenave
> <address@hidden> wrote:
>> Unfortunately, it does not.
>
> [Oops, sent it a bit too soon.]
>
>
> This used to work, for instance:
>
>
> myvar = { b'4 }
>
> #(display "this needs to be here")
>
> #(eval-string "(define-public myvar #{ a'2 #} )" )
>
> \new Staff \myvar
>
> ... And now it doesn't. For some reason it produces a "wrong type"
> error.

The reason is that eval-string in Guile does not set
port-line/port-filename to sensible values and I use them for making
sensible error messages actually pointing to the source of the error.

> No matter whether you use $ or #. (So the breakage seems unrelated,
> but it did happen at the very time the syntax changed. And in proper
> REPL, non-embedded guile it does work.)

Of course it doesn't since #{ #} would not be defined.

>>> It looks like you complain that something that did not work before now
>>> can be kept from working when you rewrite it in a special discouraged
>>> and completely unnecessary way that is documented to work just as badly
>>> as # did before my changes.
>>> If that's the worst effect on your scores you can come up with, I can
>>> live with that.
>
> Well, as I said it *does* break all of my scores.
> And I certainly can understand why such ugly things are discouraged,
> but with **my** limited coding abilities I couldn't find any other
> (more proper) way.

Should be quite easier now.  Anyway, we are talking about a
_development_ version.  The changes _all_ passed _all_ regression
tests.  If you want to avoid breakage in development versions, you have
two options:

a) contribute regression tests for your use cases
b) check out proposed patches touching your unusual work patterns before
   they reach the end of countdown
There is also
c) make a proper bug report once things break for you

Personally, I consider option
d) Try to discredit work being done with ominous postings missing useful
   information

not helpful.  I understand that you are pissed off when your scores and
work patterns (and apparently nobody else's) stop working.  You know how
to keep this from happening in future.  If you are doing things nobody
else does, it is your responsibility to commit appropriate regtests
and/or participate in testing.  Trying to piss off others as
compensatory treatment is not likely to create conditions making either
yourself or others happier in the long run.

I pushed a fix to staging that just skips location data when Guile does
not set it to useful values or types.  You don't need the ugly "display"
in your code anymore, by the way.

Could you try making your next bug reports less sensational and with
useful examples from the start?

I quote the starting headline and text:

    Subject: New read/eval Scheme syntax inconsistent in handling
             existing code

    Greetings everybody,

    David's new code with #/$(scheme) styles does offer a lot of exciting
    possibilities... but it is also hugely disruptive when it comes to
    existing code! Consider for instance the following:

[...]

    Thoughts?

So you are making an appeal to "everybody" to join into a campaign
against "inconsistent" handling of "existing code", due to the bad
disruptive things David does.  Why doesn't that existing code exist in
the regtests?

Valentin, bugs will happen.  Using eval-string is actually bypassing the
normal interplay of Scheme and Lilypond interpreters, and it is quite
likely that there are much better ways for doing what you are doing.
Since Guile does not bother providing useful location data, the error
messages (when errors occur) will be close to useless.  They _always_
were close to useless before the last batch of changes causing your
problem.  They aren't anymore, but that will not help you when using
eval-string since eval-string does not set them to useful values for
some unfathomable reason.  Yes, this caught me on the wrong foot.

What you complain about here in that indirect manner were just bugs.
Those should certainly be reported and fixed.  But I am also currently
working on changes that will indeed be more disruptive to existing code
relying on less than pretty or comprehensible behavior of Lilypond.
They _will_ break existing complex code at the Scheme level even after
all bugs are shaken out.  And for good reason.  And no convert-ly magic
will be able to fix that.  Those changes will come with changes in the
regtests and in Lilypond's Scheme code because of that.

So be sure to participate in the feedback loop in a timely and
productive manner.

I am working on turning Lilypond into an environment working in a way
that makes sense, is predictable, comfortable and powerful.  So far, I
have been able to do this with minimal disruption of existing code if we
disregard bugs slipping through our testing infrastructure.  But that's
not going to be the case every time.  I am pretty sure that you'll
appreciate most changes for ongoing work and wish that they had been
done earlier.  But if you really need complex documents meddling with
Lilypond internals to stay working without change, there is no real
option except keeping old versions of Lilypond around.

-- 
David Kastrup



reply via email to

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