Re: Compiling GnuCash on Windows
Andreas Köhler wrote: Hi, Ivars Grinbergs wrote: Andreas Köhler wrote: You have to admit that this stack trace is not extraordinary useful ;-) But yesterday I managed to improve, maybe you can try to do the same? Here is what I did: * download and unpack `pd' and `MMP' from http://www.trapkit.de, you will need the Microsoft .NET Framework Version 2.0 to run the latter * make gnucash crash within gdb * determine the PID of the running gnucash-bin process (Ctrl+Alt+Del) * open a shell and enter `pd -p $pid my.dump', where $pid is your pid * open mmp, open my.dump, let it parse it (click away errors you get, ignore please wait dialogs that do not go away and also crashes when you try to close mmp after your work) * see frame #4, it says 0x0077a51c... try to find the dll that got mapped there and also its base address (one of the first columns) * enter `add-symbol-file $mydll $myaddr' into gdb, where $mydll might be libgncmod-gnome-utils-0.dll or such, and myaddr the base address mmp told you; confirm with y * bt again Success? sorry for the answer in a hurry. Can you please double-check that 1) you select the one line in mappings within mmp such that mapping_start = 0x0077a51c mapping_end 2) $mydll is the basename (the part after the last backslash) in the mapped_from column 3) $myaddr is the mapping_start? So yes, the backtrace looks better, but still lacks real debugging information (function names, line numbers). I expect you did not change install.sh so that it either does not include debug symbols or strips the binaries... Go go, well done so far! -- andi5 Sorry, I was in rush in the morning and I missed one important point - number (3): I used Image Base instead of Mapping Start :( Below it is, when Mapping Start is uesd, but before that, I would like to mention that test results reported before was true when run from gdb; when I tried this newest version without gdb, reports cause gc to crash (gnu crash :) ). From within gdb, reports run fine. (gdb) bt #0 0x6b072b01 in _libmsvcrt_a_iname () #1 0x673116f0 in _libmsvcrt_a_iname () #2 0x6b073034 in _libmsvcrt_a_iname () #3 0x6b046dd4 in __RUNTIME_PSEUDO_RELOC_LIST__ () #4 0x0063a3dc in gnc_dense_cal_init (dcal=0x32280f0) at gnc-dense-cal.c:337 #5 0x6275c9f4 in _libws2_32_a_iname () #6 0x627466f7 in _libws2_32_a_iname () #7 0x62745b39 in _libws2_32_a_iname () #8 0x627465eb in _libws2_32_a_iname () #9 0x627466d6 in _libws2_32_a_iname () #10 0x00637ec0 in gnc_dense_cal_new () at gnc-dense-cal.c:394 #11 0x63054ab6 in gnc_ui_scheduled_xaction_dialog_create () at dialog-scheduledxaction.c:1250 #12 0x62743935 in _libws2_32_a_iname () #13 0x62756f35 in _libws2_32_a_iname () #14 0x62757cde in _libws2_32_a_iname () #15 0x62757f56 in _libws2_32_a_iname () #16 0x6048b824 in _libmsvcrt_a_iname () #17 0x62743935 in _libws2_32_a_iname () #18 0x62756f35 in _libws2_32_a_iname () #19 0x62757cde in _libws2_32_a_iname () #20 0x62757f56 in _libws2_32_a_iname () #21 0x606999e5 in _libmsvcrt_a_iname () #22 0x6058acec in _libmsvcrt_a_iname () #23 0x6058aff5 in _libmsvcrt_a_iname () #24 0x605774a2 in _libmsvcrt_a_iname () #25 0x62743935 in _libws2_32_a_iname () #26 0x62756b66 in _libws2_32_a_iname () #27 0x62757a3c in _libws2_32_a_iname () #28 0x62757f56 in _libws2_32_a_iname () #29 0x60699b74 in _libmsvcrt_a_iname () #30 0x60574651 in _libmsvcrt_a_iname () #31 0x6057593d in _libmsvcrt_a_iname () #32 0x6b07098e in _libmsvcrt_a_iname () #33 0x672dd8f7 in _libmsvcrt_a_iname () #34 0x672dedcb in _libmsvcrt_a_iname () #35 0x672defaa in _libmsvcrt_a_iname () #36 0x60574eae in _libmsvcrt_a_iname () #37 0x006448d2 in gnc_ui_start_event_loop () at gnc-gnome-utils.c:380 #38 0x00401746 in inner_main (closure=0x0, argc=1, argv=0xbd6950) at gnucash-bin.c:493 #39 0x65e2564d in scm_boot_guile (argc=1, argv=0xbd6950, main_func=0x401600 inner_main, closure=0x0) at init.c:635 #40 0x00401e26 in main (argc=1, argv=0xbd6950) at gnucash-bin.c:549 (gdb) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling GnuCash on Windows
Well, when on my WinXP I change in Control Panel-Regional and Language Settings-Regional Options: from - Standards and Formats=Latvian - Location=Latvia to - Standards and Formats=English (United States) - Location=United States I can open Scheduled Transaction Editor without crashing GC. Ivars ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
Phil Longstaff [EMAIL PROTECTED] writes: What version of LibGDA do you need to get GdaQuery? Is libgda-1.9.100 recent enough? Or do you need something more recent than that? (I ask because 1.9.100 is what FC5 has). I don't know. On the www.gnome-db.org web site, the 1.9.102.changes file is the first one I can see that mentions GdaQuery. That, of course, doesn't mean it doesn't exist earlier. Hmm.. I just pulled down libgda-devel and it indeed looks like there is no GdaQuery. I'm hesitant to request support from a GDA feature that's so new that even FC5 can't use it! I was willing to work with the upgraded SWIG dependency because it's only needed to build from SVN (not the tarball), but this would be a runtime requirement, which means we should be more conservative about it. Sorry, I think we should delay the use of GdaQuery... Phil -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
On Fri, Nov 03, 2006 at 10:09:47AM -0500, Derek Atkins wrote: Phil Longstaff [EMAIL PROTECTED] writes: What version of LibGDA do you need to get GdaQuery? Is libgda-1.9.100 recent enough? Or do you need something more recent than that? (I ask because 1.9.100 is what FC5 has). I don't know. On the www.gnome-db.org web site, the 1.9.102.changes file is the first one I can see that mentions GdaQuery. That, of course, doesn't mean it doesn't exist earlier. Hmm.. I just pulled down libgda-devel and it indeed looks like there is no GdaQuery. I'm hesitant to request support from a GDA feature that's so new that even FC5 can't use it! I was willing to work with the upgraded SWIG dependency because it's only needed to build from SVN (not the tarball), but this would be a runtime requirement, which means we should be more conservative about it. Sorry, I think we should delay the use of GdaQuery... The fact that FC5-extras has 1.9.100 is irrelavant. That's an unstable release. It's not even forward API-compatible with newer unstable releases. It also has some pretty serious bugs. You have to target a stable api - either 1.2 (FC5 also has 1.2.3) or the still-in-beta 2.0. IMO, 1.2 is not even worth looking at. As far as depending on a library version that's newer than our target distros... my advice is choose the best tool for the job. We know how to deal with the release engineering issues. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
2006/11/3, Derek Atkins [EMAIL PROTECTED]: Phil Longstaff [EMAIL PROTECTED] writes: What version of LibGDA do you need to get GdaQuery? Is libgda-1.9.100 recent enough? Or do you need something more recent than that? (I ask because 1.9.100 is what FC5 has). I don't know. On the www.gnome-db.org web site, the 1.9.102.changes file is the first one I can see that mentions GdaQuery. That, of course, doesn't mean it doesn't exist earlier. Hmm.. I just pulled down libgda-devel and it indeed looks like there is no GdaQuery. I'm hesitant to request support from a GDA feature that's so new that even FC5 can't use it! The version we MUST use is at least 1.99.1, for download in http://www.gnome-db.org/Download The stable version doen't support most of the objects like GdaQuery, Dictionary and so; I recommend to use the lastest Beta2 version (1.99.1), I'm contributing in the project and see the benefits of use a architecture based in Objects like GObject does, it's simple and quick to extend. If any one want to lear how to use GdaQuery and most of the most advanced characteristics in GDA you can read the documentation, and inspect the code in the convenient functions I'd created (you can find them in libgda/gda-init.c) I was willing to work with the upgraded SWIG dependency because it's only needed to build from SVN (not the tarball), but this would be a runtime requirement, which means we should be more conservative about it. How could we manage about this to desing over a OO using GObject. Sorry, I think we should delay the use of GdaQuery... Sad, a Design over a Object could give GC a powerfull framework and a clear design. -- Trabajar, la mejor arma para tu superación de grano en grano, se hace la arena (R) (entrámite, pero para los cuates: LIBRE) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
Quoting Daniel Espinosa [EMAIL PROTECTED]: 2006/11/2, Derek Atkins [EMAIL PROTECTED]: Quoting Phil Longstaff [EMAIL PROTECTED]: I have started working on a gda backend and am starting with a QofQuery - SQL translator. I assume no one else has such a beast (there is a SQL - QofQuery translator as part of QOF. When we get an SQL backend, it won't make sense to translate SQL - QofQuery - SQL). I have also looked at the pattern of queries. When GC starts, there is only one query - for bills which need to be paid. There is no query for the account tree, for example. GC must assume that session_begin loads the account tree. The PG Backend has a sample Query - SQL converter, but it's very limited -- it only does Transaction (Split) searches. Is this expected behaviour? I had assumed that everything would be queried for. This is expected behavior. Take a look at the PG Backend. All of the accounts are expected to get loaded at start time. From the business side, the Tax Tables and Terms are also expected to get loaded at start time. Not everything gets loaded by a query. Why you need to load all the registers in memory? in GDA you can use a GdaDataModel to refer a table or a query and get the data *just* when you use it, I think this is better in terms of performance. Who said anything about loading all of the registers in memory? Please read what I wrote. If you don't understand what I'm saying, please ask me to define the words. I realize that English is not your first language, but your question here seems like a fundamental misunderstanding of what I wrote. GnuCash ABSOLUTELY only pulls in transactions when necessary. However the ACCOUNTS are pulled in at start time. Actually, what it probably wants to do in the long run is pull in all the transactions from the current period into RAM (because operating from RAM is faster than operating from Disk).. But not pull in transactions from previous periods. Then it could query over those older transactions when necessary. Secondly, I looked at the begin/commit edit behaviour when an account was being created. There was a *lot* of begin/commit activity on the commodity, including some cases of begin/commit/commit. Is this expected behaviour? Begin/Commit can be nested (and indeed SHOULD be nested, IMNSHO).. However the begins and commits should be balanced. If they are not balanced then that is a bug. Using a GdaDataModel or a GdaQuery, you can directly modify the data in the DataBase using a begin/commit transaction (usefull in a multiuser enviroment), of course this could fix the *autosave* future request becouse you can edit a transaction and when saved it wil be automaticaly commit to the server/database. You're missing a fundamental architectural design of QOF and GnuCash. Please go study QOF and then come back here. Only the final commit() should push the data out to the database. GDA allows you to commit the data directly with out a buffer managed by GC and then commited when the user push the Save Button. So What? GnuCash doesn't do that. To GnuCash, GDA is JUST A DATA STORE. I dont know how to make it more clear. Anything else would be a fundamental change to the way gnucash operates and would be a MAJOR re-write of much of the gnucash source code. I dont think anyone wants that right now. Incremental changes are good. -dere -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
2006/11/3, Derek Atkins [EMAIL PROTECTED]: Quoting Daniel Espinosa [EMAIL PROTECTED]: 2006/11/2, Derek Atkins [EMAIL PROTECTED]: Quoting Phil Longstaff [EMAIL PROTECTED]: I have started working on a gda backend and am starting with a QofQuery - SQL translator. I assume no one else has such a beast (there is a SQL - QofQuery translator as part of QOF. When we get an SQL backend, it won't make sense to translate SQL - QofQuery - SQL). I have also looked at the pattern of queries. When GC starts, there is only one query - for bills which need to be paid. There is no query for the account tree, for example. GC must assume that session_begin loads the account tree. The PG Backend has a sample Query - SQL converter, but it's very limited -- it only does Transaction (Split) searches. Is this expected behaviour? I had assumed that everything would be queried for. This is expected behavior. Take a look at the PG Backend. All of the accounts are expected to get loaded at start time. From the business side, the Tax Tables and Terms are also expected to get loaded at start time. Not everything gets loaded by a query. Why you need to load all the registers in memory? in GDA you can use a GdaDataModel to refer a table or a query and get the data *just* when you use it, I think this is better in terms of performance. Who said anything about loading all of the registers in memory? Please read what I wrote. If you don't understand what I'm saying, please ask me to define the words. I realize that English is not your first language, but your question here seems like a fundamental misunderstanding of what I wrote. Derek I'm sorry if you can't admit any that his first language isn't english and a missundertanding could occur I'm trying to question in the best way, with out injury to any, the GC architecture and try to HELP to have a better one. GnuCash ABSOLUTELY only pulls in transactions when necessary. However the ACCOUNTS are pulled in at start time. Actually, what it probably wants to do in the long run is pull in all the transactions from the current period into RAM (because operating from RAM is faster than operating from Disk).. But not pull in transactions from previous periods. Then it could query over those older transactions when necessary. Secondly, I looked at the begin/commit edit behaviour when an account was being created. There was a *lot* of begin/commit activity on the commodity, including some cases of begin/commit/commit. Is this expected behaviour? Begin/Commit can be nested (and indeed SHOULD be nested, IMNSHO).. However the begins and commits should be balanced. If they are not balanced then that is a bug. Using a GdaDataModel or a GdaQuery, you can directly modify the data in the DataBase using a begin/commit transaction (usefull in a multiuser enviroment), of course this could fix the *autosave* future request becouse you can edit a transaction and when saved it wil be automaticaly commit to the server/database. You're missing a fundamental architectural design of QOF and GnuCash. Please go study QOF and then come back here. I don't missing that, I have studied the QOF enough to know that is a GObject like implementation with a kind of GInterface, where you have to implement the methods in order to do the work like (init, dispouse, begin transaction, commit, roll back, and so). If QOF have a GObject like architecture, may you can create objects where you can have methods for the GC to make his work, and allow any to derive from them to implement a new characteristics, even if the Backend have a GInterface (it has) you can implement the it in order to create a new back end a a clear way (I know this way in on the QOF's documentation); GDA has this kind of architecture in order to allow new Providers (any) implement the API and allow to be used inside a GDA app. I see you don't want to help any one that doesn't have a previous knowlege about QOF, even if he/she have some knowlege about GObject architecture; I know that may you haven't time enough but I haven't time to learn QOF, I prefer to learn more about GObject. Only the final commit() should push the data out to the database. GDA allows you to commit the data directly with out a buffer managed by GC and then commited when the user push the Save Button. So What? GnuCash doesn't do that. To GnuCash, GDA is JUST A DATA STORE. I dont know how to make it more clear. Anything else would be a fundamental change to the way gnucash operates and would be a MAJOR re-write of much of the gnucash source code. I dont think anyone wants that right now. Incremental changes are good. Is good to hear you incremental changes are good, but I can see you can't support to hear any discution about that. Sorry but I don't know who you are, are you the mantainer and have you the last word about
Re: GC, QOF and queries
Quoting Daniel Espinosa [EMAIL PROTECTED]: I'm trying to question in the best way, with out injury to any, the GC architecture and try to HELP to have a better one. The steps towards a better architecture are: 1) Convert QOF to use GObject natively instead of being GObject-like 2) Using the same QOF APIs, try to use GDA natively inside QOF 3) Consider moving more information into QOF. However, in the short term, major architectural changes aren't on the table. Using a GdaDataModel or a GdaQuery, you can directly modify the data in the DataBase using a begin/commit transaction (usefull in a multiuser enviroment), of course this could fix the *autosave* future request becouse you can edit a transaction and when saved it wil be automaticaly commit to the server/database. You're missing a fundamental architectural design of QOF and GnuCash. Please go study QOF and then come back here. I don't missing that, I have studied the QOF enough to know that is a GObject like implementation with a kind of GInterface, where you have to implement the methods in order to do the work like (init, dispouse, begin transaction, commit, roll back, and so). This is true, QOF is gobject-like If QOF have a GObject like architecture, may you can create objects where you can have methods for the GC to make his work, and allow any to derive from them to implement a new characteristics, even if the Backend have a GInterface (it has) you can implement the it in order to create a new back end a a clear way (I know this way in on the QOF's documentation); GDA has this kind of architecture in order to allow new Providers (any) implement the API and allow to be used inside a GDA app. Yes, but it's still just the backend.. The front end isn't changing. GnuCash is still buffering the data (through QOF). QOF is just a framework; the objects themselves are still cached in RAM, and implemented by GnuCash. QOF just provides the framework to hold it all together and Query over those objects. I see you don't want to help any one that doesn't have a previous knowlege about QOF, even if he/she have some knowlege about GObject architecture; I know that may you haven't time enough but I haven't time to learn QOF, I prefer to learn more about GObject. It's not that I don't want to help, but I want to help make forward progress in small steps. Your questions read to me the same as someone asking: * Why can't I rewrite GnuCash in C++? * Why can't change GnuCash to use WxWindows? * Why can't we write reports in python? * Why isn't GnuCash a client/server Web Application? Hundreds of man-years of effort have gone into the current GnuCash code. It's irresponsible to just throw that all away. Making fundamental changes to the way to application works is detremental to the process. This thread started as a SQL BACKEND. That's a very limited scope, and I'm happy helping someone (you, Phil, Matthew, or anyone else) to make progress on a SQL Backend. That backend can use GDA. Fine. No problem. But discussions of fundamental architectural shifts of the gnucash application? Sorry, not interested. Incremental changes are good. Is good to hear you incremental changes are good, but I can see you can't support to hear any discution about that. But you're not talking about that.. You're talking about fundamental changes. Let's take small steps here! Sorry but I don't know who you are, are you the mantainer and have you the last word about GnuCash? Pretty much, yes. I'm the longest-standing core developer. I'm a major feature contributor. I'm an active maintainer. I'm customer support. And I'm the hosting/service provider. So, yes, what I say tends to carry a LOT of weight. But as you can see from other email, I'm open to listen. Chris convinced me that we should look forward to GDA-2 (through 1.99) instead of keeping with 1.9 Is QOF the realy unique way to solve the GC's objectives? Can't be moved out or GC must use it in order to work with databases? I think you're asking, is QOF the ONLY way to solve GC's objectives? Of course not. KMyMoney doesn't use QOF; it solves the problem differently. However, can QOF get removed from GnuCash? No. QOF is a fundamental GnuCash architecture. Now, could QOF get changed over time to be more like a GDA Wrapper? Maybe. But that's not something I think should be discussed in the same conversation as a SQL Backend. I'm trying to keep the conversation focused on the task at hand instead of looking towards projects that are probably 5 years out. And yes, realistically I see what you propose as something that wouldn't happen for five years. I don't think so. -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
Re: GC, QOF and queries
On Fri, 2006-03-11 at 13:58 -0500, Derek Atkins wrote: But as you can see from other email, I'm open to listen. Chris convinced me that we should look forward to GDA-2 (through 1.99) instead of keeping with 1.9 I have seen Chris's e-mail proposing we use GDA-2 (1.99) instead of 1.2, but haven't seen agreement from you (except for this). Do you agree then that use of GdaQuery is OK? Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
Quoting Chris Shoemaker [EMAIL PROTECTED]: The fact that FC5-extras has 1.9.100 is irrelavant. That's an unstable release. It's not even forward API-compatible with newer unstable releases. It also has some pretty serious bugs. Ahh, so it is. I thought it was in core, not extras. Also, I notice that as of last week there's now a 1.99.1, aka 2.0 BETA. You have to target a stable api - either 1.2 (FC5 also has 1.2.3) or the still-in-beta 2.0. IMO, 1.2 is not even worth looking at. Yeah, no point looking to 1.2 with 2.0 right around the corner. As far as depending on a library version that's newer than our target distros... my advice is choose the best tool for the job. We know how to deal with the release engineering issues. I'd certainly prefer not to have to deal with these issues ourselves, but yeah, let's look to GDA 2.0. I retract my complaint. -chris -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling GnuCash on Windows
Hi, Am Freitag, den 03.11.2006, 11:07 +0200 schrieb Ivars Grinbergs: Sorry, I was in rush in the morning and I missed one important point - number (3): I used Image Base instead of Mapping Start :( Below it is, when Mapping Start is uesd, but before that, I would like to mention that test results reported before was true when run from gdb; when I tried this newest version without gdb, reports cause gc to crash (gnu crash :) ). From within gdb, reports run fine. (gdb) bt #0 0x6b072b01 in _libmsvcrt_a_iname () #1 0x673116f0 in _libmsvcrt_a_iname () #2 0x6b073034 in _libmsvcrt_a_iname () #3 0x6b046dd4 in __RUNTIME_PSEUDO_RELOC_LIST__ () #4 0x0063a3dc in gnc_dense_cal_init (dcal=0x32280f0) at gnc-dense-cal.c:337 snip Bingo! See r15080 (impossible without above information). Big thanks! Could you please check whether it works for you now? -- andi5 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r15081 - gnucash/trunk/src/gnome-utils - Inform the user about 'gnucash-docs' package when Help is selected with
Hi, Am Freitag, den 03.11.2006, 14:50 -0500 schrieb Andreas Köhler: Author: andi5 Date: 2006-11-03 14:50:54 -0500 (Fri, 03 Nov 2006) New Revision: 15081 Trac: http://svn.gnucash.org/trac/changeset/15081 Modified: gnucash/trunk/src/gnome-utils/gnc-gnome-utils.c Log: Inform the user about 'gnucash-docs' package when Help is selected with no content. Fixes #347102. Oh, do not we want that to be backported? -- andi5 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
2006/11/3, Derek Atkins [EMAIL PROTECTED]: Quoting Daniel Espinosa [EMAIL PROTECTED]: I'm trying to question in the best way, with out injury to any, the GC architecture and try to HELP to have a better one. The steps towards a better architecture are: 1) Convert QOF to use GObject natively instead of being GObject-like 2) Using the same QOF APIs, try to use GDA natively inside QOF 3) Consider moving more information into QOF. However, in the short term, major architectural changes aren't on the table. I'll try to joint to the QOF mailing team and try to help in this issues. Using a GdaDataModel or a GdaQuery, you can directly modify the data in the DataBase using a begin/commit transaction (usefull in a multiuser enviroment), of course this could fix the *autosave* future request becouse you can edit a transaction and when saved it wil be automaticaly commit to the server/database. You're missing a fundamental architectural design of QOF and GnuCash. Please go study QOF and then come back here. I don't missing that, I have studied the QOF enough to know that is a GObject like implementation with a kind of GInterface, where you have to implement the methods in order to do the work like (init, dispouse, begin transaction, commit, roll back, and so). This is true, QOF is gobject-like If QOF have a GObject like architecture, may you can create objects where you can have methods for the GC to make his work, and allow any to derive from them to implement a new characteristics, even if the Backend have a GInterface (it has) you can implement the it in order to create a new back end a a clear way (I know this way in on the QOF's documentation); GDA has this kind of architecture in order to allow new Providers (any) implement the API and allow to be used inside a GDA app. Yes, but it's still just the backend.. The front end isn't changing. GnuCash is still buffering the data (through QOF). QOF is just a framework; the objects themselves are still cached in RAM, and implemented by GnuCash. QOF just provides the framework to hold it all together and Query over those objects. I have some work about the implementation of GDA using a code from Chis, and yes I'd used QOF and try to implement most of the interfaces, but becouse I don't understand most of GC I couldn't find who to work with the parameters sended when the function is called by GC, even that, I want to finish the definition of the database schema to find out later how to implement in the begin_session function using just GDA. But as you can see from other email, I'm open to listen. Chris convinced me that we should look forward to GDA-2 (through 1.99) instead of keeping with 1.9 I can help here!, I was working for about 1 year in GDA 1.9x.x development process, basicaly in this areas: - Porting the GdaValue to GValue - Creation of Convenient functions to easy use of GDA - Fix compilations problems for the C# bindings (I'm not a C# programer, just find the way to fix them) - I have a work to make GnomeDB work in Glade3 (mostly finished) - I have to modify some GnomeDB widgets in order to work well in Glade3, and fixed some issues I know some about GObject architecture, I plan to use this to understand QOF, that's the easy part, and plan to implement most of the Interface to create the backend privider independient as far as I could, focus on SQLite for the first time and PosgreSQL in parallel. -- Trabajar, la mejor arma para tu superación de grano en grano, se hace la arena (R) (entrámite, pero para los cuates: LIBRE) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r15081 - gnucash/trunk/src/gnome-utils - Inform the user about 'gnucash-docs' package when Help is selected with
Am Freitag, 3. November 2006 21:31 schrieb Andreas Köhler: Hi, Am Freitag, den 03.11.2006, 14:50 -0500 schrieb Andreas Köhler: Author: andi5 Date: 2006-11-03 14:50:54 -0500 (Fri, 03 Nov 2006) New Revision: 15081 Trac: http://svn.gnucash.org/trac/changeset/15081 Modified: gnucash/trunk/src/gnome-utils/gnc-gnome-utils.c Log: Inform the user about 'gnucash-docs' package when Help is selected with no content. Fixes #347102. Oh, do not we want that to be backported? Absolutely. But it additionally requires r15082. Both together look good to me and can be back-ported just fine. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Gnucash doesn't work with external QOF (was: Re: GC, QOF and queries)
Am Freitag, 3. November 2006 21:40 schrieb Daniel Espinosa: 2006/11/3, Derek Atkins [EMAIL PROTECTED]: 1) Convert QOF to use GObject natively instead of being GObject-like 2) Using the same QOF APIs, try to use GDA natively inside QOF 3) Consider moving more information into QOF. However, in the short term, major architectural changes aren't on the table. I'll try to joint to the QOF mailing team and try to help in this issues. Oooops. Did you think by saying QOF we mean the separate QOF project at sourceforge.net? We are very sorry for this misunderstanding. No, the separate QOF project at sourceforge is a fork from gnucash that forked in April this year, and it has been diverging into a different development path. Its code will not work with gnucash anymore and vice very. Instead, by QOF we mean the general idea of the query-object-framework, whose code currently is in lib/libqof/ in the gnucash repository (it might be moved to src/libqof/ sometime in the future, but the place in the repository isn't too important). Again: The external QOF project at sourceforge.net does not work with gnucash and the only similarity is that it's a fork from the gnucash code by the beginning of this year. So its mailing list also has no use for the development gnucash right now. All discussion of the QOF concept related to gnucash are going on here on gnucash-devel, and all the source code is in the gnucash repository below lib/libqof/. I hope this clears up this issue. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
On Fri, 2006-11-03 at 12:26 -0600, Daniel Espinosa wrote: I see you don't want to help any one that doesn't have a previous knowlege about QOF, even if he/she have some knowlege about GObject architecture; I know that may you haven't time enough but I haven't time to learn QOF, I prefer to learn more about GObject. GObject's great and all, but you can't refuse to understand QOF. It's core to the gnucash engine and backend implementation, for better or for worse. You can't just pretend it's doesn't exist. Is QOF the realy unique way to solve the GC's objectives? Can't be moved out or GC must use it in order to work with databases? Abstracty, no. And QOF should probably become a layer over GObject at some point, rather than (effectively) re-implementing parts of it. Keep in mind that QOF started at a time before GObject existed, let alone was accepted and popular... But that's not really the point: GnuCash *is* implemented in terms of QOF, right now. As such, the DB backend is best achieved by working within that framework. (Or put off entirely while GnuCash is re-written in terms of GObject plus a re-tooled QOF.) -- ...jsled http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
On Fri, 2006-03-11 at 14:40 -0600, Daniel Espinosa wrote: I know some about GObject architecture, I plan to use this to understand QOF, that's the easy part, and plan to implement most of the Interface to create the backend privider independient as far as I could, focus on SQLite for the first time and PosgreSQL in parallel. I'm already creating a backend for GDA. Are you creating another one? Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
Quoting Phil Longstaff [EMAIL PROTECTED]: On Fri, 2006-03-11 at 14:40 -0600, Daniel Espinosa wrote: I know some about GObject architecture, I plan to use this to understand QOF, that's the easy part, and plan to implement most of the Interface to create the backend privider independient as far as I could, focus on SQLite for the first time and PosgreSQL in parallel. I'm already creating a backend for GDA. Are you creating another one? I think, Phil, that you should use Daniel as a resource to better understand GDA. Daniel, I think you should provide your GDA knowledge to Phil who seems to better understand the issue at hand. I leave it to you two to figure out how to best work together. Phil, you might want to try to model the GDA backend similar to the File Backend where you can add plugins that supply additional tables or callbacks. Also, you probably wants a settings table where you can keep things like DB Schema version, etc. Finally, when designing the schema you should keep in mind that we probably want an audit table so we can look back at who changed what (and maybe even when). Also, in the DB we probably want a 'last updated' column on each primary table so we can easily keep track of when changes were made.. This would be useful for multi-user cache coherency. Phil -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
On Fri, 2006-03-11 at 17:00 -0500, Derek Atkins wrote: I think, Phil, that you should use Daniel as a resource to better understand GDA. Daniel, I think you should provide your GDA knowledge to Phil who seems to better understand the issue at hand. I leave it to you two to figure out how to best work together. Phil, you might want to try to model the GDA backend similar to the File Backend where you can add plugins that supply additional tables or callbacks. Also, you probably wants a settings table where you can keep things like DB Schema version, etc. What I'm doing is basically what the file backend does. Each qof object type registers a backend handler using qof_object_register_backend(). Then, when I want to run on query on a certain object type or commit an object, I find the corresponding backend handler and call its load or commit routine. The file backend only does this for business-related objects, but I'm doing it for all objects. Finally, when designing the schema you should keep in mind that we probably want an audit table so we can look back at who changed what (and maybe even when). Also, in the DB we probably want a 'last updated' column on each primary table so we can easily keep track of when changes were made.. This would be useful for multi-user cache coherency. I know the postgres backend has something like an audit table. I'll think about how that could be handled. Last updated column is probably pretty straightforward too. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
2006/11/3, Phil Longstaff [EMAIL PROTECTED]: On Fri, 2006-03-11 at 17:00 -0500, Derek Atkins wrote: I think, Phil, that you should use Daniel as a resource to better understand GDA. Daniel, I think you should provide your GDA knowledge to Phil who seems to better understand the issue at hand. I leave it to you two to figure out how to best work together. Of course I just want to help! Phil, you might want to try to model the GDA backend similar to the File Backend where you can add plugins that supply additional tables or callbacks. Also, you probably wants a settings table where you can keep things like DB Schema version, etc. What I'm doing is basically what the file backend does. Each qof object type registers a backend handler using qof_object_register_backend(). Then, when I want to run on query on a certain object type or commit an object, I find the corresponding backend handler and call its load or commit routine. The file backend only does this for business-related objects, but I'm doing it for all objects. Could you post some of your work directly to me and may I can send you some comments and some work I have. I'll try to understand the QOF on the way, and after implement this backend, may I have the enough knowleage to contribute in other areas. Finally, when designing the schema you should keep in mind that we probably want an audit table so we can look back at who changed what (and maybe even when). Also, in the DB we probably want a 'last updated' column on each primary table so we can easily keep track of when changes were made.. This would be useful for multi-user cache coherency. I know the postgres backend has something like an audit table. I'll think about how that could be handled. Last updated column is probably pretty straightforward too. It could be made through the commit sequence. In PostgreSQL and MySQL you can trigger a function that save the changes in an audit table (I do that actualy in my DB in PostgreSQL). -- Trabajar, la mejor arma para tu superación de grano en grano, se hace la arena (R) (entrámite, pero para los cuates: LIBRE) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash doesn't work with external QOF (was: Re: GC, QOF and queries)
2006/11/3, Christian Stimming [EMAIL PROTECTED]: Am Freitag, 3. November 2006 21:40 schrieb Daniel Espinosa: 2006/11/3, Derek Atkins [EMAIL PROTECTED]: 1) Convert QOF to use GObject natively instead of being GObject-like 2) Using the same QOF APIs, try to use GDA natively inside QOF 3) Consider moving more information into QOF. However, in the short term, major architectural changes aren't on the table. I'll try to joint to the QOF mailing team and try to help in this issues. Oooops. Did you think by saying QOF we mean the separate QOF project at sourceforge.net? We are very sorry for this misunderstanding. No, the separate QOF project at sourceforge is a fork from gnucash that forked in April this year, and it has been diverging into a different development path. Its code will not work with gnucash anymore and vice very. Instead, by QOF we mean the general idea of the query-object-framework, whose code currently is in lib/libqof/ in the gnucash repository (it might be moved to src/libqof/ sometime in the future, but the place in the repository isn't too important). Again: The external QOF project at sourceforge.net does not work with gnucash and the only similarity is that it's a fork from the gnucash code by the beginning of this year. So its mailing list also has no use for the development gnucash right now. All discussion of the QOF concept related to gnucash are going on here on gnucash-devel, and all the source code is in the gnucash repository below lib/libqof/. I hope this clears up this issue. Regards, Thanks for point this. Then the documentation isn't equal, . Then the only is read the code and study how it works? Ok! :-) -- Trabajar, la mejor arma para tu superación de grano en grano, se hace la arena (R) (entrámite, pero para los cuates: LIBRE) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash doesn't work with external QOF (was: Re: GC, QOF and queries)
Quoting Daniel Espinosa [EMAIL PROTECTED]: Thanks for point this. Then the documentation isn't equal, . Then the only is read the code and study how it works? Ok! :-) The QOF documentation at http://cvs.gnucash.org/docs/HEAD is accurate. -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
