2021-07-03 GnuCash IRC logs
00:28:31 *** jervin has quit IRC
00:28:40 *** jervin has joined #gnucash
00:32:32 *** jervin has quit IRC
00:49:02 *** r2d3 has joined #gnucash
00:49:16 *** Mechtilde has joined #gnucash
00:53:40 *** Bambuzel has joined #gnucash
00:53:40 *** ChanServ sets mode: +v Bambuzel
01:11:59 *** fell has quit IRC
01:13:18 *** fell has joined #gnucash
01:13:18 *** ChanServ sets mode: +o fell
01:13:58 *** Bambuzel has quit IRC
01:14:00 *** r2d3 has quit IRC
01:14:13 *** r2d3 has joined #gnucash
01:18:32 *** r2d3 has quit IRC
01:18:45 *** r2d3 has joined #gnucash
01:41:18 *** frakturfreak has quit IRC
01:43:06 *** David1 has quit IRC
01:43:37 *** David has joined #gnucash
01:55:56 *** frakturfreak has joined #gnucash
02:37:07 *** kcin has joined #gnucash
02:45:14 *** gjanssens has joined #gnucash
02:45:14 *** ChanServ sets mode: +o gjanssens
02:45:48 <gjanssens> .
02:59:51 <gjanssens> jralls, chris: I only now found your December comments about guile's dependency resolution https://lists.gnucash.org/logs/2020/12/24.html#T12:37:15
03:00:37 <gjanssens> The notes were recorded by gncbot under variations of my nick...
03:02:45 <chris> ahhhh that's what MAKE_LINKS is about
03:03:59 <gjanssens> While MAKE_LINKS allows us to gloss over circular dependencies at build time I still suspect circular dependencies are the primary reason we can't reliably build when there's a previous installation of gnucash.
03:05:05 <gjanssens> So to me the links are a workaround until we can solve this better, that is until we solve each and every circular dependency.
03:05:52 *** kcin1 has joined #gnucash
03:06:03 *** kcin has quit IRC
03:06:26 <chris> I guess it's only report and qif-importer that show it?
03:07:02 <gjanssens> And a second thought I had around MAKE_LINKS is that we could also choose to restructure our guile sources to be in the proper directory hierarchy so that links would not be necessary.
03:08:20 *** kcin1 is now known as kcin
03:08:28 <gjanssens> IMO if we manage to finish the cleanup in app-utils, we could group all guile sources in two directories: libgnucash/bindings and gnucash/guile. Inside those directories we could lay them out to match their module names.
03:09:04 <gjanssens> At build time, we'd then have to set the proper guile load paths to include these two directories.
03:09:59 <gjanssens> chris: I don't know. I saw the issue with those two in my most recent build issue.
03:11:06 <gjanssens> jralls: as for dependency issues with swig files, I *thought* I had worked those out at some point. Have you experienced them recently still ?
03:11:39 <chris> meanwhile (1) 797596 seems a couple steps forward
03:12:15 <gjanssens> chris: just a heads up, gncbot has messages waiting for you as well, but under distorted nicks (with commas and dots added)
03:12:46 <gjanssens> chris: yes I saw your message from a few hours back. I'll try to look at your work.
03:13:11 <chris> (2) I discovered such things as finalizers/guardians in guile which can auto-call a function to free an SCM object -- would apply to gncOwnerNew objects which needs gncOwnerFree. but I haven't managed to make it work yet
03:16:41 <gjanssens> Interesting
03:43:42 *** r2d3 has quit IRC
03:46:12 *** David has quit IRC
03:46:31 *** David has joined #gnucash
05:06:34 *** kcin1 has joined #gnucash
05:06:59 *** kcin has quit IRC
05:07:21 *** fabior has joined #gnucash
05:09:02 *** kcin1 is now known as kcin
05:23:37 *** sbluhm has joined #gnucash
05:28:34 *** kcin has quit IRC
05:28:43 *** kcin has joined #gnucash
05:31:53 *** storyjesse has joined #gnucash
05:43:52 <gjanssens> @notes chris,
05:43:52 <gncbot> gjanssens: Sent 26 weeks, 6 days, 8 hours, and 53 minutes ago: <jralls> no, not crucial. I already fixed it by using MAKE_LINKS on all of the scheme targets. and Sent 9 weeks, 6 days, 9 hours, and 37 minutes ago: <jralls> what does `apt-cache policy googletest` say is the version?
05:44:13 <gjanssens> @notes chris:
05:44:13 <gncbot> gjanssens: Sent 28 weeks, 6 days, 11 hours, and 29 minutes ago: <fell> Did you forget date-utilities.scm? I still get there: warning: possibly unbound variable and Sent 22 weeks, 6 days, 18 hours, and 13 minutes ago: <Mechtilde> There are now 5 style sheets for the reports (added HEAD or Taail
05:45:09 <gjanssens> @remove chris,
05:45:09 <gncbot> gjanssens: The operation succeeded.
05:45:14 *** kcin has quit IRC
05:45:17 <gjanssens> @remove chris;
05:45:17 <gncbot> gjanssens: Error: There were no notes for 'chris;'
05:45:23 <gjanssens> @remove chris:
05:45:23 <gncbot> gjanssens: The operation succeeded.
05:45:49 *** kcin has joined #gnucash
05:46:12 * gjanssens ran the notes and remove commands in the public channel to illustrate how to trigger gncbot to show notes for impossible nicks and how to remove them afterwards
05:46:28 <gjanssens> The second command only works if you have admin rights in the channel though.
05:48:23 <fell> gjanssens: better put it in https://wiki.gnucash.org/wiki/Operating_IRC
05:54:06 <Simon> shouldn't the bot check that the nickname is valid and/or remove punctuation?
05:55:55 *** fabior has quit IRC
05:57:23 *** sbluhm has quit IRC
06:06:33 <gjanssens> Simon: I don't know. The bot is managed by warlord and IIRC it's a very old implementation. Perhaps newer bots are smarter about this.
06:13:16 *** User has joined #gnucash
06:17:44 *** sbluhm has joined #gnucash
06:18:14 *** celeste has quit IRC
06:21:37 <gjanssens> fell: fair point. I have added a small section with the basics
06:24:29 <fell> Simon: There is since several years a successor for supybot. Warlord can explain, why it is not replaced..
06:41:06 *** kcin1 has joined #gnucash
06:41:14 *** storyjesse has quit IRC
06:41:30 *** kcin has quit IRC
06:43:34 *** kcin1 is now known as kcin
07:07:13 *** sbluhm has quit IRC
07:09:09 *** David has quit IRC
07:09:32 *** David has joined #gnucash
07:09:59 <chris> gjanssens: branch bug797596 updated :)
07:10:46 <chris> it seems to work, to my jawdrop surprise
07:11:03 <chris> or, your understanding of payment arithmetic is overworldly
07:26:35 <gjanssens> chris: did you push ? If I pull git says I'm already up to date
07:48:29 <chris> gjanssens: oh forgot. just did.
07:49:09 <chris> when partial!=full amount, instead of ** it's now <bold>
07:50:52 <chris> the overpayment is calculated whenever partial!=full amount, seems to be ok
07:50:53 *** David has quit IRC
07:51:29 *** David has joined #gnucash
07:55:27 *** field^Zzz3 has joined #gnucash
07:56:04 *** FH_thecat has joined #gnucash
07:56:22 *** mydogsnameisrudy has joined #gnucash
07:58:04 *** mydogsnameisrudy has quit IRC
08:00:56 *** FH_thecat has quit IRC
08:05:51 *** mydogsnameisrudy has joined #gnucash
08:07:39 *** mydogsnameisrudy has quit IRC
08:17:07 *** mydogsnameisrudy has joined #gnucash
08:18:07 <gjanssens> chris: the amounts look good now, but the signs are still inconsistent RHS
08:18:31 *** mydogsnameisrudy has quit IRC
08:22:16 <gjanssens> For example first line RHS you have a payment split with a net positive amount while line 6 has a payment split with a negative amount. The first comes as explansion of a LHS bill, the latter from an expansion of a LHS refund. So the logic is not consistent on those two paths
08:24:24 <gjanssens> Considering LHS bills increase the balance LHS, they should have positive signs RHS as well, while payments LHS decrease the balance so they should be negative RHS. Credit notes and refunds are the opposite of bills and payments respectively so their sign RHS should reflect that.
08:25:58 <gjanssens> Lastly a cosmetic: should we add a note somewhere on the report to indicate that numbers in bold are inferred, and ideally only show that note if there actually are inferred numbers on the report ?
08:30:46 <chris> gjanssens: I am a bit more a visual person, so, a screenshot with the incorrect amounts would be useful :-/
08:31:14 <chris> a note *can* be added
08:33:08 <gjanssens> chris: Just open the screenshot I added in comment 31 of the bug. It was already visible there, but I missed that myself as I was focused on the bigger issues.
08:33:20 <gjanssens> The lines I refer to still match that screenshot
08:40:30 <chris> I'm guessing you're referring line 1 = LHS 13/01/20 and line 6 LHS = 23/01/20
09:02:39 *** Aussie_matt has quit IRC
09:09:38 <gjanssens> chris: Ah, confusing indeed as I counted RHS, but that has more lines than LHS.
09:10:40 <gjanssens> I meant LHS 01/01/2020 (partial amount RHS = €30) and LHS 04/01/2020 (partial amount RHS = € -120)
09:11:01 <gjanssens> But both are normal payments so logically they should have the same sign RHS
09:12:28 <chris> Ok so, normal Bills and Payments are +ve, CN and Reverse payments are -ve?
09:20:38 <gjanssens> No. Bills and Refuns are +ve, CN and refunds are -ve. You can see that in the LHS debit, credit and balance columns as well. There it is consistent.
09:21:20 <chris> I think you mean: Bills & Payments are +ve, CN and Refunds are -ve
09:21:56 <chris> I think you mean: Bills & Refunds are +ve, CN and Payments are -ve
09:22:13 <gjanssens> Second one indeed.
09:22:20 <chris> Finally
09:22:21 <gjanssens> Sorry for the typo
09:23:09 <gjanssens> And it may be the whole should be inverted. That is, bills and refunds are -ve, cn and payments are +ve. An accountant should confirm that.
09:23:38 <gjanssens> But for the purpose of the report, I think our choice is ok.
09:29:21 <chris> try git pull again
09:32:03 * chris hsan't tested customer/job/employee reports
09:33:33 <gjanssens> chris: this results in a build error: https://pastebin.com/0UViUTcs
09:34:17 <gjanssens> And we should probably add a test custsomer with similar transactions to our test book to check customer behaviour.
09:35:22 <chris> weird build error
09:39:21 * chris doesn't know this error - incidentally I use guile-3.0.5
09:39:58 * gjanssens is still on guile 2.2
09:41:15 <chris> may I suggest rebuild from scratch...
09:41:16 <gjanssens> Oh, never mind. It's an unresolved merge conflict. Apparently you have force-pushed your branch
09:41:50 *** jervin has joined #gnucash
09:42:07 <chris> lol
09:42:15 <chris> snap
09:47:27 <gjanssens> chris: we're very close I believe. Last nitty detail - a prepayment is a payment as well so I'd expect it to have a negative sign RHS. I'll add a current screenshot to the bug.
09:49:09 <chris> done
09:51:21 <gjanssens> Beautiful \o/
09:52:15 <gjanssens> As final icing on the cake, can you add somewhere a line to indicate bold numbers are calculated and don't exactly match underlying split values ?
09:52:36 <gjanssens> (or split amounts or what should be the term)
09:53:24 <chris> bold isn't very clever... a "*" would be better IMO
09:56:46 <gjanssens> True. Bold was your choice, I just went along with it ;)
09:57:28 <fell> bold for calculated feels wrong to me, too. Either italics or a footnote star.
09:58:34 <chris> done
10:04:06 *** jervin has quit IRC
10:05:15 *** jervin has joined #gnucash
10:05:29 <jralls> gjanssens, on the SWIG dependencies, yes. Cmake only knows about the swig-foo.c's dependency on one or two .i files, but if any of the headers that the .i includes changes then swig-foo.c should be regenerated.
10:06:22 <gjanssens> Oh right. That makes sense.
10:06:46 *** r2d3 has joined #gnucash
10:08:21 * chris will mvoe disclaimer under the RHS
10:08:23 <gjanssens> And as I remembered I did fix this for the swig interface files that are part of the bindings already.
10:09:33 <gjanssens> For example I extract the list of header files from the engine target and use that to set these headers as dependencies for the swig target. So any header change in engine should trigger a swig rebuild
10:09:53 <gjanssens> This is not done for all swig interface files yet though.
10:10:04 <gjanssens> Only the ones I moved to bindings.
10:10:12 <gjanssens> So yes, there is still work to do.
10:11:13 *** r2d3 has quit IRC
10:11:25 *** r2d3 has joined #gnucash
10:14:22 <gjanssens> chris: more work for customer invoices :-\
10:14:23 <jralls> gjanssens Unfortunately it's possible to tell cmake about a dependency and have cmake ignore it. I wrestled with that in c++-options where I added a second temporary .i. I haven't been able to convince cmake to regenerate swig-app-utils-guile.cpp unless i `touch app-utils.i`.
10:14:59 <gjanssens> That's... odd
10:15:29 <gjanssens> But again, app-utils.i hasn't had the treatment yet I mentioned.
10:15:46 <chris> gjanssens: ok. will postpone that for tomrorrow. should be a breeze.
10:15:55 <gjanssens> chris: np
10:15:58 <jralls> As for chris's circular dependencies, the only real fix is to untangle them.
10:16:14 <gjanssens> Exactly
10:16:19 <chris> "merge all the .scms" O_o
10:16:44 <jralls> One scm to rule them all and in the darkness bind them?
10:17:11 <chris> it's already a soup... why not hit the blender
10:18:07 <gjanssens> Rearranging all source files such the paths match the module names will only obsolete the use of links, but the installed file interference would not be solved.
10:18:31 <jralls> Is there an equivalent to https://www.ioccc.org for Scheme? Or is it considered unnecessary? ;->
10:18:47 <gjanssens> LOL
10:19:33 <gjanssens> Ever submitted something jralls ?
10:19:52 <jralls> Nope. My brain doesn't work that way.
10:20:20 <gjanssens> Neither does mine... but it's still an amusing website
10:20:44 <chris> er. gnc:pk is my friend.
10:23:31 <jralls> Anyway, just rearranging the files isn't going to fix the problem, and I somehow suspect that a 500,000 line everything.scm isn't either. Separate directories is so autotools. It's not how CMake works. You can see that by watching the way the build hops around as it compiles targets.
10:25:44 <gjanssens> I know. Again rearraging files will only drop the necessity to use links.
10:26:29 <gjanssens> And this is not about cmake, this is about how guile expects files to be arranged. Much like python does actually.
10:27:15 <jralls> It won't, because if foo.scm depends on bar.scm depends on baz.scm depends on foo.scm there's no way to compile them without the symlinks. It doesn't matter what's in which directory.
10:27:23 <gjanssens> Other than that I fully agree the only fix is to factor out circular dependencies.
10:27:39 <gjanssens> I don't agree.
10:27:49 <jralls> Try it. ;-)
10:28:11 <gjanssens> If foo.scm and bar.scm are in the same directory and that directory is part of guile's load path is has to work.
10:28:23 <gjanssens> The issue only happens if you try to go across directories.
10:28:49 <gjanssens> That was my experience while moving files to bindings
10:29:44 <gjanssens> In our current build configuration the source files are not part of the guile lload path.
10:30:00 <gjanssens> They can't be because they're not laid out the way guile expects.
10:30:39 <gjanssens> That's the whole point of why I keep saying rearranging files will help us get rid of the symlinks
10:30:41 <jralls> Exactly. Which is why guild ${SRCDIR}/foo.scm can't find bar.scm without the symlink.
10:31:49 <gjanssens> If foo.scm's module name is just foo, bar.scm's module name is just bar and $SRCDIR is part of guile load path, it will work.
10:32:32 <jralls> Plus foo.scm doesn't say (use-module baz) it says (use-module gnucash baz) so even if SRCDIR was in GUILE_LOAD_PATH it *still* wouldn't find it.
10:33:07 <jralls> Heh, we crossed.
10:33:07 <gjanssens> If foo.scm's module name is (gnucash foo) and bar's name is (gnucash bar) then both files have to be in ${SRCDIR}/gnucash *and* SRCDIR has to be in the load path.
10:33:34 <gjanssens> Yep
10:35:06 <gjanssens> And I suppose you mistyped. foo.scm should never have a module name ending in baz, unless you want pain.
10:35:24 <jralls> Huh?
10:35:59 <gjanssens> You said "Plus foo.scm doesn't say (use-module baz) it says (use-module gnucash baz)..."
10:37:20 <gjanssens> if you tell guile (use-modules gnucash baz) it will search for a file <prefix>/gnucash/baz.[scm,go] with prefix each directory on the load path (well separate load paths for source files and compilled files)
10:38:35 <gjanssens> It won't find module (gnucash baz) in file foo.scm by default. If you want that, you explicitly have to tell it to load file foo.scm first via (load ...) rather than (use-modules ...)
10:38:42 <gjanssens> That's pain
10:38:46 <jralls> Right. And if the dependencies are a nice acyclic graph then you just need to order the compiles so that the .go files are always in BUILDDIR/lib/...
10:39:00 <gjanssens> Agreed
10:39:44 <gjanssens> That's the core issue to solve indeed
10:40:12 <jralls> If they're not acyclic, you have to jump through hoops. The symlinks are one set of hoops that work, adding directories to the load path at build time is a different but IMO no less onerous one.
10:41:57 <gjanssens> Perhaps, though for me that's more in line with the idea of having include directories added to a C target.
10:42:35 <gjanssens> But I'd only do that if we'd have our guile sources in one or two directory trees rather than splattered all over the source tree as it is now
10:43:18 <jralls> Eh, not really, because Guile's scheme doesn't work that way. It doesn't have a separation between declaration and definition.
10:43:48 <gjanssens> I know the comparison is not very good.
10:44:30 <gjanssens> Anyway, I do agree untangling the cyclic dependencies is the better effort to spend energy on and would allow us to drop the links as well.
10:44:51 <jralls> Well, that's the goal of c++-options: To convert the guile that isn't in gnucash/reports to C++. It's proving to be far more complicated than I expected because of the hackish design of the options system.
10:45:29 <gjanssens> Yes, I can imagine.
10:46:18 <gjanssens> There are a few more guile sources in app-utils that are not directly options related. Are you converting those as well in the same effort ?
10:47:03 <jralls> No, I have my hands more than full with just the options. Once I have that done then I'll look at the others.
10:47:25 <gjanssens> And more importantly, can you create a better options system in C++ while allowing a migration from the guile one (and backward compatibilty with the latest 4.x release eventually) ?
10:50:21 <jralls> I doubt it. I can make a more maintainable and more easily understood implementation. Backward compatibility for saved reports limits the design possibilities.
10:52:22 <jralls> At least more easy for me to understand. I worry about others being able to understand C++ templates.
10:52:49 * chris would vote for a one-way 4.x saved-report to 5.x json/xml/anything saved reports data... don't partic think it's worthwhile that 5.x writes 4.x saved-reports-2.7
10:53:09 <jralls> Even though it's just a more rigorous way of expressing the type free-for-all of scripting languages like Scheme and Python.
10:53:09 <gjanssens> Well tbh I have been having second thoughts on our backwards compatibility strategy anyway. So I'd not make that priority.
10:53:21 *** mydogsnameisrudy has joined #gnucash
10:53:59 <chris> 5.x should migrate to new saved-reports, and that's it
10:54:25 * gjanssens is not ready yet to jump back in, he can just do small things here and there for the time being
10:54:48 <gjanssens> So I'm mostly encouraging from the sidelines :)
10:55:22 *** mydogsnameisrudy has quit IRC
10:55:28 * jralls wonders what happened to clawson. Hope his brain didn't explode to badly when he started looking closely at our code. :/
10:56:54 *** sbluhm has joined #gnucash
10:57:04 <jralls> chris, yes, we need a new saved-reports format that isn't scheme code. But we'll also need a migration tool to read the old saved-reports-2.8 and write the new format.
11:00:14 <jralls> gjanssens to some extent we're stuck with the backwards compatibility because we have to change incrementally. We don't have the resources to do a start-from-scratch rewrite and maintain the existing code base.
11:01:01 <gjanssens> Absolutely. I didn't mean to say we should just drop it.
11:01:36 <gjanssens> But I'm not sure it's useful to dig much deeper into this as it's yet another idea no one has time for to implement :/
11:01:49 <jralls> Yeah.
11:02:09 *** sbluhm has quit IRC
11:02:50 <jralls> Or maybe not. If you have an idea for a different approach that would save time overall it's worth considering.
11:03:32 <gjanssens> Ok. It's just a conceptual consideration I have had lately.
11:04:23 <gjanssens> Currently our strategy is that the last version of a stable series should be able to open books from the next stable series.
11:05:04 <gjanssens> That means however that we have to add code to a final release that's not very much user tested and hope that it works.
11:07:00 <jralls> s/not very much/can't be/ because the user has no way to make a file from the next major release.
11:07:30 <gjanssens> A more prudent approach would be the new stable series can read and write both old and new formats and that the old format code remains until the new format has has enough user testing. Typically I'd think one major series should suffice to iron out most bugs we missed.
11:07:50 <gjanssens> Then in the next stable series the old format support could be dropped.
11:08:15 <gjanssens> There are lots of details to figure out for this to possibly work.
11:08:54 <gjanssens> I just came to this consideration while thinking from a user perspective.
11:09:57 <gjanssens> I'm not championing this at all as I don't think it's less work with the code base as it currently is.
11:11:14 <jralls> Actually it sounds like more work. And I'm not sure how the two formats get supported: An extra entry in the backend selection? Save two files, one in each format?
11:12:51 <gjanssens> Our code is not written with evolving data formats in mind, so yes, that's currently not very viable.
11:13:47 <jralls> The XML backend is written to blow up if the data format tries to evolve so we have the virus of KVP instead.
11:15:09 <gjanssens> I have no detailed solution. All I know is others have managed to solve this issue. For example a word processor like Libreoffice supports plenty of formats in different versions. Likely they have some kind of backends for each version.
11:15:30 <gjanssens> LO is heavily xml based, I believe they use xslt files to do much of the conversion between versions
11:15:50 <gjanssens> Don't know if that's s omething we could use or not.
11:15:58 <warlord> They also probably don't use hand-written parsers that blow up if data isn't exactly how it is expected.
11:16:53 <gjanssens> Similarly database upgrades in other applications happen by way of sql queries manipulating db and table layouts.
11:17:15 <jralls> They probably went and learned about XML before writing their format. We didn't, so we don't version the header and we don't have a normative versioned DTD or schema. Having that would make compatibility vastly easier.
11:18:08 <gjanssens> Again, these are only concepts to say in principle those things can be done. As you say gnucash is not in a position to directly apply this.
11:18:17 *** sbluhm has joined #gnucash
11:18:19 <jralls> Phil Longstaff's SQL backend design is brilliant that way. It's versioned and very easy to upgrade the schema.
11:19:27 <gjanssens> So an extra reason to get rid of the xml backend at some point.
11:21:17 <gjanssens> I think we can conclude the idea is nice but not for anytime soon
11:21:24 <jralls> Yes. It's a fine backup and transfer medium. It's a lousy database format. There was a lot of effort in the late 90s and early 00s to make XML databases. It didn't work out well and I don't think any of them are still available.
11:21:46 *** r2d3 has quit IRC
11:22:05 *** r2d3 has joined #gnucash
11:22:08 <jralls> It's actually next on my list after c++options.
11:22:25 <gjanssens> Looking forward to that :)
11:22:58 <jralls> Load the XML into an in-memory SQLite DB and lose Query Object Format.
11:22:58 <gjanssens> jralls: sidenote - you're unusually early on irc ? Are you travelling ?
11:23:54 <jralls> No, I had a PR to merge on Gramps and noticed the conversation and wanted to join in before you got dragged off to something else.
11:25:15 *** celeste has joined #gnucash
11:25:15 *** ChanServ sets mode: +v celeste
11:26:14 *** r2d3 has quit IRC
11:26:23 <gjanssens> Ok. Thanks for your flexibility
11:26:26 *** r2d3 has joined #gnucash
11:26:49 <gjanssens> I'm rarely at a computer in the evenings still these days. So we don't cross very often anymore.
11:27:58 <jralls> How's the construction project going?
11:29:53 <gjanssens> We're making progress. The heatpump was activated thursday, but there's still some configuration that has to happen. Last week I had to cut a few extra holes in the inner walls of the shop (brick walls) so at was dust party all over again.
11:30:43 <gjanssens> The concrete for the new terrace is in place. We now have to wait for the tiles to be delivered. It will probably be finised by the end of August or early September.
11:31:01 <gjanssens> The garden is still a mess and has to wait for the terrace.
11:31:39 <gjanssens> Inside, the workshop ceiling still has to be redone (new panels and repainting).
11:32:02 <gjanssens> And then a few minor corrections here and there.
11:33:04 <gjanssens> The other project is still in the planning phase. We're currently having discussions with the community council about what we can and can't do.
11:33:28 <gjanssens> I expect construction to start there only in a year from now at the earliest.
11:33:42 <gjanssens> So I'll have a break from construction in between.
11:34:36 *** Hamaryns has joined #gnucash
11:34:36 *** ChanServ sets mode: +v Hamaryns
11:35:25 *** Hamaryns has quit IRC
11:37:02 *** sbluhm has quit IRC
11:39:14 <jralls> Sounds like great fun, except for the part about the community council. Planning departments can be such a pain.
11:39:46 *** sbluhm has joined #gnucash
11:41:01 <gjanssens> Yeah. They had a few absurd remarks which we're negotiating on now. With some luck we'll have a positive response on Monday.
11:42:19 <jralls> Here's to luck!
11:45:37 *** jervin has joined #gnucash
11:48:14 <gjanssens> Cheers!
11:51:39 *** Hamaryns has joined #gnucash
11:51:39 *** ChanServ sets mode: +v Hamaryns
12:01:26 *** Hamaryns has quit IRC
12:20:57 *** jervin has quit IRC
12:21:45 *** sbluhm has quit IRC
12:26:41 *** r2d3 has quit IRC
12:26:54 *** r2d3 has joined #gnucash
12:31:12 *** r2d3 has quit IRC
12:31:25 *** r2d3 has joined #gnucash
12:31:30 <warlord> jralls, re loading into in-memory SQLite... YAY!!!!
12:33:10 <warlord> gjanssens, I'm doing a bunch of electrical projects around the house (or more specifically around the yard) -- Low Voltage landscape lighting. But I have to wire in the controllers. So I've been spending hours in my crawl space pulling wires and connecting things! Oh, and drilling holes in my walls to get wires into the crawl spaces. Fun fun fun.
12:33:29 <warlord> I think today is going to be a 3 (or 4) shower day.
12:36:41 *** r2d3 has quit IRC
12:36:54 *** r2d3 has joined #gnucash
12:41:12 *** r2d3 has quit IRC
12:41:26 *** r2d3 has joined #gnucash
12:41:30 <gjanssens> warlord: yeah, I have seen all corners of the house as well. Lowered ceilings, caves,...
12:42:12 <gjanssens> Keeps us young eh ? ;)
12:42:50 <warlord> Yeah, I guess.. But we get to later enjoy the fruits of the labor.. Our front-yard landscape lighting looks really cool!
12:43:05 <warlord> Today I'm working on the side and back yards.
12:43:52 <gjanssens> Nice :)
12:46:32 <warlord> I'm just trying to finish all the "line voltage" work first.. Then we can figure out where to place the lights. I've got one switch to replace, and then I get to tie in my new wires into a junction box in the basement (which means I get to work inside! Yay)
12:54:48 <gjanssens> Good luck with all that.
12:54:58 * gjanssens has to leave now.
12:54:59 <warlord> Thanks. And good luck with your work too.
12:55:00 <gjanssens> See you later!
12:55:02 <warlord> Later!
12:55:05 <gjanssens> Thanks
12:58:20 *** sbluhm has joined #gnucash
13:08:55 *** gjanssens has quit IRC
13:12:54 <jralls> warlord, just stay away from the optical fiber!
13:19:08 *** Bambuzel has joined #gnucash
13:19:08 *** ChanServ sets mode: +v Bambuzel
13:26:42 *** r2d3 has quit IRC
13:26:57 *** r2d3 has joined #gnucash
13:28:06 <jralls> 4
13:36:14 *** r2d3 has quit IRC
13:36:28 *** r2d3 has joined #gnucash
13:54:47 *** Bambuzel has quit IRC
14:07:06 <warlord> jralls, LOL. I will. I'm not really doing much digging, and where I am digging is nowhere near the fiber. But yes, I was thinking of that last night when I *was* digging near it -- about 2 feet away.
14:28:29 <jralls> Too close for comfort!
14:58:54 *** AstronautSurfer has joined #gnucash
14:58:54 *** ChanServ sets mode: +v AstronautSurfer
15:11:41 *** r2d3 has quit IRC
15:11:55 *** r2d3 has joined #gnucash
15:12:36 *** sbluhm has quit IRC
15:16:12 *** r2d3 has quit IRC
15:16:25 *** r2d3 has joined #gnucash
15:36:54 *** r2d3 has quit IRC
15:53:26 *** Bambuzel has joined #gnucash
15:53:26 *** ChanServ sets mode: +v Bambuzel
16:04:58 *** Mechtilde has quit IRC
16:13:18 *** Bambuzel has quit IRC
17:28:11 *** AstronautSurfer has quit IRC
18:26:24 *** User has quit IRC
19:36:12 *** field^Zzz3 has quit IRC
19:57:42 *** g5pw has quit IRC
19:58:30 *** g5pw has joined #gnucash
19:58:31 *** ChanServ sets mode: +v g5pw
20:08:02 *** celeste has quit IRC
20:08:07 *** celeste has joined #gnucash
20:08:07 *** ChanServ sets mode: +v celeste
20:11:38 *** jervin has joined #gnucash
20:46:22 *** jervin has quit IRC
20:48:58 *** Aussie_matt has joined #gnucash
23:04:31 *** AstronautSurfer has joined #gnucash
23:04:31 *** ChanServ sets mode: +v AstronautSurfer
23:07:05 *** AstronautSurfer has quit IRC
23:54:42 *** AstronautSurfer has joined #gnucash
23:54:42 *** ChanServ sets mode: +v AstronautSurfer