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
Re: annoying simple Guile question
Neil Williams <[EMAIL PROTECTED]> writes: > 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. Hmm, a bad pointer, perhaps? Maybe something doen't get zero-ized properly and then doesn't get re-set later? Odd. >> 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! Hey, lots of people want the merge feature. I'm certainly going to encourage help :) Thank you for learning and doing the work! How can we keep you interested in doing more work? -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 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
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
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 s
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: 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::String::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
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 Wi
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::String::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
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::String::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
