Re: Compiling GnuCash on Windows

[Ivars Grinbergs]

Hello,

Yesterday got compiled and running version of GC on Win32.

Version: This copy was built from svn r15066 on 2006-11-01.

I did little modifications to custom.sh from

GTK_URL="$GNOME_WIN32_URL/gtk+/2.10/gtk+-2.10.3.zip"
GTK_DEV_URL="$GNOME_WIN32_URL/gtk+/2.10/gtk+-dev-2.10.3.zip"

to

GTK_URL="$GNOME_WIN32_URL/gtk+/2.10/gtk+-2.10.6.zip"
GTK_DEV_URL="$GNOME_WIN32_URL/gtk+/2.10/gtk+-dev-2.10.6.zip"

This solved me the problem (I think so) with crashing on filesistem 
operations.

Below are few more comments.

With regards,
Ivars

Christian Stimming wrote:
> I'd like to hear whether these things work, in case you have some time to 
> check them in detail: 
> - Creating a new file (with default account hierarchy)
>   
Ok.
> - Creating more accounts in that file
>   
Ok.
> - Adding transactions to these accounts
>   
Ok.
> - running reports, particularly "account summary", "income statement", 
> "balance sheet"
>   
Account Summary: OK
Income Statement: OK
Balance Sheet: OK
> - Changing some preferences (are these preserved when shutting down (without 
> crashing) and starting again?)
>   
Ok.

Other problems observed:
- I use Latvian language and location; there are problems with 
entering/showing specific latvian characters;
- Actions->Scheduled Transactions->  FAILS with this backtrace on screen 
within GDB:

GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) run
Starting program: c:\gc\gnucash\bin/gnucash-bin.exe

Program received signal SIGSEGV, Segmentation fault.
0x6b072b01 in _libmsvcrt_a_iname ()
(gdb) backtrace
#0  0x6b072b01 in _libmsvcrt_a_iname ()
#1  0x100516f0 in _PRETTY_FUNCTION__.28 ()
#2  0x6b073034 in _libmsvcrt_a_iname ()
#3  0x6b046dd4 in __RUNTIME_PSEUDO_RELOC_LIST__ ()
#4  0x0077a51c in ?? ()
#5  0x005fc9f4 in ?? ()
#6  0x005e66f7 in ?? ()
#7  0x005e5b39 in ?? ()
#8  0x005e65eb in ?? ()
#9  0x005e66d6 in ?? ()
#10 0x00778000 in ?? ()
#11 0x63054ab6 in gnc_ui_scheduled_xaction_dialog_create ()
at dialog-scheduledxaction.c:1250
#12 0x005e3935 in ?? ()
#13 0x005f6f35 in ?? ()
#14 0x005f7cde in ?? ()
#15 0x005f7f56 in ?? ()
#16 0x6048b824 in _libws2_32_a_iname ()
#17 0x005e3935 in ?? ()
#18 0x005f6f35 in ?? ()
#19 0x005f7cde in ?? ()
#20 0x005f7f56 in ?? ()
#21 0x606999e5 in _libws2_32_a_iname ()
#22 0x6058acec in _libws2_32_a_iname ()
#23 0x6058aff5 in _libws2_32_a_iname ()
#24 0x605774a2 in _libws2_32_a_iname ()
#25 0x005e3935 in ?? ()
#26 0x005f6b66 in ?? ()
#27 0x005f7a3c in ?? ()
#28 0x005f7f56 in ?? ()
#29 0x60699b74 in _libws2_32_a_iname ()
#30 0x60574651 in _libws2_32_a_iname ()
#31 0x6057593d in _libws2_32_a_iname ()
#32 0x6b07098e in _libmsvcrt_a_iname ()
#33 0x1001d8f7 in gpa_radiobutton_update ()
#34 0x1001edcb in gpa_p2f_entry_changed_cb ()
#35 0x1001efaa in gp_gc_set_font ()
#36 0x60574eae in _libws2_32_a_iname ()
#37 0x00784a12 in ?? ()
#38 0x00401746 in inner_main (closure=0x0, argc=1, argv=0xd16ea8)
at gnucash-bin.c:493
#39 0x65e2564d in scm_boot_guile (argc=1, argv=0xd16ea8,
main_func=0x401600 , closure=0x0) at init.c:635
#40 0x00401e26 in main (argc=1, argv=0xd16ea8) at gnucash-bin.c:549
(gdb)

- I also can't build gnucash.pot file as proposed by doc/TRANSLATION_HOWTO:

[EMAIL PROTECTED] ~
$ cd /c/gc/repos/po/

[EMAIL PROTECTED] /c/gc/repos/po
$ make gnucash.pot
INTLTOOL_EXTRACT=../intltool-extract srcdir=. ../intltool-update 
--gettext-package gnucash --pot

 *** The intltool-extract script wasn't found!
 *** Without it, intltool-update can not generate files.

>> Also, in the command prompt window is the following:
>>
>> gnucash: [E] "Failed to fork child process."
>> 
>
> This is probably because gnucash tries to save the file in compressed form, 
> which requires a separate gzip process that won't work on windows. In short, 
> in the preferences please uncheck the checkbox under General -> File -> 
> Compress file. Does saving work, then?
>
>   
Previously I have had problem to open data file created on Knoppix with 
GC 2.0.1. When I unziped that data file, I was able to open it on Win32 
with GC 2.0.2.
>> Is there a way to generate a backtrace in Windows?
>> 
>
> Yes, if you install gdb. It's available somewhere on mingw.org. Then you need 
> to modify the gnucash startup script so that it calls gdb instead of 
> gnucash.exe. Then, in gdb you start gnucash by "run". This is explained in 
> the file HACKING as well.
>   
Is the backtrace given above the one, which is needed? I mean, did I do 
correctly, to get backtarce?
> Thanks a lot,
>
> Christian
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-dev

Re: Compiling GnuCash on Windows

[Ivars Grinbergs]

Ivars Grinbergs wrote:
> - Actions->Scheduled Transactions->  FAILS with this backtrace on screen 
> within GDB:
>
>   
Sorry, I mean

Actions->Scheduled Transactions->Scheduled Transaction Editor


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

GC, QOF and queries

[Phil Longstaff]

