Re: state of the ’Pond for earnest tadpoles

[antlists]

On 03/01/2021 10:07, James wrote:
my desktop before that was from 2013 (i5 something) and I was getting 
sub hour make doc times even then but using 3 CPUs.


So you having those timings while using a -j5 option ... wow!

I am obviously inhabiting some technological bubble that I wasn't aware 
I was in.


Not some technological bubble - just more money than sense :-)

My "new" pc that I have yet to install gentoo on and bring into service 
was bought three years ago. Don't ask ...


The system it's replacing has an Athlon X III processor so is probably 
about ten years old. And that replaced an Athlon Thunderbird where the 
on-board memory maxed out at 768MB.


Not all of us need (or can afford) to upgrade our kit regularly.

Cheers,
Wol

Re: state of the ’Pond for earnest tadpoles

[James]

Hello

On 02/01/2021 16:58, Thomas Morley wrote:

Am Sa., 2. Jan. 2021 um 14:41 Uhr schrieb James :


On 02/01/2021 12:20, Thomas Morley wrote:

A full `make doc` takes hours for me, even if invoked with `make doc
-j5 CPU_COUNT=5`
Thus I hardly do so, but use the CG-documented methods:

Hours?

Really?

Perhaps 'an hour' if you were using some very, very old CPU - but even
using a single CPU on an 'old' i5 Intel system a full make doc for me
took less than 50 mins. That last time it took longer than an hour was
when I had an old (8+ years ago) iMac running make doc in a linux VM.

James


time make doc -j5 CPU_COUNT=5
->
real77m53,168s
user204m51,501s
sys28m57,342s

Ok, hours was not exactly correct, but significant more than one hour

Cheers,
   Harm


I don't mean to flog this dead horse, but I was curious. I did a make 
doc with one cpu on my laptop (it has an i7 7700HQ CPU - circa 2017) and 
while I don't have the exact numbers to hand, as I am currently at work, 
it was something like real: 45m user:55m (cannot recall sys values), my 
desktop before that was from 2013 (i5 something) and I was getting sub 
hour make doc times even then but using 3 CPUs.


So you having those timings while using a -j5 option ... wow!

I am obviously inhabiting some technological bubble that I wasn't aware 
I was in.


:D


James

Re: state of the ’Pond for earnest tadpoles

[Thomas Morley]

Am Sa., 2. Jan. 2021 um 14:41 Uhr schrieb James :
>
>
> On 02/01/2021 12:20, Thomas Morley wrote:
> > A full `make doc` takes hours for me, even if invoked with `make doc
> > -j5 CPU_COUNT=5`
> > Thus I hardly do so, but use the CG-documented methods:
>
> Hours?
>
> Really?
>
> Perhaps 'an hour' if you were using some very, very old CPU - but even
> using a single CPU on an 'old' i5 Intel system a full make doc for me
> took less than 50 mins. That last time it took longer than an hour was
> when I had an old (8+ years ago) iMac running make doc in a linux VM.
>
> James
>

time make doc -j5 CPU_COUNT=5
->
real77m53,168s
user204m51,501s
sys28m57,342s

Ok, hours was not exactly correct, but significant more than one hour

Cheers,
  Harm

Re: state of the ’Pond for earnest tadpoles

[James]

On 02/01/2021 15:38, Kieren MacMillan wrote:

I’m using an 11-year old iMac, running LilyDev in a Linux VM.  =)


Oh .. OK.

Yeah. Don't make doc.

%^)

James

Re: state of the ’Pond for earnest tadpoles

[Kieren MacMillan]

Hi all,

>> Perhaps 'an hour' if you were using some very, very old CPU - but even using 
>> a single CPU on an 'old' i5 Intel system a full make doc for me took less 
>> than 50 mins. That last time it took longer than an hour was when I had an 
>> old (8+ years ago) iMac running make doc in a linux VM.

I’m using an 11-year old iMac, running LilyDev in a Linux VM.  =)
At some point — when I can spare potential “hours” — I’ll let you know how long 
it takes.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: state of the ’Pond for earnest tadpoles

[James]

Hello

On 02/01/2021 14:07, Trevor wrote:



James wrote 02/01/2021 13:41:06

On 02/01/2021 12:20, Thomas Morley wrote:

A full `make doc` takes hours for me, even if invoked with `make doc
-j5 CPU_COUNT=5`
Thus I hardly do so, but use the CG-documented methods:

Hours?
Really?
Perhaps 'an hour' if you were using some very, very old CPU - but 
even using a single CPU on an 'old' i5 Intel system a full make doc 
for me took less than 50 mins. That last time it took longer than an 
hour was when I had an old (8+ years ago) iMac running make doc in a 
linux VM.
When I had an old laptop with compromised cooling many years ago, a 
full build used to take several hours, presumably because my cpu was 
automatically clocked down to keep it from overheating. That was what 
triggered me to write the original versions (later improved by I 
forget who) of scripts/auxiliar/doc-section.sh MANUAL SECTION, as I 
was writing a lot of text for the manuals at the time, and needed to 
validate my contributions before pushing.


Right but that was 'many years ago' those scripts were there when I 
started (and that was ~2010), but even so, on 1 CPU, my Mother's old 
laptop (Dell circa 2014 - mid range i3 I think), doing a make doc took 
only 55 mins tops.


I understand that people might still have old hardware, but being 
worried that make doc takes 'hours' is no longer really true on any 
reasonable laptop hardware made within the last 5 or 6 years I'd say 
(using multiple Jobs or not to compile).


