subject:"critical issues"

Janek Warchoł janek.lilyp...@gmail.com writes:

  \layout {
    \context {
      \Score
      \with \settingsFrom { \compressFullBarRests }
    }
    \context {
      \Staff
      \with \settingsFrom { \accidentalStyle modern }
    }
  }
 }
 \end{lilypond}

 \ph is a music function written in Scheme.  Can you understand it?

 Yes, but i get lost on \parallellMusic :(

It's intended for using.  And yes, it likely could be simpler given
useful APIs for manipulating Scheme.

 \settingsFrom is actually returning a Scheme expression for \with to
 use.  It makes things rather simpler than more complex, even though it
 constitutes a Scheme expression.

 Um... i would really love to be able to type
  \layout {
  \compressFullBarRests
  \override Score.SpacingSpanner #'common-shortest-duration =
 #(ly:make-moment 6 10)
  etc...
 }

Well, create a layout modification type, let \layout accept Scheme
expressions of that type, write a Scheme function \layout-from in
analogue to \settingsFrom, and it becomes

\layout {
   \layout-from { \compressFullBarRests
 \override Score.SpacingSpanner #'common-shortest-duration =
 #(ly:make-moment 6 10)
   }
   etc...
}

Stuff like that is reasonably straightforward to implement.  It would
have the advantage that you don't have to know what contexts
\settingsFrom should be placed in.

Again:

 Scheme is not hard.  Programming is hard.

And sane program design is, apparently, even harder.  People _don't_
_ever_ think about improving things.  Instead they hobble along in
whatever clunky way they see others doing, complaining how clunky it is,
and likely making it much clunkier by bending it to situations fitting
even worse than what they have seen.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-04 Thread Łukasz Czerwiński

On 3 January 2012 21:47, Janek Warchoł janek.lilyp...@gmail.com wrote:


  I am a TeX specialist, system programmer, Emacs specialist, the GNU
  maintainer (and a rather pitiful one) for AUCTeX (lytex and itexi
  anybody? preview-latex for Lilypond?)

Mmm... Preview for Lilypond? Sounds like a good start for a realtime GUI
for Lilypond (a better Denemo). I believe this will result in a fast
increase in number of Lilypond users. What do you think?


 I would have no problems spending a few hundred man years focused on
  Lilypond.  Except that I don't have a few hundred man years.  Nobody
  has.  The next best option is spending time on multipliers.  Getting
  LilyPond in a shape where passersby find it intriguing, to a degree
  where they get hooked and contribute manmonths of work over some time
  without having planned to do so at the start.

 +1


and:

  The only thing that is going to help is more eyes, more people who get

 interested, more people discovering dark corners and doing something

 about them.


and:


 To get there, we need serious programmers and serious musicians

 interested seriously in LilyPond.  To a level where they start asking

 good questions.  And we better be in a position to provide answers,

 since there is no more effective way to spend our time than on getting

 more people to spend their time, and love, and interest.


and:

 That's like + from me!
 In general, i agree that we should think in a more 'release-oriented'
 way (last stable release was half a year ago, so we should make
 another one, so i'm fixing whatever needs to be fixed to make this
 possible) instead of 'free coding' way (i care about this issue,
 i'll fix it.  And that one.  Oh, we have 0 criticals, so let's make a
 stable release before an obstruction occurs!).  To do so, we would
 have to work more as a team, less independently.  How can we achieve
 that if GOP7 showed that we don't want to?


and:

 And we better be in a position to provide answers,
  since there is no more effective way to spend our time than on getting
  more people to spend their time, and love, and interest.


Regarding all those fragments of Janek's and David's emails: For some time
I have been observing how bug are being fixed in Lilypond and spent some
time on conversations with Janek.
For me there is almost no team work in Lilypond - only a bunch of geek
trying to fix some issues, but without a leader who coordinates all
actions. As far as I remember, some time ago you have tried hard to make
some big changes in Lilypond, but finally there was no big revolution...
Without a leader that will make key design  implementation decisions
Lilypond will improve in a slow pace, letting Finale and Sibellius gain
more and more users. Probably some of you will return to the old row - is a
goal of a Lilypond to substitue Finale or compete with Sibellius. I think
there is no point in loosing your energy *and time* on that.
Instead we should do as much as possible to constantly improve Lilypond.
That means not only fixing critical bugs, but also: anticipating future
stability problems, constantly improving end user documentation and the
quality of source code (reduce complexity, comment code and so on). By now
there is a huge work to be done and Lilypond needs someone who will form
guidelines and priorities.

Łukasz (Luke)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

Łukasz Czerwiński milimet...@gmail.com writes:

 On 3 January 2012 21:47, Janek Warchoł janek.lilyp...@gmail.com wrote:


  I am a TeX specialist, system programmer, Emacs specialist, the GNU
  maintainer (and a rather pitiful one) for AUCTeX (lytex and itexi
  anybody? preview-latex for Lilypond?)

 Mmm... Preview for Lilypond? Sounds like a good start for a realtime
 GUI for Lilypond (a better Denemo). I believe this will result in a
 fast increase in number of Lilypond users. What do you think?

It won't.  People who are into Emacs won't be into Finale or Sibelius
anyway.  It will increase the ratio of LilyPond users using Emacs for
editing, and possibly the productivity of users of that combination.

But recruiting new users to both LilyPond and Emacs at the same time is
not going to show impressive results.

It is a reasonable expectation to get preview-latex cooperate with
lilypond-book in LaTeX mode with reasonable effort.  To yield a sizable
boost in productivity for LilyPond development, however, preview-latex
would have to cooperate with Texinfo.

Technologically, this is challenging and exciting.  Unfortunately, for
myself the excitement is somewhat stale since I already implemented
preview-latex once.

 Regarding all those fragments of Janek's and David's emails: For some time
 I have been observing how bug are being fixed in Lilypond and spent some
 time on conversations with Janek.
 For me there is almost no team work in Lilypond - only a bunch of geek
 trying to fix some issues, but without a leader who coordinates all
 actions.

We have coordinated procedures in place that several people spend
sizable amounts of time on.  This concerns the way new contributions are
channeled, and how bugs get registered and releases get made.  Graham is
doing a lot of work keeping just that going and coordinated.

New developments are not coordinated to a significant degree, and part
of the reason is that there are no free resources to coordinate.

 As far as I remember, some time ago you have tried hard to make some
 big changes in Lilypond, but finally there was no big revolution...

I am not sure who you are addressing.  Nominally, you are replying to
Janek, and Janek did spacing changes he not just tried to get through,
but actually did.  If you are trying to address my work: I did a lot of
big changes to LilyPond but you would not notice much of it unless you
read the manual, and even then much of it is underdocumented.  A lot of
it is hidden in making naively written code work and giving more power
more easily accessible to the somewhat above-average user as opposed to
the geniuses required before.

 Without a leader that will make key design  implementation decisions
 Lilypond will improve in a slow pace, letting Finale and Sibellius
 gain more and more users.

Forget Finale and Sibelius.  They are not a problem we need to address
since they are competing in a different space.  Our real problem is
LilyPond.

 Probably some of you will return to the old row - is a goal of a
 Lilypond to substitue Finale or compete with Sibellius. I think there
 is no point in loosing your energy *and time* on that.  Instead we
 should do as much as possible to constantly improve Lilypond.

Preaching to the choir, I see.

 That means not only fixing critical bugs, but also: anticipating
 future stability problems, constantly improving end user documentation
 and the quality of source code (reduce complexity, comment code and so
 on). By now there is a huge work to be done and Lilypond needs someone
 who will form guidelines and priorities.

There is no point in working on guidelines and priorities without
capacities that would be guided and prioritized by them.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

David Kastrup d...@gnu.org writes:

 Janek Warchoł janek.lilyp...@gmail.com writes:

  \layout {
    \context {
      \Score
      \with \settingsFrom { \compressFullBarRests }
    }
    \context {
      \Staff
      \with \settingsFrom { \accidentalStyle modern }
    }
  }
 }
 \end{lilypond}

 \ph is a music function written in Scheme.  Can you understand it?

 Yes, but i get lost on \parallellMusic :(

 It's intended for using.  And yes, it likely could be simpler given
 useful APIs for manipulating Scheme.

 \settingsFrom is actually returning a Scheme expression for \with to
 use.  It makes things rather simpler than more complex, even though it
 constitutes a Scheme expression.

 Um... i would really love to be able to type
  \layout {
  \compressFullBarRests
  \override Score.SpacingSpanner #'common-shortest-duration =
 #(ly:make-moment 6 10)
  etc...
 }

 Well, create a layout modification type, let \layout accept Scheme
 expressions of that type, write a Scheme function \layout-from in
 analogue to \settingsFrom, and it becomes

 \layout {
\layout-from { \compressFullBarRests
  \override Score.SpacingSpanner #'common-shortest-duration =
  #(ly:make-moment 6 10)
}
etc...
 }

 Stuff like that is reasonably straightforward to implement.  It would
 have the advantage that you don't have to know what contexts
 \settingsFrom should be placed in.

layout-from =
#(define-void-function (parser location music)
   (ly:music?)
   (_i To be used in output definitions.  Take the layout instruction
events from @var{music} and do the equivalent of context modifications
duplicating their effect.)
   (define (musicop m mods)
 (if (music-is-of-type? m 'layout-instruction-event)
 (ly:add-context-mod
  mods
  (case (ly:music-property m 'name)
((PropertySet)
 (list 'assign
   (ly:music-property m 'symbol)
   (ly:music-property m 'value)))
((PropertyUnset)
 (list 'unset
   (ly:music-property m 'symbol)))
((OverrideProperty)
 (list 'push
   (ly:music-property m 'symbol)
   (ly:music-property m 'grob-property-path)
   (ly:music-property m 'grob-value)))
((RevertProperty)
 (list 'pop
   (ly:music-property m 'symbol)
   (ly:music-property m 'grob-property-path)
 (case (ly:music-property m 'name)
 ((SequentialMusic SimultaneousMusic)
  (for-each (lambda (x)
  (musicop x mods))
(ly:music-property m 'elements)))
 ((ContextSpeccedMusic)
  (module-set! (current-module)
   (ly:music-property m 'context-type)
   #{ \context { $(module-ref (current-module)
  (ly:music-property m 
'context-type))
 $(musicop (ly:music-property m 
'element)
   (ly:make-context-mod))
 } #}
 mods)
   (musicop music (ly:make-context-mod)))


It is a bit wonky, but should work for most purposes.

At least it works with

\layout-from \accidentalStyle dodecaphonic

and with the above example.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-04 Thread Janek Warchoł

2012/1/4 James pkx1...@gmail.com:
 hello,

 On 3 Jan 2012, at 22:26, Janek Warchoł janek.lilyp...@gmail.com wrote:
 I might have given you a wrong impression, i don't think its really
 that bad.  There is some teamwork, but no leader indeed.

 to use an English expression ... poppycock!

 Janek you may have not noticed that the team of Colin,
 Phil and myself along with some of the bug squad managed,
 with the the help of Graham (if you want to call him a 'leader')
 to process a quite impressive number of patches.

 Before we managed to get some kind of automation of
 patch testing I personally was fielding about 6 new patches
 a day, producing reg test diffs, make checks and the like.
 Colin was managing all patch countdown and push requests
 while Phil ran around, figuratively speaking, making sure
 things were in order in terms of regressions between dev releases.
 all co ordinated by graham - pretty much.

 in the meantime Mike, Keith, Carl and co had plenty of time
 then to fix some long standing bugs, and I am seeing some
 serious work by David to do whatever it is he does with the parser etc.

Indeed, i didn't appreciate enough your work.  I apologize.
Please do not hesitate to correct me when i say something wrong again.

Nevertheless, while administration is done very efficiently as you've
shown, i'm not aware of any mid- or long-term goals set for Lily
except GLISS.  Correct me if i'm wrong, but my impression is that
there is no particular direction in which we are going.

my apologies again,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-04 Thread Janek Warchoł

2012/1/4 David Kastrup d...@gnu.org:
 \settingsFrom is actually returning a Scheme expression for \with to
 use.  It makes things rather simpler than more complex, even though it
 constitutes a Scheme expression.

 Um... i would really love to be able to type
  \layout {
  \compressFullBarRests
  \override Score.SpacingSpanner #'common-shortest-duration =
 #(ly:make-moment 6 10)
  etc...
 }

 Well, create a layout modification type, let \layout accept Scheme
 expressions of that type, write a Scheme function \layout-from in
 analogue to \settingsFrom, and it becomes

 \layout {
   \layout-from { \compressFullBarRests
 \override Score.SpacingSpanner #'common-shortest-duration =
 #(ly:make-moment 6 10)
   }
   etc...
 }

ok...  However - i'm very sorry to say this :/ - it would be better if
i wouldn't have to type \layout-from at all.  I know that it's not
much typing, and that \layout-from is an improvement, but from the
end-user perspective it's in fact PITA: when use \layout, when
\layout-from?  :(  Again, i'm very sorry beacause from the
programmer's perspective it's nothing, but for simple users
understanding what \layout does is hard enough; in fact it would be
nice to get rid of it but that's impossible.
You know, i pretend to be a really dumb user.  And i want to enter
notes, not some \overridden  \layoutish ##Scheme##  :( :( :(
LilyPond will have a chance of winning large audiences when all input
that is needed to create a full Messiah score will be sth like:

\version x.x.x

\header { ... }
\movement = Sinfony {
violin = { (notes) }
...
}
\movement = Comfort ye {



\makeScore
\makeParts

:/

 Scheme is not hard.  Programming is hard.

 And sane program design is, apparently, even harder.  People _don't_
 _ever_ think about improving things.  Instead they hobble along in
 whatever clunky way they see others doing, complaining how clunky it is,
 and likely making it much clunkier by bending it to situations fitting
 even worse than what they have seen.

:(
Have you looked at my patches and if so, does any of them do this?


2012/1/4 David Kastrup d...@gnu.org:
 layout-from =
 #(define-void-function (parser location music)
   (ly:music?)
   (_i To be used in output definitions.  Take the layout instruction
 events from @var{music} and do the equivalent of context modifications
 duplicating their effect.)
   (define (musicop m mods)
     (if (music-is-of-type? m 'layout-instruction-event)
         (ly:add-context-mod
          mods
          (case (ly:music-property m 'name)
            ((PropertySet)
             (list 'assign
                   (ly:music-property m 'symbol)
                   (ly:music-property m 'value)))
            ((PropertyUnset)
             (list 'unset
                   (ly:music-property m 'symbol)))
            ((OverrideProperty)
             (list 'push
                   (ly:music-property m 'symbol)
                   (ly:music-property m 'grob-property-path)
                   (ly:music-property m 'grob-value)))
            ((RevertProperty)
             (list 'pop
                   (ly:music-property m 'symbol)
                   (ly:music-property m 'grob-property-path)
         (case (ly:music-property m 'name)
             ((SequentialMusic SimultaneousMusic)
              (for-each (lambda (x)
                          (musicop x mods))
                        (ly:music-property m 'elements)))
             ((ContextSpeccedMusic)
              (module-set! (current-module)
                           (ly:music-property m 'context-type)
                           #{ \context { $(module-ref (current-module)
                                                      (ly:music-property m 
 'context-type))
                                         $(musicop (ly:music-property m 
 'element)
                                                   (ly:make-context-mod))
                                         } #}
     mods)
   (musicop music (ly:make-context-mod)))


 It is a bit wonky, but should work for most purposes.

 At least it works with

    \layout-from \accidentalStyle dodecaphonic

 and with the above example.

Wow, thanks!  I hope that i understand what it does and that i'll be
able to use it :)

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-04 Thread Janek Warchoł

Adding Luke to recipients again...  (please remember to include him as
he's not signed to our mailing lists),

2012/1/4 David Kastrup d...@gnu.org:
 Łukasz Czerwiński milimet...@gmail.com writes:
 Regarding all those fragments of Janek's and David's emails: For some time
 I have been observing how bug are being fixed in Lilypond and spent some
 time on conversations with Janek.
 For me there is almost no team work in Lilypond - only a bunch of geek
 trying to fix some issues, but without a leader who coordinates all
 actions.

 We have coordinated procedures in place that several people spend
 sizable amounts of time on.  This concerns the way new contributions are
 channeled, and how bugs get registered and releases get made.  Graham is
 doing a lot of work keeping just that going and coordinated.

Indeed and this means: kudos to Graham and the patch/issue team!

 As far as I remember, some time ago you have tried hard to make some
 big changes in Lilypond, but finally there was no big revolution...

 I am not sure who you are addressing.  Nominally, you are replying to
 Janek, and Janek did spacing changes he not just tried to get through,
 but actually did.

Thank you David for being so kind, but i don't remember any important
spacing issues fixed by me.
(however i'm in the process of gathering data for a truly
revolutionary move; unfortunately estimated time left before the
report will be ready is something like 3 months, because of other
stuff i have to do).

 Without a leader that will make key design  implementation decisions
 Lilypond will improve in a slow pace, letting Finale and Sibellius
 gain more and more users.

 Forget Finale and Sibelius.  They are not a problem we need to address
 since they are competing in a different space.

I don't fully agree, but i guess discusssing this is not that important.

 That means not only fixing critical bugs, but also: anticipating
 future stability problems, constantly improving end user documentation
 and the quality of source code (reduce complexity, comment code and so
 on). By now there is a huge work to be done and Lilypond needs someone
 who will form guidelines and priorities.

 There is no point in working on guidelines and priorities without
 capacities that would be guided and prioritized by them.

I'm amused by your answer, David.  It's very rational and succint; i
know Luke and if something can show him what the problem is it's your
answer.

Luke, i remember that you were doing something for GIMP.  Can you say
how things work there, what the leadership looks like and what could
we learn from them, bearing in mind little time each of us have?

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

Janek Warchoł janek.lilyp...@gmail.com writes:

 2012/1/4 David Kastrup d...@gnu.org:
 \settingsFrom is actually returning a Scheme expression for \with to
 use.  It makes things rather simpler than more complex, even though it
 constitutes a Scheme expression.

 Um... i would really love to be able to type
  \layout {
  \compressFullBarRests
  \override Score.SpacingSpanner #'common-shortest-duration =
 #(ly:make-moment 6 10)
  etc...
 }

 Well, create a layout modification type, let \layout accept Scheme
 expressions of that type, write a Scheme function \layout-from in
 analogue to \settingsFrom, and it becomes

 \layout {
   \layout-from { \compressFullBarRests
 \override Score.SpacingSpanner #'common-shortest-duration =
 #(ly:make-moment 6 10)
   }
   etc...
 }

 ok...  However - i'm very sorry to say this :/ - it would be better if
 i wouldn't have to type \layout-from at all.

\layout is not the place to accept arbitrary music.

 I know that it's not much typing, and that \layout-from is an
 improvement, but from the end-user perspective it's in fact PITA: when
 use \layout, when \layout-from?

\layout-from takes music and extracts context definitions.

 :( Again, i'm very sorry beacause from the programmer's perspective
 it's nothing, but for simple users understanding what \layout does is
 hard enough;

\layout definitions don't have a syntax compatible with music.  For
example, \layout-from is a command you could not even write in music.

If \layout accepted music and mostly ignored it, simple users would not
understand what it does, and advanced users would not either.

 And i want to enter notes, not some \overridden  \layoutish
 ##Scheme##  :( :( :(

Nobody keeps you from entering \compressFullBarRests and stuff right in
your music.  That's their default place of writing them.

As a programmer, I prefer putting the declarations where they make sense
and apply document-wide.  Nobody forces you to do it in that manner if
you prefer jamming everything explicitly into the music which, after
all, is the designed user interface for it.

[\layout-from]

 It is a bit wonky, but should work for most purposes.

 At least it works with

    \layout-from \accidentalStyle dodecaphonic

 and with the above example.

 Wow, thanks!  I hope that i understand what it does and that i'll be
 able to use it :)

It is wonky mostly because we don't have a Scheme interface to context
definitions (so I have to use #{ ... #} and fudge around with module-ref
and module-set! inside).  I am actually surprised it works.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-04 Thread m...@apollinemike.com


On Jan 5, 2012, at 1:20 AM, Janek Warchoł wrote:

 Correct me if i'm wrong, but my impression is that
 there is no particular direction in which we are going.
 

I think that it is very difficult to set these goals because different things 
interest different people.  I know that Bertrand and I are chipping away at a 
long standing markup-improvement goal, and I'd like to get smoother 
2D-object-on-the-plane-distance handling, and there's my dream of implementing 
some sort of mixed-integer-quadratic-programming engine in LilyPond (I did some 
tests with quantizing quadratic functions using linear functions, but it 
generates at least 1056 variables for a 500-measure score with 33 
columns per measure and normal line widths quantized at horizontal intervals of 
0.01...).

I'm sure that other people have their pet projects as well.  The ensemble of 
these projects is the direction of LilyPond, and I don't see why it would 
need more of a direction that that.  In fact, I think that it is because of 
some sorta unified direction that for-profit programs can often miss out on 
adding experimental or innovative features.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-03 Thread Phil Holmes

- Original Message - 
From: David Kastrup d...@gnu.org

To: lilypond-devel@gnu.org
Sent: Tuesday, January 03, 2012 7:55 AM
Subject: Re: critical issues

Graham Percival gra...@percival-music.ca writes:

On Tue, Jan 03, 2012 at 01:03:08AM +0100, David Kastrup wrote:

Graham Percival gra...@percival-music.ca writes:

 We could certainly consider dropping support for OSX or windows.

That sort of token solidarity is actually counterproductive:
if you believe that non-releases lead to non-users,

yes

and you think that
non-releases for GNU/Linux may pressure GNU/Linux developers into making
OSX/Windows releases,

no

then how does a non-release for GNU/Linux, with
its corresponding result in decreasing GNU/Linux users and GNU/Linux
developers, help in recruiting GNU/Linux developers that can be
pressured into making OSX and Windows releases?

it doesn't?

Exactly.

Suppose we announce a big new shiny lilypond 2.16.  For linux and
freebsd only.  OSX and windows users can go screw themselves.

We are not announcing a big new shiny Lilypond 2.16.  We are announcing
big new shiny 2.15.xx developer releases one after another.  For
GNU/Linux and FreeBSD only.

N.  I'm happily running pretty much every 2.15 version on my Windows 
box.  It runs fine and it's my normal music-producing environment, and also 
the one on which I test for bugs and get examples to add to the tracker. 
AFAIK the only problem is with lilypond-book, which I personally don't run 
on my windows machine.

OSX and Windows users _are_ second class (or handicapped) citizens for
LilyPond because the whole technology is based on GNU, and since the
developer skills needed to work with it strongly correlate with
UNIX-like systems.  The whole point of GUB is that it is a _cross_
building ennvironment that can be maintained by GNU/Linux developers for
the sake of OSX and Windows users.  The skill level for actively keeping
GUB working (rather than plug and pray) is considerable, and requires
good GNU/Linux (or at least UNIX) skills and at least contact skills
with OSX and Windows.  Without a healthy surplus of GNU/Linux-based
developers that are not already locked down with keeping up their own
projects, our OSX and Windows users can indeed, as you so flowery put
it, can go screw themselves because they can't hope to screw with
LilyPond, rather pure UNIX-based technology requiring UNIX-centric skill
sets and mind frames.

There is a _reason_ the remaining OSX and Windows based developers are
doing (definitely important) documentation and web site work.  They are
to a large degree locked out and dependent on support from surplus
GNU/Linux-based developer capacities.  We are not doing them any favors
by killing LilyPond development as a whole out of sympathy with their
plight.

Not at all.  I think you know that myself and James are mainly Windows 
users.  We also run big Ubuntu machines that support the build environment. 
However, we came to the development from being Windows users.  Cut off that 
supply and I'll probably stop supporting Lily, which I would regret.

- what does this do to our ONLY documentation writers and
  reviewers (who are all windows-based)?  Will they be a) more
  motivated to work on lilypond, b) no change, or c) less
  motivated?

We are already screwing them over with GNU/Linux-only developer
releases.  When will we stop using our Windows and OSX developers as an
excuse for not working on a stable release that would actually warrant
the effort of getting GUB working again and matched to current Windows
and OSX releases?

Not true - see above.

--
Phil Holmes

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

Phil Holmes m...@philholmes.net writes:

 From: David Kastrup d...@gnu.org
 To: lilypond-devel@gnu.org

 There is a _reason_ the remaining OSX and Windows based developers
 are doing (definitely important) documentation and web site work.
 They are to a large degree locked out and dependent on support from
 surplus GNU/Linux-based developer capacities.  We are not doing them
 any favors by killing LilyPond development as a whole out of sympathy
 with their plight.

 Not at all.  I think you know that myself and James are mainly Windows
 users.  We also run big Ubuntu machines that support the build
 environment. However, we came to the development from being Windows
 users.  Cut off that supply and I'll probably stop supporting Lily,
 which I would regret.

You are compiling your own binaries without using GNU/Linux in the
process?

That's what a native development environment would look like.

 - what does this do to our ONLY documentation writers and
   reviewers (who are all windows-based)?  Will they be a) more
   motivated to work on lilypond, b) no change, or c) less
   motivated?

 We are already screwing them over with GNU/Linux-only developer
 releases.  When will we stop using our Windows and OSX developers as
 an excuse for not working on a stable release that would actually
 warrant the effort of getting GUB working again and matched to
 current Windows and OSX releases?

 Not true - see above.

Documentation and web writing without a functional lilypond-book strikes
me as somewhat difficult.

It is nice that things are not as completely broken as I thought.  But I
still think that our effectively current philosophy of the next stable
release is something only developers interested in Windows and OSX need
to concern themselves with is doing anybody a favor.  Our road map has
nothing to offer beyond GUB, and so there is little interest in getting
even there.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-03 Thread Phil Holmes

- Original Message - 
From: David Kastrup d...@gnu.org

To: lilypond-devel@gnu.org
Sent: Tuesday, January 03, 2012 11:44 AM
Subject: Re: critical issues

Phil Holmes m...@philholmes.net writes:

From: David Kastrup d...@gnu.org
To: lilypond-devel@gnu.org

There is a _reason_ the remaining OSX and Windows based developers
are doing (definitely important) documentation and web site work.
They are to a large degree locked out and dependent on support from
surplus GNU/Linux-based developer capacities.  We are not doing them
any favors by killing LilyPond development as a whole out of sympathy
with their plight.

Not at all.  I think you know that myself and James are mainly Windows
users.  We also run big Ubuntu machines that support the build
environment. However, we came to the development from being Windows
users.  Cut off that supply and I'll probably stop supporting Lily,
which I would regret.

You are compiling your own binaries without using GNU/Linux in the
process?

That's what a native development environment would look like.

No.  I have an Ubuntu VM which I use for quick experiments and a very fast 
Ubuntu PC which I use for full builds.  But I support lilypond because I 
_use_ it for typesetting music on a _Windows_ machine. Take away that 
ability to use it, and the sesire to support goes away.

- what does this do to our ONLY documentation writers and
  reviewers (who are all windows-based)?  Will they be a) more
  motivated to work on lilypond, b) no change, or c) less
  motivated?

We are already screwing them over with GNU/Linux-only developer
releases.  When will we stop using our Windows and OSX developers as
an excuse for not working on a stable release that would actually
warrant the effort of getting GUB working again and matched to
current Windows and OSX releases?

Not true - see above.

Documentation and web writing without a functional lilypond-book strikes
me as somewhat difficult.

I don't use lilypond-book for day-day activity - only lilypond development.

It is nice that things are not as completely broken as I thought.  But I
still think that our effectively current philosophy of the next stable
release is something only developers interested in Windows and OSX need
to concern themselves with is doing anybody a favor.  Our road map has
nothing to offer beyond GUB, and so there is little interest in getting
even there.

I think you've mis-stated the philosophy.  It's the next stable release is 
something that will benefit users of many operating systems, including many 
flavours of Unix, plus windows and MAC.

--
Phil Holmes

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

Phil Holmes m...@philholmes.net writes:

 From: David Kastrup d...@gnu.org
 To: lilypond-devel@gnu.org
 Sent: Tuesday, January 03, 2012 11:44 AM
 Subject: Re: critical issues

 Phil Holmes m...@philholmes.net writes:

 From: David Kastrup d...@gnu.org
 To: lilypond-devel@gnu.org

 There is a _reason_ the remaining OSX and Windows based developers
 are doing (definitely important) documentation and web site work.
 They are to a large degree locked out and dependent on support from
 surplus GNU/Linux-based developer capacities.  We are not doing them
 any favors by killing LilyPond development as a whole out of sympathy
 with their plight.

 Not at all.  I think you know that myself and James are mainly Windows
 users.  We also run big Ubuntu machines that support the build
 environment. However, we came to the development from being Windows
 users.  Cut off that supply and I'll probably stop supporting Lily,
 which I would regret.

 You are compiling your own binaries without using GNU/Linux in the
 process?

 That's what a native development environment would look like.

 No.  I have an Ubuntu VM which I use for quick experiments and a very
 fast Ubuntu PC which I use for full builds.  But I support lilypond
 because I _use_ it for typesetting music on a _Windows_ machine. Take
 away that ability to use it, and the sesire to support goes away.

Yup, and our current effective strategy of not doing stable releases
takes away that ability from anyone.  Not just Windows users.

 It is nice that things are not as completely broken as I thought.
 But I still think that our effectively current philosophy of the
 next stable release is something only developers interested in
 Windows and OSX need to concern themselves with is doing anybody a
 favor.  Our road map has nothing to offer beyond GUB, and so there is
 little interest in getting even there.

 I think you've mis-stated the philosophy.  It's the next stable
 release is something that will benefit users of many operating
 systems, including many flavours of Unix, plus windows and MAC.

That's the vision.  The vision can't replace the road leading to it.
The only roadmap we have is critical issues, and none of the critical
issues are anything that could be tackled by anybody rather than
developers with quite special skills and interests.  If all of the
critical issues go away over night for some reason, we still have
nothing that can in good conscience be sold as stable release.  And by
the time we get there, GUB will probably have acquired enough fresh bit
rot that we will be in the same situation as we are now.

If we refuse thinking about stable releases by taking GUB as an excuse,
the grand next stable release that will benefit users of many operating
systems is likely to fall in the class too little, too late.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-03 Thread Phil Holmes

- Original Message - 
From: David Kastrup d...@gnu.org

To: Phil Holmes m...@philholmes.net

No.  I have an Ubuntu VM which I use for quick experiments and a very
fast Ubuntu PC which I use for full builds.  But I support lilypond
because I _use_ it for typesetting music on a _Windows_ machine. Take
away that ability to use it, and the desire to support goes away.

Yup, and our current effective strategy of not doing stable releases
takes away that ability from anyone.  Not just Windows users.

Personally, I'm quite happy using a development version for my music 
typesetting.  If the most recent one causes a problem, I revert to the 
previous version.

--
David Kastrup

--
Phil Holmes

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-03 Thread Werner LEMBERG


 If we refuse thinking about stable releases by taking GUB as an
 excuse, the grand next stable release that will benefit users of
 many operating systems is likely to fall in the class too little,
 too late.

I second David.  Given that we develop within a GNU environment, bugs
specific to Windows and Mac shouldn't prevent stable releases.  I can
even imagine that well announced release candidates for a new stable
version attracts developers to help fix issues with problematic
platforms.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-03 Thread m...@apollinemike.com

On Jan 3, 2012, at 1:36 PM, Werner LEMBERG wrote:

 
 If we refuse thinking about stable releases by taking GUB as an
 excuse, the grand next stable release that will benefit users of
 many operating systems is likely to fall in the class too little,
 too late.
 
 I second David.  Given that we develop within a GNU environment, bugs
 specific to Windows and Mac shouldn't prevent stable releases.  I can
 even imagine that well announced release candidates for a new stable
 version attracts developers to help fix issues with problematic
 platforms.
 

One in-the-middle approach is to check out package managers that are offering 
LilyPond releases.  I know, for example, that brew offers a version of LilyPond 
on Mac OS X.  If we provide a list of package managers and how-tos for the 
techno-phobic, that may be enough to maintain (and even grow) the user base.  
It has the added benefit of pointing people to better resources than those we 
could maintain in-house: I think that jEdit plus the brew version of LilyPond, 
for example, is a more compelling package than the GUI we distribute.

Does Windows have its share of package managers that offer this sorta thing?

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-03 Thread Han-Wen Nienhuys

On Tue, Jan 3, 2012 at 10:36 AM, Werner LEMBERG w...@gnu.org wrote:
 If we refuse thinking about stable releases by taking GUB as an
 excuse, the grand next stable release that will benefit users of
 many operating systems is likely to fall in the class too little,
 too late.

 I second David.  Given that we develop within a GNU environment, bugs
 specific to Windows and Mac shouldn't prevent stable releases.  I can
 even imagine that well announced release candidates for a new stable
 version attracts developers to help fix issues with problematic
 platforms.

From a support perspective, not releasing the windows and mac versions
at the same time is problematic.  Many questions and bugreports that
could be answered with upgrade to the latest version all of a sudden
start depending on the platform that the user is using. Also, it makes
it more difficult to get users to pay for work, since users won't pay
if you don't release the work to their platform

I fully sympathize with the desire to junk Mac and Windows for being a
pains in the asses to develop for, but they are the platforms where
the majority of the users are. We (Jan and I) made a conscious
decision that having more users is better for lilypond than saving
some developer resources over not distributing windows/mac binaries.

 Given that we develop within a GNU environment, bugs
 specific to Windows and Mac shouldn't prevent stable releases

I don't see how this reasoning works. You do stable releases for
users, not developers.

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

Werner LEMBERG w...@gnu.org writes:

 If we refuse thinking about stable releases by taking GUB as an
 excuse, the grand next stable release that will benefit users of
 many operating systems is likely to fall in the class too little,
 too late.

 I second David.  Given that we develop within a GNU environment, bugs
 specific to Windows and Mac shouldn't prevent stable releases.

The problem is not that bugs specific to Windows and Mac would be
preventing stable releases.  The problem is that we have a _number_ of
problems preventing a stable release, and we are not addressing them
because Mac and Windows provide a convenient excuse.

The Learning Guide and the Notation Guide need a complete rereading and
reorganization, and it is not like the Extending Guide is in
significantly better shape.  There are only few languages for which the
translations can be considered maintained.

Stuff like that picks up considerably after stable releases since the
motivation to help with documenting something that will take years
before the helper gets to see it (and fresh blood tends to get started
on stable releases) is limited.

 I can even imagine that well announced release candidates for a new
 stable version attracts developers to help fix issues with problematic
 platforms.

If you take a look at Ubuntu release candidates, they usually start with
a list of caveats concerning computers and applications that won't run
at all.  You need to _start_ with the work for cutting out a release
before it is magically finished.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-03 Thread James

Hello,

On 3 January 2012 12:53, Han-Wen Nienhuys hanw...@gmail.com wrote:
 On Tue, Jan 3, 2012 at 10:36 AM, Werner LEMBERG w...@gnu.org wrote:
 If we refuse thinking about stable releases by taking GUB as an
 excuse, the grand next stable release that will benefit users of
 many operating systems is likely to fall in the class too little,
 too late.

 I second David.  Given that we develop within a GNU environment, bugs
 specific to Windows and Mac shouldn't prevent stable releases.  I can
 even imagine that well announced release candidates for a new stable
 version attracts developers to help fix issues with problematic
 platforms.

 From a support perspective, not releasing the windows and mac versions
 at the same time is problematic.  Many questions and bugreports that
 could be answered with upgrade to the latest version all of a sudden
 start depending on the platform that the user is using.

Yes, Han-Wen beat me to that point.

So if 2.14 works on OSX but 2.16 doesn't then the user has no choice
but to stick with 2.14 or use a 2.15 branch both which are no no
longer being developed.

That is a pain to troubleshoot

There is some wonderful work gone into 2.15 that isn't (and never will
be in 2.14) that the user-base will miss out on.


 Given that we develop within a GNU environment, bugs
 specific to Windows and Mac shouldn't prevent stable releases

 I don't see how this reasoning works. You do stable releases for
 users, not developers.

Beautifully put.

As a side note, I came to LP via MacOS X + Lilypad, and ran with
windows only because it is my OS at work. Now I use Linux for all my
LP work and LilyDev in a VM for Dev and doc work (so LilyPond-Book is
not a problem for me and having LilyDev in a VM even if it is in a
Linux OS itself - allows me to use VBox's snapshot for testing or
reverting when I run into git issues or build issues), in fact my
Windows LP work is virtually nil now, unless a user or dev asks for
some second verification.

My question to David, because I am not getting where the 'ire' is
coming from, why do you care if we release dev after dev release vs
stable?

-- 
--

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

m...@apollinemike.com m...@apollinemike.com writes:

 One in-the-middle approach is to check out package managers that are
 offering LilyPond releases.  I know, for example, that brew offers a
 version of LilyPond on Mac OS X.  If we provide a list of package
 managers and how-tos for the techno-phobic, that may be enough to
 maintain (and even grow) the user base.  It has the added benefit of
 pointing people to better resources than those we could maintain
 in-house: I think that jEdit plus the brew version of LilyPond, for
 example, is a more compelling package than the GUI we distribute.

It sounds to me like Frescobaldi might be a nice base for a good total
package for systems with GUI-centric use patterns.  I have looked at
neither LilyPondTool nor Frescobaldi myself (GUIs are totally not my
thing), but maintaining a compelling GUI/editing package requires a
constant and focused effort, and I have the vague impression that
Frescobaldi is maintained with more of a core vengeance rather than an
addon spirit.

Emacs could be a nice package as well since its info reader beats every
other Lilypond information system hollow (unless you get precompiled
info files without included images in which case it is mostly
pointless), but its support of ly and lytex (and, to a degree, itexi) is
not as strong as to put it solidly ahead of the glorified duct tape
class.  Tying lytex, ly, and itexi into the AUCTeX machinery would make
a very impressive offering, but that would entail quite a bit of work.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

Han-Wen Nienhuys hanw...@gmail.com writes:

 On Tue, Jan 3, 2012 at 10:36 AM, Werner LEMBERG w...@gnu.org wrote:
 If we refuse thinking about stable releases by taking GUB as an
 excuse, the grand next stable release that will benefit users of
 many operating systems is likely to fall in the class too little,
 too late.

 I second David.  Given that we develop within a GNU environment, bugs
 specific to Windows and Mac shouldn't prevent stable releases.  I can
 even imagine that well announced release candidates for a new stable
 version attracts developers to help fix issues with problematic
 platforms.

 From a support perspective, not releasing the windows and mac versions
 at the same time is problematic.  Many questions and bugreports that
 could be answered with upgrade to the latest version all of a sudden
 start depending on the platform that the user is using. Also, it makes
 it more difficult to get users to pay for work, since users won't pay
 if you don't release the work to their platform

Which is exactly the situation that we find ourselves in already.

 I fully sympathize with the desire to junk Mac and Windows for being a
 pains in the asses to develop for, but they are the platforms where
 the majority of the users are. We (Jan and I) made a conscious
 decision that having more users is better for lilypond than saving
 some developer resources over not distributing windows/mac binaries.

Sure, but we are not talking about junking Mac and Windows, but about
junking using them as a cheap excuse for losing sight of stable release
criteria altogether.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

James pkx1...@gmail.com writes:

 Hello,

 On 3 January 2012 12:53, Han-Wen Nienhuys hanw...@gmail.com wrote:
 On Tue, Jan 3, 2012 at 10:36 AM, Werner LEMBERG w...@gnu.org wrote:
 If we refuse thinking about stable releases by taking GUB as an
 excuse, the grand next stable release that will benefit users of
 many operating systems is likely to fall in the class too little,
 too late.

 I second David.  Given that we develop within a GNU environment, bugs
 specific to Windows and Mac shouldn't prevent stable releases.  I can
 even imagine that well announced release candidates for a new stable
 version attracts developers to help fix issues with problematic
 platforms.

 From a support perspective, not releasing the windows and mac versions
 at the same time is problematic.  Many questions and bugreports that
 could be answered with upgrade to the latest version all of a sudden
 start depending on the platform that the user is using.

 Yes, Han-Wen beat me to that point.

 So if 2.14 works on OSX but 2.16 doesn't then the user has no choice
 but to stick with 2.14 or use a 2.15 branch both which are no no
 longer being developed.

Newsflash: 2.16 does not work on OSX.  Nor does it work on any other
platform.  The user has no choice but to stick with 2.14 or use a 2.15
branch which does not apparently work on OSX.

 That is a pain to troubleshoot

 There is some wonderful work gone into 2.15 that isn't (and never will
 be in 2.14) that the user-base will miss out on.

Newsflash: it is already missing out.

 As a side note, I came to LP via MacOS X + Lilypad, and ran with
 windows only because it is my OS at work. Now I use Linux for all my
 LP work and LilyDev in a VM for Dev and doc work (so LilyPond-Book is
 not a problem for me and having LilyDev in a VM even if it is in a
 Linux OS itself - allows me to use VBox's snapshot for testing or
 reverting when I run into git issues or build issues), in fact my
 Windows LP work is virtually nil now, unless a user or dev asks for
 some second verification.

This does not exactly make a strong point about the ability of Windows
to attract development.

 My question to David, because I am not getting where the 'ire' is
 coming from, why do you care if we release dev after dev release vs
 stable?

URL:http://xkcd.com/386/

If we look beyond that personality trait, I have a financial interest in
LilyPond becoming a package attractive to people with more money than
programming skills.  A stable release for which the stability and
usability aim is more than just mostly works on OSX and Windows would
be helpful to point to.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012/1/3 Graham Percival gra...@percival-music.ca:
 It so happens that none of these Critical issues are really
 fixable by reverting a single commit.

 [...]

ok, thanks for this explanation!

 Is finding them an easy (no knowledge
 needed, a complete set of dumbed-down instructions can be given) task
 that can be done using a moderately fast computer running lilydev (1,5
 GB RAM for virtual machine, processor Core i5 2.5 GHz and no idea if
 multicore thingy translates to virtual machine)?

 when the problem *is* in the lilypond code base, yes it's
 brain-dead easy to identify the problematic commit.  Instructions
 are already in the CG -- look in the regressions chapter.

Silly me, i forgot about that.


2012/1/3 David Kastrup d...@gnu.org:
 The Learning Guide and the Notation Guide need a complete rereading and
 reorganization, and it is not like the Extending Guide is in
 significantly better shape.

I'd like to fix them too, but i don't have time for everything i want
:(  Splitting my time doesn't look like a good idea - it's more
effective when i put all my foxus on one thing, analyze it deeply and
make a complete solution than swap issues.  I have to choose and i
choose improving graphical output.

 I can even imagine that well announced release candidates for a new
 stable version attracts developers to help fix issues with problematic
 platforms.

 If you take a look at Ubuntu release candidates, they usually start with
 a list of caveats concerning computers and applications that won't run
 at all.  You need to _start_ with the work for cutting out a release
 before it is magically finished.

Indeed this looks like a good point.

Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

Janek Warchoł janek.lilyp...@gmail.com writes:

 2012/1/3 David Kastrup d...@gnu.org:
 The Learning Guide and the Notation Guide need a complete rereading and
 reorganization, and it is not like the Extending Guide is in
 significantly better shape.

 I'd like to fix them too, but i don't have time for everything i want
 :(  Splitting my time doesn't look like a good idea - it's more
 effective when i put all my foxus on one thing, analyze it deeply and
 make a complete solution than swap issues.  I have to choose and i
 choose improving graphical output.

I am a TeX specialist, system programmer, Emacs specialist, the GNU
maintainer (and a rather pitiful one) for AUCTeX (lytex and itexi
anybody? preview-latex for Lilypond?), know how to make Emacs read data
from Midi ports, am pretty good concerning compiler writing, shell
scripting, general programming, efficient algorithms, am the resident
quiz person for git and so on and so on.

I would have no problems spending a few hundred man years focused on
Lilypond.  Except that I don't have a few hundred man years.  Nobody
has.  The next best option is spending time on multipliers.  Getting
LilyPond in a shape where passersby find it intriguing, to a degree
where they get hooked and contribute manmonths of work over some time
without having planned to do so at the start.

LilyPond has great infrastructure: it makes by far the most from Texinfo
from any application I know, with much better HTML than upstream, far
more thorough and good use of images (only useful in HTML or with Emacs
as info reader, I am afraid).  I have no clue why or how GUB works, but
many others don't have something like that.  It has good facilities for
internationalization.  There are other novel pieces that turn out to be
more of a maintenance problem than an asset because of a total lack of
documentation and/or mindshare: yaffut, the organization of the C++
core, many internals, stepmake, ...  Many corners are lying dormant
since their respective driving force went away or lost interest or time.

I don't manage to keep up with code reviews and am pretty sure that
there are maintenance time bombs creeping in all the while.

The only thing that is going to help is more eyes, more people who get
interested, more people discovering dark corners and doing something
about them.  LilyPond needs to get into a state where, say, half the
engravers are written and maintained in Scheme.  And by Scheme I don't
mean Scheme at the level Nicolas can barely handle but Scheme a
Fortran programmer would not have all too much of a problem
understanding.

To get there, we need serious programmers and serious musicians
interested seriously in LilyPond.  To a level where they start asking
good questions.  And we better be in a position to provide answers,
since there is no more effective way to spend our time than on getting
more people to spend their time, and love, and interest.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012/1/3 David Kastrup d...@gnu.org:
 Janek Warchoł janek.lilyp...@gmail.com writes:

 2012/1/3 David Kastrup d...@gnu.org:
 The Learning Guide and the Notation Guide need a complete rereading and
 reorganization, and it is not like the Extending Guide is in
 significantly better shape.

 I'd like to fix them too, but i don't have time for everything i want
 :(  Splitting my time doesn't look like a good idea - it's more
 effective when i put all my foxus on one thing, analyze it deeply and
 make a complete solution than swap issues.  I have to choose and i
 choose improving graphical output.

 I am a TeX specialist, system programmer, Emacs specialist, the GNU
 maintainer (and a rather pitiful one) for AUCTeX (lytex and itexi
 anybody? preview-latex for Lilypond?), know how to make Emacs read data
 from Midi ports, am pretty good concerning compiler writing, shell
 scripting, general programming, efficient algorithms, am the resident
 quiz person for git and so on and so on.

 I would have no problems spending a few hundred man years focused on
 Lilypond.  Except that I don't have a few hundred man years.  Nobody
 has.  The next best option is spending time on multipliers.  Getting
 LilyPond in a shape where passersby find it intriguing, to a degree
 where they get hooked and contribute manmonths of work over some time
 without having planned to do so at the start.

+1

 LilyPond has great infrastructure: it makes by far the most from Texinfo
 from any application I know, with much better HTML than upstream, far
 more thorough and good use of images (only useful in HTML or with Emacs
 as info reader, I am afraid).  I have no clue why or how GUB works, but
 many others don't have something like that.  It has good facilities for
 internationalization.  There are other novel pieces that turn out to be
 more of a maintenance problem than an asset because of a total lack of
 documentation and/or mindshare: yaffut, the organization of the C++
 core, many internals, stepmake, ...  Many corners are lying dormant
 since their respective driving force went away or lost interest or time.

 I don't manage to keep up with code reviews and am pretty sure that
 there are maintenance time bombs creeping in all the while.

 The only thing that is going to help is more eyes, more people who get
 interested, more people discovering dark corners and doing something
 about them.

+1

 LilyPond needs to get into a state where, say, half the
 engravers are written and maintained in Scheme.  And by Scheme I don't
 mean Scheme at the level Nicolas can barely handle but Scheme a
 Fortran programmer would not have all too much of a problem
 understanding.

Umm, impossible?  From my perspective, 'Scheme' and 'easy to
understand' are mutually exclusive.  Unless there are more comments
than code - literally - but we don't do so.

 To get there, we need serious programmers and serious musicians
 interested seriously in LilyPond.  To a level where they start asking
 good questions.  And we better be in a position to provide answers,
 since there is no more effective way to spend our time than on getting
 more people to spend their time, and love, and interest.

That's like + from me!
In general, i agree that we should think in a more 'release-oriented'
way (last stable release was half a year ago, so we should make
another one, so i'm fixing whatever needs to be fixed to make this
possible) instead of 'free coding' way (i care about this issue,
i'll fix it.  And that one.  Oh, we have 0 criticals, so let's make a
stable release before an obstruction occurs!).  To do so, we would
have to work more as a team, less independently.  How can we achieve
that if GOP7 showed that we don't want to?

By the way, you mentioned earlier that there are issues much more
severe and threatening to Lily 'stability' than those currently marked
as critical.  This made me curious.  Can you elaborate?

 And we better be in a position to provide answers,
 since there is no more effective way to spend our time than on getting
 more people to spend their time, and love, and interest.

The only easy way of moving towards this goal which i see is adding
comments to the code, explaining what it does (and thus making it
easier to provide answers).  Some time ago i was looking at horizontal
spacing code and i didn't understand anything.  I was also recently
trying to make Lily place augmentation dot differently with my friend
Luke (who is, unlike me, a programmer) - it took us a few hours to
figure it out.  I seriously think that Lily code could (and should) be
better described internally.  What do you think?

thanks,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues -- hope you're having fun

2012-01-03 Thread Graham Percival

On Tue, Jan 03, 2012 at 02:57:24PM +0100, David Kastrup wrote:
 James pkx1...@gmail.com writes:
 
  My question to David, because I am not getting where the 'ire' is
  coming from, why do you care if we release dev after dev release vs
  stable?

Yeah, especially since Carl was *already* making good progress on
the GUB-related critical issues.

 URL:http://xkcd.com/386/

yep.

Let's cut to the chase: I am an evil semi-overlord.  I jealously
guard my ssh login to lilypond.org (along with Han-Wen's and
Jan's), I am fickle, and I like to play with small kittens.  Due
to my evil fickle nature, I am not going to change the stated
policy until it has been in place for at least 12 months.  Any
critical issue will block a stable release.  I am chuckling
maniacally and delighting in how evil and wrong I am being.

Don't like it?  You have three (effective) options:
1. don't add regressions.
2. fix (or help fix) any critical issues.
3. build your own binary releases.



Finally: I bet that Hitler had strong opinions on when open-source
projects should release stable versions.

Hugs and kisses,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues -- hope you're having fun

2012-01-03 Thread James

Hello,

On 3 January 2012 20:49, Graham Percival gra...@percival-music.ca wrote:
 On Tue, Jan 03, 2012 at 02:57:24PM +0100, David Kastrup wrote:
 James pkx1...@gmail.com writes:

  My question to David, because I am not getting where the 'ire' is
  coming from, why do you care if we release dev after dev release vs
  stable?

 Yeah, especially since Carl was *already* making good progress on
 the GUB-related critical issues.

 URL:http://xkcd.com/386/

 yep.

 Let's cut to the chase: I am an evil semi-overlord.  I jealously
 guard my ssh login to lilypond.org (along with Han-Wen's and
 Jan's), I am fickle, and I like to play with small kittens.  Due
 to my evil fickle nature, I am not going to change the stated
 policy until it has been in place for at least 12 months.  Any
 critical issue will block a stable release.  I am chuckling
 maniacally and delighting in how evil and wrong I am being.

 Don't like it?  You have three (effective) options:
 1. don't add regressions.
 2. fix (or help fix) any critical issues.
 3. build your own binary releases.



 Finally: I bet that Hitler had strong opinions on when open-source
 projects should release stable versions.

 Hugs and kisses,
 - Graham

http://en.wikipedia.org/wiki/Godwin's_law

!

-- 
--

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues -- hope you're having fun

Graham Percival gra...@percival-music.ca writes:

 On Tue, Jan 03, 2012 at 02:57:24PM +0100, David Kastrup wrote:
 James pkx1...@gmail.com writes:
 
  My question to David, because I am not getting where the 'ire' is
  coming from, why do you care if we release dev after dev release vs
  stable?

 Yeah, especially since Carl was *already* making good progress on
 the GUB-related critical issues.

 URL:http://xkcd.com/386/

 yep.

 Let's cut to the chase: I am an evil semi-overlord.  I jealously
 guard my ssh login to lilypond.org (along with Han-Wen's and
 Jan's), I am fickle, and I like to play with small kittens.  Due
 to my evil fickle nature, I am not going to change the stated
 policy until it has been in place for at least 12 months.  Any
 critical issue will block a stable release.  I am chuckling
 maniacally and delighting in how evil and wrong I am being.

 Don't like it?  You have three (effective) options:
 1. don't add regressions.

The problem is that this actually falls into the categories
1a) don't mention regressions
1b) don't make significant enhancements
1c) don't contribute enhancements

 2. fix (or help fix) any critical issues.

This is usually implemented as
2a) shrug your shoulders since they don't concern you and wait another
year.

 3. build your own binary releases.

Usually done as

3a) never mind, I got my own checkout.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

Janek Warchoł janek.lilyp...@gmail.com writes:

 2012/1/3 David Kastrup d...@gnu.org:

 LilyPond needs to get into a state where, say, half the
 engravers are written and maintained in Scheme.  And by Scheme I don't
 mean Scheme at the level Nicolas can barely handle but Scheme a
 Fortran programmer would not have all too much of a problem
 understanding.

 Umm, impossible?  From my perspective, 'Scheme' and 'easy to
 understand' are mutually exclusive.  Unless there are more comments
 than code - literally - but we don't do so.

Well, as an example, take a look at
URL:http://nicolas.sceaux.free.fr/prelude/prelude.html

Now take a look at

\begin{lilypond}
ph = #(define-music-function (parser location p1 p2 p3 p4 p5)
   (ly:pitch? ly:pitch? ly:pitch? ly:pitch? ly:pitch?)
   #{
  \repeat unfold 2 { $p1 2 } |
  \repeat unfold 2 { r16 $p2 8. ~ $p2 4 } |
  \repeat unfold 2 { r8 $p3 16 $p4 $p5 $p3 $p4 $p5 } |
   #})  
\parallelMusic #'(low middle high)
{
  \ph c'   e'  g' c'' e''
  R1*7 | \skip 1*7 | R1*7 |
  \ph ac'  e' g' c''
  \voiceTwo | \change Staff = down \voiceOne | \oneVoice |
  \ph da   d' fis' c''
  R1*21 | \skip 1*21 | R1*21 |
  \ph c,   c   g bes e'
  c,2~ c, | r16 c8. ~ c4 ~ c2
  | r8 f16 a c' f' c' a c' a f a f d f d |
  c,2~ c, | r16 b,8. ~ b,4 ~ b,2
  | r8 g'16 b' d'' f'' d'' b' d'' b' g' b' d' f' e' d' |
  c,1\fermata | c1 | e' g' c''1\fermata \bar |. |
}
\score {
  \new PianoStaff 
\new Staff = up {
   \high \\ \middle 
}
\new Staff = down {
  \clef bass
  \low
}
  
  
  \midi {
\context {
  \Score
  \with \settingsFrom { \tempo 4 = 80 }
}
  }

  \layout {
\context {
  \Score
  \with \settingsFrom { \compressFullBarRests }
}
\context {
  \Staff
  \with \settingsFrom { \accidentalStyle modern }
}
  }
}  
\end{lilypond}

\ph is a music function written in Scheme.  Can you understand it?
\settingsFrom is actually returning a Scheme expression for \with to
use.  It makes things rather simpler than more complex, even though it
constitutes a Scheme expression.

Scheme is not hard.  Programming is hard.  And there is still far too
much repetitive programming required for stuff that could be handled
using shrinkwrapped tools (\settingsFrom is such a tool) if anybody had
bothered packaging them.  Far too often if I think Ok, task x has no
documented way of dealing with it.  Let's see whether we can find an
undocumented API.  And then I find about 10 files implementing their
own ad hoc API that will break in different ways if one has to change
the data structures at some point of time.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012/1/3 David Kastrup d...@gnu.org:
 Janek Warchoł janek.lilyp...@gmail.com writes:

 2012/1/3 David Kastrup d...@gnu.org:

 LilyPond needs to get into a state where, say, half the
 engravers are written and maintained in Scheme.  And by Scheme I don't
 mean Scheme at the level Nicolas can barely handle but Scheme a
 Fortran programmer would not have all too much of a problem
 understanding.

 Umm, impossible?  From my perspective, 'Scheme' and 'easy to
 understand' are mutually exclusive.  Unless there are more comments
 than code - literally - but we don't do so.

 Well, as an example, take a look at
 URL:http://nicolas.sceaux.free.fr/prelude/prelude.html

Hmm, excuse me while my brain melts ;)

 Now take a look at

 \begin{lilypond}
 ph = #(define-music-function (parser location p1 p2 p3 p4 p5)
       (ly:pitch? ly:pitch? ly:pitch? ly:pitch? ly:pitch?)
       #{
          \repeat unfold 2 { $p1 2 } |
          \repeat unfold 2 { r16 $p2 8. ~ $p2 4 } |
          \repeat unfold 2 { r8 $p3 16 $p4 $p5 $p3 $p4 $p5 } |
       #})
 \parallelMusic #'(low middle high)
 {
  \ph c'   e'  g' c'' e''
  R1*7 | \skip 1*7 | R1*7 |
  \ph a    c'  e' g' c''
  \voiceTwo | \change Staff = down \voiceOne | \oneVoice |
  \ph d    a   d' fis' c''
  R1*21 | \skip 1*21 | R1*21 |
  \ph c,   c   g bes e'
  c,2~ c, | r16 c8. ~ c4 ~ c2
  | r8 f16 a c' f' c' a c' a f a f d f d |
  c,2~ c, | r16 b,8. ~ b,4 ~ b,2
  | r8 g'16 b' d'' f'' d'' b' d'' b' g' b' d' f' e' d' |
  c,1\fermata | c1 | e' g' c''1\fermata \bar |. |
 }
 \score {
  \new PianoStaff 
    \new Staff = up {
       \high \\ \middle 
    }
    \new Staff = down {
      \clef bass
      \low
    }
  

  \midi {
    \context {
      \Score
      \with \settingsFrom { \tempo 4 = 80 }
    }
  }

  \layout {
    \context {
      \Score
      \with \settingsFrom { \compressFullBarRests }
    }
    \context {
      \Staff
      \with \settingsFrom { \accidentalStyle modern }
    }
  }
 }
 \end{lilypond}

 \ph is a music function written in Scheme.  Can you understand it?

Yes, but i get lost on \parallellMusic :(

 \settingsFrom is actually returning a Scheme expression for \with to
 use.  It makes things rather simpler than more complex, even though it
 constitutes a Scheme expression.

Um... i would really love to be able to type
 \layout {
 \compressFullBarRests
 \override Score.SpacingSpanner #'common-shortest-duration =
#(ly:make-moment 6 10)
 etc...
}

 Scheme is not hard.  Programming is hard.  And there is still far too
 much repetitive programming required for stuff that could be handled
 using shrinkwrapped tools (\settingsFrom is such a tool) if anybody had
 bothered packaging them.  Far too often if I think Ok, task x has no
 documented way of dealing with it.  Let's see whether we can find an
 undocumented API.  And then I find about 10 files implementing their
 own ad hoc API that will break in different ways if one has to change
 the data structures at some point of time.

I agree, this should not work like that.

Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

Hi Luke,

nice to see you joining the discussion :)

W dniu 3 stycznia 2012 23:06 użytkownik Łukasz Czerwiński
milimet...@gmail.com napisał:
That's like + from me!
In general, i agree that we should think in a more 'release-oriented'
way (last stable release was half a year ago, so we should make
another one, so i'm fixing whatever needs to be fixed to make this
possible) instead of 'free coding' way (i care about this issue,
i'll fix it. And that one. Oh, we have 0 criticals, so let's make a
stable release before an obstruction occurs!). To do so, we would
have to work more as a team, less independently. How can we achieve
that if GOP7 showed that we don't want to?

and:

And we better be in a position to provide answers,
since there is no more effective way to spend our time than on getting
more people to spend their time, and love, and interest.

Regarding all those fragments of Janek's and David's emails: For some time I
have been observing how bugs are being fixed in Lilypond and spent some time
on conversations with Janek.
For me there is almost no team work in Lilypond - only a bunch of geek
trying to fix some issues, but without a leader who coordinates all actions.

I might have given you a wrong impression, i don't think its really
that bad. There is some teamwork, but no leader indeed.

As far as I remember, some time ago you have tried hard to make some big
changes in Lilypond, but finally there was no big revolution...

Hmm? I remember that i mentioned to you the rewrite of vertical
spacing system, which was implemented quite successfully.

Without a leader that will make key design implementation decisions
Lilypond will improve in a slow pace, letting Finale and Sibellius gain more
and more users. Probably some of you will return to the old row - is a goal
of a Lilypond to substitue Finale or compete with Sibellius. I think there
is no point in loosing your energy and time on that.
Instead we should do as much as possible to constantly improve Lilypond.
That means not only fixing critical bugs, but also: anticipating future
stability problems, constantly improving end user documentation and the
quality of source code (reduce complexity, comment code and so on). By now
there is a huge work to be done and Lilypond needs someone who will form
guidelines and priorities.

That's generally true and i'd love to have a leader and lots of
teamwork, but who would be the leader? It would be a time-consuming
task, none of our current developers has much spare time; it would
also require lots of knowledge, so only few would qualify :(
You might consider reading
http://lilypond.org/doc/v2.15/Documentation/contributor/gop_002dprop-7-_002d-developers-as-resources
It's simply that we discussed this before and didn't manage to do
these (good) things you propose.

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-03 Thread James

hello,

On 3 Jan 2012, at 22:26, Janek Warchoł janek.lilyp...@gmail.com wrote:

 Hi Luke,
 
 nice to see you joining the discussion :)
 
 W dniu 3 stycznia 2012 23:06 użytkownik Łukasz Czerwiński
 milimet...@gmail.com napisał:
 That's like + from me!
 In general, i agree that we should think in a more 'release-oriented'
 way (last stable release was half a year ago, so we should make
 another one, so i'm fixing whatever needs to be fixed to make this
 possible) instead of 'free coding' way (i care about this issue,
 i'll fix it.  And that one.  Oh, we have 0 criticals, so let's make a
 stable release before an obstruction occurs!).  To do so, we would
 have to work more as a team, less independently.  How can we achieve
 that if GOP7 showed that we don't want to?
 
 and:
 
 And we better be in a position to provide answers,
 since there is no more effective way to spend our time than on getting
 more people to spend their time, and love, and interest.
 
 Regarding all those fragments of Janek's and David's emails: For some time I
 have been observing how bugs are being fixed in Lilypond and spent some time
 on conversations with Janek.
 For me there is almost no team work in Lilypond - only a bunch of geek
 trying to fix some issues, but without a leader who coordinates all actions.
 
 I might have given you a wrong impression, i don't think its really
 that bad.  There is some teamwork, but no leader indeed.

to use an English expression ... poppycock!

Janek you may have not noticed that the team of Colin, Phil and myself along 
with some of the bug squad managed, with the the help of Graham (if you want to 
call him a 'leader') to process a quite impressive number of patches. 

Before we managed to get some kind of automation of patch testing I personally 
was fielding about 6 new patches a day, producing reg test diffs, make checks 
and the like. Colin was managing all patch countdown and push requests while 
Phil ran around, figuratively speaking, making sure things were in order in 
terms of regressions between dev releases. all co ordinated by graham - pretty 
much.

in the meantime Mike, Keith, Carl and co had plenty of time then to fix some 
long standing bugs, and I am seeing some serious work by David to do whatever 
it is he does with the parser etc.

All of which we still pretty much managed to keep a relatively stable tree with 
one or two hiccups which considering the amount of pushed changes and the 
fundamental stuff the coders were free to do because of them not having to 
worry about things like ... oh testing their patches don't break the main tree, 
spotting quickly any potential issues or breakages because now they can focus 
on reviews of code than having to administer them, that new features are 
documented and that all emails from users complaining about this and that are 
documented themselves in a tracker completely makes that claim ridiculous and 
rather gets on my wick( to use another expression).

comments like that from Luke are unhelpful, disrespectful to many of us and 
frankly, tedious.


 
 As far as I remember, some time ago you have tried hard to make some big
 changes in Lilypond, but finally there was no big revolution...

Maybe before my time, however instead of complaining how about doing something 
constructive?


 
 Hmm?  I remember that i mentioned to you the rewrite of vertical
 spacing system, which was implemented quite successfully.
 
 Without a leader that will make key design  implementation decisions
 Lilypond will improve in a slow pace, letting Finale and Sibellius gain more
 and more users.

So what?

it's not a competition. 


 Probably some of you will return to the old row - is a goal
 of a Lilypond to substitue Finale or compete with Sibellius. I think there
 is no point in loosing your energy and time on that.

Yet you just did. some of us aren't fixated wit the stupid Sibfib comparison or 
even care. 

 Instead we should do as much as possible to constantly improve Lilypond.
 That means not only fixing critical bugs, but also: anticipating future
 stability problems, constantly improving end user documentation and the
 quality of source code (reduce complexity, comment code and so on). By now
 there is a huge work to be done and Lilypond needs someone who will form
 guidelines and priorities.

yeah, blah blah ... some of us already know and some of us are getting on with 
it instead of complaining.



James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

critical issues


I see the following critical issues:

2160document LILYPOND_WEB_MEDIA_GIT
2100Patch: CG: explanation of branches for the impatient
1948Windows install clobbered system PATH
1943lilypond after 2.15.8 fails on x86 Macs
1933Lilypond-book requires msvcrt again

1933, 1943, 1948 concern proprietary platforms and don't appear to
 be relevant to releasing a version on GNU/Linux.
2100 and 2160are not a concern for users.

There is, actually, a wagonload of other changes underfoot that does not
appear quite compatible with releasing a version called stable to me.
It seems strange to me that the _above_ should be the critical ones.
Critical enough that we don't even bother with trying to stabilize the
remaining situation.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

On Mon, Jan 02, 2012 at 09:59:47PM +0100, David Kastrup wrote:
 
 I see the following critical issues:
-snip-
 
 There is, actually, a wagonload of other changes underfoot that does not
 appear quite compatible with releasing a version called stable to me.
 It seems strange to me that the _above_ should be the critical ones.
 Critical enough that we don't even bother with trying to stabilize the
 remaining situation.

The definition of a Critical issue is given here:
http://lilypond.org/doc/v2.15/Documentation/contributor/gop_002dprop-8-_002d-issue-priorities

This was the result of between 25 to 40 emails in August 2011 on
lilypond-devel.  A quick scan didn't reveal your name amongst
those emails, but we simply cannot afford to revisit every policy
decision every six months because somebody didn't notice or wasn't
interested in the previous discussion.


If you are aware of any other issues which fall under the
definition (i.e. a reproducible failure to build lilypond from
scratch, an unintentional regression, or something which stops a
good contributor from working on lilypond), then please change
that issue to be Type-Critical instead of whatever it is right
now.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

Graham Percival gra...@percival-music.ca writes:

On Mon, Jan 02, 2012 at 09:59:47PM +0100, David Kastrup wrote:

I see the following critical issues:
-snip-

There is, actually, a wagonload of other changes underfoot that does not
appear quite compatible with releasing a version called stable to me.
It seems strange to me that the _above_ should be the critical ones.
Critical enough that we don't even bother with trying to stabilize the
remaining situation.

The definition of a Critical issue is given here:
http://lilypond.org/doc/v2.15/Documentation/contributor/gop_002dprop-8-_002d-issue-priorities

This was the result of between 25 to 40 emails in August 2011 on
lilypond-devel. A quick scan didn't reveal your name amongst
those emails, but we simply cannot afford to revisit every policy
decision every six months because somebody didn't notice or wasn't
interested in the previous discussion.

The labels are not all that interesting to me. If we don't have
developers or users interested in working seriously on or with certain
proprietary platforms, then there is no point in calling those platforms
supported and stopping the release process for those platforms that
_can_ be considered supported.

If you are aware of any other issues which fall under the
definition (i.e. a reproducible failure to build lilypond from
scratch,

On a supported platform. It does not look like there is currently much
sense in calling MacOSX or Windows that.

an unintentional regression, or something which stops a good
contributor from working on lilypond),

That's urgent. But it is not release-relevant since good contributors
don't work on released versions but on the development version. I also
see no point in delaying a stable release because of details that are
not actually worse than at the previous release.

then please change that issue to be Type-Critical instead of whatever
it is right now.

--
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

On Mon, Jan 02, 2012 at 10:23:28PM +0100, David Kastrup wrote:
 Graham Percival gra...@percival-music.ca writes:
 
  This was the result of between 25 to 40 emails in August 2011 on
  lilypond-devel.  A quick scan didn't reveal your name amongst
  those emails, but we simply cannot afford to revisit every policy
  decision every six months because somebody didn't notice or wasn't
  interested in the previous discussion.
 
 The labels are not all that interesting to me.  If we don't have
 developers or users interested in working seriously on or with certain
 proprietary platforms, then there is no point in calling those platforms
 supported and stopping the release process for those platforms that
 _can_ be considered supported.

We could certainly consider dropping support for OSX or windows.
That would eliminate 80% (or more!) of our user base, including
everybody who works on our documentation, plus certain extremely
valuable developer like Carl... but I suppose that, logically
speaking, we could consider it.

I am against that idea.

  If you are aware of any other issues which fall under the
  definition (i.e. a reproducible failure to build lilypond from
  scratch,
 
 On a supported platform.  It does not look like there is currently much
 sense in calling MacOSX or Windows that.

The exact details of the proposal specifies as long as configure
reports no problems, which presumably would fail on osx (unless
it was highly tweaked) or windows.

  an unintentional regression, or something which stops a good
  contributor from working on lilypond),
 
 That's urgent.  But it is not release-relevant since good contributors
 don't work on released versions but on the development version.  I also
 see no point in delaying a stable release because of details that are
 not actually worse than at the previous release.

I understand your point of view.  However, that was not the
decision that we reached during that GOP discussion, and I am not
interested in re-opening that discussion.

Bottom line: I will not be calling anything a stable release, or
even a release candidate, if there are issues which are known to
fall under the current definition of a Critical issue.  I am not
open to changing that definition for at least the next 6 months.
However, lilypond is open-source software; there are no legal
barriers[1] to other people building binaries and distributing
them under whatever name they wanted[2].

[1] other than trademark law.
[2] common practice in open-source software is to release forked
software under a different name than the original to avoid
confusion, but I doubt that this is a legal requirement.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-02 Thread Janek Warchoł

2012/1/2 Graham Percival gra...@percival-music.ca:
 On Mon, Jan 02, 2012 at 10:23:28PM +0100, David Kastrup wrote:
 Graham Percival gra...@percival-music.ca writes:

  This was the result of between 25 to 40 emails in August 2011 on
  lilypond-devel.  A quick scan didn't reveal your name amongst
  those emails, but we simply cannot afford to revisit every policy
  decision every six months because somebody didn't notice or wasn't
  interested in the previous discussion.

 The labels are not all that interesting to me.  If we don't have
 developers or users interested in working seriously on or with certain
 proprietary platforms, then there is no point in calling those platforms
 supported and stopping the release process for those platforms that
 _can_ be considered supported.

I'm seriously interested in using Lily on Windows.  Unfortunately
issues 1933 and 1948 are quite beyond me; i don't even understand what
is written in 1933.  I could try attacking 1948, however, this sounds
like 10+ hours of set-up work and 20+ emails *before* actual fixing
can happen (for my experience level).  I'd prefer to use this time to
do something i'm good at: fixing small things (i'm restoring my
lilydev after three-months pause) and writing well-documented and
cross-linked issues for our tracker (recently i wrote issues
2141-2145, it was really a lot of work to gather all examples and
separate the whole accidental problem into separate, yet meaningful,
issues).
If you think that i really should attack these critical issues at all
costs, let me know and i'll consider it.

 We could certainly consider dropping support for OSX or windows.
 That would eliminate 80% (or more!) of our user base, including
 everybody who works on our documentation, plus certain extremely
 valuable developer like Carl... but I suppose that, logically
 speaking, we could consider it.

 I am against that idea.

+1

I'm also against making a Linux-only release.  While technically
possible, it would introduce a high level of mess.

  an unintentional regression, or something which stops a good
  contributor from working on lilypond),

 That's urgent.  But it is not release-relevant since good contributors
 don't work on released versions but on the development version.  I also
 see no point in delaying a stable release because of details that are
 not actually worse than at the previous release.

Well, i think that this was Graham's desperate try to get us more
involved in maintainability issues.  I support that and i'll look at
issue 2100 as fast as possible,

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

Graham Percival gra...@percival-music.ca writes:

 On Mon, Jan 02, 2012 at 10:23:28PM +0100, David Kastrup wrote:
 Graham Percival gra...@percival-music.ca writes:
 
  This was the result of between 25 to 40 emails in August 2011 on
  lilypond-devel.  A quick scan didn't reveal your name amongst
  those emails, but we simply cannot afford to revisit every policy
  decision every six months because somebody didn't notice or wasn't
  interested in the previous discussion.
 
 The labels are not all that interesting to me.  If we don't have
 developers or users interested in working seriously on or with certain
 proprietary platforms, then there is no point in calling those platforms
 supported and stopping the release process for those platforms that
 _can_ be considered supported.

 We could certainly consider dropping support for OSX or windows.

Stopping releases on GNU/Linux is doing as much for supporting OSX or
Windows as throwing away your supper is doing for supporting starving
children.  That sort of token solidarity is actually counterproductive:
if you believe that non-releases lead to non-users, and you think that
non-releases for GNU/Linux may pressure GNU/Linux developers into making
OSX/Windows releases, then how does a non-release for GNU/Linux, with
its corresponding result in decreasing GNU/Linux users and GNU/Linux
developers, help in recruiting GNU/Linux developers that can be
pressured into making OSX and Windows releases?

 That would eliminate 80% (or more!) of our user base, including
 everybody who works on our documentation, plus certain extremely
 valuable developer like Carl... but I suppose that, logically
 speaking, we could consider it.

 I am against that idea.

Even if we assume that GNU/Linux releases don't help keeping and gaining
OSX and Windows users, this does not imply that not making GNU/Linux
releases helps keeping and gaining OSX and Windows users.

I am afraid that we are painting ourselves into a corner.  And I don't
think that we are doing ourselves a favor by defining stable as a
random moment when somebody managed to get GUB to run for Windows and
OSX.  We should define stable based on the stability and state of the
_actively_ happening development.  _That's_ what we should be cutting
the stable branch from.  And _then_ try getting it ported timely to the
platforms that have, lamentably, a rather lacklustre progress of
releasable material and platform-specific development.  I see very
little correlation between what I'd call a measure of stability, and
what the current set of Critical bugs entails.

 Bottom line: I will not be calling anything a stable release, or
 even a release candidate, if there are issues which are known to
 fall under the current definition of a Critical issue.  I am not
 open to changing that definition for at least the next 6 months.

And nobody feels a need to worry about stability if stable is not
expected to be around the corner anytime soon for reasons out of his
control (you can't expect people working all too much for systems they
do not even have available for testing purposes).

This is not actually supposed to be a discussion from my side.  It's
more like head-scratching.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

On Tue, Jan 03, 2012 at 01:03:08AM +0100, David Kastrup wrote:
 Graham Percival gra...@percival-music.ca writes:
 
  We could certainly consider dropping support for OSX or windows.
 
 That sort of token solidarity is actually counterproductive:
 if you believe that non-releases lead to non-users,

yes

 and you think that
 non-releases for GNU/Linux may pressure GNU/Linux developers into making
 OSX/Windows releases,

no

 then how does a non-release for GNU/Linux, with
 its corresponding result in decreasing GNU/Linux users and GNU/Linux
 developers, help in recruiting GNU/Linux developers that can be
 pressured into making OSX and Windows releases?

it doesn't?


Suppose we announce a big new shiny lilypond 2.16.  For linux and
freebsd only.  OSX and windows users can go screw themselves.

- what does this do to our ONLY documentation writers and
  reviewers (who are all windows-based)?  Will they be a) more
  motivated to work on lilypond, b) no change, or c) less
  motivated?
- what does this do to our active developers, approximately half
  of which are on OSX?  Will they be a) b) or c) ?


 And I don't think that we are doing ourselves a favor by
 defining stable as a random moment when somebody managed to
 get GUB to run for Windows and OSX.

Good news, we're not.  We're definining stable as is not
deliberately worse than the previous release, for all platforms
which we officially release for.  Plus a little bit of ... and
we can reasonably expect a reasonable contributor to be able to
contribute.

I will admit that the latter point could be construed as if we
make it very difficult to contribute to lilypond, then I'm going
to punish everybody by not having stable releases -- but almost
all of those can't-contribute bugs can be fixed in an hour or
two, and is platform-independent (or rather: it only involves
lilydev, which is ubuntu, most often inside virtualbox, so anybody
can work on that).

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-02 Thread Janek Warchoł

2012/1/3 David Kastrup d...@gnu.org:
 I am afraid that we are painting ourselves into a corner.  And I don't
 think that we are doing ourselves a favor by defining stable as a
 random moment when somebody managed to get GUB to run for Windows and
 OSX.  We should define stable based on the stability and state of the
 _actively_ happening development.  _That's_ what we should be cutting
 the stable branch from.  And _then_ try getting it ported timely to the
 platforms that have, lamentably, a rather lacklustre progress of
 releasable material and platform-specific development.  I see very
 little correlation between what I'd call a measure of stability, and
 what the current set of Critical bugs entails.

While this sounds reasonable, i'm not sure if a policy could be
written that would reflect your intentions; they're a bit too vague.
And even with current guidelines its always possible to say i think
that we shouldn't make a stable release despite having 0 critical
issues, because current master is shabby and we have some major
changes going in the codebase.

I think that the problem may be that we don't organize our work (and
don't want to according to GOP7
http://lilypond.org/~graham/gop/gop_7.html).  In fact, we work quite
like a bunch of individuals doing really independent things all the
time; there are little to no efforts like guys, let's fix that and 5
people start collaborating on something.

Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

2012-01-02 Thread Janek Warchoł

(sorry for double-post)

2012/1/2 Graham Percival gra...@percival-music.ca:
 On Mon, Jan 02, 2012 at 10:23:28PM +0100, David Kastrup wrote:
 Graham Percival gra...@percival-music.ca writes:
  If you are aware of any other issues which fall under the
  definition (i.e. a reproducible failure to build lilypond from
  scratch,

 On a supported platform.  It does not look like there is currently much
 sense in calling MacOSX or Windows that.

 The exact details of the proposal specifies as long as configure
 reports no problems, which presumably would fail on osx (unless
 it was highly tweaked) or windows.

  an unintentional regression, or something which stops a good
  contributor from working on lilypond),

 That's urgent.  But it is not release-relevant since good contributors
 don't work on released versions but on the development version.  I also
 see no point in delaying a stable release because of details that are
 not actually worse than at the previous release.

 I understand your point of view.  However, that was not the
 decision that we reached during that GOP discussion, and I am not
 interested in re-opening that discussion.

 Bottom line: I will not be calling anything a stable release, or
 even a release candidate, if there are issues which are known to
 fall under the current definition of a Critical issue.  I am not
 open to changing that definition for at least the next 6 months.
 However, lilypond is open-source software; there are no legal
 barriers[1] to other people building binaries and distributing
 them under whatever name they wanted[2].

By the way, do we have a policy about regressions?  I remember that
reverting bad commits was discussed in the past, and i'm quite for
this solution.
I don't see information about which commits caused our currently open
critical regression, does it mean that's impossible to tell or simply
noone tried to find them?  Is finding them an easy (no knowledge
needed, a complete set of dumbed-down instructions can be given) task
that can be done using a moderately fast computer running lilydev (1,5
GB RAM for virtual machine, processor Core i5 2.5 GHz and no idea if
multicore thingy translates to virtual machine)?

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

On Tue, Jan 03, 2012 at 06:24:19AM +0100, Janek Warchoł wrote:
 By the way, do we have a policy about regressions?

Yes, they're bad?  :)

 I remember that
 reverting bad commits was discussed in the past, and i'm quite for
 this solution.
 I don't see information about which commits caused our currently open
 critical regression, does it mean that's impossible to tell or simply
 noone tried to find them?

It so happens that none of these Critical issues are really
fixable by reverting a single commit.

- lilypond-book came from a general rewrite of lilypond-book.
- osx came from me accepting a GUB patch which had a problem,
  which technically we could revert but it's better to just solve
  the underlying problem.  (and in fact I think it *has* been
  solved)
- windows path isn't strictly a regression, but IMO it screws up
  users' systems in a sufficiently stupid and embarrassing way
  that I'm going to call it Critical anyway.
- git branches comes from staging, which is necessary because
  people kept on breaking git master.
- web-git came from a cleanup of the old website, originating from
  a build system patch of mine, but come on folks, we already have
  a patch for this in the system, don't complain about that issue.

 Is finding them an easy (no knowledge
 needed, a complete set of dumbed-down instructions can be given) task
 that can be done using a moderately fast computer running lilydev (1,5
 GB RAM for virtual machine, processor Core i5 2.5 GHz and no idea if
 multicore thingy translates to virtual machine)?

when the problem *is* in the lilypond code base, yes it's
brain-dead easy to identify the problematic commit.  Instructions
are already in the CG -- look in the regressions chapter.

Cheers
,- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

Graham Percival gra...@percival-music.ca writes:

 On Tue, Jan 03, 2012 at 01:03:08AM +0100, David Kastrup wrote:
 Graham Percival gra...@percival-music.ca writes:
 
  We could certainly consider dropping support for OSX or windows.
 
 That sort of token solidarity is actually counterproductive:
 if you believe that non-releases lead to non-users,

 yes

 and you think that
 non-releases for GNU/Linux may pressure GNU/Linux developers into making
 OSX/Windows releases,

 no

 then how does a non-release for GNU/Linux, with
 its corresponding result in decreasing GNU/Linux users and GNU/Linux
 developers, help in recruiting GNU/Linux developers that can be
 pressured into making OSX and Windows releases?

 it doesn't?

Exactly.

 Suppose we announce a big new shiny lilypond 2.16.  For linux and
 freebsd only.  OSX and windows users can go screw themselves.

We are not announcing a big new shiny Lilypond 2.16.  We are announcing
big new shiny 2.15.xx developer releases one after another.  For
GNU/Linux and FreeBSD only.  And we are not bothering to stabilize
development into a state where it would even make sense to announce 2.16
for anybody.  Or where the effort to bring GUB into release shape would
appear to be worth the trouble.

OSX and Windows users _are_ second class (or handicapped) citizens for
LilyPond because the whole technology is based on GNU, and since the
developer skills needed to work with it strongly correlate with
UNIX-like systems.  The whole point of GUB is that it is a _cross_
building ennvironment that can be maintained by GNU/Linux developers for
the sake of OSX and Windows users.  The skill level for actively keeping
GUB working (rather than plug and pray) is considerable, and requires
good GNU/Linux (or at least UNIX) skills and at least contact skills
with OSX and Windows.  Without a healthy surplus of GNU/Linux-based
developers that are not already locked down with keeping up their own
projects, our OSX and Windows users can indeed, as you so flowery put
it, can go screw themselves because they can't hope to screw with
LilyPond, rather pure UNIX-based technology requiring UNIX-centric skill
sets and mind frames.

There is a _reason_ the remaining OSX and Windows based developers are
doing (definitely important) documentation and web site work.  They are
to a large degree locked out and dependent on support from surplus
GNU/Linux-based developer capacities.  We are not doing them any favors
by killing LilyPond development as a whole out of sympathy with their
plight.

 - what does this do to our ONLY documentation writers and
   reviewers (who are all windows-based)?  Will they be a) more
   motivated to work on lilypond, b) no change, or c) less
   motivated?

We are already screwing them over with GNU/Linux-only developer
releases.  When will we stop using our Windows and OSX developers as an
excuse for not working on a stable release that would actually warrant
the effort of getting GUB working again and matched to current Windows
and OSX releases?

 I will admit that the latter point could be construed as if we
 make it very difficult to contribute to lilypond, then I'm going
 to punish everybody by not having stable releases -- but almost
 all of those can't-contribute bugs can be fixed in an hour or
 two, and is platform-independent (or rather: it only involves
 lilydev, which is ubuntu, most often inside virtualbox, so anybody
 can work on that).

Newsflash: anybody needs considerable GNU/Linux skills to work on
that.  And extra time.  Why should he bother when he can just go on
working with development releases on GNU/Linux?

I don't see GUB catching up without having a feature freeze, the freeze
associated with starting a stable release cycle.  A freeze that actually
_stops_ the releases labelled as development releases in order to hide
the fact that we have stopped actually catering to Windows and OSX users
years ago.  They need actions, not warm wishes and self-flagellation.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: no movement on Critical issues; 2.16 in Oct ?

Graham Percival gra...@percival-music.ca writes:

 I haven't seen any interest in
   http://code.google.com/p/lilypond/issues/detail?id=1771

My take on this (if nobody is going to protest in the next few hours) is
to revert the flawed fix.

Reason: we get rid of a critical issue.

The original bug fixer does not appear to be in the queue for fixing the
effects of his patch, and the patch adds a considerable amount of
material.

For me this means that it is easier to think about fixing the original
bug than it is thinking about the flawed fix.

I'll revert in my personal copy and start thinking from there.  However,
it will be about noonish before I actually have time.

The other critical bug appears to be related with multithreading, and I
consider it likely, given its random appearance, that it will mainly
affect multicore systems.  I don't have such a one.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: no movement on Critical issues; 2.16 in Oct ?

2011-07-31 Thread Graham Percival

On Sun, Jul 31, 2011 at 09:42:36AM +0200, David Kastrup wrote:
 Graham Percival gra...@percival-music.ca writes:
 
  I haven't seen any interest in
http://code.google.com/p/lilypond/issues/detail?id=1771
 
 My take on this (if nobody is going to protest in the next few hours) is
 to revert the flawed fix.

I think that's entirely reasonable.  IMO, if there's no clear
offer of a fix within 48 hours of a bad commit, we should revert
it.

 The other critical bug appears to be related with multithreading, and I
 consider it likely, given its random appearance, that it will mainly
 affect multicore systems.  I don't have such a one.

I thought lilypond was single-threaded?  Or is the C++ stuff
single-threaded, but the guile stuff multi-threaded?  I mean, I
know that functional programming is great for multi-threaded work
in general, but I didn't think that we used it as such.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: no movement on Critical issues; 2.16 in Oct ?

Graham Percival gra...@percival-music.ca writes:

 On Sun, Jul 31, 2011 at 09:42:36AM +0200, David Kastrup wrote:
 Graham Percival gra...@percival-music.ca writes:
 
  I haven't seen any interest in
http://code.google.com/p/lilypond/issues/detail?id=1771
 
 My take on this (if nobody is going to protest in the next few hours) is
 to revert the flawed fix.

 I think that's entirely reasonable.  IMO, if there's no clear
 offer of a fix within 48 hours of a bad commit, we should revert
 it.

 The other critical bug appears to be related with multithreading, and I
 consider it likely, given its random appearance, that it will mainly
 affect multicore systems.  I don't have such a one.

 I thought lilypond was single-threaded?  Or is the C++ stuff
 single-threaded, but the guile stuff multi-threaded?  I mean, I
 know that functional programming is great for multi-threaded work
 in general, but I didn't think that we used it as such.

Guile explicitly differentiates functions map and map-in-order.  In
theory, it would be free to evaluate map in multiple threads.  I have
no indication that it does so and would be quite surprised if they
indeed had as fine-grained threading as that.

But this bug has been reported as occuring non-deterministically even in
successive runs on the same machine, and there are rather few things
that can introduce such stochastic behavior (another possibility would
be timer-triggered garbage collection).

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: no movement on Critical issues; 2.16 in Oct ?

Graham Percival gra...@percival-music.ca writes:

 On Sun, Jul 31, 2011 at 09:42:36AM +0200, David Kastrup wrote:
 Graham Percival gra...@percival-music.ca writes:
 
  I haven't seen any interest in
http://code.google.com/p/lilypond/issues/detail?id=1771
 
 My take on this (if nobody is going to protest in the next few hours) is
 to revert the flawed fix.

 I think that's entirely reasonable.  IMO, if there's no clear
 offer of a fix within 48 hours of a bad commit, we should revert
 it.

Within 48 hours of pinpointing the bad commit.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: no movement on Critical issues; 2.16 in Oct ?

2011-07-31 Thread Trevor Daniels



David Kastrup wrote Sunday, July 31, 2011 8:42 AM



Graham Percival gra...@percival-music.ca writes:


I haven't seen any interest in
  http://code.google.com/p/lilypond/issues/detail?id=1771


My take on this (if nobody is going to protest in the next few 
hours) is

to revert the flawed fix.


+1

The original bug fixer does not appear to be in the queue for 
fixing the

effects of his patch, and the patch adds a considerable amount of
material.


Fixing LilyPond is rarely trivial.  In my experience the
first fix one thinks of is usually flawed (and the
second ...)  We need to be doubly cautious when applying
fixes from casual contributors.

Trevor



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1390 / Virus Database: 1518/3799 - Release Date: 07/30/11


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: no movement on Critical issues; 2.16 in Oct ?

2011-07-31 Thread Graham Percival

On Sun, Jul 31, 2011 at 10:04:59AM +0200, David Kastrup wrote:
 But this bug has been reported as occuring non-deterministically even in
 successive runs on the same machine, and there are rather few things
 that can introduce such stochastic behavior (another possibility would
 be timer-triggered garbage collection).

In C++ code, I'd suspect some uninitalized variables (especially
since it always seems to work on the second run on a machine that
failed in the first run).  But since that throw() message seems to
come from guile, and AFAIK you can't have an unitalized variable
in guile, I guess that's not an issue?  Or could we be setting a
guile variable from some (uninitalized) C++ variable?

It's a shame that we can't (usefully) run valgrind on lilypond, or
that nobody's experiented with llvm or even AFAIK the more
sophisticated gcc options.  Finding uninitalized variables is a
task that can be done by the computer; humans should never need to
theorize about whether that's a cause or not.  Just run the
program with a trusted tool, and then you'll either find the
variables, or else you can cross that off from the list of
possibilities.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: no movement on Critical issues; 2.16 in Oct ?

Graham Percival gra...@percival-music.ca writes:

 On Sun, Jul 31, 2011 at 10:04:59AM +0200, David Kastrup wrote:
 But this bug has been reported as occuring non-deterministically even in
 successive runs on the same machine, and there are rather few things
 that can introduce such stochastic behavior (another possibility would
 be timer-triggered garbage collection).

 In C++ code, I'd suspect some uninitalized variables (especially
 since it always seems to work on the second run on a machine that
 failed in the first run).

Modern operating systems don't give your code any leftovers from a
previous run.  That would be a security violation.

And even user stack initialization below the stack pointer is not
stochastical.  System processes (like those triggered by interrupts
and/or preemption) use their own stack, and again: it would be a
security violation if a user process could access any information from
their operation.  So the sources for variation in successive identical
runs are very limited.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: no movement on Critical issues; 2.16 in Oct ?

2011-07-31 Thread Jan Warchoł

2011/7/31 David Kastrup d...@gnu.org:
 Graham Percival gra...@percival-music.ca writes:

 On Sun, Jul 31, 2011 at 09:42:36AM +0200, David Kastrup wrote:
 Graham Percival gra...@percival-music.ca writes:

  I haven't seen any interest in
    http://code.google.com/p/lilypond/issues/detail?id=1771

 My take on this (if nobody is going to protest in the next few hours) is
 to revert the flawed fix.

 I think that's entirely reasonable.  IMO, if there's no clear
 offer of a fix within 48 hours of a bad commit, we should revert
 it.

 Within 48 hours of pinpointing the bad commit.

+1.  If we manage to get stable releases every few months, i think a
policy of reverting any flawed commit that appeared after last stable
release (i mean x in 2.x.y, not y) would be good.

I can help with these bugs when i close currently opened issues and
sort out my repository after grand fixcc-ing (estimated to happen next
weekend).

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: no movement on Critical issues; 2.16 in Oct ?

2011-07-31 Thread Reinhold Kainhofer

Am Sunday, 31. July 2011, 07:45:20 schrieb Graham Percival:
 I haven't seen any interest in
   http://code.google.com/p/lilypond/issues/detail?id=1732
 This is unfortunate, since it means that we can't have a release
 candidate on Aug 01.

Without a reproducible test case, it's simply not possible to debug the 
problem. As I mentioned in my comment, the GUILE error message indicates an 
error in the threaded code. But there is no other indication where the problem 
might be.

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: no movement on Critical issues; 2.16 in Oct ?

2011-07-31 Thread Graham Percival

On Sun, Jul 31, 2011 at 10:26:11AM +0200, David Kastrup wrote:
 Modern operating systems don't give your code any leftovers from a
 previous run.  That would be a security violation.

I'm certain that I've seen an uninitialized variable being
123456789 in some cases, and 0 in others.  I sincerly doubt that
modern operating systems remember what collection of bits were in
memory at just before the first initialization, so the security
step would surely be simply writing 0s to that location in memory.

I think it's quite reasonable that if C++ interpreted a random
collection of bits (i.e. uninitailized memory), guile would barf
when trying to do some math with the resulting value.  But since
that pile of bits would be set to 0 on program exit, and if the
initial programmer just assumed that uninitialized variables were
0 (as they are in java), that would very neatly explain why we've
never seen two successive runs of this problem.

 And even user stack initialization below the stack pointer is not
 stochastical.

Hmm, I may be misunderstanding this sentence due to my relative
ignorance of low-level OS stuff (I had a quite varied career as an
undergraduate).  If you mean the computer starts reserving pieces
of memory for variables in different places in memory on each
run, then my 0-theorizing above is false.  But I'm pretty certain
that I've seen student programs (running in 3-year-old cygwin on
windows 2000, so perhaps not the most secure of environments)
share unitialized variable locations across program runs.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: no movement on Critical issues; 2.16 in Oct ?

Graham Percival gra...@percival-music.ca writes:

 On Sun, Jul 31, 2011 at 10:26:11AM +0200, David Kastrup wrote:
 Modern operating systems don't give your code any leftovers from a
 previous run.  That would be a security violation.

 I'm certain that I've seen an uninitialized variable being
 123456789 in some cases, and 0 in others.  I sincerly doubt that
 modern operating systems remember what collection of bits were in
 memory at just before the first initialization, so the security
 step would surely be simply writing 0s to that location in memory.

If the stack never previously was used to that depth.  I did not say
that you don't get leftovers from previous function calls.  And yes, you
usually get zeros for uninitialized memory.

 And even user stack initialization below the stack pointer is not
 stochastical.

 Hmm, I may be misunderstanding this sentence due to my relative
 ignorance of low-level OS stuff (I had a quite varied career as an
 undergraduate).  If you mean the computer starts reserving pieces of
 memory for variables in different places in memory on each run, then
 my 0-theorizing above is false.

That's not what I mean, though Linux indeed nowadays has kernel
parameters for randomizing its virtual storage layout to make it harder
to developer exploits for system libraries.  If bugs pop up only
occasionally, it might be worth switching this off and see whether it
stabilizes the problem in either direction.

 But I'm pretty certain that I've seen student programs (running in
 3-year-old cygwin on windows 2000, so perhaps not the most secure of
 environments) share unitialized variable locations across program
 runs.

Windows 2000 (not NT-based IIRC) does not usefully employ memory
protection IIRC, so likely Cygwin does not add all too much on top.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: no movement on Critical issues; 2.16 in Oct ?

2011-07-31 Thread Wols Lists

On 31/07/11 17:47, David Kastrup wrote:
 Windows 2000 (not NT-based IIRC) does not usefully employ memory
 protection IIRC, so likely Cygwin does not add all too much on top.

Windows 2000 most definitely IS NT-based. You're thinking of Windows ME,
which is the last of the DOS7/Win9x line.

Cheers,
Wol

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: no movement on Critical issues; 2.16 in Oct ?