denemo-devel
[Top][All Lists]

## Re: [Denemo-devel] Release 0.8.16 - Gub Status

 From: Jeremiah Benham Subject: Re: [Denemo-devel] Release 0.8.16 - Gub Status Date: Fri, 26 Mar 2010 07:37:31 -0500




On Mar 26, 2010, at 5:06 AM, Richard Shann <address@hidden> wrote:


All attempts to invoke lilypond-windows.exe with -dgui included in the
arguments by g_spawn... failed, so I have put the batch file needed in
the denemo source files at

\$git-prefix/bin/denemo-lilypond.bat

I have checked this in to git. But I couldn't figure out how to get it

installed in /usr/local/bin/ along with the denemo executable. This, if
done would mean it would appear in c:\Program Files\GNU_Denemo\usr\bin
on windows and, I believe could then be invoked by defaulting the
prefs.lilypath to denemo-lilypond.bat.
(Of course this .bat file is not needed on a unix installation, but I
guess we don't have to fuss about that).
Jeremiah, can you fix the make system to copy this file to the execdir
on install?


I will take a look at it.

Jeremiah


Then I can fix the default pref and we are ready to release
- I hope!

Richard

On Thu, 2010-03-25 at 19:08 +0000, Richard Shann wrote:

I have found a fix for the bug!
In the executables there is a lilypond-windows.bat.in and from that I
gather we need to add a -dgui to the command line

I have succeeded by invoking lilypond-windows via a batch file that does this (changing the denemo pref to point to the batch file that adds the
-dgui parameter).

I'll try to check in later, and withdraw the mods to print.c except the
export pdf which is broken anyway.
Richard

On Thu, 2010-03-25 at 15:14 +0100, Nils Gey wrote:

On Thu, 25 Mar 2010 08:19:38 +0000


I think we can be reasonably sure that it is not the denemo sources that have triggered this bug by changing. If you can re-build from the denemo
sources of 21st I think you will see the bug.


I suspect gub is using a new version of glib with a bug, or at least
new behavior exposing a bug in denemo's code.



Gub does not build everything from git or svn. The opposite is true: Most are just stable releases. This is the case for any glib related lib, too. The main things that change are Denemo and Lilypond.



The basic problem is that gub can (AFAIK) change the versions of tools it uses and of libraries it uses and make a new installer incorporating new things other than a new denemo. Uncontrollable behavior like this is
a bad thing.
Richard


Like I said. Its not that uncontrollable.

So in this case I highly suspect Lilypond. We need to build from a stable release in any case. Building Lilypond from git to release Denemo is still not a good idea.


So the next step is to rewind lilypond or, in the best case, use stable .12 until .14 comes out and then carefully check whats new.

Nils



On Wed, 2010-03-24 at 22:31 +0100, Nils Gey wrote:

My memory was not wrong! On sunday it still worked (for me)


On Sunday the 21th I gubbed and installed a version, still labeled 0.8.15 and installed it on my laptop which had a fresh Windows 7 version on it.
Print Preview / PDF Generation works there.

Nils

On Wed, 24 Mar 2010 18:00:34 +0000


On Wed, 2010-03-24 at 09:03 +0000, Richard Shann wrote:

I have built using the my old gub, and Nils' findings apply to this also: the .pdf file is created with zero length, but lilypond does not
start until denemo exits, whereon the .pdf file is populated.
So this is *not* a bug caused by Nils' new gub code.

It seems the bug is because the code which generates a new name for each print during a denemo session has been disabled. I'll look into it.


Despite disabling all touching of the output pdf by denemo, the lilypond process still refuses it progress beyond getting itself installed in the process table (or whatever Windows has - it is in the list of processes in the task manager, but does not consume cpu until denemo exits). I did the experiment of launching a 0.8.15 in this same environment, ie
in the installation that I have made from todays sources. That

executable does not set LilyPond's path, so it has to be set outside, but once that is done the lilypond executable does run to completion
without waiting for denemo to quit.
I am bemused.
Richard


Richard

On Tue, 2010-03-23 at 21:54 +0000, Richard Shann wrote:

OK I have set all these up and checked the code into git.

One incomplete feature is that the GUILE_LOAD_PATH is over- written, as we have to be sure that the denemo scm files are in it. But this would mean that we would get the newer lilypond scm files if someone had already set GUILE_LOAD_PATH to an older installation of lilypond and
wished to use it.

LilyPond failing to run until Denemo exits would make sense if Denemo still had the .ly file open, as windows does file locking (I think). But
why this should show now I can't imagine.

A useful test would be to install LilyPond system wide as well as inside
Denemo and see if the same holds.
Richard

On Tue, 2010-03-23 at 21:40 +0100, Nils Gey wrote:

Actually the push failed, and I will delay while further investigations
take place
Richard


Investigation Complete:


I finally got all lilypond enviroment variables right to run lilypond standalone and produce a valid pdf file.
We need to copy this in Denemo.



_PATH:

...\denemo\usr\share\guile
...\denemo\usr\share\guile\1.8

...\denemo\usr\share\lilypond\current\scm //if we build lilypond git, its "current"
...\denemo\usr\share\guile
...\denemo\usr\share\guile

PATH:
...\denemo\usr\bin
...\denemo\usr\lib

LILYPOND_DATA_PATH
...\denemo\usr\share\lilypond\current\

LILYPOND_VERBOSE
1


this last one is actually not needed, but may be nice for future testing.



Problems remain, two are just to inform you, the third is the real one:


1)PDFs show up from where path\to\lilypond.exe was invoked. Means: The current working dir.


2)Running lilypond from the command line has problems. Maybe backslash\
escaping problems.
janneke: "and no-one uses the command line, apparently ;-)"


If you place the .ly file to the dir in %PATH% it works. And it works, if you do it with a file association, that means the console it the reason that it does not work (thats why I think its some escaping problem)



BUT (good news) from within Denemo these last two problems are no problems. The file gets generated and ends in the right place.


3)However the ly/pdf file does not gets processed until Denemo is closed. Don't ask me, I don't know why... You see the lilypond terminal open all the time, but nothing happens, and if you quit Denemo the processing begins and the pdf is right there.

Nils



_______________________________________________
Denemo-devel mailing list
http://lists.gnu.org/mailman/listinfo/denemo-devel



_______________________________________________
Denemo-devel mailing list
http://lists.gnu.org/mailman/listinfo/denemo-devel







_______________________________________________
Denemo-devel mailing list