I have started working on a gda backend and am starting with a QofQuery
-> SQL translator.  I assume no one else has such a beast (there is a
SQL -> QofQuery translator as part of QOF.  When we get an SQL backend,
it won't make sense to translate SQL -> QofQuery -> SQL).  I have also
looked at the pattern of queries.  When GC starts, there is only one
query - for bills which need to be paid.  There is no query for the
account tree, for example.  GC must assume that session_begin loads the
account tree.

Is this expected behaviour?  I had assumed that everything would be
queried for.

Secondly, I looked at the begin/commit edit behaviour when an account
was being created.  There was a *lot* of begin/commit activity on the
commodity, including some cases of begin/commit/commit.  Is this
expected behaviour?

Phil

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

Re: Compiling GnuCash on Windows

[Andreas Köhler]

Hi,

Am Donnerstag, den 02.11.2006, 13:31 +0200 schrieb Ivars Grinbergs:
> Hello,
> 
> Yesterday got compiled and running version of GC on Win32.
> 
> Version: This copy was built from svn r15066 on 2006-11-01.

Too bad, you missed some fixes I submitted yesterday. You might try
remove your gnome installation directory and rerun install.sh with
recent packaging/win32 directory. You should also check for an _empty_
install-sh (hyphen) file in your repository and remove it if necessary
(will fix it soon). Meanwhile, do not put install.sh into a parent
directory of the repository.

> I did little modifications to custom.sh from
> 
> GTK_URL="$GNOME_WIN32_URL/gtk+/2.10/gtk+-2.10.3.zip"
> GTK_DEV_URL="$GNOME_WIN32_URL/gtk+/2.10/gtk+-dev-2.10.3.zip"
> 
> to
> 
> GTK_URL="$GNOME_WIN32_URL/gtk+/2.10/gtk+-2.10.6.zip"
> GTK_DEV_URL="$GNOME_WIN32_URL/gtk+/2.10/gtk+-dev-2.10.6.zip"
> 
> This solved me the problem (I think so) with crashing on filesistem 
> operations.

Yeah, fixed in r15076.

> Below are few more comments.
> 
> With regards,
> Ivars
> 
> Christian Stimming wrote:
> > I'd like to hear whether these things work, in case you have some time to 
> > check them in detail: 

Did you run gnucash from the MSYS shell or gnucash.bat?

[successes snip]
> Other problems observed:
> - I use Latvian language and location; there are problems with 
> entering/showing specific latvian characters;

Please be more specific. Is there a way for us (non-latvians) to
reproduce this? BTW, we still need to fix both, the installation and
usage of our localizations.

> - Actions->Scheduled Transactions->  FAILS with this backtrace on screen 
> within GDB:
> 
> GNU gdb 5.2.1
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i686-pc-mingw32"...
> (gdb) run
> Starting program: c:\gc\gnucash\bin/gnucash-bin.exe
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x6b072b01 in _libmsvcrt_a_iname ()
> (gdb) backtrace
> #0  0x6b072b01 in _libmsvcrt_a_iname ()
> #1  0x100516f0 in _PRETTY_FUNCTION__.28 ()
> #2  0x6b073034 in _libmsvcrt_a_iname ()
> #3  0x6b046dd4 in __RUNTIME_PSEUDO_RELOC_LIST__ ()
> #4  0x0077a51c in ?? ()
> #5  0x005fc9f4 in ?? ()
> #6  0x005e66f7 in ?? ()
> #7  0x005e5b39 in ?? ()
> #8  0x005e65eb in ?? ()
> #9  0x005e66d6 in ?? ()
> #10 0x00778000 in ?? ()
> #11 0x63054ab6 in gnc_ui_scheduled_xaction_dialog_create ()
> at dialog-scheduledxaction.c:1250
> #12 0x005e3935 in ?? ()
> #13 0x005f6f35 in ?? ()
> #14 0x005f7cde in ?? ()
> #15 0x005f7f56 in ?? ()
> #16 0x6048b824 in _libws2_32_a_iname ()
> #17 0x005e3935 in ?? ()
> #18 0x005f6f35 in ?? ()
> #19 0x005f7cde in ?? ()
> #20 0x005f7f56 in ?? ()
> #21 0x606999e5 in _libws2_32_a_iname ()
> #22 0x6058acec in _libws2_32_a_iname ()
> #23 0x6058aff5 in _libws2_32_a_iname ()
> #24 0x605774a2 in _libws2_32_a_iname ()
> #25 0x005e3935 in ?? ()
> #26 0x005f6b66 in ?? ()
> #27 0x005f7a3c in ?? ()
> #28 0x005f7f56 in ?? ()
> #29 0x60699b74 in _libws2_32_a_iname ()
> #30 0x60574651 in _libws2_32_a_iname ()
> #31 0x6057593d in _libws2_32_a_iname ()
> #32 0x6b07098e in _libmsvcrt_a_iname ()
> #33 0x1001d8f7 in gpa_radiobutton_update ()
> #34 0x1001edcb in gpa_p2f_entry_changed_cb ()
> #35 0x1001efaa in gp_gc_set_font ()
> #36 0x60574eae in _libws2_32_a_iname ()
> #37 0x00784a12 in ?? ()
> #38 0x00401746 in inner_main (closure=0x0, argc=1, argv=0xd16ea8)
> at gnucash-bin.c:493
> #39 0x65e2564d in scm_boot_guile (argc=1, argv=0xd16ea8,
> main_func=0x401600 , closure=0x0) at init.c:635
> #40 0x00401e26 in main (argc=1, argv=0xd16ea8) at gnucash-bin.c:549
> (gdb)

You have to admit that this stack trace is not extraordinary useful ;-)
But yesterday I managed to improve, maybe you can try to do the same?
Here is what I did:

* download and unpack `pd' and `MMP' from http://www.trapkit.de, you
will need the Microsoft .NET Framework Version 2.0 to run the latter
* make gnucash crash within gdb
* determine the PID of the running gnucash-bin process (Ctrl+Alt+Del)
* open a shell and enter `pd -p $pid > my.dump', where $pid is your pid
* open mmp, open my.dump, let it parse it (click away errors you get,
ignore "please wait" dialogs that do not go away and also crashes when
you try to close mmp after your work)
* see frame #4, it says 0x0077a51c... try to find the dll that got
mapped there and also its base address (one of the first columns)
* enter `add-symbol-file $mydll $myaddr' into gdb, where $mydll might be
libgncmod-gnome-utils-0.dll or such, and myaddr the base address mmp
told you; confirm with "y"
* bt again

Success?

Any suggestions how to ease this process?

> - I also can't build gnucash.pot file as proposed by doc/TRANSLATION_HOWTO:
> 
> [EMAIL PR

Re: GC architecture for backends

[Daniel Espinosa]

2006/11/1, Derek Atkins <[EMAIL PROTECTED]>:
> Quoting Daniel Espinosa <[EMAIL PROTECTED]>:
>
> >> Also, we'll need to make changes to handle the fact that file://
> >> should get redirected to sqlite:// -- but the code will need to
> >> test the file first to see what kind of file it is, so that File -> Open
> >> does the "right thing".   I.e., the fact that we're using SQLite
> >> should get hidden from the user when we migrate to it.
> >>
> >
> > I think the URI mus be gda:// or db://, think that gda is wrapper for
> > many DB backends not just sqlite.
>
> At some level we need to be able to specify what kind of database is
> sitting behind there.  At SOME point we need to know how to specify
> a filename for SQLite vs. a host/port/user/password for PG.  So clearly
> there's some differentiation there.
>

Isn't the case for GDA, when you create a DSN, you can use this name
to connect: you just need to specify the DSN, user, password and some
options (read only for example) see the libgda.h file where you'll
find some convenient functions to easy use GDA and quick do some very
common task.

> But this is irrelevant to what I meant.   What the user types into the
> File->Open dialog does not need to be the string that gets passed the GDA.

If you have an option to connect or open a DSN the URI could be:

gda://gnucash:username:password

With a gnomedb-login widget you can select a predefined DNS, get
username and password, and thats all you can pass it to the QOF beggin
session function to open the back end.


> I'm just pointing out that we need to intercept that input and handle
> it appropriately, which may mean adjusting the actual string and perhaps
> calling the XML or GDA-with-SQLite backends.
>

In the event that GC will use just SQLite or other DB engines, you
don't need a special intercept, I think the dialog *must* allways show
a gnomedb-login widget to select the DSN, write a user and a password,
 and Go!

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los
cuates: LIBRE)

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

