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
Richard Shann <address@hidden> wrote:
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.
It can be downloaded here: http://www.nilsgey.de/denemo-0.8.15-20100321.exe
Nils
On Wed, 24 Mar 2010 18:00:34 +0000
Richard Shann <address@hidden> wrote:
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.
GUILE_LOAD
_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
address@hidden
http://lists.gnu.org/mailman/listinfo/denemo-devel
_______________________________________________
Denemo-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/denemo-devel
_______________________________________________
Denemo-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/denemo-devel