On Wed, 2013-01-30 at 10:05 -0600, Jeremiah Benham wrote: > On 01/29/2013 11:50 AM, Richard Shann wrote: > > What do you think - shall we make a release of the source code but > > wait until we have binaries built from it to announce on various > > forums? > > Do you feel like the bug you mention is in the uncross-compiled > version? I am guessing it is caused by something wrong in the building via cross-compiling.
> If not, we could always release the binaries later. If we release, we > can make an additional announcement when the binaries are created. Yes, and if it proves to be a Denemo source code bug we would release 1.2 as soon as it is fixed. > > I created a gub branch called release-mingw-0.9.6. With it I compiled > the mingw and master branches of denemo. > mingw: > denemo-1.0.0.~rc.7-7.mingw.exe > master: > denemo-1.0.0.~rc.7-8.mingw.exe > > I tested the mingw out on a windows xp machine. It crashed everytime > with a popup telling me about project recovery. Whatever I click > denemo exits. I tried deleting the .denemo-1.xxx dir and it the dialog > still pops up. The crashrecovery routine is triggered by the presence of a file gchar *crash_file = g_build_filename(locatedotdenemo (), "crashrecovery.denemo", NULL); this cannot happen if you successfully deleted the relevant .denemoxxx directory. Well, of course if the program is already running amok, it could still happen, more or less anything can. > Is it this dialog? I looked at the code in view.c and thought that > this dialog would probably be better off in its own function. It looks > suspicious. It is certainly that - I have never known it to do anything useful. It dates back to the days when Denemo was full of flaky code. But I don't suspect it of doing anything evil. > Can we run gdb somehow on it. Yes, when I had a windows partition I did do that. I would get it to stop on the g_dir_open_utf8() call and find out where it came from. However, if the problem is really wrongly put together libraries with in compatible interfaces we are not likely to get anywhere that way - we would be trying to debug code that was never intended to work together. It would only be useful if it were some Denemo bug that that was leading fairly directly to the problem. > Ironically, I fixed my wine installation and it ran both branches > fine (except for a couple of fonts not loading). Did you see the g_dir_open_utf8() assertion? I am seeing this on all windows builds, even those that work in other respects. I have gone back to the vista box and given it a bit of a work-out, it *does* seem to be working just fine. I have seen it working superficially on xp boxes, but looking at the denemo-console output showed serious problems. > It works better then the linux binary in gtk3 based systems. > > > > > If so, I will go ahead with a last turn of the manual/language > > update thing and we could freeze the code. > > > I will leave that up to you. Well, I have done all the language and so on stuff - and fixed some problems with the audio-in code. I've submitted the .pot file to translation.org, so I suggest we give a week for any final tweaks to the translations to come in and then build our best binaries with the version number set and decide then on which things to announce along with the tarball. Richard _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
