Re: [GNC-dev] Building Mac version using SDK 12

[Rob Gowin]

There are suggestions on the interweb that adding -DNS_FORMAT_ARGUMENT(A)=
to compiler options will work around this problem.

-- Rob



On Thu, Sep 15, 2022 at 12:55 PM john  wrote:

>
>
> > On Sep 14, 2022, at 9:41 PM, Mike Alexander  wrote:
> >
> > When I try to build either current maint or master using MacOSX12.1.sdk
> or MacOSX12.3.sdk for SDKROOT I get compile errors in
> gnc-filepath-utils.cpp.  The first error is
> >
> > In file included from
> /System/Volumes/Data/tools/gnucash-maint/gnucash/libgnucash/core-utils/gnc-filepath-utils.cpp:64:
> > In file included from
> /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12:
> >
> /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSBundle.h:91:143:
> error: function does not return NSString
> > - (NSAttributedString *)localizedAttributedStringForKey:(NSString *)key
> value:(nullable NSString *)value table:(nullable NSString *)tableName
> NS_FORMAT_ARGUMENT(1) NS_REFINED_FOR_SWIFT API_AVAILABLE(macos(12.0),
> ios(15.0), watchos(8.0), tvos(15.0));
> >
> /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:103:48:
> note: expanded from macro 'NS_FORMAT_ARGUMENT'
> >#define NS_FORMAT_ARGUMENT(A) __attribute__ ((format_arg(A)))
> >
> > This is probably because there is something wrong with my build
> environment, but I was wondering if anyone else had seen this?
>
> Mike,
>
> I haven't had any errors like that.
>
> I don't understand the error but it seems to be an SDK error rather than
> anything we're doing. Might the compiler have gotten out of sync with the
> SDK?
>
> Regards,
> John Ralls
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Porting the Tutorial & Concepts Guide to ReadTheDocs.org

[Rob Gowin]

I think the functionality of Locale Filter could be done using the Sphinx 
‘ifconfig’ extension[1]. It allows content selection based on a Python 
expression involving variables set in the Sphinx conf.py file.

[1] https://www.sphinx-doc.org/en/master/usage/extensions/ifconfig.html 
<https://www.sphinx-doc.org/en/master/usage/extensions/ifconfig.html>

Rob

> On Feb 11, 2021, at 6:41 PM, John Ralls  wrote:
> 
> A couple of references to what Geert is talking about:
> 
> The W3C specification for Internationaliation Tag Set Locale Filters: 
> https://www.w3.org/TR/its20/#LocaleFilter
> Geert had in mind to use ITS Tool for processing Locale Filter tags; the 
> relevant documentation is at http://itstool.org/documentation/its.html. No 
> Anchors, scroll to Locale Filter.
> 
> I don't see anything similar in the rather sparse reST/Sphinx i18n docs, but 
> ISTM we could probably accomplish something similar with the build system as 
> long as the locale-unique material is in its own file. With a little more 
> work we could invent a reST directive to hold the locale filter tags and 
> preprocess the file before handing it off to Sphinx.
> 
> Regards,
> John Ralls
> 
> 
>> On Feb 10, 2021, at 5:43 AM, Geert Janssens  
>> wrote:
>> 
>> Hi Rob,
>> 
>> I have gathered from irc conversations the you have picked up on your 
>> interest 
>> of converting our documentation to reStructuredText. As I'm unfortunately 
>> not 
>> able to spend much time on irc while you are there, I will add some comments 
>> on this mailing list thread.
>> 
>> From the little information I have so far it looks like reStructuredText and 
>> the sphinx tool have everything it takes for a good conversion with plenty 
>> of 
>> benefits.
>> 
>> The only concern that remains for me is as mentioned earlier:
>> So far I don't see the ability for a master document in which certain 
>> sections 
>> only apply to some languages. To be fair our current documentation doesn't 
>> support that either as of today, but adding ITS to the current docbook mix 
>> would allow us to move in that direction.
>> 
>> Personally I find that an important feature to have for our future 
>> documentation system. Contrary to many other domains, accounting 
>> documentation 
>> is sensitive to regional differences. Each region may have subtle 
>> differences 
>> in how certain things are to be explained.
>> Luckily there is standardisation which means an estimated 90% of the 
>> documentation can be shared, but a small portion is region dependent. A 
>> typical example would be tax rules. Or some concepts only make sense in 
>> certain regions and don't apply at all in other regions.
>> 
>> Considering most of the documentation is common, a translation flow based on 
>> a 
>> master document with message catalogs makes sense to me. The huge benefit is 
>> that we can offer user-friendly systems to translators. I seem to remember 
>> the 
>> biggest hurdle for documentation writers and translators is git. Going for a 
>> gettext based translation system, at least translators would be able to do 
>> most of their job in tools familiar to them, like weblate or poedit or 
>> whatever.
>> 
>> But we should take care to also be able to handle that small part that's 
>> not. 
>> And that's where ITS in the docbook context would come in. It allows (among 
>> others) to mark certain sections as applying only to one specific "language".
>> 
>> That would allow an American document writer to explain the basics of 
>> American 
>> taxes, and a Dutch translator could replace that with a Dutch alternative in 
>> such a way that if the American section changes the Dutch translation is not 
>> affected.
>> 
>> And it would allow the American document to explain state taxes. Belgium and 
>> the Netherlands don't have states, so that section could be omitted in a 
>> Dutch 
>> translation.
>> 
>> I admit not having searched very hard, but I  didn't find something similar 
>> for reStructuredText or the sphinx build system.
>> 
>> Do you see ways to implement something like that ?
>> 
>> Regards,
>> 
>> Geert
>> 
>> Op zaterdag 25 april 2020 20:16:46 CET schreef Rob Gowin:
>>>> On Apr 25, 2020, at 2:24 AM, Geert Janssens 
>>>> wrote:
>>>> 
>>>> Hi Rob,
>>>> 
>>>> Thanks for running this experiment.
>>>> 
>>>> The stylesheet used by ReadTheDocs is much more modern than ours and
>>>> indee

Re: [GNC-dev] Porting the Tutorial & Concepts Guide to ReadTheDocs.org

[Rob Gowin]

> On Apr 25, 2020, at 2:24 AM, Geert Janssens  
> wrote:
> 
> Hi Rob,
>  
> Thanks for running this experiment.
>  
> The stylesheet used by ReadTheDocs is much more modern than ours and indeed 
> looks much nicer for online consumption. Even the pdf is cleaner.
>  
> On the other hand I also have a few concerns/questions:
> 1. How would a translation flow look like with asciidoc ?
> 2. Can it support a single master document including sections that should 
> only appear for certain translations ?
> 3. ReadTheDocs is a hosted service. That's a big change from our current 
> philosophy to self-host as much as possible. Are there self-hosting options ?
>  
> Regards,
>  
> Geert

Hi Geert, 

First off, yes, the documentation can be self hosted. I’ve done that here: 
https://gnucash-docs-test.codesmythe.net/index.html 
. It uses an older 
stylesheet, so looks a little different, and there’s no PDF there. I have 
generated a PDF similar to the ReadTheDocs one locally. Note that this 
experiment uses files in the reStructuredText format, not asciidoc. The reST 
files are generated from the DocBook files using pandoc.