James

Re[2]: state of the ’Pond for earnest tadpoles

[Trevor]

James wrote 02/01/2021 13:41:06


On 02/01/2021 12:20, Thomas Morley wrote:

A full `make doc` takes hours for me, even if invoked with `make doc
-j5 CPU_COUNT=5`
Thus I hardly do so, but use the CG-documented methods:


Hours?
Really?

Perhaps 'an hour' if you were using some very, very old CPU - but even using a 
single CPU on an 'old' i5 Intel system a full make doc for me took less than 50 
mins. That last time it took longer than an hour was when I had an old (8+ 
years ago) iMac running make doc in a linux VM.
When I had an old laptop with compromised cooling many years ago, a full 
build used to take several hours, presumably because my cpu was 
automatically clocked down to keep it from overheating. That was what 
triggered me to write the original versions (later improved by I forget 
who) of scripts/auxiliar/doc-section.sh MANUAL SECTION, as I was writing 
a lot of text for the manuals at the time, and needed to validate my 
contributions before pushing.


Trevor

Re: state of the ’Pond for earnest tadpoles

[James]

On 02/01/2021 12:20, Thomas Morley wrote:

A full `make doc` takes hours for me, even if invoked with `make doc
-j5 CPU_COUNT=5`
Thus I hardly do so, but use the CG-documented methods:


Hours?

Really?

Perhaps 'an hour' if you were using some very, very old CPU - but even 
using a single CPU on an 'old' i5 Intel system a full make doc for me 
took less than 50 mins. That last time it took longer than an hour was 
when I had an old (8+ years ago) iMac running make doc in a linux VM.


James

Re: state of the ’Pond for earnest tadpoles

[Thomas Morley]

Am Sa., 2. Jan. 2021 um 13:20 Uhr schrieb Thomas Morley
:
>
> Hi Kieren,
>
> Am Sa., 2. Jan. 2021 um 00:00 Uhr schrieb Kieren MacMillan
> :
> >
> > Hi Michael (et al.),
> >
> > > please use http://lilypond.org/doc/v2.21/Documentation/contributor/lilydev
> > > instead. I adjusted some parts of this section last year. However, I
> > > would be happy to hear if something remains still unclear.
> >
> > This is great. Thanks.
> >
> > I have now compiled Lilypond on my machine! Took ~10 minutes (though I was 
> > doing a lot of other processor-intensive things at the same time, didn’t 
> > minimize the terminal window, etc., so I expect that can be reduced).
>
> To compare, on my weak and slow laptop and starting from scratch (i.e.
> after nuking the \build-directory)
> make -j5 CPU_COUNT=5
> takes ~15 minutes.
>
> As long as you work only on .ly- or .scm-files you don't need to start
> from scratch, but simply redo `make`. It will be much faster then.

Correction: changed ly/scm-files will usually not need recompilation at all.

> Ofcourse over time patches concerning .cc-files or the build-process
> will arrive, then you need to start earlier.
> Speaking only for me, I usually remove the \build-directory and start
> at the beginning, running autogen.sh ...
>
> > The only suggestion I would have is to maybe mention that the initial build 
> > outputs *some* documentation. When I started seeing “Making 
> > Documentation/out” in the terminal output, I started to worry that I had 
> > somehow triggered the documentation build which would apparently take 
> > multiple hours.  =)
>
> Iiuc, `make` initiates files like `notation.texi`, but they are not
> processed, i.e. no pdf or html is generated from them.
> A full `make doc` takes hours for me, even if invoked with `make doc
> -j5 CPU_COUNT=5`
> Thus I hardly do so, but use the CG-documented methods:
>
> CG 4.6.2 Generating documentation
> http://lilypond.org/doc/v2.21/Documentation/contributor/generating-documentation#building-documentation
> Section: Building documentation
> Section: Building a single document
>
> CG 5.7.1 Scripts to test the documentation
> http://lilypond.org/doc/v2.21/Documentation/contributor/scripts-to-test-the-documentation
> Section: Building only one section of the documentation
>
> I found the last possibility only recently.
>
> If you want to only build the internals you may use the undocumented:
>   lilypond generate-documentation.ly && texi2html internals.texi &&
> firefox internals.html
> The result is a raw, only basically formatted internals.html in the
> directory where the command is run.
> During compilation a plethora of warnings are omitted, I usually
> ignore them, the generated file is good for proof-reading, not more
> and will be superseeded by `make doc` anyway.
> Biggest advantage for me: it finishes in less than 1 minute.
>
> Cheers,
>   Harm

Re: state of the ’Pond for earnest tadpoles

[Thomas Morley]

Hi Kieren,

Am Sa., 2. Jan. 2021 um 00:00 Uhr schrieb Kieren MacMillan
:
>
> Hi Michael (et al.),
>
> > please use http://lilypond.org/doc/v2.21/Documentation/contributor/lilydev
> > instead. I adjusted some parts of this section last year. However, I
> > would be happy to hear if something remains still unclear.
>
> This is great. Thanks.
>
> I have now compiled Lilypond on my machine! Took ~10 minutes (though I was 
> doing a lot of other processor-intensive things at the same time, didn’t 
> minimize the terminal window, etc., so I expect that can be reduced).

To compare, on my weak and slow laptop and starting from scratch (i.e.
after nuking the \build-directory)
make -j5 CPU_COUNT=5
takes ~15 minutes.

