2013-10-03 GnuCash IRC logs
00:04:50 *** fuzzybunny69y has quit IRC
00:04:53 *** fuzzybunny69y has joined #gnucash
00:37:01 *** GabrieleV has quit IRC
00:37:14 *** GabrieleV has joined #gnucash
00:57:08 *** kpreid has quit IRC
00:58:08 *** kpreid has joined #gnucash
01:42:30 *** fuzzybunny69y has quit IRC
02:44:34 *** ErKa has quit IRC
02:55:43 *** fuzzybunny69y has joined #gnucash
03:46:53 *** fell has joined #gnucash
03:46:53 *** gncbot sets mode: +o fell
04:10:01 *** john has quit IRC
04:23:44 *** TradeBorG has joined #gnucash
04:34:55 *** aqua___ has joined #gnucash
05:58:18 *** nomeata has joined #gnucash
06:18:47 *** aqua_ has joined #gnucash
06:25:33 *** aqua___ has quit IRC
06:31:11 *** Bodhi-Baum has joined #gnucash
06:55:34 *** fuzzybunny69y has quit IRC
07:00:47 *** fell_ has joined #gnucash
07:00:48 *** gncbot sets mode: +o fell_
07:02:50 *** fuzzybunny69y has joined #gnucash
07:05:58 *** fell has quit IRC
07:14:44 *** Jimraehl1 has left #gnucash
07:17:40 *** Jimraehl1 has joined #gnucash
07:34:55 *** aqua__ has joined #gnucash
07:41:54 *** aqua_ has quit IRC
07:44:56 *** aqua_ has joined #gnucash
07:47:56 *** aqua__ has quit IRC
08:19:49 *** gjanssens-afk is now known as gjanssens
08:20:02 *** Topcat has joined #gnucash
08:21:46 *** Bodhi-Baum has quit IRC
08:27:42 *** fell_ is now known as fell
08:35:40 *** Topcat has quit IRC
08:36:04 *** Topcat has joined #gnucash
08:51:08 *** Topcat has quit IRC
08:51:30 *** Topcat has joined #gnucash
08:56:31 *** Topcat has quit IRC
08:56:54 *** Topcat has joined #gnucash
09:01:54 *** Topcat has quit IRC
09:02:17 *** Topcat has joined #gnucash
09:07:16 *** Topcat has quit IRC
09:07:38 *** Topcat has joined #gnucash
09:12:44 *** Topcat has quit IRC
09:13:17 *** Topcat has joined #gnucash
09:18:20 *** Topcat has quit IRC
09:18:43 *** Topcat has joined #gnucash
09:23:45 *** Topcat has quit IRC
09:24:32 *** Topcat has joined #gnucash
09:29:34 *** Topcat has quit IRC
09:29:56 *** Topcat has joined #gnucash
09:34:56 *** Topcat has quit IRC
09:35:35 *** Topcat has joined #gnucash
09:36:07 *** Sk1d has joined #gnucash
09:54:36 *** Topcat has quit IRC
09:55:25 *** Topcat has joined #gnucash
09:56:25 *** fuzzybunny69y has quit IRC
10:19:19 *** Topcat has quit IRC
10:19:41 *** Topcat has joined #gnucash
10:24:41 *** Topcat has quit IRC
10:25:19 *** Topcat has joined #gnucash
10:30:21 *** Topcat has quit IRC
10:30:49 *** Bodhi-Baum has joined #gnucash
10:30:54 *** Topcat has joined #gnucash
10:35:54 *** Topcat has quit IRC
10:36:29 *** Topcat has joined #gnucash
10:39:46 *** ErKa has joined #gnucash
10:44:37 *** benoitg has joined #gnucash
10:49:44 *** Topcat has quit IRC
10:50:29 *** Topcat has joined #gnucash
10:55:29 *** Topcat has quit IRC
10:56:14 *** Topcat has joined #gnucash
11:01:13 *** Topcat has quit IRC
11:01:35 *** Topcat has joined #gnucash
11:16:01 *** Topcat has quit IRC
11:16:35 *** Topcat has joined #gnucash
11:21:37 *** Topcat has quit IRC
11:22:22 *** Topcat has joined #gnucash
11:27:22 *** Topcat has quit IRC
11:27:45 *** Topcat has joined #gnucash
11:30:34 *** aqua_ has quit IRC
11:37:50 *** Topcat has quit IRC
11:38:43 *** Topcat has joined #gnucash
11:48:18 *** benoitg has quit IRC
11:51:16 *** john has joined #gnucash
11:51:17 *** gncbot sets mode: +o john
11:52:08 <john> gjanssens: Geert, have you made any progress with GSettings on MSWin?
11:52:55 <john> It's time for 2.5.6, and I'd like to get GSettings into it.
11:54:02 <gjanssens> Yep, gsettings works on all platforms now, with two remarks
11:54:17 <gjanssens> 1. existing settings are not migrated yet to gsettings
11:54:36 <gjanssens> So starting gnucash now will start anew with default settings
11:54:59 <gjanssens> 2. column visibility/sort order is not saved/restored
11:55:10 <gjanssens> The way it was done now was not compatible with gsettings
11:55:16 <gjanssens> So I have temporarily disabled it
11:55:58 <gjanssens> Would these two limitations be reason to not ship it with 2.5.6 ?
11:56:24 <gjanssens> I don't think I can whip up a conversion script/tool before the weekend.
11:57:21 <gjanssens> IMO it should be ok if we put a big warning in the release message (regarding the preferences)
11:57:29 <john> I wouldn't worry too much about the column settings, but yeah, there should be a way to convert the old settings.
11:57:51 <gjanssens> Before 2.5.6 or before 2.6 ?
11:58:20 <gjanssens> I would think we can do 2.5.6 without the migration and only do it later
11:58:27 <gjanssens> It is still beta after all
11:58:41 <john> If you can do it by monday, we can hold off the release until then.
12:00:50 <john> Does converting the old prefs require GConf support? Can which system is used be made runtime configurable?
12:02:00 <gjanssens> There is a way to migrate prefs that interfaces with gconf
12:02:07 <gjanssens> This comes with recent gconf versions
12:02:16 <gjanssens> And probably only works in linux
12:02:26 <gjanssens> So that's two good reasons to discard this option
12:02:45 <gjanssens> What are you thinking of when you say runtime configurable ?
12:03:31 *** todd has quit IRC
12:03:36 <john> Yes, the last GConf that works on OSX is 2.28 because I haven't been able to get gdbus to work.
12:03:55 <john> I was thinking a command-line switch.
12:04:22 <john> Or better, an env variable.
12:04:40 <gjanssens> And what should be configurable ?
12:04:50 <gjanssens> To run/skip the conversion ?
12:05:39 <john> If the conversion is ready then it's not needed. Otherwise, it would be to select which prefs backend is used.
12:06:27 <gjanssens> Ah, ok. Now I understand your orignal question.
12:06:31 <john> That way users (unlike me) who have heavily-customized gnucash would still be able to get their prefs. Others who don't care much could test out the new prefs.
12:07:31 <gjanssens> Anyway, that will be difficult
12:07:53 <gjanssens> The direct calls to gconf have been completely removed from GnuCash
12:08:06 <gjanssens> They have all been replaced with (indirect) gsettings calles
12:08:13 <gjanssens> s/calles/calls/
12:08:43 <john> OK. So the conversion will have to be a separate program.
12:08:44 <gjanssens> There is a GConf backend for gsettings, which in theory could be used
12:09:12 <gjanssens> But that one also needs a more recent GConf implementation than is available on Windows/OS X
12:09:44 <gjanssens> Yes/no
12:09:59 <gjanssens> I don't intend to use any GConf calls to do the migration
12:10:25 <gjanssens> I only need read-only access to gconf, so I intend to read the xml files directly
12:10:58 <gjanssens> It can be a separate program, it can be implemented somewhere in the gnucash source
12:11:04 <gjanssens> I hadn't decided yet
12:11:32 <john> Does that work on Linux? I thought that the point of GConf using dbus was that the conf stuff could be stored somewhere beside ~/.gconf.
12:12:08 <gjanssens> Maybe, but I still have the .gconf directory in my homedir which is actively used by gconf
12:12:25 <gjanssens> (last update to the dialogs xml file was about half an hour ago)
12:13:09 <gjanssens> So as far as I know, the xml files are still very much in use
12:13:13 <john> Yeah, I suspect that's the general case, but I'm worried about someone actually using the remote feature.
12:13:40 <gjanssens> Of which I have never heard yet ?
12:13:59 <gjanssens> How would that work ?
12:14:57 <john> Probably because you've never had a reason to look at dbus. But maybe GConf is just using it as an overly-elaborate file-locking mechanism. Given Gtk's science-fair nature, that wouldn't surprise me.
12:16:04 <john> DBus is an IPC mechanism that's separately configurable. It has config files in /etc that specify, among other things, where stuff is stored.
12:16:57 <john> There's probably per-user configs as well, but I've never bothered with any of it beyond the bare minimum to make it work on OSX.
12:18:54 * gjanssens is looking in /etc/dbus
12:18:59 <gjanssens> There's a config file for Gconf there
12:19:19 <gjanssens> But it only sets permissions on the debus interface, no paths
12:19:37 <john> Back to reading the raw XML: Gnucash doesn't have an xml parser dependency right now, though we have the somewhat half-baked sixtp stuff in the XML backend. Its API isn't exposed outside of the backend.
12:20:29 <gjanssens> I'll admit I haven't investigated this part much yet
12:20:32 <john> You should have /etc/dbus-1. Try `find /etc -name session.conf`
12:21:27 <gjanssens> Right, /etc/dbus-1 is what I was looking at. My IRC message was incomplete
12:22:03 <john> What about Scheme/Guile. Is there an XML parser for that?
12:24:45 <gjanssens> Google found this: https://www.gnu.org/software/guile/manual/html_node/Reading-and-Writing-XML.html
12:26:07 <gjanssens> But I'm not sure that's any help
12:26:25 <warlord> john: we already depend on libxml which *is* an XML parser.
12:26:27 *** Sk1d has quit IRC
12:26:33 <gjanssens> I was thinking of transforming the xml files using xsltproc
12:26:43 <gjanssens> into a format easily parsed by scheme
12:27:01 <gjanssens> Of course that adds xsltproc as runtime dependency
12:27:02 <john> Derek, we do? (it's libxml2, btw).
12:27:09 <john> What are we using it for?
12:27:09 <warlord> Yes, we use libxml2
12:27:13 <warlord> the XML backend
12:27:43 <john> No, we have our own parser in the XML backend, called sixtp.
12:28:01 <john> We *should* be using libxml2, but don't.
12:28:01 <gjanssens> We need more than only an xml parser
12:28:17 <gjanssens> most parameter names have to be converted
12:28:19 <warlord> john: yes, which pulls in libxml/SAX.h, libxml/parser.h, etc..
12:28:28 <warlord> see src/backend/xml/gnc-xml-helper.h
12:28:30 <gjanssens> we have about 170 preferences
12:28:44 <gjanssens> almost all with underscores in them
12:28:51 <gjanssens> gsettings doesn't allow underscores
12:29:04 <gjanssens> so while parsing I have to remap the names to equivalents
12:29:23 <gjanssens> (most of the equivalent names are the base name with _ replaced with -)
12:29:51 <gjanssens> But here are a few that were renamed more drastically for various reasons
12:31:10 <john> You need an XML parser to read the file: expat would do. Then you have a handler for each tag type that figures out what the option means and calls the appropriate Gsettings-backed config function to set it in the new system.
12:31:42 <john> ISTM it would be faster to do that in a scripting language, and Scheme is the only one we can count on for Windows.
12:32:23 <gjanssens> john, still libmxl2 is a runtime dependency for quite some time
12:32:34 <gjanssens> so I *could* depend on it being available
12:32:58 <gjanssens> (and webkitgtk requires it)
12:33:14 <gjanssens> But I am also inclined to look at a guile based solution
12:33:32 <gjanssens> together with a good xsl transform
12:34:01 <john> Ah, I forgot about webkit. So you could use javascript if you wanted. ;-)
12:34:02 <gjanssens> since we depend on libxml2 to be available at runtime, xsltproc will be there as well
12:34:29 <gjanssens> (on Windows, I'd package it, perhaps you need to do the same on OS X)
12:34:50 <gjanssens> How well is your javascript foo ? ;)
12:34:57 <gjanssens> Mine not too well...
12:35:03 <john> Non-existent. ;-)
12:35:55 <gjanssens> :)
12:35:59 <gjanssens> or :(
12:36:07 <gjanssens> depending on how you look at it ;)
12:36:21 <john> Well, libxslt is pulled in by WebKit, but I'm not distributing xsltproc, and I don't think it's in the Windows package, either.
12:37:07 <gjanssens> It is in the windows package
12:37:22 <john> Unfortunately there's no sxml simple in the guile we're currently using, so we'd have to track it down and add it.
12:37:29 <gjanssens> It probably shouldn't have, but it's copied in with all the rest of the libmxl dlls
12:37:42 <warlord> We know we have libxml available; why not just use it?
12:38:04 <gjanssens> I have zero experience with libxml
12:38:46 <gjanssens> That's my motivation to avoid it :)
12:38:56 <gjanssens> Perhaps not a good one
12:39:12 <gjanssens> But I do have experience with xsl transformations and some guile experience
12:39:55 <john> xsltproc is an exe, not a dll. libxslt is the dll.
12:39:58 <gjanssens> So with one smart xsl transform I could output a guile recipe to be run by gnucash
12:40:23 <john> I'll fire up my Win32 VM and look. It'll take a couple of minutes.
12:40:23 <gjanssens> john, I know. Sloppy copying on the windows build, no ?
12:40:40 <gjanssens> Don't bother, that's what I just did
12:41:02 <gjanssens> it's really xsltproc.exe that gets copied together with the libxml dll's
12:41:25 <john> Derek, because writing text-processing stuff in C is a PITA. XSLT is much faster, and it looks like it's available.
12:42:53 <john> Geert, yes, sloppy indeed. But since it's there, and it gets built anyway, I can easily add it to the OSX bundle.
12:44:34 <john> OTOH, if the rest of the conversion is in C, maybe it's easier to load the stylesheet and pass it along with the gconf files to libxslt rather than starting an external program.
12:47:38 <gjanssens> Like libxml, I don't have any libxslt experience, but perhaps that's an interesting path
12:47:48 <gjanssens> I'll read up on libxlst
12:53:02 *** Topcat has quit IRC
12:53:25 *** Topcat has joined #gnucash
12:58:26 *** Topcat has quit IRC
12:58:48 *** Topcat has joined #gnucash
13:01:49 *** todd has joined #gnucash
13:05:13 <gjanssens> libxslt can serve instead of xsltproc IMO
13:05:40 <john> OK, good.
13:06:15 *** Sk1d has joined #gnucash
13:09:29 <gjanssens> I don't see an easy way to use the output generated by libxslt directly in C
13:09:38 <gjanssens> So unless you have a good way
13:10:00 <gjanssens> I'll stick to writing out a guile file that will be invoked from within C
13:10:37 <gjanssens> The guile file will be nothing but a list of calls to gnc_prefs_set_xyz for each parameter to migrate
13:11:39 <john> That sounds reasonable to me.
13:11:44 <gjanssens> Ok
13:12:23 <gjanssens> Something else that I have been wondering about ever since the "export" variable conversation from yesterday
13:12:42 <gjanssens> It explained why my original code didn't work on Windows and OS X
13:13:07 <gjanssens> Without export, the parameter in my header file was seen as two independent parameters in the two
13:13:10 <gjanssens> source files.
13:13:24 <gjanssens> How could this ever have worked on my linux box then ?
13:14:02 <gjanssens> Are there compiler switches for such cases ?
13:15:11 <warlord> The linux linker might notice and combine them.. Or you might've just gotten lucky with memory placement.
13:15:13 <john> I think that's a linker issue rather than a compiler one: The linker decided that they were the same global and didn't raise an error for dual-definition.
13:15:49 <john> You were right yesterday when you said that the linker should have complained.
13:22:10 <gjanssens> That was actually PaulFertser suggesting that :)
13:22:48 <gjanssens> Maybe the linker did warn me, but I just didn't notice
13:23:00 <gjanssens> There's a lot of lines passing when you run a build
13:24:54 <john> BTW, another way to handle it that gives both the compactness of a static and access from another file is to declare a pointer in the header and define static the actual structure in one of the files and set the pointer to the static. Then the other file can use the pointer to access the static. You just have to be careful that the pointer is initialized before the second file tries to use it.
13:28:33 <gjanssens> Setting the pointer to the static would be like this? some_pointer = &static_struct; right?
13:28:46 <gjanssens> Is the gain sufficient that I should change this ?
13:29:03 <john> Yes, and probably not.
13:29:05 <gjanssens> GnuCash is not targetted at embedded systems
13:29:23 <john> No kidding. ;-)
13:29:32 <john> It wouldn't fit.
13:29:37 <gjanssens> LOL
13:29:54 <gjanssens> I would like to see the engine being portable one day though
13:30:12 <john> How's your C++?
13:30:29 <gjanssens> I always keep that veeerrry long-term goal in mind when a strategic decision has to be taken ;)
13:30:43 <gjanssens> Rusty ;)
13:31:02 <gjanssens> I used to program in C++ about 10 years ago
13:31:33 <john> I want start migrating from gobject, which I hate and which wasn't used correctly to write the engine in the first place, after we release 2.6 and branch.
13:31:48 <gjanssens> I know and I'm pretty excited about that
13:31:51 <PaulFertser> john: what benefit would declaring a global pointer have?
13:31:52 *** ErKa has quit IRC
13:32:20 <gjanssens> I'll try to keep up on the gui side :)
13:32:36 <john> Do templates make your head hurt?
13:32:43 *** nomeata has quit IRC
13:33:02 <warlord> Find me someone for whom templates does NOT make their head hurt..
13:33:03 <gjanssens> They did at the time yes :(
13:33:20 <gjanssens> Haven't looked at one in a very long time
13:33:38 <gjanssens> But it does depend on the complexity
13:33:48 <gjanssens> While working on the guile2 support in swig
13:33:52 <john> PaulFerster: A global pointer is a lot smaller than a non-trivial global struct. The compiler can optimize the packing of the static struct and you can still get at it from the other file.
13:33:57 <john> I think.
13:34:06 <gjanssens> I remember there was template stuff in there as well for stl
13:34:15 <PaulFertser> john: c++ templates is the only way to have compile-time code generation, so there's no way 'round them.
13:34:16 <gjanssens> I'm glad that already worked without my help
13:34:31 <john> STL is "Standard Template Library". It's templates through-and-through.
13:34:42 <gjanssens> Obviously :)
13:35:13 *** Topcat has quit IRC
13:35:23 <PaulFertser> john: with a global pointer and a static global struct you'll most probably have the same global size + the size of the pointer. The compiler doesn't "pack" structs by default afaict.
13:35:36 <john> PauFerster: Not only are templates the only way to have compile-time code generation, but the C++ committee has decided that that's a very good thing
13:36:16 <john> and that templates should be used in preference to deep inheritance hierarchies whenever possible. IOW, everyone should be writing templates.
13:36:40 <PaulFertser> john: they're very restricted by the backwards compatibility requirements, they can't do it the way D folks roll. Also, in C++11 some properly written functions are actually compile-time evaluated.
13:37:22 <PaulFertser> I thought that it's a common knowledge deep inheritance is proven to be unsuitable for the most purposes :)
13:37:35 <john> Roger, but C++11 is available on current versions of all three platforms. D, not so much.
13:38:45 <john> >unsuitable: It is *now*. Not so much 10 years ago. Compare "C++ Programming Language" 3rd Ed. with the new 4th.
13:39:45 <warlord> It's too bad that the C++ committee didn't learn from their ABI mistakes a decade ago. :-(
13:40:14 <john> You mean that all libraries have to be built with the same compiler?
13:40:41 <warlord> And the same version of the same compiler..
13:40:58 <john> I've a Habitat buddy who's on the committee. They don't see it as a significant problem.
13:41:03 <warlord> .. and against the same stllib headers...
13:41:48 <warlord> it was a MAJOR MAJOR issue 10-15 years ago, which caused many many people to not use C++ because you were never sure your stuff was going to work unless you could compile your whole program (and all dependencies) from source.
13:42:01 <warlord> i.e., you couldn't ship C++ library dependencies and expect them to work.
13:42:36 <warlord> Even if you had a C API wrapper around them you could still have link-time or run-time issues.
13:45:09 <john> There must be some way around it, though. My understanding is that most of Windows is in C++, and they manage to get things to work pretty well across versions of VC++.
13:45:11 *** benoitg has joined #gnucash
13:47:36 *** todd has quit IRC
13:47:43 *** todd has joined #gnucash
13:48:22 <john> Looks like they do it with C shims: http://msdn.microsoft.com/en-us/library/hh438475.aspx
13:59:25 *** benoitg has quit IRC
13:59:25 *** Jimraehl1 has quit IRC
13:59:25 *** fell has quit IRC
13:59:25 *** kpreid has quit IRC
13:59:25 *** GabrieleV has quit IRC
13:59:25 *** soa2ii has quit IRC
13:59:25 *** warlord has quit IRC
13:59:25 *** kim27 has quit IRC
13:59:25 *** wizkid238 has quit IRC
13:59:25 *** ryanakca has quit IRC
13:59:25 *** Mer|in has quit IRC
13:59:25 *** talso has quit IRC
13:59:25 *** blathijs has quit IRC
13:59:25 *** kenyon has quit IRC
13:59:25 *** uXus has quit IRC
14:03:20 *** benoitg has joined #gnucash
14:18:03 <PaulFertser> I have an impression that the "OO" paradigm was flawed right from the start but I do not have any scientific evidence. CS guys like Haskell :)
14:19:20 <john> *Some* CS guys like "functional programming", of which one expression is Haskell.
14:20:00 <john> I don't know of many actual products, open source or otherwise, actually written in functional languages, though. Do you?
14:29:27 *** ErKa has joined #gnucash
14:38:47 *** ErKa has quit IRC
14:39:09 <PaulFertser> Neither me. xmonad is an obvious example, but other than that...
14:39:20 *** ErKa has joined #gnucash
14:41:32 <john> And yet, with all of the emphasis on statelessness in web application code, you'd think functional would be a natural fit. Instead we have… JavaScript.
14:42:18 <john> Or worse, Java. Which has deep inheritance so firmly embedded that it essentially defines the language.
15:07:20 *** ErKa has quit IRC
15:27:47 *** ErKa has joined #gnucash
15:32:53 *** kenyon has joined #gnucash
15:42:01 *** TradeBorG has quit IRC
15:45:06 <PaulFertser> john: well, I know server-side Haskell boasts at least two well-established frameworks: Happstack and Yesod. There's also some widely deployed Scala web-framework.
15:46:04 <PaulFertser> You have to take into account the fact that many "web programmers" are either incompetent or retarded, enough to e.g. use PHP.
15:49:10 <PaulFertser> BTW, JavaScript is one of the popular high-level languages that supports closures, it's not that bad :) Fabrice Bellard even wrote an x86 emulator in it.
15:50:23 <PaulFertser> Java is probably a good fit if all you can afford for a project is a bunch of codemonkeys.
15:50:38 <PaulFertser> imho
15:52:15 *** aqua___ has joined #gnucash
15:57:23 *** aqua_ has joined #gnucash
15:57:59 *** Bodhi-Baum has quit IRC
16:05:00 *** aqua___ has quit IRC
16:20:15 *** talso has joined #gnucash
16:46:08 *** Mer|in has joined #GnuCash
16:46:44 *** wizkid238 has joined #gnucash
16:47:59 *** fell_ has joined #gnucash
16:47:59 *** gncbot sets mode: +o fell_
16:48:08 *** ryanakca has joined #gnucash
16:48:08 *** blathijs has joined #gnucash
16:50:01 *** aqua_ has quit IRC
17:06:30 *** Krzysiek_K has joined #gnucash
17:07:46 *** Krzysiek_K has left #gnucash
17:25:19 *** todd has quit IRC
17:25:28 *** todd has joined #gnucash
17:30:42 *** gncbot` has joined #gnucash
17:30:43 *** gncbot has quit IRC
17:35:50 *** nomeata has joined #gnucash
17:37:26 *** gjanssens is now known as gjanssens-afk
17:50:28 *** shaun has joined #gnucash
17:51:21 *** todd has quit IRC
17:51:27 <shaun> Hi all... looking for some help exporting to IIF or QIF for an accountant to be able to more easily look through the accounts in some software they're familiar with... I've tried using the Java JAR that is supposed to do it but it's giving me an error
17:51:33 *** todd has joined #gnucash
17:51:57 <shaun> java -jar GnuCashToQIF-1.6.jar
17:51:57 <shaun> java.lang.RuntimeException: Unhandled account type: root
17:52:18 <shaun> Wondering if anyone has encountered this and if there's any other ways I can look into working around the problem.
18:01:08 *** twunder has joined #gnucash
18:12:29 *** nomeata has quit IRC
18:17:46 *** twunder has quit IRC
18:48:26 *** benoitg has quit IRC
19:13:22 *** benoitg has joined #gnucash
19:14:59 *** todd has quit IRC
19:55:13 *** fuzzybunny69y has joined #gnucash
20:18:10 *** twunder has joined #gnucash
20:19:34 *** twunder has quit IRC
20:27:19 *** benoitg has quit IRC
20:29:55 *** fuzzybunny69y has quit IRC
20:46:02 *** benoitg has joined #gnucash
20:51:37 *** todd has joined #gnucash
21:07:20 *** benoitg has quit IRC
23:38:40 *** fell_ has quit IRC
23:49:37 *** fuzzybunny69y has joined #gnucash
23:55:23 *** ErKa has quit IRC