Delay import of `midi' module.

Delay import of `midi' module.

`make all' starts with generating the manual pages for lilypond's python
scripts using help2man.  However, at the time `midi2ly --help' gets called,
the `midi' python module (which is based on code written in C) imported by
`midi2ly' has not been compiled yet, making help2man abort.

[dak, 2016-05-31 07:13:04]

https://codereview.appspot.com/297420043/diff/1/scripts/midi2ly.py
File scripts/midi2ly.py (right):

https://codereview.appspot.com/297420043/diff/1/scripts/midi2ly.py#newcode925
scripts/midi2ly.py:925: import midi
Doesn't this merely work by chance?

If running the script depends on the midi module being compiled, the solution
would obviously be to tell that to Make with an appropriate dependency.

[dak, 2016-05-31 10:24:52]

On 2016/05/31 07:13:04, dak wrote:
> https://codereview.appspot.com/297420043/diff/1/scripts/midi2ly.py
> File scripts/midi2ly.py (right):
> 
> https://codereview.appspot.com/297420043/diff/1/scripts/midi2ly.py#newcode925
> scripts/midi2ly.py:925: import midi
> Doesn't this merely work by chance?
> 
> If running the script depends on the midi module being compiled, the solution
> would obviously be to tell that to Make with an appropriate dependency.

What   a    crock.

Ok, running the script with just --version or --help does indeed not need the
midi module.  I thought you tried changing the timing of executing the script
when it is "just" changing the dependencies when called with particular options
for the sake of help2man.

This is ugly as whatever but likely will do the trick.  Now I have no idea why I
(or anybody else) did not hit this problem previously, but it would appear I
need this patch to get staging-patchy through.

I don't have your exact commit message.  Can you push this right to staging or
to some branch where I can find it or do a git-send-email of it to the developer
list?

Thanks.

[lemzwerg, 2016-05-31 10:35:45]

> Ok, running the script with just --version or --help does indeed not
> need the midi module.

Yep.

> This is ugly as whatever but likely will do the trick.

:-) Interestingly, I haven't find out yet how `midi.c' gets compiled
at all; I can't find any trace of it in the log file that I catch

  make all &> make.all.log

> Can you push this right to staging

Done.

[lemzwerg, 2016-05-31 10:37:33]

> > Can you push this right to staging
> 
> Done.

Aargh, I forgot to massage the commit message to mention the issue.
Sorry for that.

[mail_philholmes.net, 2016-05-31 11:01:59]