Re: Compiling GnuCash on Windows

[Ivars Grinbergs]

Andreas Köhler wrote:
> Did you run gnucash from the MSYS shell or gnucash.bat?
>   
 From MSYS shell, within gdb (but it works from shell without gdb, too).
> [successes snip]
>   
>> Other problems observed:
>> - I use Latvian language and location; there are problems with 
>> entering/showing specific latvian characters;
>> 
>
> Please be more specific. Is there a way for us (non-latvians) to
> reproduce this? BTW, we still need to fix both, the installation and
> usage of our localizations.
>   
I shall check this later how to do this on "pure" WinXP, since I use 
third party software for keyboard management.
> You have to admit that this stack trace is not extraordinary useful ;-)
> But yesterday I managed to improve, maybe you can try to do the same?
> Here is what I did:
>
> * download and unpack `pd' and `MMP' from http://www.trapkit.de, you
> will need the Microsoft .NET Framework Version 2.0 to run the latter
> * make gnucash crash within gdb
> * determine the PID of the running gnucash-bin process (Ctrl+Alt+Del)
> * open a shell and enter `pd -p $pid > my.dump', where $pid is your pid
> * open mmp, open my.dump, let it parse it (click away errors you get,
> ignore "please wait" dialogs that do not go away and also crashes when
> you try to close mmp after your work)
> * see frame #4, it says 0x0077a51c... try to find the dll that got
> mapped there and also its base address (one of the first columns)
> * enter `add-symbol-file $mydll $myaddr' into gdb, where $mydll might be
> libgncmod-gnome-utils-0.dll or such, and myaddr the base address mmp
> told you; confirm with "y"
> * bt again
>
> Success?
>
>   
I shall try it out as soon as possible, will come back with results.

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

Re: Compiling GnuCash on Windows

[Ivars Grinbergs]

Andreas Köhler wrote:
> You have to admit that this stack trace is not extraordinary useful ;-)
> But yesterday I managed to improve, maybe you can try to do the same?
> Here is what I did:
>
> * download and unpack `pd' and `MMP' from http://www.trapkit.de, you
> will need the Microsoft .NET Framework Version 2.0 to run the latter
> * make gnucash crash within gdb
> * determine the PID of the running gnucash-bin process (Ctrl+Alt+Del)
> * open a shell and enter `pd -p $pid > my.dump', where $pid is your pid
> * open mmp, open my.dump, let it parse it (click away errors you get,
> ignore "please wait" dialogs that do not go away and also crashes when
> you try to close mmp after your work)
> * see frame #4, it says 0x0077a51c... try to find the dll that got
> mapped there and also its base address (one of the first columns)
> * enter `add-symbol-file $mydll $myaddr' into gdb, where $mydll might be
> libgncmod-gnome-utils-0.dll or such, and myaddr the base address mmp
> told you; confirm with "y"
> * bt again
>
> Success?
>
>   
hopefully :)
here is what I have got:

#0 0x6b072b01 in _libmsvcrt_a_iname ()
#1 0x100516f0 in _PRETTY_FUNCTION__.28 ()
#2 0x6b073034 in _libmsvcrt_a_iname ()
#3 0x6b046dd4 in __RUNTIME_PSEUDO_RELOC_LIST__ ()
#4 0x0077a51c in _end__ ()
#5 0x005fc9f4 in libgncmod_gnome_utils_0_dll_iname ()
#6 0x005e66f7 in libgncmod_gnome_utils_0_dll_iname ()
#7 0x005e5b39 in libgncmod_gnome_utils_0_dll_iname ()
#8 0x005e65eb in libgncmod_gnome_utils_0_dll_iname ()
#9 0x005e66d6 in libgncmod_gnome_utils_0_dll_iname ()
#10 0x00778000 in ?? ()
#11 0x63054ab6 in gnc_ui_scheduled_xaction_dialog_create ()
at dialog-scheduledxaction.c:1250
#12 0x005e3935 in libgncmod_gnome_utils_0_dll_iname ()
#13 0x005f6f35 in libgncmod_gnome_utils_0_dll_iname ()
#14 0x005f7cde in libgncmod_gnome_utils_0_dll_iname ()
#15 0x005f7f56 in libgncmod_gnome_utils_0_dll_iname ()
#16 0x6048b824 in _libws2_32_a_iname ()
#17 0x005e3935 in libgncmod_gnome_utils_0_dll_iname ()
#18 0x005f6f35 in libgncmod_gnome_utils_0_dll_iname ()
#19 0x005f7cde in libgncmod_gnome_utils_0_dll_iname ()
#20 0x005f7f56 in libgncmod_gnome_utils_0_dll_iname ()
#21 0x606999e5 in _libws2_32_a_iname ()
#22 0x6058acec in _libws2_32_a_iname ()
#23 0x6058aff5 in _libws2_32_a_iname ()
#24 0x605774a2 in _libws2_32_a_iname ()
#25 0x005e3935 in libgncmod_gnome_utils_0_dll_iname ()
#26 0x005f6b66 in libgncmod_gnome_utils_0_dll_iname ()
#27 0x005f7a3c in libgncmod_gnome_utils_0_dll_iname ()
#28 0x005f7f56 in libgncmod_gnome_utils_0_dll_iname ()
#29 0x60699b74 in _libws2_32_a_iname ()
#30 0x60574651 in _libws2_32_a_iname ()
#31 0x6057593d in _libws2_32_a_iname ()
#32 0x6b07098e in _libmsvcrt_a_iname ()
#33 0x1001d8f7 in gpa_radiobutton_update ()
#34 0x1001edcb in gpa_p2f_entry_changed_cb ()
#35 0x1001efaa in gp_gc_set_font ()
#36 0x60574eae in _libws2_32_a_iname ()
#37 0x00784a12 in gnc_option_set_ui_widget_commodity (option=0x40448e,
page_box=0x0, tooltips=0x0, name=0x65e25134 "\201ūt!", documentation=0x0,
enclosing=0x404868, packed=0x22fca8) at dialog-options.c:1668
#38 0x00401746 in inner_main (closure=0x0, argc=1, argv=0xd16ea8)
at gnucash-bin.c:493
#39 0x65e2564d in scm_boot_guile (argc=1, argv=0xd16ea8,
main_func=0x401600 , closure=0x0) at init.c:635
#40 0x00401e26 in main (argc=1, argv=0xd16ea8) at gnucash-bin.c:549

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

Re: GC architecture for backends

[Phil Longstaff]

