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

[Richard Shann]

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.

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


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
> >