2021-06-18 GnuCash IRC logs
00:01:20 *** storyjesse has joined #gnucash
00:01:29 *** jervin has quit IRC
00:02:50 *** `Alison has joined #gnucash
00:17:01 *** celeste has joined #gnucash
00:17:01 *** ChanServ sets mode: +v celeste
00:48:03 *** Mechtilde has joined #gnucash
01:08:15 *** celeste has quit IRC
01:08:39 *** celeste has joined #gnucash
01:08:39 *** ChanServ sets mode: +v celeste
01:29:32 *** fell has quit IRC
01:30:51 *** fell has joined #gnucash
01:30:51 *** ChanServ sets mode: +o fell
01:34:14 *** frakturfreak1 has quit IRC
01:34:28 *** sbluhm has joined #gnucash
01:48:53 *** frakturfreak1 has joined #gnucash
01:56:20 *** itsonlybinary has joined #gnucash
02:06:16 <fell> actions reminds me of ForTran – wrong column = all nonsense. ;-)
02:43:37 *** Bambuzel has joined #gnucash
02:43:37 *** ChanServ sets mode: +v Bambuzel
02:44:54 *** gjanssens has joined #gnucash
02:44:55 *** ChanServ sets mode: +o gjanssens
02:53:03 *** Hamaryns has joined #gnucash
02:53:04 *** ChanServ sets mode: +v Hamaryns
02:55:02 *** Bambuzel1 has joined #gnucash
02:55:03 *** ChanServ sets mode: +v Bambuzel1
02:55:03 *** Bambuzel has quit IRC
02:55:03 *** Bambuzel1 is now known as Bambuzel
02:59:04 *** adymitruk has joined #gnucash
03:22:57 *** DeluxeWarPlaya has joined #gnucash
03:23:10 *** ChanServ sets mode: +v DeluxeWarPlaya
03:23:11 *** DWP has joined #gnucash
03:33:10 *** DWP has quit IRC
04:03:01 *** Hamaryns has quit IRC
04:18:49 <fell> jralls, can i drop https://github.com/Gnucash/gnucash-docs/tree/maint/util/ci or is still something missing in .github/workflows/?
04:19:09 *** Hamaryns has joined #gnucash
04:19:10 *** ChanServ sets mode: +v Hamaryns
04:27:22 *** Mechtilde has quit IRC
04:27:45 *** hive-mind has joined #gnucash
04:34:07 *** Mechtilde has joined #gnucash
04:51:31 *** Hamaryns has quit IRC
05:07:27 *** gnomey has quit IRC
05:10:32 *** celeste has quit IRC
05:10:44 *** celeste has joined #gnucash
05:10:45 *** ChanServ sets mode: +v celeste
05:27:53 *** Shaan7 has joined #gnucash
05:54:04 *** User has joined #gnucash
06:21:44 *** sbluhm has quit IRC
06:54:32 *** storyjesse has quit IRC
06:54:43 *** storyjesse has joined #gnucash
07:23:33 *** Aussie_matt has quit IRC
07:25:50 *** DWP has joined #gnucash
07:26:51 *** DeluxeWarPlaya has quit IRC
07:27:55 <chris> jralls: I won't do the ACCT_TYPE_DEBIT/CREDIT_BALANCE stuff... don't quite get it yet. AFAIU it should be an account property separate from account->type.
07:33:16 <chris> if we don't introduce another property, but simply add more types, how would we distinguish between AFDA (asset contra) and Depreciation (asset contra) -- both would be ACCT_TYPE_DEBIT_BAL
07:34:23 <chris> moreover what's to stop users placing a Debit_bal acct under a Liability acct
07:34:37 <chris> chf / CDB-Man ^ too difficult for me
07:48:50 *** sbluhm has joined #gnucash
08:19:36 *** sbluhm has quit IRC
08:21:54 *** sbluhm has joined #gnucash
08:24:54 *** sbluhm has quit IRC
08:31:11 *** mikey has joined #gnucash
08:31:12 *** ChanServ sets mode: +v mikey
08:31:37 <mikey> is there a keyboard shortcut for checking and unchecking double line view?
08:38:59 <CDB-Man> Chris I think you're over thinking it just a little
08:42:20 <CDB-Man> Debit credit property sites on top of asset/liability/etc
08:42:52 <CDB-Man> For the contra, the suggestion was to use contra types
08:43:14 <CDB-Man> ACCT_TYPE_DEBIT_CONTRA or something equivalent
08:45:56 *** kcin has joined #gnucash
08:49:23 *** Jimraehl1 has joined #gnucash
08:49:34 <chris> CDB-Man: maybe -- this is why I shouldn't be doing the work...
08:50:28 *** Jimraehl1 has left #gnucash
09:15:27 *** field^Zzz3 has joined #gnucash
09:15:51 *** mydogsnameisrudy has joined #gnucash
09:17:16 *** mydogsnameisrudy has quit IRC
09:20:59 *** User has quit IRC
09:27:07 *** kcin1 has joined #gnucash
09:27:32 *** kcin has quit IRC
09:29:35 *** kcin1 is now known as kcin
09:43:29 *** Dagger has joined #gnucash
10:00:13 *** AstronautSurfer has joined #gnucash
10:00:13 *** ChanServ sets mode: +v AstronautSurfer
10:07:29 *** field^Zzz3 has quit IRC
10:39:24 *** ArtGravity has joined #gnucash
10:39:24 *** ChanServ sets mode: +v ArtGravity
10:40:55 *** kcin1 has joined #gnucash
10:41:20 *** kcin has quit IRC
10:42:32 *** {abby} has joined #gnucash
10:45:05 *** kcin has joined #gnucash
10:45:32 *** kcin1 has quit IRC
10:45:35 *** pyrrhomancer has joined #gnucash
10:46:33 *** field^Zzz3 has joined #gnucash
10:46:54 *** kcin1 has joined #gnucash
10:48:05 *** kcin has quit IRC
10:49:24 *** kcin1 is now known as kcin
11:18:13 *** User has joined #gnucash
11:18:27 *** o01eg has quit IRC
11:20:07 *** DWP has quit IRC
11:26:49 *** kcin has quit IRC
11:35:50 *** Bambuzel has quit IRC
11:44:37 <chris> question - if Contra accts are NOT a separate account property, but are account types instead, what would be the friendly Dr/Cr headers?
11:45:02 <chris> would they simply mirror ACCT_TYPE_ASSET/LIABILITY headers?
11:54:54 *** guak has joined #gnucash
11:55:43 <warlord> chris, I think it would depend if we had different Contra sub-account types. For example, a "depreciation" acct type might have different headings than, say, a "rebate" or "tax" contra-acct
11:57:48 <jralls> Right. It would depend at least on whether its a contra-debit-balance or contra-credit-balance. Plus should the word in the middle refer to the contra account's balance or the parent account's balance?
12:01:23 <chris> the account types multiply...
12:03:43 <jralls> fell, actions scripts are python-like in using whitespace instead of braces to delimit blocks. That's different from the Fortran I grew up with: It didn't have blocks.
12:08:49 <jralls> chris, they need to be account types because that's how GC determines where accounts can go in the hierarchy (xaccParentAccountTypesCompatibleWith) and what between what accounts one can transfer splits when deleting an account (xaccAccountTypeCompatibleWith).
12:10:00 <chris> ok. I'd vote for a generic ACCT_TYPE_LEFT_HAND_SIDE and RIGHT_HAND_SIDE :-) CDB-Man would approve \o/
12:11:01 <chris> or ACCT_TYPE_CONTRA_DEBIT / CREDIT
12:11:35 <chris> let me gracefully bow out... too difficult
12:12:55 <jralls> I never intended for you to bow in to that part. You asked CDB-Man yesterday about classifying accounts by whether they're debit or credit balance and I suggested a way that you could do that now without needing the new account types.
12:14:30 <jralls> Besides, you'll still need it with the new account types.
12:17:45 <jralls> The top level ACCT_TYPE_DEBIT/CREDIT_BAL placeholders aren't used everywhere (the US being the main example) and even if they were it's a lot easier, faster, and more reliable to `acct_type & DB_BAL_MASK` than to traverse the parents up to the top level.
12:19:19 <warlord> LEFT vs RIGHT masking would probably be appropriate!
12:19:54 <warlord> (DEB/CRED, whatevs)
12:20:11 <warlord> But it would change the logic of "MAX_ACCT".
12:20:32 <warlord> (or "valid account type" -- based on the way the enum is used)
12:22:01 <jralls> I think you're looking for NUM_ACCOUNT_TYPES; not that there are 4 unused types after that and before ACCT_TYPE_LAST.
12:22:37 <jralls> But that nonsense becomes unnecessary with class enum, the compiler won't let you have an invalid value.
12:24:54 <warlord> true.
12:25:13 <warlord> C vs C++ benefit
12:26:08 <jralls> Oh, you meant that the current enum isn't set up for bitmasking.
12:28:14 *** bertbob has quit IRC
12:31:06 *** storyjesse has quit IRC
12:31:32 <warlord> Yes, and extending it to do so would add empty spaces in the numbering.
12:35:18 <jralls> Lots of them. Iterating over types is a weird thing to do, but GC code has lots of weird things. For example GncTreeViewAccount has an array include_type[NUM_ACCOUNT_TYPES] that it uses to make a bitmap variable: https://github.com/Gnucash/gnucash/blob/maint/gnucash/gnome-utils/gnc-tree-view-account.c#L1235
12:35:45 *** bertbob has joined #gnucash
12:35:45 *** ChanServ sets mode: +v bertbob
12:39:16 <CDB-Man> In terms of directionality, I would say "debit contra account" = an account that is in contradiction to a standard debit account. Example, accumulated depreciation is a contra to the standard debit account of fixed assets
12:39:22 <CDB-Man> Hence its a debit contra
12:40:03 <CDB-Man> A debit contra account is necessarily a credit balance. A credit contra account is necessarily a debit balance
12:42:10 <jralls> CDB-Man, yes, debit-contra-account disambiguates the association. Good.
12:43:45 <warlord> I wonder if it would make sense to change GNCAccountType to an actual class that would allow us to sub-class easily to make custom headers, etc.
12:44:34 <warlord> (to literally mirror the allowed hierarchy in the class hierarchy)
12:49:25 *** jervin has joined #gnucash
12:49:45 <jralls> warlord, a struct instead of an enum? Why would that make sense?
12:51:12 <warlord> Because we could centralize overrides like column headers, enforce the hierarchy, enforce left/right, and other aspects of the accounts by type.
12:51:29 <jralls> Or are you thinking in terms of a template metaprogramming policy class after Alexandrescu?
12:51:35 <warlord> It would make adding a new account type relatively inexpensive.
12:52:07 <warlord> Not familiar with Alexandrescu
12:52:40 <jralls> https://www.worldcat.org/title/modern-c-design-generic-programming-and-design-patterns-applied/oclc/747927476
12:55:57 <warlord> I wasn't thinking about a template per-se. But definitely meta context, to combine all the "what does the AccountType mean" into one place, instead of using an enum. What does the enum buy us (in a C++ context)? If it we a class, we could add GNCAccountType.is_credit()/is_debit()/is_contra()/credit_header()/debit_header(). Etc.
12:56:49 <warlord> Maybe a .is_allowed_child_of() (or is_allowed_parent_of()). Maybe .can_bulk_transfer_to().
12:57:08 <warlord> Yes, this would be a semi-major change.
12:58:42 <jralls> Are you familiar with the is-a/has-a principle from 1990s OO design theory? That would hold that one should subclass Account by AccountType, but that sort of design is discouraged in C++ nowadays.
13:02:56 <jralls> Instead one does template<class AccountType>Account (C++ < 11) and SFINAE or std::variant and if constexpr for dispatch (and in C++20 an improvement on SFINAE called concepts) to make the compiler do most of the work and avoid the expense of virtual dispatch.
13:03:44 *** sbluhm has joined #gnucash
13:04:01 <jralls> https://github.com/jralls/gnucash/tree/c+%2Boptions is an e.g. for the middle version.
13:05:33 <jralls> The Alexandrescu book is an explanation of how to do the first. Nobody's written a concepts book yet because compiler support is still a bit wanting.
13:06:39 *** mikey has quit IRC
13:08:29 *** Mechtilde has quit IRC
13:08:56 *** celeste has quit IRC
13:09:17 *** kcin has joined #gnucash
13:11:31 *** lalbornoz has joined #gnucash
13:12:02 <warlord> I'm debating if we really want to template Account by AccountType as opposed to making it just a class parameter like it is now.
13:12:31 <warlord> (and yes, I am familiar with the is-a/has-a.. But I'm not thinking about it that way, either.
13:12:35 *** lalbornoz has quit IRC
13:12:43 <warlord> Certainly not in terms of Account
13:13:25 <jralls> That's a worthwhile design consideration. It doesn't really matter right now, we're not ready to redesign Account to c++ and I doubt very much that we will be this design cycle.
13:13:50 <jralls> err, development cycle.
13:14:02 *** Mechtilde has joined #gnucash
13:15:14 <warlord> ok
13:16:16 <jralls> But I'd like to get the additional 4 account types into GC5 and resolve that very long running defect, and ISTM converting GNCAccountType to a bitmaskable enum will clean up quite a bit of code plus make balance computations in reports easier.
13:16:42 <warlord> ok
13:16:48 *** celeste has joined #gnucash
13:16:48 *** ChanServ sets mode: +v celeste
13:18:02 <jralls> The only issue there is the cases where the code deems it necessary to ensure that the account type is valid, which changes from it being in a certain range to having only a single bit set.
13:21:25 <jralls> Hmm, maybe a third design, where it's a bit mask for characteristics, e.g. db-bal/cr-bal currency/non-currency, equity/liability, contra, etc.
13:24:59 *** lalbornoz has joined #gnucash
13:26:13 <warlord> Maybe use 8 bits for the "account type number" and upper 24 bits of other flags? Although that doesn't necessarily help with "is it valid" if one could "reset" ACCT_TYPE_BANK with different upper-level bits?
13:29:38 *** Mechtilde has quit IRC
13:32:59 *** sbluhm has quit IRC
13:33:25 *** Mechtilde has joined #gnucash
13:35:51 *** Robert8473 has quit IRC
13:39:11 *** shurke has joined #gnucash
13:41:02 <jralls> I don't think you can change an enum identifier's value. You could flip a bit on a variable initialized with the enum but then comparing it with the enum identifier would fail: account_type would no longer be ACCT_TYPE_BANK.
13:45:41 <jralls> https://godbolt.org/z/9M789hdxz
13:54:16 <warlord> Right.
13:54:59 <warlord> But if you got the AccountType of 0x0115 could you tell if it's a valid account type (matching an enum) quickly? Probably not.
13:56:17 *** marusich has joined #gnucash
13:56:17 *** ChanServ sets mode: +v marusich
14:08:10 <jralls> warlord, separate subject. In light of https://bugs.gnucash.org/show_bug.cgi?id=743999 is there any good reason to barf on weird numeric grouping in input instead of just ignoring it?
14:11:46 <jralls> And by ignoring it I mean ignore grouping_separator completely.
14:14:47 *** kcin has quit IRC
14:16:15 <warlord> I can't think of any reason to barf; I think ignoring the grouping separator while parsing the number is probably a good idea.
14:16:52 *** sbluhm has joined #gnucash
14:18:43 <jralls> Glad you agree.
14:19:21 *** kcin has joined #gnucash
14:22:45 <warlord> Actually, I've probably been bitten by that myself once or twice, grumbled, and retyped the whole number (to remove the comma)
14:37:39 <jralls> So have I. I suspect it's a minor irritation for most users.
14:38:15 <jralls> A clear violation of the strict output, lenient input rule.
14:38:32 <warlord> yeah
14:44:06 *** Pegasus_RPG has quit IRC
14:44:10 *** Pegasus_RPG has joined #gnucash
15:21:16 *** frakturfreak1 has quit IRC
15:21:48 *** frakturfreak1 has joined #gnucash
15:28:07 *** sbluhm has quit IRC
15:36:59 *** angel has joined #gnucash
15:58:13 *** User has quit IRC
15:59:12 *** Mechtilde has quit IRC
16:03:33 *** angel has left #gnucash
16:19:50 *** field^Zzz3 has quit IRC
16:37:15 *** frakturfreak1 has quit IRC
16:50:48 *** fell has quit IRC
16:51:18 *** frakturfreak1 has joined #gnucash
16:58:17 *** frakturfreak1 has quit IRC
17:10:01 *** attronarch has joined #gnucash
17:13:14 *** frakturfreak1 has joined #gnucash
17:16:35 *** frakturfreak1 has quit IRC
17:19:22 *** attronarch has quit IRC
17:28:34 *** kcin has quit IRC
17:37:06 *** frakturfreak1 has joined #gnucash
17:40:06 *** Cork has quit IRC
17:46:38 *** gjanssens has quit IRC
17:49:20 *** Cork has joined #gnucash
17:53:54 *** Bambuzel has joined #gnucash
17:53:54 *** ChanServ sets mode: +v Bambuzel
18:15:16 *** fell has joined #gnucash
18:15:16 *** ChanServ sets mode: +o fell
18:21:34 *** Pegasus_RPG has quit IRC
18:24:07 <fell> .
18:58:56 *** Bambuzel has quit IRC
19:04:09 *** marusich has quit IRC
19:17:10 <fell> jralls, I wonde if I should add make distcheck to gnucas-docs workflow.
19:18:42 <fell> With the exceptiob of dist, it builds all targets, because e.g. make pdf can fail while html succeeds.
19:21:45 <jralls> distcheck is really to make sure that all of the source files make it into the tarball. It's supposed to build only the base and check targets. Are you sure it builds the others?
19:23:47 <jralls> It's not a terrible idea to do a distcheck in CI, I should add it to one of the gnucash actions. chris tends to forget that he needs to add new files to the dist targets.
19:24:06 <jralls> But ISTM that's less of a problem for docs.
19:24:53 <jralls> a bigger issue is making sure that the CI image has everything it needs--fonts in particular--to build the pdf, epub, and mobi targets.
19:25:30 <jralls> That's become an issue on Debian so I switched to Fedora for doing releases.
19:30:10 <chf> Doesn't Debian have all the fonts?
19:34:36 *** Grav has joined #gnucash
19:35:45 *** ArtGravity has quit IRC
19:35:56 <fell> In the ci-logs I saw cyrilic and kanji textx., I assume pulled as dependencies of fop.
19:38:29 <fell> I dint plan to relace the makes, but add it. Most parts are already be built, so it schould not cost too much time.
19:39:33 <fell> With many small stepps it should also be easier for commiters to find their mistake.
19:51:19 <jralls> fell, OK, but don't do that to distcheck. Create another target with a different name. Or maybe better a different job for each. That will spin up a separate Azure instance and they'll go in parallel.
19:51:26 <warlord> it would be nice to make sure "make docs" works in the sources, and that "make" works in gnucash-docs.
19:52:10 <warlord> (technically, "make html pdf epub mobi"
19:52:11 <warlord> )
19:52:29 <jralls> Right, because make by itself doesn't do much.
19:53:42 *** AstronautSurfer has quit IRC
20:05:33 <fell> It din't fail, but I got a strange mixture in the log: ninja dist … configure.ac:–
20:28:38 *** guak has quit IRC
20:41:31 <fell> Our configuration is not very user friendly.. I have to install the woöe stuff despite not planingto use it.
20:51:51 *** ekleog has quit IRC
21:07:38 *** ekleog has joined #gnucash
21:22:13 *** bertbob has quit IRC
21:31:23 *** bertbob has joined #gnucash
21:31:23 *** ChanServ sets mode: +v bertbob
21:49:56 *** ArtGravity has joined #gnucash
21:49:56 *** ChanServ sets mode: +v ArtGravity
22:09:15 *** tonysoar has joined #gnucash
22:24:06 *** tonysoar has quit IRC
22:54:55 *** Peng has joined #gnucash
23:11:09 *** Lyude26 has joined #gnucash
23:20:35 *** ArtGravity has quit IRC
23:28:50 *** Aussie_matt has joined #gnucash
23:59:36 *** storyjesse has joined #gnucash