2021-09-13 GnuCash IRC logs

00:03:24 *** chris has quit IRC
00:05:54 *** David has quit IRC
00:06:13 *** David has joined #gnucash
01:07:00 *** chris has joined #gnucash
01:07:00 *** ChanServ sets mode: +v chris
01:09:08 *** sbluhm has joined #gnucash
01:10:45 *** Mechtilde has joined #gnucash
01:36:08 *** sbluhm has quit IRC
01:47:23 *** frakturfreak has quit IRC
01:50:53 *** fell has quit IRC
01:51:05 *** jervin has joined #gnucash
01:52:13 *** fell has joined #gnucash
01:52:13 *** ChanServ sets mode: +o fell
02:02:03 *** frakturfreak has joined #gnucash
02:12:50 *** Mechtilde has quit IRC
02:14:55 *** FH_thecat has quit IRC
02:43:56 *** jervin has quit IRC
02:44:02 *** jervin has joined #gnucash
02:46:33 *** jervin has quit IRC
03:41:05 *** tomk_dk has joined #gnucash
04:19:31 *** User has joined #gnucash
04:54:43 *** JeffQ has joined #gnucash
04:54:53 *** ChanServ sets mode: +v JeffQ
05:17:19 *** PowaBanga_ has joined #gnucash
05:17:19 *** PowaBanga has quit IRC
05:17:22 *** PowaBanga_ is now known as PowaBanga
05:36:41 *** tomk_dk has quit IRC
06:25:35 *** storyjesse has joined #gnucash
06:52:56 *** default_1 has joined #gnucash
06:56:37 *** celeste has quit IRC
07:10:48 *** chris_ has joined #gnucash
07:10:57 *** chris has quit IRC
07:36:31 *** Mechtilde has joined #gnucash
07:47:17 *** default_1 has quit IRC
08:34:16 *** Hamaryns has joined #gnucash
08:34:16 *** ChanServ sets mode: +v Hamaryns
08:38:18 *** Pegasus_RPG has joined #gnucash
08:39:20 *** storyjesse1 has joined #gnucash
08:43:25 *** Hamaryns has quit IRC
08:43:51 *** storyjesse1 has quit IRC
08:45:06 *** bertbob has quit IRC
09:02:05 *** bertbob has joined #gnucash
09:02:05 *** ChanServ sets mode: +v bertbob
09:06:13 *** chris_ is now known as chris
09:08:49 *** sbluhm has joined #gnucash
10:04:20 *** sbluhm has quit IRC
10:18:43 *** jervin has joined #gnucash
10:18:44 *** Pegasus_RPG has quit IRC
10:25:44 *** jervin has quit IRC
10:39:39 *** storyjesse has quit IRC
10:45:28 *** David has quit IRC
10:56:33 *** sbluhm has joined #gnucash
10:58:19 *** guak has joined #gnucash
11:03:14 *** chris has quit IRC
11:03:21 *** chris has joined #gnucash
11:03:21 *** ChanServ sets mode: +v chris
11:04:21 <chris> warlord: in the APAR register, clicking on the "P" (vs "I") makes it change to "I" - is this intentional?
11:04:49 *** Mechtilde has quit IRC
11:05:33 *** sbluhm has quit IRC
11:10:00 <warlord> chris, I don't think there is any way to prevent that.
11:11:11 *** Pegasus_RPG has joined #gnucash
11:14:55 <chris> makes you wonder what goes on behind the scenes...
11:16:23 *** gjanssens has joined #gnucash
11:16:23 *** ChanServ sets mode: +o gjanssens
11:16:44 <chris> maybe gjanssens knows
11:16:52 <chris> gjanssens: in the APAR register, clicking on the "P" (vs "I") makes it change to "I" - is this intentional?
11:17:02 <chris> (Hi Geert!
11:17:03 <chris> )
11:18:26 <warlord> chris, I don't understand the question..
11:18:45 <warlord> AR/AP accounts are not supposed to be used by the user.
11:19:02 <warlord> I wanted a way to display Invoice vs Payment for a particular transaction.
11:19:17 <chris> does clicking P->I actually change the type from TXN_TYPE_PAYMENT to TXN_TYPE_INVOICE?
11:19:27 <warlord> But there is no way to create a non-user-manipulatable cell
11:19:37 <warlord> Probably
11:19:44 <warlord> I'd have to look at the underlying code.
11:20:33 <chris> then this is likely to break things
11:20:42 <chris> because I doesn't change back to P
11:20:53 <chris> gtg
11:20:56 <warlord> once it is I the transaction gets locked.
11:21:02 <warlord> so you CAN'T change it back to P!
11:21:09 <chris> kaBOOM
11:21:34 <warlord> Well, "DONT DO THAT!"
11:21:48 <warlord> "Thou shalt not enter ARAP Transactions by Hand"
11:22:06 <warlord> That has been a commandment since the biz features were introduced.
11:22:32 <chris> still there shouldn't be a way to entrap yourself like that
11:23:17 <warlord> This "gotcha" has been in the code for nearly 20 years.
11:23:30 <warlord> People quickly learn "Don"t Do That"
11:23:46 <warlord> It's like getting your fingers caught in a mousetrap -- you only make that mistake ONCE.
11:26:15 *** sbluhm has joined #gnucash
11:35:27 <jralls> warlord wrote "But there is no way to create a non-user-manipulatable cell". Sure there is. Write a cell editor that doesn't do anything and assign it to the cell.
11:37:21 <warlord> At the time the goal was not to introduce new cell types.
11:37:35 <warlord> (keep in mind, this was 20 years ago).
11:38:54 <warlord> And again, ARAP were supposed to be "mostly view only", but there wasn't a good way to do that. (I say "mostly" because users might need to delete intra-ARAP movement transactions if they needed to clear out payments, etc.
11:45:38 <jralls> I guess "good" is defined as "without writing any code", because while non-trivial it's not that difficult to make insensitive all of the controls on a register except Delete Transaction.
11:47:03 <jralls> So I suspect it's more of a philosophical question about how far to go to protect against users doing things they're not supposed to.
11:50:06 *** Pegasus_RPG has quit IRC
12:02:23 <jralls> warlord, separate subject: How deep is your knowledge of pthreads?
12:02:51 <chris> the problem IMV is that clicking P (or ? from a simple bank<->APAR) to make it I seems to have a purpose... now gtg really
12:03:17 *** PhotoMan has quit IRC
12:03:32 *** PhotoMan has joined #gnucash
12:03:32 *** ChanServ sets mode: +v PhotoMan
12:08:00 *** Pegasus_RPG has joined #gnucash
12:08:37 *** PhotoMan has quit IRC
12:08:52 *** PhotoMan has joined #gnucash
12:08:52 *** ChanServ sets mode: +v PhotoMan
12:09:21 <Simon> being unable to change it back seems like a bug
12:10:36 *** Pegasus_RPG1 has joined #gnucash
12:11:00 *** Pegasus_RPG has quit IRC
12:11:00 *** Pegasus_RPG1 is now known as Pegasus_RPG
12:23:14 *** sbluhm has quit IRC
12:27:35 *** Mechtilde has joined #gnucash
12:30:17 *** kcin has joined #gnucash
12:39:32 <warlord> jralls, I would say medium-deep. I've never actually *implemented* threads (although I have a friend that did). I've certainly used them.
12:39:58 <warlord> chris, except you've already violated rule #1: Thou Shalt Not Enter Transactions in ARAP.
12:40:11 <warlord> Simon, you shouldn't be touching ARAP. Perior.
12:40:16 <warlord> Period.
12:41:05 <jralls> warlord: https://bugs.gnucash.org/show_bug.cgi?id=798250 seems to be a pthreads malfunction. I can replicate it in F33 as well as macOS.
12:41:14 *** ArtGravity has joined #gnucash
12:41:14 *** ChanServ sets mode: +v ArtGravity
12:41:44 <jralls> Frustratingly it didn't replicate in the debugger after I installed the glibc debugging symbols.
12:46:46 *** guak has quit IRC
12:47:32 *** guak has joined #gnucash
12:48:18 *** guak has quit IRC
12:50:33 *** guak has joined #gnucash
12:58:35 <warlord> jralls, GnuCash isn't really thread-safe. It's possible that two "threads" are banging on the same FD?
13:00:45 <Simon> I don't use AR/AP at all
13:02:19 <warlord> Simon, then you'll never run into this.
13:02:30 <Simon> jralls: if it's using a pipe, is the pipe buffer full?
13:05:06 <jralls> There's an understatement. I wouldn't think so: The thread in question sets up a pipe and gives the read FD to a thread that reads it and calls gzwrite with what it reads. The write FD is passed to fdopen, the result of which goes to the write-the-book, which duly calls fclose on it when it's done.
13:05:42 <jralls> Since the FDs are made by the pipe() call they should be invisible to everything else.
13:06:36 <Simon> could something have forked?
13:08:35 <jralls> Simon, to the first question, no, the pipe is empty and widowed, but read isn't getting the EOF. To the second, yes, webkit forks & execs two processes, one for webkit and the other for javascript. That happens at startup, long before save is called or the report is run.
13:14:38 <warlord> is it close()ed before it is widowed?
13:17:57 *** Jeanl has joined #gnucash
13:19:58 <jralls> warlord, I don't understand the question. Calling fclose on the write FILE* is supposed to fflush it then widow the pipe according to pipe(2) and reading the widowed pipe is supposed to EOF the read FD.
13:21:03 *** Jeanl has quit IRC
13:27:59 <warlord> Well, it could have been widowed by the thread exiting without closing it.
13:29:41 <jralls> Oh, OK. No, both threads are active. The main thread is sitting in g_thread_join waiting for the gz thread to finish and the gz thread is sitting in read() waiting for more data from the pipe.
13:30:00 *** Pegasus_RPG has quit IRC
13:42:49 <jralls> At least I think that's what it's doing, the top instruction is a https://sourceware.org/glibc/wiki/SyscallWrappers.
13:43:57 *** sbluhm has joined #gnucash
13:44:44 <jralls> Interestingly whatever the problem is independent of compiler, c runtime, and kernel since macOS and F33 differ on all of them.
13:49:32 <Simon> does it require that you use compression?
13:50:38 <jralls> Yes. If the compression preference is disabled then it just tells libxml2 to write the file directly, no pipe.
13:50:43 *** sbluhm has quit IRC
13:52:53 <Simon> happens to me too on Ubuntu 18.04
13:53:51 <Simon> gnc_book_write_to_xml_file_v2/wait_for_gzip/g_thread_join
13:54:49 <Simon> gz_thread_func/read
13:56:21 <Simon> jralls: the pipe is open for writing in the webkit process
13:56:32 <Simon> https://s85.org/lXbsMUqM
13:56:39 <jralls> That should be a different pipe!
13:56:55 <Simon> simon 32626 0.0 0.0 85790544 45544 pts/10 SLl+ 18:52 0:00 /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess 18 33
13:57:10 <Simon> looks like it is, but it must have forked it after opening it
13:59:19 <Simon> it looks like it's creating the webkit process on demand?
14:00:05 <Simon> there's an O_CLOEXEC for pipe2() but pipe2() isn't part of POSIX
14:00:38 <jralls> Hmm. Maybe. That would explain why the read isn't getting an EOF. With the dup'd write FD the pipe isn't widowed.
14:01:26 <jralls> Don't care if it's posix as long as it's implemented in all flavors of pthread.
14:01:47 <Simon> well, it says "Linux-specific"
14:02:17 <Simon> looks like it's available on at least FreeBSD
14:02:45 <Simon> but not on macOS
14:03:44 <Simon> you could use socketpair(), because a shutdown will work with multiple writers
14:05:19 <jralls> We can use C++ here, any libstdc++ or boost alternatives that you know of?
14:07:44 <Simon> I'm a bit surprised macOS has no way to deal with this, not being able to use pipe is inconvenient
14:08:07 <Simon> you are in control of the fork() code, so you could close() everything else
14:09:05 <jralls> Maybe we can. macOS *does* have O_CLOEXEC just not an automagic way of setting it with open or pipe. I'll try fcntl(fd, O_CLOEXEC) immediately after calling pipe().
14:09:21 <Simon> alternatively just set up a rw semaphore? read lock for pipe(), write lock for fork()
14:09:41 <jralls> I'm not sure we are in control of the fork. I think libwebkit does that on its own.
14:09:44 <Simon> yes you can do that but it's going to be fnctl() facing with fork()
14:09:56 <Simon> fcntl*
14:10:05 <jralls> sorry, facing with?
14:10:23 <Simon> "Apple added O_CLOEXEC to OS X in 10.7"
14:10:29 <Simon> sorry, "racing"
14:10:43 <Simon> you can't guarantee it doesn't go 1. pipe, 2. fork, 3. fcntl
14:11:01 <jralls> Can too: std::atomic.
14:11:47 <jralls> GnuCash's mac_os_x_version_min is 10.13 because of C++17.
14:12:00 <Simon> then it should have O_CLOEXEC on pipe2()
14:12:28 <jralls> It doesn't have pipe2. Or at least it doesn't have a man page for it.
14:13:44 <jralls> Nor is it in any header.
14:14:11 <Simon> then you could use socketpair() instead, as long as it's blocking
14:14:45 <Simon> searching for this issue just finds lots of people using fcntl() and ignoring the problem with threads
14:15:13 <Simon> https://bugs.python.org/issue26343#msg260151 has the claim that it exists
14:15:30 <Simon> https://developer.apple.com/library/archive/releasenotes/General/MacOSXLionAPIDiffs/Kernel.html it was added to fcntl.h
14:15:37 <Simon> but that's just O_CLOEXEC
14:16:08 <jralls> Right, that's what I said.
14:16:46 <jralls> O_CLOEXEC, no pipe2.
14:17:28 <Simon> oh, socketpair() can't set flags on creation either
14:18:11 <Simon> nvm, it doesn't need to because you can shutdown() it
14:20:00 <jralls> I'd rather use something a little higher level if possible.
14:22:38 <Simon> Boost.Asio can do socketpair(): https://www.boost.org/doc/libs/1_77_0/doc/html/boost_asio/reference/local__connect_pair.html
14:23:15 <Simon> but you're looking at a lot more overhead because that's asynchronous by design... and not fork() safe either
14:23:20 <Simon> you have to tell it before/after you fork
14:23:50 <Simon> socketpair() is an almost drop-in replacement for pipe() because you just need to shutdown() the writer before close()
14:24:17 <Simon> https://mail.gnome.org/archives/gtk-devel-list/2015-March/msg00052.html suggests glib is using pipe2
14:24:32 <Simon> https://mail.gnome.org/archives/gtk-devel-list/2015-March/msg00056.html but with fallback cases
14:28:46 <jralls> Yup: https://developer-old.gnome.org/glib/stable/glib-UNIX-specific-utilities-and-integration.html#g-unix-open-pipe
14:29:18 *** sbluhm has joined #gnucash
14:31:12 <jralls> And the fallback calls fcntl.
14:32:00 *** jervin has joined #gnucash
14:36:23 <jralls> Hmm, I don't think there's really a race to worry about. The report can't get launched until try_gz_open returns and gnc_book_write_to_xml_filehandle_v2 iterates main_loop to update the progressbar.
14:37:46 <jralls> I think it's safe to just replace pipe() with g_unix_open_pipe().
14:45:23 <jralls> Nope, that won't work, it won't build on mingw64. I'll have to just put the fcntl in.
15:04:31 *** raeburn has joined #gnucash
15:14:06 *** Mechtilde has quit IRC
15:19:31 *** kcin1 has joined #gnucash
15:19:55 *** kcin has quit IRC
15:22:29 *** kcin has joined #gnucash
15:22:31 *** kcin1 has quit IRC
15:55:45 *** frakturfreak has quit IRC
15:56:35 *** frakturfreak has joined #gnucash
15:57:02 *** JeffQ has quit IRC
16:01:43 <jralls> That fixes it. Simon, thanks for your help.
16:17:26 <warlord> Yay!
16:31:28 *** User has quit IRC
16:35:17 *** sbluhm has quit IRC
16:44:50 *** gjanssens has quit IRC
17:11:40 *** kcin has quit IRC
19:07:39 *** Mechtilde has joined #gnucash
19:10:39 *** Mechtilde has quit IRC
19:48:05 *** ArtGravity has quit IRC
20:49:57 *** guak has quit IRC
21:17:56 *** storyjesse has joined #gnucash
23:05:50 *** Mechtilde has joined #gnucash
23:08:51 *** Mechtilde has quit IRC
23:19:29 *** fell has quit IRC
23:20:19 *** fell has joined #gnucash
23:20:20 *** ChanServ sets mode: +o fell
23:56:21 *** fell has quit IRC