2007-01-28 GnuCash IRC logs

00:14:48 <andi5> hampton: testing material has arrived on trunk
00:36:39 *** Geot has quit IRC
00:39:26 *** andi5 has quit IRC
00:56:20 <warlord> good night.
00:56:27 *** warlord is now known as warlord-afk
00:56:33 <hampton> night
01:35:29 *** jpeach has joined #gnucash
01:47:01 *** jpeach has left #gnucash
02:35:23 *** benoitg has joined #gnucash
02:50:55 *** benoitg has left #gnucash
02:58:09 *** benoitg has joined #gnucash
03:10:23 *** ErKa has joined #gnucash
03:17:41 *** Demitar_ has quit IRC
03:32:53 *** ErKa has quit IRC
05:39:28 *** ceplma has quit IRC
05:40:36 *** kielein has joined #gnucash
06:26:52 *** sjc has joined #gnucash
07:01:46 *** sjc has quit IRC
07:19:45 *** |gunni| has joined #gnucash
07:43:29 *** Demitar has joined #gnucash
07:59:50 *** andi5 has joined #gnucash
07:59:50 *** gncbot sets mode: +o andi5
08:09:37 *** MrN has joined #gnucash
08:09:53 <MrN> hi
08:14:44 *** warlord-afk is now known as warlord
08:40:33 *** ceplma has joined #gnucash
08:42:51 *** MrN has quit IRC
08:52:13 *** sjc has joined #gnucash
09:26:02 *** prock_ is now known as prock
09:26:08 <andi5> good morning, warlord :)
09:26:19 <warlord> hi.
09:26:20 <warlord> biab
09:47:10 <warlord> back
09:47:13 <warlord> hiya andi5
10:11:15 <andi5> warlord: i am completely confused.... see http://pastebin.ca/raw/331085 and guess what it prints :)
10:13:42 <andi5> http://pastebin.ca/raw/331087 deglibized version, same result
10:26:16 <warlord> andi5: change 10 -> 10.0 and 2 -> 2.0
10:30:20 <andi5> http://pastebin.ca/raw/331100 , same story
10:31:02 <andi5> FYI, it prints 99 \n 100 \n
10:32:23 <warlord> even on linux?
10:32:34 <andi5> i do not know... probably not
10:33:13 <warlord> /tmp/test.c:8: warning: incompatible implicit declaration of built-in function ‘printf’
10:33:26 <warlord> /tmp/test
10:33:26 <warlord> 100
10:33:26 <warlord> 100
10:33:55 <warlord> Sounds like broken floating-point math on windows
10:33:57 <andi5> ok, so i included #stdio.h now... *asks on #mingw*
10:39:37 <warlord> okay
10:40:02 <warlord> I still get 100 100
10:40:34 <andi5> lol, i did not really expect a change :)
10:47:17 <warlord> Me either.
10:47:45 <andi5> ok, so i am not the only one seeing 99/100.... the first step of manuy
10:47:58 <warlord> ok
11:31:43 <andi5> warlord: http://pastebin.ca/raw/331149 .... seems like both solutions work :)
11:33:09 *** Esaj has joined #gnucash
11:36:28 <warlord> so do you have a working code example?
11:39:13 <andi5> well, i will just try to get "make check" to work :)
11:39:54 <warlord> that's fine... :)
11:40:39 <warlord> feel free to add that comment to the sorce code somewhere and then you can refer back to it where you need to make the changes..
11:41:02 <andi5> yes, i will make a big fat warning :)
11:41:10 <warlord> :)
12:07:01 *** wizkid238 has joined #gnucash
12:08:54 *** wizkid238_ has quit IRC
12:15:35 <hampton> Re: broken floating point. You really should read http://catless.ncl.ac.uk/Risks/24.53.html#subj7.3 by Spaf. Its eye-opening.
12:19:53 <andi5> ooook....
12:21:44 <warlord> Interesting...
12:22:25 <warlord> hey, hampton, any chance you could audit r15435 for me?
12:28:15 *** jpeach has joined #gnucash
12:29:03 * hampton shakes his head
12:29:11 <hampton> From the g_rename man page:
12:29:21 <hampton> Note in particular that on Win9x it is not possible to rename a file if a file with the new name already exists. Also it is not possible in general on Windows to rename an open file.
12:29:36 <andi5> yeah, welcome on windows
12:29:53 *** twunder has joined #gnucash
12:29:53 <hampton> so how does that affect r15435?
12:29:54 <warlord> Hmm...
12:30:04 <andi5> sometimes "make install" fails for me, because something is not fast enough in closing some file ;-)
12:30:13 <andi5> not at all for branches/2.0
12:30:23 <warlord> Well, for backport it doesn't matter because 2.0 isn't win32
12:30:25 <hampton> Aside from that, the patch is good.
12:30:35 <warlord> but it means we do need a better solution for trunk
12:30:54 <andi5> well, i was unable to compile libqof, so i needed a fix :-)
12:31:09 <warlord> andi5: sorry, I didn't think about it.
12:31:14 <hampton> Or a different solution for win32. What Bill provided is an elegant solution for everything else.
12:31:37 <andi5> warlord: no, it was nearly perfect.... that way you can really cherry-pick the commit for backporting
12:31:46 <warlord> Actually, I gave it to him.
12:32:21 <hampton> OK, that's en elegant patch you came up with. :-)
12:32:27 <warlord> *chuckles*
12:32:41 <warlord> His original patch just had it printing to stderr.
12:33:08 <warlord> So hampton I can backport that patch?
12:33:14 <hampton> yes
12:33:17 <warlord> thanks
12:33:43 <andi5> warlord: backport_list.empty == NULL?
12:33:53 <andi5> oh, well... you know what i mean ;-)
12:34:37 <warlord> It will be empty shortly. :)
12:35:45 <hampton> I've got a fix implmented to
12:35:48 <hampton> oops
12:36:25 *** andi5 has quit IRC
12:37:15 <hampton> I've got a fix implemented to migrate the state file from "invalid" to valid keys. Its *not* backward compatible and I really don't see how it can be. I.E. After running with this version of gnucash, you loose your state file if you go back to an older version. Is this a problem?
12:37:55 <warlord> It might be.
12:38:00 <hampton> Of course, if you've upgraded to glib 2.12.7 you've already lost your state file. :-(
12:38:19 <warlord> We might want to at least add the code to read both versions..
12:38:28 <warlord> (and be able to backport that)
12:40:19 <hampton> So users can drop back from 2.0.5 to 2.0.4? The state file was completely different in 1.8.
12:40:57 <warlord> More so that users can drop back from 2.1/2.2 to 2.0.5 if necessary.
12:41:26 <hampton> That's not a problem. The only problem is pre 2.0.5 vs 2.0.5 or later.
12:41:50 <warlord> *ponders*
12:42:23 <hampton> Oh, this is definitely something that needs to be backported to 2.0. Users have already run into glib > 2.12.7 and had problems.
12:42:25 <warlord> I'm not sure what that would mean..
12:42:46 <warlord> I guess there's not a good way to make it work with 2.0.x x<5, huh?
12:42:52 <hampton> I really only see it as a problem for devs who use more than one dev tree on the same data file.
12:43:25 *** andi5 has joined #gnucash
12:43:25 *** gncbot sets mode: +o andi5
12:43:34 <hampton> the only was would be to have gnucash continue to write state files where the key name includes spaces.
12:44:13 <hampton> The problem with that is that glib 2.12.7 won't read or store anything if the key name has a space.
12:44:41 <hampton> The reading part was relaxed from a failure to a warning in 2.12.9 (I think). Not sure about the write part.
12:44:57 <andi5> hampton: my state file was written perfectly with glib 2.12.9, so i guess the old behavior is in use again?
12:45:12 <hampton> Did you get a ton of warnings in the trace file?
12:47:20 <andi5> hm... damn, i just rebooted... but my gnucash.trace says "error reading group Window 1 key Page Count: Die Schlüsselwertedatei enthält nicht die Gruppe »Window 1«" ... hmpf
12:47:29 <hampton> I'm running 2.12.7 in my test libs and it flat out refuses to read the state file.
12:47:47 <andi5> maybe i was to eager in updating glib...
12:48:00 <hampton> you should have one of those errors for each key read.
12:49:07 <andi5> no, i only have these warnings for group names
12:49:25 <andi5> probably because it never really reads [Window 1]
12:51:19 <hampton> Section names can have spaces, just not key names
12:52:20 * andi5 compiles glib 2.12.9
12:56:35 *** MrN has joined #gnucash
12:57:03 <MrN> re
13:01:25 <hampton> I realized last night that my fc'x' libs aren't the latest and greatest. I've got gnome as of the 12/30/06 switch from cvs to svn.
13:01:38 <hampton> Figured I update once I got this patch committed.
13:02:44 <andi5> hampton: i hope i did not slow you down too much
13:02:58 <hampton> nope
13:03:15 <warlord> Well, I'm all caught up with backports.. So I'm gonna head out for a bit. TTYL.
13:03:17 *** warlord is now known as warlord-afk
13:03:29 <hampton> I needed your commit so I didn't break fc4
13:03:46 <hampton> any objection to my proposed changes before you go?
13:03:58 <hampton> warlord-afk: any objection to my proposed changes before you go?
13:06:10 <warlord-afk> I'm just... concerned.
13:06:14 *** warlord-afk is now known as warlord
13:06:42 <warlord> any chance you could do a runtime test and only do the change if you detect you're running with the broken version?
13:07:58 <warlord> I'd ask chris. He's a major "backwards compatibility" freak. ;)
13:08:01 <hampton> I could. It would mean keeping the old key names in the source and potentially modifying them on each access to the data file.
13:08:24 <hampton> np. I'll work on my rg changes this afternoon.
13:09:20 <warlord> ok
13:09:23 *** warlord is now known as warlord-afk
13:13:18 *** twunder has quit IRC
13:36:26 <chris> IMO, the standard for backward-compatibility of the state-file is _way_ lower than for the data file. I wouldn't sweat it.
13:44:11 *** twunder has joined #gnucash
13:45:03 *** jpeach has left #gnucash
14:26:01 *** warlord-afk is now known as warlord
14:36:08 <andi5> hm... i think there is a problem in engine/test/test-numeric.c, around line 660.... above there is " This test presumes that RAND_MAX is approx 2^32" ... that is definitely not the case on windows, where it is 0x7fff, i.e. 2^15 .... i do not know much about our arithmetic, but it seems that "a" and "b" are sufficiently small, that the quotient is _not_ reduced, so the test almost always fails.... you can see this on linux, if you cheat and do no
14:37:23 <andi5> maybe it even fails _always_
14:38:29 <warlord> I think all it's saying is that rand() will return a number < 2^32, which it will.
14:44:58 <andi5> say, i set na=30 --> a = {num = 16106127360, denom = 1073741824} .... b = {num = 1, denom = 331749253} .... a/b = {num = 5343195720402862080, denom = 1073741824}, whereas ne ^= 4976238795 / 1 ....
14:46:06 <andi5> well, back in 30 minutes or so
14:54:39 *** twunder has quit IRC
14:57:04 <warlord> andi5: I dont see the problem...
15:00:25 <warlord> BIAB
15:00:27 *** warlord is now known as warlord-afk
15:02:20 *** ErKa has joined #gnucash
15:06:30 <andi5> well, obviously ... gnc_numeric_equal(a/b, ne) does not hold then, as a/b is not reduced
15:08:57 *** warlord-afk is now known as warlord
15:09:10 <warlord> but why isn't it reduced?
15:09:24 <warlord> Put the same numbers in on linux and I believe it is still reduced.
15:09:48 <andi5> hm... i thought that is what GNC_HOW_DENOM_EXACT is for in gnc_numeric_div
15:10:50 *** cstim has joined #gnucash
15:10:50 *** gncbot sets mode: +o cstim
15:11:01 <andi5> hi cstim
15:11:30 <warlord> I honestly dont recall..
15:11:39 <cstim> andi5: lange nacht yesterday :-)
15:11:40 <andi5> well, apply http://pastebin.ca/raw/331351 on linux and it will fail too
15:11:44 <andi5> yep
15:12:25 <cstim> on gnucash-de someone complains "export account hierarchy" doesn't work with his gnucash-1.8.10 :-/ Anyone recalls whether it was broken at the time?
15:13:35 <warlord> INTERESTING...
15:13:55 <warlord> (to andi5)
15:14:08 <warlord> cstim: "Export Account Hierarchy", not "Export Accounts"?
15:15:01 <andi5> warlord: i guess 2^13 is a more realistic number, but it still fails some times
15:15:11 <cstim> warlord: the latter
15:15:40 <warlord> cstim: I'm fairly sure it worked fine. In 2.0, however, the file needs to exist (it wont properly create it if it doesn't exist)
15:15:59 <warlord> andi5: Shouldn't matter.. It should work properly for all inputs.
15:17:50 <warlord> Oh, I guess we ARE going..
15:17:51 <warlord> bye
15:17:53 *** warlord is now known as warlord-afk
15:18:39 <jsled> I don't believe the file needs to exist in 2.x; I just did that a few weeks ago, and don't recall needing to touch the file first, or anything.
15:19:38 <cstim> jsled: you fixed it in 1.9.2, http://bugzilla.gnome.org/show_bug.cgi?id=332802
15:20:04 <cstim> but I think the gnucash-de guy didn't understand he should enter a new filename at the file chooser dialog.
15:22:16 *** kielein has quit IRC
15:27:39 * cstim just put Maia to bed. Hope she sleeps fine this night.
15:28:57 *** benoitg has left #gnucash
15:29:02 *** andi5 has quit IRC
15:36:35 *** ErKa has quit IRC
15:36:42 <cstim> hampton: that math checking piece is really interesting
15:37:25 *** benoitg has joined #gnucash
15:44:12 *** ErKa has joined #gnucash
15:45:37 <cstim> are there any thoughts about the date of 2.0.5?
16:31:44 *** benoitg has left #gnucash
16:35:06 *** benoitg has joined #gnucash
16:36:39 <jsled> hampton: you're inserting tab characters into source files. see src/gnome/dialog-sx-editor.c@12185 and 13324, for e.g..
16:37:31 <hampton> Is that bad? I thought there were lots of tab characters in source files. Did I miss a memo?
16:38:13 <hampton> afaix emacs has always used a combination of tab and space characters to do its indentation.
16:38:48 <jsled> I think they're bad. I thought the convention was spaces, as per the style of the file, but never tabs.
16:39:32 <jsled> Well, indent-tabs-mode controls it; it will only insert one or the other.
16:39:58 <hampton> I didn't think there was a convention, and honestly it never crossed my mind to check. I'll try to remember in the future.
16:44:52 <cstim> didn't anyone of you wonder why at startup you see the "relocation disabled" message?
16:45:12 <cstim> or did you all have autoconf <= 2.59 ?
16:45:34 <hampton> indent-tabs-mode says that its ok to insert tabs. emacs will still add spaces to get to columns that aren't a multiple of 8 spaces
16:45:52 <hampton> anyway... I'll try to be more careful in the future.
16:46:57 <hampton> huh? it re-indented the whole file? (/me just saw the diffs)
16:47:50 * chris has (setq-default indent-tabs-mode nil) in .emacs
16:49:08 <hampton> I do look for and remove white-space only changes when I review diffs. I have no idea how those changes got in.
17:01:49 <hampton> I forgot to mark r15458 for backport.
17:04:36 <jsled> cstim: I do see it, since I started working on trunk again.
17:04:56 <jsled> hampton: See, my tab stop is 4, not 8. Probably the primary reason why tab characters are a bad idea.
17:05:30 <jsled> BTW, thanks for fixing the glib compatability stuff; you have FC4 in a vmware image, right? Any chance I could get a copy of that image so I could check things myself?
17:06:23 <jsled> hampton: No, it only re-indented a few sections. I just looked for any tab chars; they seemed to be introduced in at least 2 (and probably more) commits.
17:06:47 * jsled also wishes he knew why every mailing list breaks my email signatures.
17:07:12 <jsled> (especially because it didn't happen before... maybe it's Evo-2.8's fault.)
17:09:55 *** cstim has quit IRC
17:21:12 *** ErKa has quit IRC
17:23:35 *** ErKa has joined #gnucash
17:26:56 *** jpeach has joined #gnucash
17:27:09 *** jpeach has left #gnucash
18:01:57 *** Esaj has quit IRC
18:07:20 *** prock has quit IRC
18:21:43 *** warlord-afk is now known as warlord
18:32:37 *** |gunni| has quit IRC
18:55:43 *** MrN has quit IRC
18:57:00 *** benoitg has quit IRC
19:04:54 *** ErKa has quit IRC
19:10:55 *** Esaj has joined #gnucash
19:16:28 <warlord> Hmm, I wonder why test-numeric throws so many errors if you tie na to 30 on line 630?
19:17:06 <warlord> gnc_numeric_div() fails.
19:26:24 *** wizkid238_ has joined #gnucash
19:30:20 *** wizkid238 has quit IRC
19:39:36 *** Esaj has quit IRC
19:55:22 <warlord> jsled: I thought you committed code to configure.in to remove the default -O2 when we configure with --enable-debug?
20:06:11 <chris> It was just in pastebin, never committed.
20:06:56 <chris> BTW, I was assuming that <2.0.4 would simply ignore the 2.0.5 statefiles, not crash.
20:06:56 <warlord> Oh... Oh well. I guess I'll just configure with CFLAGS='-g -O0'
20:07:06 <warlord> I was assuming that, too..
20:07:09 <warlord> Crashing is BAD.
20:10:29 <hampton> chris: I thought I had tested that, but obviously not.
20:13:43 <chris> :( looks like an unchecked retuen value in gnc_find_state_file()
20:13:59 <hampton> Its a NULL being passed to strcmp.
20:14:05 *** sjc has quit IRC
20:15:06 <chris> That just absolutely sucks.
20:16:04 <hampton> what sucks more is that if I'd written safe_strcmp() instead of strcmp() this would be a non-issue
20:17:34 <warlord> *sigh*
20:23:03 <warlord> Hmm.. Interesting. in gnc_numeric_div() when both the numerator and denominator expansions are too big to code reduces both numbers first and tries again.. but if only the numerator is "too big" then it doesn't reduce it first.
20:23:16 <warlord> s/to code/the code
20:25:25 <chris> what if we kept using the old STATE_FILE_BOOK_GUID ?
20:26:05 <hampton> Can't. It has a space in the name. Glib 2.12.whatever will refuse to read it.
20:26:24 <warlord> hampton: why can't we just use our own (old) gkeyfile.[ch] code?
20:27:50 <hampton> we could. I thought we were better off migrating to the supported glib format instead of maintaining a duplicate code base ad-infinitum.
20:28:29 <chris> wait a sec...
20:28:48 <chris> people who have < 2.0.4 with broken glib can't be helped.
20:29:05 <warlord> chris: true.
20:29:12 <chris> we can only benefit people with >=2.0.5
20:29:18 <hampton> correct. people with gnucash <2.0.5 and glib >= 2.12.5 don't get state files.
20:29:23 <chris> and not harm people with <2.0.4
20:29:30 <chris> So...
20:30:10 <chris> Why not just write out the old format with a space, and also include code that specially handles that one key.
20:30:22 <chris> Obviously, it still loaded the keyfile.
20:30:41 <chris> well, maybe that doesn't follow..
20:30:59 <chris> Maybe a broken glib would've crashes earlier?
20:31:03 <hampton> glib >=2.12.5 doesn't load any key/value pairs that contain spaces, and it won't allow you to write them.
20:31:17 <chris> but it still loads the keyfile?
20:31:44 <hampton> its basically empty. almost every key gnucash uses contains a space.
20:31:52 <chris> ok, fine.
20:32:13 <chris> So, we can use a new keyname, but leave the old one, too.
20:32:53 <warlord> But new glib wont let you write that out.
20:32:55 <chris> old gnucash will still find the old key and not crash.
20:33:00 <hampton> write two keys, and only have one make it to the state file if glib > 2.12.5?
20:33:18 <hampton> That will also produce one error message per "bad" key.
20:34:39 <warlord> How about this: use our own gkeyfile implementation for 2.0.5 and 2.1/2.2..
20:34:43 <chris> do we rewrite the whole statefile every time?
20:34:55 <warlord> But slowly migrate to a spaceless key space.
20:34:59 <warlord> chris: yes.
20:35:13 <hampton> chris: yes. that's the way the GKeyFile code in glib is implemented.
20:36:18 <hampton> its only an issue for people who use the same data file with both trunk and <2.0.x
20:36:25 <hampton> 2.0.5
20:36:51 <chris> because we won't backport it?
20:37:10 <hampton> well, now. After 2.0.5 is will be an issue for anyone who drops back from 2.0.5 to 2.0.x(x<5)
20:37:33 <hampton> I requested that it be backported for 2.0.5.
20:37:57 <chris> well, we can't backport it like this.
20:38:23 <hampton> ???
20:38:34 <warlord> I really think the short-term answer is to use our own gkeyfile implementation for 2.0.x
20:39:11 <warlord> sure, we can't help the users with 2.0.x (x<5) with broken glib, but I think changing the format now is too dangerous if it's going to crash the code.
20:39:34 <chris> how bad is the "error" message from glib?
20:39:35 <warlord> 2.0.5 can even be intelligent and understand both sets of keys..
20:39:49 <hampton> It only crashes if you go back to an older version after using the newer version.
20:40:15 <warlord> hampton: true, but anyone doing testing is going to hit that.
20:41:28 <chris> and is the error on write or on read or both?
20:41:53 <chris> I guess not read, because it just won't find it.
20:42:23 <warlord> it's on both..
20:42:32 <chris> g_fatal?
20:42:32 <warlord> (it will find it the first time)
20:42:40 <warlord> No, I think just g_warning()
20:43:24 <chris> then heck, why can't we just write the "bad" key?
20:43:41 <warlord> because glib wont let us.
20:43:48 <warlord> glib wont write it out.
20:43:59 <warlord> (this is why I say we should just use our own gkeyfile impl)
20:44:27 <chris> I thought glib 2.12.7 would let us write a bad key but warn.
20:45:02 <chris> One g_warning on file close is way better than crashing on file open.
20:45:07 <warlord> I think glib is reserving the right to make it g_fatal() again.
20:45:11 <hampton> oen per key
20:45:15 <hampton> one per key
20:45:40 <hampton> warlord: that's my understanding too
20:45:48 <chris> yeah, I'm mean just for the STATE_FILE_BOOK_GUID key
20:48:03 <chris> I'd rather avoid importing g_keyfile if we can avoid it, and if we convert all keys, but still write one extra bad key, that's only read on old gnucash, and they make it fatal later, we can post-process the file to fix that one key.
20:48:04 *** twunder has joined #gnucash
20:48:17 <hampton> That appears to work.
20:48:18 <chris> But, I'm betting they won't make it fatal in 2.x
20:50:19 <warlord> who knows what they'll do. They made it fatal without any other warning once already.
20:50:33 <chris> also, new gnucash's won't warn on loading the file, right? because that bad key won't be read.
20:51:28 <warlord> chris: wrong. if it's running with a "new" glib, it'll warn because the key is there.
20:52:26 <chris> even if it's never read?
20:53:19 <warlord> it's "read" when you read the keyfile
20:53:43 <chris> that's pretty annoying. But still, two warnings are better than a crash.
20:53:44 <hampton> correct. the warning happens when the state file is parsed.
20:56:08 <hampton> so having an extra key in the state file doesn't seem to bother gnucash/trunk on glib>2.12.5. It does throw an error message.
20:56:39 <hampton> so having an extra key in the state file keeps 2.0.4 from crashing, but there aren't any pages in the main window, not even an account tree page.
20:58:14 <chris> yeah, gotta love progress.
20:58:56 <chris> The price for going back to use an old version is that you lose your toes, but.... you get to keep your head.
21:08:29 <warlord> Well, up until a week ago we had our own version of gkeyfile already...
21:10:44 <chris> and we still do on 2.0. Are you suggesting we not migrate to the spaceless keys?
21:11:00 <warlord> Yes, that's what I'm suggesting..
21:11:27 <warlord> We migrate to using the gkeyfile code already in our tree; just adjust the API to gnc_g_keyfile()
21:14:03 <chris> seems like a pretty long-term committment
21:14:18 <warlord> Nah, just through 2.0.x
21:17:29 <chris> but the statefile is tied to the book, not the gnucash version, so what happens for 2.2?
21:17:50 <hampton> well, the gkeyfile code in our tree is currently only compiled on systems that only have glib2.4.
21:18:30 <hampton> by then a 2.0.x that doesn't crash on down grade has been out long enough that it doesn't matter?
21:19:05 <hampton> All that should take is changing a strcmp() call to safe_strcmp().
21:19:14 <warlord> right, by the time 2.2 comes out, most people would have 2.0.5 and it wouldn't crash.
21:21:29 <warlord> (or something more recent than 2.0.5)
21:22:16 <chris> backport the safe_strcmp() for sure, but I'm not comfortable knowingly triggering a crasher in a stable release.
21:23:00 <warlord> I think we should backport the safe_strcmp(), and backport code that will read both with and without spaces..
21:23:46 <hampton> What's the complete plan? Rip out r15458 from trunk and replace it with different code that uses old keys an a private version of gkeyfile. Wait until 2.2 to use glib's gkeyfile and use spaceless keys then?
21:23:52 <chris> what if we just leave 2.0.x at the whims of the glib people? (see David's recent plan.)
21:24:06 <chris> s/plan/email/
21:24:43 <warlord> I'm not comfortable leaving it at the whims of the glib people unless we have a clear timeline for 2.2 before glib 2.14
21:25:07 <chris> Then, when/if it crashes, we at least can tell people to upgrade glib.
21:25:08 <hampton> but we still need a fix for glib 2.12.[5678]
21:25:57 <warlord> do any mainstream releases have those versions?
21:26:29 * hampton laughs
21:26:52 <hampton> debian always seems to have whatever version you don't want them to have
21:27:06 <warlord> Heh. But they've probably already upgraded to 2.12.9
21:27:39 <chris> debian? when did they move to glib-2?
21:28:14 <chris> oh... "unstable" whoowhoo.
21:28:19 <warlord> yeah
21:28:44 <chris> well, I guess they've learned what that word means.
21:29:04 <hampton> stable has 2.6.4, testing has 2.12.4, unstable has 2.12.6
21:29:20 <hampton> unstable wins again!
21:29:21 <warlord> unstable still hasn't upgraded?
21:29:47 <hampton> experimental has 2.12.9
21:32:26 <chris> I might change my mind if some recent "stable" distro release included 2.12.[badidea], but in general I'm okay with leaving 2.0.x with the spaces.
21:32:49 <warlord> Oh, I think we should leave the spaces.
21:33:02 <warlord> We should probably, tho, teach 2.0.x to read the no-space keys..
21:34:01 <chris> that would be nice.
21:35:32 <hampton> The 2.0 algorithm: read key as provided. If read fails, 1) split key on spaces, 2) capitalize each component, 3) join without spaces, 4) try and read new key.
21:36:13 <warlord> That works.
21:36:33 <hampton> There's still a problem for people who use trunk and then use <2.0.5 on the same data file.
21:37:26 <warlord> Well, perhaps trunk shouldn't write out the new spaceless keys, yet..
21:38:12 <hampton> Come again? That's the whole point of the change. Protecting gnucash from willful changes made by the glib developers
21:38:52 <hampton> oh, you said yet.
21:38:59 <warlord> Yes, I said "yet"
21:39:09 <warlord> We should definitely change the keys eventually..
21:39:12 <hampton> year, we could revert the change and apply it again in two weeks or so.
21:39:20 <hampton> s/year/yeah/
21:39:32 <chris> Oh, I thought that was just your accent.
21:39:42 <warlord> Or a couple weeks after 2.0.5 is released..
21:40:01 <hampton> Are you calling me a *HILLBILLY*. ARE YOU??????
21:40:08 <hampton> Well, its true, :-)
21:40:12 <warlord> :-P
21:40:37 <chris> Oh boy, now I've made him mad, good jorb!
21:40:49 <hampton> lol
21:40:58 <hampton> so when's 2.0.5?
21:41:07 <warlord> Hopefully "soon".
21:41:14 <warlord> But I haven't heard back from Chris, yet.
21:41:55 <warlord> (but waiting for the gkeyfile fixes, obviously)
21:43:39 <hampton> Ugh. All 38 calls to g_key_file_get_xxx in 2.0 will need to be changed to new gnc_key_file_get_xxx functions that know how to munge the key.
21:44:06 <warlord> 'sed' is your friend.
21:49:54 <hampton> if you can ever get the right incantation of find to go with it.
21:50:36 <hampton> The one down side to subversion? You're comparing working files to local copies of the repository. If you every rewrite the latter you're in trouble.
21:52:32 <warlord> Oh, svk doesn't have that issue.
22:07:42 <warlord> besides, just a simple 'find . -name \*.\[ch\] ...' should work.
22:10:36 *** twunder has quit IRC
22:22:25 *** jpeac1 has joined #gnucash
22:22:33 *** jpeac1 has left #gnucash
23:18:23 <hampton> Anyone want to review the diffs to make 2.0 read spaceless keys?
23:20:34 <hampton> http://pastebin.ca/331738 (although it got the coloration wrong)
23:36:59 <chris> I'll take a gander.
23:38:48 *** prock has joined #gnucash
23:50:35 <chris> any idea why the SCHEME_OPTION code loops over keys?
23:52:10 <chris> hampton: looks fine. Is there any way to detect "keynotfound" from the gerror?
23:52:58 <chris> I probably would have done the wrappers just slightly differently... mostly aesthetic...
23:53:20 <chris> result = g_key_file_get_foo(...);
23:53:33 <hampton> I thought about a template macro, but there are subtle differences
23:53:48 <chris> if (local_error == EKEYNOTFOUND) {
23:53:59 <chris> g_clear_error...
23:54:10 <chris> new_key = translate...
23:54:27 <chris> result = g_key_file_get_foo(...)
23:54:37 <chris> g_free(new_key)
23:54:43 <chris> }
23:54:59 <chris> if (local_error) g_propagate_Error....
23:55:03 <chris> return result;
23:55:43 <chris> yeah, the template macro could get pretty ugly. It could be done, but ... yuk.
23:55:56 <hampton> I figured that you've already got a parsed key file. If a key isn't there the only likely reason is that its the wrong variant of the key.
23:56:09 <hampton> I'll see what's in the actual GError
23:59:22 <hampton> G_KEY_FILE_ERROR_KEY_NOT_FOUND
00:14:48 <andi5> hampton: testing material has arrived on trunk
00:36:39 *** Geot has quit IRC
00:39:26 *** andi5 has quit IRC
00:56:20 <warlord> good night.
00:56:27 *** warlord is now known as warlord-afk
00:56:33 <hampton> night
01:35:29 *** jpeach has joined #gnucash
01:47:01 *** jpeach has left #gnucash
02:35:23 *** benoitg has joined #gnucash
02:50:55 *** benoitg has left #gnucash
02:58:09 *** benoitg has joined #gnucash
03:10:23 *** ErKa has joined #gnucash
03:17:41 *** Demitar_ has quit IRC
03:32:53 *** ErKa has quit IRC
05:39:28 *** ceplma has quit IRC
05:40:36 *** kielein has joined #gnucash
06:26:52 *** sjc has joined #gnucash
07:01:46 *** sjc has quit IRC
07:19:45 *** |gunni| has joined #gnucash
07:43:29 *** Demitar has joined #gnucash
07:59:50 *** andi5 has joined #gnucash
07:59:50 *** gncbot sets mode: +o andi5
08:09:37 *** MrN has joined #gnucash
08:09:53 <MrN> hi
08:14:44 *** warlord-afk is now known as warlord
08:40:33 *** ceplma has joined #gnucash
08:42:51 *** MrN has quit IRC
08:52:13 *** sjc has joined #gnucash
09:26:02 *** prock_ is now known as prock
09:26:08 <andi5> good morning, warlord :)
09:26:19 <warlord> hi.
09:26:20 <warlord> biab
09:47:10 <warlord> back
09:47:13 <warlord> hiya andi5
10:11:15 <andi5> warlord: i am completely confused.... see http://pastebin.ca/raw/331085 and guess what it prints :)
10:13:42 <andi5> http://pastebin.ca/raw/331087 deglibized version, same result
10:26:16 <warlord> andi5: change 10 -> 10.0 and 2 -> 2.0
10:30:20 <andi5> http://pastebin.ca/raw/331100 , same story
10:31:02 <andi5> FYI, it prints 99 \n 100 \n
10:32:23 <warlord> even on linux?
10:32:34 <andi5> i do not know... probably not
10:33:13 <warlord> /tmp/test.c:8: warning: incompatible implicit declaration of built-in function ‘printf’
10:33:26 <warlord> /tmp/test
10:33:26 <warlord> 100
10:33:26 <warlord> 100
10:33:55 <warlord> Sounds like broken floating-point math on windows
10:33:57 <andi5> ok, so i included #stdio.h now... *asks on #mingw*
10:39:37 <warlord> okay
10:40:02 <warlord> I still get 100 100
10:40:34 <andi5> lol, i did not really expect a change :)
10:47:17 <warlord> Me either.
10:47:45 <andi5> ok, so i am not the only one seeing 99/100.... the first step of manuy
10:47:58 <warlord> ok
11:31:43 <andi5> warlord: http://pastebin.ca/raw/331149 .... seems like both solutions work :)
11:33:09 *** Esaj has joined #gnucash
11:36:28 <warlord> so do you have a working code example?
11:39:13 <andi5> well, i will just try to get "make check" to work :)
11:39:54 <warlord> that's fine... :)
11:40:39 <warlord> feel free to add that comment to the sorce code somewhere and then you can refer back to it where you need to make the changes..
11:41:02 <andi5> yes, i will make a big fat warning :)
11:41:10 <warlord> :)
12:07:01 *** wizkid238 has joined #gnucash
12:08:54 *** wizkid238_ has quit IRC
12:15:35 <hampton> Re: broken floating point. You really should read http://catless.ncl.ac.uk/Risks/24.53.html#subj7.3 by Spaf. Its eye-opening.
12:19:53 <andi5> ooook....
12:21:44 <warlord> Interesting...
12:22:25 <warlord> hey, hampton, any chance you could audit r15435 for me?
12:28:15 *** jpeach has joined #gnucash
12:29:03 * hampton shakes his head
12:29:11 <hampton> From the g_rename man page:
12:29:21 <hampton> Note in particular that on Win9x it is not possible to rename a file if a file with the new name already exists. Also it is not possible in general on Windows to rename an open file.
12:29:36 <andi5> yeah, welcome on windows
12:29:53 *** twunder has joined #gnucash
12:29:53 <hampton> so how does that affect r15435?
12:29:54 <warlord> Hmm...
12:30:04 <andi5> sometimes "make install" fails for me, because something is not fast enough in closing some file ;-)
12:30:13 <andi5> not at all for branches/2.0
12:30:23 <warlord> Well, for backport it doesn't matter because 2.0 isn't win32
12:30:25 <hampton> Aside from that, the patch is good.
12:30:35 <warlord> but it means we do need a better solution for trunk
12:30:54 <andi5> well, i was unable to compile libqof, so i needed a fix :-)
12:31:09 <warlord> andi5: sorry, I didn't think about it.
12:31:14 <hampton> Or a different solution for win32. What Bill provided is an elegant solution for everything else.
12:31:37 <andi5> warlord: no, it was nearly perfect.... that way you can really cherry-pick the commit for backporting
12:31:46 <warlord> Actually, I gave it to him.
12:32:21 <hampton> OK, that's en elegant patch you came up with. :-)
12:32:27 <warlord> *chuckles*
12:32:41 <warlord> His original patch just had it printing to stderr.
12:33:08 <warlord> So hampton I can backport that patch?
12:33:14 <hampton> yes
12:33:17 <warlord> thanks
12:33:43 <andi5> warlord: backport_list.empty == NULL?
12:33:53 <andi5> oh, well... you know what i mean ;-)
12:34:37 <warlord> It will be empty shortly. :)
12:35:45 <hampton> I've got a fix implmented to
12:35:48 <hampton> oops
12:36:25 *** andi5 has quit IRC
12:37:15 <hampton> I've got a fix implemented to migrate the state file from "invalid" to valid keys. Its *not* backward compatible and I really don't see how it can be. I.E. After running with this version of gnucash, you loose your state file if you go back to an older version. Is this a problem?
12:37:55 <warlord> It might be.
12:38:00 <hampton> Of course, if you've upgraded to glib 2.12.7 you've already lost your state file. :-(
12:38:19 <warlord> We might want to at least add the code to read both versions..
12:38:28 <warlord> (and be able to backport that)
12:40:19 <hampton> So users can drop back from 2.0.5 to 2.0.4? The state file was completely different in 1.8.
12:40:57 <warlord> More so that users can drop back from 2.1/2.2 to 2.0.5 if necessary.
12:41:26 <hampton> That's not a problem. The only problem is pre 2.0.5 vs 2.0.5 or later.
12:41:50 <warlord> *ponders*
12:42:23 <hampton> Oh, this is definitely something that needs to be backported to 2.0. Users have already run into glib > 2.12.7 and had problems.
12:42:25 <warlord> I'm not sure what that would mean..
12:42:46 <warlord> I guess there's not a good way to make it work with 2.0.x x<5, huh?
12:42:52 <hampton> I really only see it as a problem for devs who use more than one dev tree on the same data file.
12:43:25 *** andi5 has joined #gnucash
12:43:25 *** gncbot sets mode: +o andi5
12:43:34 <hampton> the only was would be to have gnucash continue to write state files where the key name includes spaces.
12:44:13 <hampton> The problem with that is that glib 2.12.7 won't read or store anything if the key name has a space.
12:44:41 <hampton> The reading part was relaxed from a failure to a warning in 2.12.9 (I think). Not sure about the write part.
12:44:57 <andi5> hampton: my state file was written perfectly with glib 2.12.9, so i guess the old behavior is in use again?
12:45:12 <hampton> Did you get a ton of warnings in the trace file?
12:47:20 <andi5> hm... damn, i just rebooted... but my gnucash.trace says "error reading group Window 1 key Page Count: Die Schlüsselwertedatei enthält nicht die Gruppe »Window 1«" ... hmpf
12:47:29 <hampton> I'm running 2.12.7 in my test libs and it flat out refuses to read the state file.
12:47:47 <andi5> maybe i was to eager in updating glib...
12:48:00 <hampton> you should have one of those errors for each key read.
12:49:07 <andi5> no, i only have these warnings for group names
12:49:25 <andi5> probably because it never really reads [Window 1]
12:51:19 <hampton> Section names can have spaces, just not key names
12:52:20 * andi5 compiles glib 2.12.9
12:56:35 *** MrN has joined #gnucash
12:57:03 <MrN> re
13:01:25 <hampton> I realized last night that my fc'x' libs aren't the latest and greatest. I've got gnome as of the 12/30/06 switch from cvs to svn.
13:01:38 <hampton> Figured I update once I got this patch committed.
13:02:44 <andi5> hampton: i hope i did not slow you down too much
13:02:58 <hampton> nope
13:03:15 <warlord> Well, I'm all caught up with backports.. So I'm gonna head out for a bit. TTYL.
13:03:17 *** warlord is now known as warlord-afk
13:03:29 <hampton> I needed your commit so I didn't break fc4
13:03:46 <hampton> any objection to my proposed changes before you go?
13:03:58 <hampton> warlord-afk: any objection to my proposed changes before you go?
13:06:10 <warlord-afk> I'm just... concerned.
13:06:14 *** warlord-afk is now known as warlord
13:06:42 <warlord> any chance you could do a runtime test and only do the change if you detect you're running with the broken version?
13:07:58 <warlord> I'd ask chris. He's a major "backwards compatibility" freak. ;)
13:08:01 <hampton> I could. It would mean keeping the old key names in the source and potentially modifying them on each access to the data file.
13:08:24 <hampton> np. I'll work on my rg changes this afternoon.
13:09:20 <warlord> ok
13:09:23 *** warlord is now known as warlord-afk
13:13:18 *** twunder has quit IRC
13:36:26 <chris> IMO, the standard for backward-compatibility of the state-file is _way_ lower than for the data file. I wouldn't sweat it.
13:44:11 *** twunder has joined #gnucash
13:45:03 *** jpeach has left #gnucash
14:26:01 *** warlord-afk is now known as warlord
14:36:08 <andi5> hm... i think there is a problem in engine/test/test-numeric.c, around line 660.... above there is " This test presumes that RAND_MAX is approx 2^32" ... that is definitely not the case on windows, where it is 0x7fff, i.e. 2^15 .... i do not know much about our arithmetic, but it seems that "a" and "b" are sufficiently small, that the quotient is _not_ reduced, so the test almost always fails.... you can see this on linux, if you cheat and do no
14:37:23 <andi5> maybe it even fails _always_
14:38:29 <warlord> I think all it's saying is that rand() will return a number < 2^32, which it will.
14:44:58 <andi5> say, i set na=30 --> a = {num = 16106127360, denom = 1073741824} .... b = {num = 1, denom = 331749253} .... a/b = {num = 5343195720402862080, denom = 1073741824}, whereas ne ^= 4976238795 / 1 ....
14:46:06 <andi5> well, back in 30 minutes or so
14:54:39 *** twunder has quit IRC
14:57:04 <warlord> andi5: I dont see the problem...
15:00:25 <warlord> BIAB
15:00:27 *** warlord is now known as warlord-afk
15:02:20 *** ErKa has joined #gnucash
15:06:30 <andi5> well, obviously ... gnc_numeric_equal(a/b, ne) does not hold then, as a/b is not reduced
15:08:57 *** warlord-afk is now known as warlord
15:09:10 <warlord> but why isn't it reduced?
15:09:24 <warlord> Put the same numbers in on linux and I believe it is still reduced.
15:09:48 <andi5> hm... i thought that is what GNC_HOW_DENOM_EXACT is for in gnc_numeric_div
15:10:50 *** cstim has joined #gnucash
15:10:50 *** gncbot sets mode: +o cstim
15:11:01 <andi5> hi cstim
15:11:30 <warlord> I honestly dont recall..
15:11:39 <cstim> andi5: lange nacht yesterday :-)
15:11:40 <andi5> well, apply http://pastebin.ca/raw/331351 on linux and it will fail too
15:11:44 <andi5> yep
15:12:25 <cstim> on gnucash-de someone complains "export account hierarchy" doesn't work with his gnucash-1.8.10 :-/ Anyone recalls whether it was broken at the time?
15:13:35 <warlord> INTERESTING...
15:13:55 <warlord> (to andi5)
15:14:08 <warlord> cstim: "Export Account Hierarchy", not "Export Accounts"?
15:15:01 <andi5> warlord: i guess 2^13 is a more realistic number, but it still fails some times
15:15:11 <cstim> warlord: the latter
15:15:40 <warlord> cstim: I'm fairly sure it worked fine. In 2.0, however, the file needs to exist (it wont properly create it if it doesn't exist)
15:15:59 <warlord> andi5: Shouldn't matter.. It should work properly for all inputs.
15:17:50 <warlord> Oh, I guess we ARE going..
15:17:51 <warlord> bye
15:17:53 *** warlord is now known as warlord-afk
15:18:39 <jsled> I don't believe the file needs to exist in 2.x; I just did that a few weeks ago, and don't recall needing to touch the file first, or anything.
15:19:38 <cstim> jsled: you fixed it in 1.9.2, http://bugzilla.gnome.org/show_bug.cgi?id=332802
15:20:04 <cstim> but I think the gnucash-de guy didn't understand he should enter a new filename at the file chooser dialog.
15:22:16 *** kielein has quit IRC
15:27:39 * cstim just put Maia to bed. Hope she sleeps fine this night.
15:28:57 *** benoitg has left #gnucash
15:29:02 *** andi5 has quit IRC
15:36:35 *** ErKa has quit IRC
15:36:42 <cstim> hampton: that math checking piece is really interesting
15:37:25 *** benoitg has joined #gnucash
15:44:12 *** ErKa has joined #gnucash
15:45:37 <cstim> are there any thoughts about the date of 2.0.5?
16:31:44 *** benoitg has left #gnucash
16:35:06 *** benoitg has joined #gnucash
16:36:39 <jsled> hampton: you're inserting tab characters into source files. see src/gnome/dialog-sx-editor.c@12185 and 13324, for e.g..
16:37:31 <hampton> Is that bad? I thought there were lots of tab characters in source files. Did I miss a memo?
16:38:13 <hampton> afaix emacs has always used a combination of tab and space characters to do its indentation.
16:38:48 <jsled> I think they're bad. I thought the convention was spaces, as per the style of the file, but never tabs.
16:39:32 <jsled> Well, indent-tabs-mode controls it; it will only insert one or the other.
16:39:58 <hampton> I didn't think there was a convention, and honestly it never crossed my mind to check. I'll try to remember in the future.
16:44:52 <cstim> didn't anyone of you wonder why at startup you see the "relocation disabled" message?
16:45:12 <cstim> or did you all have autoconf <= 2.59 ?
16:45:34 <hampton> indent-tabs-mode says that its ok to insert tabs. emacs will still add spaces to get to columns that aren't a multiple of 8 spaces
16:45:52 <hampton> anyway... I'll try to be more careful in the future.
16:46:57 <hampton> huh? it re-indented the whole file? (/me just saw the diffs)
16:47:50 * chris has (setq-default indent-tabs-mode nil) in .emacs
16:49:08 <hampton> I do look for and remove white-space only changes when I review diffs. I have no idea how those changes got in.
17:01:49 <hampton> I forgot to mark r15458 for backport.
17:04:36 <jsled> cstim: I do see it, since I started working on trunk again.
17:04:56 <jsled> hampton: See, my tab stop is 4, not 8. Probably the primary reason why tab characters are a bad idea.
17:05:30 <jsled> BTW, thanks for fixing the glib compatability stuff; you have FC4 in a vmware image, right? Any chance I could get a copy of that image so I could check things myself?
17:06:23 <jsled> hampton: No, it only re-indented a few sections. I just looked for any tab chars; they seemed to be introduced in at least 2 (and probably more) commits.
17:06:47 * jsled also wishes he knew why every mailing list breaks my email signatures.
17:07:12 <jsled> (especially because it didn't happen before... maybe it's Evo-2.8's fault.)
17:09:55 *** cstim has quit IRC
17:21:12 *** ErKa has quit IRC
17:23:35 *** ErKa has joined #gnucash
17:26:56 *** jpeach has joined #gnucash
17:27:09 *** jpeach has left #gnucash
18:01:57 *** Esaj has quit IRC
18:07:20 *** prock has quit IRC
18:21:43 *** warlord-afk is now known as warlord
18:32:37 *** |gunni| has quit IRC
18:55:43 *** MrN has quit IRC
18:57:00 *** benoitg has quit IRC
19:04:54 *** ErKa has quit IRC
19:10:55 *** Esaj has joined #gnucash
19:16:28 <warlord> Hmm, I wonder why test-numeric throws so many errors if you tie na to 30 on line 630?
19:17:06 <warlord> gnc_numeric_div() fails.
19:26:24 *** wizkid238_ has joined #gnucash
19:30:20 *** wizkid238 has quit IRC
19:39:36 *** Esaj has quit IRC
19:55:22 <warlord> jsled: I thought you committed code to configure.in to remove the default -O2 when we configure with --enable-debug?
20:06:11 <chris> It was just in pastebin, never committed.
20:06:56 <chris> BTW, I was assuming that <2.0.4 would simply ignore the 2.0.5 statefiles, not crash.
20:06:56 <warlord> Oh... Oh well. I guess I'll just configure with CFLAGS='-g -O0'
20:07:06 <warlord> I was assuming that, too..
20:07:09 <warlord> Crashing is BAD.
20:10:29 <hampton> chris: I thought I had tested that, but obviously not.
20:13:43 <chris> :( looks like an unchecked retuen value in gnc_find_state_file()
20:13:59 <hampton> Its a NULL being passed to strcmp.
20:14:05 *** sjc has quit IRC
20:15:06 <chris> That just absolutely sucks.
20:16:04 <hampton> what sucks more is that if I'd written safe_strcmp() instead of strcmp() this would be a non-issue
20:17:34 <warlord> *sigh*
20:23:03 <warlord> Hmm.. Interesting. in gnc_numeric_div() when both the numerator and denominator expansions are too big to code reduces both numbers first and tries again.. but if only the numerator is "too big" then it doesn't reduce it first.
20:23:16 <warlord> s/to code/the code
20:25:25 <chris> what if we kept using the old STATE_FILE_BOOK_GUID ?
20:26:05 <hampton> Can't. It has a space in the name. Glib 2.12.whatever will refuse to read it.
20:26:24 <warlord> hampton: why can't we just use our own (old) gkeyfile.[ch] code?
20:27:50 <hampton> we could. I thought we were better off migrating to the supported glib format instead of maintaining a duplicate code base ad-infinitum.
20:28:29 <chris> wait a sec...
20:28:48 <chris> people who have < 2.0.4 with broken glib can't be helped.
20:29:05 <warlord> chris: true.
20:29:12 <chris> we can only benefit people with >=2.0.5
20:29:18 <hampton> correct. people with gnucash <2.0.5 and glib >= 2.12.5 don't get state files.
20:29:23 <chris> and not harm people with <2.0.4
20:29:30 <chris> So...
20:30:10 <chris> Why not just write out the old format with a space, and also include code that specially handles that one key.
20:30:22 <chris> Obviously, it still loaded the keyfile.
20:30:41 <chris> well, maybe that doesn't follow..
20:30:59 <chris> Maybe a broken glib would've crashes earlier?
20:31:03 <hampton> glib >=2.12.5 doesn't load any key/value pairs that contain spaces, and it won't allow you to write them.
20:31:17 <chris> but it still loads the keyfile?
20:31:44 <hampton> its basically empty. almost every key gnucash uses contains a space.
20:31:52 <chris> ok, fine.
20:32:13 <chris> So, we can use a new keyname, but leave the old one, too.
20:32:53 <warlord> But new glib wont let you write that out.
20:32:55 <chris> old gnucash will still find the old key and not crash.
20:33:00 <hampton> write two keys, and only have one make it to the state file if glib > 2.12.5?
20:33:18 <hampton> That will also produce one error message per "bad" key.
20:34:39 <warlord> How about this: use our own gkeyfile implementation for 2.0.5 and 2.1/2.2..
20:34:43 <chris> do we rewrite the whole statefile every time?
20:34:55 <warlord> But slowly migrate to a spaceless key space.
20:34:59 <warlord> chris: yes.
20:35:13 <hampton> chris: yes. that's the way the GKeyFile code in glib is implemented.
20:36:18 <hampton> its only an issue for people who use the same data file with both trunk and <2.0.x
20:36:25 <hampton> 2.0.5
20:36:51 <chris> because we won't backport it?
20:37:10 <hampton> well, now. After 2.0.5 is will be an issue for anyone who drops back from 2.0.5 to 2.0.x(x<5)
20:37:33 <hampton> I requested that it be backported for 2.0.5.
20:37:57 <chris> well, we can't backport it like this.
20:38:23 <hampton> ???
20:38:34 <warlord> I really think the short-term answer is to use our own gkeyfile implementation for 2.0.x
20:39:11 <warlord> sure, we can't help the users with 2.0.x (x<5) with broken glib, but I think changing the format now is too dangerous if it's going to crash the code.
20:39:34 <chris> how bad is the "error" message from glib?
20:39:35 <warlord> 2.0.5 can even be intelligent and understand both sets of keys..
20:39:49 <hampton> It only crashes if you go back to an older version after using the newer version.
20:40:15 <warlord> hampton: true, but anyone doing testing is going to hit that.
20:41:28 <chris> and is the error on write or on read or both?
20:41:53 <chris> I guess not read, because it just won't find it.
20:42:23 <warlord> it's on both..
20:42:32 <chris> g_fatal?
20:42:32 <warlord> (it will find it the first time)
20:42:40 <warlord> No, I think just g_warning()
20:43:24 <chris> then heck, why can't we just write the "bad" key?
20:43:41 <warlord> because glib wont let us.
20:43:48 <warlord> glib wont write it out.
20:43:59 <warlord> (this is why I say we should just use our own gkeyfile impl)
20:44:27 <chris> I thought glib 2.12.7 would let us write a bad key but warn.
20:45:02 <chris> One g_warning on file close is way better than crashing on file open.
20:45:07 <warlord> I think glib is reserving the right to make it g_fatal() again.
20:45:11 <hampton> oen per key
20:45:15 <hampton> one per key
20:45:40 <hampton> warlord: that's my understanding too
20:45:48 <chris> yeah, I'm mean just for the STATE_FILE_BOOK_GUID key
20:48:03 <chris> I'd rather avoid importing g_keyfile if we can avoid it, and if we convert all keys, but still write one extra bad key, that's only read on old gnucash, and they make it fatal later, we can post-process the file to fix that one key.
20:48:04 *** twunder has joined #gnucash
20:48:17 <hampton> That appears to work.
20:48:18 <chris> But, I'm betting they won't make it fatal in 2.x
20:50:19 <warlord> who knows what they'll do. They made it fatal without any other warning once already.
20:50:33 <chris> also, new gnucash's won't warn on loading the file, right? because that bad key won't be read.
20:51:28 <warlord> chris: wrong. if it's running with a "new" glib, it'll warn because the key is there.
20:52:26 <chris> even if it's never read?
20:53:19 <warlord> it's "read" when you read the keyfile
20:53:43 <chris> that's pretty annoying. But still, two warnings are better than a crash.
20:53:44 <hampton> correct. the warning happens when the state file is parsed.
20:56:08 <hampton> so having an extra key in the state file doesn't seem to bother gnucash/trunk on glib>2.12.5. It does throw an error message.
20:56:39 <hampton> so having an extra key in the state file keeps 2.0.4 from crashing, but there aren't any pages in the main window, not even an account tree page.
20:58:14 <chris> yeah, gotta love progress.
20:58:56 <chris> The price for going back to use an old version is that you lose your toes, but.... you get to keep your head.
21:08:29 <warlord> Well, up until a week ago we had our own version of gkeyfile already...
21:10:44 <chris> and we still do on 2.0. Are you suggesting we not migrate to the spaceless keys?
21:11:00 <warlord> Yes, that's what I'm suggesting..
21:11:27 <warlord> We migrate to using the gkeyfile code already in our tree; just adjust the API to gnc_g_keyfile()
21:14:03 <chris> seems like a pretty long-term committment
21:14:18 <warlord> Nah, just through 2.0.x
21:17:29 <chris> but the statefile is tied to the book, not the gnucash version, so what happens for 2.2?
21:17:50 <hampton> well, the gkeyfile code in our tree is currently only compiled on systems that only have glib2.4.
21:18:30 <hampton> by then a 2.0.x that doesn't crash on down grade has been out long enough that it doesn't matter?
21:19:05 <hampton> All that should take is changing a strcmp() call to safe_strcmp().
21:19:14 <warlord> right, by the time 2.2 comes out, most people would have 2.0.5 and it wouldn't crash.
21:21:29 <warlord> (or something more recent than 2.0.5)
21:22:16 <chris> backport the safe_strcmp() for sure, but I'm not comfortable knowingly triggering a crasher in a stable release.
21:23:00 <warlord> I think we should backport the safe_strcmp(), and backport code that will read both with and without spaces..
21:23:46 <hampton> What's the complete plan? Rip out r15458 from trunk and replace it with different code that uses old keys an a private version of gkeyfile. Wait until 2.2 to use glib's gkeyfile and use spaceless keys then?
21:23:52 <chris> what if we just leave 2.0.x at the whims of the glib people? (see David's recent plan.)
21:24:06 <chris> s/plan/email/
21:24:43 <warlord> I'm not comfortable leaving it at the whims of the glib people unless we have a clear timeline for 2.2 before glib 2.14
21:25:07 <chris> Then, when/if it crashes, we at least can tell people to upgrade glib.
21:25:08 <hampton> but we still need a fix for glib 2.12.[5678]
21:25:57 <warlord> do any mainstream releases have those versions?
21:26:29 * hampton laughs
21:26:52 <hampton> debian always seems to have whatever version you don't want them to have
21:27:06 <warlord> Heh. But they've probably already upgraded to 2.12.9
21:27:39 <chris> debian? when did they move to glib-2?
21:28:14 <chris> oh... "unstable" whoowhoo.
21:28:19 <warlord> yeah
21:28:44 <chris> well, I guess they've learned what that word means.
21:29:04 <hampton> stable has 2.6.4, testing has 2.12.4, unstable has 2.12.6
21:29:20 <hampton> unstable wins again!
21:29:21 <warlord> unstable still hasn't upgraded?
21:29:47 <hampton> experimental has 2.12.9
21:32:26 <chris> I might change my mind if some recent "stable" distro release included 2.12.[badidea], but in general I'm okay with leaving 2.0.x with the spaces.
21:32:49 <warlord> Oh, I think we should leave the spaces.
21:33:02 <warlord> We should probably, tho, teach 2.0.x to read the no-space keys..
21:34:01 <chris> that would be nice.
21:35:32 <hampton> The 2.0 algorithm: read key as provided. If read fails, 1) split key on spaces, 2) capitalize each component, 3) join without spaces, 4) try and read new key.
21:36:13 <warlord> That works.
21:36:33 <hampton> There's still a problem for people who use trunk and then use <2.0.5 on the same data file.
21:37:26 <warlord> Well, perhaps trunk shouldn't write out the new spaceless keys, yet..
21:38:12 <hampton> Come again? That's the whole point of the change. Protecting gnucash from willful changes made by the glib developers
21:38:52 <hampton> oh, you said yet.
21:38:59 <warlord> Yes, I said "yet"
21:39:09 <warlord> We should definitely change the keys eventually..
21:39:12 <hampton> year, we could revert the change and apply it again in two weeks or so.
21:39:20 <hampton> s/year/yeah/
21:39:32 <chris> Oh, I thought that was just your accent.
21:39:42 <warlord> Or a couple weeks after 2.0.5 is released..
21:40:01 <hampton> Are you calling me a *HILLBILLY*. ARE YOU??????
21:40:08 <hampton> Well, its true, :-)
21:40:12 <warlord> :-P
21:40:37 <chris> Oh boy, now I've made him mad, good jorb!
21:40:49 <hampton> lol
21:40:58 <hampton> so when's 2.0.5?
21:41:07 <warlord> Hopefully "soon".
21:41:14 <warlord> But I haven't heard back from Chris, yet.
21:41:55 <warlord> (but waiting for the gkeyfile fixes, obviously)
21:43:39 <hampton> Ugh. All 38 calls to g_key_file_get_xxx in 2.0 will need to be changed to new gnc_key_file_get_xxx functions that know how to munge the key.
21:44:06 <warlord> 'sed' is your friend.
21:49:54 <hampton> if you can ever get the right incantation of find to go with it.
21:50:36 <hampton> The one down side to subversion? You're comparing working files to local copies of the repository. If you every rewrite the latter you're in trouble.
21:52:32 <warlord> Oh, svk doesn't have that issue.
22:07:42 <warlord> besides, just a simple 'find . -name \*.\[ch\] ...' should work.
22:10:36 *** twunder has quit IRC
22:22:25 *** jpeac1 has joined #gnucash
22:22:33 *** jpeac1 has left #gnucash
23:18:23 <hampton> Anyone want to review the diffs to make 2.0 read spaceless keys?
23:20:34 <hampton> http://pastebin.ca/331738 (although it got the coloration wrong)
23:36:59 <chris> I'll take a gander.
23:38:48 *** prock has joined #gnucash
23:50:35 <chris> any idea why the SCHEME_OPTION code loops over keys?
23:52:10 <chris> hampton: looks fine. Is there any way to detect "keynotfound" from the gerror?
23:52:58 <chris> I probably would have done the wrappers just slightly differently... mostly aesthetic...
23:53:20 <chris> result = g_key_file_get_foo(...);
23:53:33 <hampton> I thought about a template macro, but there are subtle differences
23:53:48 <chris> if (local_error == EKEYNOTFOUND) {
23:53:59 <chris> g_clear_error...
23:54:10 <chris> new_key = translate...
23:54:27 <chris> result = g_key_file_get_foo(...)
23:54:37 <chris> g_free(new_key)
23:54:43 <chris> }
23:54:59 <chris> if (local_error) g_propagate_Error....
23:55:03 <chris> return result;
23:55:43 <chris> yeah, the template macro could get pretty ugly. It could be done, but ... yuk.
23:55:56 <hampton> I figured that you've already got a parsed key file. If a key isn't there the only likely reason is that its the wrong variant of the key.
23:56:09 <hampton> I'll see what's in the actual GError
23:59:22 <hampton> G_KEY_FILE_ERROR_KEY_NOT_FOUND