On Thu, 2006-02-11 at 08:40 -0600, Daniel Espinosa wrote:
> 2006/11/1, Derek Atkins <[EMAIL PROTECTED]>:
> > Quoting Daniel Espinosa <[EMAIL PROTECTED]>:
> >
> > >> Also, we'll need to make changes to handle the fact that file://
> > >> should get redirected to sqlite:// -- but the code will need to
> > >> test the file first to see what kind of file it is, so that File -> Open
> > >> does the "right thing".   I.e., the fact that we're using SQLite
> > >> should get hidden from the user when we migrate to it.
> > >>
> > >
> > > I think the URI mus be gda:// or db://, think that gda is wrapper for
> > > many DB backends not just sqlite.
> >
> > At some level we need to be able to specify what kind of database is
> > sitting behind there.  At SOME point we need to know how to specify
> > a filename for SQLite vs. a host/port/user/password for PG.  So clearly
> > there's some differentiation there.
> >
> 
> Isn't the case for GDA, when you create a DSN, you can use this name
> to connect: you just need to specify the DSN, user, password and some
> options (read only for example) see the libgda.h file where you'll
> find some convenient functions to easy use GDA and quick do some very
> common task.
> 
> > But this is irrelevant to what I meant.   What the user types into the
> > File->Open dialog does not need to be the string that gets passed the GDA.
> 
> If you have an option to connect or open a DSN the URI could be:
> 
> gda://gnucash:username:password
> 
> With a gnomedb-login widget you can select a predefined DNS, get
> username and password, and thats all you can pass it to the QOF beggin
> session function to open the back end.
> 
> 
> > I'm just pointing out that we need to intercept that input and handle
> > it appropriately, which may mean adjusting the actual string and perhaps
> > calling the XML or GDA-with-SQLite backends.
> >
> 
> In the event that GC will use just SQLite or other DB engines, you
> don't need a special intercept, I think the dialog *must* allways show
> a gnomedb-login widget to select the DSN, write a user and a password,
>  and Go!
> 

I haven't thought through all of the issues around connections, but I
don't think we want to use predefined DSNs.  A user shouldn't have to
set up the GC DSN with an external tool in order to use that DSN within
gnucash.

Phil


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

Re: Compiling GnuCash on Windows

[Christian Stimming]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

For me on win2000/SP4 with r15078 and the updated gnome packages
according to the recent commits in custom.sh, I get these:

>> - Creating a new file (with default account hierarchy)

Works for me just fine. The account hierarchy druid comes up and gives
all the locale=C choices that are shipped with gnucash.

>> - Creating more accounts in that file

Works.

>> - Adding transactions to these accounts

Works.

>> - running reports, particularly "account summary", "income statement", 
>> "balance sheet"

Doesn't work. I tried to run gnucash under gdb,
http://wiki.gnucash.org/wiki/Windows#gdb , and surprisingly enough then
it works! All of the text reports will simply work when running under
gdb... sigh.

>>- Saving to file

Works just fine as well, probably due to the recent gtk upgrade.

>>> Also, in the command prompt window is the following:
>>>
>>> gnucash: [E] "Failed to fork child process."
>> This is probably because gnucash tries to save the file in compressed form, 
>> which requires a separate gzip process that won't work on windows. In short, 
>> in the preferences please uncheck the checkbox under General -> File -> 
>> Compress file. Does saving work, then?
> 
> I wonder if we should just disable this feature on win32?

The feature is already disabled on windows, see io-gncxml-v2.c:1243. I
tried to find the place that's causing this "failed to fork" message,
but apparently it doesn't come from within gnucash. At least we don't
have that string anywhere, and the only fork() that gnucash uses is in
io-gncxml-v2.c which is unused on windows. So I have no idea where this
comes from, and I'd simply ignore it for now.

Christian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCUAwUBRUoq2GXAi+BfhivFAQJp2gP4j7hgq6uSk5MZ79RXe3oRp0die6PKdpah
GaFYxStJqCEdTNbSdMQmh1Or/W4zaK7l/h9tJ71CWMErwcmg+CcVGe91K6x032ZY
4hK8ZuP7viFSm7YekEyFlwbMbSm5bSc3eG+ReB8l4EPQ44tBWFmdFfJspe3iaD4h
BgDpzKJatw==
=sFD8
-END PGP SIGNATURE-
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Compiling GnuCash on Windows

[Andreas Köhler]

Hi,

Ivars Grinbergs wrote:
> Andreas Köhler wrote:
> > You have to admit that this stack trace is not extraordinary useful ;-)
> > But yesterday I managed to improve, maybe you can try to do the same?
> > Here is what I did:
> >
> > * download and unpack `pd' and `MMP' from http://www.trapkit.de, you
> > will need the Microsoft .NET Framework Version 2.0 to run the latter
> > * make gnucash crash within gdb
> > * determine the PID of the running gnucash-bin process (Ctrl+Alt+Del)
> > * open a shell and enter `pd -p $pid > my.dump', where $pid is your pid
> > * open mmp, open my.dump, let it parse it (click away errors you get,
> > ignore "please wait" dialogs that do not go away and also crashes when
> > you try to close mmp after your work)
> > * see frame #4, it says 0x0077a51c... try to find the dll that got
> > mapped there and also its base address (one of the first columns)
> > * enter `add-symbol-file $mydll $myaddr' into gdb, where $mydll might be
> > libgncmod-gnome-utils-0.dll or such, and myaddr the base address mmp
> > told you; confirm with "y"
> > * bt again
> >
> > Success?
> >
> >   
> hopefully :)
> here is what I have got:
> 
> #0 0x6b072b01 in _libmsvcrt_a_iname ()
> #1 0x100516f0 in _PRETTY_FUNCTION__.28 ()
> #2 0x6b073034 in _libmsvcrt_a_iname ()
> #3 0x6b046dd4 in __RUNTIME_PSEUDO_RELOC_LIST__ ()
> #4 0x0077a51c in _end__ ()
> #5 0x005fc9f4 in libgncmod_gnome_utils_0_dll_iname ()
> #6 0x005e66f7 in libgncmod_gnome_utils_0_dll_iname ()
> #7 0x005e5b39 in libgncmod_gnome_utils_0_dll_iname ()
> #8 0x005e65eb in libgncmod_gnome_utils_0_dll_iname ()
> #9 0x005e66d6 in libgncmod_gnome_utils_0_dll_iname ()
> #10 0x00778000 in ?? ()
> #11 0x63054ab6 in gnc_ui_scheduled_xaction_dialog_create ()
> at dialog-scheduledxaction.c:1250
> #12 0x005e3935 in libgncmod_gnome_utils_0_dll_iname ()
> #13 0x005f6f35 in libgncmod_gnome_utils_0_dll_iname ()
> #14 0x005f7cde in libgncmod_gnome_utils_0_dll_iname ()
> #15 0x005f7f56 in libgncmod_gnome_utils_0_dll_iname ()
> #16 0x6048b824 in _libws2_32_a_iname ()
> #17 0x005e3935 in libgncmod_gnome_utils_0_dll_iname ()
> #18 0x005f6f35 in libgncmod_gnome_utils_0_dll_iname ()
> #19 0x005f7cde in libgncmod_gnome_utils_0_dll_iname ()
> #20 0x005f7f56 in libgncmod_gnome_utils_0_dll_iname ()
> #21 0x606999e5 in _libws2_32_a_iname ()
> #22 0x6058acec in _libws2_32_a_iname ()
> #23 0x6058aff5 in _libws2_32_a_iname ()
> #24 0x605774a2 in _libws2_32_a_iname ()
> #25 0x005e3935 in libgncmod_gnome_utils_0_dll_iname ()
> #26 0x005f6b66 in libgncmod_gnome_utils_0_dll_iname ()
> #27 0x005f7a3c in libgncmod_gnome_utils_0_dll_iname ()
> #28 0x005f7f56 in libgncmod_gnome_utils_0_dll_iname ()
> #29 0x60699b74 in _libws2_32_a_iname ()
> #30 0x60574651 in _libws2_32_a_iname ()
> #31 0x6057593d in _libws2_32_a_iname ()
> #32 0x6b07098e in _libmsvcrt_a_iname ()
> #33 0x1001d8f7 in gpa_radiobutton_update ()
> #34 0x1001edcb in gpa_p2f_entry_changed_cb ()
> #35 0x1001efaa in gp_gc_set_font ()
> #36 0x60574eae in _libws2_32_a_iname ()
> #37 0x00784a12 in gnc_option_set_ui_widget_commodity (option=0x40448e,
> page_box=0x0, tooltips=0x0, name=0x65e25134 "\201ūt!", documentation=0x0,
> enclosing=0x404868, packed=0x22fca8) at dialog-options.c:1668
> #38 0x00401746 in inner_main (closure=0x0, argc=1, argv=0xd16ea8)
> at gnucash-bin.c:493
> #39 0x65e2564d in scm_boot_guile (argc=1, argv=0xd16ea8,
> main_func=0x401600 , closure=0x0) at init.c:635
> #40 0x00401e26 in main (argc=1, argv=0xd16ea8) at gnucash-bin.c:549

