Re: [Denemo-devel] Release 1.0.8

[Richard Shann]

On Fri, 2013-09-13 at 16:31 +0100, Richard Shann wrote:
> On Fri, 2013-09-13 at 07:57 -0500, Jeremiah Benham wrote:
> > I created/uploaded a windows binary. Please test.
> Hmm, I ran this on the vista box which I have tested the most on. It
> fails to find things - stating with fluidsynth sound font (I think) and
> ending with failing to find denemoui.xml
> I tried starting it up in /usr/share/denemo/ui where that file is

I made some progress with this: by putting the ui directory inside the
C:\Program Files\Denemo\usr\bin directory I got Denemo to find
denemoui.xml on startup. This works because Eloi made Denemo check for
ui/denemoui.xml in the current working directory on startup. So this
check worked, and the file was found and opened. But when that is not
present it should check 
C:\Program Files\Denemo\usr\share\denemo\ui\denemoui.xml

but apparently that fails, though the file is present.

Having got passed the fatal error of not finding denemoui.xml it starts
up and even runs LilyPond on the initial empty score ok. But in fact
during startup it has failed to find the scheme scripts, so there is a
lot not working. Using the Scheme window I could run the scheme
procedure

(getenv "GUILE_LOAD_PATH")

and hence verify that the correct guile load path was in the environment
(as claimed during start up). So this is a puzzle. I have looked back to
see what changes might have affected finding files and found this
suspicious code which I think is due to Eloi:


const gchar*
get_executable_dir ()
{
  static const gchar* dir = NULL;
  if(dir == NULL)
  {
    char path[1024];

#ifdef G_OS_WIN32
    GetModuleFileNameW(NULL, path, MAX_PATH);

#elif defined _MACH_O_
    char path[1024];
    guint size = sizeof (path);
    _NSGetExecutablePath (path, &size);

#else
   readlink("/proc/self/exe", path, sizeof(path));

#endif
    dir = g_path_get_dirname(path);
  }
  return dir;
}

I *think* I see several problems here: the char path[1024] is declared
twice in the _MACH_O_ case, and the MAX_PATH seems un-related to the
1024 value, and reading the Microsoft docs for GetModuleFileNameW it
seems that this string is not NULL terminated under Windows XP if it
exceeds MAX_PATH TCHARS (whatever they are
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683197%
28v=vs.85%29.aspx

But none of this would seem an obvious cause of failing to find most of
the files (soundfont, scheme scripts ...), denemoui.xml on windows.
Another thing that worries me is the use of ".." as a path element - I
*think* this does work on windows, but I am not certain. But again, this
doesn't seem to be a killer (why is get_executable_dir() needed - I
thought we were using a portable function from Glib for that?)

None would explain why guile fails to find things in the GUILE_LOAD_PATH
- that code is AFAIK untouched.

As it is, we don't have much of a release to offer :(

Richard