As long as you work only on .ly- or .scm-files you don't need to start
from scratch, but simply redo `make`. It will be much faster then.
Ofcourse over time patches concerning .cc-files or the build-process
will arrive, then you need to start earlier.
Speaking only for me, I usually remove the \build-directory and start
at the beginning, running autogen.sh ...

> The only suggestion I would have is to maybe mention that the initial build 
> outputs *some* documentation. When I started seeing “Making 
> Documentation/out” in the terminal output, I started to worry that I had 
> somehow triggered the documentation build which would apparently take 
> multiple hours.  =)

Iiuc, `make` initiates files like `notation.texi`, but they are not
processed, i.e. no pdf or html is generated from them.
A full `make doc` takes hours for me, even if invoked with `make doc
-j5 CPU_COUNT=5`
Thus I hardly do so, but use the CG-documented methods:

CG 4.6.2 Generating documentation
http://lilypond.org/doc/v2.21/Documentation/contributor/generating-documentation#building-documentation
Section: Building documentation
Section: Building a single document

CG 5.7.1 Scripts to test the documentation
http://lilypond.org/doc/v2.21/Documentation/contributor/scripts-to-test-the-documentation
Section: Building only one section of the documentation

I found the last possibility only recently.

If you want to only build the internals you may use the undocumented:
  lilypond generate-documentation.ly && texi2html internals.texi &&
firefox internals.html
The result is a raw, only basically formatted internals.html in the
directory where the command is run.
During compilation a plethora of warnings are omitted, I usually
ignore them, the generated file is good for proof-reading, not more
and will be superseeded by `make doc` anyway.
Biggest advantage for me: it finishes in less than 1 minute.

Cheers,
  Harm

Re: state of the ’Pond for earnest tadpoles

[Phil Holmes]

It shouldn't take multiple hours unless your system is very slow.  A few 10s of 
minutes is a more reasonable expectation.


On 01/01/2021 23:00, Kieren MacMillan wrote:

Hi Michael (et al.),


please use http://lilypond.org/doc/v2.21/Documentation/contributor/lilydev
instead. I adjusted some parts of this section last year. However, I
would be happy to hear if something remains still unclear.

This is great. Thanks.

I have now compiled Lilypond on my machine! Took ~10 minutes (though I was 
doing a lot of other processor-intensive things at the same time, didn’t 
minimize the terminal window, etc., so I expect that can be reduced). Despite 
multiple attempts in the past, this is the first time I’ve ever been able to do 
that — thanks to all for the help to this point.

The only suggestion I would have is to maybe mention that the initial build 
outputs *some* documentation. When I started seeing “Making Documentation/out” 
in the terminal output, I started to worry that I had somehow triggered the 
documentation build which would apparently take multiple hours.  =)

More soon!
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info




--
Phil Holmes

Re: state of the ’Pond for earnest tadpoles

[Kieren MacMillan]

Hi Michael (et al.),

> please use http://lilypond.org/doc/v2.21/Documentation/contributor/lilydev
> instead. I adjusted some parts of this section last year. However, I
> would be happy to hear if something remains still unclear.

This is great. Thanks.

I have now compiled Lilypond on my machine! Took ~10 minutes (though I was 
doing a lot of other processor-intensive things at the same time, didn’t 
minimize the terminal window, etc., so I expect that can be reduced). Despite 
multiple attempts in the past, this is the first time I’ve ever been able to do 
that — thanks to all for the help to this point.

The only suggestion I would have is to maybe mention that the initial build 
outputs *some* documentation. When I started seeing “Making Documentation/out” 
in the terminal output, I started to worry that I had somehow triggered the 
documentation build which would apparently take multiple hours.  =)

More soon!
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: state of the ’Pond for earnest tadpoles

[Michael Käppler]

Hi Kieren,

Hi Jonas (et al.),


I would claim that the contributor experience has been pretty stable
since the initial switch to GitLab. Enabling CI and the recent work to
also run 'make check' automatically shouldn't change much from a
contributor's point of view, I hope.
I can't promise to give detailed guidance, the procedures should be
described in unstable's CG, but if there's anything unclear or even
wrong I'm more than happy to help you and of course fix the docs.

So here’s what I’ve done, as per 
:

please use http://lilypond.org/doc/v2.21/Documentation/contributor/lilydev
instead. I adjusted some parts of this section last year. However, I
would be happy to hear
if something remains still unclear.

Cheers,
Michael



1. Download & install VirtualBox. No problem!

2. Download LilyDev 2 from . Um… 
There’s only one file that seems like it’s the downloadable one (LilyDev-2-debian-vm.zip), and 
it’s not named as per the docs ("lilydev-vm-fedora-VERSION"). Is that a doc problem, 
or am I being daft?

3. Unzip the downloaded file. It becomes a folder containing an .img file. Okay… except 
the docs claim it should be a "raw" file. So do I try to convert that to VDI?

Note: I’m on Mac OS High Sierra (10.13.6).

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: state of the ’Pond for earnest tadpoles

[Federico Bruni]

Il giorno ven, gen 1 2021 at 16:37:40 -0500, Kieren MacMillan 
 ha scritto:

Hi Jonas (et al.),


 I would claim that the contributor experience has been pretty stable
 since the initial switch to GitLab. Enabling CI and the recent work 
