2007-01-27 GnuCash IRC logs
00:22:02 *** Geot has joined #gnucash
00:31:50 *** benoitg has left #gnucash
00:54:33 <mishehu> hmmm... what became of the profit/loss report?
03:05:49 *** ipwizard has joined #gnucash
05:26:23 *** nubestway has joined #gnucash
05:26:32 <nubestway> hi
05:28:41 *** nubestway has left #gnucash
05:55:31 *** ipwizard has left #gnucash
06:41:23 *** andi5 has joined #gnucash
06:41:23 *** gncbot sets mode: +o andi5
06:49:28 *** |gunni| has joined #gnucash
06:51:25 *** |gunni| has joined #gnucash
06:53:18 *** |gunni| has quit IRC
06:53:35 *** |gunni| has joined #gnucash
06:56:17 *** rauch has left #gnucash
07:19:48 *** MrN has joined #gnucash
07:23:00 <MrN> hi
07:53:27 *** twunder has quit IRC
07:54:02 *** twunder has joined #gnucash
08:05:57 *** twunder has quit IRC
08:37:42 *** nubestway has joined #gnucash
08:43:57 *** warlord-afk is now known as warlord
08:44:04 <warlord> mishehu: It was renamed the "Income Statement"
08:44:22 <andi5> good morning, warlord
08:44:29 <warlord> good morning.
08:45:43 <andi5> there are several possible ways i can walk, but i do not know which one to choose... :(
08:47:16 <warlord> I would suggest one foot in front of the other.
08:48:05 <andi5> are you sure i cannot do it with only one?
08:48:27 <andi5> #ifdef HAVE_2_FEET
08:50:03 <warlord> :-P
08:50:19 <andi5> i wonder whether i should add lib/glib28, containing g_access, g_chmod and g_win32_locale-filename_from_utf8 (beginning with them)... i could also change libgsf/goffice change to use them (i did not see these g_access/g_chmod tests in configure.in).... but this is funny... both functions only make a difference on windows, but here we do not use the included copies anyway
08:51:21 <andi5> an alternative is to use what i did yesterday -> #ifdef G_OS_WIN32 special winapi blocks
08:51:58 <andi5> the third is to depend on glib 2.8 on windows... but this might not be easier, given that a linux glib 2.6 system will not these functions
08:51:59 <warlord> I think you should add a lib/glib28 and add those g_* functions..
08:52:17 <andi5> +have
08:52:50 <warlord> Well, I think it's safe to depend on glib2.8 on windows.
08:53:17 <andi5> yeah... what about HAVE_G_ACCESS and HAVE_G_CHMOD? shall i remove them and instead link against libgnc-glib? ... it seems like hampton can test on FC4 pretty fast
08:53:24 <warlord> But for Linux, It's pretty easy to have a gnc-glib28.h that has the proper #defines
08:54:04 <andi5> hm, right
08:54:10 <warlord> Well, g_access() and g_chmod() are both just #defines.
08:56:31 <andi5> ok, so i do not even need to link the included gsf, but only need to #include lib/glib28/gstdio.h
08:56:48 <warlord> Yep.
08:58:55 <andi5> so what should i do? ;-) ... i am still a bit confused (seems to be my main theme today)
09:01:12 <warlord> Test the glib version. If glib < 2.8 then add -I${top_srcdir}/lib/glib28 and add a gstdio.h that contains our macros. OR you could just put a gnc-gstdio.h and specifically #include #ifndef HAVE_GLIB28
09:04:06 <andi5> ok.... i still wondered whether i should add the windows code for g_chmod & friends, given that we control what glib is installed.... but it will not hurt
09:06:12 <warlord> I see no reason to add the windows code for that, because we control the win32 version.
09:09:03 *** mnoir has joined #gnucash
09:14:24 *** ErKa has joined #gnucash
09:15:20 *** mnoir has quit IRC
09:23:27 *** esodan has joined #gnucash
09:30:51 *** nubestway has quit IRC
09:31:01 <andi5> warlord: given that the included libgsf is not build on windows, i will do what you said, but not in lib/glib28 but in src/glib-compat.h.....i.e. (1) src/glib-compat.h adds #define g_xxx xxx for glib2.6 builds... (2) depend on glib2.8 on windows (that way g_win32_locale_filename_from_utf8 is available) .... i guess we can add lib/glib28 once we really need new features, like it was the case with gkeyfile...... does that sound right?
09:32:15 <warlord> andi5: sure, sounds good.
09:35:11 <andi5> oh, another Q: in doc/Makefile.am we create tip_of_the_day.list.... (1) why do we use an extra file? is there some other usage than in dialog-totd.c? ... (2) gcc -E -P -D'N_(x)=x' does not work well on mingw, it adds additional newlines between the entries, filling the totd will bogus (_("")) entries.... cannot we simply sed the whole file?
09:38:01 *** nubestway has joined #gnucash
09:42:37 *** nubestway has left #gnucash
09:42:58 <warlord> I dont know why we do it that way, except to make it easier to use CPP to, say, let us filter out the "this is a development version"..
09:43:26 <warlord> Although if we're not using that, I suspect we could try to use sed.. but that might be an issue if any of the strings have parens.
09:43:45 <warlord> Is gcc actually adding a newline? Or is it adding a \r where it just looks for a \n?
09:44:06 <andi5> no, in emacs it looks like 5 \n or so
09:45:24 <warlord> HUH!
09:45:43 <andi5> oh, and tip_of_the_day_list.in does not seem to contain \r
09:46:17 <warlord> Should it? Does it want eol-style-native?
09:46:32 <andi5> hm.... i will test that
09:49:10 <andi5> no, does not seem to make a difference
09:50:04 <andi5> warlord: what is in your tip_of_the_day.list? entries separated by two \n, just like in tip_of_the_day.list.in?
09:50:40 <warlord> Yes.
09:51:18 <warlord> Maybe we need a quick sed script: sed -e 's#\n\n*#\n\n#g'
09:51:28 <warlord> (assuming it's only \n)
09:55:24 <andi5> no, i am sorry, i got tricked by emacs ;-) ... the output file contains contains entries separated by 5* 0x0d0a, i.e. \r\n
09:56:00 <andi5> maybe dialog-totd.c just needs to be a little bit more clever
09:57:41 <warlord> Maybe...
09:58:26 <andi5> also, i am unsure whether your sed script will work, as imho sed works on one line only (if you do not use weird line/buffer switching stuff or know some cool command line switch) *misses `man'*
10:02:41 <warlord> Hmm.
10:05:26 *** esodan has left #gnucash
10:44:37 *** hampton|away is now known as hampton
10:44:58 <hampton> morning all
10:45:08 <andi5> morning hampton
10:45:16 * hampton now has a set of fc4 libraries compiled that he can link against
10:45:31 <andi5> great :)
10:46:01 <warlord> Hiya hampton
10:46:06 <warlord> hampton: cool!
10:46:15 <hampton> andi5: did you get my note from gncbot about wanting to use g_file_set_content (a glib 2.8 function)
10:46:36 <andi5> yes, do you intend to use it?
10:46:56 <hampton> iirc the reason for tip_of_the_day.list.in was for translators
10:47:55 <hampton> I was hoping to use it in my fix for glib tightening the screws on valid key names in a g_keyfile.
10:48:01 <andi5> hm... is translating struct members any harder?
10:49:06 * hampton shrugs
10:49:23 <andi5> hm... so you would like to see that function in lib/glib28? .... *grrr* ;-)
10:49:28 <hampton> iirc, it was already a standalone file. I think dialog_totd it the only use.
10:49:31 <hampton> yes
10:50:02 <andi5> i will see what i can do....it is the next on my agenda
10:50:14 <hampton> g_file_get_content is a 2.6 function. I wrote code that read g_file_get_content, work, work, g_file_set_contents.
10:50:35 <hampton> wasn't until I tried to compile it against the FC4 libs last night that I discovered there was a problem.
10:51:14 <andi5> ah... i thought you just looked at the "new symbols in 2.8" page... :)
10:51:29 <hampton> The what? ;-)
10:51:44 <andi5> http://developer.gnome.org/doc/API/2.0/glib/ix06.html
10:54:44 <prock> please help my terminology... the window where my transactions are entered is the "Ledger", correct?
10:54:56 <hampton> Oh, that. :-)
10:55:39 <andi5> you mean the register? :) there is also a "general ledger" listing all transactions
10:55:55 <prock> ok register
10:55:59 <prock> tnx
11:02:30 <andi5> hampton: do i need to add a dummy function for libgnc-glib again, or is there another solution.... to what problem, btw? cannot i just conditionally skip the whole dir and conditionally link against libgnc-glib?
11:03:39 <warlord> What dummy function do you think you need?
11:04:02 <andi5> warlord: http://svn.gnucash.org/trac/browser/gnucash/trunk/lib/glib26/dummy.c?rev=11565
11:04:27 <warlord> Let me rehrase, what glib28 APIs are you trying to implement?
11:04:47 <hampton> I had glib26 set up to always exist and be linked. It contained either a single empty function (if HAVE_GLIB26 was true) or the real functions.
11:05:46 <andi5> so should i do the same?
11:06:59 <warlord> andi5: probably
11:07:14 <hampton> I don't remember why I did it that way. I suspect its because all the logic of whether/what to include is in a single location, instead of copied through various makefiles.
11:08:38 <andi5> oh, a later Q may be whether the "untested" version numbers of glib, gdk, gtk and gnome could/should be raised.... i think they are only used to determine whether deprecated functions/widgets should be allowed, right?
11:11:54 <warlord> Untested version numbers?
11:13:35 <andi5> yes, we test for glib-2.0 >= 2.11.0, gtk+-2.0 >= 2.6, libgnome-2.0 >= 2.15.0 ... if these tests succeed, we set HAVE_UNTESTED_GLIB; HAVE_UNTESTED_GDK|GTK or HAVE_UNTESTED_GNOME, respectively
11:16:30 <warlord> Oh, yeah, I think that's all due to deprecation.
11:21:32 <prock> I wonder, should the .glade files get the svn:needs-lock property?
11:24:22 <warlord> What's that property do?
11:24:32 <prock> keeps someone from editing the file unless it's locked
11:25:12 <prock> not a big deal but if there are files that wont be merged properly then they usually should get the property
11:25:13 <warlord> And who would be editing the file?
11:26:25 <prock> well hampton just changed the .glade files and if someone else had made a lot of changes in their WC to them at the same time then there would have been a pretty serious conflict.
11:27:08 <hampton> The untested numbers are to catch removed functions. I also compiled a set of the latest gnome libs to test against (glib 2.12.7, gtk 2.10.7, libgnome 2.17.2) which should let me bump those numbers.
11:29:41 <warlord> prock: Again, who would be making changes to .glade files?
11:29:57 <hampton> Not necessarily. Depends on the actual changes. If someone had moved widgets around there would be conflicts, but if they'd just tweaked a value from true to false it shouldn't be an issue.
11:35:29 *** minDscrm has joined #gnucash
11:41:56 <prock> It's of course up to you. I have no write-access so the property doesn't save me any time. It's just that as a build master I've learnt to set the property on generated code and binary files.
11:52:34 <andi5> hampton: so you can basically confirm that glib 2.12.7 behaves like 2.12...., say .4, with respect to gkeyfile key names?
11:54:32 <hampton> I could if it did, but it doesn't. :-( It ignores any keys that contain spaces in the name.
11:55:25 <andi5> ok... i wanted to update install.sh to use glib 2.12.9, but i will carefully test then
11:56:39 <hampton> I have a pending fix to gnucash that updates the state file and only uses keys without spaces in them. That's the fix that needs g_file_set_contents
11:57:29 <hampton> It needs a little more testing to make sure I've covered all the bases.
11:57:35 <andi5> oh, ... i am sorry, i got interrupted
12:02:11 *** benoitg has joined #gnucash
12:05:39 *** ErKa has quit IRC
12:10:30 *** jpeach has joined #gnucash
12:10:35 *** jpeach has left #gnucash
12:16:38 <andi5> hampton: i see that you added the complete gutils.[ch] set as gutils26.[ch].... is that preferable to creating gstdio28.[ch] containing only the differences between glib26 and glib28 and #includ'ing both, gstdio.h and gstdio28.h? (this is similar to glib-compat.h then) ....
12:17:45 <mishehu> warlord: I had a feeling that the profit/loss became the income statement.
12:17:51 <mishehu> but wasn't sure. heh.
12:17:56 <warlord> :)
12:19:02 <hampton> If you can get away with only the differences between 2.6 and 2.8 that's a better solution.
12:19:29 <andi5> great
12:22:38 *** _gunni_ has joined #gnucash
12:31:13 *** |gunni| has quit IRC
12:39:03 *** benoitg has left #gnucash
12:49:19 *** ErKa has joined #gnucash
13:03:56 <warlord> andi5: Are you sure that bug #396668 is (was) trunk-only?
13:06:28 <andi5> yes, i think it stems from the remove-deprecated(?) merge
13:06:44 *** benoitg has joined #gnucash
13:06:49 <warlord> Okay.
13:07:20 <warlord> I'm going through the changes for backporting..
13:08:03 <andi5> i think the GtkComboBox (using the _text* API) has been a GtkCombo before, so the bug was new
13:09:17 <warlord> Okay
13:09:54 <warlord> Thanks.
13:10:36 <andi5> np :)
13:16:41 *** warlord2 has joined #gnucash
13:16:41 *** gncbot sets mode: +o warlord2
13:22:09 *** warlord has quit IRC
13:22:28 *** warlord2 is now known as warlord
13:22:29 <warlord> @op
13:22:29 *** gncbot sets mode: +o warlord
13:48:49 *** andi5 has quit IRC
13:52:29 <warlord> BIAB.
13:52:41 *** warlord has quit IRC
14:28:12 *** benoitg has left #gnucash
14:32:20 *** benoitg has joined #gnucash
14:39:05 *** warlord has joined #gnucash
14:39:06 *** gncbot sets mode: +o warlord
14:50:22 *** xai has joined #gnucash
14:51:12 <xai> I have this account that has several partial payments, but when I pay off the entire amount, not all the invoices get marked as paid.
14:51:27 <xai> I've aborted the save to try to do it another way, but I'm at a loss.
14:53:10 <warlord> xai: delete your partial payments, delete all the "Automatic Payment Forward" transactions, and then re-post the payments.
14:55:23 <xai> Automatic payment forwards transastion?
14:55:33 <xai> Is that a pre-payment?
14:56:18 <xai> Does it matter how I associate the payments to the particual invoices?
14:56:21 <warlord> Go look in your A/R account register
14:56:45 <warlord> What do you mean? Gnucash will always attach them FIFO
14:58:11 <xai> ok. I did have one before that with an extra payment that may have confused it.
14:58:29 <xai> at that point, it was actually ahead by $50 in payments.
14:59:03 <warlord> Something like that could theoretically confuse it. There's certainly a bug in the algorithm but I still haven't figured out how to trigger it.
14:59:52 <xai> Should I go back to that first "overpayment" and start from there?
15:01:07 <warlord> PRobably...
15:01:08 *** ceplma_ has joined #gnucash
15:01:45 <xai> Should I delete those from that A/R register (looks like the only way)..
15:04:40 <warlord> Yes, so long as you delete ALL the associated payments.
15:25:32 <xai> warlord: thank you. That works perfectly..
15:35:13 *** ErKa has quit IRC
15:39:56 *** wizkid238 has quit IRC
15:47:09 <warlord> xai: good to hear
16:00:00 *** ceplma_ has quit IRC
16:02:05 *** Demitar_ has joined #gnucash
16:02:06 *** Demitar has quit IRC
16:04:25 *** Demitar_ is now known as Demitar
16:05:28 *** Demitar_ has joined #gnucash
16:09:18 *** Demitar has quit IRC
16:11:43 *** conrad has joined #gnucash
16:11:44 *** gncbot sets mode: +o conrad
16:23:40 *** benoitg has left #gnucash
16:28:06 *** rt_ has joined #gnucash
16:39:00 <rt_> I just installed gnucash 2.0.4 and I'm trying to load my account file from version 1.8.9. However, I get a "parse error" while doing the utf8 conversion :-( The file loads fine in 1.8.9. Anyway to get past that error ?
16:42:59 *** benoitg has joined #gnucash
16:44:40 <warlord> what kind of "parse error"?
16:46:43 *** prock_ has joined #gnucash
16:55:45 *** prock has quit IRC
17:02:19 *** ceplma_ has joined #gnucash
17:10:03 *** ceplma_ has quit IRC
17:48:14 *** warlord has quit IRC
18:01:19 <rt_> It doesn't say. It's in the import druid after I've provided the correct encoding for a number of items. I get a dialog box which says "There was an error parsing the file", and then the only option is to click on "close".
18:19:00 <rt_> Problem solved: For some (inexplicable) reason my file contained two items dated back to 1901. Changing these to 2001 fixed the problem.
18:21:03 *** rt_ has quit IRC
18:40:42 *** benoitg has left #gnucash
19:18:55 *** warlord has joined #gnucash
19:18:55 *** gncbot sets mode: +o warlord
19:41:59 *** conrad has quit IRC
19:46:07 *** andi5 has joined #gnucash
19:46:08 *** gncbot sets mode: +o andi5
20:29:59 *** _gunni_ has quit IRC
20:32:59 *** wizkid238 has joined #gnucash
20:49:43 *** jharold has joined #gnucash
20:55:06 *** jharold has left #gnucash
21:45:02 *** wizkid238 has quit IRC
21:48:22 *** MisterN has joined #gnucash
21:57:51 *** MrN has quit IRC
22:01:38 *** twunder has joined #gnucash
22:16:48 *** twunder has quit IRC
22:16:55 *** wizkid238 has joined #gnucash
22:37:31 *** MisterN has quit IRC
22:43:40 *** wizkid238_ has joined #gnucash
22:47:46 *** wizkid238 has quit IRC
22:58:58 <warlord> Backport.. backport.. over the code I go...
23:00:41 <andi5> go warlord, go
23:02:55 <warlord> Heh.
23:02:56 <andi5> warlord: i am going to add files like "gwin32-2.8.[ch]"... is that ok or do they look too ugly? ;-)
23:03:18 <andi5> i thought 3228 might be a bit too confusing ;-)
23:03:25 <warlord> I still need some audits of r15347, r15414, and r15435
23:04:12 <warlord> how about gwin32-glib28.[ch] -- or glib28-win32.[ch]?
23:05:07 <andi5> hm.... do you think those look significantly better?
23:05:17 <andi5> well, maybe the first pair
23:05:27 <warlord> i like the last one, personally.
23:05:31 <andi5> lol
23:08:00 <andi5> ok... so i think my current change should work more or less... do you think the names are ok as is, or do i need to fix that again? ;-) ... (guess what happened: gfileutils28 OK gstdio28 OK gwin32...EEK)
23:11:39 <warlord> :)
23:13:17 <andi5> btw, i cannot audit 14347, ... 15414 looks good, does it fix the issue for you? .... 15435 is security related, i am not very good there
23:15:01 <warlord> Yeah, I know you can't audit 14347.. I just dont know the code well enough so i dont know what effects that might have.
23:15:23 <warlord> Yes, 15414 fixes the problem for the user.
23:15:38 <andi5> good enough for me then
23:15:44 <warlord> Okay.
23:17:39 <warlord> Thanks.
23:17:45 <warlord> Now only two outstanding AUDITs
23:18:34 *** Crazyhorse has joined #gnucash
23:22:14 *** Crazyhorse has left #gnucash
23:31:58 <hampton> the glib28 support is no longer specifically for windows, so you can just call it glib28.
23:32:34 <andi5> hampton: i am talking about gwin32.c ... it contains g_win32_locale_filename_from_utf8 :)
23:32:46 <hampton> ah
23:35:22 <andi5> oh nice... gfileutils-2.8.c introduces a new string,.... what shall i do about that one?
23:36:00 <andi5> add a hint for the translator to check the translation within gtk+ and use that?
23:36:14 <warlord> what string?
23:36:25 <andi5> _("Existing file '%s' could not be removed: g_unlink() failed: %s"),
23:37:34 <warlord> Eh? As opposed to just returning errno?
23:37:54 <warlord> What does it do with that string?
23:38:00 <andi5> yeah, g_file_set_contents also fills a GError
23:38:26 <hampton> puts the string into a GError
23:41:07 <andi5> hampton: do you plan to show that error? ... i could also remove _()
23:47:09 <andi5> warlord: http://lists.gnucash.org/pipermail/gnucash-devel/2007-January/019615.html .... when i entered the rev number, i only took a quick glimpse did not think about _what_ change this was :)
23:47:28 <hampton> If g_file_set_contents errors then I print the error with a DEBUG().
23:48:31 <warlord> andi5: okay, I can remove it from my queue.
23:48:41 <andi5> ok, thanks
23:51:51 <andi5> you are too fast...
23:52:19 <warlord> heh
23:54:01 <andi5> in a nutshell, i will remove the mark for translation... shout now or live with it
23:54:27 <hampton> fine with me
23:54:45 <warlord> fine w/ me
23:55:17 <hampton> andi5: umm, isn't it 6am for you?
23:55:28 <andi5> no, 5:55
23:55:47 <hampton> up kinda late
23:56:20 <andi5> i am not yet done
00:22:02 *** Geot has joined #gnucash
00:31:50 *** benoitg has left #gnucash
00:54:33 <mishehu> hmmm... what became of the profit/loss report?
03:05:49 *** ipwizard has joined #gnucash
05:26:23 *** nubestway has joined #gnucash
05:26:32 <nubestway> hi
05:28:41 *** nubestway has left #gnucash
05:55:31 *** ipwizard has left #gnucash
06:41:23 *** andi5 has joined #gnucash
06:41:23 *** gncbot sets mode: +o andi5
06:49:28 *** |gunni| has joined #gnucash
06:51:25 *** |gunni| has joined #gnucash
06:53:18 *** |gunni| has quit IRC
06:53:35 *** |gunni| has joined #gnucash
06:56:17 *** rauch has left #gnucash
07:19:48 *** MrN has joined #gnucash
07:23:00 <MrN> hi
07:53:27 *** twunder has quit IRC
07:54:02 *** twunder has joined #gnucash
08:05:57 *** twunder has quit IRC
08:37:42 *** nubestway has joined #gnucash
08:43:57 *** warlord-afk is now known as warlord
08:44:04 <warlord> mishehu: It was renamed the "Income Statement"
08:44:22 <andi5> good morning, warlord
08:44:29 <warlord> good morning.
08:45:43 <andi5> there are several possible ways i can walk, but i do not know which one to choose... :(
08:47:16 <warlord> I would suggest one foot in front of the other.
08:48:05 <andi5> are you sure i cannot do it with only one?
08:48:27 <andi5> #ifdef HAVE_2_FEET
08:50:03 <warlord> :-P
08:50:19 <andi5> i wonder whether i should add lib/glib28, containing g_access, g_chmod and g_win32_locale-filename_from_utf8 (beginning with them)... i could also change libgsf/goffice change to use them (i did not see these g_access/g_chmod tests in configure.in).... but this is funny... both functions only make a difference on windows, but here we do not use the included copies anyway
08:51:21 <andi5> an alternative is to use what i did yesterday -> #ifdef G_OS_WIN32 special winapi blocks
08:51:58 <andi5> the third is to depend on glib 2.8 on windows... but this might not be easier, given that a linux glib 2.6 system will not these functions
08:51:59 <warlord> I think you should add a lib/glib28 and add those g_* functions..
08:52:17 <andi5> +have
08:52:50 <warlord> Well, I think it's safe to depend on glib2.8 on windows.
08:53:17 <andi5> yeah... what about HAVE_G_ACCESS and HAVE_G_CHMOD? shall i remove them and instead link against libgnc-glib? ... it seems like hampton can test on FC4 pretty fast
08:53:24 <warlord> But for Linux, It's pretty easy to have a gnc-glib28.h that has the proper #defines
08:54:04 <andi5> hm, right
08:54:10 <warlord> Well, g_access() and g_chmod() are both just #defines.
08:56:31 <andi5> ok, so i do not even need to link the included gsf, but only need to #include lib/glib28/gstdio.h
08:56:48 <warlord> Yep.
08:58:55 <andi5> so what should i do? ;-) ... i am still a bit confused (seems to be my main theme today)
09:01:12 <warlord> Test the glib version. If glib < 2.8 then add -I${top_srcdir}/lib/glib28 and add a gstdio.h that contains our macros. OR you could just put a gnc-gstdio.h and specifically #include #ifndef HAVE_GLIB28
09:04:06 <andi5> ok.... i still wondered whether i should add the windows code for g_chmod & friends, given that we control what glib is installed.... but it will not hurt
09:06:12 <warlord> I see no reason to add the windows code for that, because we control the win32 version.
09:09:03 *** mnoir has joined #gnucash
09:14:24 *** ErKa has joined #gnucash
09:15:20 *** mnoir has quit IRC
09:23:27 *** esodan has joined #gnucash
09:30:51 *** nubestway has quit IRC
09:31:01 <andi5> warlord: given that the included libgsf is not build on windows, i will do what you said, but not in lib/glib28 but in src/glib-compat.h.....i.e. (1) src/glib-compat.h adds #define g_xxx xxx for glib2.6 builds... (2) depend on glib2.8 on windows (that way g_win32_locale_filename_from_utf8 is available) .... i guess we can add lib/glib28 once we really need new features, like it was the case with gkeyfile...... does that sound right?
09:32:15 <warlord> andi5: sure, sounds good.
09:35:11 <andi5> oh, another Q: in doc/Makefile.am we create tip_of_the_day.list.... (1) why do we use an extra file? is there some other usage than in dialog-totd.c? ... (2) gcc -E -P -D'N_(x)=x' does not work well on mingw, it adds additional newlines between the entries, filling the totd will bogus (_("")) entries.... cannot we simply sed the whole file?
09:38:01 *** nubestway has joined #gnucash
09:42:37 *** nubestway has left #gnucash
09:42:58 <warlord> I dont know why we do it that way, except to make it easier to use CPP to, say, let us filter out the "this is a development version"..
09:43:26 <warlord> Although if we're not using that, I suspect we could try to use sed.. but that might be an issue if any of the strings have parens.
09:43:45 <warlord> Is gcc actually adding a newline? Or is it adding a \r where it just looks for a \n?
09:44:06 <andi5> no, in emacs it looks like 5 \n or so
09:45:24 <warlord> HUH!
09:45:43 <andi5> oh, and tip_of_the_day_list.in does not seem to contain \r
09:46:17 <warlord> Should it? Does it want eol-style-native?
09:46:32 <andi5> hm.... i will test that
09:49:10 <andi5> no, does not seem to make a difference
09:50:04 <andi5> warlord: what is in your tip_of_the_day.list? entries separated by two \n, just like in tip_of_the_day.list.in?
09:50:40 <warlord> Yes.
09:51:18 <warlord> Maybe we need a quick sed script: sed -e 's#\n\n*#\n\n#g'
09:51:28 <warlord> (assuming it's only \n)
09:55:24 <andi5> no, i am sorry, i got tricked by emacs ;-) ... the output file contains contains entries separated by 5* 0x0d0a, i.e. \r\n
09:56:00 <andi5> maybe dialog-totd.c just needs to be a little bit more clever
09:57:41 <warlord> Maybe...
09:58:26 <andi5> also, i am unsure whether your sed script will work, as imho sed works on one line only (if you do not use weird line/buffer switching stuff or know some cool command line switch) *misses `man'*
10:02:41 <warlord> Hmm.
10:05:26 *** esodan has left #gnucash
10:44:37 *** hampton|away is now known as hampton
10:44:58 <hampton> morning all
10:45:08 <andi5> morning hampton
10:45:16 * hampton now has a set of fc4 libraries compiled that he can link against
10:45:31 <andi5> great :)
10:46:01 <warlord> Hiya hampton
10:46:06 <warlord> hampton: cool!
10:46:15 <hampton> andi5: did you get my note from gncbot about wanting to use g_file_set_content (a glib 2.8 function)
10:46:36 <andi5> yes, do you intend to use it?
10:46:56 <hampton> iirc the reason for tip_of_the_day.list.in was for translators
10:47:55 <hampton> I was hoping to use it in my fix for glib tightening the screws on valid key names in a g_keyfile.
10:48:01 <andi5> hm... is translating struct members any harder?
10:49:06 * hampton shrugs
10:49:23 <andi5> hm... so you would like to see that function in lib/glib28? .... *grrr* ;-)
10:49:28 <hampton> iirc, it was already a standalone file. I think dialog_totd it the only use.
10:49:31 <hampton> yes
10:50:02 <andi5> i will see what i can do....it is the next on my agenda
10:50:14 <hampton> g_file_get_content is a 2.6 function. I wrote code that read g_file_get_content, work, work, g_file_set_contents.
10:50:35 <hampton> wasn't until I tried to compile it against the FC4 libs last night that I discovered there was a problem.
10:51:14 <andi5> ah... i thought you just looked at the "new symbols in 2.8" page... :)
10:51:29 <hampton> The what? ;-)
10:51:44 <andi5> http://developer.gnome.org/doc/API/2.0/glib/ix06.html
10:54:44 <prock> please help my terminology... the window where my transactions are entered is the "Ledger", correct?
10:54:56 <hampton> Oh, that. :-)
10:55:39 <andi5> you mean the register? :) there is also a "general ledger" listing all transactions
10:55:55 <prock> ok register
10:55:59 <prock> tnx
11:02:30 <andi5> hampton: do i need to add a dummy function for libgnc-glib again, or is there another solution.... to what problem, btw? cannot i just conditionally skip the whole dir and conditionally link against libgnc-glib?
11:03:39 <warlord> What dummy function do you think you need?
11:04:02 <andi5> warlord: http://svn.gnucash.org/trac/browser/gnucash/trunk/lib/glib26/dummy.c?rev=11565
11:04:27 <warlord> Let me rehrase, what glib28 APIs are you trying to implement?
11:04:47 <hampton> I had glib26 set up to always exist and be linked. It contained either a single empty function (if HAVE_GLIB26 was true) or the real functions.
11:05:46 <andi5> so should i do the same?
11:06:59 <warlord> andi5: probably
11:07:14 <hampton> I don't remember why I did it that way. I suspect its because all the logic of whether/what to include is in a single location, instead of copied through various makefiles.
11:08:38 <andi5> oh, a later Q may be whether the "untested" version numbers of glib, gdk, gtk and gnome could/should be raised.... i think they are only used to determine whether deprecated functions/widgets should be allowed, right?
11:11:54 <warlord> Untested version numbers?
11:13:35 <andi5> yes, we test for glib-2.0 >= 2.11.0, gtk+-2.0 >= 2.6, libgnome-2.0 >= 2.15.0 ... if these tests succeed, we set HAVE_UNTESTED_GLIB; HAVE_UNTESTED_GDK|GTK or HAVE_UNTESTED_GNOME, respectively
11:16:30 <warlord> Oh, yeah, I think that's all due to deprecation.
11:21:32 <prock> I wonder, should the .glade files get the svn:needs-lock property?
11:24:22 <warlord> What's that property do?
11:24:32 <prock> keeps someone from editing the file unless it's locked
11:25:12 <prock> not a big deal but if there are files that wont be merged properly then they usually should get the property
11:25:13 <warlord> And who would be editing the file?
11:26:25 <prock> well hampton just changed the .glade files and if someone else had made a lot of changes in their WC to them at the same time then there would have been a pretty serious conflict.
11:27:08 <hampton> The untested numbers are to catch removed functions. I also compiled a set of the latest gnome libs to test against (glib 2.12.7, gtk 2.10.7, libgnome 2.17.2) which should let me bump those numbers.
11:29:41 <warlord> prock: Again, who would be making changes to .glade files?
11:29:57 <hampton> Not necessarily. Depends on the actual changes. If someone had moved widgets around there would be conflicts, but if they'd just tweaked a value from true to false it shouldn't be an issue.
11:35:29 *** minDscrm has joined #gnucash
11:41:56 <prock> It's of course up to you. I have no write-access so the property doesn't save me any time. It's just that as a build master I've learnt to set the property on generated code and binary files.
11:52:34 <andi5> hampton: so you can basically confirm that glib 2.12.7 behaves like 2.12...., say .4, with respect to gkeyfile key names?
11:54:32 <hampton> I could if it did, but it doesn't. :-( It ignores any keys that contain spaces in the name.
11:55:25 <andi5> ok... i wanted to update install.sh to use glib 2.12.9, but i will carefully test then
11:56:39 <hampton> I have a pending fix to gnucash that updates the state file and only uses keys without spaces in them. That's the fix that needs g_file_set_contents
11:57:29 <hampton> It needs a little more testing to make sure I've covered all the bases.
11:57:35 <andi5> oh, ... i am sorry, i got interrupted
12:02:11 *** benoitg has joined #gnucash
12:05:39 *** ErKa has quit IRC
12:10:30 *** jpeach has joined #gnucash
12:10:35 *** jpeach has left #gnucash
12:16:38 <andi5> hampton: i see that you added the complete gutils.[ch] set as gutils26.[ch].... is that preferable to creating gstdio28.[ch] containing only the differences between glib26 and glib28 and #includ'ing both, gstdio.h and gstdio28.h? (this is similar to glib-compat.h then) ....
12:17:45 <mishehu> warlord: I had a feeling that the profit/loss became the income statement.
12:17:51 <mishehu> but wasn't sure. heh.
12:17:56 <warlord> :)
12:19:02 <hampton> If you can get away with only the differences between 2.6 and 2.8 that's a better solution.
12:19:29 <andi5> great
12:22:38 *** _gunni_ has joined #gnucash
12:31:13 *** |gunni| has quit IRC
12:39:03 *** benoitg has left #gnucash
12:49:19 *** ErKa has joined #gnucash
13:03:56 <warlord> andi5: Are you sure that bug #396668 is (was) trunk-only?
13:06:28 <andi5> yes, i think it stems from the remove-deprecated(?) merge
13:06:44 *** benoitg has joined #gnucash
13:06:49 <warlord> Okay.
13:07:20 <warlord> I'm going through the changes for backporting..
13:08:03 <andi5> i think the GtkComboBox (using the _text* API) has been a GtkCombo before, so the bug was new
13:09:17 <warlord> Okay
13:09:54 <warlord> Thanks.
13:10:36 <andi5> np :)
13:16:41 *** warlord2 has joined #gnucash
13:16:41 *** gncbot sets mode: +o warlord2
13:22:09 *** warlord has quit IRC
13:22:28 *** warlord2 is now known as warlord
13:22:29 <warlord> @op
13:22:29 *** gncbot sets mode: +o warlord
13:48:49 *** andi5 has quit IRC
13:52:29 <warlord> BIAB.
13:52:41 *** warlord has quit IRC
14:28:12 *** benoitg has left #gnucash
14:32:20 *** benoitg has joined #gnucash
14:39:05 *** warlord has joined #gnucash
14:39:06 *** gncbot sets mode: +o warlord
14:50:22 *** xai has joined #gnucash
14:51:12 <xai> I have this account that has several partial payments, but when I pay off the entire amount, not all the invoices get marked as paid.
14:51:27 <xai> I've aborted the save to try to do it another way, but I'm at a loss.
14:53:10 <warlord> xai: delete your partial payments, delete all the "Automatic Payment Forward" transactions, and then re-post the payments.
14:55:23 <xai> Automatic payment forwards transastion?
14:55:33 <xai> Is that a pre-payment?
14:56:18 <xai> Does it matter how I associate the payments to the particual invoices?
14:56:21 <warlord> Go look in your A/R account register
14:56:45 <warlord> What do you mean? Gnucash will always attach them FIFO
14:58:11 <xai> ok. I did have one before that with an extra payment that may have confused it.
14:58:29 <xai> at that point, it was actually ahead by $50 in payments.
14:59:03 <warlord> Something like that could theoretically confuse it. There's certainly a bug in the algorithm but I still haven't figured out how to trigger it.
14:59:52 <xai> Should I go back to that first "overpayment" and start from there?
15:01:07 <warlord> PRobably...
15:01:08 *** ceplma_ has joined #gnucash
15:01:45 <xai> Should I delete those from that A/R register (looks like the only way)..
15:04:40 <warlord> Yes, so long as you delete ALL the associated payments.
15:25:32 <xai> warlord: thank you. That works perfectly..
15:35:13 *** ErKa has quit IRC
15:39:56 *** wizkid238 has quit IRC
15:47:09 <warlord> xai: good to hear
16:00:00 *** ceplma_ has quit IRC
16:02:05 *** Demitar_ has joined #gnucash
16:02:06 *** Demitar has quit IRC
16:04:25 *** Demitar_ is now known as Demitar
16:05:28 *** Demitar_ has joined #gnucash
16:09:18 *** Demitar has quit IRC
16:11:43 *** conrad has joined #gnucash
16:11:44 *** gncbot sets mode: +o conrad
16:23:40 *** benoitg has left #gnucash
16:28:06 *** rt_ has joined #gnucash
16:39:00 <rt_> I just installed gnucash 2.0.4 and I'm trying to load my account file from version 1.8.9. However, I get a "parse error" while doing the utf8 conversion :-( The file loads fine in 1.8.9. Anyway to get past that error ?
16:42:59 *** benoitg has joined #gnucash
16:44:40 <warlord> what kind of "parse error"?
16:46:43 *** prock_ has joined #gnucash
16:55:45 *** prock has quit IRC
17:02:19 *** ceplma_ has joined #gnucash
17:10:03 *** ceplma_ has quit IRC
17:48:14 *** warlord has quit IRC
18:01:19 <rt_> It doesn't say. It's in the import druid after I've provided the correct encoding for a number of items. I get a dialog box which says "There was an error parsing the file", and then the only option is to click on "close".
18:19:00 <rt_> Problem solved: For some (inexplicable) reason my file contained two items dated back to 1901. Changing these to 2001 fixed the problem.
18:21:03 *** rt_ has quit IRC
18:40:42 *** benoitg has left #gnucash
19:18:55 *** warlord has joined #gnucash
19:18:55 *** gncbot sets mode: +o warlord
19:41:59 *** conrad has quit IRC
19:46:07 *** andi5 has joined #gnucash
19:46:08 *** gncbot sets mode: +o andi5
20:29:59 *** _gunni_ has quit IRC
20:32:59 *** wizkid238 has joined #gnucash
20:49:43 *** jharold has joined #gnucash
20:55:06 *** jharold has left #gnucash
21:45:02 *** wizkid238 has quit IRC
21:48:22 *** MisterN has joined #gnucash
21:57:51 *** MrN has quit IRC
22:01:38 *** twunder has joined #gnucash
22:16:48 *** twunder has quit IRC
22:16:55 *** wizkid238 has joined #gnucash
22:37:31 *** MisterN has quit IRC
22:43:40 *** wizkid238_ has joined #gnucash
22:47:46 *** wizkid238 has quit IRC
22:58:58 <warlord> Backport.. backport.. over the code I go...
23:00:41 <andi5> go warlord, go
23:02:55 <warlord> Heh.
23:02:56 <andi5> warlord: i am going to add files like "gwin32-2.8.[ch]"... is that ok or do they look too ugly? ;-)
23:03:18 <andi5> i thought 3228 might be a bit too confusing ;-)
23:03:25 <warlord> I still need some audits of r15347, r15414, and r15435
23:04:12 <warlord> how about gwin32-glib28.[ch] -- or glib28-win32.[ch]?
23:05:07 <andi5> hm.... do you think those look significantly better?
23:05:17 <andi5> well, maybe the first pair
23:05:27 <warlord> i like the last one, personally.
23:05:31 <andi5> lol
23:08:00 <andi5> ok... so i think my current change should work more or less... do you think the names are ok as is, or do i need to fix that again? ;-) ... (guess what happened: gfileutils28 OK gstdio28 OK gwin32...EEK)
23:11:39 <warlord> :)
23:13:17 <andi5> btw, i cannot audit 14347, ... 15414 looks good, does it fix the issue for you? .... 15435 is security related, i am not very good there
23:15:01 <warlord> Yeah, I know you can't audit 14347.. I just dont know the code well enough so i dont know what effects that might have.
23:15:23 <warlord> Yes, 15414 fixes the problem for the user.
23:15:38 <andi5> good enough for me then
23:15:44 <warlord> Okay.
23:17:39 <warlord> Thanks.
23:17:45 <warlord> Now only two outstanding AUDITs
23:18:34 *** Crazyhorse has joined #gnucash
23:22:14 *** Crazyhorse has left #gnucash
23:31:58 <hampton> the glib28 support is no longer specifically for windows, so you can just call it glib28.
23:32:34 <andi5> hampton: i am talking about gwin32.c ... it contains g_win32_locale_filename_from_utf8 :)
23:32:46 <hampton> ah
23:35:22 <andi5> oh nice... gfileutils-2.8.c introduces a new string,.... what shall i do about that one?
23:36:00 <andi5> add a hint for the translator to check the translation within gtk+ and use that?
23:36:14 <warlord> what string?
23:36:25 <andi5> _("Existing file '%s' could not be removed: g_unlink() failed: %s"),
23:37:34 <warlord> Eh? As opposed to just returning errno?
23:37:54 <warlord> What does it do with that string?
23:38:00 <andi5> yeah, g_file_set_contents also fills a GError
23:38:26 <hampton> puts the string into a GError
23:41:07 <andi5> hampton: do you plan to show that error? ... i could also remove _()
23:47:09 <andi5> warlord: http://lists.gnucash.org/pipermail/gnucash-devel/2007-January/019615.html .... when i entered the rev number, i only took a quick glimpse did not think about _what_ change this was :)
23:47:28 <hampton> If g_file_set_contents errors then I print the error with a DEBUG().
23:48:31 <warlord> andi5: okay, I can remove it from my queue.
23:48:41 <andi5> ok, thanks
23:51:51 <andi5> you are too fast...
23:52:19 <warlord> heh
23:54:01 <andi5> in a nutshell, i will remove the mark for translation... shout now or live with it
23:54:27 <hampton> fine with me
23:54:45 <warlord> fine w/ me
23:55:17 <hampton> andi5: umm, isn't it 6am for you?
23:55:28 <andi5> no, 5:55
23:55:47 <hampton> up kinda late
23:56:20 <andi5> i am not yet done