----- Original Message ----- 
From: <lemzwerg@googlemail.com>
To: <dak@gnu.org>
Cc: <reply@codereview-hr.appspotmail.com>; <lilypond-devel@gnu.org>
Sent: Tuesday, May 31, 2016 11:37 AM
Subject: Re: Delay import of `midi' module. (issue 297420043 
bylemzwerg@googlemail.com)


>> > Can you push this right to staging
>
>> Done.
>
> Aargh, I forgot to massage the commit message to mention the issue.
> Sorry for that.

This causes make test to fail:

Traceback (most recent call last):
File "/home/patchy/patchybuild/autobuild/scripts/midi2ly.py", line 1194, in 
<module>
main ()
File "/home/patchy/patchybuild/autobuild/scripts/midi2ly.py", line 1191, in 
main
convert_midi (f, o)
File "/home/patchy/patchybuild/autobuild/scripts/midi2ly.py", line 958, in 
convert_midi
t.music = t.parse ()
File "/home/patchy/patchybuild/autobuild/scripts/midi2ly.py", line 441, in 
parse
if (e[1][0] == midi.NOTE_OFF
NameError: global name 'midi' is not defined
make[2]: *** [out-test/key-initial-midi.ly] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [local-test] Error 2
make: *** [test] Error 2


--
Phil Holmes 

[lemzwerg, 2016-05-31 11:39:18]

OK, will fix that.  Please remove the current patch from staging.

[dak, 2016-05-31 11:39:29]

"Phil Holmes" <mail@philholmes.net> writes:

> ----- Original Message ----- 
> From: <lemzwerg@googlemail.com>
> To: <dak@gnu.org>
> Cc: <reply@codereview-hr.appspotmail.com>; <lilypond-devel@gnu.org>
> Sent: Tuesday, May 31, 2016 11:37 AM
> Subject: Re: Delay import of `midi' module. (issue 297420043
> bylemzwerg@googlemail.com)
>
>>> > Can you push this right to staging
>>
>>> Done.
>>
>> Aargh, I forgot to massage the commit message to mention the issue.
>> Sorry for that.
>
> This causes make test to fail:
>
> Traceback (most recent call last):
> File "/home/patchy/patchybuild/autobuild/scripts/midi2ly.py", line
> 1194, in <module>
> main ()
> File "/home/patchy/patchybuild/autobuild/scripts/midi2ly.py", line
> 1191, in main
> convert_midi (f, o)
> File "/home/patchy/patchybuild/autobuild/scripts/midi2ly.py", line
> 958, in convert_midi
> t.music = t.parse ()
> File "/home/patchy/patchybuild/autobuild/scripts/midi2ly.py", line
> 441, in parse
> if (e[1][0] == midi.NOTE_OFF
> NameError: global name 'midi' is not defined
> make[2]: *** [out-test/key-initial-midi.ly] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [local-test] Error 2
> make: *** [test] Error 2

Argl.  Removing this commit again.  Werner, do you think you can push a
fixed version?

-- 
David Kastrup

[lemzwerg, 2016-05-31 11:59:19]

Fix `make test` run.

[lemzwerg, 2016-05-31 12:02:36]

> Werner, do you think you can push a fixed version?

Done.  For me, `make test` succeeded.

[mail_philholmes.net, 2016-05-31 12:06:16]

Patchy-staging running now.

--
Phil Holmes


----- Original Message ----- 
From: <lemzwerg@googlemail.com>
To: <dak@gnu.org>; <mail@philholmes.net>
Cc: <lilypond-devel@gnu.org>; <reply@codereview-hr.appspotmail.com>
Sent: Tuesday, May 31, 2016 1:02 PM
Subject: Re: Delay import of `midi' module. (issue 297420043 by 
lemzwerg@googlemail.com)


>> Werner, do you think you can push a fixed version?
>
> Done.  For me, `make test` succeeded.
>
> https://codereview.appspot.com/297420043/
> 

[mail_philholmes.net, 2016-05-31 12:30:57]

----- Original Message ----- 
From: <lemzwerg@googlemail.com>
To: <dak@gnu.org>; <mail@philholmes.net>
Cc: <lilypond-devel@gnu.org>; <reply@codereview-hr.appspotmail.com>
Sent: Tuesday, May 31, 2016 1:02 PM
Subject: Re: Delay import of `midi' module. (issue 297420043 by 
lemzwerg@googlemail.com)


>> Werner, do you think you can push a fixed version?
>
> Done.  For me, `make test` succeeded.
>
> https://codereview.appspot.com/297420043/
>

Tested and pushed to master.

--
Phil Holmes 

[dak, 2016-05-31 12:37:26]

"Phil Holmes" <mail@philholmes.net> writes:

> Patchy-staging running now.
>>
>> https://codereview.appspot.com/297420043/