sorry for the answer in a hurry. Can you please double-check that
1) you select the one line in mappings within mmp such that mapping_start
<= 0x0077a51c < mapping_end
2) $mydll is the basename (the part after the last backslash) in the
mapped_from column
3) $myaddr is the mapping_start?

So yes, the backtrace looks better, but still lacks real debugging
information (function names, line numbers). I expect you did not
change install.sh so that it either does not include debug symbols
or strips the binaries...

Go go, well done so far!

-- andi5

-- 
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Compiling GnuCash on Windows

[Chris Shoemaker]

On Thu, Nov 02, 2006 at 06:28:56PM +0100, Christian Stimming wrote:
> >>> Also, in the command prompt window is the following:
> >>>
> >>> gnucash: [E] "Failed to fork child process."
> >> This is probably because gnucash tries to save the file in compressed 
> >> form, 
> >> which requires a separate gzip process that won't work on windows. In 
> >> short, 
> >> in the preferences please uncheck the checkbox under General -> File -> 
> >> Compress file. Does saving work, then?
> > 
> > I wonder if we should just disable this feature on win32?
> 
> The feature is already disabled on windows, see io-gncxml-v2.c:1243. I
> tried to find the place that's causing this "failed to fork" message,
> but apparently it doesn't come from within gnucash. At least we don't
> have that string anywhere, and the only fork() that gnucash uses is in
> io-gncxml-v2.c which is unused on windows. So I have no idea where this
> comes from, and I'd simply ignore it for now.

That's process.scm which is run during price-quote retrieval.  Perhaps
guile's (primitive-fork) doesn't work on win32.

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

Re: GC architecture for backends

[Chris Shoemaker]

On Thu, Nov 02, 2006 at 12:25:17PM -0500, Phil Longstaff wrote:
> On Thu, 2006-02-11 at 08:40 -0600, Daniel Espinosa wrote:
> > 2006/11/1, Derek Atkins <[EMAIL PROTECTED]>:
> > > Quoting Daniel Espinosa <[EMAIL PROTECTED]>:
> > >
> > > >> Also, we'll need to make changes to handle the fact that file://
> > > >> should get redirected to sqlite:// -- but the code will need to
> > > >> test the file first to see what kind of file it is, so that File -> 
> > > >> Open
> > > >> does the "right thing".   I.e., the fact that we're using SQLite
> > > >> should get hidden from the user when we migrate to it.
> > > >>
> > > >
> > > > I think the URI mus be gda:// or db://, think that gda is wrapper for
> > > > many DB backends not just sqlite.
> > >
> > > At some level we need to be able to specify what kind of database is
> > > sitting behind there.  At SOME point we need to know how to specify
> > > a filename for SQLite vs. a host/port/user/password for PG.  So clearly
> > > there's some differentiation there.
> > >
> > 
> > Isn't the case for GDA, when you create a DSN, you can use this name
> > to connect: you just need to specify the DSN, user, password and some
> > options (read only for example) see the libgda.h file where you'll
> > find some convenient functions to easy use GDA and quick do some very
> > common task.
> > 
> > > But this is irrelevant to what I meant.   What the user types into the
> > > File->Open dialog does not need to be the string that gets passed the GDA.
> > 
> > If you have an option to connect or open a DSN the URI could be:
> > 
> > gda://gnucash:username:password
> > 
> > With a gnomedb-login widget you can select a predefined DNS, get
> > username and password, and thats all you can pass it to the QOF beggin
> > session function to open the back end.
> > 
> > 
> > > I'm just pointing out that we need to intercept that input and handle
> > > it appropriately, which may mean adjusting the actual string and perhaps
> > > calling the XML or GDA-with-SQLite backends.
> > >
> > 
> > In the event that GC will use just SQLite or other DB engines, you
> > don't need a special intercept, I think the dialog *must* allways show
> > a gnomedb-login widget to select the DSN, write a user and a password,
> >  and Go!
> > 
> 
> I haven't thought through all of the issues around connections, but I
> don't think we want to use predefined DSNs.  A user shouldn't have to
> set up the GC DSN with an external tool in order to use that DSN within
> gnucash.
> 
> Phil

At least for an initial implementation, I recommend letting the
external tools handle DSN setup.  The most general setups
(i.e. anything other than sqllite) will probably require external
configuration anyway.  Once it's working, we can worry about
streamlining setup for the simple cases.

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

Re: GC architecture for backends

[Derek Atkins]

Quoting Chris Shoemaker <[EMAIL PROTECTED]>:

>> I haven't thought through all of the issues around connections, but I
>> don't think we want to use predefined DSNs.  A user shouldn't have to
>> set up the GC DSN with an external tool in order to use that DSN within
>> gnucash.
>>
>> Phil
>
> At least for an initial implementation, I recommend letting the
> external tools handle DSN setup.  The most general setups
> (i.e. anything other than sqllite) will probably require external
> configuration anyway.  Once it's working, we can worry about
> streamlining setup for the simple cases.

