2007-01-16 GnuCash IRC logs

01:17:12 *** wizkid238_ has joined #gnucash
01:19:23 *** AlonzoTG has quit IRC
01:26:41 *** wizkid238 has quit IRC
01:52:33 *** Esaj has joined #gnucash
02:44:13 *** ErKa has joined #gnucash
02:56:51 *** Esaj has quit IRC
03:04:43 *** Esaj has joined #gnucash
03:21:43 *** RallyU has joined #gnucash
03:52:22 *** ceplma has joined #gnucash
04:02:23 *** bonez39 has left #gnucash
04:03:23 *** ceplma has quit IRC
04:09:56 *** ceplma has joined #gnucash
04:16:35 *** RallyU has quit IRC
05:34:17 *** cstim has joined #gnucash
05:34:17 *** gncbot sets mode: +o cstim
05:41:45 *** kielein has joined #gnucash
05:41:54 *** motin_ has quit IRC
05:42:20 <cstim> good morning. Has anyone here ever had to deal with calling conventions on win32? __stdcall vs. __cdecl ? In gwen/aqbanking, Martin Preuss said if we're calling a function through a function pointer on mingw/gcc, that function seems to require __stdcall or else the stack is corrupted.
05:43:24 <cstim> Unexpectedly, he says this is true even if both the called function and the caller are all inside the same program, compiled by the same compiler and with the same standard __cdecl calling convention.
05:44:57 <cstim> Whereas in all the internet texts it instead says that (only) the Microsoft win32 API has been compiled by Microsoft with __stdcall, so if you want to call functions there or pass function pointers to there, you better use the correct calling convention __stdcall there. But in our case, no inter-compiler calls are involved.
06:16:16 *** ceplma has quit IRC
06:16:47 *** ErKa has quit IRC
06:27:37 *** ceplma has joined #gnucash
07:04:29 *** motin has quit IRC
07:15:01 *** warlord-afk has quit IRC
07:44:54 *** kielein has quit IRC
08:06:43 *** twunder has joined #gnucash
08:42:07 *** hampton|away is now known as hampton
08:57:56 *** RallyU has joined #gnucash
09:17:03 *** warlord has joined #gnucash
09:21:39 *** tats has joined #gnucash
09:22:13 *** RallyU has quit IRC
09:45:59 <jsled> Today's edition of "gnucash-user subject line: ham or spam!?": "Invoice Loans", from evincent {at} rock.com.
09:46:12 <jsled> Note as a special circumstance that this message was sent twice.
09:47:56 <jsled> Bzzt, time's up! The answer: spam.
09:48:03 <cstim> heh
09:48:33 <jsled> Time to shovel some snow, biaw.
09:49:38 <cstim> snow?
09:49:46 * cstim hasn't seen any snow this winter
09:50:34 <cstim> http://wiki.gnucash.org/wiki/Talk:Windows seems to me like a quite funny question
09:55:41 *** wizkid238_ is now known as wizkid238
10:00:20 <warlord> amusing
10:00:50 *** ceplma has quit IRC
10:01:32 <cstim> warlord: have you ever heard about these issues with the calling conventions?
10:04:32 <cstim> (that I mentioned above?)
10:05:11 *** rlaager has joined #gnucash
10:05:13 <warlord> Sorry, I've only been here for an hour..
10:06:04 <hampton> bbiab
10:06:07 *** hampton has left #gnucash
10:06:17 <cstim> http://lists.gnucash.org/logs/2007-01-16.html#T05:42:20
10:08:08 <warlord> cstim: I've certainly heard that that could be a problem... But are you actually seeing problems?
10:08:22 *** ceplma has joined #gnucash
10:08:47 <rlaager> I'm looking for information on book closing. I have 2.0.1 and don't see any options. The FAQ says it's in SVN, which IIRC has been the answer for quite some time. Is it in the trunk or on a branch? Has it been updated recently? What's holding it out of releases?
10:09:19 *** ErKa has joined #gnucash
10:13:16 <warlord> rlaager: it was disabled in 2.0.x because it wasn't working right.
10:14:04 <cstim> warlord: I didn't see problems but I didn't do any significant testing on win32. Martin said he saw problems that were fixed once he introduced __stdcall.
10:15:13 <warlord> I'm happy to do:
10:15:19 <warlord> #ifdef G_OS_WIN32
10:15:28 <warlord> #define STDCALL __stdcall
10:15:32 <warlord> #else
10:15:33 <jsled> rlaager: it looks like it's been un-disabled in trunk/
10:15:34 <warlord> #define STDCALL
10:15:37 <warlord> #endif
10:15:45 <jsled> (sorry for interrupting the flow)
10:16:02 <warlord> rlaager: yeah, it's been undisabled in trunk, but unless the code is fixed it'll be re-disabled for 2.2.
10:16:22 *** ceplma has quit IRC
10:16:41 <warlord> cstim: I've certainly heard about __stdcall issues on win32, but I dont understand them.
10:17:05 *** ceplma has joined #gnucash
10:18:15 *** tats has quit IRC
10:18:15 <rlaager> warlord: Am I correct in assuming that it's non-trivial to fix? (In other words... Since I don't know about GnuCash internals, I wouldn't be able to fix it?)
10:19:04 <warlord> I honestly don't know.
10:19:37 <cstim> rlaager: we disabled it because nobody was working on it anymore, and so far nobody has picked it up again.
10:20:33 <rlaager> So are people just manually closing books by moving Income & Expenses to Retained Earnings then?
10:20:42 <cstim> warlord: well, this ifdef is what Martin already uses. However, aqbanking uses to many callback functions that it'll be a major PITA to use this __stdcall everywhere. I'd prefer if I could find a source that cleary says this is not necessary, or that clearly says this effort is indeed inevitable.
10:20:53 <cstim> s/to many/so many/
10:22:09 <warlord> rlaager: yes. The current "book closing" does much more than just that.
10:24:09 <warlord> cstim: well, it would be limited to the code in import-export/ right?
10:24:21 <rlaager> warlord: Are there any docs on this? I've seen things written by various people, yourself included, dating from 2001-2004, but I'm never sure what's current and accurate.
10:24:24 <warlord> (but yes, it would be a major PITA to do it)
10:24:32 <warlord> rlaager: DOCS?!?!? Hahahahahahahahahahahahahaahahahahahahaaha
10:24:53 <jsled> http://gnuaccounting.sourceforge.net/
10:24:58 <warlord> Linas was working on that code.. Then he stopped. It was never completed.
10:25:30 <jsled> [[[
10:25:31 <jsled> This thing is GPL, although Borland keeps the source code for the used XYLayout and XYConstraints closed. If somebody could patch it so that it runs without XYLayout/XYConstraints or, even better, runs as a SWT-app, feel free to do so and please send me the code.
10:25:35 <jsled> ]]] - ibid.
10:26:29 <jsled> Um. Though it looks like that text might be old, as it is an SWT app.
10:28:04 <rlaager> cstim: I forwarded your question to the Gaim win32 guy, in case he has any idea.
10:28:53 *** hampton2 has joined #gnucash
10:28:54 *** gncbot sets mode: +o hampton2
10:29:05 <jsled> Also: http://inverted-tree.livejournal.com/55450.html < which is about treeview column resizing, which might be relevant for us in register-rewrite land.
10:34:13 <cstim> rlaager: thanks
10:35:35 <rlaager> So my next question.... I've read some notes about adding inventory control to GnuCash. Is anyone working on that?
10:36:08 *** datallah has joined #gnucash
10:36:51 <warlord> nope
10:37:00 <datallah> Hi... rlaager sent me over to help with win32 calling conventions
10:38:12 <cstim> datallah: cool, that's my topic. Here's what I wrote: http://lists.gnucash.org/logs/2007-01-16.html#T05:42:20
10:39:26 *** ErKa has quit IRC
10:40:07 <datallah> cstim: ok. Well, you can use either calling convention from a function reference, but the compiler needs to be able to tell which convention to use.
10:41:26 <datallah> the default is stdcall (which is why the cdecls fail since it isn't specified explictly
10:42:02 <cstim> datallah: I'm talking about a pure-mingw/gcc project here. Is the default really stdcall on win32? I thought it were cdecl
10:43:25 <datallah> oh.. sorry, you're right, I got them backwards. cdecl is the default.
10:44:19 <cstim> datallah: ok. That's what I thought. So the other author (Martin) said he saw problems when he didn't declare the pointers (and its respective implementation functions) as stdcall
10:44:55 <cstim> datallah: but since this would imply a lot of programming work, I'm still looking whether there is a source that confirms this, as opposed to an error on his side.
10:46:49 <cstim> Because by what I know, it seems as if nothing is declared, then simply all is the default cdecls and this should work just as well.
10:47:08 <datallah> hmm... that *is* strange. It is backwards. I know that I've used lots of function references that weren't explicitly defined without issues.
10:47:30 <datallah> none of the internals in gaim specify a calling convention
10:47:46 <cstim> I can send you a simple test case (DLL and main program) that supports my claim that we don't need a specified calling convention
10:48:16 <datallah> does the testcase fail for you?
10:48:46 <cstim> no, only if conflicting calling conventions are specified.
10:48:57 <cstim> (which give a compiler warning, correctly.)
10:49:01 <datallah> (which is what you would expect)
10:49:08 <cstim> yes
10:50:17 <datallah> it *could* be a bug in whichever version of gcc he is using
10:51:18 <cstim> hm... the bugzilla at gcc only mentions issues with some c++ constellations, like "ignored decoration on static member functions of template classes" and such.
10:51:31 <cstim> but not with plain C functions
10:53:39 <cstim> You said you've used lots of function references without explicit calling convention decoration? That would be a hint that there isn't a problem.
10:54:13 <elb> as long as you're only using C, you should be safe
10:54:25 *** mnoir has joined #gnucash
10:54:38 <cstim> elb: any sources for this statement?
10:55:31 <elb> well, I see with more research that you're talking about win32 (I had only read what was on-screen)
10:55:34 <elb> so no, you're probably screwed
10:55:41 <datallah> hehe
10:55:44 <elb> but on any *normal* system, in C you should be safe ;-)
10:56:48 <elb> the internals in Gaim do not specify a calling convention because they're all compiled of a part, and as such all the same calling convention
10:56:49 <cstim> elb: (cough) this whole stupid discussion needs to be done solely because of a win32 port.
10:57:01 <elb> yeah, I told you (or someone) before that that was a stupid idea
10:57:08 <elb> enjoy ;-)
10:59:46 <warlord> :-P
11:01:33 <cstim> Ok. I can see the conclusion that in this case probably the default calling convention is fine. I'll go back to gwenhywfar/aqbanking with this.
11:01:55 <cstim> Thanks for your thoughts.
11:02:10 <rlaager> I'm ending up with blank transactions once and a while when I change my mind about something I'm doing. I can reproduce it most simply with these steps: 1) Click blank transaction, 2) click/tab into the account, 3) start typing an account name, 4) delete the account name and click back to another transaction. A blank transaction was just added to the account.
11:02:53 <rlaager> datallah: Thanks for stopping by to help the GnuCash guys. I owe you. ;)
11:03:25 <rlaager> It seems to me that GnuCash shouldn't add a transaction with no details.
11:06:47 *** tats has joined #gnucash
11:23:01 *** ErKa has joined #gnucash
11:23:51 *** ceplma has quit IRC
11:24:19 *** esodan has joined #gnucash
11:25:30 *** cstim has quit IRC
11:26:01 *** warlord has quit IRC
11:32:13 *** ceplma has joined #gnucash
11:35:10 *** ceplma_ has joined #gnucash
11:58:46 *** AlonzoTG has joined #gnucash
11:59:09 <AlonzoTG> Okay, today I'm getting the scheme backtrace bug that was reported on the forums/bugzilla. =(
11:59:23 <AlonzoTG> meanwhile, I'm squandering my money left and right...
11:59:28 <AlonzoTG> I really need to get this under control...
11:59:36 <jsled> AlonzoTG: if it's that important, don't run an unstable distribution.
11:59:46 <jsled> Revert back to the known-good package versions.
11:59:56 <AlonzoTG> =|
12:00:02 <AlonzoTG> I don't keep track of versions that closely.
12:00:27 <jsled> slib-2.4.6 is the key one.
12:00:40 <AlonzoTG> to do that, I'd have to update my machine one package at a time and test each of 700 packages for crashes each time...
12:00:49 <jsled> Huh?
12:01:04 <AlonzoTG> about a quarter of which are known to crash my computer hard due to serious driver regressions in the stupid kernel.
12:01:11 <jsled> If you want gnucash to work, `emerge =slib-2.4.6`.
12:01:18 <jsled> AlonzoTG: are you running ~x86 ?
12:02:58 <AlonzoTG> yes, for reasons I've long since forgotten. =P
12:03:48 <jsled> I always recommend keywording only really specific versions with /etc/portage/package.{keyword,mask}.
12:04:54 <jsled> In any case, if you want gnucash to work while gentoo sorts out their scheme upgrades, just go back to slib-2.4.6.
12:05:32 <jsled> You might need to add slib-2.4.6 to /etc/portage/profile/package.provided so emerge doesn't try to upgrade it in the future.
12:05:56 <jsled> s/need/want/
12:12:45 *** warlord has joined #gnucash
12:12:45 *** gncbot sets mode: +o warlord
12:15:01 *** tats_ has joined #gnucash
12:15:02 *** tats has quit IRC
12:17:53 *** tats has joined #gnucash
12:17:54 *** tats_ has quit IRC
12:47:41 *** tri has joined #gnucash
13:00:58 *** ErKa has quit IRC
13:05:15 <tri> warlord: i finished compiling gnucash from svn without g-wrap - it runs ;-)
13:06:15 <warlord> good to know :)
13:11:34 <tri> i only have a problem with something about makeinfo and with texi files - but i cann't remember it exactly
13:14:43 <tri> i solved the makeinfo problem by "touch /usr/bin/makeinfo" (lol)
13:16:25 *** tats has quit IRC
13:18:22 *** minDscrm has quit IRC
13:23:51 *** rlaager has quit IRC
13:27:15 <warlord> tri: it means you probably dont have texinfo installed.
13:37:32 *** minDscrm has joined #gnucash
14:15:56 *** tats has joined #gnucash
14:18:08 *** andi5 has joined #gnucash
14:18:09 *** gncbot sets mode: +o andi5
14:26:29 <twunder> jsled: another take on Pachelbel: http://www.youtube.com/watch?v=QjA5faZF1A8
14:44:48 *** |gunni| has joined #gnucash
14:44:58 *** |gunni| has quit IRC
14:48:37 *** |gunni| has joined #gnucash
14:49:06 *** |gunni| has joined #gnucash
14:49:58 *** |gunni| has joined #gnucash
14:53:14 *** |gunni| has joined #gnucash
14:55:15 *** sjc has joined #gnucash
15:09:10 *** esodan has quit IRC
15:11:48 *** tri has left #gnucash
15:11:49 *** tats has quit IRC
15:12:26 *** tats has joined #gnucash
15:13:56 *** andi5 has quit IRC
16:40:32 *** tats has quit IRC
16:57:21 *** bonez39 has joined #gnucash
17:11:40 *** bonez39 has quit IRC
17:12:11 *** twunder has quit IRC
17:23:20 *** tats has joined #gnucash
17:28:54 *** andi5 has joined #gnucash
17:28:54 *** gncbot sets mode: +o andi5
17:29:23 *** bonez39 has joined #gnucash
18:06:40 <jsled> Heh heh. http://uwog.net/blog/index.php/archives/66
18:07:40 <andi5> like g_open software?
18:07:57 <andi5> s,software,source, ... (in your complete backlog)
18:08:17 <jsled> hee. :)
18:08:50 <andi5> jsled: have you ever tried unionfs?
18:10:50 <jsled> andi5: no, I've not.
18:11:19 <jsled> Seems cool, though.
18:11:52 <andi5> ah, ok :) ... i just thought you gentoo guys know everything ;-) ... thinking about compiling guile1.8 from source, but my CFLAGS list is already damn long :(
18:12:41 <andi5> it is nice... guile-1.8 is in debian unstable / ubuntu, but it conflicts with libgwrap-runtime0-dev....
18:18:23 *** bonez39 has quit IRC
18:20:02 <warlord> I wonder why this guy's Preferences aren't working for him?
18:54:28 *** Esaj has quit IRC
18:55:37 *** mnoir has quit IRC
19:19:57 *** andi5 has quit IRC
19:20:52 *** warlord is now known as warlord-afk
19:22:27 *** tats has quit IRC
19:47:02 *** prock_ has joined #gnucash
19:48:18 *** prock_ is now known as prock
20:49:01 *** mnoir has joined #gnucash
21:12:04 *** sjc has quit IRC
21:24:11 *** mnoir has quit IRC
21:24:35 *** warlord-afk has quit IRC
21:25:07 *** twunder has joined #gnucash
21:42:48 *** twunder has quit IRC
21:46:58 *** twunder has joined #gnucash
22:18:32 *** twunder has quit IRC
01:17:12 *** wizkid238_ has joined #gnucash
01:19:23 *** AlonzoTG has quit IRC
01:26:41 *** wizkid238 has quit IRC
01:52:33 *** Esaj has joined #gnucash
02:44:13 *** ErKa has joined #gnucash
02:56:51 *** Esaj has quit IRC
03:04:43 *** Esaj has joined #gnucash
03:21:43 *** RallyU has joined #gnucash
03:52:22 *** ceplma has joined #gnucash
04:02:23 *** bonez39 has left #gnucash
04:03:23 *** ceplma has quit IRC
04:09:56 *** ceplma has joined #gnucash
04:16:35 *** RallyU has quit IRC
05:34:17 *** cstim has joined #gnucash
05:34:17 *** gncbot sets mode: +o cstim
05:41:45 *** kielein has joined #gnucash
05:41:54 *** motin_ has quit IRC
05:42:20 <cstim> good morning. Has anyone here ever had to deal with calling conventions on win32? __stdcall vs. __cdecl ? In gwen/aqbanking, Martin Preuss said if we're calling a function through a function pointer on mingw/gcc, that function seems to require __stdcall or else the stack is corrupted.
05:43:24 <cstim> Unexpectedly, he says this is true even if both the called function and the caller are all inside the same program, compiled by the same compiler and with the same standard __cdecl calling convention.
05:44:57 <cstim> Whereas in all the internet texts it instead says that (only) the Microsoft win32 API has been compiled by Microsoft with __stdcall, so if you want to call functions there or pass function pointers to there, you better use the correct calling convention __stdcall there. But in our case, no inter-compiler calls are involved.
06:16:16 *** ceplma has quit IRC
06:16:47 *** ErKa has quit IRC
06:27:37 *** ceplma has joined #gnucash
07:04:29 *** motin has quit IRC
07:15:01 *** warlord-afk has quit IRC
07:44:54 *** kielein has quit IRC
08:06:43 *** twunder has joined #gnucash
08:42:07 *** hampton|away is now known as hampton
08:57:56 *** RallyU has joined #gnucash
09:17:03 *** warlord has joined #gnucash
09:21:39 *** tats has joined #gnucash
09:22:13 *** RallyU has quit IRC
09:45:59 <jsled> Today's edition of "gnucash-user subject line: ham or spam!?": "Invoice Loans", from evincent {at} rock.com.
09:46:12 <jsled> Note as a special circumstance that this message was sent twice.
09:47:56 <jsled> Bzzt, time's up! The answer: spam.
09:48:03 <cstim> heh
09:48:33 <jsled> Time to shovel some snow, biaw.
09:49:38 <cstim> snow?
09:49:46 * cstim hasn't seen any snow this winter
09:50:34 <cstim> http://wiki.gnucash.org/wiki/Talk:Windows seems to me like a quite funny question
09:55:41 *** wizkid238_ is now known as wizkid238
10:00:20 <warlord> amusing
10:00:50 *** ceplma has quit IRC
10:01:32 <cstim> warlord: have you ever heard about these issues with the calling conventions?
10:04:32 <cstim> (that I mentioned above?)
10:05:11 *** rlaager has joined #gnucash
10:05:13 <warlord> Sorry, I've only been here for an hour..
10:06:04 <hampton> bbiab
10:06:07 *** hampton has left #gnucash
10:06:17 <cstim> http://lists.gnucash.org/logs/2007-01-16.html#T05:42:20
10:08:08 <warlord> cstim: I've certainly heard that that could be a problem... But are you actually seeing problems?
10:08:22 *** ceplma has joined #gnucash
10:08:47 <rlaager> I'm looking for information on book closing. I have 2.0.1 and don't see any options. The FAQ says it's in SVN, which IIRC has been the answer for quite some time. Is it in the trunk or on a branch? Has it been updated recently? What's holding it out of releases?
10:09:19 *** ErKa has joined #gnucash
10:13:16 <warlord> rlaager: it was disabled in 2.0.x because it wasn't working right.
10:14:04 <cstim> warlord: I didn't see problems but I didn't do any significant testing on win32. Martin said he saw problems that were fixed once he introduced __stdcall.
10:15:13 <warlord> I'm happy to do:
10:15:19 <warlord> #ifdef G_OS_WIN32
10:15:28 <warlord> #define STDCALL __stdcall
10:15:32 <warlord> #else
10:15:33 <jsled> rlaager: it looks like it's been un-disabled in trunk/
10:15:34 <warlord> #define STDCALL
10:15:37 <warlord> #endif
10:15:45 <jsled> (sorry for interrupting the flow)
10:16:02 <warlord> rlaager: yeah, it's been undisabled in trunk, but unless the code is fixed it'll be re-disabled for 2.2.
10:16:22 *** ceplma has quit IRC
10:16:41 <warlord> cstim: I've certainly heard about __stdcall issues on win32, but I dont understand them.
10:17:05 *** ceplma has joined #gnucash
10:18:15 *** tats has quit IRC
10:18:15 <rlaager> warlord: Am I correct in assuming that it's non-trivial to fix? (In other words... Since I don't know about GnuCash internals, I wouldn't be able to fix it?)
10:19:04 <warlord> I honestly don't know.
10:19:37 <cstim> rlaager: we disabled it because nobody was working on it anymore, and so far nobody has picked it up again.
10:20:33 <rlaager> So are people just manually closing books by moving Income & Expenses to Retained Earnings then?
10:20:42 <cstim> warlord: well, this ifdef is what Martin already uses. However, aqbanking uses to many callback functions that it'll be a major PITA to use this __stdcall everywhere. I'd prefer if I could find a source that cleary says this is not necessary, or that clearly says this effort is indeed inevitable.
10:20:53 <cstim> s/to many/so many/
10:22:09 <warlord> rlaager: yes. The current "book closing" does much more than just that.
10:24:09 <warlord> cstim: well, it would be limited to the code in import-export/ right?
10:24:21 <rlaager> warlord: Are there any docs on this? I've seen things written by various people, yourself included, dating from 2001-2004, but I'm never sure what's current and accurate.
10:24:24 <warlord> (but yes, it would be a major PITA to do it)
10:24:32 <warlord> rlaager: DOCS?!?!? Hahahahahahahahahahahahahaahahahahahahaaha
10:24:53 <jsled> http://gnuaccounting.sourceforge.net/
10:24:58 <warlord> Linas was working on that code.. Then he stopped. It was never completed.
10:25:30 <jsled> [[[
10:25:31 <jsled> This thing is GPL, although Borland keeps the source code for the used XYLayout and XYConstraints closed. If somebody could patch it so that it runs without XYLayout/XYConstraints or, even better, runs as a SWT-app, feel free to do so and please send me the code.
10:25:35 <jsled> ]]] - ibid.
10:26:29 <jsled> Um. Though it looks like that text might be old, as it is an SWT app.
10:28:04 <rlaager> cstim: I forwarded your question to the Gaim win32 guy, in case he has any idea.
10:28:53 *** hampton2 has joined #gnucash
10:28:54 *** gncbot sets mode: +o hampton2
10:29:05 <jsled> Also: http://inverted-tree.livejournal.com/55450.html < which is about treeview column resizing, which might be relevant for us in register-rewrite land.
10:34:13 <cstim> rlaager: thanks
10:35:35 <rlaager> So my next question.... I've read some notes about adding inventory control to GnuCash. Is anyone working on that?
10:36:08 *** datallah has joined #gnucash
10:36:51 <warlord> nope
10:37:00 <datallah> Hi... rlaager sent me over to help with win32 calling conventions
10:38:12 <cstim> datallah: cool, that's my topic. Here's what I wrote: http://lists.gnucash.org/logs/2007-01-16.html#T05:42:20
10:39:26 *** ErKa has quit IRC
10:40:07 <datallah> cstim: ok. Well, you can use either calling convention from a function reference, but the compiler needs to be able to tell which convention to use.
10:41:26 <datallah> the default is stdcall (which is why the cdecls fail since it isn't specified explictly
10:42:02 <cstim> datallah: I'm talking about a pure-mingw/gcc project here. Is the default really stdcall on win32? I thought it were cdecl
10:43:25 <datallah> oh.. sorry, you're right, I got them backwards. cdecl is the default.
10:44:19 <cstim> datallah: ok. That's what I thought. So the other author (Martin) said he saw problems when he didn't declare the pointers (and its respective implementation functions) as stdcall
10:44:55 <cstim> datallah: but since this would imply a lot of programming work, I'm still looking whether there is a source that confirms this, as opposed to an error on his side.
10:46:49 <cstim> Because by what I know, it seems as if nothing is declared, then simply all is the default cdecls and this should work just as well.
10:47:08 <datallah> hmm... that *is* strange. It is backwards. I know that I've used lots of function references that weren't explicitly defined without issues.
10:47:30 <datallah> none of the internals in gaim specify a calling convention
10:47:46 <cstim> I can send you a simple test case (DLL and main program) that supports my claim that we don't need a specified calling convention
10:48:16 <datallah> does the testcase fail for you?
10:48:46 <cstim> no, only if conflicting calling conventions are specified.
10:48:57 <cstim> (which give a compiler warning, correctly.)
10:49:01 <datallah> (which is what you would expect)
10:49:08 <cstim> yes
10:50:17 <datallah> it *could* be a bug in whichever version of gcc he is using
10:51:18 <cstim> hm... the bugzilla at gcc only mentions issues with some c++ constellations, like "ignored decoration on static member functions of template classes" and such.
10:51:31 <cstim> but not with plain C functions
10:53:39 <cstim> You said you've used lots of function references without explicit calling convention decoration? That would be a hint that there isn't a problem.
10:54:13 <elb> as long as you're only using C, you should be safe
10:54:25 *** mnoir has joined #gnucash
10:54:38 <cstim> elb: any sources for this statement?
10:55:31 <elb> well, I see with more research that you're talking about win32 (I had only read what was on-screen)
10:55:34 <elb> so no, you're probably screwed
10:55:41 <datallah> hehe
10:55:44 <elb> but on any *normal* system, in C you should be safe ;-)
10:56:48 <elb> the internals in Gaim do not specify a calling convention because they're all compiled of a part, and as such all the same calling convention
10:56:49 <cstim> elb: (cough) this whole stupid discussion needs to be done solely because of a win32 port.
10:57:01 <elb> yeah, I told you (or someone) before that that was a stupid idea
10:57:08 <elb> enjoy ;-)
10:59:46 <warlord> :-P
11:01:33 <cstim> Ok. I can see the conclusion that in this case probably the default calling convention is fine. I'll go back to gwenhywfar/aqbanking with this.
11:01:55 <cstim> Thanks for your thoughts.
11:02:10 <rlaager> I'm ending up with blank transactions once and a while when I change my mind about something I'm doing. I can reproduce it most simply with these steps: 1) Click blank transaction, 2) click/tab into the account, 3) start typing an account name, 4) delete the account name and click back to another transaction. A blank transaction was just added to the account.
11:02:53 <rlaager> datallah: Thanks for stopping by to help the GnuCash guys. I owe you. ;)
11:03:25 <rlaager> It seems to me that GnuCash shouldn't add a transaction with no details.
11:06:47 *** tats has joined #gnucash
11:23:01 *** ErKa has joined #gnucash
11:23:51 *** ceplma has quit IRC
11:24:19 *** esodan has joined #gnucash
11:25:30 *** cstim has quit IRC
11:26:01 *** warlord has quit IRC
11:32:13 *** ceplma has joined #gnucash
11:35:10 *** ceplma_ has joined #gnucash
11:58:46 *** AlonzoTG has joined #gnucash
11:59:09 <AlonzoTG> Okay, today I'm getting the scheme backtrace bug that was reported on the forums/bugzilla. =(
11:59:23 <AlonzoTG> meanwhile, I'm squandering my money left and right...
11:59:28 <AlonzoTG> I really need to get this under control...
11:59:36 <jsled> AlonzoTG: if it's that important, don't run an unstable distribution.
11:59:46 <jsled> Revert back to the known-good package versions.
11:59:56 <AlonzoTG> =|
12:00:02 <AlonzoTG> I don't keep track of versions that closely.
12:00:27 <jsled> slib-2.4.6 is the key one.
12:00:40 <AlonzoTG> to do that, I'd have to update my machine one package at a time and test each of 700 packages for crashes each time...
12:00:49 <jsled> Huh?
12:01:04 <AlonzoTG> about a quarter of which are known to crash my computer hard due to serious driver regressions in the stupid kernel.
12:01:11 <jsled> If you want gnucash to work, `emerge =slib-2.4.6`.
12:01:18 <jsled> AlonzoTG: are you running ~x86 ?
12:02:58 <AlonzoTG> yes, for reasons I've long since forgotten. =P
12:03:48 <jsled> I always recommend keywording only really specific versions with /etc/portage/package.{keyword,mask}.
12:04:54 <jsled> In any case, if you want gnucash to work while gentoo sorts out their scheme upgrades, just go back to slib-2.4.6.
12:05:32 <jsled> You might need to add slib-2.4.6 to /etc/portage/profile/package.provided so emerge doesn't try to upgrade it in the future.
12:05:56 <jsled> s/need/want/
12:12:45 *** warlord has joined #gnucash
12:12:45 *** gncbot sets mode: +o warlord
12:15:01 *** tats_ has joined #gnucash
12:15:02 *** tats has quit IRC
12:17:53 *** tats has joined #gnucash
12:17:54 *** tats_ has quit IRC
12:47:41 *** tri has joined #gnucash
13:00:58 *** ErKa has quit IRC
13:05:15 <tri> warlord: i finished compiling gnucash from svn without g-wrap - it runs ;-)
13:06:15 <warlord> good to know :)
13:11:34 <tri> i only have a problem with something about makeinfo and with texi files - but i cann't remember it exactly
13:14:43 <tri> i solved the makeinfo problem by "touch /usr/bin/makeinfo" (lol)
13:16:25 *** tats has quit IRC
13:18:22 *** minDscrm has quit IRC
13:23:51 *** rlaager has quit IRC
13:27:15 <warlord> tri: it means you probably dont have texinfo installed.
13:37:32 *** minDscrm has joined #gnucash
14:15:56 *** tats has joined #gnucash
14:18:08 *** andi5 has joined #gnucash
14:18:09 *** gncbot sets mode: +o andi5
14:26:29 <twunder> jsled: another take on Pachelbel: http://www.youtube.com/watch?v=QjA5faZF1A8
14:44:48 *** |gunni| has joined #gnucash
14:44:58 *** |gunni| has quit IRC
14:48:37 *** |gunni| has joined #gnucash
14:49:06 *** |gunni| has joined #gnucash
14:49:58 *** |gunni| has joined #gnucash
14:53:14 *** |gunni| has joined #gnucash
14:55:15 *** sjc has joined #gnucash
15:09:10 *** esodan has quit IRC
15:11:48 *** tri has left #gnucash
15:11:49 *** tats has quit IRC
15:12:26 *** tats has joined #gnucash
15:13:56 *** andi5 has quit IRC
16:40:32 *** tats has quit IRC
16:57:21 *** bonez39 has joined #gnucash
17:11:40 *** bonez39 has quit IRC
17:12:11 *** twunder has quit IRC
17:23:20 *** tats has joined #gnucash
17:28:54 *** andi5 has joined #gnucash
17:28:54 *** gncbot sets mode: +o andi5
17:29:23 *** bonez39 has joined #gnucash
18:06:40 <jsled> Heh heh. http://uwog.net/blog/index.php/archives/66
18:07:40 <andi5> like g_open software?
18:07:57 <andi5> s,software,source, ... (in your complete backlog)
18:08:17 <jsled> hee. :)
18:08:50 <andi5> jsled: have you ever tried unionfs?
18:10:50 <jsled> andi5: no, I've not.
18:11:19 <jsled> Seems cool, though.
18:11:52 <andi5> ah, ok :) ... i just thought you gentoo guys know everything ;-) ... thinking about compiling guile1.8 from source, but my CFLAGS list is already damn long :(
18:12:41 <andi5> it is nice... guile-1.8 is in debian unstable / ubuntu, but it conflicts with libgwrap-runtime0-dev....
18:18:23 *** bonez39 has quit IRC
18:20:02 <warlord> I wonder why this guy's Preferences aren't working for him?
18:54:28 *** Esaj has quit IRC
18:55:37 *** mnoir has quit IRC
19:19:57 *** andi5 has quit IRC
19:20:52 *** warlord is now known as warlord-afk
19:22:27 *** tats has quit IRC
19:47:02 *** prock_ has joined #gnucash
19:48:18 *** prock_ is now known as prock
20:49:01 *** mnoir has joined #gnucash
21:12:04 *** sjc has quit IRC
21:24:11 *** mnoir has quit IRC
21:24:35 *** warlord-afk has quit IRC
21:25:07 *** twunder has joined #gnucash
21:42:48 *** twunder has quit IRC
21:46:58 *** twunder has joined #gnucash
22:18:32 *** twunder has quit IRC