to

 also run 'make check' automatically shouldn't change much from a
 contributor's point of view, I hope.
 I can't promise to give detailed guidance, the procedures should be
 described in unstable's CG, but if there's anything unclear or even
 wrong I'm more than happy to help you and of course fix the docs.


So here’s what I’ve done, as per 
:


1. Download & install VirtualBox. No problem!

2. Download LilyDev 2 from 
. Um… 
There’s only one file that seems like it’s the downloadable one 
(LilyDev-2-debian-vm.zip), and it’s not named as per the docs 
("lilydev-vm-fedora-VERSION"). Is that a doc problem, or am I being 
daft?


3. Unzip the downloaded file. It becomes a folder containing an .img 
file. Okay… except the docs claim it should be a "raw" file. So do 
I try to convert that to VDI?


Note: I’m on Mac OS High Sierra (10.13.6).



Hi Kieren

Sorry, it's my fault: I've been busy in other stuff and I forgot 
LilyDev.

I'll try to make a new release soon.

The command to convert to VDI is here:
https://github.com/fedelibre/LilyDev/tree/master/mkosi

Re: state of the ’Pond for earnest tadpoles

[Kieren MacMillan]

Hi Jonas (et al.),

> I would claim that the contributor experience has been pretty stable
> since the initial switch to GitLab. Enabling CI and the recent work to
> also run 'make check' automatically shouldn't change much from a
> contributor's point of view, I hope.
> I can't promise to give detailed guidance, the procedures should be
> described in unstable's CG, but if there's anything unclear or even
> wrong I'm more than happy to help you and of course fix the docs.

So here’s what I’ve done, as per 
:

1. Download & install VirtualBox. No problem!

2. Download LilyDev 2 from 
. Um… There’s only one 
file that seems like it’s the downloadable one (LilyDev-2-debian-vm.zip), and 
it’s not named as per the docs ("lilydev-vm-fedora-VERSION"). Is that a doc 
problem, or am I being daft?

3. Unzip the downloaded file. It becomes a folder containing an .img file. 
Okay… except the docs claim it should be a "raw" file. So do I try to convert 
that to VDI?

Note: I’m on Mac OS High Sierra (10.13.6).

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: state of the ’Pond for earnest tadpoles

[Jonas Hahnfeld]

Hi Kieren,

I would claim that the contributor experience has been pretty stable
since the initial switch to GitLab. Enabling CI and the recent work to
also run 'make check' automatically shouldn't change much from a
contributor's point of view, I hope.
I can't promise to give detailed guidance, the procedures should be
described in unstable's CG, but if there's anything unclear or even
wrong I'm more than happy to help you and of course fix the docs.

Cheers
Jonas

Am Dienstag, dem 15.12.2020 um 11:25 -0500 schrieb Kieren MacMillan:
> Hello all!
> 
> I’m just wondering if the new process / repo / workflow is in a state where 
> an enthusiastic but oft-discouraged[-by-the-state-of-the-tech-and-process] 
> Frog might finally dive in fully to the contribution process?
> 
> If so, which Jedi Master(s) might patiently guide this young Padawan through 
> the setup to his first patch?
> 
> Many thanks,
> Kieren.
> 
> 
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: kie...@kierenmacmillan.info


signature.asc
Description: This is a digitally signed message part

state of the ’Pond for earnest tadpoles

[Kieren MacMillan]

Hello all!

I’m just wondering if the new process / repo / workflow is in a state where an 
enthusiastic but oft-discouraged[-by-the-state-of-the-tech-and-process] Frog 
might finally dive in fully to the contribution process?

If so, which Jedi Master(s) might patiently guide this young Padawan through 
the setup to his first patch?

Many thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: State of the pond

[Francisco Vila]

2012/4/22 James pkx1...@gmail.com:
 Hello,

 On 22 April 2012 00:02, Francisco Vila paconet@gmail.com wrote:
 2012/4/20 Graham Percival gra...@percival-music.ca:
 We do not have a long history of flawless git actions from
 translations, so my preference would be not to touch anything.

 Good idea! The definitive recipe for eternal flawless development is
 not to touch anything, ever. Better safe than sorry.

 Gosh! Talk about taking something out of context.

 No one said 'ever' - you said that,

True, apologies. Failed joke/irony.

 consider this a moment of
 'reflection', if you want an analogy.

 James

Oh, I watch and see myself reflected, thanks. I tried to react more to
the not a long history than to the not touching. I want my and
others' work to be there but I am afraid of doing anything that breaks
it all. On the other hand, I can not omit doing things forever just
for safety. Therefore, I have to assume a certain degree of risk. I
already apologized when it went bad. After that, everything has gone
smoothly. Git history will judge us all.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: State of the pond

[David Kastrup]

Francisco Vila paconet@gmail.com writes:

 On the other hand, I can not omit doing things forever just for
 safety.  Therefore, I have to assume a certain degree of risk. I
 already apologized when it went bad.  After that, everything has gone
 smoothly.  Git history will judge us all.

The thing to remember is that git history can be both _viewed_ and
_changed_ before pushing it upstream.

So there is not much of a risk one has to assume.  Graham asked for
extra carefulness when pushing directly to release/unstable.  That is
different from asking for extra fatalism because one can always check
what one is doing.

The current spacing folderol in connection with issue 2468 makes this a
moot point right now: we can't really release 2.15.37 as 2.16, so
translators have a bit more time for business as usual.

-- 
David Kastrup


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

Re: State of the pond

[Werner LEMBERG]

 Git history will judge us all.