Except for SQLite I don't have a strong opinion about DSN setup.
However, for SQLite I think Gnucash needs to control the whole
interaction and be able to "force" GDA to use SQLite.  We (read: I)
want the SQLite backend to replace the XML-File backend and "become"
the new "File Backend"...

> -chris

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available

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

gnucash 2 at FINK

[Bob Hunter]

Still no signs of life...


 
__
Check out the New Yahoo! Mail - Fire up a more powerful email and get things 
done faster. 
(http://advision.webevents.yahoo.com/mailbeta) 

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

Re: gnucash 2 at FINK

[Guillaume Lessard]

--On November 2, 2006 12:01:43 -0800 Bob Hunter <[EMAIL PROTECTED]> 
wrote:

> Still no signs of life...

Sébastien Maret put together description files to build gnucash under Fink 
in August:



I was succesful in building it this way, but I couldn't get the online 
quotes to work.

I think Dave Reiser has been working on finishing it up.


Now a lot of the reason it's slow to arrive in Fink is because of the 
multi-tree setup, with crypto and experimental. Many of gnucash's 
dependencies are themselves stuck in experimental, so it's gonna be a while 
before a binary package is available.
You can help! You can do so by building the experimental packages and 
reporting on your success or lack thereof.


If you *really* need gnucash 2 *now*, building it in macports works very 
well. It takes no more than 1GB -- that's about a dollar worth of a laptop 
hard drive -- and it builds in less than 8 hours on my 4-year-old machine. 
I'm assuming you have the developer tools installed, because after all 
you're subscribed to the devel list...

--
Guillaume Lessard
[EMAIL PROTECTED]


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

Re: GC, QOF and queries

[Derek Atkins]

Quoting Phil Longstaff <[EMAIL PROTECTED]>:

> I have started working on a gda backend and am starting with a QofQuery
> -> SQL translator.  I assume no one else has such a beast (there is a
> SQL -> QofQuery translator as part of QOF.  When we get an SQL backend,
> it won't make sense to translate SQL -> QofQuery -> SQL).  I have also
> looked at the pattern of queries.  When GC starts, there is only one
> query - for bills which need to be paid.  There is no query for the
> account tree, for example.  GC must assume that session_begin loads the
> account tree.

The PG Backend has a sample Query -> SQL converter, but it's very
limited -- it only does Transaction (Split) searches.

> Is this expected behaviour?  I had assumed that everything would be
> queried for.

This is expected behavior.  Take a look at the PG Backend.  All of the
accounts are expected to get loaded at start time.  From the business
side, the Tax Tables and Terms are also expected to get loaded at
start time.

Not everything gets loaded by a query.

> Secondly, I looked at the begin/commit edit behaviour when an account
> was being created.  There was a *lot* of begin/commit activity on the
> commodity, including some cases of begin/commit/commit.  Is this
> expected behaviour?

Begin/Commit can be nested (and indeed SHOULD be nested, IMNSHO)..  However
the begins and commits should be balanced.  If they are not balanced
then that is a bug.

Only the final commit() should push the data out to the database.

> Phil

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available

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

Re: gnucash 2 at FINK

[Dave Reiser]

Bob Hunter wrote:
> Still no signs of life...
> 
> 
>  
True. I've run into dependency issues. I (rightfully) don't have commit 
access to fink, so I need to have someone review the submissions. There 
are questions about how well new and old versions of gwenhywfar and 
aqbanking get along side by side in the distribution.

I am making some progress, but it is slower than I anticipated because 
of my unfamiliarity with resolving version upgrades that are as far 
apart as gwen and aqbanking are for fink, while allowing gnucash 1.8.x 
to still be available as it was.

Dave
-- 
David Reiser
[EMAIL PROTECTED]

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

Re: GC, QOF and queries

[Phil Longstaff]

On Thu, 2006-02-11 at 16:14 -0500, Derek Atkins wrote:
> Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> 
> > I have started working on a gda backend and am starting with a QofQuery
> > -> SQL translator.  I assume no one else has such a beast (there is a
> > SQL -> QofQuery translator as part of QOF.  When we get an SQL backend,
> > it won't make sense to translate SQL -> QofQuery -> SQL).  I have also
> > looked at the pattern of queries.  When GC starts, there is only one
> > query - for bills which need to be paid.  There is no query for the
> > account tree, for example.  GC must assume that session_begin loads the
> > account tree.
> 
> The PG Backend has a sample Query -> SQL converter, but it's very
> limited -- it only does Transaction (Split) searches.

OK.  I'll see if there is anything I can borrow from it.

> This is expected behavior.  Take a look at the PG Backend.  All of the
> accounts are expected to get loaded at start time.  From the business
> side, the Tax Tables and Terms are also expected to get loaded at
> start time.
> 
> Not everything gets loaded by a query.

OK

> > Secondly, I looked at the begin/commit edit behaviour when an account
> > was being created.  There was a *lot* of begin/commit activity on the
> > commodity, including some cases of begin/commit/commit.  Is this
> > expected behaviour?
> 
> Begin/Commit can be nested (and indeed SHOULD be nested, IMNSHO)..  However
> the begins and commits should be balanced.  If they are not balanced
> then that is a bug.
> 
> Only the final commit() should push the data out to the database.

There are 2 commits because, for example, gnc_commodity_commit_edit()
calls qof_commit_edit() and then qof_commit_edit_part2().
qof_commit_edit() calls the backend commit if the editlevel is 0 and the
instance is dirty.  qof_commit_edit_part2() always calls the backend
commit.

Phil

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

Re: GC, QOF and queries

[Derek Atkins]

Quoting Phil Longstaff <[EMAIL PROTECTED]>:

> OK.  I'll see if there is anything I can borrow from it.

I doubt there is, except as a prototype..

>> > Secondly, I looked at the begin/commit edit behaviour when an account
>> > was being created.  There was a *lot* of begin/commit activity on the
>> > commodity, including some cases of begin/commit/commit.  Is this
>> > expected behaviour?
>>
>> Begin/Commit can be nested (and indeed SHOULD be nested, IMNSHO)..  However
>> the begins and commits should be balanced.  If they are not balanced
>> then that is a bug.
>>
>> Only the final commit() should push the data out to the database.
>
> There are 2 commits because, for example, gnc_commodity_commit_edit()
> calls qof_commit_edit() and then qof_commit_edit_part2().
> qof_commit_edit() calls the backend commit if the editlevel is 0 and the
> instance is dirty.  qof_commit_edit_part2() always calls the backend
> commit.

This seems like a bug.  The backend commit should only get called once.
If it's getting called twice, that's a bug.

> Phil

-derek

--
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available

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

Re: GC, QOF and queries

[Chris Shoemaker]

On Thu, Nov 02, 2006 at 08:47:30AM -0500, Phil Longstaff wrote:
> I have started working on a gda backend and am starting with a QofQuery
> -> SQL translator.  

Have you looked at just directly using the GdaQuery objects?  You can
constuct an abstract query out of GdaQueryFieldFields,
GdaQueryFieldValues and such.  Then, libgda will emit the
provider-specific SQL for that query.

To be frank, IMO, GdaQuery is a better data model for queries than
QofQuery.  By "better", I mean "more appropriate for GnuCash".  I
think it's very unfortunate that GnuCash uses its own home-grown
object-agnostic query representation.  Someone else will probably
disagree.

But, if you re-parented GnuCash's engine objects with a
GnuCash-sepcific GncObject (even with GValue parameters, maybe), and
implemented the QofQuery functionality by generating a GdaQuery, you
would be my hero.  But that's probably more work than you were hoping
for.  *sigh*

Anyway, try to avoid writing the SQL emitter, if you can.

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

Re: GC architecture for backends

[Chris]

I would suggest that those wishing to use a database other than SQLite
will have to know what they are doing so can define the DSN externally
and so when opening a book if its name is not in the data source list
create a SQLite DSN and add it to the data source list.

Regards,
Chris
On Thu, 2006-11-02 at 12:47 -0500, Chris Shoemaker wrote:
> On Thu, Nov 02, 2006 at 12:25:17PM -0500, Phil Longstaff wrote:
> > On Thu, 2006-02-11 at 08:40 -0600, Daniel Espinosa wrote:
> > > 2006/11/1, Derek Atkins <[EMAIL PROTECTED]>:
> > > > Quoting Daniel Espinosa <[EMAIL PROTECTED]>:
> > > >
> > > > >> Also, we'll need to make changes to handle the fact that file://
> > > > >> should get redirected to sqlite:// -- but the code will need to
> > > > >> test the file first to see what kind of file it is, so that File -> 
> > > > >> Open
> > > > >> does the "right thing".   I.e., the fact that we're using SQLite
> > > > >> should get hidden from the user when we migrate to it.
> > > > >>
> > > > >
> > > > > I think the URI mus be gda:// or db://, think that gda is wrapper for
> > > > > many DB backends not just sqlite.
> > > >
> > > > At some level we need to be able to specify what kind of database is
> > > > sitting behind there.  At SOME point we need to know how to specify
> > > > a filename for SQLite vs. a host/port/user/password for PG.  So clearly
> > > > there's some differentiation there.
> > > >
> > > 
> > > Isn't the case for GDA, when you create a DSN, you can use this name
> > > to connect: you just need to specify the DSN, user, password and some
> > > options (read only for example) see the libgda.h file where you'll
> > > find some convenient functions to easy use GDA and quick do some very
> > > common task.
> > > 
> > > > But this is irrelevant to what I meant.   What the user types into the
> > > > File->Open dialog does not need to be the string that gets passed the 
> > > > GDA.
> > > 
> > > If you have an option to connect or open a DSN the URI could be:
> > > 
> > > gda://gnucash:username:password
> > > 
> > > With a gnomedb-login widget you can select a predefined DNS, get
> > > username and password, and thats all you can pass it to the QOF beggin
> > > session function to open the back end.
> > > 
> > > 
> > > > I'm just pointing out that we need to intercept that input and handle
> > > > it appropriately, which may mean adjusting the actual string and perhaps
> > > > calling the XML or GDA-with-SQLite backends.
> > > >
> > > 
> > > In the event that GC will use just SQLite or other DB engines, you
> > > don't need a special intercept, I think the dialog *must* allways show
> > > a gnomedb-login widget to select the DSN, write a user and a password,
> > >  and Go!
> > > 
> > 
> > I haven't thought through all of the issues around connections, but I
> > don't think we want to use predefined DSNs.  A user shouldn't have to
> > set up the GC DSN with an external tool in order to use that DSN within
> > gnucash.
> > 
> > Phil
> 
> At least for an initial implementation, I recommend letting the
> external tools handle DSN setup.  The most general setups
> (i.e. anything other than sqllite) will probably require external
> configuration anyway.  Once it's working, we can worry about
> streamlining setup for the simple cases.
> 
> -chris
> ___
> 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: GC, QOF and queries

[Phil Longstaff]

On Thu, 2006-02-11 at 16:53 -0500, Chris Shoemaker wrote:
> On Thu, Nov 02, 2006 at 08:47:30AM -0500, Phil Longstaff wrote:
> > I have started working on a gda backend and am starting with a QofQuery
> > -> SQL translator.  
> 
> Have you looked at just directly using the GdaQuery objects?  You can
> constuct an abstract query out of GdaQueryFieldFields,
> GdaQueryFieldValues and such.  Then, libgda will emit the
> provider-specific SQL for that query.

I hadn't yet.  I had an older version of libgda which didn't have
GdaQuery.  I've downloaded the latest version and am looking at it.

> To be frank, IMO, GdaQuery is a better data model for queries than
> QofQuery.  By "better", I mean "more appropriate for GnuCash".  I
> think it's very unfortunate that GnuCash uses its own home-grown
> object-agnostic query representation.  Someone else will probably
> disagree.

They do seem to have similar functionality.  It would be interesting if
GdaQuery were used and the current file backend acted like an in-memory
DBMS.

> But, if you re-parented GnuCash's engine objects with a
> GnuCash-sepcific GncObject (even with GValue parameters, maybe), and
> implemented the QofQuery functionality by generating a GdaQuery, you
> would be my hero.  But that's probably more work than you were hoping
> for.  *sigh*
> 
> Anyway, try to avoid writing the SQL emitter, if you can.

I don't really want to gut the core of GC and rebuild it around Gda.

Phil

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

Re: GC, QOF and queries

[Derek Atkins]

Quoting Phil Longstaff <[EMAIL PROTECTED]>:

> On Thu, 2006-02-11 at 16:53 -0500, Chris Shoemaker wrote:
>> On Thu, Nov 02, 2006 at 08:47:30AM -0500, Phil Longstaff wrote:
>> > I have started working on a gda backend and am starting with a QofQuery
>> > -> SQL translator.
>>
>> Have you looked at just directly using the GdaQuery objects?  You can
>> constuct an abstract query out of GdaQueryFieldFields,
>> GdaQueryFieldValues and such.  Then, libgda will emit the
>> provider-specific SQL for that query.
>
> I hadn't yet.  I had an older version of libgda which didn't have
> GdaQuery.  I've downloaded the latest version and am looking at it.

What version of LibGDA do you need to get GdaQuery?  Is libgda-1.9.100
recent enough?  Or do you need something more recent than that?  (I ask
because 1.9.100 is what FC5 has).

>> Anyway, try to avoid writing the SQL emitter, if you can.
>
> I don't really want to gut the core of GC and rebuild it around Gda.

Probably a good idea...

> Phil

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available

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

Re: GC, QOF and queries

[David Hampton]

On Thu, 2006-11-02 at 21:27 -0500, Phil Longstaff wrote:
> On Thu, 2006-02-11 at 16:53 -0500, Chris Shoemaker wrote:

> > Anyway, try to avoid writing the SQL emitter, if you can.
> 
> I don't really want to gut the core of GC and rebuild it around Gda.

I've been thinking of gutting the core of GC and rewriting everything
based on GObjects.  :-)

David


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

Re: GC, QOF and queries

[Chris Shoemaker]

On Thu, Nov 02, 2006 at 10:13:37PM -0500, David Hampton wrote:
> On Thu, 2006-11-02 at 21:27 -0500, Phil Longstaff wrote:
> > On Thu, 2006-02-11 at 16:53 -0500, Chris Shoemaker wrote:
> 
> > > Anyway, try to avoid writing the SQL emitter, if you can.
> > 
> > I don't really want to gut the core of GC and rebuild it around Gda.
> 
> I've been thinking of gutting the core of GC and rewriting everything
> based on GObjects.  :-)

Well, the position of "my hero" is still open...   ;)

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

