Re: r12984 - gnucash/trunk/src - Move the global report hash-table from guile to C.
On Fri, Jan 27, 2006 at 12:04:13AM -0500, David Hampton wrote: Chris, This patch broke the tree for everyone compiling with --enable-error-on-warning (which is the default setting). Please compile your tree with this flag enabled before committing. I'm configuring with: ./configure -C CFLAGS=-O0 -Wno-pointer-sign --enable-maintainer-mode --enable-etags --prefix=/opt/gnucash-g2 --enable-opt-style-install --enable-debug Should I explicitly add --enable-error-on-warning? I'm really not trying hide any warnings, but I didn't think there was anything I needed to do to see more. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r12984 - gnucash/trunk/src - Move the global report hash-table from guile to C.
On Fri, Jan 27, 2006 at 12:04:13AM -0500, David Hampton wrote: Chris, This patch broke the tree for everyone compiling with --enable-error-on-warning (which is the default setting). Please compile your tree with this flag enabled before committing. Well, it can't be _everyone_. I just reconfigured with --enable-error-on-warning, and my compiler (gcc 4.0.2) doesn't generate warnings where yours did. What version do you use and with what settings? -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r12984 - gnucash/trunk/src - Move the global report hash-table from guile to C.
On Fri, 2006-01-27 at 00:19 -0500, Chris Shoemaker wrote: I'm configuring with: ./configure -C CFLAGS=-O0 -Wno-pointer-sign --enable-maintainer-mode --enable-etags --prefix=/opt/gnucash-g2 --enable-opt-style-install --enable-debug Should I explicitly add --enable-error-on-warning? I'm really not trying hide any warnings, but I didn't think there was anything I needed to do to see more. You shouldn't need to add that flag as its supposed to be the default. Does the Options detected/selected section at the end of the configure run show that Extra Warnings contains -Werror? I tried your compile line here and I do see -Werror show up. David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r12984 - gnucash/trunk/src - Move the global report hash-table from guile to C.
On Fri, Jan 27, 2006 at 12:38:12AM -0500, David Hampton wrote: On Fri, 2006-01-27 at 00:19 -0500, Chris Shoemaker wrote: I'm configuring with: ./configure -C CFLAGS=-O0 -Wno-pointer-sign --enable-maintainer-mode --enable-etags --prefix=/opt/gnucash-g2 --enable-opt-style-install --enable-debug Should I explicitly add --enable-error-on-warning? I'm really not trying hide any warnings, but I didn't think there was anything I needed to do to see more. You shouldn't need to add that flag as its supposed to be the default. Does the Options detected/selected section at the end of the configure run show that Extra Warnings contains -Werror? I tried your compile line here and I do see -Werror show up. Extra Warnings ... : -Werror -Wdeclaration-after-statement -Wno-pointer-sign CPPFLAGS . : CFLAGS ... : -O0 -Wno-pointer-sign -g -Wall -Wunused -Werror -Wdeclaration-after-statement -Wno-pointer-sign Oh, I just remembered why distcheck failed for me the last time. It tried to configure/compile with strict defaults, and since I need the -Wno-pointer-sign, it won't compile. If you adjust the default warnings maybe you could work that one in there, too. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r12984 - gnucash/trunk/src - Move the global report hash-table from guile to C.
On Fri, 2006-01-27 at 00:36 -0500, Chris Shoemaker wrote: On Fri, Jan 27, 2006 at 12:04:13AM -0500, David Hampton wrote: Chris, This patch broke the tree for everyone compiling with --enable-error-on-warning (which is the default setting). Please compile your tree with this flag enabled before committing. Well, it can't be _everyone_. I just reconfigured with --enable-error-on-warning, What was the value of 'Extra Warnings' at the end of configure? and my compiler (gcc 4.0.2) doesn't generate warnings where yours did. What version do you use and with what settings? gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) ./configure --prefix=/opt/gnucash/u2 --enable-etags --enable-sql --enable-ofx --enable-hbci --enable-ref-counts-dumps --enable-efence --enable-compile-warnings Hmm, I have --enable-compile-warnings and you don't. Checking configure.in, that means I'm getting -Wall and -Wunused passed to the actual compilation which explains why I see errors and you don't. Autogen.sh prints a statement to the effect that this flag should be used. I think I'll go see if I can force it as the default in configure.in. David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r12956 - gnucash/trunk/src - Major step in extraction of application startup from guile.
On Mon, 2006-01-23 at 12:38 -0500, Chris Shoemaker wrote: Caveat: We have multiple mechanisms for handling the filename argument string -- some in guile and some in C. The C-side mechanisms (in engine/gnc-filepath-utils.c) seem a little nicer than the guile ones (in main.scm). They have slightly different behavior (e.g. which paths they'll search for data files.) They both handle URIs and making absolute paths out of relative ones. This patch switches from using the guile functions to the C function. I've tested that the common cases are handled the same way, but it wouldn't surprise me if some corner-cases are not. Nice work. Did you test with and without the --opt-style-install configure argument? That's where most of the path search stuff trips up. David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r12956 - gnucash/trunk/src - Major step in extraction of application startup from guile.
On Mon, Jan 23, 2006 at 01:49:32PM -0500, David Hampton wrote: On Mon, 2006-01-23 at 12:38 -0500, Chris Shoemaker wrote: Caveat: We have multiple mechanisms for handling the filename argument string -- some in guile and some in C. The C-side mechanisms (in engine/gnc-filepath-utils.c) seem a little nicer than the guile ones (in main.scm). They have slightly different behavior (e.g. which paths they'll search for data files.) They both handle URIs and making absolute paths out of relative ones. This patch switches from using the guile functions to the C function. I've tested that the common cases are handled the same way, but it wouldn't surprise me if some corner-cases are not. Nice work. Did you test with and without the --opt-style-install configure argument? That's where most of the path search stuff trips up. Hrmm.. no, I only tested /with/ --opt-style-install. But, this particular chunk of path searching is looking for the user's data file, not any installed resource, so I think it's independent of install style. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r12942 - gnucash/trunk/src - Initialize Gnome libraries before booting guile.
On Sun, Jan 22, 2006 at 06:12:16PM -0500, Chris Shoemaker wrote: - gnucash_program = -gnome_program_init(gnucash, version, LIBGNOMEUI_MODULE, -restargc, restargv, -GNOME_PARAM_POPT_TABLE, nullPoptTable, -GNOME_PROGRAM_STANDARD_PROPERTIES, -GNOME_PARAM_NONE); + gnucash_program = gnome_program_init( + gnucash, version, LIBGNOMEUI_MODULE, + argc, argv, GNOME_PARAM_POPT_TABLE, nullPoptTable, + GNOME_PROGRAM_STANDARD_PROPERTIES, GNOME_PARAM_NONE); I forgot that doing this means gnome provides its own AUTOHELP, which means our help isn't shown anymore. I'll fix ths up shortly. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: E-guile link
Hi Derek, FYI, the e-guile link is back up: http://woozle.org/~neale/repos/eguile/eguile.html I looked at it. It appears intuitive and nice to use. However, how does that fit with Josh Sled's simple roadmap explanation after G2? E.g., We've been really focused on the G2 port and 2.0, and intentionally haven't talked with too much rigor about post-2.0, at the same time there's been a lot of discussion over the last year or so, and I think it breaks out like: ... - Scheme removal ... - Fix modularity system cutpasted from http://www.mail-archive.com/gnucash-devel@gnucash.org/msg12143.html Is Scheme/Guile staying in or going out? Would e-guile be deleted within the year and replaced? Sincerely, Brian -- Contagious Design! web . design . photo Brian Rose . web programmer (604)-630-2426 . brianATcontagiousdesignDOTnet ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: E-guile link
IMNSHO, what Josh means is that the WAY gnucash uses guile needs to be fixed, and the way that gnucash is so /dependent/ on guile needs to be fixed. Guile needs to be removed from the startup sequence. Gnucash needs to depend LESS upon guile. But I don't EVER see guile being /completely/ removed. I definitely do not believe that eguile would be ripped out in a year. -derek Quoting Brian Rose [EMAIL PROTECTED]: Hi Derek, FYI, the e-guile link is back up: http://woozle.org/~neale/repos/eguile/eguile.html I looked at it. It appears intuitive and nice to use. However, how does that fit with Josh Sled's simple roadmap explanation after G2? E.g., We've been really focused on the G2 port and 2.0, and intentionally haven't talked with too much rigor about post-2.0, at the same time there's been a lot of discussion over the last year or so, and I think it breaks out like: ... - Scheme removal ... - Fix modularity system cutpasted from http://www.mail-archive.com/gnucash-devel@gnucash.org/msg12143.html Is Scheme/Guile staying in or going out? Would e-guile be deleted within the year and replaced? Sincerely, Brian -- Contagious Design! web . design . photo Brian Rose . web programmer (604)-630-2426 . brianATcontagiousdesignDOTnet ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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: E-guile link
On Tue, 2005-11-01 at 06:16 -0800, Brian Rose wrote: Is Scheme/Guile staying in or going out? Would e-guile be deleted within the year and replaced? :) Good question. In my ideal world, we would remove it entirely and find a different, light-weight templating system for the reports ... something like Template-Toolkit. At the same time, my list was my opinion only. and a little rushed... others don't have quite the desire for scheme-elimination that I do. :) My major objection to the prevalence of scheme in gnucash is in other locations than the reporting. I could certainly see scheme being removed everywhere *but* the templating of the reports via eguile. As well, we could have more than one mechanism for templating reports, especially if the bulk of the reports were already in one technology. I don't think there's a high probability of it being removed w/in a year, were it to occur. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: E-guile link
Title: RE: E-guile link I have no opinion about using scheme or not for anything, but if there are folks who want to get rid of it; we can evaluate the use of XSLT as a templating engine. I've used it and it's okay but I suspect that eguile is much more flexible. Tracy. -Original Message- From: [EMAIL PROTECTED] on behalf of Josh Sled Sent: Tue 11/1/2005 7:43 AM To: Brian Rose Cc: gnucash-devel@lists.gnucash.org Subject: Re: E-guile link On Tue, 2005-11-01 at 06:16 -0800, Brian Rose wrote: Is Scheme/Guile staying in or going out? Would e-guile be deleted within the year and replaced? :) Good question. In my ideal world, we would remove it entirely and find a different, light-weight templating system for the reports ... something like Template-Toolkit. At the same time, my list was my opinion only. and a little rushed... others don't have quite the desire for scheme-elimination that I do. :) My major objection to the prevalence of scheme in gnucash is in other locations than the reporting. I could certainly see scheme being removed everywhere *but* the templating of the reports via eguile. As well, we could have more than one mechanism for templating reports, especially if the bulk of the reports were already in one technology. I don't think there's a high probability of it being removed w/in a year, were it to occur. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] ___ 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: E-guile link
Nah, might as well focus on eguile in the short term. -derek Tracy Brown [EMAIL PROTECTED] writes: I have no opinion about using scheme or not for anything, but if there are folks who want to get rid of it; we can evaluate the use of XSLT as a templating engine. I've used it and it's okay but I suspect that eguile is much more flexible. Tracy. -Original Message- From: [EMAIL PROTECTED] on behalf of Josh Sled Sent: Tue 11/1/2005 7:43 AM To: Brian Rose Cc: gnucash-devel@lists.gnucash.org Subject: Re: E-guile link On Tue, 2005-11-01 at 06:16 -0800, Brian Rose wrote: Is Scheme/Guile staying in or going out? Would e-guile be deleted within the year and replaced? :) Good question. In my ideal world, we would remove it entirely and find a different, light-weight templating system for the reports ... something like Template-Toolkit. At the same time, my list was my opinion only. and a little rushed... others don't have quite the desire for scheme-elimination that I do. :) My major objection to the prevalence of scheme in gnucash is in other locations than the reporting. I could certainly see scheme being removed everywhere *but* the templating of the reports via eguile. As well, we could have more than one mechanism for templating reports, especially if the bulk of the reports were already in one technology. I don't think there's a high probability of it being removed w/in a year, were it to occur. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] ___ 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 -- 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: E-guile link
On Tuesday 01 November 2005 6:34 pm, Derek Atkins wrote: Nah, might as well focus on eguile in the short term. -derek Tracy Brown [EMAIL PROTECTED] writes: I have no opinion about using scheme or not for anything, but if there are folks who want to get rid of it; we can evaluate the use of XSLT as a templating engine. I've used it and it's okay but I suspect that eguile is much more flexible. You can always use XSLT for your own customised reports and if, once you have G2 installed, you create XSL stylesheets for QSF that you think could be useful to others, feel free to let me know. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpSkBCFwZc4L.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
E-guile link
FYI, the e-guile link is back up: http://woozle.org/~neale/repos/eguile/eguile.html -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-changes] Remove guile - cashutil sync.
On Sat, 2005-01-10 at 17:27 -0400, Chris Shoemaker wrote:
On Sat, Oct 01, 2005 at 09:43:29PM +0100, Neil Williams wrote:
On Saturday 01 October 2005 8:58 pm, Chris Shoemaker wrote:
+int
+main (int argc, char **argv)
{
+ qof_init();
+ if(cashobjects_register()) {
test_query_core();
test_class();
test_querynew();
Displays inline in each of the editors I use.
src/engine/test/test-querynew.c
qof_init();
if(cashobjects_register()) {
test_query_core();
test_class();
test_querynew();
}
Um, nobody cares what your editor shows you except you. What matters
is what's in the file. When I said please fix your editor I meant:
make it easier for you to detect when your change is inconsistent with
the surrounding code. Your patch will clearly produce a file with
inconsistent indentation. Readability matters.
I realize that it will be difficult for you to fix this
after-the-fact. I suggest reverting the patch until you can verify
that your patches don't screw up indentation.
(BTW, consistent treatment of whitespace is necessary for
collaboration in almost any software project.)
-chris
___
Neil, Try changing the default tab size and see how YOUR editor shows
the inconsistencies. I have been using scite for my main editor, it
shows when tabs are mixed with spaces in the same code block. It also
has the option to use spaces in place of tabs when you use the tab key.
It helps keep things consistent.
--
Brian [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] Remove guile - cashutil sync.
On Sat, Oct 01, 2005 at 09:43:29PM +0100, Neil Williams wrote:
On Saturday 01 October 2005 8:58 pm, Chris Shoemaker wrote:
+int
+main (int argc, char **argv)
{
+ qof_init();
+ if(cashobjects_register()) {
test_query_core();
test_class();
test_querynew();
Displays inline in each of the editors I use.
src/engine/test/test-querynew.c
qof_init();
if(cashobjects_register()) {
test_query_core();
test_class();
test_querynew();
}
Um, nobody cares what your editor shows you except you. What matters
is what's in the file. When I said please fix your editor I meant:
make it easier for you to detect when your change is inconsistent with
the surrounding code. Your patch will clearly produce a file with
inconsistent indentation. Readability matters.
I realize that it will be difficult for you to fix this
after-the-fact. I suggest reverting the patch until you can verify
that your patches don't screw up indentation.
(BTW, consistent treatment of whitespace is necessary for
collaboration in almost any software project.)
-chris
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: guile docs for gnucash
Brian [EMAIL PROTECTED] writes: That did it, Thanks... I did an install to /opt and that seems to work fine. Now to complete some of the changes. My other question still persists. Is there any documentation for the guile portion... logic diagrams... anything? Not really, no. :( At least none that I know of, but there might be something in the various doc directories of the source tree. Feel free to write docs as you go along. I know you would like us to make some of the code changes and submit them for a lot of these little changes, but it would make it a lot easier if we had something other than the hunt and peck method. Yea, I know. The code has never been well documented. There has been some effort lately to doxygenize the sources, but that only affects the C code, not the scheme code. -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
guile docs for gnucash
Is there any documentation of the guile modules? I have been going nuts trying to figure out some of variables, where they are originally defined, etc.. To add some business preferences such as company-phone, company-fax, etc. to be used in printing invoices, etc.. I have found 2 files so far, business-prefs.scm, business-utils.scm It seems that the variables are first defined in business-utils.scm, and exported from there (no errors generated from there). The business-prefs.scm file is used to feed the preferences dialog. Opening the Preferences dialog crashes gnucash complaining about an unbound variable. I have grepped thru everything but cannot seem to find out any other clues as to how to proceed. -- Brian [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: guile docs for gnucash
Do you properly (export) your variable? What is the error you see? -derek Brian [EMAIL PROTECTED] writes: Is there any documentation of the guile modules? I have been going nuts trying to figure out some of variables, where they are originally defined, etc.. To add some business preferences such as company-phone, company-fax, etc. to be used in printing invoices, etc.. I have found 2 files so far, business-prefs.scm, business-utils.scm It seems that the variables are first defined in business-utils.scm, and exported from there (no errors generated from there). The business-prefs.scm file is used to feed the preferences dialog. Opening the Preferences dialog crashes gnucash complaining about an unbound variable. I have grepped thru everything but cannot seem to find out any other clues as to how to proceed. -- 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: guile docs for gnucash
On Thu, 2005-19-05 at 12:23 -0400, Derek Atkins wrote: Do you properly (export) your variable? What is the error you see? -derek gnucash: [D] Running functions on hook ui-post-startup-hook #procedure business-ui-started () Backtrace: In unknown file: ?: 0* [#procedure #f ()] In /usr/share/gnucash/scm/main-window.scm: 205: 1* (let* (# #) (letrec # #)) In unknown file: ?: 2 (letrec ((changed_cb #)) (gnc:kvp-option-dialog gnc:id-book slots ...) ) ... ?: 3 [gnc:kvp-option-dialog # # Book Options ...] In /usr/share/gnucash/guile-modules/gnucash/gnome-utils.scm: 26: 4 (let* (# # #) (define # # #) (define # # #) ...) 26: 5* [gnc:make-kvp-options #gw:wcp gnc:id-type 0xb76a008a] In /usr/share/gnucash/scm/kvp-option-registry.scm: 54: 6 (let ((gen-list #) (options #)) (map (lambda # #) gen-list) options) 56: 7* [map #procedure #f (generator) (#procedure book-options-generator # )] In unknown file: ?: 8 (if (null? rest) (map1 f list1) ...) ... ?: 9 (let ((ret (list #))) (letrec ((lp #)) (lp (cdr ls) ret))) ?: 10* [list ... ?: 11* [#procedure #f # #procedure book-options-generator #] In /usr/share/gnucash/scm/kvp-option-registry.scm: 58: 12 [book-options-generator #procedure dispatch (key)] In unknown file: ?: 13 (letrec (#) (reg-option #) (reg-option #) ...) In /usr/share/gnucash/scm/business-prefs.scm: 106: 14* [reg-option ... 107: 15* [gnc:make-string-option Business ... /usr/share/gnucash/scm/business-prefs.scm:107:4: While evaluating arguments to gnc:make-string-option in expression (gnc:make-string-option gnc:*business-label* gnc:*company-phone* ...): /usr/share/gnucash/scm/business-prefs.scm:107:4: Unbound variable: gnc:*company-phone* bash-2.05b$ from business-utils.scm: (define gnc:*business-label* (N_ Business)) (define gnc:*company-name* (N_ Company Name)) (define gnc:*company-addy* (N_ Company Address)) (define gnc:*company-phone* (N_ Company Phone Number)) (define gnc:*company-fax* (N_ Company Fax Number)) (define gnc:*company-url* (N_ Company Website URL)) (define gnc:*company-email* (N_ Company Email Address)) (define gnc:*company-contact* (N_ Company Contact Person)) (export gnc:*business-label* gnc:*company-name* gnc:*company-addy*) (export gnc:*company-phone* gnc:*company-fax* gnc:*company-url*) (export gnc:*company-email* gnc:*company-contact*) From business-prefs.scm: (reg-option (gnc:make-text-option gnc:*business-label* gnc:*company-addy* b (N_ The address of your business) )) (reg-option (gnc:make-string-option gnc:*business-label* gnc:*company-phone* p (N_ The Phone Number of your business) )) [/snip] etc,etc. I just copy and pasted an existing, then edited each addition. Once I get this working I'll work on the report side. Also Is there a way to make the Company Name input field, etc wider? Our company name has to scroll thru using the cursor to see or edit what does not show. Brian [EMAIL PROTECTED] writes: Is there any documentation of the guile modules? I have been going nuts trying to figure out some of variables, where they are originally defined, etc.. To add some business preferences such as company-phone, company-fax, etc. to be used in printing invoices, etc.. I have found 2 files so far, business-prefs.scm, business-utils.scm It seems that the variables are first defined in business-utils.scm, and exported from there (no errors generated from there). The business-prefs.scm file is used to feed the preferences dialog. Opening the Preferences dialog crashes gnucash complaining about an unbound variable. I have grepped thru everything but cannot seem to find out any other clues as to how to proceed. -- Brian [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: guile docs for gnucash
Quoting Brian [EMAIL PROTECTED]: On Thu, 2005-19-05 at 12:23 -0400, Derek Atkins wrote: Do you properly (export) your variable? What is the error you see? [snip] 107: 15* [gnc:make-string-option Business ... /usr/share/gnucash/scm/business-prefs.scm:107:4: While evaluating arguments to gnc:make-string-option in expression (gnc:make-string-option gnc:*business-label* gnc:*company-phone* ...): /usr/share/gnucash/scm/business-prefs.scm:107:4: Unbound variable: gnc:*company-phone* bash-2.05b$ Yep, the symbol isn't available at runtime from business-utils.scm: [snip] (export gnc:*business-label* gnc:*company-name* gnc:*company-addy*) (export gnc:*company-phone* gnc:*company-fax* gnc:*company-url*) (export gnc:*company-email* gnc:*company-contact*) [snip] [/snip] etc,etc. I just copy and pasted an existing, then edited each addition. Are you sure you ran a make install to get your files into the install tree? The file above is /usr/share/gnucash/scm/business-prefs.scm which would seem to imply it's from the distro version and not your own version. Once I get this working I'll work on the report side. Also Is there a way to make the Company Name input field, etc wider? Our company name has to scroll thru using the cursor to see or edit what does not show. Unfortunately no, there's no way to make that input field bigger. -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: guile docs for gnucash
On Thu, 2005-19-05 at 19:31 -0400, Derek Atkins wrote: Are you sure you ran a make install to get your files into the install tree? The file above is /usr/share/gnucash/scm/business-prefs.scm which would seem to imply it's from the distro version and not your own version. -derek I renamed the original 2 files with .orig appended then copied the 2 modified ones there to test. Do I have to make everything with the modified files? I thought one of the points about using guile is not having to re-compile, but I don't know how the variables are handled thru the c code for saving in the file etc.. -- Brian [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: guile docs for gnucash
Quoting Brian [EMAIL PROTECTED]: On Thu, 2005-19-05 at 19:31 -0400, Derek Atkins wrote: Are you sure you ran a make install to get your files into the install tree? The file above is /usr/share/gnucash/scm/business-prefs.scm which would seem to imply it's from the distro version and not your own version. -derek I renamed the original 2 files with .orig appended then copied the 2 modified ones there to test. Do I have to make everything with the modified files? I thought one of the points about using guile is not having to re-compile, but I don't know how the variables are handled thru the c code for saving in the file etc.. No, you do not need to recompile, but you DO need to install the modified SCM files into the install tree (/usr/...). Having the .orig files in the install tree might be a bad idea, so you might want to remove them (or move them into your homedir or something). -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: guile docs for gnucash
On Thu, 2005-19-05 at 19:57 -0400, Derek Atkins wrote: Quoting Brian [EMAIL PROTECTED]: On Thu, 2005-19-05 at 19:31 -0400, Derek Atkins wrote: Are you sure you ran a make install to get your files into the install tree? The file above is /usr/share/gnucash/scm/business-prefs.scm which would seem to imply it's from the distro version and not your own version. -derek I renamed the original 2 files with .orig appended then copied the 2 modified ones there to test. Do I have to make everything with the modified files? I thought one of the points about using guile is not having to re-compile, but I don't know how the variables are handled thru the c code for saving in the file etc.. No, you do not need to recompile, but you DO need to install the modified SCM files into the install tree (/usr/...). Having the .orig files in the install tree might be a bad idea, so you might want to remove them (or move them into your homedir or something). -derek That did it, Thanks... I did an install to /opt and that seems to work fine. Now to complete some of the changes. My other question still persists. Is there any documentation for the guile portion... logic diagrams... anything? I know you would like us to make some of the code changes and submit them for a lot of these little changes, but it would make it a lot easier if we had something other than the hunt and peck method. -- Brian [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gdb command to decode guile SCM words?
Surely someone has written an interface from gdb into guile so that gdb can print out scheme data structures? If you google for gdb guile you find references to a plan to use scheme as a scripting language for gdb, and on the http://www.gnu.org/software/guile/ideas.html page you find GDB support for debugging Guile-using C code GDB actually has some Scheme support in there; we should teach it how to print Scheme values, how to print interpreter frames, and so on. This has been done in the past with a mixed GDB/Guile solution, but I think it would be more robust to actually put everything in GDB. Negotiate design with the GDB group, so it can be merged into Cygnus's sources. Does anyone have a quick way to print out lists in gdb? Right now I'm looking at tags.h in the guile source and I can recognize a heap address, an immediate string, and a few others, but it is a pain. --Ed Huff ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: annoying simple Guile question
On Wednesday 22 September 2004 4:23 am, you wrote: Neil Williams [EMAIL PROTECTED] writes: I'll look into that. TBH, I'm not sure why it is calling OpenSP, except that it is loading the current XML datasource files directly, without user intervention and without using Guile/Scheme/GUI. XML doesn't use OpenSP. The only thing I can think of that uses OpenSP is the OFX code. But you shouldn't be loading that at all. Erk. That is bad. I have no need or intention of calling OFX code - as it is obviously being called, this example will not make the next patch and I'll check future backtraces in other code for OpenSP - to be sure. Is a console demo/program/merge suitable for the main GnuCash tree? Sure... Great. Should it go in a new /examples or perhaps in /accounts? Neither. I'd suggest /bin, /experimental, or /optional. /experimental (It's certainly unfinished!) (I don't mind which, except that if it is outside GnuCash completely, it might make it harder to get it working when the XML backend is replaced - it'd lose the automation and have to save the XML to the filesystem for a later merge within GnuCash itself.) Well, it shouldn't depend on the XML backend even if it's embedded in the GnuCash tree. Sorry, I wasn't clear. XML as data interchange, not as a backend. If it's going to receive QofBook data from external sources, including pilot-link or via STDIN, it'll need the current XML parser, no matter what the backend becomes. As part of QOF, qof_book_merge has no need to know about specific GnuCash backends, only intermediary data formats. As we discussed originally, XML is ideally suited to this data interchange mode. Eh? You don't need to recompile the full GUI; you generally only need to recompile the library you're working on... Unless you're changing APIs. But I find I can make -C src/engine install and it works quite nicely. I'm learning all the time! :-) (I spent a lot of yesterday morning learning Glade - never used it before). Uh, Gnucash has plenty of test routines that load external files (as I said, check the tests in src/backend/file/test for examples. They work just fine, and they exit just fine when they are done. I suspect it's the early abort that is not cleaning up properly. Pity, I've *almost* got the replacement patch ready that includes the Glade and C code to wrap a QofBook* merge operation around an existing file and the output of the hierarchy druid! It works (with a few provisos) but now I'll have to either fix or remove the example before I submit the patch. Well, removing the example is pretty easy (IMHO). ;) :-) Not at 1am! I'll do it today. Although having a real test in place would be a good thing. Agreed. The current test-book-merge.c is (to quote another test program) only 'lightly testing' the framework. Question: do you still want me to apply that patch of yours from a few weeks ago? Or should I wait and apply the next one you plan to send? I've got all day tomorrow to sort it out - if it doesn't work I'll submit the patch tomorrow evening (BST) without it. I should have a patch ready later today - although some of the errors below won't get fixed by then. The patch is almost ready because I've still got GUI work to complete on the merge druid - I've got to complete the code to present the user intervention information and handle the input ready for the commit. Using radio buttons doesn't work, I need to replace them with ordinary buttons. Known problems with the merge druid so far: 1. First time crashes: For some reason, the first time you select a category, the code can cause a seg fault (in the hierarchy druid) - maybe 10% of the time. Next time you choose the same category, it works perfectly. How does it recover from a seg fault? (when you restart GnuCash). My point is that the crash is not easily reproducible. It appears to be the first run after a build has a risk of crashing. Subsequent runs seem OK - until the next make install. from the druid. I'm going to have to investigate delete_merge_group because it doesn't seem to be cleaning up properly (or else it's relying on a secondary process to do the clean up that is not called in the merge druid code). I'd guess the latter. It sounds like you're using the wrong data to merge into the existing book. I run the hierarchy druid to completion inside a second session then take the QofBook exactly as it is left by the druid. There must be a secondary step normally used by gnc_file_new() that I'm missing. The only changes I've made to druid-hierarchy.c are to allow the hierarchy druid to hand control back to the merge druid - because the second session is started by the merge druid. The hierarchy druid is now aware of the merge druid and behaves appropriately depending on whether the hierarchy druid was started directly (by File-New, without a second session) or indirectly (by File - New
Re: annoying simple Guile question
Neil Williams [EMAIL PROTECTED] writes: Well, it shouldn't depend on the XML backend even if it's embedded in the GnuCash tree. Sorry, I wasn't clear. XML as data interchange, not as a backend. If it's going to receive QofBook data from external sources, including pilot-link or via STDIN, it'll need the current XML parser, no matter what the backend becomes. As part of QOF, qof_book_merge has no need to know about specific GnuCash backends, only intermediary data formats. As we discussed originally, XML is ideally suited to this data interchange mode. AHHH.. Yes, indeed, XML is definitely suited to this. However your code still shouldn't assume XML, because a user may want to merge two PG databases together, or a PG and XML dataset, or an XML and SQLite (once that's implemented)... You should be able to use any Gnucash-supported backend to load data for merging. But yes, XML is still a great interchange format. Although having a real test in place would be a good thing. Agreed. The current test-book-merge.c is (to quote another test program) only 'lightly testing' the framework. That's ok -- it will still tell you if the framework is broken (if it's a good test). Question: do you still want me to apply that patch of yours from a few weeks ago? Or should I wait and apply the next one you plan to send? I've got all day tomorrow to sort it out - if it doesn't work I'll submit the patch tomorrow evening (BST) without it. I should have a patch ready later today - although some of the errors below won't get fixed by then. The patch is almost ready because I've still got GUI work to complete on the merge druid - I've got to complete the code to present the user intervention information and handle the input ready for the commit. Using radio buttons doesn't work, I need to replace them with ordinary buttons. That didn't answer my question, tho. Should I apply your outstanding patch or should I wait for the new one? Known problems with the merge druid so far: 1. First time crashes: For some reason, the first time you select a category, the code can cause a seg fault (in the hierarchy druid) - maybe 10% of the time. Next time you choose the same category, it works perfectly. How does it recover from a seg fault? (when you restart GnuCash). My point is that the crash is not easily reproducible. It appears to be the first run after a build has a risk of crashing. Subsequent runs seem OK - until the next make install. Oh, that's VERY weird. Unless it's a data-dependent file I can't think of ANY reason why it would do this. Unless you're writing self-modifying code. ;) Unless. you may have a race condition. The first time you run after an install the runtime loader needs to read everything from disk, which takes time. The second time you run everything is cached in memory so it runs much faster. Perhaps the load-delay due to the disk read is causing your failure because you're got a timing issue? Perhaps you're expecting something to get initialized but it's not being initialized fast enough when you're loading from disk? from the druid. I'm going to have to investigate delete_merge_group because it doesn't seem to be cleaning up properly (or else it's relying on a secondary process to do the clean up that is not called in the merge druid code). I'd guess the latter. It sounds like you're using the wrong data to merge into the existing book. I run the hierarchy druid to completion inside a second session then take the QofBook exactly as it is left by the druid. There must be a secondary step normally used by gnc_file_new() that I'm missing. The only changes I've made to druid-hierarchy.c are to allow the hierarchy druid to hand control back to the merge druid - because the second session is started by the merge druid. The hierarchy druid is now aware of the merge druid and behaves appropriately depending on whether the hierarchy druid was started directly (by File-New, without a second session) or indirectly (by File - New Account Hierarchy, which starts merge druid, the second session and then the hierarchy druid). Hmm, I'll have to look at the code. But not this week. 4. I've got some work to do with memory and g_free - the druid currently crashes if you run it twice within one GnuCash instance. Not good. :( I know. Almost certainly related to the confused data received from the druid - if I run the merge druid with dummy data and don't call the hierarchy druid, it can be run repeatedly (but then it's not doing a lot!). Not necessarily. It could be that the druid, once loaded, doesn't get destroyed but rather just hides itself to go away. If this is the case (I don't know, I haven't checked, and I don't plan to explore this myself -- I'm just suggesting avenues for you to explore) then if YOU are destroying the hierarchy druid yourself then the next time you try to run it it wont be
Re: annoying simple Guile question
On Wednesday 22 September 2004 2:56 pm, Derek Atkins wrote: AHHH.. Yes, indeed, XML is definitely suited to this. However your code still shouldn't assume XML, because a user may want to merge two PG databases together, or a PG and XML dataset, or an XML and SQLite (once that's implemented)... The code will merge any valid QofBook, no matter how it is presented. The console application that I will work on will be targetted at XML simply because I see that as the easiest for communication via pilot-link. There's nothing to stop it being adapted to accept other sources. The merge code itself is a library that can be used by any QOF aware program. Question: do you still want me to apply that patch of yours from a few weeks ago? Or should I wait and apply the next one you plan to send? That didn't answer my question, tho. Should I apply your outstanding patch or should I wait for the new one? The new one has just been sent and it completely replaces the one from the 27th August - which can now be forgotten. (when you restart GnuCash). My point is that the crash is not easily reproducible. It appears to be the first run after a build has a risk of crashing. Subsequent runs seem OK - until the next make install. Oh, that's VERY weird. Unless it's a data-dependent file I can't think of ANY reason why it would do this. Unless you're writing self-modifying code. ;) :-)) It's resolved now. I suspect it was just a messy build - in preparing the patch I tidy up what I've been coding and build in separate directories. This shows up all kinds of issues with things like the Makefile.am - it hasn't happened since. Unless. you may have a race condition. The first time you run after an install the runtime loader needs to read everything from disk, which takes time. The second time you run everything is cached in memory so it runs much faster. Perhaps the load-delay due to the disk read is causing your failure because you're got a timing issue? Perhaps you're expecting something to get initialized but it's not being initialized fast enough when you're loading from disk? I suspect there was a config error in an old file that got removed during further testing. (Unless it happens again, but I have tested the code in the patch with this in mind.) The only changes I've made to druid-hierarchy.c are to allow the hierarchy druid to hand control back to the merge druid - because the second session is started by the merge druid. The hierarchy druid is now aware of the merge druid and behaves appropriately depending on whether the hierarchy druid was started directly (by File-New, without a second session) or indirectly (by File - New Account Hierarchy, which starts merge druid, the second session and then the hierarchy druid). Hmm, I'll have to look at the code. But not this week. Thanks. I won't be doing much on this code for a week now myself - got to catch up on other projects. Not necessarily. It could be that the druid, once loaded, doesn't get destroyed but rather just hides itself to go away. If this is the case (I don't know, I haven't checked, and I don't plan to explore this myself -- I'm just suggesting avenues for you to explore) then if YOU are destroying the hierarchy druid yourself then the next time you try to run it it wont be there. *crash* It crashes within the second run of the account hierarchy druid (at the point where it is processing the user selection of example account trees), not when the merge druid loads. I will continue investigations. This is where I need the most help - when my code works fine alone but doesn't work alongside existing code. Even if the GUI isn't trouble-free I'd like to be able to submit it and get specific feedback on exactly where the problems lie. It's hard to discuss these errors when the full code isn't available to everyone. *nods* Bugs happen. Never expect your code to be perfect the first time through. :-)) Thank you for all your help with this, Derek. I know it hasn't been easy with a self-taught newbie asking daft questions each week! -- Neil Williams = http://www.codehelp.co.uk/ http://www.dclug.org.uk/ http://www.isbn.org.uk/ http://sourceforge.net/projects/isbnsearch/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3 pgplrN1TT5NwO.pgp Description: PGP signature ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: annoying simple Guile question
On Wednesday 22 September 2004 3:49 pm, Derek Atkins wrote: Thank you for learning and doing the work! How can we keep you interested in doing more work? I've got plenty more I'd like to do with the merge and GnuCash - just for now I need to give some time to other projects and certain important events that do have fixed deadlines - my tax return for 1! :-) -- Neil Williams = http://www.codehelp.co.uk/ http://www.dclug.org.uk/ http://www.isbn.org.uk/ http://sourceforge.net/projects/isbnsearch/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3 pgpI6BECpdsMH.pgp Description: PGP signature ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
annoying simple Guile question
When running a console application that uses guile via gnucash-env, how do I abort? I free the memory I used, I call gnc_engine_shutdown() but the program hangs, waiting for a Ctrl-C. I've checked and all the usual tidying up functions are called without errors - it exits normally when allowed to complete the program, but if there's an error or if the user simply wants to abort, I can't get it to exit. exit(1); is no help. I have put error handlers at the start of every function that would be called after the abort to cause the function to return if abort is set, no odds. The code itself has changed many times but this problem has remained since I started using it via guile to get access to the file backend to read the QofBook data from external files. It's the example code here: http://code.neil.williamsleesmill.me.uk/example-gncBookMerge.c (the new home for my code - codehelp doesn't have the space) (gdb) continue Continuing. Program received signal SIGINT, Interrupt. [Switching to Thread 16384 (LWP 30982)] 0x402b94fd in mallopt () from /lib/libc.so.6 #0 0x402b94fd in mallopt () from /lib/libc.so.6 #1 0x402b8d08 in mallopt () from /lib/libc.so.6 #2 0x402b7ef3 in malloc () from /lib/libc.so.6 #3 0x414ac2ee in operator new () from /usr/lib/libstdc++.so.5 #4 0x414ac41f in operator new[] () from /usr/lib/libstdc++.so.5 #5 0x415cd142 in OpenSP::Stringchar::resize () from /usr/lib/libosp.so.4 #6 0x415ccf8c in OpenSP::FileOutputByteStream::flush () from /usr/lib/libosp.so.4 #7 0x415ccf09 in OpenSP::FileOutputByteStream::close () from /usr/lib/libosp.so.4 #8 0x415ccd40 in OpenSP::FileOutputByteStream::~FileOutputByteStream () from /usr/lib/libosp.so.4 #9 0x41583c42 in OpenSP::CmdLineApp::closeFileErrorMessage () from /usr/lib/libosp.so.4 #10 0x40272ae2 in exit () from /lib/libc.so.6 #11 0x4010451d in scm_init_guile () from /usr/lib/libguile.so.12 #12 0x4010420b in scm_boot_guile () from /usr/lib/libguile.so.12 #13 0x0804a2da in main_helper (closure=0x1, argc=1077375036, argv=0x4037703c) at example-gncBookMerge.c:282 #14 0x4025cdc6 in __libc_start_main () from /lib/libc.so.6 #15 0x08049891 in ?? () -- Neil Williams = http://www.codehelp.co.uk/ http://www.dclug.org.uk/ http://www.isbn.org.uk/ http://sourceforge.net/projects/isbnsearch/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3 pgpI5K7JuW1WY.pgp Description: PGP signature ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: annoying simple Guile question
Neil Williams [EMAIL PROTECTED] writes: When running a console application that uses guile via gnucash-env, how do I abort? You mean how do you get the program to exit? You call exit(); in your C, or (exit) from guile. I free the memory I used, I call gnc_engine_shutdown() but the program hangs, waiting for a Ctrl-C. I've checked and all the usual tidying up functions are called without errors - it exits normally when allowed to complete the program, but if there's an error or if the user simply wants to abort, I can't get it to exit. exit(1); is no help. Uh, this is how you exit from ANY C program... I have put error handlers at the start of every function that would be called after the abort to cause the function to return if abort is set, no odds. The code itself has changed many times but this problem has remained since I started using it via guile to get access to the file backend to read the QofBook data from external files. It's the example code here: http://code.neil.williamsleesmill.me.uk/example-gncBookMerge.c (the new home for my code - codehelp doesn't have the space) (gdb) continue Continuing. Program received signal SIGINT, Interrupt. [Switching to Thread 16384 (LWP 30982)] 0x402b94fd in mallopt () from /lib/libc.so.6 #0 0x402b94fd in mallopt () from /lib/libc.so.6 #1 0x402b8d08 in mallopt () from /lib/libc.so.6 #2 0x402b7ef3 in malloc () from /lib/libc.so.6 #3 0x414ac2ee in operator new () from /usr/lib/libstdc++.so.5 #4 0x414ac41f in operator new[] () from /usr/lib/libstdc++.so.5 #5 0x415cd142 in OpenSP::Stringchar::resize () from /usr/lib/libosp.so.4 #6 0x415ccf8c in OpenSP::FileOutputByteStream::flush () From /usr/lib/libosp.so.4 #7 0x415ccf09 in OpenSP::FileOutputByteStream::close () From /usr/lib/libosp.so.4 #8 0x415ccd40 in OpenSP::FileOutputByteStream::~FileOutputByteStream () From /usr/lib/libosp.so.4 #9 0x41583c42 in OpenSP::CmdLineApp::closeFileErrorMessage () From /usr/lib/libosp.so.4 #10 0x40272ae2 in exit () from /lib/libc.so.6 #11 0x4010451d in scm_init_guile () from /usr/lib/libguile.so.12 #12 0x4010420b in scm_boot_guile () from /usr/lib/libguile.so.12 #13 0x0804a2da in main_helper (closure=0x1, argc=1077375036, argv=0x4037703c) at example-gncBookMerge.c:282 #14 0x4025cdc6 in __libc_start_main () from /lib/libc.so.6 #15 0x08049891 in ?? () Uh, how/why are you using OpenSP? It looks like OpenSP has an exit handler (via atexit()) which seems to be trying to flush a stream and hanging during a malloc call. Very odd -- you must be doing something different than GnuCash. Strangely, none of the other test programs have this problem, so I'd start looking at how you're being different than those. I'd start with the tests in the file backend. I'll also note that you might have a dependency issue if you're trying to load files from src/engine/test. -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 [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: annoying simple Guile question
On Tuesday 21 September 2004 9:11 pm, you wrote: Neil Williams [EMAIL PROTECTED] writes: Uh, how/why are you using OpenSP? It looks like OpenSP has an exit handler (via atexit()) which seems to be trying to flush a stream and hanging during a malloc call. I'll look into that. TBH, I'm not sure why it is calling OpenSP, except that it is loading the current XML datasource files directly, without user intervention and without using Guile/Scheme/GUI. The reason that this looks odd is because it started as a test program but has developed into somewhat of an interactive demo for the merge operations. The external files are new and the program needs to be put elsewhere. I'm hoping that the program will develop into a console tool to allow QofBook*s to be merged at the command line - using the GnuCash/QOF code but without the GUI. This could be useful for creating a pilot-link conduit for the final stage of the automation for generating invoices direct from a Palm (which is why I started this!). It may have other uses too. Is a console demo/program/merge suitable for the main GnuCash tree? Should it go in a new /examples or perhaps in /accounts? Should it be outside GnuCash entirely, perhaps a mini project or absorbed completely into pilot-link? (I don't mind which, except that if it is outside GnuCash completely, it might make it harder to get it working when the XML backend is replaced - it'd lose the automation and have to save the XML to the filesystem for a later merge within GnuCash itself.) I find it quite a useful debugging tool (quicker to recompile and test than the full GUI). I do have a more 'standardised' test routine that has none of these problems, mainly because it isn't interactive and therefore doesn't abort nor load external files. Very odd -- you must be doing something different than GnuCash. Console interactivity is probably to blame. Strangely, none of the other test programs have this problem, so I'd start looking at how you're being different than those. I'd start with the tests in the file backend. I'll also note that you might have a dependency issue if you're trying to load files from src/engine/test. Agreed. It's become too different to be in the current location. Pity, I've *almost* got the replacement patch ready that includes the Glade and C code to wrap a QofBook* merge operation around an existing file and the output of the hierarchy druid! It works (with a few provisos) but now I'll have to either fix or remove the example before I submit the patch. I've got all day tomorrow to sort it out - if it doesn't work I'll submit the patch tomorrow evening (BST) without it. The code itself is at: http://code.neil.williamsleesmill.me.uk/source.html qof_book_merge Source Code. * qof_book_merge.c * qof_book_merge.h * Test and example programs. This test file shows an implementation of the qof_book_merge API: * test-book-merge.c This example files shows an interactive console implementation using GnuCash objects: example-gncBookMerge.c + The example now uses external XML files as data sources: * druid-business.gnc * druid-simple.gnc These are simple GnuCash files, created using the New File druid. * A GUI example is available - to allow the New Account Hierarchy druid to be run over an existing file. + druid-merge.c - small changes required to window-main.c to allow for a menu item to call the druid. * merge.glade - the Glade code to describe the druid resource. Known problems with the merge druid so far: 1. First time crashes: For some reason, the first time you select a category, the code can cause a seg fault (in the hierarchy druid) - maybe 10% of the time. Next time you choose the same category, it works perfectly. 2. My GUI skills aren't the best so the druid behaviour is not ideal. 3. It's getting confused with the hierarchy druid output. Say you have a simple book open in GnuCash and select Childcare Expenses from the hierarchy druid to merge into your file. That's two accounts, Expenses (which will match an existing account) and Childcare. In the GUI, I get 63 collision reports. ??? Running the same files through the console application (I said it was handy!) generates the expected: 1 duplicate account, 1 possibly new account. Some of the collision reports list parameter data for Account objects that is clearly inherited from UNSELECTED accounts from the example list - they neither exist in the original book nor the selection from the druid. I'm going to have to investigate delete_merge_group because it doesn't seem to be cleaning up properly (or else it's relying on a secondary process to do the clean up that is not called in the merge druid code). 4. I've got some work to do with memory and g_free - the druid currently crashes if you run it twice within one GnuCash instance. :-( -- Neil Williams
Re: annoying simple Guile question
On some systems, there is either _exit() or kexit() that actually calls the OS's exit. If you are on a unix type system and want to get really nasty, you can do kill(getpid(), SIGKILL); But, even at that, a process can hang in the exit of the kernel. The best example is if you have output going to a terminal and you type ^S so the output is buffered up, a Posix compliant system will not let the process exit until the data has drained out. On Sep 21, 2004, at 3:11 PM, Derek Atkins wrote: Neil Williams [EMAIL PROTECTED] writes: When running a console application that uses guile via gnucash-env, how do I abort? You mean how do you get the program to exit? You call exit(); in your C, or (exit) from guile. I free the memory I used, I call gnc_engine_shutdown() but the program hangs, waiting for a Ctrl-C. I've checked and all the usual tidying up functions are called without errors - it exits normally when allowed to complete the program, but if there's an error or if the user simply wants to abort, I can't get it to exit. exit(1); is no help. Uh, this is how you exit from ANY C program... I have put error handlers at the start of every function that would be called after the abort to cause the function to return if abort is set, no odds. The code itself has changed many times but this problem has remained since I started using it via guile to get access to the file backend to read the QofBook data from external files. It's the example code here: http://code.neil.williamsleesmill.me.uk/example-gncBookMerge.c (the new home for my code - codehelp doesn't have the space) (gdb) continue Continuing. Program received signal SIGINT, Interrupt. [Switching to Thread 16384 (LWP 30982)] 0x402b94fd in mallopt () from /lib/libc.so.6 #0 0x402b94fd in mallopt () from /lib/libc.so.6 #1 0x402b8d08 in mallopt () from /lib/libc.so.6 #2 0x402b7ef3 in malloc () from /lib/libc.so.6 #3 0x414ac2ee in operator new () from /usr/lib/libstdc++.so.5 #4 0x414ac41f in operator new[] () from /usr/lib/libstdc++.so.5 #5 0x415cd142 in OpenSP::Stringchar::resize () from /usr/lib/libosp.so.4 #6 0x415ccf8c in OpenSP::FileOutputByteStream::flush () From /usr/lib/libosp.so.4 #7 0x415ccf09 in OpenSP::FileOutputByteStream::close () From /usr/lib/libosp.so.4 #8 0x415ccd40 in OpenSP::FileOutputByteStream::~FileOutputByteStream () From /usr/lib/libosp.so.4 #9 0x41583c42 in OpenSP::CmdLineApp::closeFileErrorMessage () From /usr/lib/libosp.so.4 #10 0x40272ae2 in exit () from /lib/libc.so.6 #11 0x4010451d in scm_init_guile () from /usr/lib/libguile.so.12 #12 0x4010420b in scm_boot_guile () from /usr/lib/libguile.so.12 #13 0x0804a2da in main_helper (closure=0x1, argc=1077375036, argv=0x4037703c) at example-gncBookMerge.c:282 #14 0x4025cdc6 in __libc_start_main () from /lib/libc.so.6 #15 0x08049891 in ?? () Uh, how/why are you using OpenSP? It looks like OpenSP has an exit handler (via atexit()) which seems to be trying to flush a stream and hanging during a malloc call. Very odd -- you must be doing something different than GnuCash. Strangely, none of the other test programs have this problem, so I'd start looking at how you're being different than those. I'd start with the tests in the file backend. I'll also note that you might have a dependency issue if you're trying to load files from src/engine/test. -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 [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: annoying simple Guile question
Neil Williams [EMAIL PROTECTED] writes: I'll look into that. TBH, I'm not sure why it is calling OpenSP, except that it is loading the current XML datasource files directly, without user intervention and without using Guile/Scheme/GUI. XML doesn't use OpenSP. The only thing I can think of that uses OpenSP is the OFX code. But you shouldn't be loading that at all. Is a console demo/program/merge suitable for the main GnuCash tree? Sure... Should it go in a new /examples or perhaps in /accounts? Neither. I'd suggest /bin, /experimental, or /optional. Should it be outside GnuCash entirely, perhaps a mini project or absorbed completely into pilot-link? I'm not sure pilot-link is the right place for it. But standalone is certainly another option. (I don't mind which, except that if it is outside GnuCash completely, it might make it harder to get it working when the XML backend is replaced - it'd lose the automation and have to save the XML to the filesystem for a later merge within GnuCash itself.) Well, it shouldn't depend on the XML backend even if it's embedded in the GnuCash tree. I find it quite a useful debugging tool (quicker to recompile and test than the full GUI). Eh? You don't need to recompile the full GUI; you generally only need to recompile the library you're working on... Unless you're changing APIs. But I find I can make -C src/engine install and it works quite nicely. I do have a more 'standardised' test routine that has none of these problems, mainly because it isn't interactive and therefore doesn't abort nor load external files. Uh, Gnucash has plenty of test routines that load external files (as I said, check the tests in src/backend/file/test for examples. They work just fine, and they exit just fine when they are done. Console interactivity is probably to blame. Could be. I don't know. Pity, I've *almost* got the replacement patch ready that includes the Glade and C code to wrap a QofBook* merge operation around an existing file and the output of the hierarchy druid! It works (with a few provisos) but now I'll have to either fix or remove the example before I submit the patch. Well, removing the example is pretty easy (IMHO). ;) Although having a real test in place would be a good thing. Question: do you still want me to apply that patch of yours from a few weeks ago? Or should I wait and apply the next one you plan to send? I've got all day tomorrow to sort it out - if it doesn't work I'll submit the patch tomorrow evening (BST) without it. Ok. Known problems with the merge druid so far: 1. First time crashes: For some reason, the first time you select a category, the code can cause a seg fault (in the hierarchy druid) - maybe 10% of the time. Next time you choose the same category, it works perfectly. How does it recover from a seg fault? 2. My GUI skills aren't the best so the druid behaviour is not ideal. :( 3. It's getting confused with the hierarchy druid output. Say you have a simple book open in GnuCash and select Childcare Expenses from the hierarchy druid to merge into your file. That's two accounts, Expenses (which will match an existing account) and Childcare. In the GUI, I get 63 collision reports. ??? Running the same files through the console application (I said it was handy!) generates the expected: 1 duplicate account, 1 possibly new account. Some of the collision reports list parameter data for Account objects that is clearly inherited from UNSELECTED accounts from the example list - they neither exist in the original book nor the selection from the druid. I'm going to have to investigate delete_merge_group because it doesn't seem to be cleaning up properly (or else it's relying on a secondary process to do the clean up that is not called in the merge druid code). I'd guess the latter. It sounds like you're using the wrong data to merge into the existing book. 4. I've got some work to do with memory and g_free - the druid currently crashes if you run it twice within one GnuCash instance. Not good. :( -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 [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Guile 1.5.6 beta available for testing.
From: Rob Browning [EMAIL PROTECTED] Date: Tue, 05 Mar 2002 17:24:23 -0600 * Remove automake and autoconf from your path, or turn off their execute bits, or something. (Users must be able to build from the tarfile without installing those tools.) absent system dir write privs, here's something you can do: mkdir /tmp/stub cat /tmp/stub/do-nothing EOF #!/bin/sh echo warning: $0 called exit 0 EOF chmod +x /tmp/stub/do-nothing ln /tmp/stub/do-nothing /tmp/stub/automake ln /tmp/stub/do-nothing /tmp/stub/autoconf# etc PATH=/tmp/stub:$PATH thi ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
gnucash-1.6.0 build problem with some guile versions
scm_long_long2num and its inverse are only compiled when LONGLONGS is defined in guile-1.3.4; this isn't the default. The attached allows gnucash to build on such a system (otherwise it tries to link in functions that don't exist...) Bill --- gnucash-1.6.0/configure.in.foo Mon Jun 18 23:05:27 2001 +++ gnucash-1.6.0/configure.in Mon Jun 18 23:05:29 2001 @@ -549,7 +549,9 @@ } ],[ AC_MSG_RESULT(yes) - AC_DEFINE(GUILE_LONG_LONG_OK,1,is sizeof(long_long) = sizeof(gint64)) + AC_CHECK_LIB(guile, scm_long_long2num, + AC_DEFINE(GUILE_LONG_LONG_OK,1,is sizeof(long_long) = + sizeof(gint64))) ],[ AC_MSG_RESULT(no) ])
Re: g-wrap fails to install because of guile
I think you need to install 'slib'. Sounds like g-wrap configure
needs to be modified to look for slib and complain if not installed.
--linas
It's been rumoured that David John Murchie said:
Let's just say this has more than frustrated me.
I get the following message...
=cut===
Making all in g-wrapped
make[2]: Entering directory `/usr/local/src/g-wrap-1.1.9/g-wrapped'
guile -c \
"(set! %load-path (cons
\"/usr/local/src/g-wrap-1.1.9/g-wrapped/..\" %load-path))""(use-modules
(g-wrap)) \
(use-modules (g-wrapped gw-runtime-spec)) \
(gw:generate-module \"gw-runtime\")"
ERROR: In procedure gsubr-apply in expression (scm-error (quote
misc-error) #f ...):
ERROR: Could not find slib/require.scm in
("/usr/local/src/g-wrap-1.1.9/g-wrapped/.."
"/usr/local/share/guile/site" "/usr/local/share/guile/1.3"
"/usr/local/share/guile" ".")
make[2]: *** [gw-runtime.c] Error 2
make[2]: Leaving directory `/usr/local/src/g-wrap-1.1.9/g-wrapped'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/g-wrap-1.1.9'
make: *** [all-recursive-am] Error 2
uncut
I cannot install gnucash cause g-wrap is not installed properly. I
can't install g-wrap cause guile is not working.
This is the second time I have attempted to install gnucash, can anyone
help?
Using slackware, all sources from the gnucash site.
Thanks in advance,
David
___
gnucash-user mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-user
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
latest g-wrap does not work with guile 1.3 on RH 6.2
Hi, I'm trying to build the latest GnuCash on Red Hat 6.2 but g-wrap seems to have dropped support for guile 1.3. I don't want to update my guile subsystem because I want to remain as close to "native 6.2" as possible (also because I still want to build the 1.4 RPMs as they are released). So, in order to continue working on GnuCash I need to get g-wrap support for guile 1.3. It _used_ to be there. GnuCash even had tests for the old v. new smob format. I just don't know enough about g-wrap to know where to start looking, or even how to test it (short of trying to build GnuCash and failing). Any help would be appreciated. -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 [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
guile i18n
I have implemented a new way of using gettext from scheme files that is easier to use than the string databases that are currently used in, for example, the reports. Essentially, it works the same way as in C. To mark a string as translatable and load the translation at the same time, use the '_' function: (display (_ "Hello, World")) ;; print the appropriate translation ;; of "Hello, World" To makr a string as translatable without loading the translatable, use the 'N_' function: (define hello (N_ "Hello, World")) ;; mark "Hello, World" as ;; a translatable string ;; hello == "Hello, World" (display (_ hello));; print the appropriate ;; translation of "Hello, World" The strings will be automatically collect statically during the build process. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: guile i18n
On Thu, Dec 21, 2000 at 12:59:58AM -0800, Dave Peticolas wrote: (display (_ "Hello, World")) ;; print the appropriate translation ;; of "Hello, World" Thanks Dave! you're a god. b.g. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Hardwired path in src/guile/Makefile.am
Dave Peticolas [EMAIL PROTECTED] writes: I'm not sure why it's there -- I can build fine and I installed g-wrap in /usr. It's there beacuse that's where I install g-wrap, but it does need to be generalized. It needs to encode the g-wrap module dir, which is available via g-wrap-config. We already have a Makefile var with that value that's determined in configure.in that we use in generating gnucash.c.in. We just need to add it to this Makefile.am. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Hardwired path in src/guile/Makefile.am
Robert Graham Merkel writes: The following code in latest CVS src/guile/Makefile.am is kinda machine-speci fic . . . FLAVOR=gnome guile -c \ '(set! %load-path (cons "/usr/local/opt/g-wrap/share/guile" %load-p ath)) \ (primitive-load "./gnc.gwp") \ (gw:generate-module "gnc")' CLEANFILES += gnc.h gnc.c gnc.html gnc-autogen.h How do you want to fix it?? I'm not sure why it's there -- I can build fine and I installed g-wrap in /usr. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Hardwired path in src/guile/Makefile.am
The following code in latest CVS src/guile/Makefile.am is kinda machine-specific . . . FLAVOR=gnome guile -c \ '(set! %load-path (cons "/usr/local/opt/g-wrap/share/guile" %load-path)) \ (primitive-load "./gnc.gwp") \ (gw:generate-module "gnc")' CLEANFILES += gnc.h gnc.c gnc.html gnc-autogen.h How do you want to fix it?? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: g-wrap and guile-gnome/gtk
Ariel Rios [EMAIL PROTECTED] writes: If there is a way of having a performance icnrease it would be even better ;) I am interested in doing the Corba /ORBit bindings using g-wrap or whatever new schema we came up with Well, I think we can probably separate this into two issues. 1) What should an API spec look like (say for gtk, glib, opengl, curses, etc.). 2) How should the implementation work? (i.e. we can potentially change that for performance later in any way we like without having to change the spec). Also, after noticing the in, out, inout, arg bits of your latest .defs proposal, it looks like it's somewhat mirroring other IDLs (of which, I'm only really passingly familiar with ILU). One thing I've wondered about for a while now is whether or not it might make sense to mirror (in scheme forms) the semantics of one of the IDLs (CORBA being the biggest elephant on the block). However, on the other side of that fence, I also wonder, whether or not there might be a legitimate place for a tool (and perhaps g-wrap should be that tool), that's exclusively focused on providing very well integrated, efficient, and clear (both in specification and in execution) bindings for C APIs from guile. Basically the question comes down to "Is it possible in this case to server all masters well?". Or in more concrete terms, say I were to try to do something very CORBA-esque with g-wrap's spec. Would I end up with a tool that was much more complex, harder to implement and understand, and didn't really provide any substantial improvments as compared to a tool that's specifically aimed at just the guile-C API problem? I don't really know, and I'd love to hear arguments either way. To a substantial extent, I'm not the best person to evaluate this argument, since I have little or no experience with CORBA, though I've done plenty of DO/RPC related work. Thanks -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile 1.3 + G-wrap 0.9.8 patches
Robert Graham Merkel [EMAIL PROTECTED] writes: Yeah, it's just that I was trying not to *force* people to upgrade their g-wrap if don't have to. If we put in a call in gnucash to an autoconf macro only distributed with 0.9.8, they have to upgrade. I have no objection to including the code in our acinclude; I think that's a great idea. Just so long as there wont be a conflict once people do upgrade to g-wrap 0.9.8 I'll go test it to make sure that the acinclude addition doesn't cause the build to fail. One thing that's come as a rude shock to me since working on gnucash is just how many problems changing dependancies cause. It really drives people nuts :) Tell me about it. Changing dependencies drives me nuts, too. :) -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 N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile 1.3 + G-wrap 0.9.8 patches
Dave Peticolas [EMAIL PROTECTED] writes: I have added the patch to the devel tree and placed the patched version of g-wrap.m4 in acinclude.m4. In the long run, though, g-wrap.m4 should be picked up from the installation of g-wrap, I think. It is, at least in g-wrap 0.9.8. If you'd like, I can upload the 0.9.8 RPMs (built on RH 6.2) -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 N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile 1.3 + G-wrap 0.9.8 patches
Derek Atkins writes: Dave Peticolas [EMAIL PROTECTED] writes: I have added the patch to the devel tree and placed the patched version of g-wrap.m4 in acinclude.m4. In the long run, though, g-wrap.m4 should be picked up from the installation of g-wrap, I think. It is, at least in g-wrap 0.9.8. If you'd like, I can upload the 0.9.8 RPMs (built on RH 6.2) Yeah, it's just that I was trying not to *force* people to upgrade their g-wrap if don't have to. If we put in a call in gnucash to an autoconf macro only distributed with 0.9.8, they have to upgrade. One thing that's come as a rude shock to me since working on gnucash is just how many problems changing dependancies cause. It really drives people nuts :) Robert Merkel [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile hacking -- accessing backtrace environment frames?
Rob Browning [EMAIL PROTECTED] writes: Derek Atkins [EMAIL PROTECTED] writes: OK, without me actually testing anything, just poking around, how about the "Debugger options" section of the guile info pages? Does that help? I see there's a way to turn on backtracing on error. I think we may turn that off in gnucash unless the --debug option is enabled. I've looked there already -- it's, umm, minimalistic at best, and useless at worst. Backtracing is already turned on, but I want to be able to get to a particular stack frame and look at the local environent. The Debugger Options doesn't show or explain how to do that. Indeed, most of the debugger is undocumented. Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -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 N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile hacking -- accessing backtrace environment frames?
Dave Peticolas [EMAIL PROTECTED] writes: Right. I just checked in some changes to src/guile/gnucash.c.in that makes running as a shell easier. Now, gnucash loads the same startup files regardless of whether it's running as a shell or not. The only difference is whether it invokes gnc:main or drops to the guile shell. Ahh, so I don't need to run my script anymore? Cool! -derek #!/bin/sh export GNC_DEBUG=t export GNC_RUN_AS_SHELL=t export GNC_BOOTSTRAP_SCM=/var/tmp/gnucash/share/gnucash/scm/bootstrap.scm cat EOF Try running the following code in guile: (primitive-load (getenv "GNC_BOOTSTRAP_SCM")) (gnc:load "startup.scm") (gnc:main) EOF # Run whichever one was built last. exec /var/tmp/gnucash/bin/gnucash \ --debug \ "$@" dave -- 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 N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile hacking -- accessing backtrace environment frames?
Derek Atkins writes: Dave Peticolas [EMAIL PROTECTED] writes: Right. I just checked in some changes to src/guile/gnucash.c.in that makes running as a shell easier. Now, gnucash loads the same startup files regardless of whether it's running as a shell or not. The only difference is whether it invokes gnc:main or drops to the guile shell. Ahh, so I don't need to run my script anymore? Cool! That's the idea, yeah. Let me know if there are problems. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile 1.3 + G-wrap 0.9.8 patches
Robert Graham Merkel writes: Derek Atkins writes: Ok, I've sucessfully got the mainline version of GnuCash to build against g-wrap 0.9.8. I had to apply the following patches to GnuCash and g-wrap respectively. I've also built a set of RPMs for RedHat 6.2 (using my own spec-file which I created back in 0.9.1 days back in May -- I have no idea why Mark didn't start with what I've done). In any event, I've improved it a bit and separated out g-wrap from g-wrap-devel, in case we want to compile with shared libraries. I'd be more than happy to give anyone the RPMS, SRPMS, or SpecFile as necessary. Hopefully my changes (both to g-wrap.m4 and g-wrap.spec) can get merged back into the g-wrap package. Thanks very much for the patch. One minor point with the patch to gnucash, though - it'll mean that gnucash now depends on g-wrap = 0.9.8. Dave, if this is a problem, all you have to do is add the autoconf test from g-wrap.m4 to gnucash's acinclude.m4. I have added the patch to the devel tree and placed the patched version of g-wrap.m4 in acinclude.m4. In the long run, though, g-wrap.m4 should be picked up from the installation of g-wrap, I think. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Guile 1.3 + G-wrap 0.9.8 patches
Derek Atkins writes: Ok, I've sucessfully got the mainline version of GnuCash to build against g-wrap 0.9.8. I had to apply the following patches to GnuCash and g-wrap respectively. I've also built a set of RPMs for RedHat 6.2 (using my own spec-file which I created back in 0.9.1 days back in May -- I have no idea why Mark didn't start with what I've done). In any event, I've improved it a bit and separated out g-wrap from g-wrap-devel, in case we want to compile with shared libraries. I'd be more than happy to give anyone the RPMS, SRPMS, or SpecFile as necessary. Hopefully my changes (both to g-wrap.m4 and g-wrap.spec) can get merged back into the g-wrap package. Thanks very much for the patch. One minor point with the patch to gnucash, though - it'll mean that gnucash now depends on g-wrap = 0.9.8. Dave, if this is a problem, all you have to do is add the autoconf test from g-wrap.m4 to gnucash's acinclude.m4. Robert Merkel [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile hacking -- accessing backtrace environment frames?
Dave Peticolas [EMAIL PROTECTED] writes: Right. I just checked in some changes to src/guile/gnucash.c.in that makes running as a shell easier. Now, gnucash loads the same startup files regardless of whether it's running as a shell or not. The only difference is whether it invokes gnc:main or drops to the guile shell. OK. In the "old days" I hadn't done that because you wanted to be able to debug the startup functions from guile, but I don't think that's really a big issue anymore, and we can always add an option like --no-X that brings you up to a "minimal" prompt later if we need it. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile 1.3 + G-wrap 0.9.8 patches
Robert Graham Merkel writes: Derek Atkins writes: Ok, I've sucessfully got the mainline version of GnuCash to build against g-wrap 0.9.8. I had to apply the following patches to GnuCash and g-wrap respectively. I've also built a set of RPMs for RedHat 6.2 (using my own spec-file which I created back in 0.9.1 days back in May -- I have no idea why Mark didn't start with what I've done). In any event, I've improved it a bit and separated out g-wrap from g-wrap-devel, in case we want to compile with shared libraries. I'd be more than happy to give anyone the RPMS, SRPMS, or SpecFile as necessary. Hopefully my changes (both to g-wrap.m4 and g-wrap.spec) can get merged back into the g-wrap package. Thanks very much for the patch. One minor point with the patch to gnucash, though - it'll mean that gnucash now depends on g-wrap = 0.9.8. Given that we are going to extend g-wrap to handle glib types, and that we will require that functionality, we were going to have to check for a minimum g-wrap version anyway. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Guile 1.3 + G-wrap 0.9.8 patches
Ok, I've sucessfully got the mainline version of GnuCash to build
against g-wrap 0.9.8. I had to apply the following patches to GnuCash
and g-wrap respectively.
I've also built a set of RPMs for RedHat 6.2 (using my own spec-file
which I created back in 0.9.1 days back in May -- I have no idea why
Mark didn't start with what I've done). In any event, I've improved
it a bit and separated out g-wrap from g-wrap-devel, in case we want
to compile with shared libraries.
I'd be more than happy to give anyone the RPMS, SRPMS, or SpecFile as
necessary. Hopefully my changes (both to g-wrap.m4 and g-wrap.spec)
can get merged back into the g-wrap package.
Enjoy!
-derek
GnuCash CHANGES:
acconfig.h
add SMOB variable
configure.in
hook into g-wrap.m4
G-Wrap Changes:
g-wrap.m4
get it to actually work
clean up the output
Index: acconfig.h
===
RCS file: /home/cvs/cvsroot/gnucash/acconfig.h,v
retrieving revision 1.9
diff -u -r1.9 acconfig.h
--- acconfig.h 2000/09/29 08:01:40 1.9
+++ acconfig.h 2000/11/02 16:58:37
@@ -53,6 +53,9 @@
/* is guile available */
#undef HAVE_GUILE
+/* New or old Guile Smob for G-wrap */
+#undef GWRAP_OLD_GUILE_SMOB
+
/* Use the new gtkhtml widget instead of the old xmhtml widget */
#undef HAVE_LIBGTKHTML
Index: configure.in
===
RCS file: /home/cvs/cvsroot/gnucash/configure.in,v
retrieving revision 1.140
diff -u -r1.140 configure.in
--- configure.in2000/10/23 09:40:30 1.140
+++ configure.in2000/11/02 16:58:40
@@ -264,29 +264,22 @@
G_WRAP_COMPILE_ARGS=""
G_WRAP_LINK_ARGS=""
-# Find the configure script
-AC_PATH_PROG(G_WRAP_CONFIG,g-wrap-config)
+AM_PATH_GWRAP(, , [AC_MSG_ERROR([
-if test -x "${G_WRAP_CONFIG}";
-then
- # Find out what the g-wrap compile and link flags are.
- G_WRAP_COMPILE_ARGS=`${G_WRAP_CONFIG} --c-compile-args guile`
- G_WRAP_LINK_ARGS=`${G_WRAP_CONFIG} --c-static-link-args guile`
-fi
+ g-wrap does not appear to be installed correctly. If you need to
+ install g-wrap, you can find it at ftp://ftp.gnucash.org/pub/g-wrap.
+])])
-# Find the tool
-AC_PATH_PROG(G_WRAP, g-wrap)
+# Find out what the g-wrap compile and link flags are.
+AC_MSG_CHECKING(for g-wrap compile args)
+G_WRAP_COMPILE_ARGS=`${G_WRAP_CONFIG} --c-compile-args guile`
+AC_MSG_RESULT($G_WRAP_COMPILE_ARGS)
-if test x"${G_WRAP_COMPILE_ARGS}" = x || \
- test x"${G_WRAP_LINK_ARGS}" = x || \
- test ! -x "${G_WRAP}";
-then
- AC_MSG_ERROR([
+AC_MSG_CHECKING(for g-wrap link args)
+G_WRAP_LINK_ARGS=`${G_WRAP_CONFIG} --c-static-link-args guile`
+AC_MSG_RESULT($G_WRAP_LINK_ARGS)
- g-wrap does not appear to be installed. It must be installed and
- its binary directory must be in your PATH. If you need to install
- g-wrap, you can find it at ftp://ftp.gnucash.org/pub/g-wrap.])
-fi
+AC_GWRAP_CHECK_GUILE
AC_SUBST(G_WRAP)
AC_SUBST(G_WRAP_CONFIG)
--- g-wrap-0.9.8/g-wrap.m4.no Wed Nov 1 23:04:06 2000
+++ g-wrap-0.9.8/g-wrap.m4 Thu Nov 2 11:46:27 2000
@@ -8,7 +8,7 @@
[if test x$GUILE = x ; then
AC_PATH_PROG(GUILE, guile, no)
fi
- AC_MSG_WARN(guile is $GUILE)
+ dnl AC_MSG_WARN(guile is $GUILE)
if test "${GUILE}" = "no" ; then
AC_MSG_ERROR(g-wrap couldn't find guile.)
fi
@@ -19,9 +19,13 @@
dnl in your acconfig.h or config.h.in, and
dnl include that config.h. If not, your code will not
dnl work with guile 1.3
+ AC_MSG_CHECKING(for whether guile uses old SMOB format)
if ${GUILE} -c '(if (string=? (version) "1.3") (exit 0) (exit 1))' ;
then
+ AC_MSG_RESULT(yes)
AC_DEFINE(GWRAP_OLD_GUILE_SMOB)
+ else
+ AC_MSG_RESULT(no)
fi
])
@@ -44,8 +48,6 @@
AC_PATH_PROG(GUILE, guile, no)
fi
-AC_MSG_CHECKING(for g-wrap - version = ${min_gwrap_version})
-
dnl if prefix set, then set them explicitly
if test x${gwrap_prefix} != x ; then
G_WRAP = ${gwrap_prefix}/bin/g-wrap
@@ -54,19 +56,21 @@
AC_PATH_PROG(G_WRAP, g-wrap, no)
if test x${G_WRAP} = xno ; then
- AC_MSG_RESULT(no)
CHECK_VERSION="no"
- ifelse([$3], , true , [$3])
+ ifelse([$3], , true , [AC_MSG_WARN(g-wrap failed)
+ $3])
fi
AC_PATH_PROG(G_WRAP_CONFIG, g-wrap-config, no)
if test x${G_WRAP_CONFIG} = xno ; then
- AC_MSG_RESULT(no)
CHECK_VERSION="no"
- ifelse([$3], , true , [$3])
+ ifelse([$3], , true , [AC_MSG_WARN(g-wrap-config failed)
+ $3])
fi
fi
if test x$CHECK_VERSION != xno ; then
+AC_MSG_CHECKING(for g-wrap - version = ${min_gwrap_version})
+
gwrap_major_version=`${G_WRAP} --version | \
sed 's/g-wrap \([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\1/'`
gwrap_minor_version=`${G_WRAP} --version | \
@@ -89,7 +93,11
Guile hacking -- accessing backtrace environment frames?
Hi, I'm trying to debug some scheme code, but I don't know guile very well. I've got a backtrace to the problematical code, but I'd like to get into that environment so that I can examine various symbols and see their values. I can't seem to find any useful guile documentation, in particular in terms of debugging from the guile shell. Anyone have a quick crash-course in guile/scheme debugging, or know where I can find one? -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 N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile hacking -- accessing backtrace environment frames?
Derek Atkins [EMAIL PROTECTED] writes: Ok, I did find the most recent info pages, which I grabbed from CVS.. But they still are useless. Wow. I hadn't actually looked at them on that topic. Pretty "sparse", no doubt... -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile hacking -- accessing backtrace environment frames?
Rob Browning [EMAIL PROTECTED] writes: Derek Atkins [EMAIL PROTECTED] writes: Ok, I did find the most recent info pages, which I grabbed from CVS.. But they still are useless. Wow. I hadn't actually looked at them on that topic. Pretty "sparse", no doubt... To say the least... I can certainly use the "debug-via-printf" debugging method, but I would definitely prefer to have step, trace, and frame level access to debug. I'd certainly appreciate any input anyone has for me? Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -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 N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile hacking -- accessing backtrace environment frames?
Derek Atkins [EMAIL PROTECTED] writes: I'm trying to debug some scheme code, but I don't know guile very well. I've got a backtrace to the problematical code, but I'd like to get into that environment so that I can examine various symbols and see their values. I can't seem to find any useful guile documentation, in particular in terms of debugging from the guile shell. Anyone have a quick crash-course in guile/scheme debugging, or know where I can find one? There is a debugger, but to tell you the truth, I've never used it. I usually just cram in some display statements and try again : : Check the info pages for "Debugger User Interface". -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile hacking -- accessing backtrace environment frames?
Rob Browning writes: Derek Atkins [EMAIL PROTECTED] writes: To say the least... I can certainly use the "debug-via-printf" debugging method, but I would definitely prefer to have step, trace, and frame level access to debug. I'd certainly appreciate any input anyone has for me? OK, without me actually testing anything, just poking around, how about the "Debugger options" section of the guile info pages? Does that help? I see there's a way to turn on backtracing on error. I think we may turn that off in gnucash unless the --debug option is enabled. Right. I just checked in some changes to src/guile/gnucash.c.in that makes running as a shell easier. Now, gnucash loads the same startup files regardless of whether it's running as a shell or not. The only difference is whether it invokes gnc:main or drops to the guile shell. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile hacking -- accessing backtrace environment frames?
Ok, I did find the most recent info pages, which I grabbed from CVS.. But they still are useless. -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 N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile hacking -- accessing backtrace environment frames?
Rob Browning [EMAIL PROTECTED] writes: There is a debugger, but to tell you the truth, I've never used it. I usually just cram in some display statements and try again : : I know, I could do that. But I hate debugging that way; it's much slower than examining information. Check the info pages for "Debugger User Interface". I can't even FIND the info pages.. And the Guile website is being useless :( I found references for guile 1.2a, but it doesn't have any useful information in the debugger section. :( Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -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 N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Guile hacking -- accessing backtrace environment frames?
Derek Atkins [EMAIL PROTECTED] writes: To say the least... I can certainly use the "debug-via-printf" debugging method, but I would definitely prefer to have step, trace, and frame level access to debug. I'd certainly appreciate any input anyone has for me? OK, without me actually testing anything, just poking around, how about the "Debugger options" section of the guile info pages? Does that help? I see there's a way to turn on backtracing on error. I think we may turn that off in gnucash unless the --debug option is enabled. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: How many people are using guile 1.3 (not 1.3.4) and can't easily switch?
The various gnome-games packages, and maybe other parts of gnome. There aren't many (any?) other widely-distributed packages, though. -Peter On Wed, Oct 18, 2000 at 12:43:01PM -0700, Dave Peticolas wrote: Rob Browning writes: Richard -Gilligan- Uschold [EMAIL PROTECTED] writes: I'm using guile 1.3, only because the rpm I downloaded for 1.4.4 required it. I thought it odd that it wasn't using a more recent version. I'll upgrade to 1.4.7 to see if that solves the problem. I seem to recall that there was some ugliness with 1.3 anyway, and that the guile people would really prefer people use 1.3.4. I can't remember what the issue was, though... The issue is that Redhat 6.x uses guile-1.3. That means if there are any other programs which link to guile, upgrading to guile-1.3.4 will be a pain because the library major version # changed and those other programs will break. I don't know if there are other programs that link to it, though. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: How many people are using guile 1.3 (not 1.3.4) and can't easily switch?
Yeah, 1.3 is a pretty lackluster guile. And that's saying something :)
-Peter
On Wed, Oct 18, 2000 at 04:08:31PM +, Richard -Gilligan- Uschold wrote:
Rob Browning wrote:
As far as I can tell, the latest version of g-wrap works fine with
guile 1.3.4 and guile 1.4 on my system(s).
Since it would be somewhat difficult/time-consuming for me to install
guile-1.3 and add backward compatibility and test g-wrap, I'm trying
to figure out if it would be unreasonable to just require guile 1.3.4
or newer and add a test to the g-wrap configure process.
Since I don't have much experience with the other distributions, I was
hoping people could give me an idea of where they are with respect to
guile packaging. Also, please let me know if my assertion about 1.3.4
and 1.4 being OK is wrong.
Thanks
--
Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
I'm using guile 1.3, only because the rpm I downloaded for 1.4.4 required
it. I thought it odd that it wasn't using a more recent version. I'll
upgrade to 1.4.7 to see if that solves the problem.
--
Gilligan|__o .oooO
/| _ \,_ ( )
/p|\(_)/ (_) \ ( Oooo.
/ | \ \_) ( )
) /
[EMAIL PROTECTED] (_/
[EMAIL PROTECTED]
--
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: How many people are using guile 1.3 (not 1.3.4) and can't easily switch?
Rob Browning wrote: As far as I can tell, the latest version of g-wrap works fine with guile 1.3.4 and guile 1.4 on my system(s). Since it would be somewhat difficult/time-consuming for me to install guile-1.3 and add backward compatibility and test g-wrap, I'm trying to figure out if it would be unreasonable to just require guile 1.3.4 or newer and add a test to the g-wrap configure process. Since I don't have much experience with the other distributions, I was hoping people could give me an idea of where they are with respect to guile packaging. Also, please let me know if my assertion about 1.3.4 and 1.4 being OK is wrong. Thanks -- Rob Browning [EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel I'm using guile 1.3, only because the rpm I downloaded for 1.4.4 required it. I thought it odd that it wasn't using a more recent version. I'll upgrade to 1.4.7 to see if that solves the problem. -- Gilligan | __o .oooO /| _ \,_ ( ) /p|\ (_)/ (_) \ ( Oooo. / | \ \_) ( ) ) / [EMAIL PROTECTED] (_/ [EMAIL PROTECTED]
Re: How many people are using guile 1.3 (not 1.3.4) and can't easily switch?
Richard -Gilligan- Uschold [EMAIL PROTECTED] writes: I'm using guile 1.3, only because the rpm I downloaded for 1.4.4 required it. I thought it odd that it wasn't using a more recent version. I'll upgrade to 1.4.7 to see if that solves the problem. I seem to recall that there was some ugliness with 1.3 anyway, and that the guile people would really prefer people use 1.3.4. I can't remember what the issue was, though... Thanks for the info. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
gnucash 1.4 + guile 1.3
Hi all 1) GnuCash is pretty darn neat 2) Do I understand correctly that gnucash 1.4 won't work with guile 1.4, but will work with guile 1.3? (my experience building gnucash today supports this observation ...) If so, how about a test in the configure script? Would have saved me a couple of hours today. I'll be happy to write it, just wanted to make sure I understand the situation, and also see if anyone else has already done this. thanks, Judah Judah Milgram [EMAIL PROTECTED] College Park Presshttp://www.cgpp.com P.O. Box 143, College Park MD, USA 20741 +001 (301) 422-4626 (422-3047 fax) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
gnucash 1.4.1, g-wrap 0.9.4 and guile 1.4 (fwd)
Hi, Problem: gnucash 1.4.1 doesn't compile with guile 1.4 and g-wrap 0.9.4 --- gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I.. -I../engine -I../gnome -I../regi ter-pipe -Wall -I/usr/include -DNEED_GNOMESUPPORT_H -I/usr/lib/gnome-libs/i clude -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/gnome-xml -I/ sr/include -I/usr/include -c gnc.c gnc.c:50: parse error before `POINTER_TOKEN_smob' gnc.c:50: warning: type defaults to `int' in declaration of `POINTER_TOKEN_smob gnc.c:51: warning: initialization makes integer from pointer without a cast gnc.c:51: warning: excess elements in scalar initializer gnc.c:51: warning: (near initialization for `POINTER_TOKEN_smob') gnc.c:51: warning: excess elements in scalar initializer gnc.c:51: warning: (near initialization for `POINTER_TOKEN_smob') gnc.c:53: warning: excess elements in scalar initializer gnc.c:53: warning: (near initialization for `POINTER_TOKEN_smob') gnc.c:53: warning: data definition has no type or storage class gnc.c:56: parse error before `POINTER_ARRAY_smob' gnc.c:56: warning: type defaults to `int' in declaration of `POINTER_ARRAY_smob gnc.c:57: warning: initialization makes integer from pointer without a cast gnc.c:57: warning: excess elements in scalar initializer gnc.c:57: warning: (near initialization for `POINTER_ARRAY_smob') gnc.c:57: warning: excess elements in scalar initializer gnc.c:57: warning: (near initialization for `POINTER_ARRAY_smob') gnc.c:59: warning: excess elements in scalar initializer gnc.c:59: warning: (near initialization for `POINTER_ARRAY_smob') gnc.c:59: warning: data definition has no type or storage class gnc.c: In function `gwrap_gnc_print_session_text': gnc.c:5922: warning: passing arg 2 of `gnc_print_session_text' discards qualifi rs from pointer target type gnc.c: In function `init_gnc': gnc.c:7208: warning: implicit declaration of function `scm_newsmob' make[3]: *** [gnc.o] Error 1 - I think this problem depends on g-wrap, because in g-wrap the function "scm_newsmob" is used but in guile 1.4 this function no longer exists. (guile-1.4/NEWS: "** Removed deprecated function scm_newsmob") Thx, christian -- eMail: [EMAIL PROTECTED] No warranty for any statement below this line! -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: gnucash 1.4.1, g-wrap 0.9.4 and guile 1.4 (fwd)
someone was going to have an rpm for suse today but i guess their busy with the 4th of july in the usa On Mon, 03 Jul 2000, Christian Krause wrote: Hi, Problem: gnucash 1.4.1 doesn't compile with guile 1.4 and g-wrap 0.9.4 --- gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I.. -I../engine -I../gnome -I../regi ter-pipe -Wall -I/usr/include -DNEED_GNOMESUPPORT_H -I/usr/lib/gnome-libs/i clude -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/gnome-xml -I/ sr/include -I/usr/include -c gnc.c gnc.c:50: parse error before `POINTER_TOKEN_smob' gnc.c:50: warning: type defaults to `int' in declaration of `POINTER_TOKEN_smob gnc.c:51: warning: initialization makes integer from pointer without a cast gnc.c:51: warning: excess elements in scalar initializer gnc.c:51: warning: (near initialization for `POINTER_TOKEN_smob') gnc.c:51: warning: excess elements in scalar initializer gnc.c:51: warning: (near initialization for `POINTER_TOKEN_smob') gnc.c:53: warning: excess elements in scalar initializer gnc.c:53: warning: (near initialization for `POINTER_TOKEN_smob') gnc.c:53: warning: data definition has no type or storage class gnc.c:56: parse error before `POINTER_ARRAY_smob' gnc.c:56: warning: type defaults to `int' in declaration of `POINTER_ARRAY_smob gnc.c:57: warning: initialization makes integer from pointer without a cast gnc.c:57: warning: excess elements in scalar initializer gnc.c:57: warning: (near initialization for `POINTER_ARRAY_smob') gnc.c:57: warning: excess elements in scalar initializer gnc.c:57: warning: (near initialization for `POINTER_ARRAY_smob') gnc.c:59: warning: excess elements in scalar initializer gnc.c:59: warning: (near initialization for `POINTER_ARRAY_smob') gnc.c:59: warning: data definition has no type or storage class gnc.c: In function `gwrap_gnc_print_session_text': gnc.c:5922: warning: passing arg 2 of `gnc_print_session_text' discards qualifi rs from pointer target type gnc.c: In function `init_gnc': gnc.c:7208: warning: implicit declaration of function `scm_newsmob' make[3]: *** [gnc.o] Error 1 - I think this problem depends on g-wrap, because in g-wrap the function "scm_newsmob" is used but in guile 1.4 this function no longer exists. (guile-1.4/NEWS: "** Removed deprecated function scm_newsmob") Thx, christian -- eMail: [EMAIL PROTECTED] No warranty for any statement below this line! -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED] -- Rolando Roman icq 3783184 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
gnucash 1.4.1, g-wrap 0.9.4 and guile 1.4 (fwd)
Christian Krause writes: Hi, Problem: gnucash 1.4.1 doesn't compile with guile 1.4 and g-wrap 0.9.4 If you check the archives, I've explained how to fix the problem with g-wrap.0.9.4. The difficulties with Guile 1.4 are known problems. Could you please revert to the 1.3.x series for the moment? Robert Merkel [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
trouble while compiling against guile-1.4
Martin Willemoes Hansen writes: Hi! I just tried compiling gnucash, after I upgrade my guile interpretter from 1.3.? to guile-1.4 and it resulted in a compile error: gnc.c:53: warning: data definition has no type or storage class gnc.c:56: parse error before ^POINTER_ARRAY_smob' gnc.c:56: warning: type defaults to nt' in declaration of ^POINTER_ARRAY_smob'gnc.c:57: warning: initialization makes integer from pointer without a cast gnc.c:57: warning: excess elements in scalar initializer gnc.c:57: warning: (near initialization for ^POINTER_ARRAY_smob') gnc.c:57: warning: excess elements in scalar initializer gnc.c:57: warning: (near initialization for ^POINTER_ARRAY_smob') gnc.c:59: warning: excess elements in scalar initializer gnc.c:59: warning: (near initialization for ^POINTER_ARRAY_smob') gnc.c:59: warning: data definition has no type or storage class gnc.c: In function ^Gwrap_gnc_print_session_text': gnc.c:5922: warning: passing arg 2 of ^Gnc_print_session_text' discards qualifiers from pointer target type gnc.c: In function nit_gnc': gnc.c:7208: warning: implicit declaration of function ^Scm_newsmob' make[2]: *** [gnc.o] Error 1 To my knowledge, none of the developers have tried building against guile-1.4 yet. It's on the list of things to do (and if you could help it would be much appreciated), but if you don't need guile-1.4 for anything else and don't have the time to fix the problem yourself I'd recommend a downgrade to one of the 1.3.x series for the moment. Robert Merkel [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Guile 1.4 Released
I'd seen the fact that Guile 1.4 existed mentioned somewhere, but it's now announced on freshmeat. Release announcement is at: http://sourceware.cygnus.com/ml/guile/2000-06/msg00198.html I suppose we should find out what breaks. . . Robert Merkel [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Guile 1.4 Released
On Fri, 23 Jun 2000 00:50:13 +1000, the world broke into rejoicing as Robert Graham Merkel [EMAIL PROTECTED] said: I'd seen the fact that Guile 1.4 existed mentioned somewhere, but it's now announced on freshmeat. Release announcement is at: http://sourceware.cygnus.com/ml/guile/2000-06/msg00198.html I suppose we should find out what breaks. . . I'd suggest holding off a little bit; part of the goal of the release was to allow syncing up GOOPS development with Guile, and so there is fairly likely to be another release fairly soon. The good news being that _that_ release is fairly likely to make GOOPS be a standard part of Guile, but that's another story... -- [EMAIL PROTECTED] - http://www.ntlug.org/~cbbrowne/lsf.html Rules of the Evil Overlord #49. "If I learn the whereabouts of the one artifact which can destroy me, I will not send all my troops out to seize it. Instead I will send them out to seize something else and quietly put a Want-Ad in the local paper." http://www.eviloverlord.com/ -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Guile, CORBA, Engine...
On Fri, 09 Jun 2000 11:03:34 +1000, the world broke into rejoicing as Robert Graham Merkel [EMAIL PROTECTED] said: I want to suggest that a better long-term architecture might be that the financial calculators etc. be implemented in C, as a part of the engine. My arguments for this is that this will make for a better client-server interface: -- there is potentially less traffic, fewer bytes crossing the wire, if the computations happen in the engine. I don't think this is as big an issue as you might think. The average balance report is probably doing the most calculations of any report, and it is pretty speedy, even on large data files. I can't recall the speed of guile ever being a live issue. The part of the code with performance issues ATM (the register) is written in C anyway. I'd want to wait until this could unambiguously be claimed to actually be a problem with Guile. Thinking that it could, someday, _possibly_ become an issue doesn't count. Note that by the time that takes place, we may see a generally deployable Hobbit system whereby Guile code could be turned into C, and compiled into place. Which can cope with those situations where something is too slow, and _could_ get compiled. Hobbit exists now; general deployment is the problem... -- if its in C, then I can potentially export this function e.g. via CORBA, to other modules. If its in scheme, it stays 'locked up in scheme'. This is not true. Calling guile functions from C is easy, we do it all over the place right now. True. AFAIK, however, there are no CORBA bindings for scheme, which means we have to wrap any scheme functions we wish to export via CORBA in C. Also, it will mean we will have to create some C wrappers so that scheme can call CORBA services from other programs (for instance, if we want to use CORBA to interface to guppi). A scheme CORBA mapping would be really nice, because as Christopher put it on Slashdot recently, the C CORBA mapping is "horrible", and I'm not looking forward to having to work with it. Actually, Christopher, is there a scheme language mapping out there? ILU supports Guile, and I'm sure it wouldn't be _too_ difficult to do a mapping using ORBit. There has been comment of such on the Guile development list; look on http://www.google.com/ for "guile" and "orbit" and "corba." There isn't a formalized mapping for Scheme yet, although there may be enough info in the ILU docs to provide something "good enough." One of the ILU guys joint-authored the Python Mapping, which now has _four_ implementations (Fnorb, ILU, 2 ORBit-based). I'd _really_ like to see a Guile implementation; I'm doing some writing for a book based on the C mapping, and it's just gross. The _awful_ part is coping with memory management. I'd be game to wait things until there is a Guile/ORBit binding, and have GnuCash's CORBA support go through the Guile side of things, particularly because this allows memory to stay managed in the garbage-collected side of the world. It seems to me that _that_ would substantially improve the _robustness_ of this. I think there are some good arguments for a scheme implementation. Scheme is much more flexible than C. Having the statistics package in scheme would make it easier for users to add their own functions if the existing ones don't provide something they need. Agreed. Having users (and developers) use scheme where appropriate makes it a little bit harder to inadvertantly shoot oneself in the foot :) One of the major merits, as I see it, of using Guile is that it means leaving memory management to the garbage collector, which is likely to be better at memory management than I am. -- [EMAIL PROTECTED] - http://www.ntlug.org/~cbbrowne/linux.html "Like I've always said, if you don't have anything nice to say, come sit by me." -- Steel Magnolias -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Entry in Guile-Projects
I "saw fit" to see about adding GnuCash to the Guile-related projects; information submission listed below... --- Forwarded Message Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: (qmail 3861 invoked from network); 15 Apr 2000 16:41:58 - Received: from unknown (HELO revel.glug.org) (@204.210.4.154) by yellow.hex.net with SMTP; 15 Apr 2000 16:41:58 - Received: (from ttn@localhost) by revel.glug.org (8.9.3/8.9.3) id JAA08428; Sat, 15 Apr 2000 09:41:49 -0700 Date: Sat, 15 Apr 2000 09:41:49 -0700 Message-Id: [EMAIL PROTECTED] X-Authentication-Warning: revel.glug.org: ttn set sender to [EMAIL PROTECTED] using -f From: thi [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] In-reply-to: [EMAIL PROTECTED] ([EMAIL PROTECTED]) Subject: Re: (name "GnuCash") Reply-to: [EMAIL PROTECTED] References: [EMAIL PROTECTED] more munging... thi = ((name "GnuCash") (password "Update to GnuCash Info") (category "Applications") (keywords "Extension Language Scheme Interpreter") (description "A personal finance software package. " "The basic GnuCash engine is written in C, as is the base " (url "http://www.gtk.org/" "GTK") " user interface code. " "An increasing body of secondary functionality, including" "reporting, data interchange, and budgeting is supported" "via the Guile scripting engine.") (location (url "http://www.gnucash.org/" "GnuCash")) (authors "Linas Vepstas, Rob Browning, Jeremy Collins, Dave Peticola, Rob Clark, and a cast of thousands") (maintainer (email "Linas Vepstas" "[EMAIL PROTECTED]")) (mailing-list (email "GnuCash Developers mailing list" "[EMAIL PROTECTED]") " is the main list for GnuCash. " "To subscribe to the GnuCash list, send mail to " (email "[EMAIL PROTECTED]" "[EMAIL PROTECTED]") ". The message does not need to contain any commands.") (status "The current release of GnuCash is 1.3.x; it is still undergoing many changes, but is beginning to be stable enough for everyday use.") (help-wanted "Cool hackage always appreciated." "Many proposed features are listed under " (url "http://linas.org/linux/xacc/projects.html" "Project Goals") ".") (testers-wanted "Go for it!") (license "GPL")) --- End of Forwarded Message -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
about scheme and guile in the future
Take a look at this page: http://www.freshmeat.net/news/2000/04/01/954615693.html RMS said: "We've abandoned Scheme, and will slowly be removing Guile from all our projects over the course of this summer. We had to find an extension language to replace it. I looked at Perl, Python, Eiffel, LOGO... even at TCL." RMS choose Visual Basic Yannick __ Si votre email etait sur iFrance vous pourriez ecouter ce message au tel ! http://www.ifrance.com : ne laissez plus vos emails loin de vous ... gratuit sur iFrance : emails (20 MO, POP, FAX), Agenda, Site perso -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Guile and compile problems
I tried to compile the latest cvs of gnucash. I got an error and saw that it was the same error I saw mentioned here (about having the latest guile). I downloaded the latest guile from the gnucash web site (1.3.4-6) and installed it. No problem. Now I get this error during configure: checking for guile... /usr/bin/guile configure: error: Cannot configure guile bits Do you have guile 1.3 installed? And it bails out. So, what's this about? -- Randy Powell - ICQ:61280419 "Reality is just a convenient level of complexity" Steven Lassiter -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Guile and Slib
OK, I managed to fix the configure guile parts problem. I apparently also needed the 1.3.4-2 of guile-devel. I installed that and configure ran fine. Now, gnucash seems to compile The only error I get is about a questionable "makeinfo", but I always get that. But after I compile and install gnucash (today's cvs) I try to run it. I get an error that says I need slib2c6 installed. Slib2c6-1 is installed. So what symlink that pointed to slib got overwritten when I installed guile 1.3.4-2 and guile-devel-1.3.4-2? I've tried a number of things to convince gnucash that slib is there, but it's still not buying it. I tried uninstalling slib and re-installing it, I tried putting symlinks in a couple of places pointing to slib but nothing has yet worked. Slib is installed in /usr/lib/umb-scheme. Thanks for any help. -- Randy Powell - ICQ:61280419 "Reality is just a convenient level of complexity" Steven Lassiter -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Guile and Slib
On Sat, 19 Feb 2000, Dave Peticolas wrote: Date: Sat, 19 Feb 2000 13:10:34 -0800 To: [EMAIL PROTECTED] From: Dave Peticolas [EMAIL PROTECTED] Subject: Re: Guile and Slib OK, I managed to fix the configure guile parts problem. I apparently also needed the 1.3.4-2 of guile-devel. I installed that and configure ran fine. Now, gnucash seems to compile The only error I get is about a questionable "makeinfo", but I always get that. But after I compile and install gnucash (today's cvs) I try to run it. I get an error that says I need slib2c6 installed. Slib2c6-1 is installed. So what symlink that pointed to slib got overwritten when I installed guile 1.3.4-2 and guile-devel-1.3.4-2? I've tried a number of things to convince gnucash that slib is there, but it's still not buying it. I tried uninstalling slib and re-installing it, I tried putting symlinks in a couple of places pointing to slib but nothing has yet worked. Slib is installed in /usr/lib/umb-scheme. Put a symlink named 'slib' in /usr/share/guile that points to /usr/lib/umb-scheme/slib. You may need to run gnucash once as root. dave Dave, Thanks, that did it. I just didn't know where gnucash was looking for it. -- Randy Powell - ICQ:61280419 "Reality is just a convenient level of complexity" Steven Lassiter -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Guile and Slib
Put a symlink named 'slib' in /usr/share/guile that points to /usr/lib/umb-scheme/slib. You may need to run gnucash once as root. dave Dave, Thanks, that did it. I just didn't know where gnucash was looking for it. Unfortunately, this problem illustrates the fact that upgrading with guile-1.3.4-2 will not be a panacea. The 1.3.4 rpm does not install the link to slib, while the 1.3 rpm does. I am going to try and remove the dependency on 1.3.4 before we release. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Guile and Slib
Dave Peticolas [EMAIL PROTECTED] writes: Unfortunately, this problem illustrates the fact that upgrading with guile-1.3.4-2 will not be a panacea. The 1.3.4 rpm does not install the link to slib, while the 1.3 rpm does. I am going to try and remove the dependency on 1.3.4 before we release. Alternately, is there a way we can just test for the right symlink and print appropriate instructions if things are messed up? This might be done in conjunction with guile-config (which if 1.3.4 is installed, should be available). -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Guile and Slib
Dave Peticolas [EMAIL PROTECTED] writes: Unfortunately, this problem illustrates the fact that upgrading with guile-1.3.4-2 will not be a panacea. The 1.3.4 rpm does not install the link to slib, while the 1.3 rpm does. I am going to try and remove the dependency on 1.3.4 before we release. Alternately, is there a way we can just test for the right symlink and print appropriate instructions if things are messed up? This might be done in conjunction with guile-config (which if 1.3.4 is installed, should be available). That's a possiblity, but we should keep in mind that many rpm users aren't going to have experience with creating symlinks and such. GnuCash has a (deserved) reputation of being a bear to install and I think we should try as much as possible to change that. Having a gnucash rpm that installs and runs on a stock redhat system would be a real plus. Given that the 1.3.4 dependency results from a single function call, I think we are better off just working around it for now. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
guile reports
For everyone writing reports, you should know that your report file is only loaded once. This means that any global variables you use will only be initialized once. Thus, any global variables which you change must be re-initialized in the report generation function. Also, you can have the same report instantiated with different variables at the same time. This means if you use global variables, they will be shared between the two instantiations, so keep that in mind too. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
guile: (re)enabling readline...
In recent versions of guile, libreadline is no longer linked directly or enabled by default, but as we all know, it's quite nice to have during development. If you'd like to turn it back on, and you didn't find the tidbit buried in the NEWS file, all you need to do is execute this: (use-modules (ice-9 readline)) (activate-readline) You can put this in your ~/.guile file and it'll be the default. Enjoy. (For anyone using the Debian guile packages, this was broken for a while, but it's fixed in the latest version(s).) -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: guile: (re)enabling readline...
In recent versions of guile, libreadline is no longer linked directly or enabled by default, but as we all know, it's quite nice to have during development. If you'd like to turn it back on, and you didn't find the tidbit buried in the NEWS file, all you need to do is execute this: (use-modules (ice-9 readline)) (activate-readline) You can put this in your ~/.guile file and it'll be the default. Enjoy. (For anyone using the Debian guile packages, this was broken for a while, but it's fixed in the latest version(s).) Unfortunatly, it still seems to be broken in the rpms. Specifically, the libguilereadline shared library is missing. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: guile/slib
teri wrote: The guile tarball I got has no such file and the slib docs don't say anything about guile. Given that all I want to do is run gnucash and don't particularly care about doing anything fancy with guile/slib, can I just copy the scm files someplace where guile will find them? or do I need to take other unspecified steps for which there is no documentation? If I've missed *the* documentation file that contains all these answers, please someone point me to it. Am I extremely stupid or is it that both the guile and slib docs assume you know everything about lisp/scheme environments/systems? (which I know nothing about). As I said, I installed guile-1.3 in /usr/local from the tarball and gnucash configure finds it. There is no scheme (binaries or docs) of any kind on Caldera 2.3. Red Hat 6.0 only has a man page for scheme(1) but nothing else that I could find (?), and of course nothing specific to guile and slib. The guile / slib documentation is very poor, at least I didn't find anything useful, too. If you install guile-1.3 you should get a /usr/local/share/guile/1.3 directory. In this dir create a subdir slib and copy the .scm files to that subdir. Then run gnucash once as root, because guile seems to need to setup some things. This worked with my SuSE 6.3 installation, which brings guile-1.3.4 with it, but no slib. On another computer I installed the UMBscheme rpm from ftp.gnucash.org. This installs a /usr/lib/umbscheme/slib ((?) not entirely sure about that path) directory. Then a ln -s /usr/lib/umbscheme/slib /usr/local/share/guile/1.3/slib solved all slib problems. Hope this helps. Herbert. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: guile/slib
... If you have installed guile, you already have a complete Scheme system. That's what guile is - a Scheme interpreter designed for easy embedding in other programs. Ok. Thanks. slib works fine with guile. As well as the slib documentation, you should check the guile-ref info file for information about setting up slib to work with guile. The guile tarball I got has no such file and the slib docs don't say anything about guile. Given that all I want to do is run gnucash and don't particularly care about doing anything fancy with guile/slib, can I just copy the scm files someplace where guile will find them? or do I need to take other unspecified steps for which there is no documentation? In my dist, slib is installed in /usr/share/slib. There is a symbolic link named 'slib' in /usr/share/guile (where my guile is installed) to /usr/share/slib. Also, I have an environment variable defined SCHEME_LIBRARY_PATH=/usr/share/slib/ export SCHEME_LIBRARY_PATH good luck, dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: guile/slib
The guile tarball I got has no such file and the slib docs don't say anything about guile. Given that all I want to do is run gnucash and don't particularly care about doing anything fancy with guile/slib, can I just copy the scm files someplace where guile will find them? or do I need to take other unspecified steps for which there is no documentation? Alls I've ever had to do is to put the .scm files someplace where gnucash can find them. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Guile Listener
This approach would have the advantage of giving you a nice readline interface with command history for free. You'd still have the problem Speaking of which, when I moved to guile 1.3.4, I lost my nice readline interface in using the guile interpreter. Is there something you need to do to turn it back on? dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Guile Listener
Dave Peticolas [EMAIL PROTECTED] writes: Speaking of which, when I moved to guile 1.3.4, I lost my nice readline interface in using the guile interpreter. Is there something you need to do to turn it back on? They've moved it out to a separate module in response to GPL issues. There's a way to turn it on, but in the Debian packages at least, it doesn't currently work. I believe I filed a bug a while back. The docs are in the NEWS file, which says: ** Readline support has changed again. The old (readline-activator) module is gone. Use (ice-9 readline) instead, which now contains all readline functionality. So the code to activate readline is now (use-modules (ice-9 readline)) (activate-readline) This should work at any time, including from the guile prompt. To avoid confusion about the terms of Guile's license, please only enable readline for your personal use; please don't make it the default for others. Here is why we make this rather odd-sounding request: Guile is normally licensed under a weakened form of the GNU General Public License, which allows you to link code with Guile without placing that code under the GPL. This exception is important to some people. However, since readline is distributed under the GNU General Public License, when you link Guile with readline, either statically or dynamically, you effectively change Guile's license to the strict GPL. Whenever you link any strictly GPL'd code into Guile, uses of Guile which are normally permitted become forbidden. This is a rather non-obvious consequence of the licensing terms. So, to make sure things remain clear, please let people choose for themselves whether to link GPL'd libraries like readline with Guile. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Guile and Structures
On 09 Aug 1999 00:17:53 CDT, the world broke into rejoicing as Rob Browning [EMAIL PROTECTED] said: [EMAIL PROTECTED] writes: What struck me Friday morning was that I really should be marshalling data into somewhat more organized "structures" rather than just building assoc lists. [ General agreement. ] I also finally grokked define-struct, and maybe am looking at is as a "hammer," and am looking for "nails" to hit with it. Could be. Rather than assoc lists, unless I need something fancier, I generally use vectors and define getters/setters and use those exclusively: (define (point:create x y z) (vector 'point x y z)) ;; the tag is optional. .. (define (point:x pt) (vector-ref pt 0) (define (point:set-x! pt value) (vector-set! v 0 value)) ... The advantage to using this over something like define-struct is that define-struct is not standard scheme so your code won't be portable to other implementations. I'm not a about using non-portable scheme code, but I try to avoid it unless it provides a compelling advantage. Of course, if you need dispatch, then you have to do a little more (which without looking closely yet, looks like what you've done). Only a little bit more. For example, *if* we ever decided to implement even more of GnuCash in scheme, and we really needed to speed some of it up to C level performance, we could use a good scheme compiler as long as the relevant code didn't depend on a lot of uncommon functions. Stalin, maybehaps. [This is one of the annoyances of Scheme as compared to Common Lisp; there are many commonly desirable functions/macros that CL has standardized but that different Schemes handle differently.] True, but there is some movement toward fixing this (see below). Further, slib, which we already requrire implements a whole bunch of useful things. Though I've tended to avoid using slib if I could implement the same function easily because we might or might not want to keep that dependency long-term. There's actually quite a bit of useful code at the MIT and Indiana repositories we could include if we needed it, but more interesting than that for your purposes would probably be the SRFI (Scheme Request For Implementation) process (see www.schemers.org). If you're going to implement the skeleton of any "struct" style system, I'd suggest modelling it after the relevant SRFI. In fact, since a SRFI is required to provide a reference implementation written in standard scheme to be valid, there should already be code there for this. SRFI's, especially the finalized ones, should be commonly available in most schemes soon, and if not, you can just copy/paste the reference code into your own project. The problem with SRFI's is that they still won't provide you with a standard way of requesting facilities, e.g. - things like (require) which is different from the DrScheme equivalent. Also, if we're going to use non-standard scheme bits, I'd recommend using hash tables instead of alists for any case where there's likely to be more than a small number of items. Might as well get O(1) lookups rather than O(n). Agreed; hashing is another thing that almost always has a slightly different expression in each different implementation. In the case of a struct, n isn't likely more than 10 or so, the complexity is essentially "O(10)," which is probably effectively only a little slower than hashing. -- Found in a TOPS-10 MCO: Quotation for the day: "a counter that doesn't exist can't get messed up." "Once in a blue moon" is defined as the creation of a new SFD or the renaming of an old one. [EMAIL PROTECTED] http://www.hex.net/~cbbrowne/lsf.html - % % -- The GnuCash / X-Accountant Mailing List To unsubscribe, send mail to [EMAIL PROTECTED] and put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
Re: Guile and Structures
[EMAIL PROTECTED] writes: The problem with SRFI's is that they still won't provide you with a standard way of requesting facilities, e.g. - things like (require) which is different from the DrScheme equivalent. True, though my guess is that that'll be the subject of a future SRFI. For now you can just put all that stuff in separate "preload" files, one per implementation that you care about. Ugly, but functional. Agreed; hashing is another thing that almost always has a slightly different expression in each different implementation. Right, but if you pick (or create) a suitably abstract interface, you can implement it in terms of the other language's primitives if you need to migrate. Things like object systems could be a much bigger undertaking (though implementing most object systems' semantics in scheme, as SICP points out, isn't really that big a deal if you're not a huge syntax nut. In the case of a struct, n isn't likely more than 10 or so, the complexity is essentially "O(10)," which is probably effectively only a little slower than hashing. Agreed. I didn't know exactly what you were using them for. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 - % % -- The GnuCash / X-Accountant Mailing List To unsubscribe, send mail to [EMAIL PROTECTED] and put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
Guile and Structures
I'm starting to look Rather More Seriously at understanding the transaction engine. This is encouraging me to establish sets of data structures on the Guile side of the world to represent data in the two quite distinct forms: a) QIF's "bunch of transactions that get attached to an account, sometimes with a split," and b) The GnuCash Engine "Bunch of accounts that have transactions attached to them that have a bunch of splits attached to them." Those are quite different structures, and I didn't fully grasp what was going on until Friday night. What struck me Friday morning was that I really should be marshalling data into somewhat more organized "structures" rather than just building assoc lists. I also finally grokked define-struct, and maybe am looking at is as a "hammer," and am looking for "nails" to hit with it. What I'd like to do is collect the data all together via (define-struct qif-txn-structure '(memo date id payee addresslist amount status category splitlist))) and then go off and do (define thistxn (make-qif-txn-structure)) every time I want to create a new transaction. Seems sensible to have the names all together in one spot, much as gnucash/src/engine/TransactionP.h and the other *P.h files collect such data together into C structures. Unfortunately, Guile evidently hides (define-struct) and I've not gotten it to compile or otherwise work. Hence, note the attached, that does largely the same thing. I would be more than pleased to eliminate it in favor of a more "native" facility, if the "true" define-struct may be made to work. [This is one of the annoyances of Scheme as compared to Common Lisp; there are many commonly desirable functions/macros that CL has standardized but that different Schemes handle differently.] Note to those that didn't know; the below essentially represents a message dispatch system; Object Oriented Programming recreated in 43 lines of code. Paul Graham's book, "Common Lisp," does a presentation of an 8 line OO system that does everything but multiple inheritance... -- "It's a pretty rare beginner who isn't clueless. If beginners weren't clueless, the infamous Unix learning cliff wouldn't be a problem." -- david parsons [EMAIL PROTECTED] http://www.hex.net/~cbbrowne/langlisp.html ;;; Some functions to help build structures ;;; define-mystruct is used to build an association list that defines ;;; the layout of a structure... (define (define-mystruct lst) (define alist '()) ;; Association list (define count 0);; Number of entries (define (add-item item) (set! alist (cons (cons item count) alist)) (set! count (+ 1 count))) (for-each add-item lst) alist) ;;; Use as follows: ;;; (define qif-split-structure (define-mystruct '(category memo ;;; amount percent))) ;;; (define (build-mystruct-instance structinfo) ;;; struct-instance is the vector for the data... (define struct-instance (make-vector (length structinfo) #f)) (define (get-item field-id) ;;; Look up entry based on ID (let ((assocv (assoc field-id structinfo))) (if assocv (vector-ref struct-instance (cdr assocv)) #f))) (define (set-item! field-id value) ;;; Plunk in new value (let ((assocv (assoc field-id structinfo))) (if assocv (vector-set! struct-instance (cdr assocv) value) #f))) (define (actions action field . value) ;;; now, methods to be applied (cond ((eq? action 'get) (car (get-item field))) ((eq? action 'put) (set-item! field (car value))) (else (list structinfo struct-instance actions)
Re: Guile and Structures
[EMAIL PROTECTED] writes: What struck me Friday morning was that I really should be marshalling data into somewhat more organized "structures" rather than just building assoc lists. [ General agreement. ] I also finally grokked define-struct, and maybe am looking at is as a "hammer," and am looking for "nails" to hit with it. Could be. Rather than assoc lists, unless I need something fancier, I generally use vectors and define getters/setters and use those exclusively: (define (point:create x y z) (vector 'point x y z)) ;; the tag is optional... (define (point:x pt) (vector-ref pt 0) (define (point:set-x! pt value) (vector-set! v 0 value)) ... The advantage to using this over something like define-struct is that define-struct is not standard scheme so your code won't be portable to other implementations. I'm not a about using non-portable scheme code, but I try to avoid it unless it provides a compelling advantage. Of course, if you need dispatch, then you have to do a little more (which without looking closely yet, looks like what you've done). For example, *if* we ever decided to implement even more of GnuCash in scheme, and we really needed to speed some of it up to C level performance, we could use a good scheme compiler as long as the relevant code didn't depend on a lot of uncommon functions. [This is one of the annoyances of Scheme as compared to Common Lisp; there are many commonly desirable functions/macros that CL has standardized but that different Schemes handle differently.] True, but there is some movement toward fixing this (see below). Further, slib, which we already requrire implements a whole bunch of useful things. Though I've tended to avoid using slib if I could implement the same function easily because we might or might not want to keep that dependency long-term. There's actually quite a bit of useful code at the MIT and Indiana repositories we could include if we needed it, but more interesting than that for your purposes would probably be the SRFI (Scheme Request For Implementation) process (see www.schemers.org). If you're going to implement the skeleton of any "struct" style system, I'd suggest modelling it after the relevant SRFI. In fact, since a SRFI is required to provide a reference implementation written in standard scheme to be valid, there should already be code there for this. SRFI's, especially the finalized ones, should be commonly available in most schemes soon, and if not, you can just copy/paste the reference code into your own project. Also, if we're going to use non-standard scheme bits, I'd recommend using hash tables instead of alists for any case where there's likely to be more than a small number of items. Might as well get O(1) lookups rather than O(n). -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 - % % -- The GnuCash / X-Accountant Mailing List To unsubscribe, send mail to [EMAIL PROTECTED] and put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
Re: guile: Stack overflow
Yeah, sorry dumb question. Don't know how I missed that. I have since got it up and running with all features working. Thanks eveyone for a great product. Carey [EMAIL PROTECTED] wrote: It's been rumoured that Carey Stevens said: gnucash: bootstrap file is /usr/share/gnucash/scm/bootstrap.scm guile: Stack overflow The guile on my system is version 1.2 You need guile 1.3 --linas - % % -- The GnuCash / X-Accountant Mailing List To unsubscribe, send mail to [EMAIL PROTECTED] and put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
Re: guile: Stack overflow
It's been rumoured that Carey Stevens said: gnucash: bootstrap file is /usr/share/gnucash/scm/bootstrap.scm guile: Stack overflow The guile on my system is version 1.2 You need guile 1.3 --linas - % % -- The GnuCash / X-Accountant Mailing List To unsubscribe, send mail to [EMAIL PROTECTED] and put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
Re: guile: Stack overflow
Carey Stevens [EMAIL PROTECTED] writes: Hi, I have just compiled and installed motif gnucash-1.2.0 on an out of the box Redhat 5.2 system on a Pentium Pro with 64M RAM. It compiled fine, however when I try to run it I get only the following gnucash: bootstrap file is /usr/share/gnucash/scm/bootstrap.scm guile: Stack overflow The guile on my system is version 1.2 Does anybody know what the problem is, or have any suggestions? Your guile is too old. Check the README. You need 1.3 or better. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 - % % -- The GnuCash / X-Accountant Mailing List To unsubscribe, send mail to [EMAIL PROTECTED] and put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
guile: Stack overflow
Hi, I have just compiled and installed motif gnucash-1.2.0 on an out of the box Redhat 5.2 system on a Pentium Pro with 64M RAM. It compiled fine, however when I try to run it I get only the following gnucash: bootstrap file is /usr/share/gnucash/scm/bootstrap.scm guile: Stack overflow The guile on my system is version 1.2 Does anybody know what the problem is, or have any suggestions? Thanks in advance. Carey - % % -- The GnuCash / X-Accountant Mailing List To unsubscribe, send mail to [EMAIL PROTECTED] and put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
