denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Richard Shann
Subject: Re: [Denemo-devel] Release 0.8.16 - Gub Status
Date: Thu, 25 Mar 2010 19:08:49 +0000

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]