[GNC-dev] wiki:Installing_Dependencies#Installing_Main_GnuCash_Dependencies; was: Build Issues on Ubuntu jammy - guile

[Frank H. Ellenberger]

Hi,
Oh, we have
Dependencies,
Installing_Dependencies, and the
Building* pages

The list in Installing_Dependencies was not maintained at least the last
2 years.

>From my POV it is hard to maintain because it lists
* indirect dependencies from the times, when apt and rpm were unable to
resolve dependencies.
* contains explicit minor and packaging versions, which might have been
right some years ago on a specific Ubuntu version, but  not in the
package managers of other distributions.

In short I am in favour of replacing this list by a link to
README.dependencies.

David, you have been the author?

Regards
Frank


Am 17.07.22 um 18:33 schrieb Paul Kroitor:
> Line 5 in the large list at 
> https://wiki.gnucash.org/wiki/Installing_Dependencies
> 
> -Original Message-
> From: Frank H. Ellenberger  
> Sent: July 17, 2022 12:27 PM
> To: Paul Kroitor 
> Cc: gnucash-devel@gnucash.org
> Subject: Re: [GNC-dev] Build Issues on Ubuntu jammy - guile
> 
> 
> 
> Am 17.07.22 um 17:25 schrieb Paul Kroitor:
>> *the documentation says use guile 2.0 but only 2.2 or 3.0 are 
>> available - is there any reason not to install 3.0?
>>
> Where exactly?
> Perhaps it was written a few years ago with conservatie LTS users in mind, 
> which can be 5 years behind.
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Build Issues on Ubuntu jammy - guile

[Paul Kroitor]

Line 5 in the large list at 
https://wiki.gnucash.org/wiki/Installing_Dependencies

-Original Message-
From: Frank H. Ellenberger  
Sent: July 17, 2022 12:27 PM
To: Paul Kroitor 
Cc: gnucash-devel@gnucash.org
Subject: Re: [GNC-dev] Build Issues on Ubuntu jammy - guile



Am 17.07.22 um 17:25 schrieb Paul Kroitor:
> *the documentation says use guile 2.0 but only 2.2 or 3.0 are 
> available - is there any reason not to install 3.0?
> 
Where exactly?
Perhaps it was written a few years ago with conservatie LTS users in mind, 
which can be 5 years behind.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Build Issues on Ubuntu jammy - guile

[Frank H. Ellenberger]

Am 17.07.22 um 17:25 schrieb Paul Kroitor:
> *the documentation says use guile 2.0 but only 2.2 or 3.0 are available - is
> there any reason not to install 3.0? 
> 
Where exactly?
Perhaps it was written a few years ago with conservatie LTS users in
mind, which can be 5 years behind.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] gnucash-on-windows master: Guile 2.2 for Windows.

[Geert Janssens]

Op vrijdag 26 april 2019 16:44:03 CEST schreef John Ralls:
> > I am aware I suggested on irc to put the tarball on sourceforge. However
> > while seeing this commit I wonder if there's a reason not to do as we did
> > for guile 2.0: start from the upstream tarball and apply patches during
> > the build ? That would mean storing the patches in our gnucash-on-windows
> > repo.
> The last Guile release was almost a year ago and I'm not able to get it to
> build, so the patch set to that tarball would have to incorporate all of
> the commits to bring it current with stable-2.2. If the Guile team would do
> a release then we could reasonably use that tarball. In an ideal world it
> would include my patches [1][2] and we could use it unmodified.
> 
Oh, in that case, let's just stick with our own guile tarball until the guile 
team does another release. Perhaps make a note of this somewhere so we 
remember in a year or so why we did this.

Geert

> Regards,
> John Ralls
> 
> [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=35405
> [2] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=35430




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] gnucash-on-windows master: Guile 2.2 for Windows.

[John Ralls]

> On Apr 26, 2019, at 12:22 AM, Geert Janssens via gnucash-devel 
>  wrote:
> 
> Op donderdag 25 april 2019 23:54:01 CEST schreef John Ralls:
>> Updated   via  
>> https://github.com/Gnucash/gnucash-on-windows/commit/c739d231
>> (commit) from 
>> https://github.com/Gnucash/gnucash-on-windows/commit/fe22df60 (commit)
>> 
>> 
>> 
>> commit c739d231b5dc4775d40433d3148979a4a4d4c7ab
>> Author: John Ralls 
>> Date:   Thu Apr 25 14:53:28 2019 -0700
>> 
>>Guile 2.2 for Windows.
>> 
>> diff --git a/gnucash.modules b/gnucash.modules
>> index 04c3856..29b8c62 100644
>> --- a/gnucash.modules
>> +++ b/gnucash.modules
>> @@ -119,11 +119,9 @@
>>   
>> 
>>   
>> -  > autogen-sh="autoreconf" autogenargs="--without-threads">
>> -> repo="ftp.gnu.org" module="guile/guile-2.0.14.tar.gz" - 
>> version="2.0.14">
>> -  > file="https://raw.githubusercontent.com/Gnucash/gnucash-on-windows/master/p
>> atches/guile-2.0.14-mingw64-fixups.patch" strip="1"/>
>> -  > file="https://raw.githubusercontent.com/Gnucash/gnucash-on-windows/master/p
>> atches/guile-2.0.14-Fix-mktime-test.patch" strip="1"/>
>> +  > id="guile2" autogen-sh="configure" autogenargs="--disable-rpath
>> --enable-networking --enable-nls --enable-posix --enable-regex
>> --with-threads --with-modules --disable-static">
>> +> repo="sourceforge" module="gnucash/Dependencies/guile-2.2.4+mingw.tar.bz2"
>> +version="2.2.4+mingw">
> 
> I am aware I suggested on irc to put the tarball on sourceforge. However 
> while 
> seeing this commit I wonder if there's a reason not to do as we did for guile 
> 2.0: start from the upstream tarball and apply patches during the build ?
> That would mean storing the patches in our gnucash-on-windows repo.

The last Guile release was almost a year ago and I'm not able to get it to 
build, so the patch set to that tarball would have to incorporate all of the 
commits to bring it current with stable-2.2. 
If the Guile team would do a release then we could reasonably use that tarball. 
In an ideal world it would include my patches [1][2] and we could use it 
unmodified.

Regards,
John Ralls

[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=35405
[2] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=35430
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] gnucash-on-windows master: Guile 2.2 for Windows.

[Geert Janssens via gnucash-devel]

Op donderdag 25 april 2019 23:54:01 CEST schreef John Ralls:
> Updatedvia  
> https://github.com/Gnucash/gnucash-on-windows/commit/c739d231
> (commit) from 
> https://github.com/Gnucash/gnucash-on-windows/commit/fe22df60 (commit)
> 
> 
> 
> commit c739d231b5dc4775d40433d3148979a4a4d4c7ab
> Author: John Ralls 
> Date:   Thu Apr 25 14:53:28 2019 -0700
> 
> Guile 2.2 for Windows.
> 
> diff --git a/gnucash.modules b/gnucash.modules
> index 04c3856..29b8c62 100644
> --- a/gnucash.modules
> +++ b/gnucash.modules
> @@ -119,11 +119,9 @@
>
> 
>
> -   autogen-sh="autoreconf" autogenargs="--without-threads">
> - repo="ftp.gnu.org" module="guile/guile-2.0.14.tar.gz" -  
> version="2.0.14">
> -   file="https://raw.githubusercontent.com/Gnucash/gnucash-on-windows/master/p
> atches/guile-2.0.14-mingw64-fixups.patch" strip="1"/>
> -   file="https://raw.githubusercontent.com/Gnucash/gnucash-on-windows/master/p
> atches/guile-2.0.14-Fix-mktime-test.patch" strip="1"/>
> +   id="guile2" autogen-sh="configure" autogenargs="--disable-rpath
> --enable-networking --enable-nls --enable-posix --enable-regex
> --with-threads --with-modules --disable-static">
> + repo="sourceforge" module="gnucash/Dependencies/guile-2.2.4+mingw.tar.bz2"
> + version="2.2.4+mingw">

I am aware I suggested on irc to put the tarball on sourceforge. However while 
seeing this commit I wonder if there's a reason not to do as we did for guile 
2.0: start from the upstream tarball and apply patches during the build ?
That would mean storing the patches in our gnucash-on-windows repo.

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] gnucash maint: Set the SWIG minimum version to 2.0.11 now that we require Guile-2.0.

[John Ralls]

> On Aug 11, 2018, at 1:27 AM, Geert Janssens  
> wrote:
> 
> Op vrijdag 10 augustus 2018 22:02:28 CEST schreef John Ralls:
>> Updated   via  https://github.com/Gnucash/gnucash/commit/22dd716b 
>> (commit)
>>  from  https://github.com/Gnucash/gnucash/commit/2f861bc2 (commit)
>> 
>> 
>> 
>> commit 22dd716b58a6a9c424a71268f78af37b972ab23b
>> Author: John Ralls 
>> Date:   Fri Aug 10 12:57:46 2018 -0700
>> 
>>Set the SWIG minimum version to 2.0.11 now that we require Guile-2.0.
>> 
>> diff --git a/CMakeLists.txt b/CMakeLists.txt
>> index f5d372e..42a23b6 100644
>> --- a/CMakeLists.txt
>> +++ b/CMakeLists.txt
>> @@ -285,7 +285,7 @@ endif (WIN32)
>> 
>> # SWIG
>> if(GENERATE_SWIG_WRAPPERS)
>> -  find_package (SWIG REQUIRED)
>> +  find_package (SWIG 2.0.10 REQUIRED)
> 
> Interestingly your comment says to require 2.0.11 but you enforce only 2.0.10
> 
> Which version is the correct minimum one ?

Darn. It should be 2.0.10, according to your code from 2.6’s configure.ac.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] gnucash maint: Set the SWIG minimum version to 2.0.11 now that we require Guile-2.0.

[Geert Janssens]

Op vrijdag 10 augustus 2018 22:02:28 CEST schreef John Ralls:
> Updatedvia  https://github.com/Gnucash/gnucash/commit/22dd716b 
> (commit)
>   from  https://github.com/Gnucash/gnucash/commit/2f861bc2 (commit)
> 
> 
> 
> commit 22dd716b58a6a9c424a71268f78af37b972ab23b
> Author: John Ralls 
> Date:   Fri Aug 10 12:57:46 2018 -0700
> 
> Set the SWIG minimum version to 2.0.11 now that we require Guile-2.0.
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index f5d372e..42a23b6 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -285,7 +285,7 @@ endif (WIN32)
> 
>  # SWIG
>  if(GENERATE_SWIG_WRAPPERS)
> -  find_package (SWIG REQUIRED)
> +  find_package (SWIG 2.0.10 REQUIRED)

Interestingly your comment says to require 2.0.11 but you enforce only 2.0.10

Which version is the correct minimum one ?

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Ubuntu. Both guile-2.0 and guile-2.2 installed, can't find guile-2.2

[Christopher Lam]

As it turns out, thanks to #guile, I found out I had to 'sudo apt 
install guile-2.2-dev' to properly get the right guile-2.2.


C


On 11/05/18 21:29, Christopher Lam wrote:

As per subject.

Having successfully worked on guile-2.0, I wished to try 2.2 and 'sudo 
apt install guile-2.2' and all was well. I can run guile-2.2.


However cmake rebuild script cannot find guile-2.2 and tries to 
configure with guile-2.0 instead.


However the test suite runs using guile-2.2 and obviously fails.

I think the CMake guile-2.0/2.2 detector can't handle having both.

Any clues?

Attached logfile from cmake... && cd build && ninja && ninja check



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Ubuntu. Both guile-2.0 and guile-2.2 installed, can't find guile-2.2

[Geert Janssens]

Op vrijdag 11 mei 2018 15:29:34 CEST schreef Christopher Lam:
> As per subject.
> 
> Having successfully worked on guile-2.0, I wished to try 2.2 and 'sudo
> apt install guile-2.2' and all was well. I can run guile-2.2.
> 
> However cmake rebuild script cannot find guile-2.2 and tries to
> configure with guile-2.0 instead.
> 
> However the test suite runs using guile-2.2 and obviously fails.
> 
> I think the CMake guile-2.0/2.2 detector can't handle having both.
> 
> Any clues?
> 
> Attached logfile from cmake... && cd build && ninja && ninja check

Did you install guile-2.2-dev as well ?

In addition you may have to clear you CMakeCache. ISTR it doesn't always 
automatically recheck dependencies once they are resolved.

Geert



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Ubuntu. Both guile-2.0 and guile-2.2 installed, can't find guile-2.2

[John Ralls]

> On May 11, 2018, at 6:29 AM, Christopher Lam <christopher@gmail.com> 
> wrote:
> 
> As per subject.
> 
> Having successfully worked on guile-2.0, I wished to try 2.2 and 'sudo apt 
> install guile-2.2' and all was well. I can run guile-2.2.
> 
> However cmake rebuild script cannot find guile-2.2 and tries to configure 
> with guile-2.0 instead.
> 
> However the test suite runs using guile-2.2 and obviously fails.
> 
> I think the CMake guile-2.0/2.2 detector can't handle having both.
> 
> Any clues?
> 
> Attached logfile from cmake... && cd build && ninja && ninja check

Assuming you’re using a current maint clone it checks for 2.2 first, so it 
would seem to be a matter of not finding guile-2.2.

What does `pkg-config --modversion guile-2.2` return?

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] guile error during build

[Herbert Thoma]

Hi John,

Am 08.04.2018 um 18:45 schrieb John Ralls:




On Apr 8, 2018, at 3:04 AM, Herbert Thoma <herbert.th...@iis.fraunhofer.de> 
wrote:

This message had the subject "Building GnuCash 3 on openSuSE".
May be that did not raise enough attention ...

So, any hints from anybody with more scheme knowledge is greatly
appreciated.



<...>

With this environment set cmake completes, but make aborts with this
error:

[ 30%] Built target scm-gnc-module
Scanning dependencies of target scm-core-utils
[ 30%] Generating ../../lib64/gnucash/scm/ccache/2.0/gnucash/core-utils.go
Backtrace:
In srfi/srfi-1.scm:
619: 19 [for-each # #]


<...>


Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2

Any suggestions?

gcc --version
gcc (SUSE Linux) 4.8.5

guile --version
guile (GNU Guile) 2.0.9


Frank did reply to your first email, though he didn’t address the missing 
gnc-build-userdata-path.


Yes, I saw that.


Delete ~/.cache/guile


Did not help.

Make sure that you’re building from a completely clean source, in a completely clean build directory, and installing to a prefix with no //gnucash. 


I started from a fresh git clone, so this should be OK.


Make sure that there are no cached gnucash files anywhere guile can find them: 
You make need to fuddle guile’s search paths if you have gnucash installed from 
the package manager in /usr. I don’t know how to do that. The OpenSuSE packager 
hangs out on IRC with the nick luc14n0 and he might be able to help.


I'll fiddle with this when I find more spare time. Or just try it in a fresh VM.

Thanks for your suggestions.

Best regards,
 Herbert.


Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] guile error during build

[John Ralls]

