Re: Allows for easier creation of many Lilypond objects via Scheme. (issue 7009047)
On 2012/12/24 07:28:17, mike7 wrote: On 24 déc. 2012, at 01:10, mailto:d...@gnu.org wrote: > All of this is absolutely devastatingly horrible code that is not > reconcilable with sane per-session semantics and tampers with LilyPond > internals in a way that has bleed-over effects into future files in the > same command line. > > In addition, the interfaces into the exposed internals are absolutely > horrific and cryptic and don't make any sense as a user interface. > I agree that the innards I'm exposing are not coded particularly well You don't get the point. A user interface is not supposed to "expose innards", it is supposed to provide functionality. Pulling data structures and some of the code accessing them into the open is not a user interface. > This is taking everything that is broken with > input/regression/scheme-text-spanner.ly, magnifies it to a number of > other cases, and gives it a bad interface. I am of the opinion that it is better to have stuff like this that allows people to do creative and interesting things with LilyPond than not have it at all. But those "creative and interesting things" will break frequently on update. We already have quite a bit of "why doesn't this stuff I based on [some version of] scheme-text-spanner.ly not work in my version of LilyPond?" questions. This is something that several users have asked for. But this does not give it to them. It is just a teaser which we'll take away again. It is bad enough if we have teasers in input/regression. Teasers don't belong in LilyPond proper. > No, no, and no again. Extensibility in this area would be nice, but > pulling out LilyPond's innards into the public without a proper design > is no substitute for that and totally a step in the wrong direction. I disagree. Proper design is important, but people who use LilyPond want this. People who use LilyPond want some parts of LilyPond to be extensible. This is _not_, I repeat _not_ what your patch does. It just pulls some internals from LilyPond's non-extensible parts into the open. It is like pulling some wires into the passenger room of a car that you can short-circuit for stiffening the dampeners and say that drivers want this. It will cause explosions when the gas runs low when using this, but it is better to have this now than later. There is some correlation to the desires of drivers, yes. I don't believe in withholding a capacity from people just because its design has problems. Mike, there is no design. It is not that the "design has problems", it is that you did not even bother with designing a user interface. It is just wires sticking out, and it is wires to something that was never intended to be shorted. Yes, let's improve the design, but let's get it out there. If anything, that will allow people to poke at it, see where it fails, and give us the opportunity to make it better. Mike, that is crap. If a programmer can't be bothered designing a user interface, how can "people poking at it" replace that? How can they better understand what is at issue than the programmer who could not be bothered creating an actual interface? For one thing, incrementally patching things up wherever they break is no substitute for design. For another thing, that can only incrementally _mask_ "broken by design" but can never fix it. We can refine the regtest over time to be whatever we think it should be. We have that approach with scheme-text-spanner already, and it is a continuing embarrassment to tell people "Uh, this will most certainly not continue working in future versions. It broke already for you? Tough." > None of these ad-hoc interfaces can sensibly be guaranteed to > survive any evolution of LilyPond's operation since they don't > interface to functionality, but rather to the current internals. So then let's make the functions and regtest better over time instead of not releasing it at all. Mike, you don't even try to understand what I am saying. The point of an interface is not to make it "better over time". An interface is not supposed to change all the time. When we provide an interface, it needs to be better than sawing off the hood of a car so that people can reach into it from the driver's seat. People _can_ already open the hood and poke around, but there is no guarantee that all the details will be in the same place with the next iteration. > If people want to poke LilyPond's internals with a stick, of > course they can do so with all bad side effects including > everything breaking possibly on the next update. But there is no > point giving them a stick with a handle for that if there is no > way in which we can guarantee the handle working for longer or > better than the stick does. We can guarantee this by fixing it when and if it breaks, like everything else. You can't "fix" a thin wrapper, nay merely a coating of internals when the internals change into something more generally
Re: Allows for easier creation of many Lilypond objects via Scheme. (issue 7009047)
On 2012/12/24 08:10:25, marc wrote: On 2012/12/24 07:28:17, mike7 wrote: > So what I need from you, if you're willing to help me out, are explanations of > how this causes bleedover effects. IIRC, the functions define-session and define-session-public were created for that very reason, so perhaps they are what you're after? They'd help with some of the bleedovers. They won't help with providing a sensible and reliable user interface, and they can't fix the fundamental "object property on symbols" storage design which is just incompatible with non-permanent behavior. That needs to be replaced first. https://codereview.appspot.com/7009047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows for easier creation of many Lilypond objects via Scheme. (issue 7009047)
On 2012/12/24 07:28:17, mike7 wrote: So what I need from you, if you're willing to help me out, are explanations of how this causes bleedover effects. IIRC, the functions define-session and define-session-public were created for that very reason, so perhaps they are what you're after? Just my 2ct Marc https://codereview.appspot.com/7009047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows for easier creation of many Lilypond objects via Scheme. (issue 7009047)
On 24 déc. 2012, at 10:10, m...@hohlart.de wrote: > On 2012/12/24 07:28:17, mike7 wrote: > >> So what I need from you, if you're willing to help me out, are > explanations of >> how this causes bleedover effects. > > IIRC, the functions define-session and define-session-public were > created for that very reason, so perhaps they are what you're after? > > Just my 2ct > > Marc > Thank you, Marc. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows for easier creation of many Lilypond objects via Scheme. (issue 7009047)
On 24 déc. 2012, at 10:36, d...@gnu.org wrote: > On 2012/12/24 07:28:17, mike7 wrote: > >> On 24 déc. 2012, at 01:10, mailto:d...@gnu.org wrote: > >> > All of this is absolutely devastatingly horrible code that is not >> > reconcilable with sane per-session semantics and tampers with > LilyPond >> > internals in a way that has bleed-over effects into future files in > the >> > same command line. >> > >> > In addition, the interfaces into the exposed internals are > absolutely >> > horrific and cryptic and don't make any sense as a user interface. >> > > >> I agree that the innards I'm exposing are not coded particularly >> well > > You don't get the point. A user interface is not supposed to "expose > innards", it is supposed to provide functionality. Pulling data > structures and some of the code accessing them into the open is not a > user interface. > I am certainly not saying that this type of task is for every user, but someone comfortable enough to do this should not have to copy and paste from define-*.scm every time. >> > This is taking everything that is broken with >> > input/regression/scheme-text-spanner.ly, magnifies it to a number of >> > other cases, and gives it a bad interface. > > >> I am of the opinion that it is better to have stuff like this that >> allows people to do creative and interesting things with LilyPond >> than not have it at all. > > But those "creative and interesting things" will break frequently on > update. We already have quite a bit of "why doesn't this stuff I > based on [some version of] scheme-text-spanner.ly not work in my > version of LilyPond?" questions. It seems like you'd rather not make something accessible rather than making it accessible in a fragile state. I certainly prefer the latter, as it allows more people to experiment. For example, David's work on the frame engraver would be a great trial ground for this sort of thing. > >> This is something that several users have asked for. > > But this does not give it to them. It is just a teaser which we'll > take away again. It is bad enough if we have teasers in > input/regression. Teasers don't belong in LilyPond proper. The whole point seems like by putting it there, we will hold ourselves to the standard of making sure it works should it ever break. I completely agree that teasers don't belong in LilyPond proper, but I don't see this going away. > >> > No, no, and no again. Extensibility in this area would be nice, but >> > pulling out LilyPond's innards into the public without a proper > design >> > is no substitute for that and totally a step in the wrong direction. > >> I disagree. Proper design is important, but people who use LilyPond >> want this. > > People who use LilyPond want some parts of LilyPond to be extensible. > This is _not_, I repeat _not_ what your patch does. It just pulls > some internals from LilyPond's non-extensible parts into the open. And by pulling these out into the open, it allows people to make customizable things. > > It is like pulling some wires into the passenger room of a car that > you can short-circuit for stiffening the dampeners and say that > drivers want this. This doesn't mess up the car for other people. And yes, drivers do want this! If there were an ambulance that one had to short-circuit to get me to the hospital, I wouldn't ask the driver not to drive for fear of an improper car design. > It will cause explosions when the gas runs low > when using this, but it is better to have this now than later. > That's exactly my point - it will explode, we'll see how it explodes, and that's exactly what will help us fix it over time. Unless we can afford a dedicated team of developers that get just-right, perfect interfaces full of bug free code the first time round, this seems like an imperfect but functional way for LilyPond to move forward. There are very few things in LilyPond that did not evolve because of the using->failing->fixing cycle. > There is some correlation to the desires of drivers, yes. > >> I don't believe in withholding a capacity from people just because >> its design has problems. > > Mike, there is no design Fair enough. > It is not that the "design has problems", > it is that you did not even bother with designing a user interface. I tried to make it as painless as possible given the current tools. Again, those who are using it are likely adept enough at LilyPond where they'll be able to do the things in the regtest. > It is just wires sticking out, and it is wires to something that was > never intended to be shorted. Let the wires stick out and let people experiment! Us, users, et cetera. That is, in my opinion, the best way for things to move forward. What I'm interested in fixing are the bleed-over problems, as of course this patch shouldn't make LilyPond worse, but it should be a first step towards making this functionality what we want it to be. > >> Yes, let's imp
Re: Allows for easier creation of many Lilypond objects via Scheme. (issue 7009047)
On Mon, Dec 24, 2012 at 7:22 AM, m...@mikesolomon.org wrote: > On 24 déc. 2012, at 10:36, d...@gnu.org wrote: > > On 2012/12/24 07:28:17, mike7 wrote: > > On 24 déc. 2012, at 01:10, mailto:d...@gnu.org wrote: > > >> All of this is absolutely devastatingly horrible code that is not >> reconcilable with sane per-session semantics and tampers with > > LilyPond > >> internals in a way that has bleed-over effects into future files in > > the > >> same command line. >> >> In addition, the interfaces into the exposed internals are > > absolutely > >> horrific and cryptic and don't make any sense as a user interface. >> > > > I agree that the innards I'm exposing are not coded particularly > well > > > You don't get the point. A user interface is not supposed to "expose > innards", it is supposed to provide functionality. Pulling data > structures and some of the code accessing them into the open is not a > user interface. > > > I am certainly not saying that this type of task is for every user, but > someone comfortable enough to do this should not have to copy and paste from > define-*.scm every time. > >> This is taking everything that is broken with >> input/regression/scheme-text-spanner.ly, magnifies it to a number of >> other cases, and gives it a bad interface. > > > > I am of the opinion that it is better to have stuff like this that > allows people to do creative and interesting things with LilyPond > than not have it at all. > > > But those "creative and interesting things" will break frequently on > update. We already have quite a bit of "why doesn't this stuff I > based on [some version of] scheme-text-spanner.ly not work in my > version of LilyPond?" questions. > > > It seems like you'd rather not make something accessible rather than making > it accessible in a fragile state. I certainly prefer the latter, as it > allows more people to experiment. For example, David's work on the frame > engraver would be a great trial ground for this sort of thing. > I've gotten a lot of use out of techniques in scheme-text-spanner.ly--that's probably very evident--and I'm quite appreciative that it's there. I understand the problems that it causes--I've seen evidence of bleed-over. However, I'm using these techniques as a convenient aid to developing new features. I could certainly work directly in LilyDev and alter the necessary files in the proper way, but then I'm unable to get feedback from those users who would actively use the new features but aren't comfortable applying patches. You can see just how much user feedback I got during the creation of the measure counter (issue 2445). As far as the frame engraver goes, I've gotten a good sense of what such a thing ought to do, and corrected several problems based on input from lilypond-user. My efforts here are still quite a way from producing a formal patch and putting it up for review, but that is the end goal. Best, David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
git-problem "fatal: read error: Connection reset by peer"
Hi, trying ~/lilypond-git (dev/local_working)$ git pull -r returns: fatal: read error: Connection reset by peer What's wrong? -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows for easier creation of many Lilypond objects via Scheme. (issue 7009047)
>> It is just wires sticking out, and it is wires to something that >> was never intended to be shorted. > > Let the wires stick out and let people experiment! Us, users, et > cetera. That is, in my opinion, the best way for things to move > forward. What I'm interested in fixing are the bleed-over problems, > as of course this patch shouldn't make LilyPond worse, but it should > be a first step towards making this functionality what we want it to > be. I think this is exactly what git branches are good for. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git-problem "fatal: read error: Connection reset by peer"
2012/12/24 Thomas Morley : > Hi, > > trying > > ~/lilypond-git (dev/local_working)$ git pull -r > > returns: > > fatal: read error: Connection reset by peer > > What's wrong? > > > > -Harm After rebooting LilyDev, it works again. -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Moved Appendix C to CG (issue 6948070)
Reviewers: Trevor Daniels,
https://codereview.appspot.com/6948070/diff/1/Documentation/contributor.texi
File Documentation/contributor.texi (right):
https://codereview.appspot.com/6948070/diff/1/Documentation/contributor.texi#newcode74
Documentation/contributor.texi:74: @verbatiminclude ly-grammar.txt
On 2012/12/17 23:43:58, Trevor Daniels wrote:
The text needs to go just before the
@include fdl.itexi
near the end of this file.
Just the * LilyPond grammar:: line should
appear in the menu block.
You'll also need to prefix the text with
@node LilyPond grammar
@appendix LilyPond grammar
Done.
https://codereview.appspot.com/6948070/diff/1/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (left):
https://codereview.appspot.com/6948070/diff/1/Documentation/notation/notation-appendices.itely#oldcode1545
Documentation/notation/notation-appendices.itely:1545: (BNF) in
@ref{LilyPond grammar}. This file is used to build the
On 2012/12/17 23:43:58, Trevor Daniels wrote:
How about leaving this paragraph in, simply
changing the @ref{} to @rcontrib{}? It is in a
Technical glossary, so I don't mind the technicalities
being mentioned here. What do you think?
Done.
Description:
Doc: NR Moved Appendix C to CG
Issue 3015
Please review this at https://codereview.appspot.com/6948070/
Affected files:
M Documentation/contributor.texi
M Documentation/notation.tely
M Documentation/notation/notation-appendices.itely
Index: Documentation/contributor.texi
diff --git a/Documentation/contributor.texi b/Documentation/contributor.texi
index
74d03bd1b7e8fb9a05ba3fbaeee96dcfa49733cd..a71b124ce60e9517849a6b8fcb46bdfa9bcf4794
100644
--- a/Documentation/contributor.texi
+++ b/Documentation/contributor.texi
@@ -66,6 +66,8 @@ Copyright @copyright{} 2007--2012 by the authors.
Appendices
+* LilyPond grammar::
+
* GNU Free Documentation License:: License of this document.
@end menu
@@ -91,7 +93,14 @@ Appendices
@include contributor/feta-font.itexi
@include contributor/administration.itexi
+@node LilyPond grammar
+@appendix LilyPond grammar
+
+This appendix contains a description of the LilyPond grammar, as
+output from the parser.
+
+@verbatiminclude ly-grammar.txt
+
@include fdl.itexi
@bye
-
Index: Documentation/notation.tely
diff --git a/Documentation/notation.tely b/Documentation/notation.tely
index
098d4f3593a3cb1aea7d783e310761a788987fc8..0e269c2076a6e7933ad0a5c8b9d4785814e33848
100644
--- a/Documentation/notation.tely
+++ b/Documentation/notation.tely
@@ -84,16 +84,6 @@ Appendices
@include notation/cheatsheet.itely
-
-@node LilyPond grammar
-@appendix LilyPond grammar
-
-This appendix contains a description of the LilyPond grammar, as
-output from the parser.
-
-@verbatiminclude ly-grammar.txt
-
-
@include fdl.itexi
Index: Documentation/notation/notation-appendices.itely
diff --git a/Documentation/notation/notation-appendices.itely
b/Documentation/notation/notation-appendices.itely
index
e74dae6184639caa4a96455ece846bfe9dca6557..8926646de7c12ac9f8b6c860b130fcadff5482c8
100644
--- a/Documentation/notation/notation-appendices.itely
+++ b/Documentation/notation/notation-appendices.itely
@@ -1530,7 +1530,8 @@ created for midi, layout and paper blocks.
@cindex parser
@cindex Bison
-@cindex grammar for LilyPond
+@cindex LilyPond grammar
+@cindex grammar, for LilyPond
@cindex BNF
A @strong{parser} analyzes the sequence of tokens produced by a
@@ -1542,10 +1543,10 @@ cannot be achieved the file is invalid and an
appropriate error
message is produced. The syntactic groupings and the rules for
constructing the groupings from their parts for the LilyPond syntax
are defined in @file{lily/parser.yy} and shown in Backus Normal Form
-(BNF) in @ref{LilyPond grammar}. This file is used to build the
-parser during the program build by the parser generator, Bison. It
-is part of the source code and is not included in the LilyPond
-binary installation.
+(BNF) in @rcontrib{LilyPond grammar}. This file is used to build the
+parser during the program build by the parser generator, Bison. It is
+part of the source code and is not included in the LilyPond binary
+installation.
@node parser variable
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