For translation: The underlying tool used by ReadTheDocs is the Sphinx Python 
Doc Generation Project. Their I18N flow is described here: 
http://www.sphinx-doc.org/en/master/usage/advanced/intl.html 
. I’m no expert 
in the area, but seems it does support a single master document. I don’t know 
about sections that should only appear for certain translations.

I’ll jump on IRC sometime this week to discuss translations in more detail. 

Regards,

Rob

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

[GNC-dev] Porting the Tutorial & Concepts Guide to ReadTheDocs.org

[Rob Gowin]

Got the itch to play around with GnuCash’s documentation tooling, file format, 
etc. I’m an AsciiDoc fan, but like the docs I read on ReadTheDocs.org 
, which uses reStructuredText. 

So, got out ‘pandoc’ to convert the T Guide (English only) from DocBook  to 
RST, did a little scripting and here is the result:

https://gnucash-docs-rst.readthedocs.io/en/latest/index.html 


I’d say it’s appearance is a bit improved over the existing online docs.. :-)

I haven’t examined every chapter in detail, but I think this is pretty good for 
a first attempt at the conversion, which is 99% automated. The only thing done 
by hand is the intro page, which is ch_oview.rst with some markup for the table 
of contents. Speaking of which, the TOC for the Appendices isn’t done 
correctly, but should be straightforward to fix. I’m not 100% sure all the 
table formatting is correct.

One nice thing about using ReadTheDocs is that the book looks good on mobile. 
Give it a try.

Also, ReadTheDocs automatically generates PDF and EPUB versions. Click on the 
down arrow at the bottom near “v: latest” to pop up a menu to download these 
formats. They look pretty decent.

Comments welcome.

Rob


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

Re: [GNC-dev] Testing python

[Rob Gowin]

On Sun, Apr 19, 2020 at 2:19 PM Andy Goblins  wrote:

>I also tried skipping the virtual environment and just running
>"GNC_UNINSTALLED=1;GNC_BUILDDIR=dir>;PYTHONPATH=$GNC_BUILDDIR/lib/python3.8/site-packages:$GNC_BUILDDIR
>/lib/gnucash python" just like the cmake tests use, but I get the same
>result; it's not finding the libgncmod-backend stuff in
>build/lib/gnucash.
>

You almost had it. :-) The semicolons in the above command line make it
such that, for example, "GNC_UNINSTALLED=1" is its own (no-op) command that
does not affect the python command.

Try this in your virtual environment:

(gnucash-build) robg@kubuntu01:~/gnucash-build$ GNC_UNINSTALLED=1
GNC_BUILDDIR=`pwd` python3

Python 3.6.9 (default, Apr 18 2020, 01:56:04)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gnucash
* 23:52:18  WARN  no preferences backend loaded, or the
backend doesn't define register_cb, returning 0
* 23:52:18  WARN  no preferences backend loaded, or the
backend doesn't define register_cb, returning 0
* 23:52:18  WARN  no preferences backend loaded, or the
backend doesn't define register_cb, returning 0
* 23:52:18  WARN  no preferences backend loaded, or the
backend doesn't define register_cb, returning 0
* 23:52:18  WARN  no preferences backend loaded, or the
backend doesn't define register_cb, returning 0
>>> import gnucash.gnucash_core_c
>>> print(gnucash.gnucash_core_c.CREC)
c

I don't know what the deal with the preference backend stuff is, but maybe
it won't affect your testing.

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

Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)

[Rob Gowin]

On Mon, Aug 27, 2018 at 7:50 AM, Mike Evans  wrote:
>
> Hi Rob
>
> Referring to your mail of 2015-09-01 you "put the XSL file and a python
> script to run the conversion process in a repository at
> https://github.com/codesmythe/asciidoc-conversion.;
>
> This no longer exists, can you make it available again? Unless you'd
> rather not of course.
>
> Mike Evans
>

And by not-so-popular demand, that repository is back. :-)

I haven't touched that code since the 2015 discussion, but hopefully you
can some use out of it.

Regards,

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

Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)

[Rob Gowin]

On Thu, Aug 23, 2018 at 11:40 AM, John Ralls  wrote:

>
>
> So a new thought: One of the core devs use pandoc to convert the DocBook
> source to one of the markup/markdown variants, do the necessary manual
> fixups and commit the result. If we want DocBook for some reason the build
> process would use pandoc to generate it.
>
> If we had GitHub-flavored markdown sources then
> https://github.com/gnucash/gnucash-docs would show rendered documentation
> and one could use the "preview" button to check basic layout; it would
> appear pretty similar to how the document would look in a PDF or eBook
> rendering.
>
>
Hmmm. Old thought. :-) I did all of this in the 2015 thread that Geert
referenced. (Except I did not use pandoc, and used Asciidoc has my markup
variant of choice.) A rendered version of the Tutorial and Concept Guide
can be found here: https://github.com/codesmythe/gnucash-guide-asciidoc.
For example, click on 'en' then on ch_cbook.adoc to see a rendered version.
Then on that page click on the 'Raw' to see the Asciidoc source. I'd also
worked out the flow changes to generate PDF, eBook, etc from the Asciidoc
sources.

