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

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

[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

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

Re: Gnucash with Guile 2

[Geert Janssens]

On vrijdag 20 mei 2011, Mike Alexander wrote:
 --On May 18, 2011 7:23:38 PM +0200 Geert Janssens
 
 janssens-ge...@telenet.be wrote:
  On vrijdag 6 mei 2011, John Ralls wrote:
  On May 6, 2011, at 9:47 AM, Daniel Kraft wrote:
   Hi all,
   
   I'm not able to build Gnucash 2.4.5 with Guile 2 installed --
   which is not too surprising, since the API and architecture of
   Guile changed a lot since 1.8.  Is this expected, or is there some
   way I can build Gnucash without having to install also an old
   Guile somewhere?  Are there plans to switch to the new API (or in
   general, support Guile 2)?
  
  It's expected. We haven't done anything with Guile2. Heck, we just
  got rid of the Guile 1.6 dependencies in trunk. I'm afraid you're
  stuck with having to have both versions installed for awhile.
  
  Regards,
  John Ralls
  
  If you are adventurous though, you could try to build GnuCash from
  trunk. I  have applied a number of patches by Andy Wingo [1] that
  should make GnuCash  work with Guile 2. It would be a nice test to
  see if that actually works.
  
  Standard disclaimer: note that such an attempt is at your own risk.
  Trunk is  not considered production quality and using it may cause
  crashes and data  loss.
  
  If you want to try it and have further questions, I suggest you
  subscribe to  the gnucash-devel list and post your findings there.
 
 Just out of curiosity I gave this a try today.  I got it to build ok,
 but it doesn't run since SWIG hasn't been updated to work with Guile2.
 There seems to be some progress on this, however [1] so there's hope.
 
Ok, thanks for trying. At least we know where the bottleneck is now.

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

Re: Gnucash with Guile 2

[Mike Alexander]

--On May 18, 2011 7:23:38 PM +0200 Geert Janssens 
janssens-ge...@telenet.be wrote:



On vrijdag 6 mei 2011, John Ralls wrote:

On May 6, 2011, at 9:47 AM, Daniel Kraft wrote:
 Hi all,

 I'm not able to build Gnucash 2.4.5 with Guile 2 installed --
 which is not too surprising, since the API and architecture of
 Guile changed a lot since 1.8.  Is this expected, or is there some
 way I can build Gnucash without having to install also an old
 Guile somewhere?  Are there plans to switch to the new API (or in
 general, support Guile 2)?

It's expected. We haven't done anything with Guile2. Heck, we just
got rid of the Guile 1.6 dependencies in trunk. I'm afraid you're
stuck with having to have both versions installed for awhile.

Regards,
John Ralls


If you are adventurous though, you could try to build GnuCash from
trunk. I  have applied a number of patches by Andy Wingo [1] that
should make GnuCash  work with Guile 2. It would be a nice test to
see if that actually works.

Standard disclaimer: note that such an attempt is at your own risk.
Trunk is  not considered production quality and using it may cause
crashes and data  loss.

If you want to try it and have further questions, I suggest you
subscribe to  the gnucash-devel list and post your findings there.


Just out of curiosity I gave this a try today.  I got it to build ok, 
but it doesn't run since SWIG hasn't been updated to work with Guile2. 
There seems to be some progress on this, however [1] so there's hope.


 Mike

[1] http://lists.gnu.org/archive/html/guile-user/2011-03/msg00066.html


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