Well, hooray!  master has been pushed.  Now let's see whether this helps
James in any respect (if there is still a Ghostscript problem, it likely
won't, but otherwise it might).

And I need to stop LilyPond from conflating $(LD) for both C and C++.
In fact, it first proceeds to find a good version of LD for C, only to
have it stomped over with '$(CXX)' in STEPMAKE_CXX afterwards (commit
commit 078703a6ab29f75983a55ac2cc35fe5f315da574
Author: Jan Nieuwenhuizen <janneke@gnu.org>
Date:   Wed Oct 19 13:54:23 2005 +0000

    * stepmake/stepmake/*:
    * */GNUmakefile:
    * config.make.in:
    * GNUmakefile.in:
    * stepmake/aclocal.m4: Friendlier --srcdir build, allowing `make'
    from any directory in build-dir.  Cleanups.
    
    * make/srcdir.make.in: Remove.
    
    * lily/main.cc (setup_paths): Fix and document build-dir hack.
).

As I want to have 64bit compilation with C++ and 32bit with C on my
personal computer (don't ask), it's important to have the linker
distinguished properly.

-- 
David Kastrup

[pkx, 2016-05-31 12:56:57]

On 31/05/16 13:37, David Kastrup wrote:
> "Phil Holmes" <mail@philholmes.net> writes:
>
>> Patchy-staging running now.
>>> https://codereview.appspot.com/297420043/
> Well, hooray!  master has been pushed.  Now let's see whether this helps
> James in any respect (if there is still a Ghostscript problem, it likely
> won't, but otherwise it might).

I am running a merge now - it doesn't matter that someone else already 
has done it (Patchy just replies that staging has already been pushed by 
'someone else'; I do appreciate those devs that worked on Patchy) - so 
if that works, I'll know in about 20 mins from now.

Then I'll see if I can test a patch - although I fear we may get 
failures that have more to do with needing to rebase with current master ;)

I'll let you all know.

James

[dak, 2016-05-31 15:43:03]

James <pkx@gnu.org> writes:

> On 31/05/16 13:37, David Kastrup wrote:
>> "Phil Holmes" <mail@philholmes.net> writes:
>>
>>> Patchy-staging running now.
>>>> https://codereview.appspot.com/297420043/
>> Well, hooray!  master has been pushed.  Now let's see whether this helps
>> James in any respect (if there is still a Ghostscript problem, it likely
>> won't, but otherwise it might).
>
> I am running a merge now - it doesn't matter that someone else already
> has done it (Patchy just replies that staging has already been pushed
> by 'someone else'; I do appreciate those devs that worked on Patchy) -
> so if that works, I'll know in about 20 mins from now.
>
> Then I'll see if I can test a patch - although I fear we may get
> failures that have more to do with needing to rebase with current
> master ;)
>
> I'll let you all know.

I'm rather interested in issue 4871: that one is necessary for my rather
peculiar C++/64 C/32 setup to work.  Once I can push that one to
staging, I should be able to rejoin the lilypond-patchy-staging crowd.

-- 
David Kastrup

[pkx, 2016-05-31 15:43:16]

hello

On 31/05/16 13:56, James wrote:
>
>
> On 31/05/16 13:37, David Kastrup wrote:
>> "Phil Holmes" <mail@philholmes.net> writes:
>>
>>> Patchy-staging running now.
>>>> https://codereview.appspot.com/297420043/
>> Well, hooray!  master has been pushed.  Now let's see whether this helps
>> James in any respect (if there is still a Ghostscript problem, it likely
>> won't, but otherwise it might).
>
> I am running a merge now - it doesn't matter that someone else already 
> has done it (Patchy just replies that staging has already been pushed 
> by 'someone else'; I do appreciate those devs that worked on Patchy) - 
> so if that works, I'll know in about 20 mins from now.
>
> Then I'll see if I can test a patch - although I fear we may get 
> failures that have more to do with needing to rebase with current 
> master ;)
>
> I'll let you all know.
OK that all worked and I was technically able to push.

\o/

Although I hadn't noticed that I had the default values of j3 and it 
took nearly an hour to compile the doc =80 (no wonder people hate doing 
it, I had forgotten what it was like in the olden days when I used to do 
doc work on my 2 CPU iMac running LilyDev in a VM).

Anyway, I'll start to see if I can get some patches tested now.

Thanks for the work to all concerned.

Onwards and upwards!

James

[dak, 2016-05-31 15:53:31]

James <pkx@gnu.org> writes:

> On 31/05/16 13:56, James wrote:
>>
>>
>> On 31/05/16 13:37, David Kastrup wrote:
>>> "Phil Holmes" <mail@philholmes.net> writes:
>>>
>>>> Patchy-staging running now.
>>>>> https://codereview.appspot.com/297420043/
>>> Well, hooray!  master has been pushed.  Now let's see whether this helps
>>> James in any respect (if there is still a Ghostscript problem, it likely
>>> won't, but otherwise it might).
>>
>> I am running a merge now - it doesn't matter that someone else
>> already has done it (Patchy just replies that staging has already
>> been pushed by 'someone else'; I do appreciate those devs that
>> worked on Patchy) - 
>> so if that works, I'll know in about 20 mins from now.
>>
>> Then I'll see if I can test a patch - although I fear we may get
>> failures that have more to do with needing to rebase with current
>> master ;)
>>
>> I'll let you all know.
> OK that all worked and I was technically able to push.
>
> \o/
>
> Although I hadn't noticed that I had the default values of j3 and it
> took nearly an hour to compile the doc =80 (no wonder people hate
> doing it, I had forgotten what it was like in the olden days when I
> used to do doc work on my 2 CPU iMac running LilyDev in a VM).

That sounds like Lilydev and 32bit.  I'd be interested to know whether
64bit has improved.

> Thanks for the work to all concerned.

The frustrating thing is that the commit that broke things was just
reorganizing some stuff, and the commit that possibly made things work
again was further reorganizing and there is no sane reason for either to
have made a difference.  But I hope this buys me time for figuring out
the insane reasons.

-- 
David Kastrup

[pkx, 2016-05-31 16:15:34]

On 31/05/16 16:52, David Kastrup wrote:

> That sounds like Lilydev and 32bit.  I'd be interested to know whether
> 64bit has improved.

This was 64 bit.

It is just that I still had default setting of the 
lilypond-patchy-config file is j3 from my restored build environmenty 
when we first had the issue and  thought the problem was local to my 
machine.

I can try 32 bit if you like - I still have my lilydev VM around.

James

[dak, 2016-05-31 16:18:36]

James <pkx@gnu.org> writes:

> On 31/05/16 16:52, David Kastrup wrote:
>
>> That sounds like Lilydev and 32bit.  I'd be interested to know whether
>> 64bit has improved.
>
> This was 64 bit.

Great.

> It is just that I still had default setting of the
> lilypond-patchy-config file is j3 from my restored build environmenty
> when we first had the issue and thought the problem was local to my
> machine.
>
> I can try 32 bit if you like - I still have my lilydev VM around.

Let's just wait and see if someone else hollers.

-- 
David Kastrup

[dak, 2016-05-31 18:39:31]

James <pkx@gnu.org> writes:

> Although I hadn't noticed that I had the default values of j3 and it
> took nearly an hour to compile the doc

Luxury.  <URL:https://www.youtube.com/watch?v=VKHFZBUTA4k>

> (no wonder people hate doing it, I had forgotten what it was like in
> the olden days when I used to do doc work on my 2 CPU iMac running
> LilyDev in a VM).

16:55:29 (UTC) Begin LilyPond compile, previous commit at
	1b6d6de94a26c3e8b75e1f78f6d0cfc9eec96a89
16:55:43 Merged staging, now at:	1b6d6de94a26c3e8b75e1f78f6d0cfc9eec96a89
16:55:44 	Success:		./autogen.sh --noconfigure
16:56:01 	Success:		/tmp/lilypond-autobuild/configure --disable-optimising
16:56:04 	Success:		nice make clean
17:03:03 	Success:		nice make -j3 CPU_COUNT=3
17:18:03 	Success:		nice make test -j3 CPU_COUNT=3
18:32:37 	Success:		nice make doc -j3 CPU_COUNT=3
18:32:54 To ssh://git.sv.gnu.org/srv/git/lilypond.git
   905109e..1b6d6de  test-staging -> master
18:32:54 	Success:		pushed to master

-- 
David Kastrup