Re: GC, QOF and queries

[Phil Longstaff]

On Thu, 2006-02-11 at 22:04 -0500, Derek Atkins wrote:
> Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> 
> > On Thu, 2006-02-11 at 16:53 -0500, Chris Shoemaker wrote:
> >> On Thu, Nov 02, 2006 at 08:47:30AM -0500, Phil Longstaff wrote:
> >> > I have started working on a gda backend and am starting with a QofQuery
> >> > -> SQL translator.
> >>
> >> Have you looked at just directly using the GdaQuery objects?  You can
> >> constuct an abstract query out of GdaQueryFieldFields,
> >> GdaQueryFieldValues and such.  Then, libgda will emit the
> >> provider-specific SQL for that query.
> >
> > I hadn't yet.  I had an older version of libgda which didn't have
> > GdaQuery.  I've downloaded the latest version and am looking at it.
> 
> What version of LibGDA do you need to get GdaQuery?  Is libgda-1.9.100
> recent enough?  Or do you need something more recent than that?  (I ask
> because 1.9.100 is what FC5 has).

I don't know.  On the www.gnome-db.org web site, the 1.9.102.changes
file is the first one I can see that mentions GdaQuery.  That, of
course, doesn't mean it doesn't exist earlier.

Phil

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

Re: Compiling GnuCash on Windows