> On Apr 8, 2018, at 3:04 AM, Herbert Thoma <herbert.th...@iis.fraunhofer.de> 
> wrote:
> 
> This message had the subject "Building GnuCash 3 on openSuSE".
> May be that did not raise enough attention ...
> 
> So, any hints from anybody with more scheme knowledge is greatly
> appreciated.
> 
> 
> Hi!
> 
> I did not build GnuCash myself for some time, but with 3.0 I did
> try again.
> 
> I'm running openSUSE Leap 42.3.
> 
> So the first error was about gettext being only version 0.19.2.
> OK, this is easily circumvented with -D ALLOW_OLD_GETTEXT=ON,
> but still a bit unfortunate because openSUSE Leap 42.3 ships only
> 0.19.2 and openSUSE Leap 42.3 is the most recent stable openSUSE
> distribution.
> 
> Next problem was GTEST. openSUSE Leap 42.3 has a package libgtest0,
> but this does not help. So I downloaded googletest and set the
> GTEST_ROOT and GMOCK_ROOT variables.
> 
> With this environment set cmake completes, but make aborts with this
> error:
> 
> [ 30%] Built target scm-gnc-module
> Scanning dependencies of target scm-core-utils
> [ 30%] Generating ../../lib64/gnucash/scm/ccache/2.0/gnucash/core-utils.go
> Backtrace:
> In srfi/srfi-1.scm:
> 619: 19 [for-each # #]
> In scripts/compile.scm:
> 182: 18 [# 
> "/home/tma/gnucash/gnucash_cvs/gnucash/libgnucash/core-utils/core-utils.scm"]
> In system/base/target.scm:
>  59: 17 [with-target "x86_64-suse-linux-gnu" ...]
> In system/base/compile.scm:
> 150: 16 [compile-file 
> "/home/tma/gnucash/gnucash_cvs/gnucash/libgnucash/core-utils/core-utils.scm" 
> ...]
>  43: 15 [call-once #]
> In ice-9/boot-9.scm:
> 171: 14 [with-throw-handler #t ...]
> In system/base/compile.scm:
>  59: 13 [#]
> 153: 12 [# 
> #]
> 216: 11 [read-and-compile # #:from ...]
> 232: 10 [lp (# # # # ...) # #]
> 180: 9 [lp # # # ...]
> In ice-9/boot-9.scm:
> 2320: 8 [save-module-excursion # language/scheme/compile-tree-il.scm:29:3 ()>]
> In language/scheme/compile-tree-il.scm:
>  31: 7 [#]
> In ice-9/psyntax.scm:
> 1091: 6 [expand-top-sequence ((re-export gnc-build-userdata-path)) () ...]
> 976: 5 [scan ((re-export gnc-build-userdata-path)) () ...]
> 270: 4 [scan ((# #)) () (()) ...]
> In ice-9/boot-9.scm:
> 2015: 3 [call-with-deferred-observers # ice-9/eval.scm:416:20 ()>]
> 700: 2 [for-each # #]
> In unknown file:
>   ?: 1 [scm-error misc-error #f ...]
> In ice-9/boot-9.scm:
> 106: 0 [# 
> misc-error ...]
> 
> ice-9/boot-9.scm:106:20: In procedure # ice-9/boot-9.scm:97:6 (thrown-k . args)>:
> ice-9/boot-9.scm:106:20: Undefined variable: gnc-build-userdata-path
> libgnucash/core-utils/CMakeFiles/scm-core-utils.dir/build.make:61: recipe for 
> target 'lib64/gnucash/scm/ccache/2.0/gnucash/core-utils.go' failed
> make[2]: *** [lib64/gnucash/scm/ccache/2.0/gnucash/core-utils.go] Error 1
> CMakeFiles/Makefile2:3773: recipe for target 
> 'libgnucash/core-utils/CMakeFiles/scm-core-utils.dir/all' failed
> make[1]: *** [libgnucash/core-utils/CMakeFiles/scm-core-utils.dir/all] Error 2
> Makefile:160: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> Any suggestions?
> 
> gcc --version
> gcc (SUSE Linux) 4.8.5
> 
> guile --version
> guile (GNU Guile) 2.0.9

Frank did reply to your first email, though he didn’t address the missing 
gnc-build-userdata-path.

Delete ~/.cache/guile
Make sure that you’re building from a completely clean source, in a completely 
clean build directory, and installing to a prefix with no 
//gnucash. Make sure that there are no cached gnucash files 
anywhere guile can find them: You make need to fuddle guile’s search paths if 
you have gnucash installed from the package manager in /usr. I don’t know how 
to do that. The OpenSuSE packager hangs out on IRC with the nick luc14n0 and he 
might be able to help.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] guile error during build

[Herbert Thoma]

This message had the subject "Building GnuCash 3 on openSuSE".
May be that did not raise enough attention ...

So, any hints from anybody with more scheme knowledge is greatly
appreciated.


Hi!

I did not build GnuCash myself for some time, but with 3.0 I did
try again.

I'm running openSUSE Leap 42.3.

So the first error was about gettext being only version 0.19.2.
OK, this is easily circumvented with -D ALLOW_OLD_GETTEXT=ON,
but still a bit unfortunate because openSUSE Leap 42.3 ships only
0.19.2 and openSUSE Leap 42.3 is the most recent stable openSUSE
distribution.

Next problem was GTEST. openSUSE Leap 42.3 has a package libgtest0,
but this does not help. So I downloaded googletest and set the
GTEST_ROOT and GMOCK_ROOT variables.

With this environment set cmake completes, but make aborts with this
error:

[ 30%] Built target scm-gnc-module
Scanning dependencies of target scm-core-utils
[ 30%] Generating ../../lib64/gnucash/scm/ccache/2.0/gnucash/core-utils.go
Backtrace:
In srfi/srfi-1.scm:
 619: 19 [for-each # #]
In scripts/compile.scm:
 182: 18 [# 
"/home/tma/gnucash/gnucash_cvs/gnucash/libgnucash/core-utils/core-utils.scm"]
In system/base/target.scm:
  59: 17 [with-target "x86_64-suse-linux-gnu" ...]
In system/base/compile.scm:
 150: 16 [compile-file 
"/home/tma/gnucash/gnucash_cvs/gnucash/libgnucash/core-utils/core-utils.scm" 
...]
  43: 15 [call-once #]
In ice-9/boot-9.scm:
 171: 14 [with-throw-handler #t ...]
In system/base/compile.scm:
  59: 13 [#]
 153: 12 [# #]
 216: 11 [read-and-compile # #:from ...]
 232: 10 [lp (# # # # ...) # #]
 180: 9 [lp # # # ...]
In ice-9/boot-9.scm:
2320: 8 [save-module-excursion #]
In language/scheme/compile-tree-il.scm:
  31: 7 [#]
In ice-9/psyntax.scm:
1091: 6 [expand-top-sequence ((re-export gnc-build-userdata-path)) () ...]
 976: 5 [scan ((re-export gnc-build-userdata-path)) () ...]
 270: 4 [scan ((# #)) () (()) ...]
In ice-9/boot-9.scm:
2015: 3 [call-with-deferred-observers #]
 700: 2 [for-each # #]
In unknown file:
   ?: 1 [scm-error misc-error #f ...]
In ice-9/boot-9.scm:
 106: 0 [# 
misc-error ...]

ice-9/boot-9.scm:106:20: In procedure #:
ice-9/boot-9.scm:106:20: Undefined variable: gnc-build-userdata-path
libgnucash/core-utils/CMakeFiles/scm-core-utils.dir/build.make:61: recipe for 
target 'lib64/gnucash/scm/ccache/2.0/gnucash/core-utils.go' failed
make[2]: *** [lib64/gnucash/scm/ccache/2.0/gnucash/core-utils.go] Error 1
CMakeFiles/Makefile2:3773: recipe for target 
'libgnucash/core-utils/CMakeFiles/scm-core-utils.dir/all' failed
make[1]: *** [libgnucash/core-utils/CMakeFiles/scm-core-utils.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2

Any suggestions?

gcc --version
gcc (SUSE Linux) 4.8.5

guile --version
guile (GNU Guile) 2.0.9


 Herbert.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: update of guile version in windows build

[Sébastien de Menten]

Great!
I have installed gnucash 2.7 on windows (downloaded the binaries) but can't
make it work.
Anyone using the 2.7 binaries for windows successfully?



On Nov 14, 2017 11:00 AM, "Geert Janssens" <geert.gnuc...@kobaltwit.be>
wrote:

Op dinsdag 14 november 2017 09:01:01 CET schreef Sébastien de Menten:
> hello,
>
> What version of guile is packaged with the windows build of gnucash ?
> I have the impression it is the 1.8.8 released in 2010 but am not sure...
> if so, would it be possible to upgrade it to 2.0 or 2.2 ?
>
> sebastien

Gnucash 2.6 is indeed still shipped with guile 1.8 on Windows. Gnucash
2.7/2.8
will ship guile 2.0 on all platforms.

Regards,

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: update of guile version in windows build

[Geert Janssens]

Op dinsdag 14 november 2017 09:01:01 CET schreef Sébastien de Menten:
> hello,
> 
> What version of guile is packaged with the windows build of gnucash ?
> I have the impression it is the 1.8.8 released in 2010 but am not sure...
> if so, would it be possible to upgrade it to 2.0 or 2.2 ?
> 
> sebastien

Gnucash 2.6 is indeed still shipped with guile 1.8 on Windows. Gnucash 2.7/2.8 
will ship guile 2.0 on all platforms.

Regards,

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

update of guile version in windows build

[Sébastien de Menten]

hello,

What version of guile is packaged with the windows build of gnucash ?
I have the impression it is the 1.8.8 released in 2010 but am not sure...
if so, would it be possible to upgrade it to 2.0 or 2.2 ?

sebastien
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

guile

[Aaron Laws]

I'm using archlinux (https://distrowatch.com/table.php?distribution=arch).
It supplies guile 2.0 and guile 2.2 at the same time as /usr/bin/guile2.0
and /usr/bin/guile, respectively. When I build gnucash, I get errors since
I'm using guile2.2. Perhaps the fix is as simple as:

FIND_PROGRAM (GUILE_EXECUTABLE guile2.0 guile)

(and an analogous change for guild) in CMakeLists.txt ? If someone else
would make this change and confirm that the system can find "guile" as
well, that would be helpful.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Missing Guile Bindings and False Positive Unit tests

[Derek Atkins]

Hi,

Chad Albers <calb...@neomantic.com> writes:

> Hi Derek,
>
> Thanks for the history about Gnucash bindings.  I might be asking for
> trouble.  I just would rather interact with GnuCash rather that
> Python.  Personal preference that is pretty arbitrary.  I'm curious
> how far I can take it.

Oh, I understand.  Personally I would have rather seen Ruby bindings
instead of Python, but I didn't write them so 

> After further inspection, I now understand what you meant my "swig
> exports the functions for guile".  I found the exactly location where
> I need to add new exports in the swig interface file.  I haven't
> managed, though, to try it out yet.

Understood.  Good Luck!

-derek

>
> On Tue, Feb 21, 2017 at 11:59 AM, Derek Atkins <warl...@mit.edu> wrote:
>> Hi Chad,
>>
>> Please remember to CC gnucash-user on all replies so that everyone can
>> remain "in the loop".
>>
>> Also, the gnc-modules should properly export swig-exported functions
>> without a re-export.  If it stopped doing that, that would be a bug
>> IMHO.
>>
>> Note that these unit tests are probably 18 years old.
>>
>> 
>> A long long time ago (well, around GnuCash 1.6 or so), /usr/bin/gnucash
>> was a guile script.  It loaded everything in as guile modules
>> (technically it loaded GncModules) and then jumped back and forth
>> between C and Scheme.  Still, not everything was available from Scheme,
>> but I don't believe anything has been *removed* from the guile
>> bindings.
>>
>> Anyways, this structure was very hard to debug.  You couldn't
>> run it under gdb; you needed to "attach" gdb to the running process,
>> which made it nearly impossible to debug issues during application
>> loading.  Eventually the Schemer developers left the project to pursue
>> other endeavors, and those that remained eventually switched back to the
>> "main() in C" structure that we have today.
>>
>> Of course a bunch of the functionality is still in GncModules.
>> 
>>
>> Having said all that, you shouldn't need to export or re-export a
>> wrapped API.  It should "just work".  And the unit tests should be
>> properly failing when there are missing or broken APIs.
>>
>> -derek
>>
>> Chad Albers <calb...@neomantic.com> writes:
>>
>>> I'll file a bug report.
>>>
>>> But, for the record, swig isn't exporting.  That's not what swig does.
>>>   Function exports are done by using 2 APIs - the Guile define-modules
>>> API or Guiles' C API.
>>>
>>> For example,
>>>
>>> - Some guile functions are defined here:  src/engine/swig-engine.c.
>>> This is where qof-session-new is defined.
>>> - swig-engine.c uses Guile's C API to create a module called sw_engine
>>> - swig-engine.c exports the functions - including qof-session-new -
>>> using scm_c_export(...)
>>> - Several Guile scm files use this module: (use-modules (sw_engine)).
>>> None of these scm files either (export...) or (re-export...) functions
>>> from the sw_engine module.
>>>
>>> Therefore, none of the Guile  defined modules expose sw_engine functions.
>>>
>>> There may be, though, one exception, but even that isn't exposing
>>> anything from sw_engine.  The following is speculation...
>>>
>>> - GnuCash seems to include, what I suspect, is another module system.
>>> I think it's in the module (gnucash gnc-module).  Calls such as these
>>> -   (gnc:module-system-init) - may be a part that system.
>>> - Included in that system may be code from: src/engine/gncmod-engine.c
>>> - This C code has a C function  called 
>>> 'libgncmod_engine_gnc_module_init(...)
>>> - This includes the sw_engine module.  It calls
>>> scm_c_eval_string("(use-modules (sw_engine))");
>>> - This scm_c_eval_string does not include any (exports...) or
>>> (re-exports...) in the gncmode-engine.c file.
>>>
>>> Therefore, the sw_engine functions are not available in this other
>>> module system.
>>>
>>> To make the sw_engine functions available (which is what I would
>>> like),  this may have been how it was once accomplished. The units
>>> test that pass when they shouldn't include this line:
>>>
>>>  (gnc:module-load "gnucash/engine" 0)
>>>
>>> Maybe, at one time gnc:module-load exported functions from
>>> "gnucash/engine" modules.  Or something like that.  I'm still
>>> investigatin

Re: Missing Guile Bindings and False Positive Unit tests

[Chad Albers]

Hi Derek,

Thanks for the history about Gnucash bindings.  I might be asking for
trouble.  I just would rather interact with GnuCash rather that
Python.  Personal preference that is pretty arbitrary.  I'm curious
how far I can take it.

After further inspection, I now understand what you meant my "swig
exports the functions for guile".  I found the exactly location where
I need to add new exports in the swig interface file.  I haven't
managed, though, to try it out yet.
--


On Tue, Feb 21, 2017 at 11:59 AM, Derek Atkins <warl...@mit.edu> wrote:
> Hi Chad,
>
> Please remember to CC gnucash-user on all replies so that everyone can
> remain "in the loop".
>
> Also, the gnc-modules should properly export swig-exported functions
> without a re-export.  If it stopped doing that, that would be a bug
> IMHO.
>
> Note that these unit tests are probably 18 years old.
>
> 
> A long long time ago (well, around GnuCash 1.6 or so), /usr/bin/gnucash
> was a guile script.  It loaded everything in as guile modules
> (technically it loaded GncModules) and then jumped back and forth
> between C and Scheme.  Still, not everything was available from Scheme,
> but I don't believe anything has been *removed* from the guile
> bindings.
>
> Anyways, this structure was very hard to debug.  You couldn't
> run it under gdb; you needed to "attach" gdb to the running process,
> which made it nearly impossible to debug issues during application
> loading.  Eventually the Schemer developers left the project to pursue
> other endeavors, and those that remained eventually switched back to the
> "main() in C" structure that we have today.
>
> Of course a bunch of the functionality is still in GncModules.
> 
>
> Having said all that, you shouldn't need to export or re-export a
> wrapped API.  It should "just work".  And the unit tests should be
> properly failing when there are missing or broken APIs.
>
> -derek
>
> Chad Albers <calb...@neomantic.com> writes:
>
>> I'll file a bug report.
>>
>> But, for the record, swig isn't exporting.  That's not what swig does.
>>   Function exports are done by using 2 APIs - the Guile define-modules
>> API or Guiles' C API.
>>
>> For example,
>>
>> - Some guile functions are defined here:  src/engine/swig-engine.c.
>> This is where qof-session-new is defined.
>> - swig-engine.c uses Guile's C API to create a module called sw_engine
>> - swig-engine.c exports the functions - including qof-session-new -
>> using scm_c_export(...)
>> - Several Guile scm files use this module: (use-modules (sw_engine)).
>> None of these scm files either (export...) or (re-export...) functions
>> from the sw_engine module.
>>
>> Therefore, none of the Guile  defined modules expose sw_engine functions.
>>
>> There may be, though, one exception, but even that isn't exposing
>> anything from sw_engine.  The following is speculation...
>>
>> - GnuCash seems to include, what I suspect, is another module system.
>> I think it's in the module (gnucash gnc-module).  Calls such as these
>> -   (gnc:module-system-init) - may be a part that system.
>> - Included in that system may be code from: src/engine/gncmod-engine.c
>> - This C code has a C function  called 'libgncmod_engine_gnc_module_init(...)
>> - This includes the sw_engine module.  It calls
>> scm_c_eval_string("(use-modules (sw_engine))");
>> - This scm_c_eval_string does not include any (exports...) or
>> (re-exports...) in the gncmode-engine.c file.
>>
>> Therefore, the sw_engine functions are not available in this other
>> module system.
>>
>> To make the sw_engine functions available (which is what I would
>> like),  this may have been how it was once accomplished. The units
>> test that pass when they shouldn't include this line:
>>
>>  (gnc:module-load "gnucash/engine" 0)
>>
>> Maybe, at one time gnc:module-load exported functions from
>> "gnucash/engine" modules.  Or something like that.  I'm still
>> investigating the what/why/how of the other module system.
>>
>> In the meantime, one solution is just to re-export sw_engine functions
>> from (gnucash engine) or engine.scm.  That's what I'm doing for my
>> experiments, and it works.  Perhaps I will submit a patch for that,
>> but I'm thinking that that's a hack. I'm opening up the discussion
>> here for a better solution, if exposing more of the Guile API is a)
>> fixing a bug and/or b) adding a new feature.  Since much of GnuCash
>> was written in Guile, I thought I would use that instead of Python.
>> 

Re: Missing Guile Bindings and False Positive Unit tests

[Derek Atkins]

Ted Creedon  writes:

> FYI there is a swig problem in OpenSuse leap 4.2.
>
> Its not the latest version.

And this is why we package it up such that in general you don't need
swig to build GnuCash.  :)

> Tedc

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Missing Guile Bindings and False Positive Unit tests

[Ted Creedon]

FYI there is a swig problem in OpenSuse leap 4.2.

Its not the latest version.

Tedc

From: gnucash-devel <gnucash-devel-bounces+tcreedon=easystreet@gnucash.org> 
on behalf of Derek Atkins <warl...@mit.edu>
Sent: Tuesday, February 21, 2017 8:59:27 AM
To: Chad Albers
Cc: gnucash-devel@gnucash.org
Subject: Re: Missing Guile Bindings and False Positive Unit tests

Hi Chad,

Please remember to CC gnucash-user on all replies so that everyone can
remain "in the loop".

Also, the gnc-modules should properly export swig-exported functions
without a re-export.  If it stopped doing that, that would be a bug
IMHO.

Note that these unit tests are probably 18 years old.


A long long time ago (well, around GnuCash 1.6 or so), /usr/bin/gnucash
was a guile script.  It loaded everything in as guile modules
(technically it loaded GncModules) and then jumped back and forth
between C and Scheme.  Still, not everything was available from Scheme,
but I don't believe anything has been *removed* from the guile
bindings.

Anyways, this structure was very hard to debug.  You couldn't
run it under gdb; you needed to "attach" gdb to the running process,
which made it nearly impossible to debug issues during application
loading.  Eventually the Schemer developers left the project to pursue
other endeavors, and those that remained eventually switched back to the
"main() in C" structure that we have today.

Of course a bunch of the functionality is still in GncModules.


Having said all that, you shouldn't need to export or re-export a
wrapped API.  It should "just work".  And the unit tests should be
properly failing when there are missing or broken APIs.

-derek

Chad Albers <calb...@neomantic.com> writes:

> I'll file a bug report.
>
> But, for the record, swig isn't exporting.  That's not what swig does.
>   Function exports are done by using 2 APIs - the Guile define-modules
> API or Guiles' C API.
>
> For example,
>
> - Some guile functions are defined here:  src/engine/swig-engine.c.
> This is where qof-session-new is defined.
> - swig-engine.c uses Guile's C API to create a module called sw_engine
> - swig-engine.c exports the functions - including qof-session-new -
> using scm_c_export(...)
> - Several Guile scm files use this module: (use-modules (sw_engine)).
> None of these scm files either (export...) or (re-export...) functions
> from the sw_engine module.
>
> Therefore, none of the Guile  defined modules expose sw_engine functions.
>
> There may be, though, one exception, but even that isn't exposing
> anything from sw_engine.  The following is speculation...
>
> - GnuCash seems to include, what I suspect, is another module system.
> I think it's in the module (gnucash gnc-module).  Calls such as these
> -   (gnc:module-system-init) - may be a part that system.
> - Included in that system may be code from: src/engine/gncmod-engine.c
> - This C code has a C function  called 'libgncmod_engine_gnc_module_init(...)
> - This includes the sw_engine module.  It calls
> scm_c_eval_string("(use-modules (sw_engine))");
> - This scm_c_eval_string does not include any (exports...) or
> (re-exports...) in the gncmode-engine.c file.
>
> Therefore, the sw_engine functions are not available in this other
> module system.
>
> To make the sw_engine functions available (which is what I would
> like),  this may have been how it was once accomplished. The units
> test that pass when they shouldn't include this line:
>
>  (gnc:module-load "gnucash/engine" 0)
>
> Maybe, at one time gnc:module-load exported functions from
> "gnucash/engine" modules.  Or something like that.  I'm still
> investigating the what/why/how of the other module system.
>
> In the meantime, one solution is just to re-export sw_engine functions
> from (gnucash engine) or engine.scm.  That's what I'm doing for my
> experiments, and it works.  Perhaps I will submit a patch for that,
> but I'm thinking that that's a hack. I'm opening up the discussion
> here for a better solution, if exposing more of the Guile API is a)
> fixing a bug and/or b) adding a new feature.  Since much of GnuCash
> was written in Guile, I thought I would use that instead of Python.
> As is, though, there doesn't seem to be a way to even source a GnuCash
> using its Guile bindings.  It can be done using Python.
>
> Chad
>
> --
>
> On Sun, Feb 19, 2017 at 5:34 PM, Derek Atkins <de...@ihtfp.com> wrote:
>> That srfi didn't exist when the tests were written, which was probably
>> around 18 years ago.  The fact the tests don't fail just means nobody tested
>> the tests for false positives.  Please file a bug report?
>>
>> There isn't a need to be-export.  Swig 

Re: Missing Guile Bindings and False Positive Unit tests

[Derek Atkins]

Hi Chad,

Please remember to CC gnucash-user on all replies so that everyone can
remain "in the loop".

Also, the gnc-modules should properly export swig-exported functions
without a re-export.  If it stopped doing that, that would be a bug
IMHO.

Note that these unit tests are probably 18 years old.


A long long time ago (well, around GnuCash 1.6 or so), /usr/bin/gnucash
was a guile script.  It loaded everything in as guile modules
(technically it loaded GncModules) and then jumped back and forth
between C and Scheme.  Still, not everything was available from Scheme,
but I don't believe anything has been *removed* from the guile
bindings.

Anyways, this structure was very hard to debug.  You couldn't
run it under gdb; you needed to "attach" gdb to the running process,
which made it nearly impossible to debug issues during application
loading.  Eventually the Schemer developers left the project to pursue
other endeavors, and those that remained eventually switched back to the
"main() in C" structure that we have today.

Of course a bunch of the functionality is still in GncModules.


Having said all that, you shouldn't need to export or re-export a
wrapped API.  It should "just work".  And the unit tests should be
properly failing when there are missing or broken APIs.

-derek

Chad Albers <calb...@neomantic.com> writes:

> I'll file a bug report.
>
> But, for the record, swig isn't exporting.  That's not what swig does.
>   Function exports are done by using 2 APIs - the Guile define-modules
> API or Guiles' C API.
>
> For example,
>
> - Some guile functions are defined here:  src/engine/swig-engine.c.
> This is where qof-session-new is defined.
> - swig-engine.c uses Guile's C API to create a module called sw_engine
> - swig-engine.c exports the functions - including qof-session-new -
> using scm_c_export(...)
> - Several Guile scm files use this module: (use-modules (sw_engine)).
> None of these scm files either (export...) or (re-export...) functions
> from the sw_engine module.
>
> Therefore, none of the Guile  defined modules expose sw_engine functions.
>
> There may be, though, one exception, but even that isn't exposing
> anything from sw_engine.  The following is speculation...
>
> - GnuCash seems to include, what I suspect, is another module system.
> I think it's in the module (gnucash gnc-module).  Calls such as these
> -   (gnc:module-system-init) - may be a part that system.
> - Included in that system may be code from: src/engine/gncmod-engine.c
> - This C code has a C function  called 'libgncmod_engine_gnc_module_init(...)
> - This includes the sw_engine module.  It calls
> scm_c_eval_string("(use-modules (sw_engine))");
> - This scm_c_eval_string does not include any (exports...) or
> (re-exports...) in the gncmode-engine.c file.
>
> Therefore, the sw_engine functions are not available in this other
> module system.
>
> To make the sw_engine functions available (which is what I would
> like),  this may have been how it was once accomplished. The units
> test that pass when they shouldn't include this line:
>
>  (gnc:module-load "gnucash/engine" 0)
>
> Maybe, at one time gnc:module-load exported functions from
> "gnucash/engine" modules.  Or something like that.  I'm still
> investigating the what/why/how of the other module system.
>
> In the meantime, one solution is just to re-export sw_engine functions
> from (gnucash engine) or engine.scm.  That's what I'm doing for my
> experiments, and it works.  Perhaps I will submit a patch for that,
> but I'm thinking that that's a hack. I'm opening up the discussion
> here for a better solution, if exposing more of the Guile API is a)
> fixing a bug and/or b) adding a new feature.  Since much of GnuCash
> was written in Guile, I thought I would use that instead of Python.
> As is, though, there doesn't seem to be a way to even source a GnuCash
> using its Guile bindings.  It can be done using Python.
>
> Chad
>
> --
>
> On Sun, Feb 19, 2017 at 5:34 PM, Derek Atkins <de...@ihtfp.com> wrote:
>> That srfi didn't exist when the tests were written, which was probably
>> around 18 years ago.  The fact the tests don't fail just means nobody tested
>> the tests for false positives.  Please file a bug report?
>>
>> There isn't a need to be-export.  Swig exports do that automatically.
>>
>> -derek
>>
>> Sent from my mobile device. Please excuse any typos.
>>
>> - Reply message -
>> From: "Chad Albers" <calb...@neomantic.com>
>> To: "Derek Atkins" <de...@ihtfp.com>
>> Subject: Missing Guile Bindings and False Positive Unit tests
>> Date: Sun, Feb 19, 2017 5:23 PM
>&g

Re: Missing Guile Bindings and False Positive Unit tests

[Derek Atkins]

Hi,
Except for a few functions in app-utils, most of QofSession is not wrapped in 
the scheme bindings like they are in the python bindings.

-derek

Sent from my mobile device. Please excuse any typos.

- Reply message -
From: "Chad Albers" <calb...@neomantic.com>
To: <gnucash-devel@gnucash.org>
Subject: Missing Guile Bindings and False Positive Unit tests
Date: Sun, Feb 19, 2017 4:46 PM

Hi,

I found some problems with some unit tests for the Guile bindings.
Here's the background.

Rather than use the Python bindings, I wanted to use guile to add/manipulate
my GnuCash data.  From the Python bindings, I deduced that the entry
point into creating
transactions is via a construct called a "session".  Accordingly, I went to find
the Guile equivalent: "qof-session-new".  I wrote a Guile script which
successfully
imports GNUCash's guile bindings.  However, I was never able to successfully use
"qof-session-*" functions.  They are considered "unbound".

After further investigation, I found that GNUCash has unit tests that
specifically exercise the
'qof-session-new' function.
Here...'src/engine/test/test-create-account.scm'.  I ran
these units tests with 'make check' and they passed. I concluded that
since the unit test
passes, it must somehow have the binding for 'qof-session-new'.

'make check', though, creates a log for each unit test.  I peeked in
'test-create-account.scm.log'.
I found the following line:

;;; src/engine/test/./test-create-account.scm:30:18: warning: possibly
unbound variable `qof-session-new'

This is the same error that I have encountered in my own Guile script.
But...I also see this line
at the end of the test log.

PASS test-create-account (exit status: 0)

So the unit test cannot find 'qof-session-new' and yet the unit test
framework thinks its
passing. I wanted to let someone know that GNUCash has unit tests
(perhaps only for guile)
that are returning false positives. That's bug one.  Would you like me
to file a bug for this?

It turns out that GnuCash is not properly exposing the Guile bindings.
I consider this
a "bug", but others may disagree.  GnuCash seems to work pretty well
without them.  For my
purposes, though, I know where they are defined, why they aren't
exposed, and how to expose them.
If someone wants a patch for that, I may be able to provide it.

In the meantime, the heads up here is that there are some testing
returning false positives.

Let me know if you want any more information.
___
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

Missing Guile Bindings and False Positive Unit tests

[Chad Albers]

Hi,

I found some problems with some unit tests for the Guile bindings.
Here's the background.

Rather than use the Python bindings, I wanted to use guile to add/manipulate
my GnuCash data.  From the Python bindings, I deduced that the entry
point into creating
transactions is via a construct called a "session".  Accordingly, I went to find
the Guile equivalent: "qof-session-new".  I wrote a Guile script which
successfully
imports GNUCash's guile bindings.  However, I was never able to successfully use
"qof-session-*" functions.  They are considered "unbound".

After further investigation, I found that GNUCash has unit tests that
specifically exercise the
'qof-session-new' function.
Here...'src/engine/test/test-create-account.scm'.  I ran
these units tests with 'make check' and they passed. I concluded that
since the unit test
passes, it must somehow have the binding for 'qof-session-new'.

'make check', though, creates a log for each unit test.  I peeked in
'test-create-account.scm.log'.
 I found the following line:

;;; src/engine/test/./test-create-account.scm:30:18: warning: possibly
unbound variable `qof-session-new'

This is the same error that I have encountered in my own Guile script.
But...I also see this line
at the end of the test log.

PASS test-create-account (exit status: 0)

So the unit test cannot find 'qof-session-new' and yet the unit test
framework thinks its
passing. I wanted to let someone know that GNUCash has unit tests
(perhaps only for guile)
that are returning false positives. That's bug one.  Would you like me
to file a bug for this?

It turns out that GnuCash is not properly exposing the Guile bindings.
I consider this
a "bug", but others may disagree.  GnuCash seems to work pretty well
without them.  For my
purposes, though, I know where they are defined, why they aren't
exposed, and how to expose them.
If someone wants a patch for that, I may be able to provide it.

In the meantime, the heads up here is that there are some testing
returning false positives.

Let me know if you want any more information.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile gnucash modules documentation

[John Ralls]

> On Nov 6, 2016, at 12:25 AM, Sébastien de Menten <sdemen...@gmail.com> wrote:
> 
> Cross posting to gnucash-devel as probably more a dev question.
> Essentially: is there any way to get some documentation (even just the list
> of modules with symbols exported) on the guile gnucash bindings ?

For the bindings you can use the C documentation, just change the underscores 
(_) into hyphens (-). The only listing of what's exported is in the swig 
interface files, e.g. src/engine/engine.i. That covers about a third of the 
Scheme functionality, the rest being functions written in Scheme. AFAIK there 
is no documentation of that beyond the comments in the source files and of 
course the code itself.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Fwd: Guile gnucash modules documentation

[Sébastien de Menten]

Cross posting to gnucash-devel as probably more a dev question.
Essentially: is there any way to get some documentation (even just the list
of modules with symbols exported) on the guile gnucash bindings ?

Sébastien
-- Forwarded message --
From: "Sébastien de Menten" <sdemen...@gmail.com>
Date: Nov 2, 2016 02:00
Subject: Guile gnucash modules documentation
To: <gnucash-u...@gnucash.org>
Cc:

Is there a place where we can find documentation on the functions available
> from guile to write report ?
> Diving back in scheme bring good memories but these are not sufficient to
> understand how to use guile with gnucash.
> For instance, how can I get back just the current session ?
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Problems with make check and guile, apparently

[Colin Law]

I am having getting make check to pass for reasons unknown to me.  In
src/engine/test/test-suite.log I see


   GnuCash 2.6.12: src/engine/test/test-suite.log


# TOTAL: 27
# PASS:  24
# SKIP:  0
# XFAIL: 0
# FAIL:  3
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test-test-extras
==

;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling 
/home/colinl/apps/gnucash_git/src/engine/test/./test-test-extras.scm
;;; WARNING: compilation of
/home/colinl/apps/gnucash_git/src/engine/test/./test-test-extras.scm
failed:
;;; ERROR: no code for module (gnucash engine test test-extras)
Backtrace:
In ice-9/boot-9.scm:
 157: 17 [catch #t # ...]
In unknown file:
   ?: 16 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 15 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 14 [eval # #]
In ice-9/boot-9.scm:
2401: 13 [save-module-excursion #]
4052: 12 [#]
1724: 11 [%start-stack load-stack ...]
1729: 10 [#]
In unknown file:
   ?: 9 [primitive-load
"/home/colinl/apps/gnucash_git/src/engine/test/./test-test-extras.scm"]
In ice-9/eval.scm:
 505: 8 [# (use-modules #)]
In ice-9/psyntax.scm:
1106: 7 [expand-top-sequence ((use-modules (gnucash engine test ...))) () ...]
 989: 6 [scan ((use-modules (gnucash engine test ...))) () ...]
 279: 5 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...]
In ice-9/boot-9.scm:
3597: 4 [process-use-modules (((gnucash engine test test-extras)))]
 702: 3 [map # ((#))]
3598: 2 [# (#)]
2867: 1 [resolve-interface (gnucash engine test ...) #:select ...]
In unknown file:
   ?: 0 [scm-error misc-error #f ...]

ERROR: In procedure scm-error:
ERROR: no code for module (gnucash engine test test-extras)
FAIL test-test-extras (exit status: 1)

Followed by several other similar reports.  Having searched the list I
found suggestions to delete ~/.cache/guile/ccache but that did not
help, in fact I tried deleting ~/.cache/guile but again I still get
the error.  A few days ago make check was ok but I don't know what I
may have done to mess it up.  The only file modified (from the maint
branch) is gnc-backend-dbi.c which does not appear to be related to
the problem.

This is running on Ubuntu 16.04.

Any help will be much appreciated.

Colin
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile

[Geert Janssens]

On Monday 09 November 2015 15:57:09 John Ralls wrote:
> > On Nov 9, 2015, at 3:35 PM, Pjotr Prins <pjotr2...@thebird.nl>
> > wrote:
> > 
> > Dear John,
> > 
> > We have a devroom at FOSDEM this year (one of the most important
> > FOSS conferences).
> > 
> > Do you know anyone who could do a talk on one of your Guile projects
> > by submitting one paragraph description to
> > https://penta.fosdem.org/submission/FOSDEM16/?
> > 
> > It would be great if you could make it. I have been using GNUCash
> > for years.
> Pjotr,
> 
> I don’t plan to attend FOSDEM, but we have some developers who live
> reasonably close and might be able to give a presentation. I’ve
> copied our developer list on this reply, so if any of them are
> interested and can make time they can respond to you directly.
> 
> Regards,
> John Ralls
> 
Hi,

I normally attend FOSDEM whenever I can (which has been almost every 
year for quite some time now).

I plan to go this year as well, though there are a few external factors 
that may block me last minute. I'll only now right before the weekend.

I'll not be able to do a presentation at FOSDEM, that I'm sure about.

Regards,

Geert

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile

[John Ralls]

> On Nov 9, 2015, at 3:35 PM, Pjotr Prins <pjotr2...@thebird.nl> wrote:
> 
> Dear John,
> 
> We have a devroom at FOSDEM this year (one of the most important FOSS 
> conferences).
> 
> Do you know anyone who could do a talk on one of your Guile projects by
> submitting one paragraph description to
> https://penta.fosdem.org/submission/FOSDEM16/?
> 
> It would be great if you could make it. I have been using GNUCash for years.

Pjotr,

I don’t plan to attend FOSDEM, but we have some developers who live reasonably 
close and might be able to give a presentation. I’ve copied our developer list 
on this reply, so if any of them are interested and can make time they can 
respond to you directly.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash maint: Cutecash: Switch from guile to xml to manage our iso-currencies source file

[Geert Janssens]

Thanks Christian !

I meant to look into this, but my cmake experience is close to zero.

Glad you picked it up.

Regards,

Geert

On Wednesday 22 April 2015 16:40:17 Christian Stimming wrote:
 Updatedvia  https://github.com/Gnucash/gnucash/commit/e9b6ee74
 (commit) from  https://github.com/Gnucash/gnucash/commit/274113b3
 (commit)
 
 
 
 commit e9b6ee74ad4d1461777e8671d5c61161db907ad3
 Author: Christian Stimming christ...@cstimming.de
 Date:   Wed Apr 22 22:33:58 2015 +0200
 
 Cutecash: Switch from guile to xml to manage our iso-currencies
 source file
 
 Copies 87520cdde4b into the cmake build system.
 
 
 
 Summary of changes:
  CMakeLists.txt| 5 +
  src/engine/CMakeLists.txt | 4 ++--
  2 files changed, 7 insertions(+), 2 deletions(-)
 
 ___
 gnucash-patches mailing list
 gnucash-patc...@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-patches

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Guile path for scm files

[David Christopher]

I have edited my .profile file by adding this line to the very end.

PATH=$PATH:$HOME/Documents

Now with that in there I can in terminal type echo $PATH and get this
return:

david@david-Aspire-XC-605G ~ $ echo $PATH
/home/david/Documents:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/david/Documents

Supposedly when I chmod to make the hello.scm practice file executable and
run from the terminal command line I should see the Hello World.  As
opposed to on the command line typing guile hello.world.

When I type hello.scm in terminal command line, I get the following error.

---
david@david-Aspire-XC-605G ~ $ hello.scm
;;; Stat of /home/david/?s failed:
;;; ERROR: In procedure stat: No such file or directory:
/home/david/\u2013s
Backtrace:
In ice-9/boot-9.scm:
 157: 8 [catch #t #catch-closure 1f48400 ...]
In unknown file:
   ?: 7 [apply-smob/1 #catch-closure 1f48400]
In ice-9/boot-9.scm:
  63: 6 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 5 [eval # #]
In ice-9/boot-9.scm:
2320: 4 [save-module-excursion #procedure 1f7ad00 at
ice-9/boot-9.scm:3961:3 ()]
3968: 3 [#procedure 1f7ad00 at ice-9/boot-9.scm:3961:3 ()]
1645: 2 [%start-stack load-stack ...]
1650: 1 [#procedure 1f780f0 ()]
In unknown file:
   ?: 0 [primitive-load /home/david/\u2013s]

ERROR: In procedure primitive-load:
ERROR: In procedure open-file: No such file or directory:
/home/david/\u2013s
---
Now without that line in .profile, I get file not found

A friend told me I get te \u0213s from having a bad character in the
.profile file in that added line.  Well, I have typed it in by hand several
times, copied an untouched .profile from my back up into the thing and
still get the error.  Also tried creating the .bashrc and the
.pamenvironment file and I get the same error with those two files.

Anyone know why I get this No such file or directory: /home/david/\u2013s
  ??
 It should say /home/david/Documents

I studied the Guile Reference Manual about %load and setting environmental
variables.

In guile load does not look in the path, it seems to only look in current
directory for the file to load.  I did copy and paste the hello.scm in the
2.0 directory where the Manual says scm files should be.  Then I entered
(load-from-path hello.scm) and that works fine.

Thanks for any help and especially looking a a newbee proplem.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile path for scm files

[John Ralls]

 On Mar 15, 2015, at 4:46 AM, David Christopher chrst...@gmail.com wrote:
 
 I have edited my .profile file by adding this line to the very end.
 
 PATH=$PATH:$HOME/Documents
 
 Now with that in there I can in terminal type echo $PATH and get this
 return:
 
 david@david-Aspire-XC-605G ~ $ echo $PATH
 /home/david/Documents:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/david/Documents
 
 Supposedly when I chmod to make the hello.scm practice file executable and
 run from the terminal command line I should see the Hello World.  As
 opposed to on the command line typing guile hello.world.
 
 When I type hello.scm in terminal command line, I get the following error.
 
 ---
 david@david-Aspire-XC-605G ~ $ hello.scm
 ;;; Stat of /home/david/?s failed:
 ;;; ERROR: In procedure stat: No such file or directory:
 /home/david/\u2013s
 Backtrace:
 In ice-9/boot-9.scm:
 157: 8 [catch #t #catch-closure 1f48400 ...]
 In unknown file:
   ?: 7 [apply-smob/1 #catch-closure 1f48400]
 In ice-9/boot-9.scm:
  63: 6 [call-with-prompt prompt0 ...]
 In ice-9/eval.scm:
 432: 5 [eval # #]
 In ice-9/boot-9.scm:
 2320: 4 [save-module-excursion #procedure 1f7ad00 at
 ice-9/boot-9.scm:3961:3 ()]
 3968: 3 [#procedure 1f7ad00 at ice-9/boot-9.scm:3961:3 ()]
 1645: 2 [%start-stack load-stack ...]
 1650: 1 [#procedure 1f780f0 ()]
 In unknown file:
   ?: 0 [primitive-load /home/david/\u2013s]
 
 ERROR: In procedure primitive-load:
 ERROR: In procedure open-file: No such file or directory:
 /home/david/\u2013s
 ---
 Now without that line in .profile, I get file not found
 
 A friend told me I get te \u0213s from having a bad character in the
 .profile file in that added line.  Well, I have typed it in by hand several
 times, copied an untouched .profile from my back up into the thing and
 still get the error.  Also tried creating the .bashrc and the
 .pamenvironment file and I get the same error with those two files.
 
 Anyone know why I get this No such file or directory: /home/david/\u2013s
   ??
 It should say /home/david/Documents
 
 I studied the Guile Reference Manual about %load and setting environmental
 variables.
 
 In guile load does not look in the path, it seems to only look in current
 directory for the file to load.  I did copy and paste the hello.scm in the
 2.0 directory where the Manual says scm files should be.  Then I entered
 (load-from-path hello.scm) and that works fine.
 
 Thanks for any help and especially looking a a newbee proplem.

David,

Might I suggest that our developer list is not the appropriate place to teach 
you how to use Linux nor to program in Scheme? This list is not for newbies, 
sorry.

As I told you before, the PATH environment variable is used by the shell to 
find executable files. It is the matter of having the hello.world file 
executable and beginning with #!/usr/bin/guile that allows you to type its name 
directly from the command line; including your Documents directory in $PATH 
just saves you from having to type out the path. Try that instead:
  Documents/hello.world
and see if you get the same error.

Don't reply here, nor to me personally. Find resources appropriate to what you 
need to learn. An adult-education class on Linux and/or beginning programming 
would be an excellent option.

Regards,
John Ralls




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Geert Janssens]

On Thursday 16 January 2014 14:26:41 Geert Janssens wrote:
 Gary,
 
 While looking at your changes I noticed you changed two lines in
 the vbs script.
 
 One is that you added my repository/branch in a comment.
 That's ok and makes it easier for others to start.
 
 The second is to install msys-patch. Is there a reason you do this
 in the vbs script and not in install-impl.sh ?
 
 Geert
 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Gary,

A late update on this.

I have tried to apply your patches to my branch. The first two were already 
integrated. Of the 
other 5 only two could be applied cleanly. I have added one more manually, but 
two are 
currently not applied.

I have just rebased my branch from the most recent trunk. Can you pull my 
branch (with git pull 
--rebase) and check which parts are missing and recreate patches for these 
items ?

Thanks,

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Geert Janssens]

On Friday 17 January 2014 07:30:00 John Ralls wrote:
  
  OK Geert,
  I think I have what you want at
  http://www.greenwheel.com/publicFiles/rebase-patches.zip Let me
  know if this works for you.
  Not being a git expert, it's possible I've not quite done the right
  thing, but I think this should be OK.
 As another option, perhaps the most git-ish (sorry) of all, would be
 for Gary to get a (free) Github account, fork Geert's repo, make his
 branch, push that back to *his* repo, and then from Github send Geert
 a pull request.
 
 I know I've argued against allowing this in the past, but I'm coming
 around to the idea that we need to make it easier for folks to offer
 patches.
 

Heh, I didn't want to propose this exactly because of your opposition in the 
past. But I have 
been thinking of leveraging github's pull requests as well.

I see for example that swig is using this approach rather succesfully. I can 
imagine that a 
project the size of a linux kernel needs some stricter rules to keep organized. 
But GnuCash is 
pretty small in comparison. Reminds me we still have to discuss our future 
branching strategy, 
but that's for another thread.

Back to the patches at hand:
Gary, I tried to download the zip file you made available, but I get a 
permission error on that 
website. Can you check that ?

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Gary Bilkus]

On 18/01/2014 09:53, Geert Janssens wrote:


On Friday 17 January 2014 07:30:00 John Ralls wrote:

 

  OK Geert,

  I think I have what you want at

  http://www.greenwheel.com/publicFiles/rebase-patches.zip Let me

  know if this works for you.

  Not being a git expert, it's possible I've not quite done the right

  thing, but I think this should be OK.

 As another option, perhaps the most git-ish (sorry) of all, would be

 for Gary to get a (free) Github account, fork Geert's repo, make his

 branch, push that back to *his* repo, and then from Github send Geert

 a pull request.



 I know I've argued against allowing this in the past, but I'm coming

 around to the idea that we need to make it easier for folks to offer

 patches.



Heh, I didn't want to propose this exactly because of your opposition 
in the past. But I have been thinking of leveraging github's pull 
requests as well.


I see for example that swig is using this approach rather succesfully. 
I can imagine that a project the size of a linux kernel needs some 
stricter rules to keep organized. But GnuCash is pretty small in 
comparison. Reminds me we still have to discuss our future branching 
strategy, but that's for another thread.


Back to the patches at hand:

Gary, I tried to download the zip file you made available, but I get a 
permission error on that website. Can you check that ?


Geert


Sorry Geert, forgot to add read perms to the file. Should be OK now.
Gary
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Gary Bilkus]

On 16/01/2014 15:38, Geert Janssens wrote:


On Thursday 16 January 2014 15:06:55 Gary Bilkus wrote:

 On 16/01/2014 13:26, Geert Janssens wrote:

  Gary,

 

  While looking at your changes I noticed you changed two lines in the

  vbs script.

 

  One is that you added my repository/branch in a comment. That's ok

  and makes it easier for others to start.

 

  The second is to install msys-patch. Is there a reason you do this

  in

  the vbs script and not in install-impl.sh ?

 

  Geert



 Hi Geert.

 The reason I added in msys-patch to my version of your script is so

 that the instructions I posted on the wiki would work, since they

 tell you to run your vbs script and then run patch against the 2.6

 repo with my patchfile, and that doesn't work if you don't yet have

 patch installed.



 Of course, as and when there's a git repo with the patches already

 incorporated, that step is no longer needed and nor is patch. But it

 doesn't do much harm to leave it around, and would make it easier for

 people who have to play catch-up the next time a downstream dependency

 gets broken.

 Gary

Hi Gary,

That makes sense.

The reason I'm very cautious about adding stuff in the bootstrap 
script is that mingw-get is fairly fragile. The bootstrap script 
unconditionally installs the most recent version of the various 
packages, but in the install.sh script we force specific versions. If 
at some point the most recent version is more recent than what we 
explicitly set this will probably cause mingw-get to error out. That 
may or may not be bad but at least pretty confusing to new users.


We may fix this by installing very specific versions in the bootstrap 
script already instead of the latest available. Although that approach 
risks that these versions will at some point get out of sync with the 
versions defined in defaults.sh. But IMO that is less of an issue. If 
this happens the installation script will update the packages to the 
proper versions without errors the first time it runs.


I'll admit this is close to nitpicking. There are bigger issues to 
solve right now, but I mention it because now I noticed it. I will 
probably forget later on.


Geert

I completely understand the thinking. That said, I think patch is 
probably a pretty safe program to just download, given its longevity and 
stability at this point, compared to things like say the c compiler!


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Gary Bilkus]

On 16/01/2014 13:23, Geert Janssens wrote:


On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote:



 So just to make sure I understand exactly what you need.



 1. I should get the gnucash.git repository from

 git://github.com:gjanssens/gnucash.git

 2. I should git branch -t mingw origin/mingw-rebasing and check out

 that branch

 3. I should appy my patches to that branch - ignoring any which are

 already there

 4. I should run git diff to get a series of patches against the branch

 in the repository

 5. I should split the resulting diff into different files relating to

 the different fixes

 6. I should post the result somewhere and tell you where it is



 Gary

Gary,

That's close. But git's workflow is slightly different:

1 and 2 are correct

3. Apply your patches and ignore those that are already there is also 
correct. Then before committing anything it's worth considering which 
changes logically belong together and check these changes in in 
separate commits. 'git add -i' will be tremendously helpful for this 
part (adding changes into the index interactively).


4. Each time you have added a coherent set of changes to the index 
file, you can create a (local) commit using 'git commit'. You may want 
to use clear commit messages in this step as they will eventually end 
up in the master repository. You can look at my commits for examples 
but they're only that not hard rules. I suggest though that you 
explicitly add an author line in your commit message. Since we're 
still linked to the svn repo, git's author information gets lost for 
non-committers when we commit to the master repository. This line is 
in the form:


Author: name email

5. When there are no more changes to commit, you can run 'git 
format-patch' to generate a series of patch files like so:


git format-patch origin/mingw-rebasing

That should generate the patch files in the current working directory.

6. The normal way to make these patches available to me is to create 
an enhancement request in bugzilla and attach the patches there. But 
in this case I'm equally fine if you post them to the list or tell me 
where you stored them on your own server or whatever.


Geert


OK Geert,
I think I have what you want at 
http://www.greenwheel.com/publicFiles/rebase-patches.zip

Let me know if this works for you.
Not being a git expert, it's possible I've not quite done the right 
thing, but I think this should be OK.

Gary
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[John Ralls]

On Jan 17, 2014, at 5:57 AM, Gary Bilkus m...@gary.bilkus.com wrote:

 On 16/01/2014 13:23, Geert Janssens wrote:
 
 On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote:
 
 
 
  So just to make sure I understand exactly what you need.
 
 
 
  1. I should get the gnucash.git repository from
 
  git://github.com:gjanssens/gnucash.git
 
  2. I should git branch -t mingw origin/mingw-rebasing and check out
 
  that branch
 
  3. I should appy my patches to that branch - ignoring any which are
 
  already there
 
  4. I should run git diff to get a series of patches against the branch
 
  in the repository
 
  5. I should split the resulting diff into different files relating to
 
  the different fixes
 
  6. I should post the result somewhere and tell you where it is
 
 
 
  Gary
 
 Gary,
 
 That's close. But git's workflow is slightly different:
 
 1 and 2 are correct
 
 3. Apply your patches and ignore those that are already there is also 
 correct. Then before committing anything it's worth considering which 
 changes logically belong together and check these changes in in separate 
 commits. 'git add -i' will be tremendously helpful for this part (adding 
 changes into the index interactively).
 
 4. Each time you have added a coherent set of changes to the index file, you 
 can create a (local) commit using 'git commit'. You may want to use clear 
 commit messages in this step as they will eventually end up in the master 
 repository. You can look at my commits for examples but they're only that 
 not hard rules. I suggest though that you explicitly add an author line in 
 your commit message. Since we're still linked to the svn repo, git's author 
 information gets lost for non-committers when we commit to the master 
 repository. This line is in the form:
 
 Author: name email
 
 5. When there are no more changes to commit, you can run 'git format-patch' 
 to generate a series of patch files like so:
 
 git format-patch origin/mingw-rebasing
 
 That should generate the patch files in the current working directory.
 
 6. The normal way to make these patches available to me is to create an 
 enhancement request in bugzilla and attach the patches there. But in this 
 case I'm equally fine if you post them to the list or tell me where you 
 stored them on your own server or whatever.
 
 Geert
 
 OK Geert,
 I think I have what you want at 
 http://www.greenwheel.com/publicFiles/rebase-patches.zip
 Let me know if this works for you.
 Not being a git expert, it's possible I've not quite done the right thing, 
 but I think this should be OK.

As another option, perhaps the most git-ish (sorry) of all, would be for Gary 
to get a (free) Github account, fork Geert's repo, make his branch, push that 
back to *his* repo, and then from Github send Geert a pull request.

I know I've argued against allowing this in the past, but I'm coming around to 
the idea that we need to make it easier for folks to offer patches.

Regards,
John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[John Ralls]

On Jan 17, 2014, at 7:30 AM, John Ralls jra...@ceridwen.us wrote:

 
 On Jan 17, 2014, at 5:57 AM, Gary Bilkus m...@gary.bilkus.com wrote:
 
 On 16/01/2014 13:23, Geert Janssens wrote:
 
 On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote:
 
 
 
 So just to make sure I understand exactly what you need.
 
 
 
 1. I should get the gnucash.git repository from
 
 git://github.com:gjanssens/gnucash.git
 
 2. I should git branch -t mingw origin/mingw-rebasing and check out
 
 that branch
 
 3. I should appy my patches to that branch - ignoring any which are
 
 already there
 
 4. I should run git diff to get a series of patches against the branch
 
 in the repository
 
 5. I should split the resulting diff into different files relating to
 
 the different fixes
 
 6. I should post the result somewhere and tell you where it is
 
 
 
 Gary
 
 Gary,
 
 That's close. But git's workflow is slightly different:
 
 1 and 2 are correct
 
 3. Apply your patches and ignore those that are already there is also 
 correct. Then before committing anything it's worth considering which 
 changes logically belong together and check these changes in in separate 
 commits. 'git add -i' will be tremendously helpful for this part (adding 
 changes into the index interactively).
 
 4. Each time you have added a coherent set of changes to the index file, 
 you can create a (local) commit using 'git commit'. You may want to use 
 clear commit messages in this step as they will eventually end up in the 
 master repository. You can look at my commits for examples but they're only 
 that not hard rules. I suggest though that you explicitly add an author 
 line in your commit message. Since we're still linked to the svn repo, 
 git's author information gets lost for non-committers when we commit to the 
 master repository. This line is in the form:
 
 Author: name email
 
 5. When there are no more changes to commit, you can run 'git format-patch' 
 to generate a series of patch files like so:
 
 git format-patch origin/mingw-rebasing
 
 That should generate the patch files in the current working directory.
 
 6. The normal way to make these patches available to me is to create an 
 enhancement request in bugzilla and attach the patches there. But in this 
 case I'm equally fine if you post them to the list or tell me where you 
 stored them on your own server or whatever.
 
 Geert
 
 OK Geert,
 I think I have what you want at 
 http://www.greenwheel.com/publicFiles/rebase-patches.zip
 Let me know if this works for you.
 Not being a git expert, it's possible I've not quite done the right thing, 
 but I think this should be OK.
 
 As another option, perhaps the most git-ish (sorry) of all, would be for 
 Gary to get a (free) Github account, fork Geert's repo, make his branch, push 
 that back to *his* repo, and then from Github send Geert a pull request.
 
 I know I've argued against allowing this in the past, but I'm coming around 
 to the idea that we need to make it easier for folks to offer patches.

I'll add that this finesses
 The reason I added in msys-patch to my version of your script is so that the 
 instructions I posted on the wiki would work, since they tell you to run your 
 vbs script and then run patch against the 2.6 repo with my patchfile, and 
 that doesn't work if you don't yet have patch installed.
 
 Of course, as and when there's a git repo with the patches already 
 incorporated, that step is no longer needed and nor is patch. But it doesn't 
 do much harm to leave it around, and would make it easier for people who have 
 to play catch-up the next time a downstream dependency gets broken.

because there's instantly a published git repository with the patches 
incorporated!

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[John Ralls]

On Jan 16, 2014, at 7:53 AM, Geert Janssens janssens-ge...@telenet.be wrote:

 On Thursday 16 January 2014 07:49:53 John Ralls wrote:
  On Jan 16, 2014, at 5:23 AM, Geert Janssens janssens-ge...@telenet.be 
  wrote:
   3. Apply your patches and ignore those that are already there is
   also correct. Then before committing anything it's worth
   considering which changes logically belong together and check these
   changes in in separate commits. 'git add -i' will be tremendously
   helpful for this part (adding changes into the index
   interactively).
  
  Pardon me for barging in. I just want to add that a git GUI makes it
  much less painful to pull diffs apart into commits compared to `git
  add -i`. TortoiseGit (http://code.google.com/p/tortoisegit/) works
  well on M$Windows.
  
  Regards,
  John Ralls
  
 Interesting. I never used a gui for this yet. Which one do you use on your 
 mac ?

I'd been using GitX [1], but it's pretty buggy and crash-prone, so I've lately 
switched to Atlassian Stash [2], which is free as in beer instead Free, but it 
hasn't yet crashed on me.
On Linux I use gitx and giggle, both of which are in all of the package 
managers.

Regards,
John Ralls


[1] http://gitx.org/
[2] https://www.atlassian.com/software/stash/overview

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[John Ralls]

On Jan 17, 2014, at 7:39 AM, John Ralls jra...@ceridwen.us wrote:

 
 On Jan 16, 2014, at 7:53 AM, Geert Janssens janssens-ge...@telenet.be wrote:
 
 On Thursday 16 January 2014 07:49:53 John Ralls wrote:
 On Jan 16, 2014, at 5:23 AM, Geert Janssens janssens-ge...@telenet.be 
 wrote:
 3. Apply your patches and ignore those that are already there is
 also correct. Then before committing anything it's worth
 considering which changes logically belong together and check these
 changes in in separate commits. 'git add -i' will be tremendously
 helpful for this part (adding changes into the index
 interactively).
 
 Pardon me for barging in. I just want to add that a git GUI makes it
 much less painful to pull diffs apart into commits compared to `git
 add -i`. TortoiseGit (http://code.google.com/p/tortoisegit/) works
 well on M$Windows.
 
 Regards,
 John Ralls
 
 Interesting. I never used a gui for this yet. Which one do you use on your 
 mac ?
 
 I'd been using GitX [1], but it's pretty buggy and crash-prone, so I've 
 lately switched to Atlassian Stash [2], which is free as in beer instead 
 Free, but it hasn't yet crashed on me.

Oops, that’s wrong. It’s Atlassian SourceTree: http://www.sourcetreeapp.com/

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Geert Janssens]

On Friday 10 January 2014 17:41:15 Gary Bilkus wrote:
 On 10/01/2014 15:03, John Ralls wrote:
  On Jan 9, 2014, at 11:13 PM, Gary Bilkus m...@gary.bilkus.com wrote:
  Well, interestingly enough, the problem is not directly with the
  compiler optimizer. It's with the configure test for strncasecmp.
  This test fails on mingw in its current incarnation because guile
  uses a standard test for the function, but on mingw strncasecmp is
  actually a cpp definition. As a result, guile is compiled with
  #HAVE_STRNCASECMP unset, and so guile tries to create its own
  version in read.c Now if you compile with no optimization, the
  compiler notices that read.c is attempting to create this with a
  different signature and bombs out. However, with optimisation on,
  the code compiles for some reason, and then fails to run properly.
  
  So there seem to be two problems: one in configure for guile and/or
  the standard configure macros on mingw, the other in the compiler.
  Fortunately, there's a very easy although ugly workaround, which
  is to add an echo #define HAVE_STRNCASECMP config.h
  
  Would adding -DHAVE_STRNCASECMP to $CFLAGS work? It's a bit cleaner
  than echoing a #define into the config header. Better yet,
  sometimes there's a variable that can be defined on the configure
  command line -- perhaps $ac_have_strncasecmp -- to force configure
  to do the right thing. 
  in install-impl.sh
  just after the guile configure and before the make
  
  I've incorporated this fix into my downloadable file of fixes as
  referred to on the wiki page I updated. More as and when I find
  any further issues. As always, feedback or other experiences
  welcome. 
  Regards,
  John Ralls
 
 I agree that the configure commandline change would be cleaner, and if
 I can find out what to do I'll change my fix.
 
 I disagree that a CFLAGS define is cleaner. With my solution the
 define is in the right file, even if it gets there for the wrong
 reason. That way, it guarantees not to affect any compilation which
 doesn't involve including config.h, which saves having to check for
 any unexpected consequenses elsewhere.
 Gary
 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Gary,

Thanks for all your updates. Today I found some time to check which of your 
fixes I should still 
add to my windows branch, but got lost in your patch. It looks like you are 
generating a patch 
to be applied to the current trunk branch, including all the separate commits 
from my branch. 
Unfortunately that makes it hard if not impossible to see only the changes 
needed on my 
branch.

It's not the intention to apply such a large patch one day to current trunk. 
Instead my branch 
will be merged in eventually (likely after the 2.6 branch is generated and 
certainly not before 
the dist part and build server scripts are also fixed).

So can you extract only the changes that still need to be applied to my branch 
please ? Ideally 
split up in small patches per topic (fix -no-undefined, fix guile's 
str_ncase_comp, ...). That way 
we generate clean and readable history in the repository.
You may want to set up your own clone of the git repository [1] as git can be 
very helpful in 
generating such patches.

Thanks,

Geert

[1] http://wiki.gnucash.org/wiki/Git#Non-Committers
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Geert Janssens]

On Thursday 16 January 2014 11:10:30 Geert Janssens wrote:
 
 Gary,
 
 Thanks for all your updates. Today I found some time to check which of
 your fixes I should still add to my windows branch, but got lost in
 your patch. It looks like you are generating a patch to be applied to
 the current trunk branch, including all the separate commits from my
 branch. Unfortunately that makes it hard if not impossible to see
 only the changes needed on my branch.
 
 It's not the intention to apply such a large patch one day to current
 trunk. Instead my branch will be merged in eventually (likely after
 the 2.6 branch is generated and certainly not before the dist part
 and build server scripts are also fixed).
 
 So can you extract only the changes that still need to be applied to
 my branch please ? Ideally split up in small patches per topic (fix
 -no-undefined, fix guile's str_ncase_comp, ...). That way we generate
 clean and readable history in the repository.
 You may want to set up your own clone of the git repository [1] as git
 can be very helpful in generating such patches.
 
 Thanks,
 
 Geert
 
 [1] http://wiki.gnucash.org/wiki/Git#Non-Committers

Also note that I have rebased the mingw-rebasing branch again in my repository 
to pick up 
the most recent version of aqbanking and gwenview. I haven't had the 
opportunity yet to 
check if these versions build in the new mingw environment.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Gary Bilkus]

On 16/01/2014 11:43, Geert Janssens wrote:

On Thursday 16 January 2014 11:10:30 Geert Janssens wrote:

Gary,

Thanks for all your updates. Today I found some time to check which of
your fixes I should still add to my windows branch, but got lost in
your patch. It looks like you are generating a patch to be applied to
the current trunk branch, including all the separate commits from my
branch. Unfortunately that makes it hard if not impossible to see
only the changes needed on my branch.

It's not the intention to apply such a large patch one day to current
trunk. Instead my branch will be merged in eventually (likely after
the 2.6 branch is generated and certainly not before the dist part
and build server scripts are also fixed).

So can you extract only the changes that still need to be applied to
my branch please ? Ideally split up in small patches per topic (fix
-no-undefined, fix guile's str_ncase_comp, ...). That way we generate
clean and readable history in the repository.
You may want to set up your own clone of the git repository [1] as git
can be very helpful in generating such patches.

Thanks,

Geert

[1] http://wiki.gnucash.org/wiki/Git#Non-Committers

Also note that I have rebased the mingw-rebasing branch again in my repository 
to pick up
the most recent version of aqbanking and gwenview. I haven't had the 
opportunity yet to
check if these versions build in the new mingw environment.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

So just to make sure I understand exactly what you need.

1. I should get the gnucash.git repository from 
git://github.com:gjanssens/gnucash.git
2. I should git branch -t mingw origin/mingw-rebasing and check out that 
branch
3. I should appy my patches to that branch - ignoring any which are 
already there
4. I should run git diff to get a series of patches against the branch 
in the repository
5. I should split the resulting diff into different files relating to 
the different fixes

6. I should post the result somewhere and tell you where it is

Gary


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Geert Janssens]

On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote:
 
 So just to make sure I understand exactly what you need.
 
 1. I should get the gnucash.git repository from
 git://github.com:gjanssens/gnucash.git
 2. I should git branch -t mingw origin/mingw-rebasing and check out
 that branch
 3. I should appy my patches to that branch - ignoring any which are
 already there
 4. I should run git diff to get a series of patches against the branch
 in the repository
 5. I should split the resulting diff into different files relating to
 the different fixes
 6. I should post the result somewhere and tell you where it is
 
 Gary

Gary,

That's close. But git's workflow is slightly different:

1 and 2 are correct

3. Apply your patches and ignore those that are already there is also correct. 
Then before 
committing anything it's worth considering which changes logically belong 
together and check 
these changes in in separate commits. 'git add -i' will be tremendously helpful 
for this part 
(adding changes into the index interactively).

4. Each time you have added a coherent set of changes to the index file, you 
can create a (local) 
commit using 'git commit'. You may want to use clear commit messages in this 
step as they will 
eventually end up in the master repository. You can look at my commits for 
examples but 
they're only that not hard rules. I suggest though that you explicitly add an 
author line in your 
commit message. Since we're still linked to the svn repo, git's author 
information gets lost for 
non-committers when we commit to the master repository. This line is in the 
form:
Author: name email

5. When there are no more changes to commit, you can run 'git format-patch' to 
generate a 
series of patch files like so:
git format-patch origin/mingw-rebasing
That should generate the patch files in the current working directory.

6. The normal way to make these patches available to me is to create an 
enhancement request 
in bugzilla and attach the patches there. But in this case I'm equally fine if 
you post them to the 
list or tell me where you stored them on your own server or whatever.


Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Geert Janssens]

Gary,

While looking at your changes I noticed you changed two lines in 
the vbs script.

One is that you added my repository/branch in a comment. 
That's ok and makes it easier for others to start.

The second is to install msys-patch. Is there a reason you do this 
in the vbs script and not in install-impl.sh ?

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Gary Bilkus]

On 16/01/2014 13:26, Geert Janssens wrote:


Gary,

While looking at your changes I noticed you changed two lines in the 
vbs script.


One is that you added my repository/branch in a comment. That's ok and 
makes it easier for others to start.


The second is to install msys-patch. Is there a reason you do this in 
the vbs script and not in install-impl.sh ?


Geert


Hi Geert.
The reason I added in msys-patch to my version of your script is so that 
the instructions I posted on the wiki would work, since they tell you to 
run your vbs script and then run patch against the 2.6 repo with my 
patchfile, and that doesn't work if you don't yet have patch installed.


Of course, as and when there's a git repo with the patches already 
incorporated, that step is no longer needed and nor is patch. But it 
doesn't do much harm to leave it around, and would make it easier for 
people who have to play catch-up the next time a downstream dependency 
gets broken.

Gary
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Geert Janssens]

On Thursday 16 January 2014 15:06:55 Gary Bilkus wrote:
 On 16/01/2014 13:26, Geert Janssens wrote:
  Gary,
  
  While looking at your changes I noticed you changed two lines in the
  vbs script.
  
  One is that you added my repository/branch in a comment. That's ok
  and makes it easier for others to start.
  
  The second is to install msys-patch. Is there a reason you do this
  in
  the vbs script and not in install-impl.sh ?
  
  Geert
 
 Hi Geert.
 The reason I added in msys-patch to my version of your script is so
 that the instructions I posted on the wiki would work, since they
 tell you to run your vbs script and then run patch against the 2.6
 repo with my patchfile, and that doesn't work if you don't yet have
 patch installed.
 
 Of course, as and when there's a git repo with the patches already
 incorporated, that step is no longer needed and nor is patch. But it
 doesn't do much harm to leave it around, and would make it easier for
 people who have to play catch-up the next time a downstream dependency
 gets broken.
 Gary

Hi Gary,

That makes sense.

The reason I'm very cautious about adding stuff in the bootstrap script is that 
mingw-get is 
fairly fragile. The bootstrap script unconditionally installs the most recent 
version of the various 
packages, but in the install.sh script we force specific versions. If at some 
point the most recent 
version is more recent than what we explicitly set this will probably cause 
mingw-get to error 
out. That may or may not be bad but at least pretty confusing to new users.

We may fix this by installing very specific versions in the bootstrap script 
already instead of the 
latest available. Although that approach risks that these versions will at some 
point get out of 
sync with the versions defined in defaults.sh. But IMO that is less of an 
issue. If this happens the 
installation script will update the packages to the proper versions without 
errors the first time it 
runs.

I'll admit this is close to nitpicking. There are bigger issues to solve right 
now, but I mention it 
because now I noticed it. I will probably forget later on.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[John Ralls]

On Jan 16, 2014, at 5:23 AM, Geert Janssens janssens-ge...@telenet.be wrote:
 3. Apply your patches and ignore those that are already there is also 
 correct. Then before 
 committing anything it's worth considering which changes logically belong 
 together and check 
 these changes in in separate commits. 'git add -i' will be tremendously 
 helpful for this part 
 (adding changes into the index interactively).

Pardon me for barging in. I just want to add that a git GUI makes it much less 
painful to pull diffs apart into commits compared to `git add -i`. TortoiseGit 
(http://code.google.com/p/tortoisegit/) works well on M$Windows.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Geert Janssens]

On Thursday 16 January 2014 07:49:53 John Ralls wrote:
 On Jan 16, 2014, at 5:23 AM, Geert Janssens janssens-ge...@telenet.be wrote:
  3. Apply your patches and ignore those that are already there is
  also correct. Then before committing anything it's worth
  considering which changes logically belong together and check these
  changes in in separate commits. 'git add -i' will be tremendously
  helpful for this part (adding changes into the index
  interactively).
 
 Pardon me for barging in. I just want to add that a git GUI makes it
 much less painful to pull diffs apart into commits compared to `git
 add -i`. TortoiseGit (http://code.google.com/p/tortoisegit/) works
 well on M$Windows.
 
 Regards,
 John Ralls

Interesting. I never used a gui for this yet. Which one do you use on your mac ?

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[John Ralls]

On Jan 9, 2014, at 11:13 PM, Gary Bilkus m...@gary.bilkus.com wrote:

 Well, interestingly enough, the problem is not directly with the compiler 
 optimizer. It's with the configure test for strncasecmp. This test fails on 
 mingw in its current incarnation because guile uses a standard test for the 
 function, but on mingw strncasecmp is actually a cpp definition. As a result, 
 guile is compiled with #HAVE_STRNCASECMP unset, and so guile tries to create 
 its own version in read.c
 Now if you compile with no optimization, the compiler notices that read.c is 
 attempting to create this with a different signature and bombs out. However, 
 with optimisation on, the code compiles for some reason, and then fails to 
 run properly.
 
 So there seem to be two problems: one in configure for guile and/or the 
 standard configure macros on mingw, the other in the compiler.
 Fortunately, there's a very easy although ugly workaround, which is to add an
 echo #define HAVE_STRNCASECMP config.h

Would adding -DHAVE_STRNCASECMP to $CFLAGS work? It's a bit cleaner than 
echoing a #define into the config header.
Better yet, sometimes there's a variable that can be defined on the configure 
command line -- perhaps $ac_have_strncasecmp -- to force configure to do the 
right thing.

 in install-impl.sh
 just after the guile configure and before the make
 
 I've incorporated this fix into my downloadable file of fixes as referred to 
 on the wiki page I updated.
 More as and when I find any further issues. As always, feedback or other 
 experiences welcome.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - guile problem SOLVED

[Gary Bilkus]

On 10/01/2014 15:03, John Ralls wrote:

On Jan 9, 2014, at 11:13 PM, Gary Bilkus m...@gary.bilkus.com wrote:


Well, interestingly enough, the problem is not directly with the compiler 
optimizer. It's with the configure test for strncasecmp. This test fails on 
mingw in its current incarnation because guile uses a standard test for the 
function, but on mingw strncasecmp is actually a cpp definition. As a result, 
guile is compiled with #HAVE_STRNCASECMP unset, and so guile tries to create 
its own version in read.c
Now if you compile with no optimization, the compiler notices that read.c is 
attempting to create this with a different signature and bombs out. However, 
with optimisation on, the code compiles for some reason, and then fails to run 
properly.

So there seem to be two problems: one in configure for guile and/or the 
standard configure macros on mingw, the other in the compiler.
Fortunately, there's a very easy although ugly workaround, which is to add an
echo #define HAVE_STRNCASECMP config.h

Would adding -DHAVE_STRNCASECMP to $CFLAGS work? It's a bit cleaner than 
echoing a #define into the config header.
Better yet, sometimes there's a variable that can be defined on the configure 
command line -- perhaps $ac_have_strncasecmp -- to force configure to do the 
right thing.


in install-impl.sh
just after the guile configure and before the make

I've incorporated this fix into my downloadable file of fixes as referred to on 
the wiki page I updated.
More as and when I find any further issues. As always, feedback or other 
experiences welcome.

Regards,
John Ralls

I agree that the configure commandline change would be cleaner, and if I 
can find out what to do I'll change my fix.


I disagree that a CFLAGS define is cleaner. With my solution the define 
is in the right file, even if it gets there for the wrong reason. That 
way, it guarantees not to affect any compilation which doesn't involve 
including config.h, which saves having to check for any unexpected 
consequenses elsewhere.

Gary
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Fwd: Building on Windows from scratch - guile problem SOLVED

[John Ralls]

Begin forwarded message:

 From: Gary Bilkus m...@gary.bilkus.com
 Subject: Re: Building on Windows from scratch - guile problem SOLVED
 Date: January 10, 2014 at 2:21:54 PM PST
 To: John Ralls jra...@ceridwen.us
 
 On 10/01/2014 17:41, Gary Bilkus wrote:
 On 10/01/2014 15:03, John Ralls wrote:
 On Jan 9, 2014, at 11:13 PM, Gary Bilkus m...@gary.bilkus.com wrote:
 
 Well, interestingly enough, the problem is not directly with the compiler 
 optimizer. It's with the configure test for strncasecmp. This test fails 
 on mingw in its current incarnation because guile uses a standard test for 
 the function, but on mingw strncasecmp is actually a cpp definition. As a 
 result, guile is compiled with #HAVE_STRNCASECMP unset, and so guile tries 
 to create its own version in read.c
 Now if you compile with no optimization, the compiler notices that read.c 
 is attempting to create this with a different signature and bombs out. 
 However, with optimisation on, the code compiles for some reason, and then 
 fails to run properly.
 
 So there seem to be two problems: one in configure for guile and/or the 
 standard configure macros on mingw, the other in the compiler.
 Fortunately, there's a very easy although ugly workaround, which is to add 
 an
 echo #define HAVE_STRNCASECMP config.h
 Would adding -DHAVE_STRNCASECMP to $CFLAGS work? It's a bit cleaner than 
 echoing a #define into the config header.
 Better yet, sometimes there's a variable that can be defined on the 
 configure command line -- perhaps $ac_have_strncasecmp -- to force 
 configure to do the right thing.
 
 in install-impl.sh
 just after the guile configure and before the make
 
 I've incorporated this fix into my downloadable file of fixes as referred 
 to on the wiki page I updated.
 More as and when I find any further issues. As always, feedback or other 
 experiences welcome.
 Regards,
 John Ralls
 
 I agree that the configure commandline change would be cleaner, and if I can 
 find out what to do I'll change my fix.
 
 I disagree that a CFLAGS define is cleaner. With my solution the define is 
 in the right file, even if it gets there for the wrong reason. That way, it 
 guarantees not to affect any compilation which doesn't involve including 
 config.h, which saves having to check for any unexpected consequenses 
 elsewhere.
 Gary
 OK. I've found the cleaner fix. You add ac_cv_func_strncasecmp=yes as a 
 command line argument to guile configure and then all seems good.
 Have updated my patch accordingly.
 


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Building on Windows from scratch - guile problem

[Gary Bilkus]

I have done some testing of my build, and it appears there is some kind 
of problem with guile


The symptom is that whenever I try to run a report, even hello world, it 
fails.


Digging into things, it turns out that there is at least one problem 
with the guile build, whcih is that

character constants like #\space are not being initialized correctly.

Just running guile standalone shows the problem.

guile #\space
\#nul

So there's obviously some problem with the guile build over and above 
the library naming one I found earlier. Not sure if it's the version, 
the compiler version or what.


Will investigate further, but any suggestions or experience from other 
would be welcome

Gary




On 08/01/2014 15:07, Gary Bilkus wrote:
I have written up the procedure which as of today is working to build 
gnucash 2.6 from scratch on windows and updated 
http://wiki.gnucash.org/wiki/Windows/Development


It would be really nice if the patch file I have created along with my 
modified version of geert's vbs file could find their way into the 
official repo.
It should be safe enough as all the changes are to the win32 directory 
except for two, which I'm reasonably confident won't break anything else:

- configure.ac now deals with the -no-undefined flag more cleverly
- gnc-split-reg.h has a couple of #undef statements added to avoid 
DELETE and DUPLICATE being defined in windows headers.


It probably also makes sense for the page to be split up again, and 
some of the older information moved away, but it would be good to get 
some feedback from people who try following the instructions.


I've done my best to ensure that there are no ambiguities or 
misprints, and the entire process has worked for me, but feel free to 
fix any errors, or tell me of any changes I can/should make to the zip 
file I've published.


Please note that I haven't extensively tested all the features of the 
program. There could be some issues with the build which don't 
immediately manifest themselves..but at least it runs.


Also, I haven't yet tried packaging the app into an msi or installable 
exe


Gary
___
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: Building on Windows from scratch - guile problem

[Gary Bilkus]

Hmm,

The problem appears to be with the compiler optimiser doing something too 
aggressive, If I manually recompile guile with -O0 instead of -O2 the problem 
seems to go away. This could be caused by one of the new optimisations in the 
more recent versions of gcc in which case it could start to matter on *nix at 
some point. Anyone know much about this?

 
 
Gary
 
-Original message-
From:Gary Bilkus m...@gary.bilkus.com
Sent:Thu 09-01-2014 13:37
Subject:Building on Windows from scratch - guile problem
To:gnucash-devel@gnucash.org; 
I have done some testing of my build, and it appears there is some kind 
of problem with guile

The symptom is that whenever I try to run a report, even hello world, it 
fails.

Digging into things, it turns out that there is at least one problem 
with the guile build, whcih is that
character constants like #\space are not being initialized correctly.

Just running guile standalone shows the problem.

guile #\space
\#nul

So there's obviously some problem with the guile build over and above 
the library naming one I found earlier. Not sure if it's the version, 
the compiler version or what.

Will investigate further, but any suggestions or experience from other 
would be welcome
Gary




On 08/01/2014 15:07, Gary Bilkus wrote:
 I have written up the procedure which as of today is working to build 
 gnucash 2.6 from scratch on windows and updated 
 http://wiki.gnucash.org/wiki/Windows/Development

 It would be really nice if the patch file I have created along with my 
 modified version of geert's vbs file could find their way into the 
 official repo.
 It should be safe enough as all the changes are to the win32 directory 
 except for two, which I'm reasonably confident won't break anything else:
 - configure.ac now deals with the -no-undefined flag more cleverly
 - gnc-split-reg.h has a couple of #undef statements added to avoid 
 DELETE and DUPLICATE being defined in windows headers.

 It probably also makes sense for the page to be split up again, and 
 some of the older information moved away, but it would be good to get 
 some feedback from people who try following the instructions.

 I've done my best to ensure that there are no ambiguities or 
 misprints, and the entire process has worked for me, but feel free to 
 fix any errors, or tell me of any changes I can/should make to the zip 
 file I've published.

 Please note that I haven't extensively tested all the features of the 
 program. There could be some issues with the build which don't 
 immediately manifest themselves..but at least it runs.

 Also, I haven't yet tried packaging the app into an msi or installable 
 exe

 Gary
 ___
 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
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Guile 2 status

[Geert Janssens]

With r23444 I have squashed the last failing tests I ran into with 
guile 2 and auto-compilation enabled.

I am aware that our tests don't cover the full source code, so there 
may still be guile 2 related bugs lurking in some dark forgotten 
corners.

Nevertheless I consider the guile 2 support to be complete now.

Would this be a good time to start preferring guile 2 over guile 1.8 
when both are available ? It's an easy switch in configure.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Guile 2 performance

[Geert Janssens]

The people at the guile irc channel asked me for some performance tests in 
gnucash comparing 
gnucash/guile1.8 vs gnucash/guile2.0.

I thought our GnuCash devs could be interested as well, so here goes:

I have conducted two tests:
1. run make check 20 times in the src/report/standard-reports directory. I have 
chosen that 
directory because the tests are fairly heavy and almost purely in scheme. So 
the time to run the 
tests is a good indicator of the relative performance of the two guile versions.

2. start gnucash --nofile a couple of times in a row and time how long it takes 
to display the 
main window. This is not a very accurate test - I looked at the wall clock to 
measure this. But 
startup time is something users are sensitive to, so it would be interesting to 
check for 
improvements.

Note that guile 2 now compiles its source files. This happens automatically 
whenever a file is 
newer than the last compiled version. For an installed gnucash, this should 
happen only once 
(at first startup) and hence is not representative of the user's experience. So 
for the 
gnucash/guile 2 test, I have first run make check and started the application 
once before doing 
my performance tests. As such, (one time) compile times are not part of the 
test results.

The results:
20x standard-reports tests:
- guile 1.8: real: 3m59s  user: 2m40s  sys: 0m9s
- guile 2.0: real: 2m48s  user: 1m45s  sys: 0m11s
Startup time (wall clock time to show main window, test run 3 times at least)
Average time is given:
- guile 1.8: 13s (consistently)
- guile 2.0: 9s (consistently)

That means that guile 2 improves the test performance with about 30% compared 
with guile 
1.8 and reduces the startup time with about 30% as well.

That's a nice improvement we get for free without even optimizing our own code 
IMO :)

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile 2 status

[Mike Alexander]

On Nov 26, 2013, at 8:52 AM, Geert Janssens janssens-ge...@telenet.be wrote:
 
 Would this be a good time to start preferring guile 2 over guile 1.8 
 when both are available ? It's an easy switch in configure.

That's fine with me.  I've been using Guile 2 for the last week or two and 
haven't noticed any issues related to that.

Mike
 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Guile 2 compatible release tarballs

[Geert Janssens]

Let me bring guile 2 up again. The current status is this:
- gnucash is ready for guile2, but depends on a very recent version of swig to 
generate guile 2 
compatible wrapper code
- in fact *very* recent: swig 2.0.10 has been release today and is the first 
version of swig 
capable of generating guile 2 compatible wrapper code

Does that mean we *require* swig 2.0.10 ? No. GnuCash 2.5.x works perfectly 
fine with guile 
1.8 and older versions of swig generate code that works fine with guile 1.8.

So if you start from our svn/git repository, it's just a matter of personal 
choice: do I want guile 
2 ? Ok, I'll have to make sure I get swig 2.0.10. If that's not an option yet, 
stick with guile 1.8 
and an older version of swig. Working code will be generated in both cases.

But what about our tarballs ? There we currently have a problem. The tarballs 
are shipped 
with pre-generated wrapper code. So a consumer of our tarballs doesn't have the 
choice: it 
has to find a guile version compatible with the pre-generated wrapper code. The 
currently 
pre-generated wrapper code is not guile 2 compatible, because it's still 
generated with an 
older swig version.

This mostly affects distro packagers. Most distros are currently switching to 
guile 2. Since our 
tarballs are not guile 2 ready, distros still have to provide guile 1.8 as well.

Also it sends the wrong message: we claim gnucash is guile 2 ready, but we ship 
a tarball 
that doesn't work with guile 2 ? Not good.

So here's my request: can we do future 2.5.x releases on a machine that has 
swig 2.0.10 
installed ? I know it's incredibly recent software, but it would correct the 
message we send 
and make the lives of several distro packagers more easy.

With future, I don't mean 2.5.2 that's currently in the middle of a release, 
but perhaps 2.5.3 
end of June would be possible ?

There is one more devil in the details: while the tarballs for 2.5.x should 
ideally be generated 
on a system with swig 2.0.10, tarballs for any possible future 2.4.x releases 
should *not*. 
Reason: swig 2.0.10 drops support for guile 1.6, while we claim gnucash 2.4.x 
does support 
guile 1.6.

So either 2.4.x and 2.5.x releases should be done from different machines or we 
drop support 
for guile 1.6 as well in the next 2.4.x release (if any).

What do you think ?

@John: since you are currently doing most releases, the question is probably 
aimed mostly at 
you: are you willing to install swig 2.0.10 on a machine you will be generating 
tarballs on ?

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile 2 compatible release tarballs

[John Ralls]

On May 27, 2013, at 1:45 PM, Geert Janssens janssens-ge...@telenet.be wrote:

 Let me bring guile 2 up again. The current status is this:
 - gnucash is ready for guile2, but depends on a very recent version of swig 
 to generate guile 2 
 compatible wrapper code
 - in fact *very* recent: swig 2.0.10 has been release today and is the first 
 version of swig 
 capable of generating guile 2 compatible wrapper code
 
 Does that mean we *require* swig 2.0.10 ? No. GnuCash 2.5.x works perfectly 
 fine with guile 
 1.8 and older versions of swig generate code that works fine with guile 1.8.
 
 So if you start from our svn/git repository, it's just a matter of personal 
 choice: do I want guile 
 2 ? Ok, I'll have to make sure I get swig 2.0.10. If that's not an option 
 yet, stick with guile 1.8 
 and an older version of swig. Working code will be generated in both cases.
 
 But what about our tarballs ? There we currently have a problem. The tarballs 
 are shipped 
 with pre-generated wrapper code. So a consumer of our tarballs doesn't have 
 the choice: it 
 has to find a guile version compatible with the pre-generated wrapper code. 
 The currently 
 pre-generated wrapper code is not guile 2 compatible, because it's still 
 generated with an 
 older swig version.
 
 This mostly affects distro packagers. Most distros are currently switching to 
 guile 2. Since our 
 tarballs are not guile 2 ready, distros still have to provide guile 1.8 as 
 well.
 
 Also it sends the wrong message: we claim gnucash is guile 2 ready, but we 
 ship a tarball 
 that doesn't work with guile 2 ? Not good.
 
 So here's my request: can we do future 2.5.x releases on a machine that has 
 swig 2.0.10 
 installed ? I know it's incredibly recent software, but it would correct the 
 message we send 
 and make the lives of several distro packagers more easy.
 
 With future, I don't mean 2.5.2 that's currently in the middle of a 
 release, but perhaps 2.5.3 
 end of June would be possible ?
 
 There is one more devil in the details: while the tarballs for 2.5.x should 
 ideally be generated 
 on a system with swig 2.0.10, tarballs for any possible future 2.4.x releases 
 should *not*. 
 Reason: swig 2.0.10 drops support for guile 1.6, while we claim gnucash 2.4.x 
 does support 
 guile 1.6.
 
 So either 2.4.x and 2.5.x releases should be done from different machines or 
 we drop support 
 for guile 1.6 as well in the next 2.4.x release (if any).
 
 What do you think ?
 
 @John: since you are currently doing most releases, the question is probably 
 aimed mostly at 
 you: are you willing to install swig 2.0.10 on a machine you will be 
 generating tarballs on ?

Yup. No problem. It's just a VM, and it's used exclusively for cross-platform
testing and doing Gnucash releases. Building now...

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: r22651 - gnucash/trunk/src - Guile 2: replace deprecated SCM_SYMBOL_CHARS function

[Geert Janssens]

Hi Alex,


On 21-12-12 20:06, Alex Aycinena wrote:

A couple of years ago, I used valgrind to find and correct memory
leaks in some code I had previously committed. In that process I
discovered that some of my leaks were caused by
'scm_to_locale_string'.

I investigated on the internet and found that to prevent memory leaks
in scm_to_locale_string() per the guile manual (see
'http://www.gnu.org/software/guile/manual/html_node/Dynamic-Wind.html#Dynamic-Wind),
you needed to surround scm_to_locale_string() with calls to
scm_dynwind_begin (0) and scm_dynwind_free (str) followed by
scm_dynwind_end ().

So I added the code that you have removed with this commit. I also
added it in many more places, including in code that I hadn't
committed, to clear up more memory leaks. Later, I realized that I
should refactor my code to replace all the instances that I had put it
in with a call to gnc_scm_to_locale_string. I haven't got around to
that last part yet but it is on my to do list.

So my questions to you are:

1. were you aware of the memory leak issue with gnc_scm_to_locale_string?
I remember those commits very well. I was excited about your valgrind 
work (which even today still feels like dark magic to me). I didn't 
really understand the details of the dynwind constructs, but trusted 
they fixed the memory leaks, which I still do.

2. has something changed between then and now that make this no longer
an issue and therefore the code no longer necessary?
Nothing has changed, except that I now believe the dynwind code has 
never really be necessary. My work to make GnuCash guile 2 compatible 
forced me in many ways to get a deeper understanding of how guile and c 
interact. As part of this, I also had to revisit the dynwind construct, 
what it does and when/why we should use it. This lead me to a slightly 
different understanding. From the manual:


For Scheme code, the fundamental procedure to react to non-local entry 
and exits of dynamic contexts is |dynamic-wind.


|The key part in this sentence is non-local entry and exits. dynwind 
is meant to wrap function calls that may not return to the place where 
they are called. Guile comes internally with an error handler that can 
make this happen for example. In the particular case of 
scm_to_locale_string, this function allocates memory to a variable. If a 
subsequent guile function is called that triggers guile's internal error 
handler, the call to g_free that follows is never reached. Hence the 
memory leak.


Does that mean that every call to scm_to_locale_string must be wrapped 
with scn_dynwind_begin and scm_dynwind_end ? In my opinion: no. Just 
look at the example in the manual you refer to: the first call to 
scm_to_locale_string isn't wrapped. It's the subsequent call and the 
call to scm_memory_error that are wrapped, because either of these 
function can trigger a non-local exit preventing the normal code flow 
from freeing the first assigned variable.


The same goes for our own gnc_scm_to_locale_string function :

gchar *gnc_scm_to_locale_string(SCM scm_string)
{
gchar* s;
char * str;

scm_dynwind_begin (0);
str = scm_to_locale_string(scm_string);
s = g_strdup(str);
scm_dynwind_free (str);
scm_dynwind_end ();
return s;
}

scm_to_locale_string doesn't have to be wrapped itself, because if it 
fails, str isn't assigned yet and can't be a memory leak. So there's 
only one function left that is wrapped: g_strdup(str). This function 
won't ever cause a non-local exit for guile: either it succeeds or it 
brings the whole application down because of memory issues. In the first 
case, the code proceeds normally and str can be freed normally. In the 
second case, well, a memory leak is not an issue anymore.


To conclude: as I understand it, the wrapping is not wrong, but adds 
unneeded overhead for our use case.


BUT... While writing all this, I noticed I glossed over a subtle memory 
issue nonetheless that I have to fix again: scm_to_locale_string uses 
malloc to allocate memory for the return value. The memory should be 
freed using free. However gnucash is based on glib and hence mostly 
deopends g_malloc to allocate memory. This memory should be freed using 
g_free. That was probably the main reason scm_to_locale_string was 
wrapped in the first place, which I didn't realize.


I'll readd the function gnc_scm_to_locale_string (in a simplified form) 
shortly to correct this. So once again: thanks for point this out.


||

3. does moving from guile 1.2 to guile 2 affect this in some way?

No

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: r22651 - gnucash/trunk/src - Guile 2: replace deprecated SCM_SYMBOL_CHARS function

[Geert Janssens]

And just to complete my explanation, you are in fact using the 
scm_dynwind_* functions slightly differently from their intended use. In 
the example of gnc_scm_to_locale_string the net result is the same, but 
in locations where it matters you won't get the desired memory leak 
protection effect.


A minimal code snippet:

str = scm_to_locale_string(scm_string);
scm_dynwind_begin (0);
call_other_scm_function; /* potentially non-local exiting function */
scm_dynwind_free (str); /* wrong: too late */
scm_dynwind_end ();

What happens here is that call_other_scm_function may exit non-locally 
(for example because it triggers the error catch code internally). If 
that happens, scm_dynwind_free is never reached and str won't be freed.


scm_dynwind_free is not actually freeing memory itself, but it tells 
guile to free the memory whenever the dynwind context is left (locally 
by reaching scm_dynwind_end or non-locally). So this function should be 
called *before* calling any function that might exit non-locally. The 
proper invocation would be:


str = scm_to_locale_string(scm_string);
scm_dynwind_begin (0);
scm_dynwind_free (str); /* ok */
call_other_scm_function; /* potentially non-local exiting function */
scm_dynwind_end ();

In this case, str is first marked for freeing (but not freed yet !) 
whenever the context ends and only then the potentially non-local 
exiting function is called. In this case str is guaranteed to be freed: 
if other_scm_function succeeds, str will be freed once scm_dynwind_end 
is reached. If it fails the non-local exit is detected internally and 
str is freed then.


As said before, for gnc_scm_to_locale_string this didn't matter really, 
because g_strdup is never exiting non-locally from guile's point of view.


I hope this helps clearing it up.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: r22651 - gnucash/trunk/src - Guile 2: replace deprecated SCM_SYMBOL_CHARS function

[Geert Janssens]

On 22-12-12 10:38, Geert Janssens wrote:
BUT... While writing all this, I noticed I glossed over a subtle 
memory issue nonetheless that I have to fix again: 
scm_to_locale_string uses malloc to allocate memory for the return 
value. The memory should be freed using free. However gnucash is based 
on glib and hence mostly deopends g_malloc to allocate memory. This 
memory should be freed using g_free. That was probably the main reason 
scm_to_locale_string was wrapped in the first place, which I didn't 
realize.


I'll readd the function gnc_scm_to_locale_string (in a simplified 
form) shortly to correct this. So once again: thanks for point this out.
I have readded a gnc_scm_to_locale_string functino and evaluated each 
use of scm_to_locale_string for possible memory leaks. I think they 
should all be properly handled now.


In most cases gnc_scm_to_locale_string was the proper replacement. In 
the very few cases where it made sense, I kept the original 
scm_to_locale_string accompanied by the proper scm_dynwind_* calls.


I also took the opportunity to improve some other guile convenience 
functions. But this work is incomplete. I may add to it as I encounter 
other cases where the wrapper functions make sense.


Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: r22651 - gnucash/trunk/src - Guile 2: replace deprecated SCM_SYMBOL_CHARS function

[Alex Aycinena]

Geert,

On Sat, Dec 15, 2012 at 9:58 AM, Geert Janssens
gjanss...@code.gnucash.org wrote:
 Author: gjanssens
 Date: 2012-12-15 12:58:40 -0500 (Sat, 15 Dec 2012)
 New Revision: 22651
 Trac: http://svn.gnucash.org/trac/changeset/22651

 Added:
gnucash/trunk/src/core-utils/gnc-guile-utils.c
gnucash/trunk/src/core-utils/gnc-guile-utils.h
 Modified:
gnucash/trunk/src/app-utils/guile-util.c
gnucash/trunk/src/app-utils/guile-util.h
gnucash/trunk/src/app-utils/option-util.c
gnucash/trunk/src/core-utils/Makefile.am
gnucash/trunk/src/engine/engine-helpers.c
gnucash/trunk/src/gnome/dialog-tax-info.c
gnucash/trunk/src/import-export/qif-import/assistant-qif-import.c
 Log:
 Guile 2: replace deprecated SCM_SYMBOL_CHARS function

 The replacements require guile 1.8 or above

 ___
 gnucash-patches mailing list
 gnucash-patc...@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-patches

A couple of years ago, I used valgrind to find and correct memory
leaks in some code I had previously committed. In that process I
discovered that some of my leaks were caused by
'scm_to_locale_string'.

I investigated on the internet and found that to prevent memory leaks
in scm_to_locale_string() per the guile manual (see
'http://www.gnu.org/software/guile/manual/html_node/Dynamic-Wind.html#Dynamic-Wind),
you needed to surround scm_to_locale_string() with calls to
scm_dynwind_begin (0) and scm_dynwind_free (str) followed by
scm_dynwind_end ().

So I added the code that you have removed with this commit. I also
added it in many more places, including in code that I hadn't
committed, to clear up more memory leaks. Later, I realized that I
should refactor my code to replace all the instances that I had put it
in with a call to gnc_scm_to_locale_string. I haven't got around to
that last part yet but it is on my to do list.

So my questions to you are:

1. were you aware of the memory leak issue with gnc_scm_to_locale_string?
2. has something changed between then and now that make this no longer
an issue and therefore the code no longer necessary?
3. does moving from guile 1.2 to guile 2 affect this in some way?

Regards,

Alex
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Guile-2.0

[rbibr...@t-online.de]

Hello,
nice to hear that my hints were of any help. To cleanup the different
hash datatypes is obviously the best solution. Thank you for this and
all the other corrections.

Relating to   scm_internal_stack_catch i found this email:

http://lists.gnu.org/archive/html/guile-devel/2011-07/msg9.html

but ihave no further insight 

Rudolf


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: guile-2.0

[Geert Janssens]

On 15-12-12 19:28, Geert Janssens wrote:

On 10-02-12 16:34, rbibr...@t-online.de wrote:


Starting gnucash within the console will result in a new compile process
for the guile files. Besides masses of warnings there are some errors
relating missing sw_*** files The lines (load-extension ..) in
file core-utils.scm, gnc-module.scm and qif-import.scm should be
replaced with (eval-when (compile load eval) (load-extension...)). In
file app-utils.scm it should read (eval-whwn (compile load eval)
(gnc:module-load gnucash/engine 0)).
One error in business-reports.scm remains : unbound variable:
gnc:menuname-business-reports which I do not understand??? But as long
gnucash does not use these compiled files it is not very relevant.

I still have to go into this, but again a very good starting point !
I have used your suggested changes, but wrapped them to only be used 
when running with guile 2.
For the remaining error in gnc:menuname-business-reports, I used the 
same trick which eliminates all autocompile errors.


I am ignoring the warnings for now. They are generated at autocompile 
time, but GnuCash works fine regardless.


Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GnuCash and Guile 2

[Geert Janssens]

I have fixed the remaining warnings I got when not auto compiling and 
the errors that guile's autocompile (1) generated. While files are 
autocompiled, it still generates lots of warnings about 'potentially 
undefined symbols'. This only happens while autocompiling. Since the 
compile results are cached, this happens only once for normal users.

The warnings are apparently harmless, because gnucash runs fine in my tests.

Also make check passes for both guile 1.8 and guile 2.0. Word of caution 
here though: if you install both guile and guile 2, for one of both the 
guile executable is not guile. In my case, I have guile (1.8) and 
guile2 (2.0). Some tests are hardcoded to execute 'guile' and these 
tests will segfault when run against guile2. If you manually fix the 
tests to execute guile2, they pass fine. This is a transient issue that 
will resolve itself once only guile2 is an option.


With current code, only three real deprecated symbol compile warnings 
(generated by guile) remain in src/app-utils/gfec.c


This has to do with catching errors when trying to eval some string/load 
a file from c to scm. This is slightly too technical for me to really 
grasp. Moreover, the deprecation warning states:
'scm_internal_stack_catch' is deprecated. Talk to guile-devel if you see 
this message


So that's what needs to happen. For now, I'll just keep the warnings in 
place, but will prevent the build from failing on this and consider 
GnuCash ready for guile 2.


Note this hasn't been tested on platforms other than (Fedora) linux. The 
windows build should first try to get guile 2 itself running before it 
can be tested and probably something similar is needed for the OS 
X/Quarz build.


But I consider neither a requirement for GnuCash 2.6. What guile 2 is 
concerned, I consider it ready to go.


Geert


(1) Note that compiling scheme files is a new feature of guile 2. Guile 
2 by default compiles those files into some byte code format to be run 
on in internal virtual machine. If no specific parameters are set, this 
happens the first time a scheme file is needed by guile. The compiled 
file is cached for later use. Compilation can be skipped by setting the 
environment variable GUILE_AUTO_COMPILE to 0 before running the 
program.  If skipped guile will fall back to the old method of simply 
interpreting the files (unless a previously compiled file is still found 
in cache).


On 15-12-12 19:21, Geert Janssens wrote:

As of r22655 the development branch of gnucash can be built and run
with guile 2. It still spews warnings and the environment variable
GUILE_AUTO_COMPILE should be set to 0, so this is still a work in 
progress.


It is important to realize though that this is only possible is swig is
properly patched as well. I have submitted a patch here for swig:
https://bugzilla.redhat.com/show_bug.cgi?id=752054

So build instructions in short:
- download the swig patch from the above link (against swig 2.0.8) and 
build a

patched swig
- install guile 2
- checkout gnucash' trunk branch as of r22655
- you may need to update configure.ac to have it prefer guile 2 if 
both guile

1.8 and guile 2 are installed on the system
- build gnucash as usual
- run gnucash as
GUILE_AUTO_COMPILE=0 /path/to/gnucash

It goes without saying that gnucash continues to work with guile 1.8.

Feedback is welcome.


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GnuCash and Guile 2

[John Ralls]

On Dec 18, 2012, at 10:01 AM, Geert Janssens janssens-ge...@telenet.be wrote:
 Also make check passes for both guile 1.8 and guile 2.0. Word of caution here 
 though: if you install both guile and guile 2, for one of both the guile 
 executable is not guile. In my case, I have guile (1.8) and guile2 (2.0). 
 Some tests are hardcoded to execute 'guile' and these tests will segfault 
 when run against guile2. If you manually fix the tests to execute guile2, 
 they pass fine. This is a transient issue that will resolve itself once only 
 guile2 is an option.

Can we fix that to use a configure-set variable?

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GnuCash and Guile 2

[Geert Janssens]

On 18-12-12 19:52, John Ralls wrote:

On Dec 18, 2012, at 10:01 AM, Geert Janssens janssens-ge...@telenet.be wrote:

Also make check passes for both guile 1.8 and guile 2.0. Word of caution here though: if 
you install both guile and guile 2, for one of both the guile executable is not 
guile. In my case, I have guile (1.8) and guile2 (2.0). Some tests are 
hardcoded to execute 'guile' and these tests will segfault when run against guile2. If 
you manually fix the tests to execute guile2, they pass fine. This is a transient issue 
that will resolve itself once only guile2 is an option.

Can we fix that to use a configure-set variable?

Regards,
John Ralls

As far as I understand, this is a distro-specific issue. Upstream the 
guile binary is called guile for both 1.8 and 2.0. It's because distro's 
want to install two releases next to each other that they rename one 
binary. Fedora has chosen guile and guile2, but another distro might 
just as well choose guile1 and guile or guile and guile-2 as binary names.


GnuCash can't know this. It also not something that is defined in 
pkgconfig, so I don't know how we can figure out what binary name we 
should use.


Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GnuCash and Guile 2

[John Ralls]

On Dec 18, 2012, at 1:16 PM, Geert Janssens janssens-ge...@telenet.be wrote:

 On 18-12-12 19:52, John Ralls wrote:
 On Dec 18, 2012, at 10:01 AM, Geert Janssens janssens-ge...@telenet.be 
 wrote:
 Also make check passes for both guile 1.8 and guile 2.0. Word of caution 
 here though: if you install both guile and guile 2, for one of both the 
 guile executable is not guile. In my case, I have guile (1.8) and guile2 
 (2.0). Some tests are hardcoded to execute 'guile' and these tests will 
 segfault when run against guile2. If you manually fix the tests to execute 
 guile2, they pass fine. This is a transient issue that will resolve itself 
 once only guile2 is an option.
 Can we fix that to use a configure-set variable?
 
 Regards,
 John Ralls
 
 As far as I understand, this is a distro-specific issue. Upstream the guile 
 binary is called guile for both 1.8 and 2.0. It's because distro's want to 
 install two releases next to each other that they rename one binary. Fedora 
 has chosen guile and guile2, but another distro might just as well choose 
 guile1 and guile or guile and guile-2 as binary names.
 
 GnuCash can't know this. It also not something that is defined in pkgconfig, 
 so I don't know how we can figure out what binary name we should use.

But configure can figure it out by testing possibilities with AC_CHECK_PROGS, 
as a configure option using AC_ARG_WITH, or both.

You could also check an environment variable, which would facilitate testing 
the same build with both versions.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

GnuCash and Guile 2

[Geert Janssens]

As of r22655 the development branch of gnucash can be built and run
with guile 2. It still spews warnings and the environment variable
GUILE_AUTO_COMPILE should be set to 0, so this is still a work in progress.

It is important to realize though that this is only possible is swig is
properly patched as well. I have submitted a patch here for swig:
https://bugzilla.redhat.com/show_bug.cgi?id=752054

So build instructions in short:
- download the swig patch from the above link (against swig 2.0.8) and build a
patched swig
- install guile 2
- checkout gnucash' trunk branch as of r22655
- you may need to update configure.ac to have it prefer guile 2 if both guile
1.8 and guile 2 are installed on the system
- build gnucash as usual
- run gnucash as
GUILE_AUTO_COMPILE=0 /path/to/gnucash

It goes without saying that gnucash continues to work with guile 1.8.

Feedback is welcome.

For those interested, below are the warnings I still get:
WARNING: (gnucash import-export qif-import): `gnc-build-dotgnucash-path' 
imported from both (sw_engine) and (gnucash core-utils)
WARNING: (gnucash report report-system): imported module (gnucash app-utils) 
overrides core binding `N_'
WARNING: (gnucash report report-system): imported module (gnucash app-utils) 
overrides core binding `N_'
WARNING: (gnucash report report-system): imported module (gnucash app-utils) 
overrides core binding `N_'
WARNING: (gnucash report stylesheet-plain): imported module (gnucash app-utils) 
overrides core binding `N_'
WARNING: (gnucash report stylesheet-fancy): imported module (gnucash app-utils) 
overrides core binding `N_'
WARNING: (gnucash report stylesheet-footer): imported module (gnucash 
app-utils) overrides core binding `N_'
WARNING: (gnucash report stylesheet-easy): imported module (gnucash app-utils) 
overrides core binding `N_'
WARNING: (gnucash report standard-reports budget): imported module (gnucash 
app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports average-balance): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports budget-balance-sheet): imported 
module (gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports category-barchart): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports general-journal): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports net-barchart): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports net-linechart): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports cash-flow): imported module (gnucash 
app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports register): imported module (gnucash 
app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports budget-barchart): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports daily-reports): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports price-scatter): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports trial-balance): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports budget-flow): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports account-summary): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports balance-sheet): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports general-ledger): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports advanced-portfolio): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports income-statement): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports budget-income-statement): imported 
module (gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports account-piecharts): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports portfolio): imported module (gnucash 
app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports sx-summary): imported module (gnucash 
app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports equity-statement): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports transaction): imported module 
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report hello-world): imported module (gnucash app-utils

Re: guile-2.0

[Geert Janssens]

On 10-02-12 16:34, rbibr...@t-online.de wrote:

-Original Message-
Date: Fri, 03 Feb 2012 15:40:17 +0100
Subject: Re: guile-2.0
From: rbibr...@t-online.de rbibr...@t-online.de
To: gnucash-devel@gnucash.org



according to the manual guile provides two types of hashtables one
abstract type and one vectorlike type. May be that mixing both types
was allowed in guile 1.8 but not longer in 2.0

In file html-style-info.scm a vector type table was created. The lines
for the abstract type are outcommented. May be that the hanging
hash-fold should be replaced by a construction similare to kvt-fold.???

Rudolf


In the file html-document.scm line 292 I have replaced hash-fold with
kvt-fold so that this line reads now:
  (if attr (kvt-fold add-attribute  #f attr))
The reports are working now!!
Obviously guile-2 has different sorts of hashtables.
Your suggestion about incompatible hashtable types was invaluable to get 
me past this crasher.


GnuCash was mixing a custom hash datatype (kvt-hash) with a guile proper 
hash type. Apparently in guile 1.8 the internal representation was 
compatible enough to get away with this. In guile 2 this obviously 
changed. I decided to fix it in the other direction though: I have 
thrown out our custom hash datatype. It was only used in one file and I 
couldn't see any obvious benefits in it.


Thanks a lot for guiding me in the right direction !

Starting gnucash within the console will result in a new compile process
for the guile files. Besides masses of warnings there are some errors
relating missing sw_*** files The lines (load-extension ..) in
file core-utils.scm, gnc-module.scm and qif-import.scm should be
replaced with (eval-when (compile load eval) (load-extension...)). In
file app-utils.scm it should read (eval-whwn (compile load eval)
(gnc:module-load gnucash/engine 0)).
One error in business-reports.scm remains : unbound variable:
gnc:menuname-business-reports which I do not understand??? But as long
gnucash does not use these compiled files it is not very relevant.

I still have to go into this, but again a very good starting point !

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

guile-2.0

[rbibr...@t-online.de]

-Original Message-
Date: Fri, 03 Feb 2012 15:40:17 +0100
Subject: Re: guile-2.0
From: rbibr...@t-online.de rbibr...@t-online.de
To: gnucash-devel@gnucash.org


-Original Message-
Date: Fri, 03 Feb 2012 13:36:58 +0100
Subject: Re: guile-2.0
From: Geert Janssens janssens-ge...@telenet.be

This is also where I stranded so far on Fedora 16, with test packages
for 
Guile 2.0 installed.

My guile knowledge is too limited to understand this well. The gnucash
code 
has a definition for the hash-table procedure. But this should only be 
triggered for guile 1.8 and older.

Guile 2.0 has its own definition of hash-table. Perhaps these
definitions are 
not compatible ? I mean, the gnucash guile code was written for guile
1.6 and 
1.8. So perhaps GnuCash interprets hash-table differently in terms of
1.8 
while the 2.0 definition may be slightly different ?

From what I could read in the guile 2.0 manual it doesn't seem like
that.

Geert

according to the manual guile provides two types of hashtables one
abstract type and one vectorlike type. May be that mixing both types
was allowed in guile 1.8 but not longer in 2.0

In file html-style-info.scm a vector type table was created. The lines
for the abstract type are outcommented. May be that the hanging
hash-fold should be replaced by a construction similare to kvt-fold.???

Rudolf


In the file html-document.scm line 292 I have replaced hash-fold with
kvt-fold so that this line reads now:
 (if attr (kvt-fold add-attribute  #f attr))
The reports are working now!!
Obviously guile-2 has different sorts of hashtables.

Starting gnucash within the console will result in a new compile process
for the guile files. Besides masses of warnings there are some errors
relating missing sw_*** files The lines (load-extension ..) in
file core-utils.scm, gnc-module.scm and qif-import.scm should be
replaced with (eval-when (compile load eval) (load-extension...)). In
file app-utils.scm it should read (eval-whwn (compile load eval)
(gnc:module-load gnucash/engine 0)).
One error in business-reports.scm remains : unbound variable: 
gnc:menuname-business-reports which I do not understand??? But as long
gnucash does not use these compiled files it is not very relevant.

RBB




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: guile-2.0

[Geert Janssens]

Op vrijdag 10 februari 2012 16:34:00 schreef rbibr...@t-online.de:
 -Original Message-
 Date: Fri, 03 Feb 2012 15:40:17 +0100
 Subject: Re: guile-2.0
 From: rbibr...@t-online.de rbibr...@t-online.de
 To: gnucash-devel@gnucash.org
 
 
 -Original Message-
 Date: Fri, 03 Feb 2012 13:36:58 +0100
 Subject: Re: guile-2.0
 From: Geert Janssens janssens-ge...@telenet.be
 
 This is also where I stranded so far on Fedora 16, with test packages
 for
 Guile 2.0 installed.
 
 My guile knowledge is too limited to understand this well. The gnucash
 code
 has a definition for the hash-table procedure. But this should only be
 triggered for guile 1.8 and older.
 
 Guile 2.0 has its own definition of hash-table. Perhaps these
 definitions are
 not compatible ? I mean, the gnucash guile code was written for guile
 1.6 and
 1.8. So perhaps GnuCash interprets hash-table differently in terms of
 1.8
 while the 2.0 definition may be slightly different ?
 
 From what I could read in the guile 2.0 manual it doesn't seem like
 
 that.
 
 Geert
 
 according to the manual guile provides two types of hashtables one
 abstract type and one vectorlike type. May be that mixing both types
 was allowed in guile 1.8 but not longer in 2.0
 
 In file html-style-info.scm a vector type table was created. The lines
 for the abstract type are outcommented. May be that the hanging
 hash-fold should be replaced by a construction similare to kvt-fold.???
 
 Rudolf
 
 
 In the file html-document.scm line 292 I have replaced hash-fold with
 kvt-fold so that this line reads now:
  (if attr (kvt-fold add-attribute  #f attr))
 The reports are working now!!
 Obviously guile-2 has different sorts of hashtables.
 
 Starting gnucash within the console will result in a new compile process
 for the guile files. Besides masses of warnings there are some errors
 relating missing sw_*** files The lines (load-extension ..) in
 file core-utils.scm, gnc-module.scm and qif-import.scm should be
 replaced with (eval-when (compile load eval) (load-extension...)). In
 file app-utils.scm it should read (eval-whwn (compile load eval)
 (gnc:module-load gnucash/engine 0)).
 One error in business-reports.scm remains : unbound variable:
 gnc:menuname-business-reports which I do not understand??? But as long
 gnucash does not use these compiled files it is not very relevant.
 
 RBB
 

Rudolf,

Thanks for figuring this out. I'll play with it one of the next days to see if 
I can come up with a guile 2.0 fix based on your findings.  One thing to keep 
in mind is that guile 1.8 should still be supported as well, so perhaps the 
eval-when (compile ...) constructs may have to be wrapped once again in guile2 
a guile2 only selector.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

guile-2.0

[rbibr...@t-online.de]

Hello,
as reported in one of my earlier mails I have build a working gnucash
(opensuse 12.1, guile 2). but starting a report  is still impossible.
Today I tried it again in the console and got this message:

ERROR: In procedure hash-fold: Wrong type argument in position 3
(expecting hash-table): #(((bgcolor . #f6ffdb)))

this seemed to be in file html-document.scm line 292

actually I do not now if this is indeed an error in this file or one of
the new guile-2 things. ???

RBB



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: guile-2.0

[Geert Janssens]

Op vrijdag 3 februari 2012 13:15:32 schreef rbibr...@t-online.de:
 Hello,
 as reported in one of my earlier mails I have build a working gnucash
 (opensuse 12.1, guile 2). but starting a report  is still impossible.
 Today I tried it again in the console and got this message:
 
 ERROR: In procedure hash-fold: Wrong type argument in position 3
 (expecting hash-table): #(((bgcolor . #f6ffdb)))
 
 this seemed to be in file html-document.scm line 292
 
 actually I do not now if this is indeed an error in this file or one of
 the new guile-2 things. ???
 
This is also where I stranded so far on Fedora 16, with test packages for 
Guile 2.0 installed.

My guile knowledge is too limited to understand this well. The gnucash code 
has a definition for the hash-table procedure. But this should only be 
triggered for guile 1.8 and older.

Guile 2.0 has its own definition of hash-table. Perhaps these definitions are 
not compatible ? I mean, the gnucash guile code was written for guile 1.6 and 
1.8. So perhaps GnuCash interprets hash-table differently in terms of 1.8 
while the 2.0 definition may be slightly different ?

From what I could read in the guile 2.0 manual it doesn't seem like that.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: guile-2.0

[rbibr...@t-online.de]

-Original Message-
Date: Fri, 03 Feb 2012 13:36:58 +0100
Subject: Re: guile-2.0
From: Geert Janssens janssens-ge...@telenet.be

This is also where I stranded so far on Fedora 16, with test packages
for 
Guile 2.0 installed.

My guile knowledge is too limited to understand this well. The gnucash
code 
has a definition for the hash-table procedure. But this should only be 
triggered for guile 1.8 and older.

Guile 2.0 has its own definition of hash-table. Perhaps these
definitions are 
not compatible ? I mean, the gnucash guile code was written for guile
1.6 and 
1.8. So perhaps GnuCash interprets hash-table differently in terms of
1.8 
while the 2.0 definition may be slightly different ?

From what I could read in the guile 2.0 manual it doesn't seem like
that.

Geert

according to the manual guile provides two types of hashtables one
abstract type and one vectorlike type. May be that mixing both types
was allowed in guile 1.8 but not longer in 2.0

In file html-style-info.scm a vector type table was created. The lines
for the abstract type are outcommented. May be that the hanging
hash-fold should be replaced by a construction similare to kvt-fold.???

Rudolf



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

gnucash mentioned in guile docs.

[Hendrik Boom]

Just a matter of slight interest -- gnucash is mentioned in the guile 1.8 
documentation.  It seems that gnucash is part of a significant code eco-
system for Guile-based applications.

See the last paragraph of http://www.gnu.org/software/guile/docs/docs-1.8/
guile-ref/Scheme-vs-C.html#Scheme-vs-C

-- hendrik

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile 2

[Hendrik Boom]

On Fri, 09 Dec 2011 23:52:25 +0100, Geert Janssens wrote:

 Op vrijdag 9 december 2011 10:59:31 schreef Ted Creedon:
 Is anyone working on the Guile 2 issues?
 
 Not right now, but it's on my to do list.
 
 I plan to work on it somewhere in the next couple of weeks.

Please keep me informed what's happening -- I'm trying to write 
documentation for the users who want to write their own reports and such 
in guile -- both for those who want their onw report generators invoked 
from within gnucash and those who want to use the gnucash engine in their 
own scheme code to access the database.

-- hendrik


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile problems

[John Ralls]

On Jan 1, 2012, at 10:51 AM, Ted Creedon wrote:

 Nothing like progress, installing guile 1.8 doesn't work either

And since Guile 1.8 is known to work with GC (it's what's shipped in the OSX 
distribution and what you'll find in most distros), you may have other 
issues... or GC might still be finding the Guile-2 installation. But this is a 
topic for your distro' s support mailing list, not for here.

Regards,
John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: r21803 - gnucash/branches/2.4/packaging/win32 - Fix guile load path for guile-1.8.8

[Geert Janssens]

Op vrijdag 30 december 2011 16:40:11 schreef John Ralls:
 Author: jralls
 Date: 2011-12-30 16:40:11 -0500 (Fri, 30 Dec 2011)
 New Revision: 21803
 Trac: http://svn.gnucash.org/trac/changeset/21803
 
 Modified:
gnucash/branches/2.4/packaging/win32/gnucash.iss.in
 Log:
 Fix guile load path for guile-1.8.8
 
 
 Otherwise Gnucash crashes on launch.
 
 Modified: gnucash/branches/2.4/packaging/win32/gnucash.iss.in
 ===
 --- gnucash/branches/2.4/packaging/win32/gnucash.iss.in   2011-12-30 
 17:27:12
 UTC (rev 21802) +++
 gnucash/branches/2.4/packaging/win32/gnucash.iss.in   2011-12-30 21:40:11 UTC
 (rev 21803) @@ -164,7 +164,7 @@
  [UninstallDelete]
  Type: files; Name: {app}\bin\guile.cmd
  Type: files; Name: {app}\etc\gnucash\environment
 -Type: files; Name: {app}\share\guile\1.6\slibcat
 +Type: files; Name: {app}\share\guile\1.8\slibcat
  Type: filesandordirs; Name: {app}\share\guile
  Type: filesandordirs; Name: {app}\etc\gconf
  Type: dirifempty; Name: {app}\etc\gnucash
 
 ___
 gnucash-changes mailing list
 gnucash-chan...@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-changes
I have fixed a couple more in the same file that are more subtle. Without 
these the Windows installation would effectively use guile 1.6 modules if 
still available on the system (and otherwise error out).

While I was at it, I have also backported Derek's feature table 
implementation.

I have restarted the 2.4 nightly to pick up these changes, so you can still 
check today if everything works.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile Strings

[Geert Janssens]

Op vrijdag 30 december 2011 15:18:30 schreef John Ralls: 
 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.
 
That's already good.

 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/Gn
 ucash-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.

Have you tried with environment variable GUILE_AUTO_COMPILE=0 set ? You may 
need to remove the already autocompiled modules from /Users/john/.cache/guile 
also.

I read somewhere [1] that guile 2 can either precompile modules for 
performance or use the old interpreted mechanism. I never found explicit 
documentation on how to select one or the other, but as I understand it you 
have to disable auto compilation to get the interpreter.

Geert

[1] http://sites.google.com/site/robertharamoto/Home/programming/moving-to-
guile-2
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile Strings

[John Ralls]

On Dec 31, 2011, at 1:59 AM, Geert Janssens wrote:

 Op vrijdag 30 december 2011 15:18:30 schreef John Ralls: 
 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.
 
 That's already good.
 
 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/Gn
 ucash-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.
 
 Have you tried with environment variable GUILE_AUTO_COMPILE=0 set ? You may 
 need to remove the already autocompiled modules from /Users/john/.cache/guile 
 also.
 
 I read somewhere [1] that guile 2 can either precompile modules for 
 performance or use the old interpreted mechanism. I never found explicit 
 documentation on how to select one or the other, but as I understand it you 
 have to disable auto compilation to get the interpreter.

Yes. It only reduces the spew, it doesn't fix the segfault at the end.

The key is in ERROR: no code for module (sw_gnc_module), and after debugging 
into it with the Guile interpreter I've established that Guile 2.0 changes the 
way that it loads C libraries. I could only get (dynamic-link) to find a 
library in /usr/lib. It ignores LD_LIBRARY_PATH and DYLD_LIBRARY_PATH and won't 
load even with an absolute path (though the documentation implies that it 
should).

I'm going to have to go code-diving in the Guile-2 sources to figure this out, 
but not right now.

Regards,
John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile Strings

[Derek Atkins]

On Sat, December 31, 2011 2:01 pm, John Ralls wrote:

 On Dec 31, 2011, at 1:59 AM, Geert Janssens wrote:

 The key is in ERROR: no code for module (sw_gnc_module), and after
 debugging into it with the Guile interpreter I've established that Guile
 2.0 changes the way that it loads C libraries. I could only get
 (dynamic-link) to find a library in /usr/lib. It ignores LD_LIBRARY_PATH
 and DYLD_LIBRARY_PATH and won't load even with an absolute path (though
 the documentation implies that it should).

 I'm going to have to go code-diving in the Guile-2 sources to figure this
 out, but not right now.


IMHO this is not high priority for 2.4.x, but we should get guile-2
working for 2.6.  So, this should not hold up the 2.4.9 release.

 Regards,
 John Ralls

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile Strings

[John Ralls]

On Dec 31, 2011, at 11:11 AM, Derek Atkins wrote:

 
 On Sat, December 31, 2011 2:01 pm, John Ralls wrote:
 
 On Dec 31, 2011, at 1:59 AM, Geert Janssens wrote:
 
 The key is in ERROR: no code for module (sw_gnc_module), and after
 debugging into it with the Guile interpreter I've established that Guile
 2.0 changes the way that it loads C libraries. I could only get
 (dynamic-link) to find a library in /usr/lib. It ignores LD_LIBRARY_PATH
 and DYLD_LIBRARY_PATH and won't load even with an absolute path (though
 the documentation implies that it should).
 
 I'm going to have to go code-diving in the Guile-2 sources to figure this
 out, but not right now.
 
 
 IMHO this is not high priority for 2.4.x, but we should get guile-2
 working for 2.6.  So, this should not hold up the 2.4.9 release.

Absolutely. I need to get guile-1.8 working correctly in M$Win for the 2.4.9 
release.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile Strings

[John Ralls]

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

Guile 2

[Ted Creedon]

Is anyone working on the Guile 2 issues?

tedc
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Guile 2

[Geert Janssens]

Op vrijdag 9 december 2011 10:59:31 schreef Ted Creedon:
 Is anyone working on the Guile 2 issues?
 
Not right now, but it's on my to do list.

I plan to work on it somewhere in the next couple of weeks.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

FW: OpenSuse 12.1 Guile 2.0

[rbibr...@t-online.de]

Hello,

in the moment I am using this version (J.Engel)
http://download.opensuse.org/repositories/home:/j-engel/openSUSE_12.1/i586/
It is working including the onelinebanking (hbci), but the the reports
have severe problems (hanging, crashing)

In Guile 2.0 several procedures are completly deleted:
the GH Interface (isthis of any relevance??)
maxdepth, scm_string_chars (already corrected in trunk),
scm_stringp, scm_symbol_chars

scm_symbol_chars appears in the following files:

guile-util.c, option-util.c, engine-helpers.c, dialog-tax-info.c, 
druid-qif-import.c
 At least here a correction is needed
(may be with scm_symbol_to_string, scm_to_utf8_stringn)

My capabilities are are limited, sorry

Rudolf




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: FW: OpenSuse 12.1 Guile 2.0

[Ted Creedon]

Guile 2.0 has sabotaged guncash

I'm told to build 2.4.99/2.4.8  against guile 1.8.x which I have with
limited success

Also discovered dbus problem with running via ssh -X -A

tedc

On Sat, Dec 3, 2011 at 2:44 AM, rbibr...@t-online.de
rbibr...@t-online.dewrote:

 Hello,

 in the moment I am using this version (J.Engel)
 http://download.opensuse.org/repositories/home:/j-engel/openSUSE_12.1/i586/
 It is working including the onelinebanking (hbci), but the the reports
 have severe problems (hanging, crashing)

 In Guile 2.0 several procedures are completly deleted:
 the GH Interface (isthis of any relevance??)
 maxdepth, scm_string_chars (already corrected in trunk),
 scm_stringp, scm_symbol_chars

 scm_symbol_chars appears in the following files:

 guile-util.c, option-util.c, engine-helpers.c, dialog-tax-info.c,
 druid-qif-import.c
  At least here a correction is needed
 (may be with scm_symbol_to_string, scm_to_utf8_stringn)

 My capabilities are are limited, sorry

 Rudolf




 ___
 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: Fwd: 2.4.8 git /w guile 2.0

[Geert Janssens]

On donderdag 10 november 2011, Ted Creedon wrote:
 Built a new system w. guile 2.0
 
 export GUILE_AUTO_COMPILE=0
 make clean;./configure --disable-error-on-warning;time nice make -s
 gnucash
 
 On Wed, Nov 9, 2izzy:/data/gnucash # rm -rf /root/.cache/guile/*;gnucash
 
 gnc.bin-Message: main: binreloc relocation support was disabled at
 configure time.
 
 WARNING: no socket to connect to
 Backtrace:
 In ice-9/boot-9.scm:
  170: 12 [catch #t #catch-closure c5dc60 ...]
 In unknown file:
?: 11 [catch-closure]
 In ice-9/boot-9.scm:
 2497: 10 [#procedure bf17a0 at ice-9/boot-9.scm:2485:4 (name #:optional
 autoload version #:key ensure) # ...]
 2763: 9 [try-module-autoload (gnucash main) #f]
 2103: 8 [save-module-excursion #procedure dd97b0 at
 ice-9/boot-9.scm:2764:17 ()]
 2774: 7 [#procedure dd97b0 at ice-9/boot-9.scm:2764:17 ()]
 In unknown file:
?: 6 [primitive-load-path gnucash/main #f]
 In ice-9/eval.scm:
  458: 5 [#procedure b330c0 at ice-9/eval.scm:452:4 (exp) #]
 In ice-9/psyntax.scm:
 1024: 4 [chi-top-sequence ((debug-set! maxdepth 10)) () ...]
  922: 3 [scan ((debug-set! maxdepth 10)) () ...]
 1015: 2 [scan ((#(syntax-object debug-options # ...) (# # #))) () ...]
 In ice-9/boot-9.scm:
 2854: 1 [debug-options (show-file-name #t stack ...)]
 In unknown file:
?: 0 [debug-options-interface (show-file-name #t stack ...)]
 
 ERROR: In procedure debug-options-interface:
 ERROR: In procedure debug-options-interface: Unknown option name: maxdepth
 
This error was fixed a couple of days ago on the trunk branch. It seems you 
are not using the most recent HEAD, the wrong branch or the wrong git repo.

What is the url of your origin git repo ?
What branch did you check out ?

Geert

 011 at 9:06 AM, Ted Creedon tcree...@easystreet.net wrote:
  can anyone suggest a suitable log.conf?
  
The errors you get so far are in guile code. My experience is that there's not 
much debug logging in that code unfortunately. But you could set gnc.scm to 
debug to get most out of it. You can do that either on the commandline with 
the switch --log=gnc.scm=debug or in log.conf.
See http://wiki.gnucash.org/wiki/Logging for some more details.

Geert

  thanks
  ted
  
  On Wed, Nov 9, 2011 at 8:59 AM, Ted Creedon 
tcree...@easystreet.netwrote:
  announce window  tip of the day pop up before exiting
  
  rm -rf /root/.cache/guile/;GUILE_AUTO_COMPILE=0 gnucash --debug --extra
  
  gnc.bin-Message: main: binreloc relocation support was disabled at
  configure time.
  
  This is a development version. It may or may not work.
  Report bugs and other problems to gnucash-devel@gnucash.org.
  You can also lookup and file bug reports at http://bugzilla.gnome.org
  The last stable version was GnuCash 2.4.7
  The next stable version will be GnuCash 2.6
  
  WARNING: (gnucash import-export qif-import): `GNC-DENOM-AUTO' imported
  from both (sw_engine) and (gnucash engine)
  WARNING: (gnucash import-export qif-import): `gnc-build-dotgnucash-path'
  imported from both (sw_engine) and (gnucash core-utils)
  WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
  both (sw_engine) and (gnucash engine)
  WARNING: (gnucash report report-system): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report report-system): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
  both (sw_engine) and (gnucash engine)
  WARNING: (gnucash report report-system): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
  both (sw_engine) and (gnucash engine)
  WARNING: (gnucash report report-system): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report stylesheet-plain): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report stylesheet-fancy): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report stylesheet-footer): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report stylesheet-easy): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports daily-reports): imported
  module (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports account-summary): imported
  module (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports general-journal): imported
  module (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports advanced-portfolio): imported
  module (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports advanced-portfolio):
  `GNC-DENOM-AUTO' imported from both (sw_engine) and (gnucash engine)
  WARNING: (gnucash report standard-reports balance-sheet): imported
  module

Re: Fwd: 2.4.8 git /w guile 2.0

[Derek Atkins]

Ted,

Ted Creedon tcree...@easystreet.net writes:

 Brand new clean system Lizzy - first build did a git pull and ran the
 perl script

 #!/usr/bin/perl
 #-;-perl-;-
 use strict;

 use lib (split(/:/, $ENV{GITPERLLIB} ||
 /usr/local/git/lib/perl5/site_perl));
 use Git;

 Git::command_noisy(pull, (--rebase, origin, @ARGV));
 my @branches = Git::command(branch, -r);
 map s/[*\s]//g, @branches;
 @branches = map { /^origin\/([^\s]+)$/ ? $1 : () } @branches;
 map { Git::command(update-ref, (refs/remotes/$_,
 refs/remotes/origin/$_)); } @branches;

This script means absolutely nothing to me, and you didn't answer my
question:

Are you sure you're using the most recent trunk (of GnuCash)?

-derek

 On Thu, Nov 10, 2011 at 10:49 AM, Derek Atkins de...@ihtfp.com wrote:

 Ted,

 Are you sure you're using the most recent trunk?

 Also, I wonder where it's finding ice-9/boot-9.scm?  Are there any traces
 of guile-1.8 on this system?  Any traces of an old GnuCash build?

 -derek

 On Thu, November 10, 2011 1:37 pm, Ted Creedon wrote:
  Built a new system w. guile 2.0
 
  export GUILE_AUTO_COMPILE=0
  make clean;./configure --disable-error-on-warning;time nice make -s
  gnucash
 
  On Wed, Nov 9, 2izzy:/data/gnucash # rm -rf /root/.cache/guile/*;gnucash
 
  gnc.bin-Message: main: binreloc relocation support was disabled at
  configure time.
 
  WARNING: no socket to connect to
  Backtrace:
  In ice-9/boot-9.scm:
   170: 12 [catch #t #catch-closure c5dc60 ...]
  In unknown file:
 ?: 11 [catch-closure]
  In ice-9/boot-9.scm:
  2497: 10 [#procedure bf17a0 at ice-9/boot-9.scm:2485:4 (name #:optional
  autoload version #:key ensure) # ...]
  2763: 9 [try-module-autoload (gnucash main) #f]
  2103: 8 [save-module-excursion #procedure dd97b0 at
  ice-9/boot-9.scm:2764:17 ()]
  2774: 7 [#procedure dd97b0 at ice-9/boot-9.scm:2764:17 ()]
  In unknown file:
 ?: 6 [primitive-load-path gnucash/main #f]
  In ice-9/eval.scm:
   458: 5 [#procedure b330c0 at ice-9/eval.scm:452:4 (exp) #]
  In ice-9/psyntax.scm:
  1024: 4 [chi-top-sequence ((debug-set! maxdepth 10)) () ...]
   922: 3 [scan ((debug-set! maxdepth 10)) () ...]
  1015: 2 [scan ((#(syntax-object debug-options # ...) (# # #))) () ...]
  In ice-9/boot-9.scm:
  2854: 1 [debug-options (show-file-name #t stack ...)]
  In unknown file:
 ?: 0 [debug-options-interface (show-file-name #t stack ...)]
 
  ERROR: In procedure debug-options-interface:
  ERROR: In procedure debug-options-interface: Unknown option name:
 maxdepth
  011 at 9:06 AM, Ted Creedon tcree...@easystreet.net wrote:
 
  can anyone suggest a suitable log.conf?
 
  thanks
  ted
 
 
  On Wed, Nov 9, 2011 at 8:59 AM, Ted Creedon
  tcree...@easystreet.netwrote:
 
  announce window  tip of the day pop up before exiting
 
  rm -rf /root/.cache/guile/;GUILE_AUTO_COMPILE=0 gnucash --debug --extra
 
  gnc.bin-Message: main: binreloc relocation support was disabled at
  configure time.
 
  This is a development version. It may or may not work.
  Report bugs and other problems to gnucash-devel@gnucash.org.
  You can also lookup and file bug reports at http://bugzilla.gnome.org
  The last stable version was GnuCash 2.4.7
  The next stable version will be GnuCash 2.6
 
  WARNING: (gnucash import-export qif-import): `GNC-DENOM-AUTO' imported
  from both (sw_engine) and (gnucash engine)
  WARNING: (gnucash import-export qif-import):
  `gnc-build-dotgnucash-path'
  imported from both (sw_engine) and (gnucash core-utils)
  WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
  both (sw_engine) and (gnucash engine)
  WARNING: (gnucash report report-system): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report report-system): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
  both (sw_engine) and (gnucash engine)
  WARNING: (gnucash report report-system): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
  both (sw_engine) and (gnucash engine)
  WARNING: (gnucash report report-system): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report stylesheet-plain): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report stylesheet-fancy): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report stylesheet-footer): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report stylesheet-easy): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports daily-reports): imported
  module
  (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports account-summary): imported
  module (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard

Re: 2.4.8 git /w guile 2.0

[John Ralls]

On Nov 11, 2011, at 8:01 AM, Derek Atkins wrote:

 Ted,
 
 Ted Creedon tcree...@easystreet.net writes:
 
 Brand new clean system Lizzy - first build did a git pull and ran the
 perl script
 
 #!/usr/bin/perl
 #-;-perl-;-
 use strict;
 
 use lib (split(/:/, $ENV{GITPERLLIB} ||
 /usr/local/git/lib/perl5/site_perl));
 use Git;
 
 Git::command_noisy(pull, (--rebase, origin, @ARGV));
 my @branches = Git::command(branch, -r);
 map s/[*\s]//g, @branches;
 @branches = map { /^origin\/([^\s]+)$/ ? $1 : () } @branches;
 map { Git::command(update-ref, (refs/remotes/$_,
 refs/remotes/origin/$_)); } @branches;
 
 This script means absolutely nothing to me, and you didn't answer my
 question:
 
 Are you sure you're using the most recent trunk (of GnuCash)?
 

The script just gets the latest from git (one hopes that that's 
git://github.com/Gnucash/gnucash.git) and renames the branch pointers -- 
basically a no-op.

What he's not telling us is what branch he has checked out to do his build.

Regards,
John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: 2.4.8 git /w guile 2.0

[Ted Creedon]

Whats the correct incantation?
ted

On Fri, Nov 11, 2011 at 8:30 AM, John Ralls jra...@ceridwen.us wrote:


 On Nov 11, 2011, at 8:01 AM, Derek Atkins wrote:

  Ted,
 
  Ted Creedon tcree...@easystreet.net writes:
 
  Brand new clean system Lizzy - first build did a git pull and ran the
  perl script
 
  #!/usr/bin/perl
  #-;-perl-;-
  use strict;
 
  use lib (split(/:/, $ENV{GITPERLLIB} ||
  /usr/local/git/lib/perl5/site_perl));
  use Git;
 
  Git::command_noisy(pull, (--rebase, origin, @ARGV));
  my @branches = Git::command(branch, -r);
  map s/[*\s]//g, @branches;
  @branches = map { /^origin\/([^\s]+)$/ ? $1 : () } @branches;
  map { Git::command(update-ref, (refs/remotes/$_,
  refs/remotes/origin/$_)); } @branches;
 
  This script means absolutely nothing to me, and you didn't answer my
  question:
 
  Are you sure you're using the most recent trunk (of GnuCash)?
 

 The script just gets the latest from git (one hopes that that's git://
 github.com/Gnucash/gnucash.git) and renames the branch pointers --
 basically a no-op.

 What he's not telling us is what branch he has checked out to do his build.

 Regards,
 John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: 2.4.8 git /w guile 2.0

[John Ralls]

On Nov 11, 2011, at 8:39 AM, Ted Creedon wrote:

 Whats the correct incantation?

To do what?

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: 2.4.8 git /w guile 2.0

[Ted Creedon]

here's what I did, it it correct?

git clone git://github.com/Gnucash/gnucash.git
cd gnucash/
./autogen.sh
./configure --enable-debug --disable-error-on-warning  #won't
compile without this disable switch
 make

gnucash --version
gnc.bin-Message: main: binreloc relocation support was disabled at
configure time.

GnuCash 2.4.99 development version
Built 2011-11-08 from r872d437+


rm -rf /root/.cache/guile/;GUILE_AUTO_COMPILE=0 gnucash --debug --extra
--log=gnc.scm=debug
gnc.bin-Message: main: binreloc relocation support was disabled at
configure time.

This is a development version. It may or may not work.
Report bugs and other problems to gnucash-devel@gnucash.org.
You can also lookup and file bug reports at http://bugzilla.gnome.org
The last stable version was GnuCash 2.4.7
The next stable version will be GnuCash 2.6

WARNING: (gnucash import-export qif-import): `GNC-DENOM-AUTO' imported from
both (sw_engine) and (gnucash engine)
WARNING: (gnucash import-export qif-import): `gnc-build-dotgnucash-path'
imported from both (sw_engine) and (gnucash core-utils)
WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
both (sw_engine) and (gnucash engine)
WARNING: (gnucash report report-system): imported module (gnucash
app-utils) overrides core binding `N_'
WARNING: (gnucash report report-system): imported module (gnucash
app-utils) overrides core binding `N_'
WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
both (sw_engine) and (gnucash engine)
WARNING: (gnucash report report-system): imported module (gnucash
app-utils) overrides core binding `N_'
WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
both (sw_engine) and (gnucash engine)
WARNING: (gnucash report report-system): imported module (gnucash
app-utils) overrides core binding `N_'
WARNING: (gnucash report stylesheet-plain): imported module (gnucash
app-utils) overrides core binding `N_'
WARNING: (gnucash report stylesheet-fancy): imported module (gnucash
app-utils) overrides core binding `N_'
WARNING: (gnucash report stylesheet-footer): imported module (gnucash
app-utils) overrides core binding `N_'
WARNING: (gnucash report stylesheet-easy): imported module (gnucash
app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports daily-reports): imported module
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports account-summary): imported module
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports general-journal): imported module
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports advanced-portfolio): imported
module (gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports advanced-portfolio):
`GNC-DENOM-AUTO' imported from both (sw_engine) and (gnucash engine)
WARNING: (gnucash report standard-reports balance-sheet): imported module
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports category-barchart): imported
module (gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports budget-barchart): imported module
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports price-scatter): imported module
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports sx-summary): imported module
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports average-balance): imported module
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports equity-statement): imported
module (gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports transaction): imported module
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports budget-flow): imported module
(gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash report standard-reports account-piecharts): imported
module (gnucash app-utils) overrides core binding `N_'
WARNING: (gnucash business-utils): imported module (gnucash app-utils)
overrides core binding `N_'
WARNING: (gnucash business-utils): imported module (gnucash app-utils)
overrides core binding `N_'
WARNING: (gnucash report hello-world): imported module (gnucash app-utils)
overrides core binding `N_'
WARNING: (gnucash report view-column): imported module (gnucash app-utils)
overrides core binding `N_'
WARNING: (gnucash report welcome-to-gnucash): imported module (gnucash
app-utils) overrides core binding `N_'
WARNING: (gnucash report report-gnome): imported module (gnucash app-utils)
overrides core binding `N_'
WARNING: (gnucash report business-reports): imported module (gnucash
app-utils) overrides core binding `N_'
WARNING: (gnucash report fancy-invoice): imported module (gnucash
app-utils) overrides core binding `N_'
WARNING: (gnucash report invoice): imported

Re: 2.4.8 git /w guile 2.0

[Ted Creedon]

here's the trace file
 10:04:12  INFO gnc.engine [gnc_hook_lookup] no hook lists
* 10:04:12  INFO qof.engine [init_from_file] guid_init got 512 bytes from
/dev/urandom
* 10:04:12  INFO qof.engine [init_from_file] guid_init got 1375 bytes
from /etc/passwd
* 10:04:12  INFO qof.engine [init_from_file] guid_init got 27 bytes from
/proc/loadavg
* 10:04:12  INFO qof.engine [init_from_file] guid_init got 1170 bytes
from /proc/meminfo
* 10:04:12  INFO qof.engine [init_from_file] guid_init got 571 bytes from
/proc/net/dev
* 10:04:12  INFO qof.engine [init_from_file] guid_init got 4096 bytes
from /proc/self/environ
* 10:04:12  INFO qof.engine [init_from_file] guid_init got 236 bytes from
/proc/self/stat
* 10:04:12  INFO qof.engine [init_from_file] guid_init got 3041 bytes
from /proc/stat
* 10:04:12  INFO qof.engine [init_from_file] guid_init got 19 bytes from
/proc/uptime
* 10:04:12  INFO qof.engine [guid_init] got 38589 bytes
* 10:04:12  INFO gnc.backend.dbi [gnc_module_init_backend_dbi]
GNC_DBD_DIR not set: using libdbi built-in default
* 10:04:12  INFO gnc.backend.dbi [gnc_module_init_backend_dbi] 3 DBD
drivers found
* 10:04:12  INFO gnc.backend.dbi [gnc_module_init_backend_dbi] Driver:
mysql
* 10:04:12  INFO gnc.backend.dbi [gnc_module_init_backend_dbi] Driver:
sqlite3
* 10:04:12  INFO gnc.backend.dbi [gnc_module_init_backend_dbi] Driver:
pgsql
* 10:04:14 MESSG gnc.module Could not locate optional module
gnucash/import-export/aqbanking interface v.0
* 10:04:15 DEBUG gnc.scm dir-files=(daily-reports.scm account-summary.scm
general-journal.scm advanced-portfolio.scm balance-sheet.scm
category-barchart.scm budget-barchart.scm price-scatter.scm sx-summary.scm
average-balance.scm equity-statement.scm transaction.scm budget-flow.scm
account-piecharts.scm balsheet-eg.scm register.scm
budget-income-statement.scm general-ledger.scm cash-flow.scm portfolio.scm
trial-balance.scm budget.scm budget-balance-sheet.scm net-barchart.scm
income-statement.scm)
* 10:04:15 DEBUG gnc.scm processed=(daily-reports account-summary
general-journal advanced-portfolio balance-sheet category-barchart
budget-barchart price-scatter sx-summary average-balance equity-statement
transaction budget-flow account-piecharts balsheet-eg register
budget-income-statement general-ledger cash-flow portfolio trial-balance
budget budget-balance-sheet net-barchart income-statement)
* 10:04:15 DEBUG gnc.scm report-list=(daily-reports account-summary
general-journal advanced-portfolio balance-sheet category-barchart
budget-barchart price-scatter sx-summary average-balance equity-statement
transaction budget-flow account-piecharts balsheet-eg register
budget-income-statement general-ledger cash-flow portfolio trial-balance
budget budget-balance-sheet net-barchart income-statement)


On Fri, Nov 11, 2011 at 10:11 AM, Ted Creedon tcree...@easystreet.netwrote:

 here's what I did, it it correct?

 git clone git://github.com/Gnucash/gnucash.git
 cd gnucash/
 ./autogen.sh
 ./configure --enable-debug --disable-error-on-warning  #won't
 compile without this disable switch
  make

 gnucash --version

 gnc.bin-Message: main: binreloc relocation support was disabled at
 configure time.

 GnuCash 2.4.99 development version
 Built 2011-11-08 from r872d437+


 rm -rf /root/.cache/guile/;GUILE_AUTO_COMPILE=0 gnucash --debug --extra
 --log=gnc.scm=debug
 gnc.bin-Message: main: binreloc relocation support was disabled at
 configure time.

 This is a development version. It may or may not work.
 Report bugs and other problems to gnucash-devel@gnucash.org.
 You can also lookup and file bug reports at http://bugzilla.gnome.org
 The last stable version was GnuCash 2.4.7
 The next stable version will be GnuCash 2.6

 WARNING: (gnucash import-export qif-import): `GNC-DENOM-AUTO' imported
 from both (sw_engine) and (gnucash engine)
 WARNING: (gnucash import-export qif-import): `gnc-build-dotgnucash-path'
 imported from both (sw_engine) and (gnucash core-utils)
 WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
 both (sw_engine) and (gnucash engine)
 WARNING: (gnucash report report-system): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report report-system): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
 both (sw_engine) and (gnucash engine)
 WARNING: (gnucash report report-system): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
 both (sw_engine) and (gnucash engine)
 WARNING: (gnucash report report-system): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report stylesheet-plain): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report stylesheet-fancy): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report stylesheet-footer

Re: 2.4.8 git /w guile 2.0

[Geert Janssens]

On vrijdag 11 november 2011, Ted Creedon wrote:
 here's what I did, it it correct?
 
 git clone git://github.com/Gnucash/gnucash.git
 cd gnucash/
 ./autogen.sh
 ./configure --enable-debug --disable-error-on-warning  #won't
 compile without this disable switch
  make
 
 gnucash --version
 gnc.bin-Message: main: binreloc relocation support was disabled at
 configure time.
 
 GnuCash 2.4.99 development version
 Built 2011-11-08 from r872d437+
 
This is not the most recent git commit, but recent enough. It does have the 
maxdepth bug fix.

git checkout trunk
git-update (the perl script you displayed before)
should get you to the latest commit.

I'll have to investigate the new errors you report below.

Geert

 
 rm -rf /root/.cache/guile/;GUILE_AUTO_COMPILE=0 gnucash --debug --extra
 --log=gnc.scm=debug
 gnc.bin-Message: main: binreloc relocation support was disabled at
 configure time.
 
 This is a development version. It may or may not work.
 Report bugs and other problems to gnucash-devel@gnucash.org.
 You can also lookup and file bug reports at http://bugzilla.gnome.org
 The last stable version was GnuCash 2.4.7
 The next stable version will be GnuCash 2.6
 
 WARNING: (gnucash import-export qif-import): `GNC-DENOM-AUTO' imported from
 both (sw_engine) and (gnucash engine)
 WARNING: (gnucash import-export qif-import): `gnc-build-dotgnucash-path'
 imported from both (sw_engine) and (gnucash core-utils)
 WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
 both (sw_engine) and (gnucash engine)
 WARNING: (gnucash report report-system): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report report-system): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
 both (sw_engine) and (gnucash engine)
 WARNING: (gnucash report report-system): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
 both (sw_engine) and (gnucash engine)
 WARNING: (gnucash report report-system): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report stylesheet-plain): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report stylesheet-fancy): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report stylesheet-footer): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report stylesheet-easy): imported module (gnucash
 app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports daily-reports): imported module
 (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports account-summary): imported module
 (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports general-journal): imported module
 (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports advanced-portfolio): imported
 module (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports advanced-portfolio):
 `GNC-DENOM-AUTO' imported from both (sw_engine) and (gnucash engine)
 WARNING: (gnucash report standard-reports balance-sheet): imported module
 (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports category-barchart): imported
 module (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports budget-barchart): imported module
 (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports price-scatter): imported module
 (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports sx-summary): imported module
 (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports average-balance): imported module
 (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports equity-statement): imported
 module (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports transaction): imported module
 (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports budget-flow): imported module
 (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash report standard-reports account-piecharts): imported
 module (gnucash app-utils) overrides core binding `N_'
 WARNING: (gnucash business-utils): imported module (gnucash app-utils)
 overrides core binding `N_'
 WARNING: (gnucash business-utils): imported module (gnucash app-utils)
 overrides core binding `N_'
 WARNING: (gnucash report hello-world): imported module (gnucash app-utils)
 overrides core binding `N_'
 WARNING: (gnucash report view-column): imported module (gnucash app-utils)
 overrides core binding `N_'
 WARNING: (gnucash report welcome-to-gnucash): imported module

Re: 2.4.8 git /w guile 2.0

[Ted Creedon]

GUILE_WARN_DEPRECATED=detailed make check
cut =
PASS: test-load-c
FAIL: test-load-scm
PASS: test-gwrapped-c
PASS: test-scm-module
FAIL: test-scm-multi
FAIL: test-load-deps


On Fri, Nov 11, 2011 at 10:33 AM, Geert Janssens
janssens-ge...@telenet.bewrote:

 On vrijdag 11 november 2011, Ted Creedon wrote:
  here's what I did, it it correct?
 
  git clone git://github.com/Gnucash/gnucash.git
  cd gnucash/
  ./autogen.sh
  ./configure --enable-debug --disable-error-on-warning  #won't
  compile without this disable switch
   make
 
  gnucash --version
  gnc.bin-Message: main: binreloc relocation support was disabled at
  configure time.
 
  GnuCash 2.4.99 development version
  Built 2011-11-08 from r872d437+
 
 This is not the most recent git commit, but recent enough. It does have the
 maxdepth bug fix.

 git checkout trunk
 git-update (the perl script you displayed before)
 should get you to the latest commit.

 I'll have to investigate the new errors you report below.

 Geert

 
  rm -rf /root/.cache/guile/;GUILE_AUTO_COMPILE=0 gnucash --debug --extra
  --log=gnc.scm=debug
  gnc.bin-Message: main: binreloc relocation support was disabled at
  configure time.
 
  This is a development version. It may or may not work.
  Report bugs and other problems to gnucash-devel@gnucash.org.
  You can also lookup and file bug reports at http://bugzilla.gnome.org
  The last stable version was GnuCash 2.4.7
  The next stable version will be GnuCash 2.6
 
  WARNING: (gnucash import-export qif-import): `GNC-DENOM-AUTO' imported
 from
  both (sw_engine) and (gnucash engine)
  WARNING: (gnucash import-export qif-import): `gnc-build-dotgnucash-path'
  imported from both (sw_engine) and (gnucash core-utils)
  WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
  both (sw_engine) and (gnucash engine)
  WARNING: (gnucash report report-system): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report report-system): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
  both (sw_engine) and (gnucash engine)
  WARNING: (gnucash report report-system): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report report-system): `GNC-DENOM-AUTO' imported from
  both (sw_engine) and (gnucash engine)
  WARNING: (gnucash report report-system): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report stylesheet-plain): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report stylesheet-fancy): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report stylesheet-footer): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report stylesheet-easy): imported module (gnucash
  app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports daily-reports): imported module
  (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports account-summary): imported
 module
  (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports general-journal): imported
 module
  (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports advanced-portfolio): imported
  module (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports advanced-portfolio):
  `GNC-DENOM-AUTO' imported from both (sw_engine) and (gnucash engine)
  WARNING: (gnucash report standard-reports balance-sheet): imported module
  (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports category-barchart): imported
  module (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports budget-barchart): imported
 module
  (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports price-scatter): imported module
  (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports sx-summary): imported module
  (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports average-balance): imported
 module
  (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports equity-statement): imported
  module (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports transaction): imported module
  (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports budget-flow): imported module
  (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash report standard-reports account-piecharts): imported
  module (gnucash app-utils) overrides core binding `N_'
  WARNING: (gnucash business-utils): imported module (gnucash app-utils)
  overrides core binding `N_'
  WARNING