2018-02-18 GnuCash IRC logs

00:18:03 *** josephcocoa has quit IRC
00:25:13 *** kus has quit IRC
01:11:04 <fell> while looking around for __VA_ARGS__ examples, I see in libqof/qof/qoflog.h an #ifdef _MSC_VER and in its GNU branch the pre C99 ‘args…’ form. Shouldn't it become simplified or missed I something?
01:15:25 *** fell has quit IRC
01:16:40 *** fell has joined #gnucash
01:17:03 *** gncbot sets mode: +o fell
01:18:28 <fell> No stringization, but the old form of '__VA_OPT__(,) '
01:24:58 *** CDB-Man_ has joined #gnucash
01:25:58 *** CDB-Away has joined #gnucash
01:27:01 *** CDB-Away_ has quit IRC
01:27:27 *** CDB-Man has quit IRC
01:28:58 <fell> IMHO we can drop the '#else /* _MSC_VER */' branch
01:34:51 *** gncbot has joined #gnucash
01:47:22 *** fell sets mode: +o gncbot
01:48:19 <fell> warlord, gncbot returns unoped.
01:53:14 <fell> Hm, I am still something missing. error: '__VA_OPT__' undeclared (first use in this function)
02:26:03 *** gncbot has joined #gnucash
02:33:51 *** woodrec has joined #gnucash
02:35:29 *** mpiechotka has joined #gnucash
02:42:25 *** jotrago has joined #gnucash
02:48:48 *** gncbot has joined #gnucash
02:49:42 *** fell sets mode: +o gncbot
03:00:08 *** gjanssens has joined #gnucash
03:00:08 *** ChanServ sets mode: +o gjanssens
03:00:18 <gjanssens> .
03:00:45 *** marusich has quit IRC
03:03:04 *** Mechtilde has joined #gnucash
03:15:53 *** fekepp has joined #gnucash
03:30:12 *** gncbot has joined #gnucash
03:30:48 *** gncbot has joined #gnucash
03:34:01 <fell> arahael: I don't know, but the MSC section contains the same expressions as used in https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html#Variadic-Macros
03:35:39 <arahael> Hmm, my intenret is *shit* today, I can't resolve gnu.org.
03:38:13 *** gncbot has joined #gnucash
03:38:27 <arahael> Ah, I can connect to gnu.org again. :)
03:38:28 <fell> and you see gncbot leaving every hour
03:38:28 <gjanssens> fell: I know, but warlord's nick is still there, so I assume he'll find my message when he wakes up
03:38:58 <gjanssens> Indeed. Flakey network in US land...
03:39:03 <arahael> fell: That last paragraph is insightful, thanks for that link.
03:39:14 <arahael> gjanssens: Irregardless of how bad teh US is, mine is worse. :)
03:39:29 <gjanssens> arahael: :)
03:39:51 <fell> That are only fake news ;-)
03:43:41 <fell> gjanssens, do you have some idea were I have the mistake?
03:43:41 <gjanssens> fell: mistake about what ? I can't connect to lists.gnucash.org, so I can't scroll back in the history...
03:43:44 *** gncbot has joined #gnucash
03:43:50 <gjanssens> Hi gncbot...
03:44:06 <fell> while looking around for __VA_ARGS__ examples, I see in libqof/qof/qoflog.h an #ifdef _MSC_VER and in its GNU branch the pre C99 ‘args…’ form. Shouldn't it become simplified or missed I something?
03:44:18 <fell> Found it, GNU C needs stringization.
03:44:27 <fell> No stringization, but the old form of '__VA_OPT__(,) '
03:44:35 <fell> IMHO we can drop the '#else /* _MSC_VER */' branch
03:44:44 <fell> Hm, I am still something missing. error: '__VA_OPT__' undeclared (first use in this function)
03:46:09 <gjanssens> fell: I have never studied variadic macros, so I don't know much about them :(
03:46:09 <fell> But other macros?
03:47:56 <fell> the last arguments are [__VA_OPT__(,) ]__VA_ARGS__
03:49:00 <fell> or in old form #define MACRO(...) print(args)
03:54:46 *** harshitaneja has joined #gnucash
03:56:09 <fell> oops old was "args..."
03:58:41 *** mpiechotka has quit IRC
04:00:11 *** mpiechotka has joined #gnucash
04:00:55 *** pilotauto has quit IRC
04:01:08 <gjanssens> fell: at first sight I would agree the #else branch is obsolete by now. What errors do you get if you remove it ?
04:02:29 <fell> '__VA_OPT__' undeclared (first use in this function)
04:05:09 <fell> I was still on maint with autotools
04:09:38 *** gncbot has joined #gnucash
04:11:47 <fell> Second, C++2a introduces the __VA_OPT__ function macro. ... __VA_OPT__ is also available in GNU C and GNU C++.
04:12:00 <arahael> gjanssens: Where does it say that?
04:12:37 <fell> in the middle of the page
04:13:43 <arahael> Ah... Onyl in "GNU C", and C++.
04:15:33 <gjanssens> arahael: not even in "GNU C". GNU C has its own solution using "## args"
04:16:03 <gjanssens> Eh no
04:16:15 <gjanssens> It is written it should be available in GNU C
04:17:07 <arahael> gjanssens: Yeah, that was why I was confused. :)
04:17:19 *** fabior has joined #gnucash
04:18:50 <gjanssens> Yeah, I'm confused now as well, because I thought we were using gnu c. Our compile options define -std=gnu11
04:19:00 <fell> In C99 it became standard. Before CPP had ‘args…’
04:21:15 <fell> A millenium bug, 99>11? ;-)
04:22:02 *** fekepp has quit IRC
04:22:19 <gjanssens> fell: the "it" in your previous quote is important. It's referring to variadic macros in general, but I'm not sure that also includes __VA_OPT__
04:31:31 <fell> It might be a C++2a feature, so next decade :-(
04:31:48 <gjanssens> Also C++2a appears to be similar to C++20. C++17 hasn't even been complely implemented in compilers yet
04:31:58 <gjanssens> Yeah, I just figured that out as well...
04:32:35 <gjanssens> I also grepped for VA_OPT on the gcc7 included headers. It's not found at all.
04:32:47 <gjanssens> It's equally not found on any include file installed on my system
04:33:28 <gjanssens> I do find "## __VA_ARGS__", which is again the gnu c hack.
04:33:33 <arahael> Well, you have other alternatives for C++, anyway.
04:33:43 <arahael> Eg, variadic templates.
04:34:38 <arahael> So, if I were to import a .odx file again, would it duplicate my entrie?
04:34:41 <arahael> *entries
04:34:59 <fell> For what I wanted to do I do not need it, I hope.
04:35:44 <fell> But I thought we could clean up qoflog.h.
04:36:43 <fell> odx?
04:37:20 <arahael> OFX, my mistake.
04:38:15 *** hoijui has joined #gnucash
04:40:17 <fell> I don't use that importer. Goes it straight forward or has it an assign account dialog?
04:41:44 <arahael> It has an assign account dialog.
04:42:15 <fell> Then you can mark them as duplicates?
04:42:45 <fell> Save your data before testing
04:42:46 <arahael> Ie, explicitly?
04:43:09 <arahael> I'll have to figure out how to stop it from autosaving, but that's a good point.
04:43:36 <arahael> I'm just wondering waht workflow I should use - eg, I just bought some "supplies". Do I enter them in now, or wait until my next OFX import?
04:43:46 <fell> Save again as test-file
04:44:24 <arahael> Of course - "save as".
04:50:57 <fell> gjanssens: should I add a TODO note in qoflog.h?
05:02:14 <gjanssens> fell: sure, go ahead
05:04:46 *** mipesom has joined #gnucash
05:37:59 *** gjanssens is now known as gjanssens_afk
05:58:02 *** nicolash has joined #gnucash
06:10:02 *** chris_M has joined #gnucash
06:25:15 *** chris_M1 has joined #gnucash
06:26:59 *** chris_M has quit IRC
06:31:53 *** chris_M has joined #gnucash
06:31:54 *** chris_M1 has quit IRC
06:37:13 *** darshan has joined #gnucash
06:38:50 *** darshan has quit IRC
06:57:41 *** fabior has quit IRC
07:27:58 *** chris_M has quit IRC
07:34:03 *** nicolash has quit IRC
08:06:45 *** O01eg has joined #gnucash
08:15:45 *** warlord sets mode: +o gncbot
08:16:42 <warlord> gjanssens_afk: My VM system seems to have an issue weekly when the VM Host runs a md-resync.
08:31:24 <fell> warlord: from 07:34-10:09+01 gncbot hourly disappeared and returned as normal user.
08:33:14 *** nicolash has joined #gnucash
08:54:26 *** mib_mzq1vv has joined #gnucash
09:10:13 <warlord> fell: hmm, not sure why hourly.. But that timeframe corresponds approximately with the resync and other issues I got around 4:10am ET
09:11:43 <warlord> 1;46, 2:39, 2:46, 2:48, 2:57, 3:04, 3:07, 3:12, 3:47, 4:05, 4:09, 4:10
09:15:18 <warlord> At least those are the times that Code reported a CPU Lockup.. Which corresponded to the resync of md125.
09:21:59 <fell> Because then additionally cron starts jobs?
09:26:24 <warlord> I think the MD resync is somehow hogging I/O..
09:29:01 <warlord> THere's a kernel and firmware update available so I'm going to take it and see if it corrects the issue.
09:41:24 <warlord> So now I need to schedule a reboot.
09:55:31 *** nicolash has quit IRC
10:05:25 *** fabior has joined #gnucash
10:06:13 *** fekepp has joined #gnucash
10:43:52 *** User_ has joined #gnucash
11:17:43 *** User_ has quit IRC
11:19:25 *** To7 has joined #gnucash
11:20:15 *** fabior has quit IRC
11:28:18 *** harshitaneja has quit IRC
11:51:57 *** andersonvom has joined #gnucash
11:55:17 *** woodrec has quit IRC
11:58:54 *** andersonvom has quit IRC
12:00:48 *** andersonvom has joined #gnucash
12:08:30 *** fabior has joined #gnucash
12:09:39 *** fabior has quit IRC
12:10:54 *** fabior has joined #gnucash
12:11:58 *** andersonvom has quit IRC
12:30:59 *** fabior has joined #gnucash
12:36:46 *** Cuare has joined #gnucash
12:48:00 *** jralls_afk is now known as jralls
13:04:55 *** gjanssens_afk is now known as gjanssens
13:14:39 <gjanssens> warlord: the planned reboot is no issue for me. I'll be in bed by then.
13:15:45 *** User_ has joined #gnucash
13:16:01 <jralls> warlord: And I'll be making dinner.
13:20:40 *** fabior has quit IRC
13:45:13 *** User_ has quit IRC
14:14:29 *** frakturfreak has joined #gnucash
14:22:30 *** marusich has joined #gnucash
14:37:05 *** mib_mzq1vv has quit IRC
14:40:48 <jralls> gjanssens: There's a circular dependency for compiling gnucash/gnome/gnome-utils.scm: It calls load-extension("libgncmod-gnome-utils" "scm_init_sw_gnome_utils_module"), and libgncmod_gnome_utils_gnc_module_init() calls use-modules(gnucash gnome-utils).
14:41:57 <jralls> That obviously works, but I suspect that telling CMake about it will break.
14:43:46 *** nicolash has joined #gnucash
14:48:14 *** BuschMan has joined #gnucash
14:48:29 <gjanssens> jralls: I agree we can't explain this to CMake. And I don't know how much work it would be to rewrite our code to stop having circular dependencies like this.
14:49:07 <gjanssens> I hope we can clean them up bit by bit in our continued c++ conversion (although this one is in gnome-utils, so gui land)
14:49:34 <jralls> One of these days we need to re-thing gnc-module. AFAICT all it does for us right now is get the C symbols into Scheme and it's a ton of overhead for that.
14:49:51 <jralls> s/re-thing/re-think/
14:54:34 <gjanssens> I thought the primary "benefit" of gnc-module was that it helps ensure an initialization function is run when loading the module first-time, so whatever library is in the module is always properly initialized when loaded.
14:54:56 <gjanssens> I thought getting the C symbols in Scheme was via load-extension (<swig-wrapper>)
14:55:42 <gjanssens> But perhaps both are needed to get the C symbols in Scheme.
14:56:31 <gjanssens> That would need some more study for which I currently don't have time (though I am willing to investigate this further for 4.0)
14:56:52 <jralls> Right, definitely for 4.0, it's a big design change.
14:57:17 <jralls> But if we have libraries that need to be initialized that's a pretty bad design flaw that will have to be fixed first.
14:58:53 <gjanssens> True. We're looking at it as libraries now, but in the past they were considered "self-contained modules"
14:59:11 <gjanssens> It makes slightly more sense in that context, but I'm not a fan of it.
14:59:11 <jralls> But you lead into my other question, which is "what's the difference between "gnc:module-load(gnucash/gnome-utils)" and "(load-extension "libgncmod-gnome-utils" "scm_init_sw_gnome_utils_init")"?
14:59:14 *** BuschMan has quit IRC
15:00:06 <gjanssens> When generating the swig wrappers, this also created a shared library with all the wrapper code in it.
15:00:18 <gjanssens> This wrapper library has to be loaded with load-extension
15:00:40 <gjanssens> The second parameter is -again- an initialization function to call at load time of the shared library.
15:00:44 <jralls> Well, no, because one dlopens libraries. Self contained modules live in their own threads and use IPC to communicate.
15:01:07 <gjanssens> Sure, but that's not how it was designed back then
15:01:39 <gjanssens> gnucash comes from a guile backend where everything is a module
15:02:06 <gjanssens> It's a bit like the __init__ concept in python modules I suppose.
15:02:30 <gjanssens> But I'm just interpreting all this. I was not involved in the design at all of course
15:05:30 <gjanssens> I'll also note that dlopen will also look for an initialization function and execute it if found (from man dlopen)
15:06:09 <jralls> Yes, because in the 70's when dlopen was invented globals weren't anathema.
15:06:11 <gjanssens> I think we should look at those more as constructor functions (and that's what it's called in dlopen terminology even)
15:06:30 <gjanssens> anathema is a word I don't understand...
15:11:03 <jralls> It's from ancient Greek for "devoted to evil". I think it got into English from the Catholic Church which used to "anathematize" behavior that went against their teaching but didn't rise (sink?) to the level of heresy.
15:12:02 <gjanssens> Ok
15:12:36 *** gjanssens is now known as gjanssens_afk
15:12:36 <jralls> Google translate says that it's a Dutch word, too, and offers banvloek as a synonym.
15:13:06 <gjanssens_afk> Oh, in Dutch it sounds rather dramatic :)
15:25:15 <jralls> So back to load-extension. gnc_module_load calls libgncmod_gnome_utils_gnc_module_init when it loads the gnome-utils module, and that calls scm_init_sw_gnome_utils_module, then tells Guile to (use-modules sw_gnome_utils) and (use-module(gnucash gnome-utils)).
15:32:40 *** gjanssens_afk is now known as gjanssens
15:32:41 <gjanssens> ok
15:34:55 <jralls> So why are there instances where it's beneficial to do the extra stuff that libgncmod_gnome_utils_gnc_module_init does and instance where it's not?
15:37:16 <jralls> And then gnome-utils.scm does (eval-when (compile load eval expand) (load-extension "libgncmod-gnome-utils" "scm_init_sw_gnome_utils_module")) *again*.
15:37:33 <jralls> This makes my head hurt.
15:37:38 <gjanssens> Indeed. That's got me puzzled as well.
15:39:10 <gjanssens> I am not sure it has to, but I don't know that for certain. It may be it's only required on one side but having it at both sides is a remnant of an incomplete conversion from pure Scheme to a mixed C/Scheme world
15:40:35 <gjanssens> It may also be the initializations happen in different scopes if it's started from scheme vs started from C.
15:41:09 <gjanssens> Remember we talked yesterday about the use-modules vs resolve-module/set-current-module thing ?
15:41:22 <gjanssens> This may be the same here.
15:41:22 <jralls> Yes.
15:41:49 <gjanssens> But whatever it is we should really figure out a way to untangle this mess and simplify it drastically.
15:42:39 <gjanssens> If neither you nor I can make sense of it, how can we ever hope more casual contributors would that know the code less well ?
15:42:47 <jralls> There's another variation that I don't understand: (gnc:module-begin-syntax (gnc:module-load "gnucash/report/report-system" 0))
15:44:27 <gjanssens> Ah, that one's a bit more easy :)
15:44:29 <jralls> And yeah, no kidding. So after we've got 3.0 shipped and stable we need to go through all the code and understand it.
15:45:17 <gjanssens> The gnc:module-begin-syntax construct was added to cope with the different ways modules needed to be loaded in guile 1.8 and guile 2
15:45:25 <jralls> And then either document the tangles a bit more throughly than gnc-module/doc/design.txt or clean it up or both.
15:46:13 <gjanssens> For guile 2 we have to specify the module loading also has to happen while compiling the scheme code
15:46:14 <jralls> Ah. OK, so since we've dropped 1.8 support that can be cleaned up.... but why was it necessary only sometimes?
15:46:28 <gjanssens> In guile 1.8 this was not necessary
15:47:38 <gjanssens> So much of our code had constructs like (cond-expand (guile-2 (<do it the guile 2 way>))(else (<do it the guile 1.8 way>)))
15:48:19 <gjanssens> To simplify this code, the syntax rule was written to wrap this, you can find it in libgnucash/gnc-module/gnc-module.scm
15:49:08 <gjanssens> The conversion to use the syntax rule was not complete, so we have had a mixture of the cond-expand and gnc:module-begin-syntax constructs
15:49:59 <gjanssens> When I dropped support for guile 1.8 in unstable I went through most of the (cond-expand ...) lines to drop the 1.8 variant, but it seems I missed the syntax rule cleanup
15:50:26 <gjanssens> So that could be cleaned up now as well.
15:51:04 <jralls> But e.g. report/locale-specific/us/taxtxf-de_DE.scm has naked gnc:module-load, no cond-expand and no gnc:module-begin-syntax.
15:51:38 <jralls> Ah, we crossed and your explanation answers the question.
15:53:39 <gjanssens> Well, not exactly. I think you have found a bug. The naked gnc:module-loads should still be wrapped in (eval-when (compile load eval expand) ...)
15:54:16 <gjanssens> We never saw this because the german tax report is only built when you have a german locale set
15:54:24 <gjanssens> Speaking of an ugly hack :(
15:55:13 *** kael has joined #gnucash
15:56:14 <gjanssens> Well, that not completely accurate
15:57:32 <jralls> Oh, that was just the first file that came up. The naked gnc:module-loads are by far the majority.
15:59:36 <gjanssens> Interesting. I remember at some point I had to wrap them in eval-when, but I don't remember exactly why.
15:59:57 <gjanssens> I thought there were errors about unresolved symbols if they weren't wrapped.
16:00:15 <gjanssens> It could easily be tested by removing the eval-when wrappers again.
16:00:59 <gjanssens> And perhaps it's not always necessary, only if the scm module uses certain symbols.
16:01:35 <gjanssens> And this is all about compile time symbol resolution, at runtime the eval-when would be a no-op
16:02:20 <gjanssens> I can probably find recover the motivation from my irc logs on the guile channel when I was preparing gnucash for guile 2 support.
16:04:04 *** hoijui has quit IRC
16:04:36 <jralls> OK. Maybe as part of understanding gnc-module.
16:05:09 *** nicolash has quit IRC
16:08:25 *** Mechtilde has quit IRC
16:12:09 *** Mechtilde has joined #gnucash
16:16:02 *** Mechtilde has quit IRC
16:22:19 <gjanssens> jralls: I found a discussion on this with Andy Wingo back in November 2013.
16:22:43 <jralls> Wow. No wonder you don't remember the details!
16:23:11 <gjanssens> It looks like the eval-when is needed if the module loaded with gnc:module-load in turn also loads other scheme modules *and* the original scheme module requires symbols from the latter
16:23:59 <gjanssens> In this particular case the symbol was (N_ )
16:24:18 <gjanssens> So the eval-when construct is not always needed.
16:24:37 <gjanssens> And I think I was being pragmatic at the time and only added it whenever I got compilation issues.
16:27:14 <jralls> Hmm. Other scheme modules or other gnc-modules?
16:30:26 <jralls> Either way there are still a lot of standard-reports that depend on report-system and don't wrap gnc:module-load with eval-when.
16:31:54 <jralls> So it seems that there's probably more to it and the only way to know at this point is when the compile breaks.
16:32:11 <gjanssens> Yes
16:32:59 <gjanssens> It's also possible the definition of (N_ ) has moved since and maybe the eval-when's are no longer needed.
16:33:08 <gjanssens> Will need experimentation at some point
16:33:27 <jralls> Later. Let's get 3.0 done.
16:34:04 *** pilotauto has joined #gnucash
16:42:46 *** frakturfreak has quit IRC
16:52:37 *** oozer has joined #gnucash
16:59:23 *** fekepp has quit IRC
16:59:34 *** fekepp has joined #gnucash
17:07:38 *** fekepp has quit IRC
17:08:21 *** kael has quit IRC
17:12:59 *** kus has joined #gnucash
17:16:47 *** kael has joined #gnucash
17:57:21 *** kus has quit IRC
18:10:07 <gjanssens> Time to call it a day... TTYL
18:10:39 *** gjanssens has quit IRC
18:32:53 *** josephcocoa has joined #gnucash
19:21:21 *** kael has quit IRC
19:28:37 *** kael has joined #gnucash
19:31:55 <chris> jralls (1) I'll be using srfi-64 for unit tests, it's rather nice - see http://i.imgur.com/8uDBwm8.png ... (2) I wish guile-lib was included for htmlprag; I'll be keen to query <table> using sxpath for tests and sxpath is rather strict on xml parsing
19:34:43 <jralls> chris: Excellent. A built in facility is definitely better.
19:35:44 <jralls> chris: what's htmlprag? Part of SRFI-64?
19:36:09 <chris> it's part of guile-lib
19:36:42 <chris> so, guile has (use-modules (sxml simple)) which decodes welll-formed xml into sxml, which is amazing to query via xpath-type queries
19:37:14 <jralls> OK. I like xpath.
19:37:34 <chris> but i know make-html-table doesn't always produce valid XML (e.g. <td>Debit AUD</td> because doesn't need ) therefore something permissive like htmlprag would be nicer
19:38:19 <jralls> The XHTML break tag is .
19:38:25 <chris> is always encouraged, instead of apparently
19:38:35 <jralls> By whom?
19:39:09 <chris> found somewhere in the 'nets
19:39:10 <jralls> I generally use on https://californiaancestors.org
19:39:45 <chris> oh well I can modify TR to always output well-formed XML and job done
19:39:50 <jralls> Well, unless it's https://www.w3c.org, it's not authoritative.
19:41:58 <jralls> Yes, well-formed XML or XHTML is better. gjanssens and I have talked a bit about having xml or json report output for export and then processing that separately for display.
19:42:32 <jralls> We really need to get out from under webkit.
19:43:08 <chris> I added due to https://developer.mozilla.org/en-US/docs/Web/HTML/Element/br - but can change to for ease of testing
19:47:23 <jralls> That's because is legit for HTML. If you follow https://www.w3.org/TR/2002/REC-xhtml1-20020801/ then any browser can render it and it's well-formed XML.
19:48:04 <jralls> You miss out on some of the fancy stuff from HTML5, but that's not really significant for our reports.
19:49:47 *** woodrec has joined #gnucash
19:50:22 <chris> ok time for work!
19:52:52 <jralls> Have fun!
19:53:07 <jralls> Time for me to make dinner.
19:53:14 *** jralls is now known as jralls_afk
19:57:55 <arahael> is encouraged, for html5. But if you're using xhtml, seems perfectly adequate.
19:58:25 <arahael> xhtml seems to be getting less and less popular on the nets, for some reason.
20:03:48 <jralls_afk> arahael: That's because html5 provides services that get rid of flash and that's a Good Thing. But it's not something that matters in the closed world of our reports.
20:05:01 <arahael> jralls_afk: Arguably, I think those services could've been done with xhtml as well, but there's also the conflict between w3c and whatng.
20:05:26 <jralls_afk> No doubt.
20:05:40 *** woodrec has left #gnucash
20:05:55 <jralls_afk> But that's not how it played out, so we have html5 instead of xhtml2.
20:05:58 <arahael> jralls_afk: Most devs don't care about correctness, validtity, or even leveraging tools, such as xpath. :(
20:06:18 <arahael> I'm not really a fan of xml itself, but the tooling in it's ecosystem are seriously good. :/
20:10:35 <arahael> jralls_afk: Btw, I wasn't able to run the latest build of Gnucash, only the latest stable. Not sure why yet, it might be something as simple as already having the stable version open.
20:10:48 <arahael> I'll need to look at it later in more detail.
20:33:18 *** oozer has quit IRC
20:49:10 *** mdforbis has joined #gnucash
20:51:12 *** mdf has quit IRC
21:01:50 *** kael has quit IRC
21:07:42 <warlord> .
21:07:51 <warlord> Okay, I'm bringing down the VMs to reboot. Thanks.
21:46:28 *** gncbot has joined #gnucash
21:46:37 *** warlord sets mode: +o gncbot
22:37:42 *** woodrec has joined #gnucash
22:44:59 *** woodrec has quit IRC
23:11:18 *** Cuare has quit IRC
23:13:20 *** To7 has quit IRC
23:34:05 *** wget has quit IRC
23:36:49 *** wget has joined #gnucash