[Ivars Grinbergs]

Andreas Köhler wrote:
> Hi,
>
> Ivars Grinbergs wrote:
>   
>> Andreas Köhler wrote:
>> 
>>> You have to admit that this stack trace is not extraordinary useful ;-)
>>> But yesterday I managed to improve, maybe you can try to do the same?
>>> Here is what I did:
>>>
>>> * download and unpack `pd' and `MMP' from http://www.trapkit.de, you
>>> will need the Microsoft .NET Framework Version 2.0 to run the latter
>>> * make gnucash crash within gdb
>>> * determine the PID of the running gnucash-bin process (Ctrl+Alt+Del)
>>> * open a shell and enter `pd -p $pid > my.dump', where $pid is your pid
>>> * open mmp, open my.dump, let it parse it (click away errors you get,
>>> ignore "please wait" dialogs that do not go away and also crashes when
>>> you try to close mmp after your work)
>>> * see frame #4, it says 0x0077a51c... try to find the dll that got
>>> mapped there and also its base address (one of the first columns)
>>> * enter `add-symbol-file $mydll $myaddr' into gdb, where $mydll might be
>>> libgncmod-gnome-utils-0.dll or such, and myaddr the base address mmp
>>> told you; confirm with "y"
>>> * bt again
>>>
>>> Success?
>>>
>>>   
>>>   
>> hopefully :)
>> here is what I have got:
>>
>> 
[snip]
> sorry for the answer in a hurry. Can you please double-check that
> 1) you select the one line in mappings within mmp such that mapping_start
> <= 0x0077a51c < mapping_end
> 2) $mydll is the basename (the part after the last backslash) in the
> mapped_from column
> 3) $myaddr is the mapping_start?
>
> So yes, the backtrace looks better, but still lacks real debugging
> information (function names, line numbers). I expect you did not
> change install.sh so that it either does not include debug symbols
> or strips the binaries...
>
> Go go, well done so far!
>
> -- andi5
>
>   
here is new results with fresh compiled stuff (This copy was built from 
svn r15078 on 2006-11-03.)

Actions->Scheduled Transactions->Scheduled Transaction Editor

(gdb) bt
#0  0x6b072b01 in _libmsvcrt_a_iname ()
#1  0x673116f0 in _libmsvcrt_a_iname ()
#2  0x6b073034 in _libmsvcrt_a_iname ()
#3  0x6b046dd4 in __RUNTIME_PSEUDO_RELOC_LIST__ ()
#4  0x0063a3dc in gnc_druid_gnome_get_type () at gnc-druid-gnome.c:40
#5  0x6275c9f4 in _libws2_32_a_iname ()
#6  0x627466f7 in _libws2_32_a_iname ()
#7  0x62745b39 in _libws2_32_a_iname ()
#8  0x627465eb in _libws2_32_a_iname ()
#9  0x627466d6 in _libws2_32_a_iname ()
#10 0x00637ec0 in gnc_dense_cal_draw_to_buffer (dcal=0x7c90ee18)
at gnc-dense-cal.c:1275
#11 0x63054ab6 in gnc_ui_scheduled_xaction_dialog_create ()
at dialog-scheduledxaction.c:1250
#12 0x62743935 in _libws2_32_a_iname ()
#13 0x62756f35 in _libws2_32_a_iname ()
#14 0x62757cde in _libws2_32_a_iname ()
#15 0x62757f56 in _libws2_32_a_iname ()
#16 0x6048b824 in _libmsvcrt_a_iname ()
#17 0x62743935 in _libws2_32_a_iname ()
#18 0x62756f35 in _libws2_32_a_iname ()
#19 0x62757cde in _libws2_32_a_iname ()
#20 0x62757f56 in _libws2_32_a_iname ()
#21 0x606999e5 in _libmsvcrt_a_iname ()
#22 0x6058acec in _libmsvcrt_a_iname ()
#23 0x6058aff5 in _libmsvcrt_a_iname ()
#24 0x605774a2 in _libmsvcrt_a_iname ()
#25 0x62743935 in _libws2_32_a_iname ()
#26 0x62756b66 in _libws2_32_a_iname ()
#27 0x62757a3c in _libws2_32_a_iname ()
#28 0x62757f56 in _libws2_32_a_iname ()
#29 0x60699b74 in _libmsvcrt_a_iname ()
#30 0x60574651 in _libmsvcrt_a_iname ()
#31 0x6057593d in _libmsvcrt_a_iname ()
#32 0x6b07098e in _libmsvcrt_a_iname ()
#33 0x672dd8f7 in _libmsvcrt_a_iname ()
#34 0x672dedcb in _libmsvcrt_a_iname ()
#35 0x672defaa in _libmsvcrt_a_iname ()
#36 0x60574eae in _libmsvcrt_a_iname ()
#37 0x006448d2 in set_chart_axis_labels_from_hash (chart=0x22e9f0, eb=0x0)
at gnc-html-graph-gog.c:269
#38 0x00401746 in inner_main (closure=0x0, argc=1, argv=0xbd6ea8)
at gnucash-bin.c:493
#39 0x65e2564d in scm_boot_guile (argc=1, argv=0xbd6ea8,
main_func=0x401600 , closure=0x0) at init.c:635
#40 0x00401e26 in main (argc=1, argv=0xbd6ea8) at gnucash-bin.c:549
(gdb)

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