Interesting.  Up to now I've assumed God does this.


Werner

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

Re: State of the pond

[David Kastrup]

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

 Git history will judge us all.

 Interesting.  Up to now I've assumed God does this.

If HE weren't a fan of distributed version control systems, why create
the world in the first place?

-- 
David Kastrup


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

Re: State of the pond

[Werner LEMBERG]

 Interesting.  Up to now I've assumed God does this.
 
 If HE weren't a fan of distributed version control systems, why
 create the world in the first place?

Good point :-)

This reminds me of a joke:

  Two planets meet.

  `How are you?'
  `Well, not very well.'
  `How comes?'
  `I suffer from homo sapiens.'
  `Oh, don't worry, you'll get over it.'


 Werner

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

Re: State of the pond

[James]

Hello,

On 22 April 2012 11:59, David Kastrup d...@gnu.org wrote:
 Werner LEMBERG w...@gnu.org writes:

 Git history will judge us all.

 Interesting.  Up to now I've assumed God does this.

 If HE weren't a fan of distributed version control systems, why create
 the world in the first place?


God Loves Git

Now there's a rallying cry/T-shirt slogan if ever I've heard one!

James

PS For all those who are not British, I don't think I can convey the
absolute simple pleasure that I (at least, perhaps others) get from
having a DVCS called 'Git' :)

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

Re: State of the pond

[Jean-Charles Malahieude]

Le 20/04/2012 23:42, Graham Percival disait :

On Fri, Apr 20, 2012 at 07:38:06PM +0200, Jean-Charles Malahieude wrote:

Le 19/04/2012 21:30, Graham Percival disait :

- nobody touches the release/unstable branch, other than
   translators, who may merge with that if they want to and don't
   break anything.
   The question of whether translators have a stable branch or not
   is a separate matter and has nothing to do with the release
   plans.  It's just a question of how the translators want to
   organize themselves.


Will you cherry-pick downloads from FTP, or should I push them
directly on release/unstable?


I'm not going to be cherry-picking downloads from FTP.  If you
think it's absolutely necessary to include those in the 2.16.0
release, and if you're not going to break anything, then push
directly to release/unstable.

We do not have a long history of flawless git actions from
translations, so my preference would be not to touch anything.
That said, I can't recall any problems from FTP updates, so it's
probably ok.



Sorry, I didn't express myself very well.  I usually download updated 
po-files from FTP and push them to staging.


It is important to have them with 2.16, since the About automatic 
language selection string seems to no longer be picked up from 
Documentation/po but from the binary's po. And some doc string, which I 
consider as important, have been modified.


Cheers,
Jean-Charles

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

Re: State of the pond

[David Kastrup]

Jean-Charles Malahieude lily...@orange.fr writes:

 Le 20/04/2012 23:42, Graham Percival disait :
 On Fri, Apr 20, 2012 at 07:38:06PM +0200, Jean-Charles Malahieude wrote:
 Le 19/04/2012 21:30, Graham Percival disait :
 - nobody touches the release/unstable branch, other than
translators, who may merge with that if they want to and don't
break anything.
The question of whether translators have a stable branch or not
is a separate matter and has nothing to do with the release
plans.  It's just a question of how the translators want to
organize themselves.

 Will you cherry-pick downloads from FTP, or should I push them
 directly on release/unstable?

 I'm not going to be cherry-picking downloads from FTP.  If you
 think it's absolutely necessary to include those in the 2.16.0
 release, and if you're not going to break anything, then push
 directly to release/unstable.

 We do not have a long history of flawless git actions from
 translations, so my preference would be not to touch anything.
 That said, I can't recall any problems from FTP updates, so it's
 probably ok.


 Sorry, I didn't express myself very well.  I usually download updated
 po-files from FTP and push them to staging.

 It is important to have them with 2.16, since the About automatic
 language selection string seems to no longer be picked up from
 Documentation/po but from the binary's po. And some doc string, which
 I consider as important, have been modified.

I'd suggest that you do the same (namely push to staging), wait for
migration into master, check that the result agrees with your
expectations (I think the automated tests are not likely to cover this
well) and then ask Graham for permission to cherry-pick the respective
commit from master into release/unstable.  Test again and push.  And if
there is anything like mysterious merge conflicts or whatever else,
abort operations.  Regarding do not have a long history of flawless git
actions from translations, most problems have been with automatic or
manual salvaging of mysterious conflicts.

-- 
David Kastrup


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

Re: State of the pond

[Bernard Hurley]

On Sat, Apr 21, 2012 at 11:08:00AM +0200, Werner LEMBERG wrote:
 
  [1] why oh why does the main GNU editor not use the official
  extension language for the GNU operating system??
  
  Same reason why its keyboard shortcuts are only so-so compatible with
  CUA and/or GNOME: its development was started more than 30 years ago,
  when nobody had ever heard of Guile.
 
 Note, however, one of this year's Google-Summer-of-Code projects is
 integrating guile into Emacs; the idea is to use guile as the
 interpreter for Emacs Lisp.  At the same time, Scheme will be
 available for free.
 

That sounds interesting.  Personally I would rather see Emacs re-implemented 
using Common Lisp instead of Emacs Lisp.

The languages are very similar but it is their very similarity that trips me up 
whenever I try to use Emacs Lisp.

OTOH, I don't think I could live without Emacs!

Cheers,

Bernard.

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

Re: State of the pond

[David Kastrup]

Bernard Hurley bern...@marcade.biz writes:

 On Sat, Apr 21, 2012 at 11:08:00AM +0200, Werner LEMBERG wrote:
 
  [1] why oh why does the main GNU editor not use the official
  extension language for the GNU operating system??
  
  Same reason why its keyboard shortcuts are only so-so compatible with
  CUA and/or GNOME: its development was started more than 30 years ago,
  when nobody had ever heard of Guile.
 
 Note, however, one of this year's Google-Summer-of-Code projects is
 integrating guile into Emacs; the idea is to use guile as the
 interpreter for Emacs Lisp.  At the same time, Scheme will be
 available for free.
 

 That sounds interesting.  Personally I would rather see Emacs
 re-implemented using Common Lisp instead of Emacs Lisp.

URL:http://common-lisp.net/project/climacs/ is one such thing, and the
web site lists a number of other ports that failed to reach significant
mindshare.

Common Lisp is far too big to make sense as an extension language.

-- 
David Kastrup

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

Re: State of the pond

[Bernard Hurley]

On Sat, Apr 21, 2012 at 01:49:38PM +0200, David Kastrup wrote:
 Bernard Hurley bern...@marcade.biz writes:
 
  On Sat, Apr 21, 2012 at 11:08:00AM +0200, Werner LEMBERG wrote:
  
   [1] why oh why does the main GNU editor not use the official
   extension language for the GNU operating system??
   
   Same reason why its keyboard shortcuts are only so-so compatible with
   CUA and/or GNOME: its development was started more than 30 years ago,
   when nobody had ever heard of Guile.
  
  Note, however, one of this year's Google-Summer-of-Code projects is
  integrating guile into Emacs; the idea is to use guile as the
  interpreter for Emacs Lisp.  At the same time, Scheme will be
  available for free.
  
 
  That sounds interesting.  Personally I would rather see Emacs
  re-implemented using Common Lisp instead of Emacs Lisp.
 
 URL:http://common-lisp.net/project/climacs/ is one such thing, and the
 web site lists a number of other ports that failed to reach significant
 mindshare.
 
 Common Lisp is far too big to make sense as an extension language.
 

True but I use the stump window manager so I have SBCL running anyway. Climacs 
doesn't seem to have progressed since 2008 and is nowhere near a drop-in 
replacement for Emacs.

Anyway maybe this is getting a little far from Lilypond!

Cheers,

Bernard

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

Re: State of the pond

[David Kastrup]

Bernard Hurley bern...@marcade.biz writes:

 On Sat, Apr 21, 2012 at 01:49:38PM +0200, David Kastrup wrote:
 Bernard Hurley bern...@marcade.biz writes:
 
  That sounds interesting.  Personally I would rather see Emacs
  re-implemented using Common Lisp instead of Emacs Lisp.
 
 URL:http://common-lisp.net/project/climacs/ is one such thing, and the
 web site lists a number of other ports that failed to reach significant
 mindshare.
 
 Common Lisp is far too big to make sense as an extension language.
 

 True but I use the stump window manager so I have SBCL running
 anyway.

It does not make more sense for the tail to wag the dog just because the
dog would be there anyway.

-- 
David Kastrup

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

Re: State of the pond

[Francisco Vila]

2012/4/20 Graham Percival gra...@percival-music.ca:
 We do not have a long history of flawless git actions from
 translations, so my preference would be not to touch anything.

Good idea! The definitive recipe for eternal flawless development is
not to touch anything, ever. Better safe than sorry.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: State of the pond

[James]

Hello,

On 22 April 2012 00:02, Francisco Vila paconet@gmail.com wrote:
 2012/4/20 Graham Percival gra...@percival-music.ca:
 We do not have a long history of flawless git actions from
 translations, so my preference would be not to touch anything.

 Good idea! The definitive recipe for eternal flawless development is
 not to touch anything, ever. Better safe than sorry.

Gosh! Talk about taking something out of context.

No one said 'ever' - you said that, consider this a moment of
'reflection', if you want an analogy.

James

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

Re: State of the pond

[m...@apollinemike.com]

On Apr 19, 2012, at 9:30 PM, Graham Percival wrote:

 We have a new release candidate, slower development, highlights on
 development problems, and a vacation.
 
 
 SLOWER DEVELOPMENT
 
 Development has slowed to a trickle.  I'm not certain if this is
 just because it's late spring (i.e. busy academic time), or if
 people are holding their breaths waiting for the stable release
 (i.e. not putting forward any major patches), or just everybody
 getting older.
 

I'm still working on a long-term skyline project w/ Joe.

My summer of Lily agenda has bits and pieces of projects in it but nothing 
major for the moment - I am always open to ideas, though!  I think we'll see a 
big boost in Lyrics after Janek's work on it this summer.

 
 DEVELOPMENT PROBLEMS
 
 The lack of interested mentors is a problem.

I'm always willing to give pointers - sorry if I haven't been attentive on the 
list.  I'll contact these people.

 
 VACATION
 
 On a personal note, I'm off to Europe from May 8 to 24, seeing
 Zurich, Munich, Salzburg, Vienna, Prague, and Germany (in that
 order).

Gute Reise!

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

Re: State of the pond

[Adam Spiers]

On Thu, Apr 19, 2012 at 12:30 PM, Graham Percival
gra...@percival-music.ca wrote:
 Trying to anticipate future problems, I recalled guile
 indentation:
 http://codereview.appspot.com/4896043/
 My impression is that it would only take an hour or two to fix
 this, and then we could standardize all the scheme indentation.
 This isn't a theoretical concern; Adam Spiers' first patch
 required hours of extra work because of misunderstandings about
 our desired indentation.  This strikes me as a fairly juicy piece
 of low-hanging fruit.

I would be happy to tackle this and *hope* to have a spare few hours
at some point in the next month, although it all depends on how things
pan out when I get back from California on Wednesday - if someone
beats me to it then that's fine.  Just to clarify, the remaining work
is to follow Neil's suggestions, merge the patch set, close the
review, and then run the tool on all .scm files and submit as a
separate review?

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

Re: State of the pond

[Jean-Charles Malahieude]

Le 19/04/2012 21:30, Graham Percival disait :

We have a new release candidate, slower development, highlights on
development problems, and a vacation.


RELEASE CANDIDATE

As always, this means:

- activity on master goes on as normal.

- nobody touches the release/unstable branch, other than
   translators, who may merge with that if they want to and don't
   break anything.
   The question of whether translators have a stable branch or not
   is a separate matter and has nothing to do with the release
   plans.  It's just a question of how the translators want to
   organize themselves.

- when I say nobody touches the release/unstable branch, I mean
   it.  There will be no new features, no ordinary bugfixes, no doc
   changes.



Will you cherry-pick downloads from FTP, or should I push them directly 
on release/unstable?


Cheers, and a nice trip!
Jean-Charles

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

Re: State of the pond

[Graham Percival]

On Fri, Apr 20, 2012 at 08:27:20AM -0700, Adam Spiers wrote:
 On Thu, Apr 19, 2012 at 12:30 PM, Graham Percival
 gra...@percival-music.ca wrote:
  Trying to anticipate future problems, I recalled guile
  indentation:
  http://codereview.appspot.com/4896043/
 
 I would be happy to tackle this and *hope* to have a spare few hours
 at some point in the next month, although it all depends on how things
 pan out when I get back from California on Wednesday - if someone
 beats me to it then that's fine.  Just to clarify, the remaining work
 is to follow Neil's suggestions, merge the patch set, close the
 review, and then run the tool on all .scm files and submit as a
 separate review?

Almost.

Specifications of the guile indenting tool:
- indent scheme exactly as emacs does it.  (if there's
  disagreement between different versions of emacs, then maybe
  pick one?  I don't know about this)
- provide a command-line method of doing the indentation which
  fits into our source repository and does not require the
  user to install 50 MB of software packages (i.e. emacs).

I believe that Carl's script is 95% of the way there, so editing
that is almost certainly the way to go.  However, it is
theoretically possible that it would be less work to find the
emacs lips indentation .elisp file, translate that from elisp to
guile[1] then add a command-line interface to those macros.  I'm
not sufficiently familiar with translating between lisp dialects,
nor the emacs source code, to judge if the latter method might be
a reasonable way to proceed.

[1] why oh why does the main GNU editor not use the official
extension language for the GNU operating system??

Whichever method you choose, we would like to review the modified
script before it's pushed.  We have new guidelines (IIRC from
February?) for this process:
http://lilypond.org/doc/v2.15/Documentation/contributor/summary-for-experienced-developers
Once the script has been pushed to staging, you (or I) can run it
on all .scm and push that directly to staging as well.

Thanks for your interest!
- Graham

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

Re: State of the pond

[Graham Percival]

On Fri, Apr 20, 2012 at 07:38:06PM +0200, Jean-Charles Malahieude wrote:
 Le 19/04/2012 21:30, Graham Percival disait :
 - nobody touches the release/unstable branch, other than
translators, who may merge with that if they want to and don't
break anything.
The question of whether translators have a stable branch or not
is a separate matter and has nothing to do with the release
plans.  It's just a question of how the translators want to
organize themselves.
 
 Will you cherry-pick downloads from FTP, or should I push them
 directly on release/unstable?

I'm not going to be cherry-picking downloads from FTP.  If you
think it's absolutely necessary to include those in the 2.16.0
release, and if you're not going to break anything, then push
directly to release/unstable.

We do not have a long history of flawless git actions from
translations, so my preference would be not to touch anything.
That said, I can't recall any problems from FTP updates, so it's
probably ok.

- Graham

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

Re: State of the pond

[Janek Warchoł]

On Fri, Apr 20, 2012 at 3:23 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
 On Apr 19, 2012, at 9:30 PM, Graham Percival wrote:

 Development has slowed to a trickle.  I'm not certain if this is
 just because it's late spring (i.e. busy academic time), or if
 people are holding their breaths waiting for the stable release
 (i.e. not putting forward any major patches), or just everybody
 getting older.

 I'm still working on a long-term skyline project w/ Joe.

 My summer of Lily agenda has bits and pieces of projects in it but nothing 
 major for the moment - I am always open to ideas, though!

Ideas - that's something for me!  I see 6 possible major projects
about graphical output:
- improving ties
- improving beams
- improving slurs
- improving vertical spacing (area spacing)
- automatically modyfying objects placement and size to reduce
vertical sizes of staves
- improving horizontal spacing

all of these are awesome :)

cheers,
Janek

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

Re: State of the pond

[David Kastrup]

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

 [1] why oh why does the main GNU editor not use the official
 extension language for the GNU operating system??

Same reason why its keyboard shortcuts are only so-so compatible with
CUA and/or GNOME: its development was started more than 30 years ago,
when nobody had ever heard of Guile.

-- 
David Kastrup


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

State of the pond

[Graham Percival]

We have a new release candidate, slower development, highlights on
development problems, and a vacation.


RELEASE CANDIDATE

As always, this means:

- activity on master goes on as normal.

- nobody touches the release/unstable branch, other than
  translators, who may merge with that if they want to and don't
  break anything.
  The question of whether translators have a stable branch or not
  is a separate matter and has nothing to do with the release
  plans.  It's just a question of how the translators want to
  organize themselves.

- when I say nobody touches the release/unstable branch, I mean
  it.  There will be no new features, no ordinary bugfixes, no doc
  changes.

- if there are no Critical issues in two weeks, release/unstable
  becomes stable/2.16.

- if not, I make a new release/unstable based on master whenever
  those Critical issues are fixed.  This will obviously pick up
  any new features, bugfixes, or doc updates that happened in
  master.


SLOWER DEVELOPMENT

Development has slowed to a trickle.  I'm not certain if this is
just because it's late spring (i.e. busy academic time), or if
people are holding their breaths waiting for the stable release
(i.e. not putting forward any major patches), or just everybody
getting older.


DEVELOPMENT PROBLEMS

The lack of interested mentors is a problem.  For example, Luke
has been trying to add a few comments and clean-ups to our code
since Feb 10.
http://code.google.com/p/lilypond/issues/detail?id=2310
However, this is a general problem which we've had for years; it's
not going to be fixed any time soon.  And I'm certainly not
pointing fingers here, since I'm not willing to mentor people.

Trying to anticipate future problems, I recalled guile
indentation:
http://codereview.appspot.com/4896043/
My impression is that it would only take an hour or two to fix
this, and then we could standardize all the scheme indentation.
This isn't a theoretical concern; Adam Spiers' first patch
required hours of extra work because of misunderstandings about
our desired indentation.  This strikes me as a fairly juicy piece
of low-hanging fruit.


VACATION

On a personal note, I'm off to Europe from May 8 to 24, seeing
Zurich, Munich, Salzburg, Vienna, Prague, and Germany (in that
order).  If anybody is in one of those cities and wants to meet up
for a few hours, let me know.

Taking it back to lilypond, all our accommodation is supposed to
have wifi, so I should be able to make releases as normal.
However, if 2.16 turns stable during that time, and if that
release requires unforseen fixes, there may be some problems.


- Graham

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

Re: State of the pond

[David Kastrup]

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

 SLOWER DEVELOPMENT

 Development has slowed to a trickle.  I'm not certain if this is
 just because it's late spring (i.e. busy academic time), or if
 people are holding their breaths waiting for the stable release
 (i.e. not putting forward any major patches), or just everybody
 getting older.

I am partly responsible.  For one thing I've been climbing around
Easter, for another I am brooding over the best way to work on
user-definable new events, grobs, other things.  I am coding far too
little and brooding far too much: I am not really all that content with
my current approaches of making LilyPond extensible in that area while
not impacting performance more than inevitable.

 VACATION

 On a personal note, I'm off to Europe from May 8 to 24, seeing Zurich,
 Munich, Salzburg, Vienna, Prague, and Germany (in that order).

It will be interesting to hear how you manage to visit Munich as second
city while holding off on Germany till the end.

 If anybody is in one of those cities and wants to meet up for a few
 hours, let me know.

I think I am in the city of Germany right now, and probably even then.

All the best

-- 
David Kastrup


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

Re: State of the pond

[Graham Percival]

On Thu, Apr 19, 2012 at 09:52:55PM +0200, David Kastrup wrote:
 Graham Percival gra...@percival-music.ca writes:
 
  SLOWER DEVELOPMENT
 
  Development has slowed to a trickle.  I'm not certain if this is
 
 I am partly responsible.

A power-law function for development work is certainly predicted
by numerous studies on open-source software, but we could still
strive to have a power-law function with a shallower slope.

  On a personal note, I'm off to Europe from May 8 to 24, seeing Zurich,
  Munich, Salzburg, Vienna, Prague, and Germany (in that order).
 
 It will be interesting to hear how you manage to visit Munich as second
 city while holding off on Germany till the end.

Oops.  s/Germany/Berlin.  Hey, at least that's not as bad as
losing four hours because of a missing minus sign when
transcribing output from maxima into latex (and then into python).

- Graham

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

Re: State of the pond

[James]

Hello,

On 19 April 2012 20:52, David Kastrup d...@gnu.org wrote:
 Graham Percival gra...@percival-music.ca writes:

 SLOWER DEVELOPMENT

 Development has slowed to a trickle.  I'm not certain if this is
 just because it's late spring (i.e. busy academic time), or if
 people are holding their breaths waiting for the stable release
 (i.e. not putting forward any major patches), or just everybody
 getting older.

 I am partly responsible.  For one thing I've been climbing around
 Easter, for another I am brooding over the best way to work on
 user-definable new events, grobs, other things.  I am coding far too
 little and brooding far too much: I am not really all that content with
 my current approaches of making LilyPond extensible in that area while
 not impacting performance more than inevitable.

 VACATION

 On a personal note, I'm off to Europe from May 8 to 24, seeing Zurich,
 Munich, Salzburg, Vienna, Prague, and Germany (in that order).

 It will be interesting to hear how you manage to visit Munich as second
 city while holding off on Germany till the end.

You obviously don't work with Bavarians (like I do).

:)

James

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