Re: Email from Phil's patchy
Phil Holmes m...@philholmes.net writes: Sorry, Marc. To do this completely, you will need to add the changed file to snippets/new. The files in snippets get over-written when we import from the LSR, so this update would be lost. However, to make current git compile, you do also need to keep this change in snippets. I realise this isn't completely straightforward, but that's the way it is... I repeat: why change all the function names of functions with a public interface in the first place when they have the same functionality? Without a convert-ly rule, this will break user code. I cited some user quote on the mailing list that will also break. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Email from Phil's patchy
Am 29.07.2012 08:12, schrieb David Kastrup: Phil Holmes m...@philholmes.net writes: Sorry, Marc. To do this completely, you will need to add the changed file to snippets/new. The files in snippets get over-written when we import from the LSR, so this update would be lost. However, to make current git compile, you do also need to keep this change in snippets. I realise this isn't completely straightforward, but that's the way it is... I repeat: why change all the function names of functions with a public interface in the first place when they have the same functionality? Without a convert-ly rule, this will break user code. I cited some user quote on the mailing list that will also break. I misunderstood the ly: convention in function names. I renamed the concerned definitions and am currently doing make and make doc. The changes in Documentation/snippets were reverted. If make doc succeeds, I'll upload another patch. Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Email from Phil's patchy
Am 29.07.2012 10:10, schrieb David Kastrup: Marc Hohl m...@hohlart.de writes: Am 29.07.2012 08:12, schrieb David Kastrup: Phil Holmes m...@philholmes.net writes: Sorry, Marc. To do this completely, you will need to add the changed file to snippets/new. The files in snippets get over-written when we import from the LSR, so this update would be lost. However, to make current git compile, you do also need to keep this change in snippets. I realise this isn't completely straightforward, but that's the way it is... I repeat: why change all the function names of functions with a public interface in the first place when they have the same functionality? Without a convert-ly rule, this will break user code. I cited some user quote on the mailing list that will also break. I misunderstood the ly: convention in function names. It is used inconsistently. It is _required_ (or possibly was at some point of time, I don't quite remember) for LY_DEFINE. At a point of time where pretty much everything concerning LilyPond internal operation was done in C++, it may have had some correlation with functionality and/or mangling. But there is really very little sense in us having predicates ly:music? as opposed to markup? since the user could care less what language some functionality is, or has been, implemented in, possibly at some point in history. Personally, I would think that pretty much everything that looks like a Scheme interface to a C++ callback (namely containing :: in its name) should likely have the ly: prefix to preserve some predictability, but it would appear that this train left station a long time ago. We also have the situation that we autoextract documentation from functions defined using LY_DEFINE into the manual (probably the main incentive to have LY_DEFINE) The same is not done for functions defined in Scheme as far as I can tell. But the functions we are talking about were defined with some *CALLBACK* macro, I think, and not documented anyway. So it is an inconsistent historical mess we are dealing with here. It would be nice to provide some guarantees, like everything starting with ly: has a documentation in the internals manual, but those guarantees should not be tied into the implementation language: that is a line irrelevant to the user. Somewhat more relevant would be don't expect to change this in mid-session or at all since other callers might have memoized the location or called it directly. However, LilyPond code memoizes a lot, never mind the ly: prefix. I renamed the concerned definitions and am currently doing make and make doc. The changes in Documentation/snippets were reverted. If make doc succeeds, I'll upload another patch. To me, I think for drop-in exported-function-by-function replacements, that is the sanest way to proceed since for the caller, nothing has changed. +1 But at one point of time, we need to put down some explicit policies here as well and come up with good guidelines users and developers can depend on. And implementation language is a terrible criterion for a user-visible distinction in interfaces. +1 In C, the equivalent would be to have to write extern FORTRAN not just in the respective headers of a library, but also for _every_ _single_ function call. Now function call prefixes in naming are not unusual, but they are ordered according to library, not according to implementation language. And I don't need yet_another_prefix if the function has been rewritten in assembly language. Now it is true that we probably did not have a formal discussion of this in any rate, and you are probably quite keeping with some sort of de-facto standard and are in the unlucky position of standing next when I am waking up to some problem wildly thrashing my arms. Sorry for that. No problem. I was a bit disappointed that this patch being into staging has to be reworked, but I assumed that make doc is covered within the make test-redo; make check cycle, and I was proven wrong. We'll likely need something better than a raving core programmer as a guideline. ;-) In the meantime, I consider it a good idea for drop-in replacements of public interfaces to keep the name, or the drop-in idea is no longer valid, meaning that it gets much harder to do comparisons of before/after when necessary, and we get a user-visible incompatibility that serves no discernible purpose. Meanwhile, make doc succeded. I had to insert a check for glyph = #f in bar-line::compound-barline, too, which was not covered before. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Email from Phil's patchy
Marc Hohl m...@hohlart.de writes: Am 29.07.2012 10:10, schrieb David Kastrup: Now it is true that we probably did not have a formal discussion of this in any rate, and you are probably quite keeping with some sort of de-facto standard and are in the unlucky position of standing next when I am waking up to some problem wildly thrashing my arms. Sorry for that. No problem. I was a bit disappointed that this patch being into staging has to be reworked, but I assumed that make doc is covered within the make test-redo; make check cycle, and I was proven wrong. make doc is really expensive. And the staging branch is our ultimate safety net (more often than not, patches gone through testing and review need rebasing before getting pushed, and we don't start a new test-patchy for that), intended to catch unexpected kinds of problem. Which this, in a way, was. Meanwhile, make doc succeded. I had to insert a check for glyph = #f in bar-line::compound-barline, too, which was not covered before. Well, it was more or less coincidence that made that problem turn up (which should really have been discussed and resolved in review in a perfect world), but if we are handed on a platter the chance to improve a previous choice including an example of why that would be a good idea, it would be a shame to waste it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Email from Phil's patchy
Am 29.07.2012 11:16, schrieb David Kastrup: Marc Hohl m...@hohlart.de writes: Am 29.07.2012 10:10, schrieb David Kastrup: Now it is true that we probably did not have a formal discussion of this in any rate, and you are probably quite keeping with some sort of de-facto standard and are in the unlucky position of standing next when I am waking up to some problem wildly thrashing my arms. Sorry for that. No problem. I was a bit disappointed that this patch being into staging has to be reworked, but I assumed that make doc is covered within the make test-redo; make check cycle, and I was proven wrong. make doc is really expensive. Yup. And the staging branch is our ultimate safety net (more often than not, patches gone through testing and review need rebasing before getting pushed, and we don't start a new test-patchy for that), intended to catch unexpected kinds of problem. Which this, in a way, was. Meanwhile, make doc succeded. I had to insert a check for glyph = #f in bar-line::compound-barline, too, which was not covered before. Well, it was more or less coincidence that made that problem turn up (which should really have been discussed and resolved in review in a perfect world), but if we are handed on a platter the chance to improve a previous choice including an example of why that would be a good idea, it would be a shame to waste it. At least I learned from this incident that doing a make doc after the tests are clean is not the worst option either. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Email from Phil's patchy
12:31:10 (UTC) Begin LilyPond compile, previous commit at 3573a92d92728dc8d6452e5cd3cfba73e49e6990 12:31:28 Merged staging, now at:65c53165ab3535a9186f501c9a8b454d07c82642 12:31:29Success:./autogen.sh --noconfigure 12:31:42Success:../configure --disable-optimising 12:31:51Success:nice make clean -j9 CPU_COUNT=9 -s 12:32:55Success:nice make -j9 CPU_COUNT=9 -s 12:34:47Success:nice make test -j9 CPU_COUNT=9 -s 12:37:51 *** FAILED BUILD *** nice make doc -j9 CPU_COUNT=9 -s Previous good commit: 3573a92d92728dc8d6452e5cd3cfba73e49e6990 Current broken commit: 65c53165ab3535a9186f501c9a8b454d07c82642 12:37:51 *** FAILED STEP *** merge from staging Failed runner: nice make doc -j9 CPU_COUNT=9 -s See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9--s.txt ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Email from Phil's patchy
philehol...@googlemail.com writes: 12:31:10 (UTC) Begin LilyPond compile, previous commit at 3573a92d92728dc8d6452e5cd3cfba73e49e6990 12:31:28 Merged staging, now at: 65c53165ab3535a9186f501c9a8b454d07c82642 12:31:29 Success:./autogen.sh --noconfigure 12:31:42 Success:../configure --disable-optimising 12:31:51 Success:nice make clean -j9 CPU_COUNT=9 -s 12:32:55 Success:nice make -j9 CPU_COUNT=9 -s 12:34:47 Success:nice make test -j9 CPU_COUNT=9 -s 12:37:51 *** FAILED BUILD *** nice make doc -j9 CPU_COUNT=9 -s Previous good commit: 3573a92d92728dc8d6452e5cd3cfba73e49e6990 Current broken commit: 65c53165ab3535a9186f501c9a8b454d07c82642 12:37:51 *** FAILED STEP *** merge from staging Failed runner: nice make doc -j9 CPU_COUNT=9 -s See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9--s.txt Ok, I'll be backing this out. If someone with horsepower can produce a relevant log file for the problem (possibly the one listed above is still around which might be a good start), this would likely be quite helpful. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Email from Phil's patchy
- Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Saturday, July 28, 2012 1:41 PM Subject: Re: Email from Phil's patchy philehol...@googlemail.com writes: 12:31:10 (UTC) Begin LilyPond compile, previous commit at 3573a92d92728dc8d6452e5cd3cfba73e49e6990 12:31:28 Merged staging, now at: 65c53165ab3535a9186f501c9a8b454d07c82642 12:31:29 Success: ./autogen.sh --noconfigure 12:31:42 Success: ../configure --disable-optimising 12:31:51 Success: nice make clean -j9 CPU_COUNT=9 -s 12:32:55 Success: nice make -j9 CPU_COUNT=9 -s 12:34:47 Success: nice make test -j9 CPU_COUNT=9 -s 12:37:51 *** FAILED BUILD *** nice make doc -j9 CPU_COUNT=9 -s Previous good commit: 3573a92d92728dc8d6452e5cd3cfba73e49e6990 Current broken commit: 65c53165ab3535a9186f501c9a8b454d07c82642 12:37:51 *** FAILED STEP *** merge from staging Failed runner: nice make doc -j9 CPU_COUNT=9 -s See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9--s.txt Ok, I'll be backing this out. If someone with horsepower can produce a relevant log file for the problem (possibly the one listed above is still around which might be a good start), this would likely be quite helpful. -- David Kastrup Parsing... Renaming input to: `adding-indicators-to-staves-which-get-split-after-a-break.ly' Interpreting music...[8] Preprocessing graphical objects.../media/IntelSSD/patchybuild/autobuild/build/out/lybook-db/d5/lily-520248d0.ly:59:9: In expression (ly:bar-line::print grob): /media/IntelSSD/patchybuild/autobuild/build/out/lybook-db/d5/lily-520248d0.ly:59:9: Unbound variable: ly:bar-line::print -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Email from Phil's patchy
Phil Holmes m...@philholmes.net writes: Ok, I'll be backing this out. If someone with horsepower can produce a relevant log file for the problem (possibly the one listed above is still around which might be a good start), this would likely be quite helpful. -- David Kastrup Parsing... Renaming input to: adding-indicators-to-staves-which-get-split-after-a-break.ly' Interpreting music...[8] Preprocessing graphical objects.../media/IntelSSD/patchybuild/autobuild/build/out/lybook-db/d5/lily-520248d0.ly:59:9: In expression (ly:bar-line::print grob): /media/IntelSSD/patchybuild/autobuild/build/out/lybook-db/d5/lily-520248d0.ly:59:9: Unbound variable: ly:bar-line::print Thanks, I changed issue 1320 accordingly. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Email from Phil's patchy
Am 28.07.2012 15:27, schrieb David Kastrup: Phil Holmes m...@philholmes.net writes: Ok, I'll be backing this out. If someone with horsepower can produce a relevant log file for the problem (possibly the one listed above is still around which might be a good start), this would likely be quite helpful. -- David Kastrup Parsing... Renaming input to: adding-indicators-to-staves-which-get-split-after-a-break.ly' Interpreting music...[8] Preprocessing graphical objects.../media/IntelSSD/patchybuild/autobuild/build/out/lybook-db/d5/lily-520248d0.ly:59:9: In expression (ly:bar-line::print grob): /media/IntelSSD/patchybuild/autobuild/build/out/lybook-db/d5/lily-520248d0.ly:59:9: Unbound variable: ly:bar-line::print Thanks, I changed issue 1320 accordingly So I have to edit the snippet, isn't it? I didn't follow the threads with snippets and stuff closely, but IIUC I have to move the snippet into snippets/new and edit it. Can I include the relevant changes into my patch? Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Email from Phil's patchy
Am 28.07.2012 19:43, schrieb Marc Hohl: Am 28.07.2012 15:27, schrieb David Kastrup: Phil Holmes m...@philholmes.net writes: Ok, I'll be backing this out. If someone with horsepower can produce a relevant log file for the problem (possibly the one listed above is still around which might be a good start), this would likely be quite helpful. -- David Kastrup Parsing... Renaming input to: adding-indicators-to-staves-which-get-split-after-a-break.ly' Interpreting music...[8] Preprocessing graphical objects.../media/IntelSSD/patchybuild/autobuild/build/out/lybook-db/d5/lily-520248d0.ly:59:9: In expression (ly:bar-line::print grob): /media/IntelSSD/patchybuild/autobuild/build/out/lybook-db/d5/lily-520248d0.ly:59:9: Unbound variable: ly:bar-line::print Thanks, I changed issue 1320 accordingly So I have to edit the snippet, isn't it? I didn't follow the threads with snippets and stuff closely, but IIUC I have to move the snippet into snippets/new and edit it. Can I include the relevant changes into my patch? I think I got it. http://codereview.appspot.com/6305115 Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Email from Phil's patchy
- Original Message - From: Marc Hohl m...@hohlart.de To: lilypond-devel@gnu.org Sent: Saturday, July 28, 2012 7:07 PM Subject: Re: Email from Phil's patchy Am 28.07.2012 19:43, schrieb Marc Hohl: Am 28.07.2012 15:27, schrieb David Kastrup: Phil Holmes m...@philholmes.net writes: Ok, I'll be backing this out. If someone with horsepower can produce a relevant log file for the problem (possibly the one listed above is still around which might be a good start), this would likely be quite helpful. -- David Kastrup Parsing... Renaming input to: adding-indicators-to-staves-which-get-split-after-a-break.ly' Interpreting music...[8] Preprocessing graphical objects.../media/IntelSSD/patchybuild/autobuild/build/out/lybook-db/d5/lily-520248d0.ly:59:9: In expression (ly:bar-line::print grob): /media/IntelSSD/patchybuild/autobuild/build/out/lybook-db/d5/lily-520248d0.ly:59:9: Unbound variable: ly:bar-line::print Thanks, I changed issue 1320 accordingly So I have to edit the snippet, isn't it? I didn't follow the threads with snippets and stuff closely, but IIUC I have to move the snippet into snippets/new and edit it. Can I include the relevant changes into my patch? I think I got it. http://codereview.appspot.com/6305115 Regards, Marc Sorry, Marc. To do this completely, you will need to add the changed file to snippets/new. The files in snippets get over-written when we import from the LSR, so this update would be lost. However, to make current git compile, you do also need to keep this change in snippets. I realise this isn't completely straightforward, but that's the way it is... -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
