Allows for easier creation of many Lilypond objects via Scheme.

Allows for easier creation of many Lilypond objects via Scheme.

[dak, 2012-12-23 23:10:19]

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.

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.

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.  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.

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.

https://codereview.appspot.com/7009047/diff/2001/ly/property-init.ly
File ly/property-init.ly (right):

https://codereview.appspot.com/7009047/diff/2001/ly/property-init.ly#newcode682
ly/property-init.ly:682: defineEventClass =
Absolutely awful interface here.  No.

https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm
File scm/define-grobs.scm (right):

https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm#newcode...
scm/define-grobs.scm:2695: (define (register-grob-name x)
No.  This is an interface with heavy session bleedover characteristics: as long
as a symbol is not garbage-collected (for example, because it is referenced
anywhere as a symbol in a totally non-grob context), it will remain defined
between sessions.

First the internals need to be redefined in a manner allowing for sane
per-session behavior before any exposed public interface is offered for that.

https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm#newcode...
scm/define-grobs.scm:2703: (completize-grob-entry x))
No, this will cause heavy bleedover effects between sessions.

https://codereview.appspot.com/7009047/diff/2001/scm/define-music-types.scm
File scm/define-music-types.scm (right):

https://codereview.appspot.com/7009047/diff/2001/scm/define-music-types.scm#n...
scm/define-music-types.scm:758: (define-public (make-music-descriptions
descriptions)
Unsuitable for a public interface because of session bleedover.

[mike7, 2012-12-24 07:28:17]

On 24 déc. 2012, at 01:10, dak@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 - there is
a lot of glue code in Scheme just to get the machine running.  I would rather
take the time now to clean that code up and get it so that users can use it
(that has been a frequent request) if that is what people think should be done.

> 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. 
This is something that several users have asked for.  I do not mind, however:

1) putting a caveat that it is subject to change or bad code.
2) working on the code so that it gets better.

What would be most helpful from you are constructive comments on how to make the
patch better, which you are doing below and I appreciate.  More are welcome.

> 
> 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. 
I don't believe in withholding a capacity from people just because its design
has problems.  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.  We can refine the regtest over time to be
whatever we think it should be.

> 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.  If LilyPond's imperfect were a criteria for not making it
available to the public, no one would have ever used any of it back in the day
and we would not be having this discussion.

> 
> 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. 
I think it's important to have the feature first and make it perfect later.

So what I need from you, if you're willing to help me out, are explanations of
how this causes bleedover effects.

> 
> 
> https://codereview.appspot.com/7009047/diff/2001/ly/property-init.ly
> File ly/property-init.ly (right):
> 
>
https://codereview.appspot.com/7009047/diff/2001/ly/property-init.ly#newcode682
> ly/property-init.ly:682: defineEventClass =
> Absolutely awful interface here.  No.

Helpful suggestions appreciated.  Again, I think it's better to have a bad UI
than not have one at all.  At least it is a start, but of course I want to make
it as good as possible in this first round.

> 
> https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm
> File scm/define-grobs.scm (right):
> 
>
https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm#newcode...
> scm/define-grobs.scm:2695: (define (register-grob-name x)
> No.  This is an interface with heavy session bleedover characteristics:
> as long as a symbol is not garbage-collected (for example, because it is
> referenced anywhere as a symbol in a totally non-grob context), it will
> remain defined between sessions.
> 

How can we force it to be garbage collected at the end of a session?

> First the internals need to be redefined in a manner allowing for sane
> per-session behavior before any exposed public interface is offered for
> that.
> 
>
https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm#newcode...
> scm/define-grobs.scm:2703: (completize-grob-entry x))
> No, this will cause heavy bleedover effects between sessions.

How do I fix this?

