Re: 2.6 Release
Op vrijdag 30 december 2011 09:06:58 schreef u: On Dec 30, 2011, at 2:57 AM, Geert Janssens wrote: Op donderdag 29 december 2011 14:18:38 schreef u: On Dec 29, 2011, at 12:24 PM, Christian Stimming wrote: Am Mittwoch, 28. Dezember 2011, 18:16:48 schrieb John Ralls: A release plan isn't a list of features to get enough reasons for a 2.6.0 release. It's a list of features and existing bugs, whether implemented or not, that the project team agrees should be what's going to be in the 2.6.0 release. It guides the testers who use the development (2.5.x) releases, so that they know what to try out, and to write bugs against. Ok, let my re-phrase my original proposal, like so: Over the past months, several very useful features for small business usage have been added to trunk. I'd like to get those features out in the stable releases so that users who are asking for this can get them through their default distro package, which implies those features need to appear in a stable release series. Here's an (incomplete) list of new features for small business users which is now available in trunk but not in 2.4: * Customer / Vendor overview pages * Print to PDF for reports and invoices by a single button click * Allow Filter By settings to be saved and re-used * Customer overview reports * Line chart report for Net Worth (Bug #664862) * Re-assign existing transactions as payments * Duplicate invoices * Easier invoice / bill handling: Post, Print, or Duplicate multiple items directly from the search result list * Better invoice printing setup: Choose the default invoice report for printing in the preferences * Change the ordering of invoice entries by up/down buttons in the invoice window * and last but not least Geert has ongoing work to include Credit Notes I propose to start a new 2.5.0 / 2.6.0 release series in order to make those small business user improvements available in a stable release. As already discussed in length, there haven't been that much significant changes in gnucash apart from these features which might seem minor to all users who don't happen to use gnucash for running a business. On the upside, this means trunk in itself isn't that much unstable right now, which means we will probably get a 2.6.0 stable release ready with only very few unstable 2.5.x releases on the way. Because of this, the extra work to get trunk into shape for another stable branch is probably only a small distraction from longer- term work that will continue on trunk. I doubt that either Gtk3 or the engine cleanup will be done in another year unless a lot of help shows up. Going through a development release series while continuing that work in trunk will push both further out: Time spent getting a release polished up is time not spent on longer-term projects. By the way, the time between 2.2.0 and 2.4.0 was 42 months (July 2007 to December 2010); it was 22 months between releasing 2.2.0 and the first 2.3 release (May 2009). What's special about a year? Point taken. My proposal is not based on particular time frames, but rather on making this collection of small business improvements available in a stable release, and do so in the near future (i.e. within the next 2-4 months). Other proposals / comments? Thank you. That's much better; perhaps we can turn it into a wiki page to point testers at. Are there unit tests for all of those features? Most of what I've worked at are GUI related items. I don't think we have unit tests for any of the GUI's. I will check to add some unit tests for the small changes I did in the engine though. I'll spend some more time chasing down edits that aren't immediately committed, so that the SQL backend is sure to work properly (and also add automated tests for that to setters). Is it feasible to remove Guile 1.6 support (by fixing the deprecation warnings with Guile 1.8)? Will that be sufficient to make Guile 2.0 work? (I'm willing to do the work.) I have been investigating this problem before. Here are my findings so far: GnuCash itself is no longer using any deprecated Guile routines. The deprecated warnings come from the autogenerated swig code. There are a number of related bugreports to give you some more information: Gnome's bugzilla (GnuCash): https://bugzilla.gnome.org/show_bug.cgi?id=655901 Fedora has two related bugs, the latter being the most relevant one: https://bugzilla.redhat.com/show_bug.cgi?id=752054 https://bugzilla.redhat.com/show_bug.cgi?id=704527 All these bugs eventually refer to a swig upstream bug: http://sourceforge.net/tracker/?func=detailaid=1511038group_id=1645at id=301645 I left a comment there early November, but there's no response so far. If this has to be worked around from within GnuCash, the only option I
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Am Donnerstag, 29. Dezember 2011, 15:11:39 schrieb John Ralls: Which turned out to be more WebKit contamination, sort of. Ktoblzcheck needs a couple of libraries from mingw (libstdc++-6.dll and libgcc_s_dw2-1.dll) and we were relying on WebKit to provide them -- but it only provides an older version of libstdc++-1. Very interesting. Now, libktoblzcheck isn't anything miraculous - it's just a C++ library that we build ourselves. Apparently once we do this, the libstdc++ of the compiler needs to be present but hasn't been so far. This change is most probably also needed in trunk, isn't it? It wouldn't matter whether we built it or got a binary from somewhere: If it links against libstdc++, it has to have it. C++ library symbols are mangled in a compiler-specific way, so it's not possible to link a program made with one compiler against a library made with another. But that wasn't the problem here: The libstdc++-6 that WekKit provided didn't define a symbol that ktoblzcheck wanted (__gxx_personality_v0), but there are a couple of dozen others that it was perfectly happy with. That indicates a libstdc++-6 version problem rather than a wrong compiler problem. Yes: From the description it sounds as if webkit's libstdc++6 was older than the one of the mingw that we use. Hence the newer one of mingw has some symbol which the older one hasn't, and this is what the hand-compiled ktoblzcheck complains about. But I don't know libstdc++ version details here. It looks to me from the symbols imported from libgcc_s_dw2-1 (Unwind_resume, _deregister_frame_info, _moddi3, and _register_frame_info) that it has to do with debugging, so we might be able to get rid of that dependency by changing CFLAGS. I tried, but apparently linking against libstdc++ always pulls in this libgcc_s. There were no CFLAGS or similar that triggered the linking to this library, nor were there any that could be removed to remove this dependency. I don't know if it needs changing in trunk. AQB works there, right? I haven't checked myself on windows, ever. From the gnucash-de mailing list reports apparently it does work. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.6 Release
Am Donnerstag, 29. Dezember 2011, 14:18:38 schrieb John Ralls: I propose to start a new 2.5.0 / 2.6.0 release series in order to make those small business user improvements available in a stable release. As already discussed in length, there haven't been that much significant changes in gnucash apart from these features which might seem minor to all users who don't happen to use gnucash for running a business. Thank you. That's much better; perhaps we can turn it into a wiki page to point testers at. Yes. I've collected my list at http://wiki.gnucash.org/wiki/Release_Schedule#Feature_Checklist_for_2.6.0 Feel free to edit this list and/or add any comments, as usual in the wiki. Are there unit tests for all of those features? No. The points I mentioned are all UI features, for which we don't have any unittests so far. But all of those features have been implemented by direct user requests who also acknowledged the successful implementation of the feature, so they are indeed in daily use by some people. On the other hand some of them imply some additional engine layer features (or business logic features), and of course those might get tested by unittests. To my knowledge, none of those features have had business logic unittests added. I will look into adding this, but I doubt it will cover any significant parts of those features. Best Regards, Christian I'll spend some more time chasing down edits that aren't immediately committed, so that the SQL backend is sure to work properly (and also add automated tests for that to setters). Is it feasible to remove Guile 1.6 support (by fixing the deprecation warnings with Guile 1.8)? Will that be sufficient to make Guile 2.0 work? (I'm willing to do the work.) Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.6 Release
Need the guile 2.x thing resolved soon Tedc On Friday, December 30, 2011, Christian Stimming christ...@cstimming.de wrote: Am Donnerstag, 29. Dezember 2011, 14:18:38 schrieb John Ralls: I propose to start a new 2.5.0 / 2.6.0 release series in order to make those small business user improvements available in a stable release. As already discussed in length, there haven't been that much significant changes in gnucash apart from these features which might seem minor to all users who don't happen to use gnucash for running a business. Thank you. That's much better; perhaps we can turn it into a wiki page to point testers at. Yes. I've collected my list at http://wiki.gnucash.org/wiki/Release_Schedule#Feature_Checklist_for_2.6.0 Feel free to edit this list and/or add any comments, as usual in the wiki. Are there unit tests for all of those features? No. The points I mentioned are all UI features, for which we don't have any unittests so far. But all of those features have been implemented by direct user requests who also acknowledged the successful implementation of the feature, so they are indeed in daily use by some people. On the other hand some of them imply some additional engine layer features (or business logic features), and of course those might get tested by unittests. To my knowledge, none of those features have had business logic unittests added. I will look into adding this, but I doubt it will cover any significant parts of those features. Best Regards, Christian I'll spend some more time chasing down edits that aren't immediately committed, so that the SQL backend is sure to work properly (and also add automated tests for that to setters). Is it feasible to remove Guile 1.6 support (by fixing the deprecation warnings with Guile 1.8)? Will that be sufficient to make Guile 2.0 work? (I'm willing to do the work.) Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Guile Strings
On Dec 30, 2011, at 9:19 AM, Geert Janssens wrote:
Op vrijdag 30 december 2011 09:06:58 schreef u:
On Dec 30, 2011, at 2:57 AM, Geert Janssens wrote:
As for the string problem, we may have to modify the C-side functions to
require gstrdup'd strings that the consumer function frees. I'll have to
have a look at how those strings are being used to suggest something more
concrete.
The actual code that SWIG injects is
SWIGINTERN char *
SWIG_Guile_scm2newstr(SCM str, size_t *len) {
#define FUNC_NAME SWIG_Guile_scm2newstr
char *ret;
size_t l;
SCM_ASSERT (SCM_STRINGP(str), str, 1, FUNC_NAME);
l = SCM_STRING_LENGTH(str);
ret = (char *) SWIG_malloc( (l + 1) * sizeof(char));
if (!ret) return NULL;
memcpy(ret, SCM_STRING_CHARS(str), l);
ret[l] = '\0';
if (len) *len = l;
return ret;
#undef FUNC_NAME
}
As you can see, it's allocating a string on the heap and returning it, so
either the strings are already getting freed or we're already leaking them.
So I went ahead and built swig with the patch from the bug and gave it a spin.
It did indeed silence the deprecation warnings in guile-1.8.8.
Unfortunately guile-2.0 appears to have changed the way that extensions are
loaded, because with guile-2.0 installed make check fails with
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling
/Volumes/RAID1/Gnucash-Build/Gnucash-svn/src/gnucash-git/src/engine/test/./test-create-account.scm
;;; note: source file
/Volumes/RAID1/Gnucash-Build/Gnucash-svn/src/gnucash-git/src/gnc-module/gnc-module.scm
;;; newer than compiled
/Users/john/.cache/guile/ccache/2.0-LE-4-2.0/Volumes/RAID1/Gnucash-Build/Gnucash-svn/src/gnucash-git/src/gnc-module/gnc-module.scm.go
;;; compiling
/Volumes/RAID1/Gnucash-Build/Gnucash-svn/src/gnucash-git/src/gnc-module/gnc-module.scm
;;; WARNING: compilation of
/Volumes/RAID1/Gnucash-Build/Gnucash-svn/src/gnucash-git/src/gnc-module/gnc-module.scm
failed:
;;; ERROR: no code for module (sw_gnc_module)
./test-create-account: line 2: 80147 Bus error guile -l
$SRCDIR/test-create-account.scm -c (exit (run-test))
I poked at it briefly, but it couldn't get it to work.
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
What about backporting the feature table patch? -derek Sent from my HTC on the Now Network from Sprint! - Reply message - From: John Ralls jra...@ceridwen.us Date: Fri, Dec 30, 2011 6:30 pm Subject: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24. To: Cc: gnucash-devel@gnucash.org On Dec 29, 2011, at 2:00 PM, John Ralls wrote: On Dec 27, 2011, at 10:09 PM, John Ralls wrote: It's still not quite ready for release: Gnucash isn't noticing that AQB is present. Which turned out to be more WebKit contamination, sort of. Ktoblzcheck needs a couple of libraries from mingw (libstdc++-6.dll and libgcc_s_dw2-1.dll) and we were relying on WebKit to provide them -- but it only provides an older version of libstdc++-1. Screen shot 2011-12-29 at 1.49.30 PM.png We should be able to release 2.4.9 after checking tomorrow's build. Which failed. I hadn't changed the guile/1.6 reference in gnucash.iss.in. That's committed, and the package I built today installed and launched, so I think we can tag tomorrow, unless we want to wait till after New Year's day. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 30, 2011, at 5:17 PM, Derek Atkins wrote: What about backporting the feature table patch? Oh, did you commit that to trunk? I thought you'd done it direct to 2.4. If you don't beat me to it, I'll backport it tomorrow. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
