2007-02-15 GnuCash IRC logs
00:09:53 *** egsavage has quit IRC
00:10:58 <hampton> gncbot: tell andi5 I'm still around, just not hacking as much.
00:10:58 <gncbot> hampton: The operation succeeded.
00:13:17 <hampton> warlord-afk: The "better solution" for printing may be migrating to the new GTK printing libraries. I haven't had time to investigate, but its been on my list.
00:16:49 <dbr> would newer gtk have anything to do with it? I'm stuck a 2.6.10.
00:18:52 *** vaix has quit IRC
00:25:17 *** dbr has quit IRC
00:37:52 *** jpeach has joined #gnucash
00:46:31 *** rlaager has quit IRC
02:08:22 *** Esaj has joined #gnucash
03:19:59 *** RallyU has joined #gnucash
03:30:12 *** nomeata has joined #gnucash
03:34:32 *** ErKa has joined #gnucash
03:44:46 *** nomeata has quit IRC
04:05:31 *** RallyU has left #gnucash
04:10:33 *** exper_ has joined #gnucash
04:16:34 *** exper has quit IRC
05:30:57 *** exper has joined #gnucash
05:37:52 *** exper_ has quit IRC
05:59:43 *** ErKa has quit IRC
06:27:26 *** egsavage has joined #gnucash
06:55:14 <prock_> so if I'm understanding things correctly: GnuCash has half-implemented modules. There is an interface for g_module, but we also link against the modules and call their functions outside of that interface. Is this accurate?
06:55:21 *** prock_ is now known as prock
07:14:58 *** egsavage has quit IRC
07:15:05 *** egsavage has joined #gnucash
07:31:19 *** ockernerd has joined #gnucash
07:36:17 *** IanL has joined #gnucash
08:07:47 *** twunder has joined #gnucash
08:09:03 *** ockernerd has quit IRC
08:15:28 *** ErKa has joined #gnucash
08:31:30 <chris> prock: that's basically correct.
08:53:26 *** IanL has quit IRC
09:11:39 *** ceplma has joined #gnucash
09:22:35 *** ceplma has quit IRC
09:23:56 *** ceplma has joined #gnucash
09:24:01 *** warlord-afk is now known as warlord
09:24:08 <warlord> prock: basically, yeah.
09:36:10 *** ceplma has quit IRC
10:35:15 *** jpeach has left #gnucash
11:04:57 *** leomburke has joined #gnucash
11:07:47 *** MrN has joined #gnucash
11:08:17 <MrN> hi
11:09:56 *** bonez39 has joined #gnucash
11:12:20 *** AlwaysChanging has joined #gnucash
11:12:34 *** leomburke has left #gnucash
11:15:36 *** ceplma has joined #gnucash
11:32:53 *** AlwaysChanging has quit IRC
11:44:29 *** ceplma has quit IRC
11:46:17 *** ceplma has joined #gnucash
11:58:08 *** andi5 has joined #gnucash
11:58:08 *** gncbot sets mode: +o andi5
12:07:48 <jsled> Wow I should have stretched before shovelling snow at 7:30am. :/
12:08:48 <andi5> lol... well, this winer is pretty snow-less here, i think i have shovelled... once :)
12:14:21 *** bonez39 has quit IRC
12:15:36 <warlord> How much snow did you have?
12:16:30 <jsled> 2 - 2 1/2'
12:16:49 <warlord> Oh. WOW.
12:16:56 <warlord> 2 to 2.5 FEET?
12:17:04 <jsled> yeah. Pics forthcoming.
12:17:12 <warlord> 'k
12:17:57 <warlord> hampton: where does one acquire the "exchange code" for a currency??
12:18:07 <hampton> wow. we had about 3" of sleet
12:18:51 <warlord> BIAB...
12:18:54 *** warlord is now known as warlord-afk
12:19:47 *** ceplma has quit IRC
12:24:02 <hampton> http://www.evertype.com/standards/iso4217/iso4217-en.html
12:24:08 <hampton> http://www.xe.com/iso4217.htm
12:24:19 <hampton> http://www.thefinancials.com/vortex/CurrencyFormats.html
12:28:31 <jsled> http://asynchronous.org/tmp/blizzard-07/
12:28:42 <jsled> (while we're posting links...)
12:29:51 <andi5> jsled: how long did it take to ... move all that snow?
12:30:16 <jsled> about 3 hours, though we traded help with our neighbor across the way for a bit.
12:31:36 <andi5> i like burried-car.jpg.... it could have been anything, including a car :)
12:32:01 <jsled> burried-what-do-you-guess.jpg :)
12:32:50 *** esodan has joined #gnucash
12:36:55 *** andi5 has quit IRC
12:44:50 <prock> nice pics, is this VT?
12:45:30 <jsled> yeah.
12:45:53 *** ceplma has joined #gnucash
12:51:59 *** sjc has joined #gnucash
13:04:21 <jsled> (go prock go! :)
13:12:57 <prock> :)
13:13:27 <jsled> for some context, the module system came in with the last crop of developers, and has been a thorn in our side for years.
13:13:28 <prock> it's hard to write a sx-projection report when I can't compile gnucash...
13:13:49 <jsled> prock: The sticking point might be the reports, which I think were the motivation for some of the modules.
13:13:55 *** warlord-afk is now known as warlord
13:14:06 <jsled> But I have to imagine that there's a better way to solve that problem.
13:14:22 <prock> I don't feel strongly for or against it... but the choice (libraries or modules) needs to be made
13:14:30 <warlord> prock: definitely.
13:14:47 <warlord> I suspect that MOST of the "modules" can/should be changed back to just plain libraries..
13:16:01 <prock> my biggest dislike of modules is that it will make some programming mistakes show up at runtime instead of compile time.
13:16:24 <prock> but a nice module interface opens up the door for plugins, which would be cool.
13:17:46 <warlord> That's not completely true.. You can still get compiler warnings from modules.
13:18:28 <prock> yes, but not all that you would if we were linking at compile-time.
13:20:09 <warlord> For the record, I'm with hampton, not jsled.
13:20:16 <warlord> I think having runtime modules is a GOOD thing..
13:20:40 <warlord> But we need a much cleaner line between what's a module and what's a library.
13:20:52 <warlord> For example, I DEFINITELY think that the importers and backends should remain modules..
13:21:13 <jsled> Why? What's the point, if we're not making use them as such?
13:22:47 *** ErKa has quit IRC
13:26:59 <warlord> Packagers make use of them as such!
13:27:19 *** ceplma has quit IRC
13:27:19 <warlord> c.f. gnucash-ofx, gnucash-hbci, gnucash-backend-postgres, ...
13:27:39 <jsled> ah. The inferior distro problem. :) Good point.
13:27:48 <warlord> :-P
13:28:06 *** ceplma has joined #gnucash
13:30:02 <prock> hmm... does GnuCash not use modules effectively because the implementation is lacking or is the implementation lacking because GnuCash doesn't need modules?
13:30:21 <jsled> yes.
13:30:28 <prock> :)
13:30:50 <jsled> Certainly app-utils doesn't need to be a module. As warlord points out, the importers -- and to a lesser extent the backends -- do.
13:30:54 <warlord> I think it doesn't use modules effectively because the designers of the module system didn't really think hard about what it would mean to modularlize gnucash.
13:34:47 *** cliff has joined #gnucash
13:37:17 *** cliff has quit IRC
13:37:50 *** ceplma has quit IRC
13:52:19 *** ceplma has joined #gnucash
14:06:42 *** ceplma has quit IRC
14:11:46 *** ceplma has joined #gnucash
15:02:42 *** xoloki has joined #gnucash
15:03:10 <xoloki> hi everyone
15:03:20 <xoloki> i'm getting a crash on a fresh install of gnucash on linux
15:03:26 <xoloki> here's the terminal output:
15:03:33 <xoloki> jyandle@xoloki:~ $ gnucash
15:03:33 <xoloki> Backtrace:
15:03:33 <xoloki> In current input:
15:03:33 <xoloki> 1: 0* [gnc:report-menu-setup]
15:03:33 <xoloki> ?: 1 (letrec (# # # ...) (gnc:add-extension income-expense-menu) ...)
15:03:34 <xoloki> In /usr/share/gnucash/guile-modules/gnucash/report/report-gnome.scm:
15:03:36 <xoloki> 118: 2* [gnc:hook-run-danglers "hook_report" . #f]
15:03:38 <xoloki> In /usr/share/gnucash/scm/hooks.scm:
15:03:40 <xoloki> 22: 3 [gnc:hook-run-danglers-real "hook_report" #f]
15:04:06 <jsled> xoloki: http://www.google.com/search?hl=en&q=gnucash%20backtrace%20report-menu-setup&btnG=Google+Search
15:04:16 <warlord> xoloki: g-wrap 1.9.7 is broken. Remove that, install 1.9.6, and rebuild gnucash.
15:04:29 <xoloki> sweet, thanks
15:04:43 <warlord> http://wiki.gnucash.org/wiki/FAQ#Q:_What_does_it_mean_when_GnuCash_.28built_with_g-wrap-1.9.7.29_crashes_with_an_error_about_a_wrong_type_of_argument_in_hook-run-danglers-real.3F
15:04:46 <jsled> xoloki: what distro?
15:05:51 <xoloki> jsled: RHEL 4
15:07:10 <warlord> xoloki: did you build it yourself or use Bill's packages?
15:07:50 <xoloki> built it and g-wrap myself, all deps installed as binaries
15:08:40 <warlord> Well, you know what you need to do now.
15:08:44 <warlord> But this IS in the FAQ.
15:09:31 <xoloki> thanks... i did check bugzilla, you should probably have a bug there
15:09:45 <warlord> Why? It's not our bug.
15:10:25 <warlord> Besides, our use of g-wrap is EOL'd. trunk doesn't use g-wrap anymore.
15:11:14 <xoloki> fair enough
15:11:37 <warlord> Still, it's in the FAQ..
15:11:47 <warlord> The FAQ exists for a reason!
15:27:16 *** andi5 has joined #gnucash
15:27:16 *** gncbot sets mode: +o andi5
15:28:22 *** xoloki has quit IRC
15:57:32 *** benoitg has joined #gnucash
16:23:00 *** ceplma has quit IRC
16:27:15 *** esodan has quit IRC
16:32:37 *** bock has joined #gnucash
16:32:37 *** benoitg has quit IRC
16:53:56 *** andi5 has quit IRC
16:53:56 *** exper has quit IRC
16:53:56 *** wizkid238 has quit IRC
16:53:56 *** cortana has quit IRC
16:53:56 *** Geot has quit IRC
16:53:56 *** BC^bd has quit IRC
16:53:56 *** conrad has quit IRC
16:53:56 *** slicslak has quit IRC
16:53:56 *** rhowe has quit IRC
16:53:56 *** mishehu has quit IRC
16:53:56 *** aj has quit IRC
16:54:49 *** twunder has quit IRC
16:56:23 *** conrad has joined #gnucash
16:56:23 *** exper has joined #gnucash
16:56:23 *** wizkid238 has joined #gnucash
16:56:23 *** cortana has joined #gnucash
16:56:23 *** rhowe has joined #gnucash
16:56:23 *** mishehu has joined #gnucash
16:56:23 *** aj has joined #gnucash
16:56:23 *** slicslak has joined #gnucash
16:56:23 *** BC^bd has joined #gnucash
16:56:23 *** Geot has joined #gnucash
16:56:23 *** irc.acc.umu.se sets mode: +o conrad
16:56:23 *** gncbot sets mode: +o conrad
16:59:39 *** esodan has joined #gnucash
17:02:00 *** egsavage has quit IRC
17:03:23 <esodan> Hi all, I have a question, on SX-book.c file in line 81, use qof_collection_set_data and get_data to store SchedXactions in that collection, but...
17:03:44 *** egsavage has joined #gnucash
17:04:00 <esodan> QofCollection do nothing to free this data... :-$
17:04:18 <jsled> esodan: That's not a question... :)
17:04:29 <esodan> call do col->data = NULL
17:04:49 <esodan> jsled: :)
17:05:37 <esodan> I see its dangerous to use this function as is even, I think we have momory leaks here...
17:05:47 <jsled> esodan: probably.
17:06:27 *** Esaj has quit IRC
17:07:16 <esodan> jsled: in SX-book.c, line 200 you g_new a SchedXactions, but any place in the code you free it... and ofcourse QofCollection doesn't... :-$
17:07:18 <warlord> I would say put an "XXX FIXME" comment on it now and move on, we can change it later.
17:09:02 <esodan> Now for me (;)) QofCollection is an object and I can #define this to g_object_set_data function, and even better use g_object_set_full to call a function to custom free this data...
17:10:04 <MrN> being anti-productive again: i stopped using "XXX" since i googled for it when i was like 12
17:10:07 <esodan> This now I'll file a bug...
17:10:22 <jsled> esodan: there's no need to file a bug. Just put a comment in the code.
17:10:33 <jsled> esodan: I'm sure there's lots of memory leaks; it's not useful to file a bug for each one.
17:11:18 <jsled> I've never been thrilled with the way SchedXaction(s) are stored relative to the book. It's always seemed weird.
17:11:46 <jsled> And I don't know why it'd be g_object_set_data'ed in ... it should be a normal member field.
17:11:53 <jsled> book->sched_xactions or whatever.
17:12:17 <esodan> for my work I'll change this function to use g_object_set_full to be sure the SchedXactions will be destroied...
17:12:36 <jsled> esodan: does the code compile, yet? That's way more important.
17:12:43 <warlord> jsled: I think that short-term we should try to keep as close an API to existing QOF as possible..
17:12:58 <jsled> True true. My comment was more of an aside.
17:13:00 <warlord> Which means using the existing qof_book_set_data() APIs.
17:13:19 <esodan> Working...
17:13:20 <warlord> esodan: again, you shouldn't be making changes outside of lib/libqof/qof until the code compiles.
17:14:30 <esodan> warlord: I can't now... my changes will create the basic structure for GObject in all the GC's objects, and modify realy just a few lines of code...
17:14:47 <warlord> Daniel...
17:14:51 <warlord> We TALKED about this.
17:14:54 <esodan> I in the last steps to begin the code to compile...
17:15:20 <esodan> Dereck....
17:15:37 <esodan> I can't stop now, I finishing...
17:15:56 <esodan> (sorry Derek)
17:16:14 <esodan> :-P
17:17:19 <warlord> I still think you're biting off WAY too much for the first steps.
17:17:23 <esodan> jsled: warlord: could you file this FIXME coment for me plase... my work will be diferent for the problem in QofCollection data...
17:17:48 <warlord> esodan: put the comment in the code
17:18:51 <esodan> warlord: may be, thats why I stoped to do more changes, I have the basic structure to have GC based in GObject, I just auditing the code to find potencial problems before make this code to compile...
17:19:24 <jsled> esodan: you're going to find infinite potential problems, I'm sure.
17:19:24 <warlord> dont worry about potential problems. There will be problems. And we have many many more steps to get the code fully GObjectified...
17:19:38 <warlord> We'll have to go through the code MANY more times.
17:19:42 <warlord> So dont worry about it now.
17:19:49 <warlord> Just add a comment "LOOK HERE"
17:19:52 <warlord> and move on
17:20:06 <esodan> OK... :-D
17:21:57 <jsled> esodan: so, in terms of the layering we talked about yesterday, did that seem about right?
17:22:40 <jsled> I mean, first getting the objects registered, then converting over the construction, then the destruction...
17:23:45 <esodan> jsled: mmmm... please continue...
17:24:15 *** egsavage has quit IRC
17:24:33 <jsled> esodan: well, I was mentioning this yesterday. It might be a better approach to try to add each "feature" of gobject in sequence, rather than trying to approach the problem a type at a time.
17:25:49 <jsled> The theory being that if you try to fully GObjectify (say) Accounts, then it will force everything else to become fullly GObjectified at the same time...
17:26:17 <jsled> Which will eventually mean you need to make everything fully GObjectified all at onces.
17:26:42 <esodan> For the moment the more GObjectify is QofInstance and QofBook... but that realy don't change any thing...
17:26:57 <esodan> my point in on how the G
17:27:14 <jsled> Rather than the approach we'd like, which is a very progressive addition of each "capability" of GObject... with working milestones in between.
17:27:27 <jsled> It might be you're basically doing the same thing ...
17:27:32 <jsled> ... but it's not sounding like it.
17:27:35 <esodan> QofBook is storing the QofInstances Objects, it has a hash table using string as types...
17:28:12 <esodan> now it use int (a GType)...
17:28:28 <esodan> this is becouse I found some problems in the actual type system...
17:28:34 <warlord> esodan: you're not listening to us.
17:29:34 <esodan> but don't worry I realy finishing it... I have done too much work and the changes doesn't affect too much realy the the code in other objects outside Account or Transaction... see the others...
17:29:35 <warlord> think about this: if it still used the string type, you could make QofInstance a GObject but Account doesn't need to be its own GObject. The "Account" type could still be a string in the QofInstance.. And then you could still use the string hash table... And then you dont have to go change every object to use GType.
17:29:41 <esodan> I just add some code...
17:30:40 <esodan> But this is done now... I just need to finish to auditing the code... with few changes...
17:32:05 <jsled> esodan: For instance. I'd consider adding GError** to the backend begin/commit/rollback handlers to be something in a much later milestone.
17:33:17 <warlord> I'd consider changing anything outside lib/libqof/qof to be something to happen at a later milestone.. But I think it's too late for that.
17:34:13 <warlord> (unfortunately)
17:35:14 <esodan> Realy I think you are right, but yes unfortunately... :-/, but I think will be best (with its problems..) :)
17:35:20 <jsled> warlord: yeah. I mean, he's saying he's past that point, already. Though it'd be nice if the code at that point compiled.... if there was a revision number that one could give that meant "this is the state of the code where "core QOF" is GObjectified, but engine/ is not.
17:35:55 <jsled> "
17:36:04 <esodan> I working to do this code to compile, just wait...
17:36:08 <warlord> No, it's not best, because as jsled said there's not a revision number with with a working milestone.
17:36:58 <esodan> I have stoped to make more changes, I will do this code to compile...
17:38:00 <warlord> Thank you
17:38:01 <esodan> I have to leave for a moment...
17:38:02 <warlord> Gracias
17:38:24 <jsled> Thank you, indeed. I think this will help.
18:15:02 *** ceplma has joined #gnucash
18:15:04 *** egsavage has joined #gnucash
18:21:30 *** MrN has quit IRC
18:27:29 <prock> so is GnuCash a democracy? 2 votes for modules and one against. :)
18:28:03 <warlord> prock: it's more a meritocracy, and I think I've convinced jsled that we need modules (see the irc logs)
18:28:35 <jsled> oh, indeed.
18:28:57 <jsled> Of course, we can all agree that the modules should be pretty different.
18:29:17 <prock> ok, what I've got on my mind then...
18:29:24 <jsled> Each source dir is just a shared lib (or part of one), and the modules are higher level ... backend/file, ofx, hbci.
18:29:42 <warlord> I wonder if "gnome UI" should be a module...
18:30:08 <jsled> (though, again, I think we could just build the file backend into the core by default, and deal with modularizing it when we have another option, later.
18:30:48 <jsled> Maybe ... again, there's no real option there at present, so it's not that compelling as a module.
18:31:13 <warlord> Well, there's still the (old) postgres backend
18:31:42 <jsled> Gotta run to the corner store; biab.
18:31:58 <prock> phew...
18:32:07 <warlord> phew?
18:32:46 <prock> I'm not really that concerned about what is a module or what isn't. I see that as being a later stage.
18:33:59 <warlord> well, at some level we DO need to decide that as we work forward.. That needs to be part of the module architecture/design.
18:34:26 <prock> I think where I see myself starting on this is to turn what gnucash currently considers modules actually into modules (via a lot of symbol lookups at init and then changing the way the symbols are referenced)
18:34:56 <warlord> umm........
18:35:02 <warlord> I dont agree with that.
18:35:09 <prock> ok.
18:35:17 <warlord> First I think you should think about what should be a module and what should be a shared library...
18:35:38 <warlord> Then make the stuff that should be shared libraries, shared libraries.. (and make sure we deal with the library initializations)..
18:35:56 <warlord> Then see where we are.
18:36:09 <prock> Hmm...
18:36:58 <prock> How about this: we figure out what everyone agrees (right now) should be a shared library, and force the module interface on the rest.
18:37:13 <warlord> That's fine...
18:37:40 <prock> My fear is that if we try to get a definite list of "this is a module and this isn't" then I'll never be able to get started.
18:38:29 <warlord> Well, you gotta start somewhere.
18:38:49 <warlord> Just changing register-core and register-gnome into shared libraries is going to introduce interesting initialization issues.
18:39:27 <prock> sorry, got to go eat dinner but I'll review logs and email -devel with the "what should be a module" question this evening.
18:39:35 <warlord> okay..
18:39:41 <warlord> and also ponder the initialization problem.
18:39:46 <prock> ack
18:39:58 <prock> (as in acknowledge)
18:40:01 <warlord> I know
18:43:59 <jsled> prock: I don't think it'll be too hard to come up with the "this is a module" list. But certainly most of the existing modules are actually just shared libraries.
18:45:23 <warlord> yeah, I think most of them are.
19:02:42 <prock> (at a later stage) would it be a good idea to create src/libs and src/modules and move code into them as is appropriate?
19:04:22 <jsled> Maybe, though the current organization by function seems pretty good.
19:05:02 <jsled> Though maybe the top level could be a bit more aligned with the overall modularity.
19:05:33 <warlord> We could consider a code realignment..
19:05:36 <jsled> I guess then it'd look something like src/{core/{engine, app-utils,...}, import-export/{ofx, hbci, ...}, ui/{gnome, ...}}
19:05:46 <jsled> Which, you'll notice, is pretty close to how it is now. :)
19:08:09 <warlord> Yeah.
19:15:34 <jsled> Is there an implied "core" module? I mean ... there's just the core libs that are linked to gnucash-bin (or whatever), which would then load the hbci, ofx, backend-file modules ... but the core itself isn't a module per-se, right?
19:16:20 <warlord> jsled: No, I dont think "engine" needs to be a module..
19:16:50 <warlord> so, no, I dont think there is a "core" module, per se.
19:19:34 <jsled> I'm thinking of "core" as engine + app-utils + core-utils + register-core + reports + calculation + qof + (some things I'm forgetting).
19:20:59 <warlord> I'm not sure about register-core per se.. Well, register-core is clearly a shared-lib, but.... *shrugs*
19:21:21 <jsled> Yeah. A "core" (pseudo-)module.
19:23:09 <prock> ok, so what is a better approach: "Anything that is agreed to be a module will be a module and if there is disagreement then it's a library"? Or the other way around?
19:24:02 <prock> btw, this is the list of modules that I can find: http://paste.debian.net/22040
19:24:10 <prock> does this list look complete?
19:25:46 <jsled> Where's gnucash/gnome ? Or is there one?
19:26:08 <jsled> Or core-utils
19:26:36 <jsled> prock: how'd you "find" that list?
19:27:04 <prock> grep -ri -A5 gnc_module_path src/*
19:27:46 <prock> but I've cscope'd gnc_module_load_optional and gnc_module_load and there are more, as you say.
19:27:47 <warlord> WTF is gnucash/agedver ?
19:28:29 <warlord> I think you're including the test modules.
19:28:52 <prock> yes, they are still modules so...
19:29:15 <warlord> prock: yeah, but......
19:29:33 <warlord> the test system shouldn't need to change, so you can ignore it.
19:29:46 <warlord> (and not ignoring it just adds chaff to the discussion)
19:30:02 <prock> ok, sounds good to me.
19:36:17 *** esodan has quit IRC
19:39:34 <warlord> prock: and thank you for taking to time to deal with the library/modularlization thing..
19:39:48 <prock> thank me when it's done :)
19:39:53 <warlord> ok :)
19:44:07 <prock> hmm I guess that list isn't complete. I'll have a better one soonish.
19:49:58 <prock> hmm no core-utils module
19:50:48 <jsled> hmm?
19:51:36 <prock> this time I've "grep -r gnucash\/ src/* " and have trimmed the output and there's no "core-utils" string to be found
19:52:18 <jsled> Hmm. I guess it isn't. there's a libgncmod-app-utils, but only libgnc-core-utils
19:57:47 <prock> In fact I wasn't far off, here is everything that was in the results of `grep -r gnucash\/ src/*` (trimmed and sorted/uniq'd): http://paste.debian.net/22047
20:13:01 *** twunder has joined #gnucash
20:25:56 *** ceplma has quit IRC
20:33:51 <warlord> prock: you're missing gnucash/backend/postgres
20:35:12 <hampton> should the report system be its own module?
20:35:49 <warlord> I dont know....
20:36:01 <warlord> Part of me thinks that the report-system core should be part of the core application..
20:42:33 <prock> warlord: where is this? I'll look to see how it defines itself and look for any more that define themselves the same way.
20:42:59 <warlord> src/backend/postgres
20:44:35 *** bock has left #gnucash
21:00:28 *** sjc has quit IRC
21:00:38 *** egsavage has quit IRC
21:08:27 *** egsavage has joined #gnucash
21:19:14 *** egsavage has quit IRC
21:19:55 *** egsavage has joined #gnucash
21:27:15 *** bistra has joined #gnucash
21:58:04 *** twunder has quit IRC
22:12:43 *** dbr has joined #gnucash
22:20:36 *** iTarian has joined #gnucash
22:25:40 *** warlord is now known as warlord-afk
22:41:01 *** iTarian has quit IRC
22:43:09 *** rlaager has joined #gnucash
23:23:30 *** egsavage has left #gnucash
23:59:34 *** Wilddev has joined #gnucash
23:59:35 *** gncbot sets mode: +o Wilddev