> 
> https://codereview.appspot.com/7009047/diff/2001/scm/define-music-types.scm
> File scm/define-music-types.scm (right):
> 
>
https://codereview.appspot.com/7009047/diff/2001/scm/define-music-types.scm#n...
> scm/define-music-types.scm:758: (define-public (make-music-descriptions
> descriptions)
> Unsuitable for a public interface because of session bleedover.

How do I fix this?

What would help is a sort of mark-for-garbage-collection-at-end-of-session
function.  Does that exist?

Cheers,
MS

[marc, 2012-12-24 08:10:25]

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

[dak, 2012-12-24 08:36:31]

On 2012/12/24 07:28:17, mike7 wrote:

> On 24 déc. 2012, at 01:10, mailto:dak@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 useful.  If this
coating is supposed to be an "interface", you can't change the engine
any more.

> I think it's important to have the feature first and make it perfect
> later.

But you are not providing a feature.  You are just providing access to
the engine.  And if poking around in the engine without any provision
of consistence and continued operation is the goal, that can already
be done.

At the current point of time, LilyPond is not designed for supporting
this kind of extensibility.  Every "interface" designed as a thin
wrapper will break in future versions.

>
https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm#newcode...
> > scm/define-grobs.scm:2695: (define (register-grob-name x)
> > No.  This is an interface with heavy session bleedover characteristics:
> > as long as a symbol is not garbage-collected (for example, because it is
> > referenced anywhere as a symbol in a totally non-grob context), it will
> > remain defined between sessions.
> > 
> 
> How can we force it to be garbage collected at the end of a session?

_Everything_ is garbage collected continually, and particularly at the
end of a session.  However, every symbol that is compiled somewhere
into the LilyPond code base is not garbage.  Putting this kind of data
as _object_ properties on symbols is fine when one is certain that the
data should stay around indefinitely.

It is unsuitable for per-session data.  By design.  So we need to
change this mechanism to something else before we offer to change this
to per-session.  Since there was no actual interface before, every
code poking around in these object properties of symbols on its own
initiative previously will break.  That's not nice, but then there was
no guarantee or reasonable expectation that our internals would stick
around in the same manner.

And we should not start giving them coatings suggesting otherwise when
we know that they can't work reliably for the purpose we are selling
them for.

> What would help is a sort of
> mark-for-garbage-collection-at-end-of-session function.

Object properties stick around as long as their objects do, and
whether a symbol is used/mentioned somewhere in existing code for
whatever purpose that might not be related to use as a user grob or
event name is an open bet.

This needs to move from symbol object properties to some more reliably
resettable data structure _before_ one can sensibly offer a user-level
interface for it.

[dak, 2012-12-24 08:40:43]

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.

[mike7, 2012-12-24 13:01:14]

On 24 déc. 2012, at 10:10, marc@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

[mike7, 2012-12-24 13:22:22]

On 24 déc. 2012, at 10:36, dak@gnu.org wrote:

> On 2012/12/24 07:28:17, mike7 wrote:
> 
>> On 24 déc. 2012, at 01:10, mailto:dak@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 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?

People poking around at things is the reason for the majority of great
discoveries and advances in the history of mankind.

> How can
> they better understand what is at issue than the programmer who could
> not be bothered creating an actual interface?

I'm not saying they should understand what is at issue - I'm saying they should
ignore or use it, be happy when it works, complain that it doesn't, and we move
towards making it better.

> For one thing,
> incrementally patching things up wherever they break is no substitute
> for design.

No, not at all, but it is the thing that allows for design to happen.  We will
see how these things are used, realize where they fail, patch as we go, and then
make a better design once we understand the scope of the problem.  But how can
one understand the scope of anything without experimenting?

> 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."

It is thanks to the existence of this that I have written several pieces that
have been necessary to my career as a composer.  If you could voyage into the
past and undo the creation of that engraver, that would take away part of my and
other's livelihoods.  Sure, you could make the argument that somethings' working
and then breaking is more destructive for the livelihoods of people than not
having it at all, but I would disagree.  From my experience, it is always better
to work with imperfect things and suffer through the pains of breaking and
fixing than only letting perfect things pass.

> 
>> > 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.

Then what are development versions for?

> 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.

So then help me with this with constructive criticism like that of Marc.

> 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.

No, but we'll document the changes and do the best we can to help people adapt.

> 
>> > 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 useful.  If this
> coating is supposed to be an "interface", you can't change the engine
> any more.
> 
>> I think it's important to have the feature first and make it perfect
>> later.
> 
> But you are not providing a feature.  You are just providing access to
> the engine.

How is access to the engine not a feature?

Christmasing, so gotta go, but I will continue to be appreciative of all
constructive criticism that can help make this patch realizable for people like
me, Jeffrey Treviño who requested it, and David N. who has to copy and paste out
of scheme files to make this happen.  All three of us make our living thanks to
LilyPond.  I can't speak on their behalves, but I can certainly say that I'd
appreciate making this patch as good as possible and getting it into LilyPond so
that people can poke at it it rather than not adding it for fear of the issues
you discuss above.

Cheers,
MS

[wl_gnu.org, 2012-12-24 13:43:42]

>> 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

[david.nalesnik, 2012-12-24 13:56:00]

On Mon, Dec 24, 2012 at 7:22 AM, mike@mikesolomon.org
<mike@mikesolomon.org> wrote:
> On 24 déc. 2012, at 10:36, dak@gnu.org wrote:
>
> On 2012/12/24 07:28:17, mike7 wrote:
>
> On 24 déc. 2012, at 01:10, mailto:dak@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

[mike7, 2012-12-25 09:17:34]

On 24 déc. 2012, at 15:55, David Nalesnik <david.nalesnik@gmail.com> wrote:

> On Mon, Dec 24, 2012 at 7:22 AM, mike@mikesolomon.org
> <mike@mikesolomon.org> wrote:
>> On 24 déc. 2012, at 10:36, dak@gnu.org wrote:
>> 
>> On 2012/12/24 07:28:17, mike7 wrote:
>> 
>> On 24 déc. 2012, at 01:10, mailto:dak@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.

[responding to Werner too] I completely see where you're coming from - this is
how I've gone about work with a lot of features.  This is why I think the idea
of a git branch, while good for development, is not necessarily possible for the
average user to access.

> 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.

I'm positive you'll get there.  The frame patch, when submitted, should be able
to use in-house grob-creation and event-creation mechanisms instead of copying
and pasting out of Scheme files.  My goal with the present patch is to get
LilyPond to a state where you and others can do this.  Any feedback on how to
control the bleed-over mechanisms that you, Mark and David K. have identified
would be very helpful.

Cheers,
MS