On Fri, Dec 2, 2011 at 10:14 AM, David Kastrup <d...@gnu.org> wrote: > The port-line/port-filename values that it had when reading a literal > string. Of course, this approach would not work when we are talking > about a constructed string.
[Which precisely happens to be what I'm using eval-line for in my framework, so I guess this point would be moot anyway.] > Upgrade, rinse and repeat. Up to now, your problems have exclusively > been unrelated to the nature of the patches, but rather because of bugs > slipping through the current regtest net that could be fixed with few > lines of code. I'm glad to read that. Indeed, the new staging branch compiles my scores (at least, the ones I've tested so far) with virtually no modification needed. (Which doesn't mean I don't need to clean the code in the long run, but that's still reassuring for now.) > "Consider for instance the following" tries to present the bug as > endemic and a systematic part of the changes. You don't ask for a fix, > but ask for "thoughts". Not me as the author of the changes, but > everybody else. Well, this *is* the _bug_ list. I thought that the mere fact that I was posting _here_, with a minimal example, thusly made it what we call a "bug report". I'm sorry if that wasn't clear. And, yes, I had every reason to suspect that the hackish code I used had suddenly be made unsupported because of the new, improved Scheme evaluation. Which is why I was asking for "thoughts" and not demanding that we reverted any of it. And I suspected there were more than one issue at stake (which turned out to be right), hence the "for instance". > Now get yourself out of the "lambs to the slaughter" mind frame > and report bugs as bugs. [...] > Sigh. There is no "new behavior". There _was_ a bug. There is nothing > to "work around" here. Again: "this" is the _bug_ list. I only post here whenever they're an unwanted behavior (in this particular case, I just wasn't sure whether it was unwanted by only me.) I'm sorry that not using the word "bug", and using the word "disruptive", made you regard this as a call for drama. -- and if so, I'm grateful that you addressed it anyway. > Once you get into the habit of treating bugs like bugs instead of a > personal attack on your code base, you might change your mind. At least > in this case. I have reported hundreds of bugs over the years (there was even a time where I was in a "one bug a day" rush). So, there hasn't been any trauma on my end -- just a major change that I needed to get accustomed to, and that had side-effects that I wasn't sure were intentional or not. > Why do you want delayed evaluation in Guile? Can you put together an > example demonstrating the technique you employ here? Not just something > demonstrating a bug (which should be gone by now) but rather showing > what you use this for? Yes, it's on my todo-list alongside with the regtests I'll suggest adding. > The use of "eval-string" does not just stick out like a sore thumb in > Lilypond. It would also be considered really bad style in most Scheme > programs. I hear you. I used defmacro previously, but that wouldn't work any longer with the new define-music-function syntax (a "disruption" which I didn't nag you about, since I was able to cope with it by using hacks). > Not all that tough, I suppose. Music functions will have less need to > "unpeal" their arguments, but that also means that there is a larger > variety of input they might need to deal with. "Everything is an > EventChord" is what I am trying to get rid of right now. Interesting. I'll have to keep up with it. > There is not much of a point thinking about 2-month periods. Either the > changes are due to bugs, in which case the bugs will still be there > after 2 months if you did not bother reporting them. Or they will be > permanent, in which case you can wait all you want. Hence the need for us to be having this discussion (and the couple of regtests we've been discussing) now rather than in months. Cheers, Valentin. _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
