2007-01-20 GnuCash IRC logs
00:14:35 *** warlord is now known as warlord-afk
01:10:27 *** BurnOut has quit IRC
02:50:44 *** motin has joined #gnucash
04:41:26 *** errre has joined #gnucash
04:42:36 *** ErKa has joined #gnucash
04:43:44 *** errre has left #gnucash
05:42:42 *** nomeata has joined #gnucash
07:05:29 *** BC-bd has joined #gnucash
07:25:11 *** andi5 has joined #gnucash
07:25:12 *** gncbot sets mode: +o andi5
07:36:53 <prock> jsled: thanks =)
07:48:27 *** nomeata has quit IRC
08:01:15 *** twunder has joined #gnucash
08:11:37 *** MrN has joined #gnucash
08:14:05 <MrN> hi
08:27:35 *** |gunni| has joined #gnucash
08:55:36 *** mnoir has joined #gnucash
09:10:16 *** twunder has quit IRC
10:26:12 <jsled> andi5: sorry, I probably should have waited for your version upgrade. I hope my commit didn't slow you down too much. But it compiled, &c., for you?
10:27:00 <andi5> yes
10:27:24 <andi5> i only needed to remove 3 lines in your new plugin page (gkeyfile.h) that was all
10:28:15 <andi5> make check slowed me down... (it still does not work in po/ for me)
10:28:40 <jsled> did you see any other failures? I added some new SX-related tests...
10:29:02 <andi5> were should i look?
10:29:05 <andi5> +h
10:29:21 <jsled> engine. app-utils gnome-utils
10:30:05 <andi5> jsled: i only saw these g_date_somewhat warnings, but i guess you know them
10:30:31 <jsled> yeah. That's not me. Some other guy, some other job.
10:30:46 <jsled> :)
10:30:47 <andi5> is it that hard to fix?
10:32:39 <jsled> I'm not sure, yet. http://bugzilla.gnome.org/show_bug.cgi?id=394420
10:37:05 <andi5> test-sx passed (warnings, see above), test-freq-spec and test-recurrence looks as if unchanged, test-sx in app-utils: 74 tests passed quietly
10:38:16 <jsled> Good good.
10:38:42 <jsled> That (app-utils) is the key one, though just a skeleton at this point.
10:39:27 <andi5> i see... please do not take it personally, but i probably will not take a closer look soon :-)
10:39:46 <jsled> no no, that's alright. Thanks very much. :)
10:42:56 <andi5> jsled: so current trunk builds for you?
10:43:04 <jsled> yes, just finished.
10:43:05 *** warlord-afk is now known as warlord
10:43:20 <andi5> good :)
10:43:36 * warlord is checking trunk
10:43:46 <warlord> (I'll try on Mac soon)
10:44:55 * andi5 will test on windows tomorrow
10:45:18 <jsled> Hmm. How to get `--enable-debug` to remove (or not add) `-O2` to CFLAGS?
10:45:29 <warlord> jsled: very hard.
10:45:56 <andi5> -O0
10:46:07 <warlord> You need to reset CPPFLAGS/CFLAGS/CXXFLAGS just after AC_PROG_GCC
10:46:33 <jsled> AC_PROG_CC ?
10:47:39 <warlord> jsled: FYI, we might need the old gkey* implementation to workaround the glib "no spaces in keys" issue.
10:48:00 <jsled> it looks like they've backed off.
10:48:03 <warlord> Sorry, yeah, AC_PROG_CC
10:48:14 <jsled> trunk now only warns on "conditions that would make the file unreadable", I believe.
10:48:16 <warlord> Have they backed off completely?
10:50:41 <jsled> "completely" I don't know. <http://bugs.gentoo.org/show_bug.cgi?id=158673#c4>
10:50:55 <warlord> it sounds like they still intend to make this change...
10:53:51 <jsled> It looks like "spaces in the middle of keys" are accepted, but not "initial of [sic] final spaces, which would lead to silent corruption".
10:54:25 <jsled> which, I though, was our case: no initial/final space, but spaces in the middle of keys.
10:54:43 <andi5> it is our case, indeed
10:56:21 <andi5> warlord: i think having symbols with the same name in different libraries (like gkeyfile functionality in gnucash and gtk) will lead to problems... it has already for gtktreedata,[ch]
10:57:10 <warlord> andi5: who said that we'd keep the symbols the same name?
10:57:34 <andi5> nobody :)
10:58:26 <andi5> ah, gtktreedatalist.[ch] was it
10:59:36 <warlord> Okay, trunk builds, passes checks, and installs for me on x86
11:00:38 * andi5 is starting his semi-automatic (sed-machine)
11:01:01 <warlord> :)
11:03:39 <warlord> Wow. Interesting guile bug!
11:04:00 <warlord> guile
11:04:00 <warlord> guile> (string-match "taxes:tax fica(mel" "income:bonus")
11:04:00 <warlord> <unnamed port>: In procedure make-regexp in expression (make-regexp pattern):
11:04:00 <warlord> <unnamed port>: Unmatched ( or \(
11:04:00 <warlord> ABORT: (regular-expression-syntax)
11:05:18 <MrN> that's no scheme exception stuff, right?
11:06:15 <warlord> MrN: Huh?
11:06:31 *** mnoir has quit IRC
11:06:49 <MrN> i don't know if scheme has exceptions or something like that
11:07:01 <warlord> Actually, it's not a bug per-se.. The first argument to string-match is a regexp.. Hmm..
11:07:12 <andi5> svn.gnome.org/viewcvs seems to be faster now... is it only me?
11:08:24 <warlord> andi5: it's only you.
11:08:30 <warlord> (maybe)
11:08:46 <warlord> MrN: it sort of has exceptions..
11:09:11 <MrN> well then this expressions should throw one, right?
11:13:03 <warlord> MrN: you're not helping.
11:13:15 <warlord> It IS throwing an exception, that's the problem!
11:13:36 <MrN> catch it.
11:13:50 <warlord> MrN: you're REALLY not helping.
11:14:04 <MrN> why can't you catch it?
11:14:16 <warlord> Catch it where? And do what?
11:14:35 <jsled> (string-match (regex-escape "taxes:tax fica(mel") "income:bonus")
11:14:47 <jsled> I don't know if/who provides regex-escape, but they're easy to write.
11:14:48 <andi5> bug-buddy catches crashes, but people somehow do not like it... makes me wonder
11:15:34 <MrN> if you escape it anyways, why don't you use some non-regex function?
11:16:05 <warlord> MrN: Well, the thing is, I was unaware (until a few minutes ago) that string-match actually used a regex.
11:16:13 <warlord> I thought it was more like strstr()
11:16:14 *** minDscrm has quit IRC
11:16:20 <MrN> i see.
11:16:22 <jsled> Yeah. Maybe (regexp-match ...) only matches literal strings. ;)
11:16:41 <MrN> string-contains or something like that?
11:17:24 <warlord> jsled: I'm not using regexp-match.. I'm using string-match
11:17:37 <warlord> Apparently /IT/ uses regexp-match internally.
11:17:48 <warlord> MrN: guile> string-contains
11:17:48 <warlord> <unnamed port>: In expression string-contains:
11:17:48 <warlord> <unnamed port>: Unbound variable: string-contains
11:17:48 <warlord> ABORT: (unbound-variable)
11:17:53 <warlord> try again.
11:18:00 <jsled> warlord: That's what I'm saying ... if string-match matches regexps, maybe regexp-match matches strings... I was trying to make a funny.
11:18:07 <MrN> hey come on, who's the scheme god here?
11:18:18 * jsled goes back to changing litter pans
11:18:42 <warlord> jsled: hahaha
11:19:10 <warlord> MrN: it's interesting that http://os.cqu.edu.au/cgi-bin/info/info2html.cgi?(guile)String%20Searching mentions string-contains, but guile doesn't have it in my environment.
11:19:45 <MrN> ...cool
11:19:46 *** minDscrm has joined #gnucash
11:20:58 <andi5> guile -c "(use-modules (srfi srfi-13)) (if (string-contains \"ABC\" \"B\") (display \"YES\\n\"))"
11:24:24 <warlord> yeah. thanks.
11:24:37 *** minDscrm has quit IRC
11:37:49 *** mnoir has joined #gnucash
11:38:45 <MrN> yeah i guessed the procedure name correctly
11:38:48 <MrN> *proud*
11:39:09 <andi5> so you did not know it?
11:39:21 <andi5> *disappointed*
11:39:41 <MrN> hey guessing well is harder than knowing :)
11:40:12 <MrN> ok maybe i'm a bit stretching the truth... but... whatever
11:40:19 <andi5> a little bit
11:40:47 <jsled> andi5, warlord: what do you think of <http://pastebin.ca/322662>? I'm always wary about changing configure.in, but this seems pretty safe/broadly-supported.
11:41:12 <jsled> It might be better to test for -O*, but I'm not sure how to do that in a safe way.
11:42:57 <jsled> Otherwise, I'd do some nifty bash-ism like `test ${flag/-O/} -gt 0` or something
11:43:21 <jsled> (with an alternate test, I guess, as that wouldn't work exactly, but you get my drift)
11:43:30 <warlord> jsled: echo $flag | egrep '^-O[0-9]$' ??
11:43:53 <andi5> honestly, why does not appending "-O0" work?
11:43:57 *** minDscrm has joined #gnucash
11:44:12 <warlord> andi5: it doesn't. You don't want any -O in this case.
11:44:19 <warlord> -O0 still applies optimization.
11:44:47 <andi5> -O0 Do not optimize. This is the default. (man gcc)
11:45:37 <chris> I use CFLAGS="-O0" here. It doens't optimize.
11:46:20 <warlord> I've had problems with using -O0 where not using any -O at all has fixed it.
11:46:23 <MrN> CFLAGS=$(echo $CFLAGS|sed -e 's/-O./-O0/g')
11:46:23 <jsled> I'd rather have the gnucash build be self-contained (i.e., didn't require an environmental setup). /me tries adding -O0 in --enable-debug instead of filtering.
11:46:51 <andi5> jsled: actually i think that is a good idea... i had it before :-P
11:47:07 <chris> We used to prepend the environment CFLAGS, and that wouldn't work when some lib decided to add -O2. But, now I think we append.
11:47:09 <jsled> Though that then has both args on the command-line, which is confusing, at best.
11:48:05 <andi5> CFLAGS work oppose to PATH, right? ... i.e. last wins?
11:48:10 <chris> jsled: Why force it? We should respect the environment variable.
11:48:27 <jsled> because if you --enable-debug, debugging should work. :)
11:48:59 <andi5> CFLAGS="-O1" ./configure --enable-debug ... should probably be O1
11:49:32 <chris> debugging still works with -g -02. Disabling optimization is independent.
11:50:24 <warlord> chris: optimization makes debugging MUCH MUCH harder.
11:50:25 *** mnoir has quit IRC
11:50:44 <chris> Some projects have --disable-optimization if setting CFLAGS is really too much trouble.
11:51:43 <jsled> I shouldn't need to change my environment. The build should just work. If I --enable-debug, I want debugging to work, and it often doesn't with -O*
11:51:57 <chris> warlord: I agree, but I'd rather not have to hack at configure.in in order to do it. We _have_ hit compiler optimization bugs with gnucash before.
11:52:46 <chris> jsled: define "work" --enable-debug doesn't do _everything_. It just gives you debugging symbols.
11:53:21 <chris> jsled: or are you saying it doesn't build?
11:53:47 <jsled> no, it builds fine, eliding function-calls and variables along the way.
11:54:35 <chris> Anybody building --enable-debug should know the difference between -g and -O.
11:55:38 <andi5> glib tarballs -> --enable-debug=[no/minimum/yes] == turn on debugging [default=minimum] ..... maybe we could mimic something similar? (i do not really know what minimum is, i just build with yes)
11:55:43 <chris> jsled: anyway, I don't mind _defaulting_ to -O0 or -O1 when --enable-debug.
11:56:18 <warlord> I dont think there's any easy way to set that "default". AC_PROG_CC sets it to -O2 by default.
11:56:26 <chris> jsled: but please don't strip out anything added by the enviroment variables.
11:56:51 <warlord> I dont think there's any way to differentiate between what was in the env var and what AC_PROG_CC adds.
11:57:01 <jsled> warlord: we could save it before the AC_PROG_CC call.
11:57:07 <warlord> (short of saving the env var prior to calling AC_PROG_CC)
11:57:12 <warlord> heh.
11:57:13 <warlord> yeah.
11:57:26 <andi5> reasking: -O2 -O0 == -O0, right?
11:57:55 <chris> andi5: yes.
11:57:59 <warlord> andi5: I /think/ so
11:59:20 <jsled> I can't get a clear read from man gcc.
11:59:55 <chris> AC_PROG_CC must already preserve CFLAGS, so we should just always prepend.
12:02:06 <warlord> Anyways, I'm going to head out for a bit.
12:02:10 *** warlord is now known as warlord-afk
12:05:08 <andi5> btw, why do we add "-g" to LDFLAGS?
12:07:41 <jsled> chris: except, if AC_PROG_CC appends -O2, we need to strip that. So it seems: save -O? from env cflags; AC_PROG_CC; if --enable-debug: strip -O?; add "-O0 $env_opt_flags";
12:07:42 <jsled> :(
12:08:08 <hampton> andi5: From the ld man page: -g Ignored. Provided for compatibility with other tools.
12:08:35 <andi5> hampton: yep, so it is safe to do... but why do we do it? ;-)
12:08:40 <hampton> I think you need -g with other compilers to keep the debugging information in the executable.
12:08:56 <hampton> I don't know, but its pretty common.
12:09:21 <andi5> you mean there are linkers that strip debugging symbols off?
12:10:18 <hampton> I'm thinking that there were such back around 1990, but my memory could be wrong. :-)
12:10:29 <andi5> hehe =)
12:11:05 <hampton> I haven't really used any tool chain other than gcc since then. Before that I was using both the sun and gcc tool chains..
12:13:04 <chris> jsled: why do you think that AC_PROG_CC appends -O2? I don't _think_ it does.
12:13:21 <jsled> It does unless CFLAGS already has anything, apparently.
12:13:37 <jsled> i.e, if CFLAGS is unset, it seems to default to "-g -O2".
12:14:21 <andi5> ack.... chris: what did you mean by "AC_PROG_CC must already preserve CFLAGS"? .... i thought we would want to _ap_pend... hmmm
12:14:36 <hampton> I see I need to get my act in gear and finish testing the "remove group" changes....
12:15:16 <chris> hmm, okay, so it doesn't override the environment, but it provides its own default.
12:15:52 <chris> andi5: I mean that it doesn't undo the effect of the environment's CFLAGS.
12:17:06 <chris> jsled: just an idea: check for --enable-debug _before_ AC_PROG_CC?
12:17:33 <jsled> except, AC_PROG_CC will then add -O2 back in...
12:17:51 <jsled> Oh, unless it sets it to -O0 explicitly.
12:17:52 <chris> if CFLAGS is unset, add _your_ default.
12:22:10 <andi5> cannot we use ac_test_CFLAGS to check whether CFLAGS was empty or not?
12:22:43 <andi5> or even better: ac_save_CFLAGS :)
12:23:12 <andi5> (one should check whether these variables change over time ;-))
12:24:16 *** |gunni| has joined #gnucash
12:26:36 <jsled> Well, I have a version that extracts any r'-O.' from environment CFLAGS, then (if enable-debug) strips r'-O.' and adds $USER_OPTIMIZATION back in.
12:27:37 <jsled> <http://pastebin.ca/322691>
12:28:12 <jsled> (except w/o the 'echo', of course.)
12:37:05 <chris> jsled: I don't get it. In the case where there was a USER_OPTIMIZATION, AC_PROG_CC will respect it. You don't have to have to do anything.
12:38:13 *** earlNameless has joined #gnucash
12:38:13 <chris> you only care about what happens when CFLAGS is completely empty, right?
12:39:23 <jsled> I care that there's not unrequested -O.s; empty CFLAGS happens to correlate with that.
12:39:42 <jsled> (b/c of AC_PROG_CC)
12:40:32 <jsled> So, yeah, rather than being conditional, it just is overly aggressive. Save $user_request; strip blindly; add $user_request;
12:43:18 * chris shrugs.
12:43:50 <chris> seems heavy-handed to me. but it should work, and it respects the environment.
12:44:00 <chris> so, fine with me.
12:45:31 <chris> Of course, if you're really worried about random pollution of CFLAGS, it'd be better to do this much later.
12:51:01 <earlNameless> when I do file->import->log file, gnucash plays the log file, and then hangs (gui unresponsive); is there some long operation it is doing, or should i be doing something special?
12:51:41 <earlNameless> (using 1.8.11; using gentoo, so upgrade to newest version will take >=6 hours)
12:52:16 <jsled> you sould totally upgrade to 2.0.x
12:52:24 <chris> earlNameless: what does 'top' say?
12:52:49 <jsled> in particular, there were import log files in 2.0.x
12:53:58 <earlNameless> jsled: in progress of upgrading, downloading package 38 of 54 that are required for upgrade
12:54:39 <chris> jsled: s/files/fixes/ ?
12:54:57 <earlNameless> chris: Debug: process_trans_record: process_trans_record(): Record ended
12:55:12 <earlNameless> chris: nevermind, i am a moron hold on
12:56:11 <jsled> fixes, yes. like serious, data-file corrupting fixes.
12:56:22 <MrN> earlNameless: if you have such a friggin slow box, consider using something different than gentoo
12:56:41 * chris waits for earlNameless to stop being a moron... dum de dum dum...
12:57:18 <earlNameless> chris: guile taking up 94% of cpu
12:57:32 <chris> earlNameless: ah... better let 'er cook.
12:57:58 <earlNameless> MrN: it is not a slow box, it worked, so i did not upgrade in past 4 months, so now have to upgrade a lot of dependencies
12:58:05 <chris> but, still consider upgrading.
12:58:40 <MrN> earlNameless: heh. well, still you might consider using something different. i once used gentoo myself and now think that all this compiling is wasted time. whatever :D
12:58:42 *** twunder has joined #gnucash
12:59:11 * earlNameless currently doing fetch of packages required for upgrade to 2.0.1 (latest in gentoo)
12:59:23 *** rearnsha has joined #gnucash
13:00:06 <earlNameless> MrN: might be a waste of time, but it forces you to know how your system is setup much more; when i used mandrake and something would break i would just reinstall, in gentoo i actually try to fix it
13:00:42 <MrN> earlNameless: well gentoo is great for learning linux, that's true
13:02:49 <earlNameless> chris: i stopped being moron, top says that guile is taking all of cpu use
13:03:16 <earlNameless> chris: should i just let it sit there? and see what happens
13:04:38 <earlNameless> MrN: yah, recompiling the kernel is not voodoo (seemed that way in mandrake)
13:07:14 * andi5 does not compile kernels any more (but using 2.6.20 nonetheless)... that bit of extra speed is really compensated my time saved (ok, maybe you have better reasons to do it)
13:08:11 <chris> earlNameless: yeah, that log import is notoriously slow, but it's probably making progress.
13:09:14 <earlNameless> chris: ok, thanks; i'll let it sit there; at the beginning I saw number change in the accounts page; but now the entire window is just gray and white (solid colors)
13:10:42 <earlNameless> andi5: if you recompile it, you can also customize it more; since my machine is not a server, i am using file scheduled that splits time equally between all processes, so i can listen to music while root is unpacking huge files
13:11:49 <andi5> earlNameless: i cannot remember the last time my music stopped playing because of anything ;)
13:12:21 <rearnsha> I've just tried to upgrade from gnucash-1.8.12 to gnucash-2.0.3 and now gnucash is crashing every time I try to enter anything in the register.
13:12:39 <andi5> rearnsha: distro?
13:12:47 <rearnsha> NetBSD
13:12:52 <earlNameless> chris: ok, it is done now, took 7 minutes of cpu time; i'll let it sit there from now :)
13:12:52 <rearnsha> standard pkgsrc build
13:13:05 <andi5> rearnsha: do you have a good stacktrace to pastebin?
13:13:12 *** Gnucahier has joined #gnucash
13:13:23 <rearnsha> Not really, the build system strips all the libraries
13:13:35 <Gnucahier> Hi all..
13:13:40 <andi5> arrgh... anything printed to the terminal?
13:14:17 <Gnucahier> Wow .. this channel looks busy, great.
13:14:18 *** gander has joined #gnucash
13:14:51 <rearnsha> bug-buddy says its in gnc_default_share_print_info, but I'd take that with a pinch of salt.
13:15:13 <Gnucahier> Is there a way to change the lettertype or size for the invoices ( not the html )
13:15:15 <earlNameless> andi5: the only time i had it happen was when i was upgrading system, which resulted in a lot of harddrive accesses by root, which had higher priority than my mp3 player, causing music to studder
13:15:51 <Gnucahier> If i print them the lettertypes are terribly big.
13:16:00 <chris> rearnsha: can you coerce the build system (ports?) to not strip the symbols?
13:16:09 <Gnucahier> Anyone?
13:16:22 <andi5> Gnucahier: see the topic :)
13:16:26 <rearnsha> chris: I'll have to do some poking around
13:17:03 <Gnucahier> mmmk idd
13:17:51 <andi5> hm... i do not know whether we have a solution to "font sizes are too big on print" now.... *does not print*
13:19:59 <andi5> Gnucahier: i can only say: we use gnomeprint and do not do anything spectacular... maybe you can find something in the ml archives via lists.gnucash.org/search
13:20:01 *** motin has quit IRC
13:22:20 *** slicslak has joined #gnucash
13:23:08 <Gnucahier> Ok, at least i am able to print. :) But with gnomeprint you've got a standard printing size? The standard size used now is to big, i will try to search. The font printed on the screen is fine, but when we print we do get a too large size.
13:23:52 <slicslak> 2.0.2 crashes on startup. i have the backtrace. what should i do with it?
13:27:46 <earlNameless> chris: thanks for the help
13:28:53 <chris> earlNameless: yw.
13:29:33 <chris> slicslak: pastebin it first.
13:29:50 <Gnucahier> Which option in gnomeprint will change the print output font and size?
13:30:57 *** motin has joined #gnucash
13:30:59 <andi5> Gnucahier: if there was some obvious we would have changed it already :-)
13:32:19 <Gnucahier> :-) Too bad..
13:36:47 <slicslak> chris, gentoo, gnucash 2.0.2, on startup, every time. http://pastebin.com/863680
13:37:01 <Gnucahier> thanks for the help
13:38:58 <andi5> slicslak: downgrade slib
13:40:37 <slicslak> andi5, to what?
13:41:11 <andi5> hm.... 3a3 or so... i am sorry, i cannot check right now... there are some posts about it, in bugzilla and some mailing list
13:41:25 <chris> this should be in FAQ if it's not.
13:41:43 <andi5> has anyone checked whether the bug may be gnucash's?
13:42:29 <slicslak> andi5, right, ok, i'll check
13:44:24 *** andi5 has quit IRC
13:50:42 *** motin has quit IRC
13:51:42 <jsled> slicslak: http://wiki.gnucash.org/wiki/Gentoo#Early_2007_problems_with_guile.2C_slib.2C_g-wrap_and_gnucash
13:51:52 <jsled> What version of guile, g-wrap and slib are you running?
13:54:16 <MrN> i was told that gnucash refocused on C instead of Scheme. will the guile dependency be eliminated entirely, eventually?
13:54:43 <jsled> MrN: "refocused"? I think it will eventually be eliminated, yes.
13:55:00 <jsled> It's probably on the order of years, though.
13:55:07 <MrN> 3.0 or something?
13:55:17 <MrN> are you really about to replace all scheme with C?
13:55:38 <jsled> "about to"? No. I'd like to, yes. The big question right now is the reports.
13:55:50 <jsled> s/question/scheme-user/
13:56:38 <jsled> I'd like to revise the report subsystem, in part to allow them to be defined in something besides scheme, then migrate the reports over to whatever that is.
13:59:13 <MrN> hmm... perl would be ok as you already depend on it, wouldn't it?
14:00:25 <jsled> We don't really depend on perl. I'd personally rather it was python. That'll be a very interesting dev discussion. :)
14:01:39 <MrN> so you're a C/Python freak? :P
14:02:34 <MrN> well i guess that Gnucash Report Description Language would be the least controversial choice :)
14:02:37 <jsled> not particularly. day job is java. I like python. I do C, obviously, but have no real love for non-managed languages, at this point.
14:03:04 *** minDscrm has quit IRC
14:03:17 <MrN> well having no love for C is understandable *ducks*
14:05:52 <jsled> :)
14:06:08 *** wizkid238 has quit IRC
14:06:31 <MrN> the problem is that other languages tend to be more controversial
14:06:50 <MrN> the real problem being that many people don't have my opinion
14:10:59 *** twunder has quit IRC
14:11:13 *** minDscrm has joined #gnucash
14:19:58 *** warlord-afk is now known as warlord
14:20:05 <warlord> FWIW, I'm not a fan of python.
14:20:50 <warlord> For reports I'd much rather see something like eguile where reports are actual HTML templates that get executed.
14:25:45 <jsled> we could do that with any language; and it's good to separate the "report data generation" from the "html formatting".
14:26:05 <jsled> via some intermediate data-structure.
14:27:34 <jsled> It seems like ruby is about in the same boat as python. perl is widely known, widely-available, and basically as simple; it's probably the best choice.
14:27:57 <warlord> True. It would be best to have an intermediate (XML?) format from the generator, and then some XSLT+CSS for the output/display
14:27:59 <MrN> and finance::quote uses it
14:28:12 <warlord> I would not object to perl..
14:28:39 <jsled> MrN: yeah, though our dependence on F::Q is more data-focused: we spawn it, and it returns a s-expr.
14:28:58 <jsled> we don't care that it's perl or C#.
14:29:00 <MrN> perl is not a great language. but it's quite ok.
14:29:28 <MrN> do you have a c-parser for the s-expr?
14:30:27 <warlord> No, i think it's done in scheme.
14:30:47 <warlord> actually, it might be done in C (via libguile) ;)
14:31:13 <MrN> but it's primarily used by C-code?
14:31:53 <warlord> "it" == what in this context? the s-expr? or price quites?
14:32:00 <warlord> quotes evem
14:32:01 <warlord> even
14:32:04 <warlord> GRR..
14:32:24 <earlNameless> if you make xml intermediate format, most languages have xml parsers, so it should be fairly easy to access them in any language
14:32:28 <MrN> the quotes
14:34:14 <jsled> or json.
14:34:53 <jsled> Really, though, I'm not sure it needs to be either serialization.
14:35:11 *** Gnucahier has quit IRC
14:35:17 <jsled> (heh)
14:35:43 <jsled> So much as just an in-memory data strcuture.
14:35:50 <jsled> structure, even.
14:35:56 <MrN> well... that'd not be language-neutral :)
14:36:06 <jsled> no, it'd be language neutral, via swig.
14:36:13 <jsled> So long as that was the agreement.
14:36:51 <jsled> I mean, there's a pretty standard set of basic data types, right now. primitves, lists, dictionaries.
14:36:51 <MrN> so it'd be a c-managed data structure used by all them languages
14:37:08 <jsled> I don't know about all-them. I think we should choose one for the reports.
14:37:38 <jsled> I mean, we only want to write gnucash code to evaluate one language, not any.
14:38:34 <jsled> in which case, it doesn't necessarily *need* to be language neutral, let alone XML/JSON. But there's no call to use any perl-specific mumble...
14:42:01 <jsled> The report-"core" should generate a data-structure (that could be serialized to a language-indep. format, though it probably isn't), and the report-"template" should simply operate over that structure (conditionals, iteration, &c.) to emit text (probably html, maybe xml)
14:42:37 <MrN> well and graphics
14:43:01 <MrN> you could use SVG for that.
14:43:22 <jsled> yeah, good point. we do that now with <object data="1,2,3" /> tags.
14:43:58 <jsled> I'd rather the reports didn't emit svg in particular. AT the same time I think they should emit html in particular. :)
14:44:18 <MrN> PDF would be nice to export
14:44:21 <MrN> maybe latex?
14:44:26 <jsled> oh god.
14:44:28 <jsled> no.
14:44:50 <warlord> Not latex.
14:44:54 <warlord> (except, maybe, for invoices)
14:44:55 <MrN> heh
14:45:15 <warlord> And as for pdf -- the html-viewer should be able to "print to PDF"
14:45:42 <jsled> Yeah. It feels like html + css + a good html component (gecko) should get us a suitable PDF.
14:45:48 <MrN> but if you use html, you really should go for SVG or some vector graphics stuff
14:45:53 <jsled> And we should probably be able to export SVG.
14:45:58 <jsled> And GOG will create SVG for us.
14:46:17 <earlNameless> i am a developer by trade, so this discussion has peaked my interest; are report-"templates" part of the gnucash code? (or can they be executed as standalone programs)
14:46:19 <MrN> gecko supports displaying svg afaik
14:46:35 <jsled> But the form we have now -- where the report emits an <object/> with the data points, that's rendered by gnucash into the right output format (pixbuf, png, svg) isn't bad.
14:47:06 <MrN> you have html intermixed with gnucash:object?
14:47:10 <jsled> earlNameless: reports right now are scheme scripts that both iterate over the data and emit html; they can't really be run stand-alone.
14:48:06 <jsled> Not <gnc:object>, just <[html:]object classid="gnc:..." /> (I think). The gtkhtml calls us back as per registration for those object classes.
14:48:44 <jsled> earlNameless: They bind against the g-wrap-exposed API over the engine and application APIs.
14:49:07 <earlNameless> jsled: ok, thanks; the discussion makes more sense now :)
14:49:21 <MrN> jsled: i see. so you generate (more or less) compliant html. not bad.
14:49:47 <jsled> MrN: less than more; our html emission is sub-optimal, and gtkhtml sucks.
14:50:06 <MrN> well not like gecko doesn't suck :)
14:50:09 <warlord> gtkhtml sucks royally
14:50:17 <jsled> MrN: Though, this was developed pre-html4 and pre-CSS, so some of it's excusable.
14:50:20 <warlord> gecko is at least more HTML-compliant.
14:50:22 <MrN> but it's probably better
14:50:42 *** Gnucashier has joined #gnucash
14:50:51 <MrN> good html renderer are indeed rare
14:51:14 <warlord> Of course, there's no "gecko-devel" package... One needs to pull in mozilla to get it. :(
14:51:48 <MrN> would cairo be an appropriate "output language"?
14:51:48 <Gnucashier> http://liferea.blogspot.com/2006/10/solving-font-problems.html Maybe this will help
14:51:59 <Gnucashier> setting the font-size.
14:53:39 <warlord> Hmm, that talks about gtkhtml-2, not gtkhtml-3
14:55:10 <jsled> MrN: I don't think so. I mean, goffice/gtk will use cairo to render images, if we like ... but I don't think there's a application/cairo or anything..
14:55:40 <jsled> MrN: But I'm not immersed in that stuff; there might well be!
14:55:44 <MrN> jsled: you depend on goffice?
14:56:05 <jsled> MrN: we do, yes. We use GOG for graphing in place of Guppi.
14:56:41 <jsled> (biaw)
14:56:54 <MrN> *scratch head*
14:57:50 <warlord> MrN: what are you confused about?
14:57:54 *** wizkid238 has joined #gnucash
14:59:30 *** mnoir has joined #gnucash
14:59:48 <MrN> well i'm...
15:00:04 <MrN> stunned
15:00:06 <rearnsha> sigh! I've just managed to rebuild gnucash with -O0 -g, and now it crashes as soon as I try to open a transaction register...
15:00:33 <rearnsha> #0 0xbb9bf1be in block_picker_signals (cell=0x9294700) at datecell-gnome.c:270
15:00:38 <MrN> warlord: using an office suite for graphing... sounds a bit insane
15:01:03 <rearnsha> box is set to -1
15:02:05 <warlord> MrN: it's GOG == Gnome Office Graphics.
15:02:20 <warlord> rearnsha: can you pastebin the full stack trace
15:02:32 <warlord> rearnsha: and what version of gnucash is this?
15:02:42 <rearnsha> 2.0.3
15:03:47 <warlord> Gnucashier: I dont know if we actually put a font name/size into a style..
15:04:18 <rearnsha> warlord: http://pastebin.com/863733
15:05:39 <warlord> MrN: it's not insane at all. Now, writing a graphics library from scratch instead of using an existing graphics library, now THAT would indeed be insane!
15:05:39 *** twunder has joined #gnucash
15:05:59 <warlord> rearnsha: try upgrading to 2.0.4?
15:06:18 <MrN> warlord: there are other graphics libraries that are not a whole office suite? :)
15:06:25 <rearnsha> Not trivial, since this is all built through the NetBSD package system.
15:06:46 <rearnsha> Is this a know problem, or just a 'have you tried?'
15:07:34 <rearnsha> Oddly, this problem doesn't occur with a non-debug build :-(
15:09:36 <warlord> rearnsha: I haven't tried, but 2.0.3 is a known-buggy release.
15:09:55 <warlord> MrN: libgoffice isn't a whole office suite.
15:10:26 <MrN> warlord: hmm probably i was just shocked by the name.
15:10:36 <warlord> MrN: you seem very easily shocked.
15:10:46 <MrN> you too :)
15:11:22 <warlord> only at you! ;)
15:15:15 <Gnucashier> Okay i am still searching for setting my print size in gnucash ( the invoice print )
15:15:37 <warlord> Gnucashier: searching where?
15:15:53 <warlord> I think the issue is that we dont actually set font name/size in the generated html
15:16:28 <Gnucashier> Okay i understand, but i mean the font's for the interface seem to be different then the printed fonts.
15:17:55 <warlord> Well, can you change the visible font?
15:18:09 <warlord> (if so, then the problem is gtkhtml/gnomeprint)
15:18:12 <Gnucashier> Yes..
15:18:24 <Gnucashier> libgtkhtml/document/htmldocument.c (html_document_class_init): Add the gtkhtml-minimum-font-size
15:19:01 <Gnucashier> More on http://cia.navi.cx/stats/project/gnome/gtkhtml2
15:19:23 <chris> rearnsha: with the non-debug build it didn't start at all, right?
15:19:44 <rearnsha> chris: No, it got further...
15:20:20 <rearnsha> I wonder if there's some form of pthread race going on. WIth some single stepping it is now going ok...
15:20:23 <rearnsha> weird stuff.
15:20:59 <warlord> i'm not sure what threads.. gnucash isn't multi-threaded
15:21:20 <warlord> Gnucashier: thats gtkhtml2.. thats not gtkhtml3, which is what we use.
15:21:30 <rearnsha> warlord: maybe not, but some parts of the gnome stuff are.
15:21:58 <rearnsha> at least, the app has been linked with pthreads code, I'm seeing it in functiosn within that
15:27:31 *** ErKa has quit IRC
15:28:36 <warlord> rearnsha: unfortunately none of the devs use *BSD
15:28:43 <warlord> so it's not well-tested there.
15:29:20 <chris> rearnsha: you said box == -1, right?
15:29:26 <rearnsha> yes
15:29:52 <rearnsha> It's looking to me like some memory corruption in the date parsing code
15:29:56 <chris> Gnucash only sets that value once, (all other times are set to NULL).
15:30:31 <rearnsha> The Cell value gets corrupted
15:30:32 <chris> and it's right after being dereferenced. In combocell-gnome.c:151
15:31:02 <rearnsha> In fact, in this case it seems like its the pointer to the cell itself.
15:31:09 <rearnsha> (that gets mashed)
15:32:01 <chris> it's definitely something getting corrupted.
15:32:45 <warlord> chris: we need your register rewrite. ;)
15:33:08 <chris> warlord: I know.
15:33:55 <chris> rearnsha: this is probably something particular to your setup. Do let us know if you find out what.
15:36:07 <rearnsha> Is there a way of hooking gdb into the startup process (so that I don't have to try and catch a particular pid before things go wrong?)
15:39:13 *** Gnucashier has quit IRC
15:51:10 *** sjc has joined #gnucash
15:51:34 <warlord> rearnsha: "gnucash-env gdb gnucash-bin"
15:51:53 <rearnsha> Ta!
15:54:33 <rearnsha> The corruption is occuring in g_spawn_command_line_sync -- don't ask me why!
15:55:40 <rearnsha> Hmm, maybe not. But it is somewhere in libglib-2.0.so
15:55:44 *** |gunni| has joined #gnucash
15:55:51 *** |gunni| has quit IRC
15:55:59 <rearnsha> part of the g_vsnprintf code at a guess
15:57:21 <warlord> rearnsha: are you on x86 or a 64-bit platform?
15:57:29 <rearnsha> 32-bit
15:58:15 <rearnsha> Hmm, how big is DATE_BUF supposed ot be?
16:00:48 <rearnsha> Aha! DATE_BUF=30. the len value passed to snprintf is 31!
16:00:55 *** earlNameless has quit IRC
16:01:05 <warlord> That seems broken.
16:01:15 *** rouven has joined #gnucash
16:01:15 *** twunder has quit IRC
16:02:27 *** twunder has joined #gnucash
16:02:55 <rearnsha> Indeed, the lenght value passed to qof_print_date_dmy_buff is MAX_DATE_LENGTH, which is 31
16:04:19 <warlord> Where is the buffer defined?
16:04:44 <rearnsha> gnc_date_cell_set_value_internal
16:05:08 <rearnsha> datecell-gnome.c:668
16:05:19 <rearnsha> or thereabouts
16:06:59 <warlord> Yeah, looks like DATE_BUF needs to change from 30 to 32.
16:07:27 <rearnsha> More precisely, shoudn't it be MAX_DATE_LENGTH + 1?
16:07:53 <warlord> Yeah, but is MAX_DATE_LENGTH defined here?
16:07:59 <warlord> Anyways, try it and see..
16:08:11 <warlord> if it fixes it, file a bug report with the diff.
16:08:14 <warlord> I gotta run
16:08:16 *** warlord is now known as warlord-afk
16:10:36 *** cortana has quit IRC
16:30:20 *** twunder has quit IRC
16:44:19 *** rouven has quit IRC
16:56:39 <prock> trunk//lib/libgnc-backend-file-utils.so.0: undefined reference to `gnc_book_set_schedxactions'
16:57:40 <slicslak> jsled, slib-3.1.4 and slib-3.1.1 both showed the same issue so I hardmaked both of them (thanks andi5!). this brought in dependencies g-wrap-1.3.4-r1, slib-2.4.6 and guile-1.6.7 which fixed the problem.
17:05:51 <jsled> slicslak: huh. I've seen slib-3.1.1 work (I'm using it right now); and it only works (so far) with guile-1.6.7. I wonder if g-wrap-1.3.4-r1 isn't playing nicely with slib-3.1.1.
17:11:09 <slicslak> jsled, from what i can see, it looks like my gwrap version hasn't change through all of this. slib-3.1.1 didn't require anything different, only slib-2.4.6 required the lower version of guile, guile-1.6.7. i wonder if i could have fixed it then by just using guile-1.6.7. <shrug> back go coding!
17:11:23 <slicslak> go = to
17:11:29 <jsled> slicslak: oh, you were using guile-1.6.8?
17:12:23 <jsled> Yeah, I think you'd be able to go to slib-3.1.1, now, though you'd have to rebuild gnucash. But if you quickpkg both, at least you can quickly *revert* if things don't work. :) If you have the time, it'd be a great other datapoint.
17:21:04 <jsled> prock: did you resolve that?
17:24:51 <prock> have to go I'll look at it later.
17:26:27 <jsled> gncbot: tell prock the general form of the solution is "add an explicit reference to the library containing the missing symbol to the link line for the module". Though I notice in src/backend/file/Makefile.am that there's a missing "${top_builddir}" ... that might be it. I'm not sure from your message what dir the error was in.
17:26:27 <gncbot> jsled: The operation succeeded.
17:31:06 *** vnx has joined #gnucash
17:48:32 *** Demitar has quit IRC
17:48:45 *** Demitar has joined #gnucash
18:13:31 *** gander has quit IRC
18:16:10 *** vnx has left #gnucash
18:42:57 <slicslak> jsled, yes, guile-1.6.8. sure, i have emerge nice=15 so it doesn't bother me. :-) just recompiled; guile-1.6.7 + slib-3.1.1 also work fine
18:56:26 <jsled> slicslak: good; thanks for the confirmation. :)
19:48:05 *** andi5 has joined #gnucash
19:48:06 *** gncbot sets mode: +o andi5
20:05:01 *** jpeach has joined #gnucash
20:22:35 *** jpeach has quit IRC
20:31:42 *** jpeach has joined #gnucash
20:32:29 *** jpeach has left #gnucash
20:32:54 *** mnoir has quit IRC
21:02:31 *** andi5 has quit IRC
21:07:51 *** xai has joined #gnucash
21:17:22 *** xai has quit IRC
21:20:19 *** sjc has quit IRC
21:31:53 *** MrN has quit IRC
22:32:08 *** Demitar_ has joined #gnucash
22:42:01 *** warlord-afk is now known as warlord
22:42:09 <warlord> where the hell did someone come up with "gnucash --usage"?
22:42:33 <warlord> (and why does glib/gtk actually print something for that!?!? WTF?)
23:06:35 <hampton> I think its build into g_options, or whatever we're using for option parsing.
23:06:56 * hampton crosses his fingers that the new video card will be supported...
23:08:24 <warlord> Huh. I wonder if we can override it to say something like [[[ What kind of idiot are you? Where did you think "--usage" is anything standard. Trying using "--help" ]]]
23:13:46 <hampton> A HA!!!! Something rewrote my xorg.conf file to use the radeon driver instead of the fglrx driver.
23:13:56 * hampton does a jig. :-) :-)
23:14:00 <warlord> Nice
23:14:03 <warlord> (or not)
23:26:38 *** hampton is now known as hampton2
23:26:45 *** hampto1 has joined #gnucash
23:26:45 *** gncbot sets mode: +o hampto1
23:26:51 *** hampto1 is now known as hampton
00:14:35 *** warlord is now known as warlord-afk
01:10:27 *** BurnOut has quit IRC
02:50:44 *** motin has joined #gnucash
04:41:26 *** errre has joined #gnucash
04:42:36 *** ErKa has joined #gnucash
04:43:44 *** errre has left #gnucash
05:42:42 *** nomeata has joined #gnucash
07:05:29 *** BC-bd has joined #gnucash
07:25:11 *** andi5 has joined #gnucash
07:25:12 *** gncbot sets mode: +o andi5
07:36:53 <prock> jsled: thanks =)
07:48:27 *** nomeata has quit IRC
08:01:15 *** twunder has joined #gnucash
08:11:37 *** MrN has joined #gnucash
08:14:05 <MrN> hi
08:27:35 *** |gunni| has joined #gnucash
08:55:36 *** mnoir has joined #gnucash
09:10:16 *** twunder has quit IRC
10:26:12 <jsled> andi5: sorry, I probably should have waited for your version upgrade. I hope my commit didn't slow you down too much. But it compiled, &c., for you?
10:27:00 <andi5> yes
10:27:24 <andi5> i only needed to remove 3 lines in your new plugin page (gkeyfile.h) that was all
10:28:15 <andi5> make check slowed me down... (it still does not work in po/ for me)
10:28:40 <jsled> did you see any other failures? I added some new SX-related tests...
10:29:02 <andi5> were should i look?
10:29:05 <andi5> +h
10:29:21 <jsled> engine. app-utils gnome-utils
10:30:05 <andi5> jsled: i only saw these g_date_somewhat warnings, but i guess you know them
10:30:31 <jsled> yeah. That's not me. Some other guy, some other job.
10:30:46 <jsled> :)
10:30:47 <andi5> is it that hard to fix?
10:32:39 <jsled> I'm not sure, yet. http://bugzilla.gnome.org/show_bug.cgi?id=394420
10:37:05 <andi5> test-sx passed (warnings, see above), test-freq-spec and test-recurrence looks as if unchanged, test-sx in app-utils: 74 tests passed quietly
10:38:16 <jsled> Good good.
10:38:42 <jsled> That (app-utils) is the key one, though just a skeleton at this point.
10:39:27 <andi5> i see... please do not take it personally, but i probably will not take a closer look soon :-)
10:39:46 <jsled> no no, that's alright. Thanks very much. :)
10:42:56 <andi5> jsled: so current trunk builds for you?
10:43:04 <jsled> yes, just finished.
10:43:05 *** warlord-afk is now known as warlord
10:43:20 <andi5> good :)
10:43:36 * warlord is checking trunk
10:43:46 <warlord> (I'll try on Mac soon)
10:44:55 * andi5 will test on windows tomorrow
10:45:18 <jsled> Hmm. How to get `--enable-debug` to remove (or not add) `-O2` to CFLAGS?
10:45:29 <warlord> jsled: very hard.
10:45:56 <andi5> -O0
10:46:07 <warlord> You need to reset CPPFLAGS/CFLAGS/CXXFLAGS just after AC_PROG_GCC
10:46:33 <jsled> AC_PROG_CC ?
10:47:39 <warlord> jsled: FYI, we might need the old gkey* implementation to workaround the glib "no spaces in keys" issue.
10:48:00 <jsled> it looks like they've backed off.
10:48:03 <warlord> Sorry, yeah, AC_PROG_CC
10:48:14 <jsled> trunk now only warns on "conditions that would make the file unreadable", I believe.
10:48:16 <warlord> Have they backed off completely?
10:50:41 <jsled> "completely" I don't know. <http://bugs.gentoo.org/show_bug.cgi?id=158673#c4>
10:50:55 <warlord> it sounds like they still intend to make this change...
10:53:51 <jsled> It looks like "spaces in the middle of keys" are accepted, but not "initial of [sic] final spaces, which would lead to silent corruption".
10:54:25 <jsled> which, I though, was our case: no initial/final space, but spaces in the middle of keys.
10:54:43 <andi5> it is our case, indeed
10:56:21 <andi5> warlord: i think having symbols with the same name in different libraries (like gkeyfile functionality in gnucash and gtk) will lead to problems... it has already for gtktreedata,[ch]
10:57:10 <warlord> andi5: who said that we'd keep the symbols the same name?
10:57:34 <andi5> nobody :)
10:58:26 <andi5> ah, gtktreedatalist.[ch] was it
10:59:36 <warlord> Okay, trunk builds, passes checks, and installs for me on x86
11:00:38 * andi5 is starting his semi-automatic (sed-machine)
11:01:01 <warlord> :)
11:03:39 <warlord> Wow. Interesting guile bug!
11:04:00 <warlord> guile
11:04:00 <warlord> guile> (string-match "taxes:tax fica(mel" "income:bonus")
11:04:00 <warlord> <unnamed port>: In procedure make-regexp in expression (make-regexp pattern):
11:04:00 <warlord> <unnamed port>: Unmatched ( or \(
11:04:00 <warlord> ABORT: (regular-expression-syntax)
11:05:18 <MrN> that's no scheme exception stuff, right?
11:06:15 <warlord> MrN: Huh?
11:06:31 *** mnoir has quit IRC
11:06:49 <MrN> i don't know if scheme has exceptions or something like that
11:07:01 <warlord> Actually, it's not a bug per-se.. The first argument to string-match is a regexp.. Hmm..
11:07:12 <andi5> svn.gnome.org/viewcvs seems to be faster now... is it only me?
11:08:24 <warlord> andi5: it's only you.
11:08:30 <warlord> (maybe)
11:08:46 <warlord> MrN: it sort of has exceptions..
11:09:11 <MrN> well then this expressions should throw one, right?
11:13:03 <warlord> MrN: you're not helping.
11:13:15 <warlord> It IS throwing an exception, that's the problem!
11:13:36 <MrN> catch it.
11:13:50 <warlord> MrN: you're REALLY not helping.
11:14:04 <MrN> why can't you catch it?
11:14:16 <warlord> Catch it where? And do what?
11:14:35 <jsled> (string-match (regex-escape "taxes:tax fica(mel") "income:bonus")
11:14:47 <jsled> I don't know if/who provides regex-escape, but they're easy to write.
11:14:48 <andi5> bug-buddy catches crashes, but people somehow do not like it... makes me wonder
11:15:34 <MrN> if you escape it anyways, why don't you use some non-regex function?
11:16:05 <warlord> MrN: Well, the thing is, I was unaware (until a few minutes ago) that string-match actually used a regex.
11:16:13 <warlord> I thought it was more like strstr()
11:16:14 *** minDscrm has quit IRC
11:16:20 <MrN> i see.
11:16:22 <jsled> Yeah. Maybe (regexp-match ...) only matches literal strings. ;)
11:16:41 <MrN> string-contains or something like that?
11:17:24 <warlord> jsled: I'm not using regexp-match.. I'm using string-match
11:17:37 <warlord> Apparently /IT/ uses regexp-match internally.
11:17:48 <warlord> MrN: guile> string-contains
11:17:48 <warlord> <unnamed port>: In expression string-contains:
11:17:48 <warlord> <unnamed port>: Unbound variable: string-contains
11:17:48 <warlord> ABORT: (unbound-variable)
11:17:53 <warlord> try again.
11:18:00 <jsled> warlord: That's what I'm saying ... if string-match matches regexps, maybe regexp-match matches strings... I was trying to make a funny.
11:18:07 <MrN> hey come on, who's the scheme god here?
11:18:18 * jsled goes back to changing litter pans
11:18:42 <warlord> jsled: hahaha
11:19:10 <warlord> MrN: it's interesting that http://os.cqu.edu.au/cgi-bin/info/info2html.cgi?(guile)String%20Searching mentions string-contains, but guile doesn't have it in my environment.
11:19:45 <MrN> ...cool
11:19:46 *** minDscrm has joined #gnucash
11:20:58 <andi5> guile -c "(use-modules (srfi srfi-13)) (if (string-contains \"ABC\" \"B\") (display \"YES\\n\"))"
11:24:24 <warlord> yeah. thanks.
11:24:37 *** minDscrm has quit IRC
11:37:49 *** mnoir has joined #gnucash
11:38:45 <MrN> yeah i guessed the procedure name correctly
11:38:48 <MrN> *proud*
11:39:09 <andi5> so you did not know it?
11:39:21 <andi5> *disappointed*
11:39:41 <MrN> hey guessing well is harder than knowing :)
11:40:12 <MrN> ok maybe i'm a bit stretching the truth... but... whatever
11:40:19 <andi5> a little bit
11:40:47 <jsled> andi5, warlord: what do you think of <http://pastebin.ca/322662>? I'm always wary about changing configure.in, but this seems pretty safe/broadly-supported.
11:41:12 <jsled> It might be better to test for -O*, but I'm not sure how to do that in a safe way.
11:42:57 <jsled> Otherwise, I'd do some nifty bash-ism like `test ${flag/-O/} -gt 0` or something
11:43:21 <jsled> (with an alternate test, I guess, as that wouldn't work exactly, but you get my drift)
11:43:30 <warlord> jsled: echo $flag | egrep '^-O[0-9]$' ??
11:43:53 <andi5> honestly, why does not appending "-O0" work?
11:43:57 *** minDscrm has joined #gnucash
11:44:12 <warlord> andi5: it doesn't. You don't want any -O in this case.
11:44:19 <warlord> -O0 still applies optimization.
11:44:47 <andi5> -O0 Do not optimize. This is the default. (man gcc)
11:45:37 <chris> I use CFLAGS="-O0" here. It doens't optimize.
11:46:20 <warlord> I've had problems with using -O0 where not using any -O at all has fixed it.
11:46:23 <MrN> CFLAGS=$(echo $CFLAGS|sed -e 's/-O./-O0/g')
11:46:23 <jsled> I'd rather have the gnucash build be self-contained (i.e., didn't require an environmental setup). /me tries adding -O0 in --enable-debug instead of filtering.
11:46:51 <andi5> jsled: actually i think that is a good idea... i had it before :-P
11:47:07 <chris> We used to prepend the environment CFLAGS, and that wouldn't work when some lib decided to add -O2. But, now I think we append.
11:47:09 <jsled> Though that then has both args on the command-line, which is confusing, at best.
11:48:05 <andi5> CFLAGS work oppose to PATH, right? ... i.e. last wins?
11:48:10 <chris> jsled: Why force it? We should respect the environment variable.
11:48:27 <jsled> because if you --enable-debug, debugging should work. :)
11:48:59 <andi5> CFLAGS="-O1" ./configure --enable-debug ... should probably be O1
11:49:32 <chris> debugging still works with -g -02. Disabling optimization is independent.
11:50:24 <warlord> chris: optimization makes debugging MUCH MUCH harder.
11:50:25 *** mnoir has quit IRC
11:50:44 <chris> Some projects have --disable-optimization if setting CFLAGS is really too much trouble.
11:51:43 <jsled> I shouldn't need to change my environment. The build should just work. If I --enable-debug, I want debugging to work, and it often doesn't with -O*
11:51:57 <chris> warlord: I agree, but I'd rather not have to hack at configure.in in order to do it. We _have_ hit compiler optimization bugs with gnucash before.
11:52:46 <chris> jsled: define "work" --enable-debug doesn't do _everything_. It just gives you debugging symbols.
11:53:21 <chris> jsled: or are you saying it doesn't build?
11:53:47 <jsled> no, it builds fine, eliding function-calls and variables along the way.
11:54:35 <chris> Anybody building --enable-debug should know the difference between -g and -O.
11:55:38 <andi5> glib tarballs -> --enable-debug=[no/minimum/yes] == turn on debugging [default=minimum] ..... maybe we could mimic something similar? (i do not really know what minimum is, i just build with yes)
11:55:43 <chris> jsled: anyway, I don't mind _defaulting_ to -O0 or -O1 when --enable-debug.
11:56:18 <warlord> I dont think there's any easy way to set that "default". AC_PROG_CC sets it to -O2 by default.
11:56:26 <chris> jsled: but please don't strip out anything added by the enviroment variables.
11:56:51 <warlord> I dont think there's any way to differentiate between what was in the env var and what AC_PROG_CC adds.
11:57:01 <jsled> warlord: we could save it before the AC_PROG_CC call.
11:57:07 <warlord> (short of saving the env var prior to calling AC_PROG_CC)
11:57:12 <warlord> heh.
11:57:13 <warlord> yeah.
11:57:26 <andi5> reasking: -O2 -O0 == -O0, right?
11:57:55 <chris> andi5: yes.
11:57:59 <warlord> andi5: I /think/ so
11:59:20 <jsled> I can't get a clear read from man gcc.
11:59:55 <chris> AC_PROG_CC must already preserve CFLAGS, so we should just always prepend.
12:02:06 <warlord> Anyways, I'm going to head out for a bit.
12:02:10 *** warlord is now known as warlord-afk
12:05:08 <andi5> btw, why do we add "-g" to LDFLAGS?
12:07:41 <jsled> chris: except, if AC_PROG_CC appends -O2, we need to strip that. So it seems: save -O? from env cflags; AC_PROG_CC; if --enable-debug: strip -O?; add "-O0 $env_opt_flags";
12:07:42 <jsled> :(
12:08:08 <hampton> andi5: From the ld man page: -g Ignored. Provided for compatibility with other tools.
12:08:35 <andi5> hampton: yep, so it is safe to do... but why do we do it? ;-)
12:08:40 <hampton> I think you need -g with other compilers to keep the debugging information in the executable.
12:08:56 <hampton> I don't know, but its pretty common.
12:09:21 <andi5> you mean there are linkers that strip debugging symbols off?
12:10:18 <hampton> I'm thinking that there were such back around 1990, but my memory could be wrong. :-)
12:10:29 <andi5> hehe =)
12:11:05 <hampton> I haven't really used any tool chain other than gcc since then. Before that I was using both the sun and gcc tool chains..
12:13:04 <chris> jsled: why do you think that AC_PROG_CC appends -O2? I don't _think_ it does.
12:13:21 <jsled> It does unless CFLAGS already has anything, apparently.
12:13:37 <jsled> i.e, if CFLAGS is unset, it seems to default to "-g -O2".
12:14:21 <andi5> ack.... chris: what did you mean by "AC_PROG_CC must already preserve CFLAGS"? .... i thought we would want to _ap_pend... hmmm
12:14:36 <hampton> I see I need to get my act in gear and finish testing the "remove group" changes....
12:15:16 <chris> hmm, okay, so it doesn't override the environment, but it provides its own default.
12:15:52 <chris> andi5: I mean that it doesn't undo the effect of the environment's CFLAGS.
12:17:06 <chris> jsled: just an idea: check for --enable-debug _before_ AC_PROG_CC?
12:17:33 <jsled> except, AC_PROG_CC will then add -O2 back in...
12:17:51 <jsled> Oh, unless it sets it to -O0 explicitly.
12:17:52 <chris> if CFLAGS is unset, add _your_ default.
12:22:10 <andi5> cannot we use ac_test_CFLAGS to check whether CFLAGS was empty or not?
12:22:43 <andi5> or even better: ac_save_CFLAGS :)
12:23:12 <andi5> (one should check whether these variables change over time ;-))
12:24:16 *** |gunni| has joined #gnucash
12:26:36 <jsled> Well, I have a version that extracts any r'-O.' from environment CFLAGS, then (if enable-debug) strips r'-O.' and adds $USER_OPTIMIZATION back in.
12:27:37 <jsled> <http://pastebin.ca/322691>
12:28:12 <jsled> (except w/o the 'echo', of course.)
12:37:05 <chris> jsled: I don't get it. In the case where there was a USER_OPTIMIZATION, AC_PROG_CC will respect it. You don't have to have to do anything.
12:38:13 *** earlNameless has joined #gnucash
12:38:13 <chris> you only care about what happens when CFLAGS is completely empty, right?
12:39:23 <jsled> I care that there's not unrequested -O.s; empty CFLAGS happens to correlate with that.
12:39:42 <jsled> (b/c of AC_PROG_CC)
12:40:32 <jsled> So, yeah, rather than being conditional, it just is overly aggressive. Save $user_request; strip blindly; add $user_request;
12:43:18 * chris shrugs.
12:43:50 <chris> seems heavy-handed to me. but it should work, and it respects the environment.
12:44:00 <chris> so, fine with me.
12:45:31 <chris> Of course, if you're really worried about random pollution of CFLAGS, it'd be better to do this much later.
12:51:01 <earlNameless> when I do file->import->log file, gnucash plays the log file, and then hangs (gui unresponsive); is there some long operation it is doing, or should i be doing something special?
12:51:41 <earlNameless> (using 1.8.11; using gentoo, so upgrade to newest version will take >=6 hours)
12:52:16 <jsled> you sould totally upgrade to 2.0.x
12:52:24 <chris> earlNameless: what does 'top' say?
12:52:49 <jsled> in particular, there were import log files in 2.0.x
12:53:58 <earlNameless> jsled: in progress of upgrading, downloading package 38 of 54 that are required for upgrade
12:54:39 <chris> jsled: s/files/fixes/ ?
12:54:57 <earlNameless> chris: Debug: process_trans_record: process_trans_record(): Record ended
12:55:12 <earlNameless> chris: nevermind, i am a moron hold on
12:56:11 <jsled> fixes, yes. like serious, data-file corrupting fixes.
12:56:22 <MrN> earlNameless: if you have such a friggin slow box, consider using something different than gentoo
12:56:41 * chris waits for earlNameless to stop being a moron... dum de dum dum...
12:57:18 <earlNameless> chris: guile taking up 94% of cpu
12:57:32 <chris> earlNameless: ah... better let 'er cook.
12:57:58 <earlNameless> MrN: it is not a slow box, it worked, so i did not upgrade in past 4 months, so now have to upgrade a lot of dependencies
12:58:05 <chris> but, still consider upgrading.
12:58:40 <MrN> earlNameless: heh. well, still you might consider using something different. i once used gentoo myself and now think that all this compiling is wasted time. whatever :D
12:58:42 *** twunder has joined #gnucash
12:59:11 * earlNameless currently doing fetch of packages required for upgrade to 2.0.1 (latest in gentoo)
12:59:23 *** rearnsha has joined #gnucash
13:00:06 <earlNameless> MrN: might be a waste of time, but it forces you to know how your system is setup much more; when i used mandrake and something would break i would just reinstall, in gentoo i actually try to fix it
13:00:42 <MrN> earlNameless: well gentoo is great for learning linux, that's true
13:02:49 <earlNameless> chris: i stopped being moron, top says that guile is taking all of cpu use
13:03:16 <earlNameless> chris: should i just let it sit there? and see what happens
13:04:38 <earlNameless> MrN: yah, recompiling the kernel is not voodoo (seemed that way in mandrake)
13:07:14 * andi5 does not compile kernels any more (but using 2.6.20 nonetheless)... that bit of extra speed is really compensated my time saved (ok, maybe you have better reasons to do it)
13:08:11 <chris> earlNameless: yeah, that log import is notoriously slow, but it's probably making progress.
13:09:14 <earlNameless> chris: ok, thanks; i'll let it sit there; at the beginning I saw number change in the accounts page; but now the entire window is just gray and white (solid colors)
13:10:42 <earlNameless> andi5: if you recompile it, you can also customize it more; since my machine is not a server, i am using file scheduled that splits time equally between all processes, so i can listen to music while root is unpacking huge files
13:11:49 <andi5> earlNameless: i cannot remember the last time my music stopped playing because of anything ;)
13:12:21 <rearnsha> I've just tried to upgrade from gnucash-1.8.12 to gnucash-2.0.3 and now gnucash is crashing every time I try to enter anything in the register.
13:12:39 <andi5> rearnsha: distro?
13:12:47 <rearnsha> NetBSD
13:12:52 <earlNameless> chris: ok, it is done now, took 7 minutes of cpu time; i'll let it sit there from now :)
13:12:52 <rearnsha> standard pkgsrc build
13:13:05 <andi5> rearnsha: do you have a good stacktrace to pastebin?
13:13:12 *** Gnucahier has joined #gnucash
13:13:23 <rearnsha> Not really, the build system strips all the libraries
13:13:35 <Gnucahier> Hi all..
13:13:40 <andi5> arrgh... anything printed to the terminal?
13:14:17 <Gnucahier> Wow .. this channel looks busy, great.
13:14:18 *** gander has joined #gnucash
13:14:51 <rearnsha> bug-buddy says its in gnc_default_share_print_info, but I'd take that with a pinch of salt.
13:15:13 <Gnucahier> Is there a way to change the lettertype or size for the invoices ( not the html )
13:15:15 <earlNameless> andi5: the only time i had it happen was when i was upgrading system, which resulted in a lot of harddrive accesses by root, which had higher priority than my mp3 player, causing music to studder
13:15:51 <Gnucahier> If i print them the lettertypes are terribly big.
13:16:00 <chris> rearnsha: can you coerce the build system (ports?) to not strip the symbols?
13:16:09 <Gnucahier> Anyone?
13:16:22 <andi5> Gnucahier: see the topic :)
13:16:26 <rearnsha> chris: I'll have to do some poking around
13:17:03 <Gnucahier> mmmk idd
13:17:51 <andi5> hm... i do not know whether we have a solution to "font sizes are too big on print" now.... *does not print*
13:19:59 <andi5> Gnucahier: i can only say: we use gnomeprint and do not do anything spectacular... maybe you can find something in the ml archives via lists.gnucash.org/search
13:20:01 *** motin has quit IRC
13:22:20 *** slicslak has joined #gnucash
13:23:08 <Gnucahier> Ok, at least i am able to print. :) But with gnomeprint you've got a standard printing size? The standard size used now is to big, i will try to search. The font printed on the screen is fine, but when we print we do get a too large size.
13:23:52 <slicslak> 2.0.2 crashes on startup. i have the backtrace. what should i do with it?
13:27:46 <earlNameless> chris: thanks for the help
13:28:53 <chris> earlNameless: yw.
13:29:33 <chris> slicslak: pastebin it first.
13:29:50 <Gnucahier> Which option in gnomeprint will change the print output font and size?
13:30:57 *** motin has joined #gnucash
13:30:59 <andi5> Gnucahier: if there was some obvious we would have changed it already :-)
13:32:19 <Gnucahier> :-) Too bad..
13:36:47 <slicslak> chris, gentoo, gnucash 2.0.2, on startup, every time. http://pastebin.com/863680
13:37:01 <Gnucahier> thanks for the help
13:38:58 <andi5> slicslak: downgrade slib
13:40:37 <slicslak> andi5, to what?
13:41:11 <andi5> hm.... 3a3 or so... i am sorry, i cannot check right now... there are some posts about it, in bugzilla and some mailing list
13:41:25 <chris> this should be in FAQ if it's not.
13:41:43 <andi5> has anyone checked whether the bug may be gnucash's?
13:42:29 <slicslak> andi5, right, ok, i'll check
13:44:24 *** andi5 has quit IRC
13:50:42 *** motin has quit IRC
13:51:42 <jsled> slicslak: http://wiki.gnucash.org/wiki/Gentoo#Early_2007_problems_with_guile.2C_slib.2C_g-wrap_and_gnucash
13:51:52 <jsled> What version of guile, g-wrap and slib are you running?
13:54:16 <MrN> i was told that gnucash refocused on C instead of Scheme. will the guile dependency be eliminated entirely, eventually?
13:54:43 <jsled> MrN: "refocused"? I think it will eventually be eliminated, yes.
13:55:00 <jsled> It's probably on the order of years, though.
13:55:07 <MrN> 3.0 or something?
13:55:17 <MrN> are you really about to replace all scheme with C?
13:55:38 <jsled> "about to"? No. I'd like to, yes. The big question right now is the reports.
13:55:50 <jsled> s/question/scheme-user/
13:56:38 <jsled> I'd like to revise the report subsystem, in part to allow them to be defined in something besides scheme, then migrate the reports over to whatever that is.
13:59:13 <MrN> hmm... perl would be ok as you already depend on it, wouldn't it?
14:00:25 <jsled> We don't really depend on perl. I'd personally rather it was python. That'll be a very interesting dev discussion. :)
14:01:39 <MrN> so you're a C/Python freak? :P
14:02:34 <MrN> well i guess that Gnucash Report Description Language would be the least controversial choice :)
14:02:37 <jsled> not particularly. day job is java. I like python. I do C, obviously, but have no real love for non-managed languages, at this point.
14:03:04 *** minDscrm has quit IRC
14:03:17 <MrN> well having no love for C is understandable *ducks*
14:05:52 <jsled> :)
14:06:08 *** wizkid238 has quit IRC
14:06:31 <MrN> the problem is that other languages tend to be more controversial
14:06:50 <MrN> the real problem being that many people don't have my opinion
14:10:59 *** twunder has quit IRC
14:11:13 *** minDscrm has joined #gnucash
14:19:58 *** warlord-afk is now known as warlord
14:20:05 <warlord> FWIW, I'm not a fan of python.
14:20:50 <warlord> For reports I'd much rather see something like eguile where reports are actual HTML templates that get executed.
14:25:45 <jsled> we could do that with any language; and it's good to separate the "report data generation" from the "html formatting".
14:26:05 <jsled> via some intermediate data-structure.
14:27:34 <jsled> It seems like ruby is about in the same boat as python. perl is widely known, widely-available, and basically as simple; it's probably the best choice.
14:27:57 <warlord> True. It would be best to have an intermediate (XML?) format from the generator, and then some XSLT+CSS for the output/display
14:27:59 <MrN> and finance::quote uses it
14:28:12 <warlord> I would not object to perl..
14:28:39 <jsled> MrN: yeah, though our dependence on F::Q is more data-focused: we spawn it, and it returns a s-expr.
14:28:58 <jsled> we don't care that it's perl or C#.
14:29:00 <MrN> perl is not a great language. but it's quite ok.
14:29:28 <MrN> do you have a c-parser for the s-expr?
14:30:27 <warlord> No, i think it's done in scheme.
14:30:47 <warlord> actually, it might be done in C (via libguile) ;)
14:31:13 <MrN> but it's primarily used by C-code?
14:31:53 <warlord> "it" == what in this context? the s-expr? or price quites?
14:32:00 <warlord> quotes evem
14:32:01 <warlord> even
14:32:04 <warlord> GRR..
14:32:24 <earlNameless> if you make xml intermediate format, most languages have xml parsers, so it should be fairly easy to access them in any language
14:32:28 <MrN> the quotes
14:34:14 <jsled> or json.
14:34:53 <jsled> Really, though, I'm not sure it needs to be either serialization.
14:35:11 *** Gnucahier has quit IRC
14:35:17 <jsled> (heh)
14:35:43 <jsled> So much as just an in-memory data strcuture.
14:35:50 <jsled> structure, even.
14:35:56 <MrN> well... that'd not be language-neutral :)
14:36:06 <jsled> no, it'd be language neutral, via swig.
14:36:13 <jsled> So long as that was the agreement.
14:36:51 <jsled> I mean, there's a pretty standard set of basic data types, right now. primitves, lists, dictionaries.
14:36:51 <MrN> so it'd be a c-managed data structure used by all them languages
14:37:08 <jsled> I don't know about all-them. I think we should choose one for the reports.
14:37:38 <jsled> I mean, we only want to write gnucash code to evaluate one language, not any.
14:38:34 <jsled> in which case, it doesn't necessarily *need* to be language neutral, let alone XML/JSON. But there's no call to use any perl-specific mumble...
14:42:01 <jsled> The report-"core" should generate a data-structure (that could be serialized to a language-indep. format, though it probably isn't), and the report-"template" should simply operate over that structure (conditionals, iteration, &c.) to emit text (probably html, maybe xml)
14:42:37 <MrN> well and graphics
14:43:01 <MrN> you could use SVG for that.
14:43:22 <jsled> yeah, good point. we do that now with <object data="1,2,3" /> tags.
14:43:58 <jsled> I'd rather the reports didn't emit svg in particular. AT the same time I think they should emit html in particular. :)
14:44:18 <MrN> PDF would be nice to export
14:44:21 <MrN> maybe latex?
14:44:26 <jsled> oh god.
14:44:28 <jsled> no.
14:44:50 <warlord> Not latex.
14:44:54 <warlord> (except, maybe, for invoices)
14:44:55 <MrN> heh
14:45:15 <warlord> And as for pdf -- the html-viewer should be able to "print to PDF"
14:45:42 <jsled> Yeah. It feels like html + css + a good html component (gecko) should get us a suitable PDF.
14:45:48 <MrN> but if you use html, you really should go for SVG or some vector graphics stuff
14:45:53 <jsled> And we should probably be able to export SVG.
14:45:58 <jsled> And GOG will create SVG for us.
14:46:17 <earlNameless> i am a developer by trade, so this discussion has peaked my interest; are report-"templates" part of the gnucash code? (or can they be executed as standalone programs)
14:46:19 <MrN> gecko supports displaying svg afaik
14:46:35 <jsled> But the form we have now -- where the report emits an <object/> with the data points, that's rendered by gnucash into the right output format (pixbuf, png, svg) isn't bad.
14:47:06 <MrN> you have html intermixed with gnucash:object?
14:47:10 <jsled> earlNameless: reports right now are scheme scripts that both iterate over the data and emit html; they can't really be run stand-alone.
14:48:06 <jsled> Not <gnc:object>, just <[html:]object classid="gnc:..." /> (I think). The gtkhtml calls us back as per registration for those object classes.
14:48:44 <jsled> earlNameless: They bind against the g-wrap-exposed API over the engine and application APIs.
14:49:07 <earlNameless> jsled: ok, thanks; the discussion makes more sense now :)
14:49:21 <MrN> jsled: i see. so you generate (more or less) compliant html. not bad.
14:49:47 <jsled> MrN: less than more; our html emission is sub-optimal, and gtkhtml sucks.
14:50:06 <MrN> well not like gecko doesn't suck :)
14:50:09 <warlord> gtkhtml sucks royally
14:50:17 <jsled> MrN: Though, this was developed pre-html4 and pre-CSS, so some of it's excusable.
14:50:20 <warlord> gecko is at least more HTML-compliant.
14:50:22 <MrN> but it's probably better
14:50:42 *** Gnucashier has joined #gnucash
14:50:51 <MrN> good html renderer are indeed rare
14:51:14 <warlord> Of course, there's no "gecko-devel" package... One needs to pull in mozilla to get it. :(
14:51:48 <MrN> would cairo be an appropriate "output language"?
14:51:48 <Gnucashier> http://liferea.blogspot.com/2006/10/solving-font-problems.html Maybe this will help
14:51:59 <Gnucashier> setting the font-size.
14:53:39 <warlord> Hmm, that talks about gtkhtml-2, not gtkhtml-3
14:55:10 <jsled> MrN: I don't think so. I mean, goffice/gtk will use cairo to render images, if we like ... but I don't think there's a application/cairo or anything..
14:55:40 <jsled> MrN: But I'm not immersed in that stuff; there might well be!
14:55:44 <MrN> jsled: you depend on goffice?
14:56:05 <jsled> MrN: we do, yes. We use GOG for graphing in place of Guppi.
14:56:41 <jsled> (biaw)
14:56:54 <MrN> *scratch head*
14:57:50 <warlord> MrN: what are you confused about?
14:57:54 *** wizkid238 has joined #gnucash
14:59:30 *** mnoir has joined #gnucash
14:59:48 <MrN> well i'm...
15:00:04 <MrN> stunned
15:00:06 <rearnsha> sigh! I've just managed to rebuild gnucash with -O0 -g, and now it crashes as soon as I try to open a transaction register...
15:00:33 <rearnsha> #0 0xbb9bf1be in block_picker_signals (cell=0x9294700) at datecell-gnome.c:270
15:00:38 <MrN> warlord: using an office suite for graphing... sounds a bit insane
15:01:03 <rearnsha> box is set to -1
15:02:05 <warlord> MrN: it's GOG == Gnome Office Graphics.
15:02:20 <warlord> rearnsha: can you pastebin the full stack trace
15:02:32 <warlord> rearnsha: and what version of gnucash is this?
15:02:42 <rearnsha> 2.0.3
15:03:47 <warlord> Gnucashier: I dont know if we actually put a font name/size into a style..
15:04:18 <rearnsha> warlord: http://pastebin.com/863733
15:05:39 <warlord> MrN: it's not insane at all. Now, writing a graphics library from scratch instead of using an existing graphics library, now THAT would indeed be insane!
15:05:39 *** twunder has joined #gnucash
15:05:59 <warlord> rearnsha: try upgrading to 2.0.4?
15:06:18 <MrN> warlord: there are other graphics libraries that are not a whole office suite? :)
15:06:25 <rearnsha> Not trivial, since this is all built through the NetBSD package system.
15:06:46 <rearnsha> Is this a know problem, or just a 'have you tried?'
15:07:34 <rearnsha> Oddly, this problem doesn't occur with a non-debug build :-(
15:09:36 <warlord> rearnsha: I haven't tried, but 2.0.3 is a known-buggy release.
15:09:55 <warlord> MrN: libgoffice isn't a whole office suite.
15:10:26 <MrN> warlord: hmm probably i was just shocked by the name.
15:10:36 <warlord> MrN: you seem very easily shocked.
15:10:46 <MrN> you too :)
15:11:22 <warlord> only at you! ;)
15:15:15 <Gnucashier> Okay i am still searching for setting my print size in gnucash ( the invoice print )
15:15:37 <warlord> Gnucashier: searching where?
15:15:53 <warlord> I think the issue is that we dont actually set font name/size in the generated html
15:16:28 <Gnucashier> Okay i understand, but i mean the font's for the interface seem to be different then the printed fonts.
15:17:55 <warlord> Well, can you change the visible font?
15:18:09 <warlord> (if so, then the problem is gtkhtml/gnomeprint)
15:18:12 <Gnucashier> Yes..
15:18:24 <Gnucashier> libgtkhtml/document/htmldocument.c (html_document_class_init): Add the gtkhtml-minimum-font-size
15:19:01 <Gnucashier> More on http://cia.navi.cx/stats/project/gnome/gtkhtml2
15:19:23 <chris> rearnsha: with the non-debug build it didn't start at all, right?
15:19:44 <rearnsha> chris: No, it got further...
15:20:20 <rearnsha> I wonder if there's some form of pthread race going on. WIth some single stepping it is now going ok...
15:20:23 <rearnsha> weird stuff.
15:20:59 <warlord> i'm not sure what threads.. gnucash isn't multi-threaded
15:21:20 <warlord> Gnucashier: thats gtkhtml2.. thats not gtkhtml3, which is what we use.
15:21:30 <rearnsha> warlord: maybe not, but some parts of the gnome stuff are.
15:21:58 <rearnsha> at least, the app has been linked with pthreads code, I'm seeing it in functiosn within that
15:27:31 *** ErKa has quit IRC
15:28:36 <warlord> rearnsha: unfortunately none of the devs use *BSD
15:28:43 <warlord> so it's not well-tested there.
15:29:20 <chris> rearnsha: you said box == -1, right?
15:29:26 <rearnsha> yes
15:29:52 <rearnsha> It's looking to me like some memory corruption in the date parsing code
15:29:56 <chris> Gnucash only sets that value once, (all other times are set to NULL).
15:30:31 <rearnsha> The Cell value gets corrupted
15:30:32 <chris> and it's right after being dereferenced. In combocell-gnome.c:151
15:31:02 <rearnsha> In fact, in this case it seems like its the pointer to the cell itself.
15:31:09 <rearnsha> (that gets mashed)
15:32:01 <chris> it's definitely something getting corrupted.
15:32:45 <warlord> chris: we need your register rewrite. ;)
15:33:08 <chris> warlord: I know.
15:33:55 <chris> rearnsha: this is probably something particular to your setup. Do let us know if you find out what.
15:36:07 <rearnsha> Is there a way of hooking gdb into the startup process (so that I don't have to try and catch a particular pid before things go wrong?)
15:39:13 *** Gnucashier has quit IRC
15:51:10 *** sjc has joined #gnucash
15:51:34 <warlord> rearnsha: "gnucash-env gdb gnucash-bin"
15:51:53 <rearnsha> Ta!
15:54:33 <rearnsha> The corruption is occuring in g_spawn_command_line_sync -- don't ask me why!
15:55:40 <rearnsha> Hmm, maybe not. But it is somewhere in libglib-2.0.so
15:55:44 *** |gunni| has joined #gnucash
15:55:51 *** |gunni| has quit IRC
15:55:59 <rearnsha> part of the g_vsnprintf code at a guess
15:57:21 <warlord> rearnsha: are you on x86 or a 64-bit platform?
15:57:29 <rearnsha> 32-bit
15:58:15 <rearnsha> Hmm, how big is DATE_BUF supposed ot be?
16:00:48 <rearnsha> Aha! DATE_BUF=30. the len value passed to snprintf is 31!
16:00:55 *** earlNameless has quit IRC
16:01:05 <warlord> That seems broken.
16:01:15 *** rouven has joined #gnucash
16:01:15 *** twunder has quit IRC
16:02:27 *** twunder has joined #gnucash
16:02:55 <rearnsha> Indeed, the lenght value passed to qof_print_date_dmy_buff is MAX_DATE_LENGTH, which is 31
16:04:19 <warlord> Where is the buffer defined?
16:04:44 <rearnsha> gnc_date_cell_set_value_internal
16:05:08 <rearnsha> datecell-gnome.c:668
16:05:19 <rearnsha> or thereabouts
16:06:59 <warlord> Yeah, looks like DATE_BUF needs to change from 30 to 32.
16:07:27 <rearnsha> More precisely, shoudn't it be MAX_DATE_LENGTH + 1?
16:07:53 <warlord> Yeah, but is MAX_DATE_LENGTH defined here?
16:07:59 <warlord> Anyways, try it and see..
16:08:11 <warlord> if it fixes it, file a bug report with the diff.
16:08:14 <warlord> I gotta run
16:08:16 *** warlord is now known as warlord-afk
16:10:36 *** cortana has quit IRC
16:30:20 *** twunder has quit IRC
16:44:19 *** rouven has quit IRC
16:56:39 <prock> trunk//lib/libgnc-backend-file-utils.so.0: undefined reference to `gnc_book_set_schedxactions'
16:57:40 <slicslak> jsled, slib-3.1.4 and slib-3.1.1 both showed the same issue so I hardmaked both of them (thanks andi5!). this brought in dependencies g-wrap-1.3.4-r1, slib-2.4.6 and guile-1.6.7 which fixed the problem.
17:05:51 <jsled> slicslak: huh. I've seen slib-3.1.1 work (I'm using it right now); and it only works (so far) with guile-1.6.7. I wonder if g-wrap-1.3.4-r1 isn't playing nicely with slib-3.1.1.
17:11:09 <slicslak> jsled, from what i can see, it looks like my gwrap version hasn't change through all of this. slib-3.1.1 didn't require anything different, only slib-2.4.6 required the lower version of guile, guile-1.6.7. i wonder if i could have fixed it then by just using guile-1.6.7. <shrug> back go coding!
17:11:23 <slicslak> go = to
17:11:29 <jsled> slicslak: oh, you were using guile-1.6.8?
17:12:23 <jsled> Yeah, I think you'd be able to go to slib-3.1.1, now, though you'd have to rebuild gnucash. But if you quickpkg both, at least you can quickly *revert* if things don't work. :) If you have the time, it'd be a great other datapoint.
17:21:04 <jsled> prock: did you resolve that?
17:24:51 <prock> have to go I'll look at it later.
17:26:27 <jsled> gncbot: tell prock the general form of the solution is "add an explicit reference to the library containing the missing symbol to the link line for the module". Though I notice in src/backend/file/Makefile.am that there's a missing "${top_builddir}" ... that might be it. I'm not sure from your message what dir the error was in.
17:26:27 <gncbot> jsled: The operation succeeded.
17:31:06 *** vnx has joined #gnucash
17:48:32 *** Demitar has quit IRC
17:48:45 *** Demitar has joined #gnucash
18:13:31 *** gander has quit IRC
18:16:10 *** vnx has left #gnucash
18:42:57 <slicslak> jsled, yes, guile-1.6.8. sure, i have emerge nice=15 so it doesn't bother me. :-) just recompiled; guile-1.6.7 + slib-3.1.1 also work fine
18:56:26 <jsled> slicslak: good; thanks for the confirmation. :)
19:48:05 *** andi5 has joined #gnucash
19:48:06 *** gncbot sets mode: +o andi5
20:05:01 *** jpeach has joined #gnucash
20:22:35 *** jpeach has quit IRC
20:31:42 *** jpeach has joined #gnucash
20:32:29 *** jpeach has left #gnucash
20:32:54 *** mnoir has quit IRC
21:02:31 *** andi5 has quit IRC
21:07:51 *** xai has joined #gnucash
21:17:22 *** xai has quit IRC
21:20:19 *** sjc has quit IRC
21:31:53 *** MrN has quit IRC
22:32:08 *** Demitar_ has joined #gnucash
22:42:01 *** warlord-afk is now known as warlord
22:42:09 <warlord> where the hell did someone come up with "gnucash --usage"?
22:42:33 <warlord> (and why does glib/gtk actually print something for that!?!? WTF?)
23:06:35 <hampton> I think its build into g_options, or whatever we're using for option parsing.
23:06:56 * hampton crosses his fingers that the new video card will be supported...
23:08:24 <warlord> Huh. I wonder if we can override it to say something like [[[ What kind of idiot are you? Where did you think "--usage" is anything standard. Trying using "--help" ]]]
23:13:46 <hampton> A HA!!!! Something rewrote my xorg.conf file to use the radeon driver instead of the fglrx driver.
23:13:56 * hampton does a jig. :-) :-)
23:14:00 <warlord> Nice
23:14:03 <warlord> (or not)
23:26:38 *** hampton is now known as hampton2
23:26:45 *** hampto1 has joined #gnucash
23:26:45 *** gncbot sets mode: +o hampto1
23:26:51 *** hampto1 is now known as hampton