In
https://lists.gnucash.org/pipermail/gnucash-devel/2015-September/038997.html,
you asked for buy-in from the non-tech doc writers, and unfortunately, none
was found. :-(

One thing that has changed in the interim is the availability of decent
editors that have a live-preview mode that will show the raw Asciidoc on
the left and the live-rendered result on the right. For example, Visual
Studio Code (available for Mac, Linux, Windows) has an extension for this:
https://marketplace.visualstudio.com/items?itemName=joaompinto.asciidoctor-vscode
(see the demo gif), and VS Code supports Git out of the box.

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

Re: [GNC-dev] Compiling Gnucash on MacOS - not for the faint of heart...

[Rob Gowin]

On Mon, Jul 2, 2018 at 7:22 PM, chris graves  wrote:

>
>
> On Jul 1, 2018, at 8:39 PM, Rob Gowin  wrote:
>
>
>
> On Sun, Jul 1, 2018, 11:25 PM John Ralls  wrote:
>
>>
>>
>> > On Jul 1, 2018, at 7:39 PM, chris graves  wrote:
>> >
>> > Also, just curious, what IDE's gnucash developers use on MacOS.  It
>> appears that Xcode is not suitable.
>>
>> Last question first, bash and emacs. ISTR Mike Alexander uses vim and
>> emacs.
>>
>> Cmake *will* generate an Xcode project and I managed to get it to work
>> once, but for the most after ~35 years of emacs I just don’t find that
>> Xcode offers enough to make the time to switch.
>>
>
> The README_CMAKE.txt file (https://github.com/Gnucash/
> gnucash/blob/maint/cmake/README_CMAKE.txt) documents the details about
> how to use Xcode for GnuCash development (once all of the dependencies are
> built.)
>
> Rob
>
> Thanks for the comments Rob.  Yeah I figured to just take the path of
> least resistance.  Long time vi user, so guess we'll stick with that.
> Tried emacs once, but couldn't get my fingers to simultaneously press all
> the needed keys :-(
>
>
If you're going to stick with vi, why were you asking about IDEs? :-)


>   
>version="1.56.0"/>
> 
>   
>   
> 
>   
>
>
> I guessing one needs to run bootstrap.sh which may generate b2, but if so,
> not sure which args to provide bootstrap.sh
>

No arguments needed,  as per  https://wiki.gnucash.org/wiki/MacOSX/Quartz

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

Re: [GNC-dev] Compiling Gnucash on MacOS - not for the faint of heart...

[Rob Gowin]

On Sun, Jul 1, 2018, 11:25 PM John Ralls  wrote:

>
>
> > On Jul 1, 2018, at 7:39 PM, chris graves  wrote:
> >
> > Also, just curious, what IDE's gnucash developers use on MacOS.  It
> appears that Xcode is not suitable.
>
> Last question first, bash and emacs. ISTR Mike Alexander uses vim and
> emacs.
>
> Cmake *will* generate an Xcode project and I managed to get it to work
> once, but for the most after ~35 years of emacs I just don’t find that
> Xcode offers enough to make the time to switch.
>

The README_CMAKE.txt file (
https://github.com/Gnucash/gnucash/blob/maint/cmake/README_CMAKE.txt)
documents the details about how to use Xcode for GnuCash development (once
all of the dependencies are built.)

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

gnc_add_swig_guile_command compile errors

[Rob Gowin]

Hello Devs,

There have been a couple of folks who have run into errors when building
3.0 that complain about gnc_add_swig_guile_command (one report on IRC, one
on -user).

This will happen when the build directory is created inside the toplevel
source (gnucash) directory instead of as a sibling to it. When the build
directory is inside top-level gnucash, a reference to ../gnucash on a CMake
command line will pick up gnucash/gnucash/CMakeLists.txt. This in turn
loads gnucash/gnome/CMakeLists.txt which attempts the
gnc_add_swig_guile_command.

The solution is to make sure that the build directory is parallel to the
toplevel gnucash directory. This is a bit confusing because we have a
gnucash directory inside gnucash. The arrangement needs to be

build-cmake
gnucash
+ gnucash
+ libgnucash
+ 

[I'm not subscribed to -user; could someone please reply to DaveC49 with a
pointer to this message?]

Regards,

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

Re: Difficulty with apps-utils

[Rob Gowin]

Hi Aaron,

Since test-app-utils uses guile, you can't execute that test from the
build/bin directory without setting up the Guile environment. Look into
the Testing/Temporary/LastTest.log file to retreive the command
you need. For me, this command is

cmake "-E" "env" "GNC_BUILDDIR=$GNUCASH_BUILD" "GNC_UNINSTALLED=yes" \
  "GNC_BUILDDIR=$GNUCASH_BUILD" "GUILE_WARN_DEPRECATED=no" \
  "LD_LIBRARY_PATH=$GNUCASH_BUILD/lib:$GNUCASH_BUILD/lib/gnucash" \
  "GNC_MODULE_PATH=$GNUCASH_BUILD/lib:$GNUCASH_BUILD/lib/gnucash" \
  "GUILE=/usr/bin/guile"
"GUILE_LOAD_COMPILED_PATH=$GNUCASH_BUILD/lib/gnucash/scm/ccache/2.0" \

"GUILE_LOAD_PATH=$GNUCASH_SRC/libgnucash/app-utils/test/mod-foo:$GNUCASH_SRC/libgnucash/app-utils/test/mod-bar:$GNUCASH_SRC/libgnucash/app-utils/test/mod-baz"
\
  "$GNUCASH_BUILD/bin/test-app-utils"

where I have substituted $GNUCASH_BUILD and $GNUCASH_SRC for my
directory details.  But you can just cut-n-paste whatever command
is in LastTest.log to run the test.

When I clone and build your branch on Fedora 26 (gcc 7.1.1), I
get this message in my LastTest.log and when running the above
cmake command by hand:

Output:
--
/app-utils/option-util/Option DB Load: **
ERROR:/home/robg/gnucash/libgnucash/app-utils/test/test-option-util.cpp:98:void
test_option_load(Fixture*, gconstpointer): assertion failed
(gnc_option_db_lookup_string_option (odb, "Business", "Company Name",
FALSE) == "Bogus Company"): ("" == "Bogus Company")
Child aborted

I also get a segfault in test-engine after
gnc-budget_set_account_period_value()

What do you see in your Testing/Temporary/LastTest.log?

Regards,

Rob


On Tue, Nov 7, 2017 at 7:49 AM, Aaron Laws  wrote:

> I have made several changes on my branch to avoid kvp parsing keys. The
> last change I made removes the functions that take char*, but the unit test
> suite does not pass. All tests pass except app-utils which fails with the
> strange error:
>
> (./test-app-utils:6860): gnc.module-WARNING **: Could not locate module
> gnucash/app-utils interface v.0
>
> You can see my code at
>
> https://github.com/limitedatonement/gnucash/tree/fix_bayes
>
> Can anyone reproduce the problem? Any suggestions?
> ___
> 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: Compilation error using cmake, but no error using autotools

[Rob Gowin]

On Sep 9, 2017 10:37 AM, "Sumit Bhardwaj"  wrote:

Hi,

After pulling master, I decided to do a cmake build instead of the usual
autotools. Ran into problems as detailed below. Autotools work smoothly. I
would try to make more headway, but I don't understand scheme and a quick
stack overflow search didn't show anything that I could try either.

Thanks,
Sumit

Fedora 26
guile version: 2.0.14

Command:
cmake -D WITH_AQBANKING=OFF -D WITH_OFX=OFF -G Ninja ../gnucash/ && ninja
check && ninja install

Error message:
[984/1000] Generating
../../../lib/gnucash/scm/ccache/2.0/gnucash/report/invoice.go
FAILED: lib/gnucash/scm/ccache/2.0/gnucash/report/invoice.go
cd /home/bhardwajs/ac/devel/build_gnucash/gnucash/report/business-reports
&& /usr/bin/cmake -E env
LD_LIBRARY_PATH=/home/bhardwajs/ac/devel/build_gnucash/lib:/home/bhardwajs/
ac/devel/build_gnucash/lib/gnucash:
GNC_UNINSTALLED=YES GNC_BUILDDIR=/home/bhardwajs/ac/devel/build_gnucash
GUILE_LOAD_PATH=/home/bhardwajs/ac/devel/gnucash/gnucash/report/business-
reports:/home/bhardwajs/ac/devel/build_gnucash/share/gnucash/scm
GUILE_LOAD_COMPILED_PATH=/home/bhardwajs/ac/devel/build_
gnucash/lib/gnucash/scm/ccache/2.0
GNC_MODULE_PATH=/home/bhardwajs/ac/devel/build_gnucash/lib:/home/bhardwajs/
ac/devel/build_gnucash/lib/gnucash:
/usr/bin/guile -e '(@@ (guild) main)' -s /usr/bin/guild compile -o
/home/bhardwajs/ac/devel/build_gnucash/lib/gnucash/scm/
ccache/2.0/gnucash/report/invoice.go
/home/bhardwajs/ac/devel/gnucash/gnucash/report/business-reports/invoice.scm
Backtrace:
In system/base/target.scm:
  59: 19 [with-target "x86_64-redhat-linux-gnu" ...]
In system/base/compile.scm:
 152: 18 [compile-file
"/home/bhardwajs/ac/devel/gnucash/gnucash/report/
business-reports/invoice.scm"
...]
  43: 17 [call-once #]
In ice-9/boot-9.scm:
 174: 16 [with-throw-handler #t ...]
In system/base/compile.scm:
  59: 15 [#]
 155: 14 [#
#]
 218: 13 [read-and-compile # #:from ...]
 234: 12 [lp (# # # # ...) # #]
 182: 11 [lp (#) (use-modules #) ...]
In ice-9/boot-9.scm:
2412: 10 [save-module-excursion #]
In language/scheme/compile-tree-il.scm:
  31: 9 [#]
In ice-9/psyntax.scm:
1107: 8 [expand-top-sequence ((use-modules #)) () ((top)) ...]
 990: 7 [scan ((use-modules (gnucash report standard-reports))) () ...]
 279: 6 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...]
In ice-9/boot-9.scm:
3622: 5 [process-use-modules (((gnucash report standard-reports)))]
 712: 4 [map # ((#))]
3623: 3 [#
(#)]
2903: 2 [resolve-interface (gnucash report standard-reports) #:select ...]
In unknown file:
   ?: 1 [scm-error misc-error #f ...]
In ice-9/boot-9.scm:
 109: 0 [# misc-error ...]

ice-9/boot-9.scm:109:20: In procedure #:
ice-9/boot-9.scm:109:20: no code for module (gnucash report
standard-reports)
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Hi Simit,

There are scheme dependency issues with CMake when you do 'ninja check'
without first running plain 'ninja' first. So as a workaround until I can
fix, do 'ninja && ninja check && ninja install'.

Regards,

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

Re: Master Build problem

[Rob Gowin]

There needs to be a one character fix in cmake/CMakeLists.txt to change an
underscore to a dash. Could a committer please make this change for me (in
maint, then merge to master)? Or I could do a PR if necessary.

Thanks,

Rob

diff --git a/cmake/CMakeLists.txt b/cmake/CMakeLists.txt
index 9e1e2cbed..a8651da48 100644
--- a/cmake/CMakeLists.txt
+++ b/cmake/CMakeLists.txt
@@ -19,7 +19,7 @@ SET(schema-targets business-gnome-gschema csv-exp-gschema
csv-imp-gschema
 generic-import-gschema gnome-gschema gnome-utils-gschema ofx-gschema
qif-imp-gschema)

 IF (WITH_AQBANKING)
-  LIST(APPEND schema_targets aqb-gschema)
+  LIST(APPEND schema-targets aqb-gschema)
 ENDIF (WITH_AQBANKING)

 SET(SCHEMA_DIRECTORY ${DATADIR_BUILD}/glib-2.0/schemas)


On Sun, Jul 16, 2017 at 4:30 PM, John Ralls  wrote:

>
> > On Jul 16, 2017, at 8:42 AM, Geert Janssens 
> wrote:
> >
> > That is the same error I was having last week when building with
> aqbanking.
> >
> > John recently made building with aqbanking the default. But clearly
> there is something missing for it.
> >
> > Until this is fixed you can disable building with aqbanking by setting
> an option to cmake
> >
> > Regards
> >
> > Geert
> >
> > Robert Fewell <14ubo...@gmail.com> schreef op 16 juli 2017 13:27:31
> CEST:
> >> I having trouble with the latest master, it will not build for the
> >> following reason...
> >>
> >> I the build directory _build/src/import-export/aqb/gschemas there
> >> should be
> >> three gschema files but they are missing. One file is in the source
> >> directory and I think the other two are created but I can not see why
> >> they
> >> are not.
> >> I assume there is some cmake stuff that is missing but can not see it
> >> at
> >> the moment.
>
> Yeah, I don't see the problem either after staring at it for a bit. The
> cmake option to bypass it is -DWITH_AQBANKING=No .
>
> Regards,
> John Ralls
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: dist target differences between cmake and autotools

[Rob Gowin]

On Wed, Jul 12, 2017 at 7:27 AM, Geert Janssens 
wrote:

> On zondag 9 juli 2017 22:56:57 CEST John Ralls wrote:
> > > On Jul 9, 2017, at 1:17 PM, Geert Janssens  >
> > > wrote:
> > >
> > > Hi,
> > >
> > > I have tested the dist target in both cmake and autotools. I couldn't
> test
> > > the autotools dist generated by cmake because my autotools is too
> recent.
> > > So I have one tarball purely cmake and one tarball purely autotools.
> > >
> > > There are a few missed files that should be fixed on both sides I
> believe.
> > > Those are easy to fix by comparing a diff of the tarball content lists.
> > >
> > > The more interesting issue is though that the autotools based dist
> tarball
> > > doesn't contain a single CMakeLists.txt or the related cmake support
> > > files.
> > > And the other way around the cmake tarball doesn't contain the
> Makefile.in
> > > files (it does include Makefile.am) and the typical autotools related
> > > support files.
> > >
> > > Perhaps the latter is because of the autotools-too-recent issue I
> > > mentioned at the start.
> > >
> > > I wonder though what our eventual goal is: should the dist tarball
> support
> > > both cmake and autotools ?
> > >
> > > Or put differently should the tarballs being output by the different
> > > toolchains be identical and interchangeable ?
> > >
> > > Or is it time to make a definitive choice of build system ?
> > >
> > > I worry that if both toolchains generate dist tarballs that are not the
> > > same we will get mixups at some point and confusion as a result.
> > >
> > > Regards,
> > >
> > > Geert
> > >
> > > P.S. I have attached the contents of the two tarballs I have created
> with
> > > today's master for comparison.
> >
> > I don't think it's because your autotools are "too recent", I think it's
> > because there are some problems with running the autotools part of cmake
> > distcheck on master. That step is required for creating the
> Makefile.in-s.
> >
> This has me confused.
>
> Shouldn't distcheck start with running "dist" to generate the tarball
> which is then unpacked and
> used as source for a "check" run ?
>
> If so and assuming we agree on supporting two build systems, I would
> conclude the dist step in
> a cmake environment should already include the Makefile.in files in the
> tarball, because those
> are also included when running make dist via autotools. There are a few
> other files generated
> during autogen.sh that are also shipped in the autotools generated dist
> tarball. To keep the
> discussion focussed I'm not going to mention all of them, but obviously
> they should get the
> same treatment.
>
> When I run dist after configuring my environment using cmake with default
> options and the
> ninja build system I get this error:
> $ ninja-build dist
>
> The only way for me to have a cmake/ninja based environment generate a
> dist tarball is to
> configure using cmake -DAUTOTOOLS_IN_DIST=OFF
>
> So that's why I said "my automake is too recent" and I can't get a dist
> tarball including the
> autotools related generated files.
>
> Am I missing something here ?
>
> Geert
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>

Hi Geert,

For any version of automake except 1.15, the CMake 'dist' target will run
autogen.sh to create the various Makefile.in-s and include them in the dist
tarball. Independent of anything CMake related, autotools distcheck will
fail on systems using automake-1.15 (including Fedora 25) because in that
version the distcheck working directory has been changed  ([1], near
bottom) such that the missing files check in 'po' gets confused and fails.

In my original CMake distcheck commit, I had the autotools part do
'distcheck'.  I put in checks to prevent running the autotools distcheck if
automake-1.15 was detected. John mentioned in IRC that I did not need to
run distcheck, so I removed it in the second commit in the PR. I should
have then removed the automake version check at that point since it is no
longer need. I'll do that soon.

Regards,

Rob

[1] https://autotools.io/forwardporting/automake.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building with CMake

[Rob Gowin]

On Sun, Jun 4, 2017 at 12:34 AM, DaveC49  wrote:

>  Hi further progress
> I ran cmake with the --trace option ( *cmake --trace -D
> CMAKE_INSTALL_PREFIX=/opt/gnucash-devel ../gnucash*). It appears that
> cmake
> is executing the call to add the libqof directory
> .../gnucash/src/CMakeLists.txt  line 141 and the qof/test subdirectory
> .../gnucash/src/libqof/CMakeLists.txt(3) without ever having called the
> INCLUDE (GncAddTest) at line 48 of .../gnucash/CMakeLists.txt.
> In the resultant trace output cmake in fact never seems to enter
> .../gnucash/CMakeLists.txt as the trace starts with
> .../gnucash/src/CMakeLists.txt(0):  PROJECT(Project )  and does not appear
> to be executing .../gnucash/CMakeLists.txt at all or if it is is executing
> it silently.
>
> I have deleted the cach files .../gnucash/CMakeFiles and rerun the above
> command but still get the same error and trace output
>
> If I execute *cmake --trace -D CMAKE_INSTALL_PREFIX=/opt/gnucash-devel
> ../gnucash/CmakeLists.txt*
> I obtain
> *cmake: /usr/local/lib/libcurl.so.4: no version information available
> (required by cmake)
> Running with trace output on.
> CMake Error: The source ".../gnucash/CMakeLists.txt" does not match the
> source ".../gnucash/src/CMakeLists.txt" used to generate cache.  Re-run
> cmake with a different source directory.*
>  I confess to being totally confused as to why cmake is not executing
> .../gnucash/CmakeLists.txt
>
> The trace output can be accessed using this link to a folder in my dropbox
> https://www.dropbox.com/sh/chibk4l66mz1esp/AADDP0EV9pmHjwpUHeow_zkra?dl=0
>
> Thanks for any help anyone can offer
>
> David Cousens


 Hi David,

Do you have CMake cache files in
/home/david/Documents/SoftwareDevelopment/GnucashDevelopment/sources/gnucash/src?
I think you do. If so, you need to remove them.

>From what I can tell, you haven't created a separate CMake build directory,
which you should. I usually use 'gnucash-build' that lives in the same
directory as gnucash (so in the 'sources' directory for you). Other folks
will create a 'build' directory in the gnucash source directory and use
that.

Run these commands to do a clean clone and build in a /tmp directory. If
these work, you might want to remove your .../sources/gnucash directory and
start over. Also, you should consider building with ninja for faster build
times (CMake generates a build using 'make' by default).

Commands: (assumes bash)

$ rm -rf /tmp/gcdev
$ mkdir /tmp/gcdev
$ cd /tmp/gcdev
$ git clone https://github.com/Gnucash/gnucash.git
$ mkdir gnucash-build
$ cd gnucash-build
# For ninja, add '-G Ninja' to cmake command below before '../gnucash'
# Also, make sure /opt/gnucash-devel is user-writable
$ cmake -D CMAKE_INSTALL_PREFIX=/opt/gnucash-devel ../gnucash
$ make -j 4 && TZ=America/Los_Angeles make -j 4 check && make install
# or: ninja && TZ=America/Los_Angeles ninja check && ninja install

Let me know how it goes.

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

Re: Building with CMake

[Rob Gowin]

On Thu, Jun 1, 2017 at 2:19 AM, DaveC49  wrote:

> Hi,
> I am getting an error as follows while building a branch from the master
> for
> gnucash to implement links to documents in invoices/bills/creditNotes etc.
>
> $ cmake -D CMAKE_INSTALL_PREFIX=/opt/gnucash-devel ../gnucash
> CMake Error at libqof/qof/test/CMakeLists.txt:44 (GNC_ADD_TEST):
>   Unknown CMake command "GNC_ADD_TEST".
>
>
> -- Configuring incomplete, errors occurred!
>
> I am presuming that GNC_ADD_TEST is a macro but cannot find where it is
> defined or if it is defined.  Is anyone able to enlighten me as to where I
> can or should find it and what the macro is
>
> Thanks
>
> David Cousens
>

Hi David,

The GNC_ADD_TEST function is defined in src/cmake_modules/GncAddTest.cmake.
See here:
https://github.com/Gnucash/gnucash/blob/master/src/cmake_modules/GncAddTest.cmake#L40


Perhaps you only have a partial checkout of the branch? What version of
CMake are you using (cmake -version) and on what platform? For what it's
worth, I just checked that master builds on Ubuntu 16.04 without error.

Regards,

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

Re: Compiling on Fedora25

[Rob Gowin]

On Sat, Apr 15, 2017 at 3:24 AM, Mike Evans  wrote:

>
> Compiling using cmake I get a different error messages:
>
> In file included from /usr/include/sys/types.h:25:0,
>  from /home/mikee/Projects/gnucash/
> src/libqof/qof/md5.c:27:
> /usr/include/features.h:331:4: error: #warning _FORTIFY_SOURCE requires
> compiling with optimization (-O) [-Werror=cpp]
>  #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
> ^~~
>
> Any thoughts?
>
> Regards Mike E
>

Hi Mike,

Looks like I need to backport this commit on master to maint:
https://github.com/Gnucash/gnucash/commit/992f3232ee90cfcf6484a0fdb4cf506168676a40

In the meantime as a workaround, on line 419 of the top level
CMakeLists.txt file, you can change -D_FORTIFY_SOURCE=2 to
-U_FORTIFY_SOURCE.to continue.

Regards,

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

Re: compile errors

[Rob Gowin]

On Sat, Nov 19, 2016 at 6:18 PM, John Ralls <jra...@ceridwen.us> wrote:

>
> > On Nov 19, 2016, at 11:14 AM, Rob Gowin <r...@gowin.net> wrote:
> >
> > On Sat, Nov 19, 2016 at 12:26 PM, Alex Aycinena <alex.aycin...@gmail.com
> >
> > wrote:
> >
> >> On Sat, Nov 19, 2016 at 10:09 AM, John Ralls <jra...@ceridwen.us>
> wrote:
> >>
> >>>
> >>>> On Nov 19, 2016, at 9:34 AM, Alex Aycinena <alex.aycin...@gmail.com>
> >>> wrote:
> >>
> >>>>
> >>>> Don't know if you already knew that.
> >>>
> >>> Alex,
> >>>
> >>> Nope, didn't know that because it passes on Travis and all of my VMs
> >>> including Fedora-24, so ISTM you have a local problem.
> >>>
> >>> A clue is that the error about the error about xaccSplitEqualCheckBal
> >>> isn't issued until line 967, yet the test reports that it's failing at
> >> line
> >>> 948.
> >>>
> >>> Regards,
> >>> John Ralls
> >>>
> >>>
> >>> John,
> >>
> >> I think I got the error because I had done a git pull followed by a make
> >> and make check without redoing autogen, clearing out the build directory
> >> and rerunning configure. My mistake. When I did it that way, it all
> >> workied.
> >>
> >> Thanks,
> >>
> >> Alex
> >>
> >>
> >
> > [ Alex, I originally forgot to reply-all, so you'll see this twice. ]
> >
> > For what it's worth, I am able to reproduce this failure in test-engine
> on
> > Ubuntu 16.04.4, g++ 5.4.0. I started looking into why the test did not
> fail
> > in the CMake build environment. It seems to be an intermittent failure
> for
> > me.  It only happens when running under the gtester program, with both
> > MALLOC_CHECK_ and MALLOC_PERTURB_ set. After Alex's most recent comment,
> I
> > did a new clone, autogen.sh, configure, make and make check, and am able
> to
> > see the failure.
> >
> > The CMake test environment does not use gtester, nor does it set the
> > MALLOC* environment variables. I suppose it should.
> >
> >
> > I ran this script in src/test/engine to run test-engine 500 times and it
> > always fails at some point:
> >
> > #!/bin/bash
> >
> > for run in {1..500}; do
> >   MALLOC_CHECK_=2 MALLOC_PERTURB_=$((${RANDOM:-256} % 256)) gtester
> > --verbose test-engine
> >   if [ $? -ne 0 ]; then
> >   echo '** FAIL **'
> >   exit 1
> >   fi
> > done
> > echo '** PASS **'
> > exit 0
>
>
> Hmm. I ran your script 5 times (so 2500 total runs of test-engine) on my
> Fedora 24 VM and it passed every time.
>
> Does the machine/VM that you tested on have an installed GnuCash? If so,
> are you absolutely certain that the test build can't link the installed
> libraries?
>
> Regards,
> John Ralls
>

I'm using a machine (non-VM) that does not have GnuCash installed. However,
I built a clean Ubuntu 16.04 VM and I can't get it to fail in 2500 runs
either. Probably is something local to my box.

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

Re: compile errors

[Rob Gowin]

On Sat, Nov 19, 2016 at 12:26 PM, Alex Aycinena 
wrote:

> On Sat, Nov 19, 2016 at 10:09 AM, John Ralls  wrote:
>
> >
> > > On Nov 19, 2016, at 9:34 AM, Alex Aycinena 
> > wrote:
>
> > >
> > > Don't know if you already knew that.
> >
> > Alex,
> >
> > Nope, didn't know that because it passes on Travis and all of my VMs
> > including Fedora-24, so ISTM you have a local problem.
> >
> > A clue is that the error about the error about xaccSplitEqualCheckBal
> > isn't issued until line 967, yet the test reports that it's failing at
> line
> > 948.
> >
> > Regards,
> > John Ralls
> >
> >
> > John,
>
> I think I got the error because I had done a git pull followed by a make
> and make check without redoing autogen, clearing out the build directory
> and rerunning configure. My mistake. When I did it that way, it all
> workied.
>
> Thanks,
>
> Alex
>
>

[ Alex, I originally forgot to reply-all, so you'll see this twice. ]

For what it's worth, I am able to reproduce this failure in test-engine on
Ubuntu 16.04.4, g++ 5.4.0. I started looking into why the test did not fail
in the CMake build environment. It seems to be an intermittent failure for
me.  It only happens when running under the gtester program, with both
MALLOC_CHECK_ and MALLOC_PERTURB_ set. After Alex's most recent comment, I
did a new clone, autogen.sh, configure, make and make check, and am able to
see the failure.

The CMake test environment does not use gtester, nor does it set the
MALLOC* environment variables. I suppose it should.


I ran this script in src/test/engine to run test-engine 500 times and it
always fails at some point:

#!/bin/bash

for run in {1..500}; do
   MALLOC_CHECK_=2 MALLOC_PERTURB_=$((${RANDOM:-256} % 256)) gtester
--verbose test-engine
   if [ $? -ne 0 ]; then
   echo '** FAIL **'
   exit 1
   fi
done
echo '** PASS **'
exit 0
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Still Failing: Gnucash/gnucash#778 (master - 1774de7)

[Rob Gowin]

Hi John,

Yeah, I'll do that.

Regards,

Rob

On Thu, Nov 17, 2016 at 9:58 PM, John Ralls  wrote:

> Hey Rob,
>
> This failed because I forgot to update POTFILES for the newly created
> files and ninja check didn't catch it. Can you teach CMake to generate
> intltool checks?
>
> Regards,
> John Ralls
>
> Begin forwarded message:
>
> *From: *Travis CI 
> *Subject: **Still Failing: Gnucash/gnucash#778 (master - 1774de7)*
> *Date: *November 17, 2016 at 5:21:09 PM PST
> *To: *
>
> *Gnucash / gnucash * (master
> )
> Build #778 is still failing.
> 
> 10 minutes and 41 seconds
> *John Ralls* 1774de7
> 
>  Changeset
> → 
>   Fix Travis build errors.
>
> *Want to know about upcoming build environment updates?*
>
> Would you like to stay up-to-date with the upcoming Travis CI build
> environment updates? We set up a mailing list for you! Sign up here
> .
> Documentation  about Travis CI
> Need help? Mail support !
> Choose who receives these build notification emails in your configuration
> file .
>
> *Would you like to test your private code?*
>
> Travis CI for Private Projects
> 
> could be your new best friend!
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Compile on Windows with Python Bindings

[Rob Gowin]

On Wed, Oct 12, 2016 at 3:21 PM, Adam  wrote:

>
> * 21:17:31 OTHER  No GSettings schemas are installed on the
> system
>
> Any thoughts on where I might be going wrong? Is trying to compile with
> Python bindings a lost cause?


Hi Adam,

I don't have anything to offer on your first two items, but for the third,
try copying the python binary to C:\GCDev\gnucash\inst\bin as a workaround.
Then launch python from c:\gcdev\gnucash\inst as 'bin\python.exe'. For me
(using CMake though), this avoids the GSettings message and gets me a
python prompt with the module loaded.

Gnucash needs to load the file inst\etc\gnucash\environment to find things
like GSettings schemas, and it tries to find that file relative to where
the binary is (or is run from?). So copying the python executable to the
inst\bin directory allows it to find the necessary files.

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

Re: Windows Nightly Builds

[Rob Gowin]

On Thu, Apr 28, 2016 at 9:38 AM, Robert Fewell <14ubo...@gmail.com> wrote:

> If I do my own build and run it from the inst directory, it works as normal
> with out any error messages.
> If I create my own setup.exe by using dist.sh and install that it runs as
> usual with no errors on start up.
>

Are you doing your own builds with autotools or CMake?

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

Re: Windows Nightly Builds

[Rob Gowin]

Hi Robert,

I think the libgnc-gnome issue is caused by the fact that the current
nightly package has a jumble of autotools- and cmake-created DLLs. I've
created a PR to fix this and another issue in the build scripts at
https://github.com/Gnucash/gnucash-on-windows/pull/8

I don't know anything about the second issue.

Rob

On Fri, Apr 22, 2016 at 11:11 AM, Robert Fewell <14ubo...@gmail.com> wrote:

> OK, the build was created last night and I have downloaded and installed
> on my XP VM but fails to start properly, console output below...
>
> Report bugs and other problems to gnucash-devel@gnucash.org
> You can also lookup and file bug reports at http://bugzilla.gnome.org
> To find the last stable version, please refer to http://www.gnucash.org
> 3:2016/04/22 16-23-56:gwen(3076):i18n.c:  120: No translation found for
> WIN32 locale [English_United Kingdom.1252]
> Backtrace:
> In unknown file:
>?: 15  [try-load-module (gnucash import-export qif-import)]
>?: 16  (or (begin (try-module-linked name)) (try-module-autoload name)
> ...)
>?: 17* [try-module-autoload (gnucash import-export qif-import)]
>?: 18  (let* (# # # #) (resolve-module dir-hint-module-name #f) (and #
> #))
> ...
>?: 19  (letrec ((load-file #)) (dynamic-wind (lambda () #) (lambda ()
> #) ...) ...)
>?: 20* [dynamic-wind # # # #f ()>]
>?: 21* [#]
>?: 22* (let* ((file #)) (cond (# => #) (# => #)))
>?: 23  [# "C:\\Program
> Files\\gnucash\\share\\gnucash/scm/gnucash/import-export/qif-import.scm"]
>?: 24  [with-fluid* # #f #]
>?: 25* [#]
>?: 26* [load-file # ...]
>?: 27* [save-module-excursion #]
>?: 28  (let (# #) (dynamic-wind # thunk #))
>?: 29  [dynamic-wind # # # #f ()>]
>?: 30* [#]
>?: 31* [primitive-load "C:\\Program
> Files\\gnucash\\share\\gnucash/scm/gnucash/import-export/qif-import.scm"]
> In C:\Program
> Files\gnucash\share\gnucash/scm/gnucash/import-export/qif-import.scm:
>   32: 32* (cond-expand (guile-2 #) (else #))
>   32: 33  (begin (load-extension "libgnc-gnome"
> "scm_init_sw_gnome_module"))
>   38: 34  [load-extension "libgnc-gnome" "scm_init_sw_gnome_module"]
>
> C:\Program
> Files\gnucash\share\gnucash/scm/gnucash/import-export/qif-import.scm:38:5:
> In procedure dynamic-link in expre
> ssion (load-extension "libgnc-gnome" "scm_init_sw_gnome_module"):
> C:\Program
> Files\gnucash\share\gnucash/scm/gnucash/import-export/qif-import.scm:38:5:
> file: "libgnc-gnome", message: "Th
> e specified procedure could not be found."
>
> C:\Program Files\gnucash\bin>
>
>
> I also tried to load and run on my recent Windows 10 machine with the
> following slightly different output...
>
> 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
> To find the last stable version, please refer to http://www.gnucash.org
> 3:2016/04/22 15-52-52:gwen(5520):i18n.c:  120: No translation found for
> WIN32 locale [English_United Kingdom.1252]
> terminate called after throwing an instance of 'std::out_of_range'
>   what():  Year 1970 isn't covered by this time zone.
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
>
> Not really sure what is wrong,
>
>
> Robert
>
> On 21 April 2016 at 15:09, Geert Janssens <geert.gnuc...@kobaltwit.be>
> wrote:
>
>> On Thursday 21 April 2016 08:46:02 Rob Gowin wrote:
>>
>> > Hi Robert,
>>
>> >
>>
>> > This is due to an error in a CMakeLists.txt file. (Nightly builds of
>>
>> > master on Windows use CMake.) I have submitted PR #78 to fix.
>>
>> >
>>
>> > Rob
>>
>> >
>>
>> And I have just merged the PR. Thanks a lot!
>>
>>
>>
>> Geert
>>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Nightly Builds

[Rob Gowin]

Hi Robert,

This is due to an error in a CMakeLists.txt file. (Nightly builds of master
on Windows use CMake.) I have submitted PR #78 to fix.

Rob

On Thu, Apr 21, 2016 at 8:06 AM, Robert Fewell <14ubo...@gmail.com> wrote:

> Hi,
>
> There does not seem to be any recent nightly builds, the last one in the
> list is 2016-01-10.
>
> The reason I am asking is that I just installed Windows 10 on a spare drive
> and tried to build master which it did, but does not run so wanted to prove
> with a nightly build.
>
> Normal release works OK.
>
> Could some one see why and possibly give it kick!!
>
> Robert
> ___
> 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: dlopen error with newly introduced (but still unused) c++ class

[Rob Gowin]

Geert,

The reason you are not seeing these errors at link time is because, as
Derek hinted at, when you link a shared object, the link step is only
checking that the object files in the shared object are internally
consistent. It will not check that any external symbols that are used are
actually available.

Without the extern "C" you will encounter runtime crashes in the CSV
importer when you try to access a function that your code thinks is C++,
but the core thinks is C. This will be similar to the runtime errors you
ran into a couple of months ago (
http://lists.gnucash.org/pipermail/gnucash-devel/2015-December/039239.html)
that I fixed with a PR to handle some extern "C" issues.

For example, consider the "xaccParseAmount" function used by
gnc-csv-imp-trans.o. Using the 'nm' tool, we can poke around and see the
link symbols used for this function, which is defined in app-utils. If you
run 'nm' (on Fedora 23) on src/app-utils/.libs/gnc-ui-utils.o you'll see

 $ cd gnucash/src/app-utils/.libs
 $ nm  gnc-ui-util.o | grep xaccParse
   3030 T xaccParseAmount
   2760 T xaccParseAmountExtended

The 'T' stands for "text' and means the function is defined in this object
file.

If you do the same thing for an object file in the csv-importer that does
not have the extern "C", you'll see that the function names are mangled
(where 'U' means undefined):

  $ cd gnucash/src/import-export/csv-imp/.libs
  $ nm gnc-csv-imp-trans.o | grep xaccParse
U _Z15xaccParseAmountPKciP12_gnc_numericPPc
U _Z23xaccParseAmountExtendedPKcijjjS0_S0_P12_gnc_numericPPc

The 'nm' command has a handy argument '-C' that will demangle the name:

  $ nm -C gnc-csv-imp-trans.o | grep xaccParse
 U xaccParseAmount(char const*, int, _gnc_numeric*, char**)
 U xaccParseAmountExtended(char const*, int, unsigned int, unsigned
int, unsigned int, char const*, char const*, _gnc_numeric*, char**)

To resolved overloaded functions, C++ needs to encode the types of the
function parameters in the function name, which is what all of the extra
symbols in the C++ names are doing.

After adding extern "C", the undefined symbols now have "C" linkage, are
not mangled, and will be matched with the functions in app-utils.

  $ nm gnc-csv-imp-trans.o | grep xaccParse
 U xaccParseAmount
 U xaccParseAmountExtended

--

The reason you don't see the kinds of errors until runtime is because when
GnuCash does the dlopen(), it does it lazily. The code is in gnc-module.c:

  303 /*   g_debug("(init) dlopening '%s'\n", fullpath); */
  304 gmodule = g_module_open(fullpath, G_MODULE_BIND_LAZY);
  305 if (gmodule == NULL)
  306 {
  307 g_warning("Failed to dlopen() '%s': %s\n", fullpath,
g_module_error());
  308 return NULL;
  309 }

This means that any symbols in your library, like the inadvertent C++
symbols because of missing extern "C", are not resolved (looked up) until
the point they are actually needed. If the symbols are not found, you will
get a runtime crash. While you are developing your csv-imp module it might
be a good idea to change "G_MODULE_BIND_LAZY" on line 304 to 0, and change
line 308 to exit() so that GnuCash attempts to resolve symbols right away
(when the shared object is loaded) and exit if any are missing. (But don't
check those changes in.)

Or not. It seems on the Mac that symbols for shared objects are fully
resolved at link time (this is how I noticed the missing extern "C" on
IRC). So when I eventually get your new code running on CMake on the Mac,
I'll come hunt you down when things don't link. :-)

Regards,

Rob
(codesmythe on IRC)





On Sun, Jan 31, 2016 at 1:09 AM, Geert Janssens 
wrote:

> On Saturday 30 January 2016 08:33:56 John Ralls wrote:
> > > On Jan 30, 2016, at 6:04 AM, Geert Janssens
> > >  wrote:
> > > When running gnucash in this setup, I get this warning:
> > >
> > > WARN  Failed to dlopen()
> > > '/home/janssege/Lokaal/installs/gnucash/master/lib/gnucash/libgncmo
> > >
>
> > I'm a bit puzzled about how exactly the C++ bits are integrated with
> > the rest of the importer, but I think your problem is that you're
> > including C-linkage headers into C++ without declaring them as such.
> > For example in gnc-csv-imp-trans.hpp, you have
> >
> > #include "config.h"
> > #include "Account.h"
> > #include "Transaction.h"
> > #include 
> > #include 
> >
> > it needs to be
> >
> > extern "C"
> > {
> > #include "config.h"
> > #include "Account.h"
> > #include "Transaction.h"
> > }
> > #include 
> > #include 
> >
> > to tell the compiler to use unmangled names for the symbols from those
> > headers. That lack of mangling is called C linkage. You need to do
> > that in both headers and implementations. If a header will be
> > included in a C file, wrap the 'extern "C" {' and closing } with
> > #ifdef __cplusplus … #endif so that the C compiler doesn't see it.
> >
> > Any C++ 

Re: Runtime issues with current master

[Rob Gowin]

Hi Geert,

Issue 2 is resolved by this pull request:
https://github.com/Gnucash/gnucash/pull/46

Rob
I have done a fresh rebuild of master as of this morning (commit
b3cfef70842). While running it I got the following errors:

1. It will run, but segfaults when quitting the application. See
attached backtrace.

2. I tried to create a new file. The assistant completes successfully,
however it crashes while saving with this error:

./bin/gnucash: symbol lookup error:
/kobaltnet/janssege/Development/installs/gnucash/master/lib/gnucash/libgncmod-
backend-xml.so: undefined symbol:
_Z34gnc_prefs_get_file_save_compressedv

The command was run from
/kobaltnet/janssege/Development/installs/gnucash/master which is where
my fresh build got installed.

Regards,

Geert
___
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: Using AsciiDoc for Documentation

[Rob Gowin]

> On Sep 1, 2015, at 4:56 AM, Mike Evans  wrote:
>> [snip]
> 
> Hi Rob
> 
> Looks good to me. Still a few minor bugs with the Asciidoc.  
> 
> Some of the Figure titles are missing
> Second level bullet indents missing
> 
> But these are minor and some tweaking of the XSL should fix that.  Speaking 
> of which, I notice the XSL isn't in github can you make that available 
> somewhere so others can chip in with help? I'd also like to generate the 
> Asciidoc locally so I can ensure both formats are from the same source for 
> comparison purposes.
> 
> Now you (we) have to convince others to use Asciidoc!
> 
> I use Geany for my coding/writing and there is a Markdown plugin for preview, 
> no Asciidoc at the moment though.  I'm looking at the PEG code to see how 
> difficult it would be to produce an Asciidoc previewer plugin.  It may be 
> beyond my learning tolerance though.
> 
> Mike E
> 
> 
> 
> -- 
> PGP key:
> http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53  


Hi Mike,

Thanks for taking a look. I have put the XSL file and a python
script to run the conversion process in a repository at 
https://github.com/codesmythe/asciidoc-conversion. See the README
there for details.

As for editors, I just use a command line converter and then
reload the generated HTML into a browser. I need to try some of the
live preview editors mentioned in the link you sent out yesterday.

I'll look at the issues you mentioned in the next couple of days.

Thanks,

Rob




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

Using AsciiDoc for Documentation

[Rob Gowin]

[Hello List. Long time GnuCash user, -devel list lurker,
 coming out of the shadows.]

 On Aug 29, 2015, at 5:43 AM, Mike Evans mi...@saxicola.co.uk wrote:
 Another random thought then.

 I use asciidoc for pretty much all the docs I write, not much
 admittedly but it's easy to learn and can produce many output formats.
 I just used https://github.com/oreillymedia/docbook2asciidoc to
 convert the guide to asciidoc using:

 $ java -jar /home/mikee/Projects/docbook2asciidoc/saxon9he.jar
 -s gnucash-guide.xml -o gnucash-guide.asc
 /home/mikee/Projects/docbook2asciidoc/d2a.xsl  chunk-output=true

 This produces an asccidoc file for each chapter plus the master page.

 [...]

 I'm not an expert on XML parsing using .xsl stylesheets but I suspect
 this could be easily(?) remedied by editing the d2a.xsl to correctly
 include the figures[...]

I am also a fan of using AsciiDoc as a documentation format. A
while back I did some of the XSL hacking Mike refers to that is needed
to get a decent conversion from the existing DocBook files. It's to
the point where I would like to get some feedback.

I've done a first-pass conversion of the English version of the T  CG to
AsciiDoc at https://github.com/codesmythe/gnucash-docs/tree/asciidoc/guide/C
.
You can click on the *.asc files there like ch_oview.asc to see GitHub's
rendered verison of the file, including non-SVG images. (Note that SVG files
and inter-chapter links don't work on GitHub's render.) You can click on the
'Raw' button for a file to see the AsciiDoc source. The source needs  clean
up
(lines too long, etc), but it is clean enough for folks to get an idea of
the
syntax. The GitHub web interace is useful because I think small edits could
be
done and sent as pull requests all from the web.

Like Mike said, the AsciiDoc tools (asciidoctor, at http://asciidoctor.org
in
this case) support the generation of DocBook XML files, so it's relatively
simple to insert AsciiDoc support into the  current document generation
flow.
The asciidoctor tool generates DocBook output, and the existing flow for
generating PDFs, HTML, EPUB, MOBI etc. works the same. My branch has the
changes to the various Makefile.am files to support this. Those interested
should be able to clone the repo, switch to the asciidoc branch and then
'make
pdf' as usual. Note that the 'configure' script will expect to find the
asciidoctor program on the system. I think the generated PDF is reasonably
close to the original for a first pass proof of concept.  I've tested the
flow
on OS X and Fedora 21. Dunno about Windows.

Hopefully this little demo can move the documentation file format
discussion
forward a bit. :-) Thoughts?


Regards,

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