2015-06-01 GnuCash IRC logs

00:44:05 *** Jimraehl1 has joined #gnucash
00:51:45 *** MechtiIde has joined #gnucash
01:05:30 *** ErKa has quit IRC
01:16:02 *** O01eg has quit IRC
01:28:56 *** CDB-Man has joined #gnucash
01:30:03 <CDB-Man> hmm, so ive managed to setup a stocks account, and created a purchase. is there a way to record a paper gain on the increase in price at the end of the year?
01:36:37 *** MechtiIde has quit IRC
01:51:42 *** MechtiIde has joined #gnucash
02:04:05 *** StuM has joined #gnucash
02:06:02 *** MechtiIde has quit IRC
02:07:26 *** StuM has quit IRC
02:17:59 <CDB-Man> also, it seems not to be recognizing that i installed finance:quote after running the windows install script
03:29:58 *** dgm has joined #gnucash
03:56:27 *** gjanssens has joined #gnucash
03:56:27 *** ChanServ sets mode: +o gjanssens
04:11:32 <dgm> Hi there! Have some spare hours weekly for coding.
04:12:11 <gjanssens> dgm Wonderful
04:12:15 <gjanssens> What are your intentions ?
04:12:20 <dgm> As site and wiki is not accessible, is there a way to read on building on Mac?
04:13:33 <dgm> Well, my clear needs are: multicurrency accounts in personal bookkeeping + plugins for different bank access
04:14:27 <gjanssens> dgm: the main site is indeed down
04:14:39 <dgm> And also - a complimentary Android app to register transactions on the go with syncing.
04:14:45 <gjanssens> The wiki however is not (at least I can connect): http://wiki.gnucash.org/wiki/GnuCash
04:15:10 <dgm> any host in *.gnucash.org does not resolve for me.
04:15:43 <dgm> MBP-DGM:~ dennis$ dig wiki.gnucash.org
04:15:43 <dgm> ; <<>> DiG 9.8.3-P1 <<>> wiki.gnucash.org
04:15:43 <dgm> ;; global options: +cmd
04:15:45 <dgm> ;; Got answer:
04:15:46 <dgm> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19531
04:15:48 <dgm> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
04:15:50 <dgm> ;; QUESTION SECTION:
04:15:52 <dgm> ;wiki.gnucash.org. IN A
04:15:54 <dgm> ;; Query time: 189 msec
04:15:56 <dgm> ;; SERVER: 192.168.0.1#53(192.168.0.1)
04:15:58 <dgm> ;; WHEN: Mon Jun 1 10:16:27 2015
04:16:00 <dgm> ;; MSG SIZE rcvd: 34
04:19:25 <gjanssens> Hmm, looks like the crash of the main server also brought down the nameservers for the gnucash domain
04:19:52 <gjanssens> Only one nameserver is currently alive, but it's the fourth in the list so maybe your dns resolver is never reaching it
04:20:00 <gjanssens> Here is what I get:
04:20:04 <gjanssens> $ dig wiki.gnucash.org
04:20:05 <gjanssens> ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> wiki.gnucash.org
04:20:07 <gjanssens> ;; global options: +cmd
04:20:08 <gjanssens> ;; Got answer:
04:20:10 <gjanssens> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62745
04:20:11 <gjanssens> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
04:20:13 <gjanssens> ;; OPT PSEUDOSECTION:
04:20:14 <gjanssens> ; EDNS: version: 0, flags:; udp: 4096
04:20:16 <gjanssens> ;; QUESTION SECTION:
04:20:17 <gjanssens> ;wiki.gnucash.org. IN A
04:20:19 <gjanssens> ;; ANSWER SECTION:
04:20:20 <gjanssens> wiki.gnucash.org. 32167 IN A 204.107.200.65
04:20:57 <gjanssens> You could temporarily add "204.107.200.65 wiki.gnucash.org." in the hosts file on your system to bypass dns
04:21:10 <gjanssens> I'm not sure how that's done on OS X though
04:21:48 <gjanssens> Then this wiki page will explain how to build on OS X: http://wiki.gnucash.org/wiki/MacOSX/Quartz
04:23:10 <gjanssens> I'd love to discuss about your coding ideas but have to leave now. If you're around later I'll try to come back to it
04:23:18 *** gjanssens is now known as gjanssens_
04:27:15 *** fabior has joined #gnucash
04:37:10 <dgm> Thanks! /etc/hosts should work.
05:58:25 *** fell__ has joined #gnucash
06:00:33 *** fell_ has quit IRC
06:06:02 *** jessie23 has joined #gnucash
06:09:21 <jessie23> Hi. Does somebody know where i can find the file for the "saved report configurations" on my linux debian? I want to move my gnucash to a new system
06:21:32 <jessie23> I could find it. FYI: The file was here: ~/.gnucash/saved-reports-2.4
06:21:42 *** jessie23 has quit IRC
06:44:12 <warlord> gjanssens_. dgm: the issue is most likely DNSSEC.. The gnucash.org DNSSEC signatures have expired.
06:45:49 <dgm> warlord: Could be. On another host I can dig wiki.gnucash.org normally.
06:49:55 <warlord> if you do a
06:50:05 <warlord> 'dig +dnssec gnucash.org' you'll see the expiration
06:53:30 <dgm> ls
06:53:43 <dgm> oops, sorry :)
06:53:57 <warlord> :)
06:59:36 *** Jimraehl1 has left #gnucash
06:59:51 *** Jimraehl1 has joined #gnucash
07:00:57 <kimmo2> ihtfp
07:01:33 <warlord> kimmo2: :)
07:05:46 *** pacon has joined #gnucash
07:07:58 *** fabior has quit IRC
07:18:27 <warlord> gotta run.. back in a while.
07:18:42 *** warlord has quit IRC
07:26:08 *** uXus has quit IRC
07:28:39 *** uXus has joined #gnucash
07:35:29 *** fabior has joined #gnucash
07:41:00 *** lwells has quit IRC
07:43:50 *** pacon has quit IRC
07:44:01 *** lwells has joined #gnucash
07:45:29 *** andy has quit IRC
07:48:32 *** pacon has joined #gnucash
07:48:48 *** rickoehn has joined #gnucash
07:58:27 *** andy has joined #gnucash
08:24:20 *** himaxx has joined #gnucash
08:40:49 *** himaxx has quit IRC
08:45:09 *** StuM has joined #gnucash
08:47:56 *** uXus has quit IRC
08:49:01 *** pacon has quit IRC
09:04:19 *** dgm has quit IRC
09:10:31 *** wizkid238 has quit IRC
09:14:45 *** dgm has joined #gnucash
09:16:17 *** andy has quit IRC
09:21:03 *** ErKa has joined #gnucash
09:24:04 *** wizkid238 has joined #gnucash
10:03:53 *** andy has joined #gnucash
10:10:50 *** StuM has quit IRC
10:38:43 <dgm> Well... After few hours reading sources... Why not C++ from the very beginning?
10:39:14 <dgm> Guess, need to put some efforts on moving things to C++
10:40:24 <dgm> http://wiki.gnucash.org/wiki/C%2B%2B states, that Qof is the place to start with, although it seems like a lot of things were done there already and wiki is out-of-date
10:41:16 <dgm> Any clue where I can grab quite isolated C to C++ task?
10:43:25 *** himaxx has joined #gnucash
10:43:32 *** dgm has quit IRC
10:44:10 *** himaxx has quit IRC
11:41:28 *** O01eg has joined #gnucash
11:43:00 *** fabior has quit IRC
11:58:04 *** fabior has joined #gnucash
12:04:14 *** Krzysiek_K has joined #gnucash
12:05:49 *** dgm has joined #gnucash
12:11:12 <dgm> Internet is back. Have I missed an answer to "Where to start on c->c++" ?
12:17:05 <jralls> dgm: Nope. I just got here, and ATM I'm the C++ guy.
12:17:25 <dgm> Hi!
12:20:25 <jralls> dgm: There are still some opportunities in QOF, though they're not very isolated. We started with QOF because it's the bottom of the dependency stack.
12:21:32 <jralls> dgm: If you want isolated, look at app-utils and import-export, especially anything written in Scheme.
12:21:51 <dgm> jralls: Ok, will check that.
12:22:22 <dgm> Am I rightthat cutecash is an early beginning of the gnucash 3.x?
12:22:35 <dgm> Am I right that cutecash is an early beginning of the gnucash 3.x?
12:24:51 <jralls> dgm: No. Cutecash is an experimental effort by cstim to demonstrate using Qt and CMake instead of Gtk+ and Autotools. But it's backwards because it has to wrap our existing C library in C++ to work with Qt. We're working on replacing the C library with C++, wrapping it in C to keep the other parts working.
12:25:57 <dgm> Ah, I see. Thanks
12:27:05 *** MechtiIde has joined #gnucash
12:45:18 *** himaxx has joined #gnucash
12:48:51 *** himaxx has quit IRC
13:05:24 *** Krzysiek_K has left #gnucash
13:34:54 *** warlord has joined #gnucash
13:34:55 *** gncbot sets mode: +o warlord
13:46:25 *** rickoehn has quit IRC
13:47:32 *** rickoehn has joined #gnucash
13:56:51 *** warlord has quit IRC
13:58:57 <gjanssens_> jralls, dgm: regarding cutecash/cmake - what's the advantage of cmake over autotools ?
13:59:41 *** warlord has joined #gnucash
13:59:42 *** gncbot sets mode: +o warlord
13:59:54 <gjanssens_> jralls: in my (currently rare) free time I'm still working on a conversion of the csv importer to c++
14:00:02 <dgm> Better MS VS support AFAIR
14:00:26 <gjanssens_> Got side-tracked by writing unit tests first in that area
14:00:31 *** gjanssens_ is now known as gjanssens
14:01:04 <gjanssens> dgm: if you can help with the c->c++ conversion that would be most welcome!
14:01:44 <warlord> dgm: what do you mean by "VS support"?
14:02:27 <gjanssens> hi warlord
14:02:33 <dgm> gjanssens: C/C++ - Have not much time as well, OTOH do really like gnucash and see its codebase is barely maintainable (IMHO)
14:02:58 <gjanssens> yes that's true
14:03:19 <gjanssens> it's high time we clean up
14:03:41 <gjanssens> warlord, linas: what's the current status of the web server ?
14:03:45 <dgm> warlord: some out of the box macros that support using MS compiler instead of MinGW. It was quite some time ago, so I can be wrong here.
14:04:45 <gjanssens> dgm: even small contributions are welcome (the kind of stuff that can be done in "some spare hours a week")
14:05:01 <gjanssens> we don't expect a minimum productivity quota ;)
14:05:13 <dgm> :)
14:05:18 <gjanssens> After all we're all volunteers
14:05:35 <dgm> yup.
14:08:05 *** StuM has joined #gnucash
14:09:05 <linas> gjanssens I am in the middle of building a brand new box. I gave up rescuingthe old server
14:09:36 <linas> I might have the basic website up later today if all goes well
14:10:29 <gjanssens> linas: ok. Good luck.
14:11:15 *** StuM has quit IRC
14:12:37 <gjanssens> linas, warlord: I was thinking that perhaps it would be good to have multiple instances of the webserver running around the globe
14:12:45 <gjanssens> It's a static website after all
14:13:05 <linas> There is a mirror in australia
14:13:09 <gjanssens> If you're interested, I'm running a public webserver in Europe
14:13:24 <linas> I'm trying to set up the new website with lxc
14:13:34 <linas> so that maybe next time, rescue will be much easier
14:13:38 <gjanssens> Ok
14:13:51 <linas> any lxc poiters/tips ? do you use it?
14:14:00 <gjanssens> unfortunately no
14:14:24 <gjanssens> I'm mostly working on Fedora/Centos
14:14:33 <linas> ah, I've used docker for some things, and its marvelous, I'm gonna see if lxc is "even better"
14:14:34 <gjanssens> These guys are all raving about Docker
14:14:48 <gjanssens> But haven't tried either
14:15:18 <linas> For certain things, dcker really is great/revolutionary. Not sure if its for everything yet
14:15:48 <gjanssens> From what I've read there are still a number of security issues to tackle
14:16:11 <gjanssens> If you want really strong separation between containers
14:16:19 <linas> I don't think security is worse than a bare-metal server
14:16:30 <gjanssens> That's what I think as well
14:17:01 <gjanssens> That's mostly a concern for ISP style configurations in which each customer would get its own container
14:17:34 <linas> yes.
14:17:42 <gjanssens> That australian mirror, what's its domain name ?
14:17:55 <gjanssens> (url)
14:18:06 <linas> here I'm trying to solve the problem that the webserver data was trapped on a disk drive on a server that won't boot.
14:18:27 <linas> so its not just the staic pages, its also the apach.conf and the port-knocking and dns
14:19:15 <gjanssens> DNS is on the same server ?
14:19:23 <linas> my backup of the config files is scatter-shot ... and besides, wouldn't be exactly the same when installing a new server.
14:19:40 <linas> I have to physical boxes, dns is on both
14:19:44 <linas> two
14:19:48 <gjanssens> indeed
14:19:48 <gjanssens> ok
14:20:14 <linas> and warlord has a dns mirrir for gnucash in boston
14:20:26 <gjanssens> yes, I saw that in dns
14:20:35 <gjanssens> there are 5 ns servers for gnucash.org
14:20:36 <linas> If you are good with dns, you could mirror in europe
14:20:50 <linas> five ? should be only three
14:21:39 <linas> oh
14:21:49 <linas> weird.
14:21:53 <gjanssens> ns1.gnucash.org. ns.gnucash.org. ns1.linas.org. ns.linas.org. fly-by-night.ihtfp.org.
14:21:58 <linas> I don't recall setting up ns1 ...
14:22:47 <gjanssens> Currently I don't have a public DNS server yet
14:22:47 <linas> I'll have to figure out how an ns1 appeared.
14:22:58 <gjanssens> It's on my list of things to implement
14:23:20 <linas> sysadmin is both easy and hard.
14:23:21 <gjanssens> When it's up, I'll ping you again on the offer to host a European mirror
14:23:37 <linas> setting up dns is not hard .. but then it takes 5 or 10 hours a year to admin it.
14:23:53 <gjanssens> I have implemented some dns servers in the past
14:24:05 <linas> which doesn't sound like a lot, except that its always on some emergency basis
14:24:10 <gjanssens> But that customer has moved to rented hosting and didn't need one anymore
14:24:17 <gjanssens> Heh, got that...
14:25:22 <gjanssens> warlord: I recently went through the list of notes gnc bot is keeping
14:25:39 <gjanssens> Most of them seem horribly outdated (some as much as 8 years old)
14:25:52 <gjanssens> How about cleaning those out ?
14:26:24 <gjanssens> I have a list sorted by age to make it easier for you if you like
14:29:35 <warlord> dgm: the issue with that is the requirement for supporting multiple build systems.. And most of th devs are NOT working on MS. So MSys lets us develop on Linux/Mac and then it "just works" on Windows... without requiring a windows dev env in order to, e.g. add a new source file.
14:31:09 <warlord> linas: there is still the issue of the DNSSec Cron job not firing...
14:31:15 <warlord> (last signed on May 11th)
14:31:43 <warlord> gjanssens: Email me the list and I'll clear them out later this week.
14:31:47 <linas> warlord, is that taking down your stuff too?
14:31:51 <dgm> warlord: I do remember our setup allowed building cross-platform, including gcc on Linux, clang on Mac OS X and MS VC++ on Windows. All from same sources and with no efforts
14:31:54 <linas> should I fix dnssec first?
14:32:13 <warlord> linas: yes.. it's causing lots of failures because people with validating dns clients cannot resolve any gnucash.org name.
14:32:29 <linas> ok
14:32:45 <warlord> dgm: gcc and clang, yes.. but never vc
14:32:55 <warlord> vc isn't command-line driven
14:33:10 <dgm> warlord: c'mon! it is.
14:33:26 <warlord> Show me an automake makefile that calls VC
14:34:13 <dgm> not using automake. The compiler/linker themselves are command-line
14:35:47 <warlord> My point is that the build system already requires auto-tools... and that's not going to change. So you still need mingw/msys in order to get the shell to run the configure scripts.. But you're welcome to figure out how to ./configure with the compiler == vc++
14:36:00 <warlord> But we're not going to support multiple build systems..
14:36:01 <dgm> CMake generates appropriate set of commands for a toolchain.It is not always Make or autotools behind it.
14:36:18 <warlord> we dont use cmake
14:36:33 <warlord> (or rather -- GNUCASH does not use cmake)
14:36:47 <dgm> I'm not an advocate for it either :)
14:38:14 <dgm> As of app-utils: is it mostly a massive key/value data + routines for default preferences?
14:39:23 <warlord> there's a lot of utility code in app-utils... Can you be more specific?
14:39:40 <warlord> (not sure what "as of app-utils" means)
14:40:32 <gjanssens> warlord: my earlier question on cmake vs autotools was actually to gauge if it'd be worth it converting gnucash to cmake
14:40:52 <gjanssens> the cutecash experiment has already done this for the non-gui parts
14:40:54 <warlord> I dont know...
14:41:11 <gjanssens> So if cmake really has important advantages, that could be worth it
14:41:33 <gjanssens> I don't know cmake though so I can't give useful input on that
14:41:37 <warlord> The 'advantage' is that cmake will generate "local build system" configs.
14:42:01 <dgm> warlord: jralls suggested to take a look at app-utils to choose something isolated for c->c++ conversion
14:42:28 <gjanssens> warlord: just sent you the list of notes per e-mail
14:42:52 <warlord> gjanssens: thanks
14:43:24 <warlord> dgm: right... and there are lots of different pieces in app-utils. the options are just one piece.
14:43:38 <gjanssens> So the way cstim used cmake it generated autotools configs for cutecash and we'd still be running makefiles ?
14:44:17 <warlord> yes, on Linux the process is: cmake; make
14:44:25 <gjanssens> As for vc compatibility, I remember cstim had also worked on that
14:44:36 <warlord> on Windows you'd run Cmake and then load the project into VC++
14:44:51 <gjanssens> or msys/mingw if you prefer
14:45:07 <gjanssens> (I suppose)
14:45:38 <gjanssens> IIRC cutecash would also build on Windows, so I guess it was using makefiles there as well
14:46:32 <gjanssens> Personally I think it'd be nice if gnucash could be built with several build systems (including vc)
14:46:41 <gjanssens> But I'm not volunteering to maintain it
14:47:09 <gjanssens> A while ago jralls mentioned ninja
14:47:24 <gjanssens> Is that also a build system supported by cmake ?
14:47:31 <gjanssens> I read it's extremely fast
14:48:41 <warlord> I dont know.
14:48:52 <jralls> gjanssens: Yes, IIUC ninja requires cmake. I was musing about that as a way to speed up our excruciatingly slow Win32 builds.
14:48:53 <gjanssens> Anyway, way too far from current reality...
14:49:03 <warlord> I think a lot of the "slowness" is the fact that we have a recursive make.
14:49:25 <gjanssens> Yes apparently that also bogs things down a lot
14:49:55 <gjanssens> So essentially cmake replaces autogen/configure ?
14:51:07 <jralls> gjanssens: Yes. Plus it can output build scripts for a variety of build tools, including IDE like Visual Studio and Xcode.
14:51:27 <gjanssens> Nice...
14:51:52 <gjanssens> We should have proposed a gsoc project to convert our build system to cmake :p
14:52:10 <gjanssens> And one to finish the c++ migration :D
14:52:18 <kimmo2> how about just bring back the lin graphs? ;)
14:52:47 <jralls> warlord: Th eGtk stack is now largely buildable with VS. If we also built GC with it then it might be easier to get stack traces from Win32.
14:53:19 <warlord> "largely buildable with VS"??
14:53:20 <warlord> ;)
14:54:07 <jralls> warlord: Up through gtk+ itself. I don't know about some of the things that sit on top of it, like WebKitGtk and its dependencies.
14:54:41 <gjanssens> jralls: just to get that clear - if we want to build gnucash on VS, should all of its dependencies be built with it as well ?
14:54:47 <jralls> But Gtk+ and all of its deps can be built in VS, and Fanwei Chun maintains project files in the tree.
14:54:57 <gjanssens> Including guile and friends ?
14:55:24 <gjanssens> Or can libraries built with gcc be mixed with code built with VS ?
14:55:54 <dgm> gjanssens: AFAIK - no.
14:55:54 <jralls> gjanssens: Not necessarily. MinGW claims that its dlls can be linked from VS and vice-versa. I haven't personally tested that.
14:56:36 <gjanssens> That would be great. That looks like the experiment that cstim did a while back
14:56:39 <dgm> M.b. now, but not 3-4 years ago
14:56:59 <gjanssens> I remember messages on the list about his efforts to compile gnucash on VS
14:57:39 <gjanssens> Still VS is a much used build system and much more at home for Windows devs
14:58:03 <gjanssens> If we could get to a point that gnucash can be built on VS, that would certainly lower the barriers for Windows devs
14:59:27 <jralls> gjanssens: Maybe. But would someone who can only work in VS be able to handle cross-platform development?
14:59:57 <gjanssens> jralls: the cross-platform part is relatively small
15:00:24 <gjanssens> And we have linux devs and a good OS X dev to guard that part
15:01:01 <gjanssens> Reality check: 14 of 167 source directories have a CMakeList.txt file
15:01:25 <gjanssens> So we're still pretty far from a cmake based source tree :(
15:01:38 <jralls> gjanssens: It's more than you think. Windows on its own is not POSIX, and MS has lots of non-C/C++-standard stuff that a cross-platform developer would need to be careful about.
15:02:06 <gjanssens> jralls: ok, that's a potential pitfall then.
15:03:24 <gjanssens> We'll have to be clear about that upfront when promoting gnucash development on Windows in VS
15:03:37 <jralls> gjanssens: Yeah, I know. OTOH, Some of those CMakeList.txts are top-level that cover all the directories underneath them. But it's still correct that cstim covered a lot less of GnuCash than he likes to claim.
15:04:37 <gjanssens> Oh well, on the bright side if someone is volunteering, cstim's work is a good start :)
15:04:50 <gjanssens> Not me just yet...
15:04:55 <jralls> True enough.
15:05:40 <gjanssens> jralls: now that I have your attention, I asked this a while back but never got an answer:
15:05:45 <gjanssens> Policy question - what's the gnucash coding policy on class member variables ?
15:05:52 <gjanssens> Should they always be private and have a getter and setter function defined
15:05:58 <gjanssens> Or can they also be public ?
15:06:06 <gjanssens> In the latter case direct access is obviously the way to use them
15:06:20 <gjanssens> I'm asking in the context of the csv importer which is currently using a struct (in C, not c++) to store the state of the importer
15:06:27 <gjanssens> Several of the struct members are accessed directly from the gui code (the Assistant)
15:06:38 <gjanssens> I'm asking because for example the new Gnc_Rational class has public member variables
15:06:50 <gjanssens> So I was wondering what guidelines to follow to decide this.
15:08:30 <gjanssens> I didn't find anything on this on http://wiki.gnucash.org/wiki/CodingStandard
15:10:40 <jralls> gjanssens: I think that it depends. GncRational is essentially private to gnc-numeric.cpp, and there were a few cases where it made sense in that context to access the member variables directly.
15:11:04 *** fabior has quit IRC
15:11:23 <gjanssens> jralls: ok
15:12:10 <gjanssens> The csv importer models the imported file based on several parameters (like separator char, quoting,...)
15:12:38 <jralls> gjanssens: For the importer you want to keep the GUI as independent as possible from the implementation so that you can change one without affecting the other.
15:13:14 <gjanssens> The assistant needs to know about these settings to properly visually show the current settings to the user and a preview of the currently parsed data
15:13:35 <gjanssens> So the assistant needs to read a lot of the parameters also required by the csv importer internally
15:13:56 <gjanssens> And it needs to set several of them based on the user input
15:14:23 <gjanssens> So there is at least some common knowledge of parameters
15:15:17 <jralls> gjanssens: Right. Those are "properties", chunks of data that are going to be universal to anything dealing with CSV files. Python has a cool feature that lets you have accessor functions that are automatically called when you assign to or read from the "property". AFAIK C++ doesn't ahve that facility.
15:16:52 <gjanssens> So, should I translate such properties in private member variables with getter/setter functions or just dumbly make them public member variables ?
15:16:53 *** josePHPagoda has joined #gnucash
15:17:16 <jralls> I think I'd create a separate struct for the properties and make that public. The Assistant and the import/export engine can each use that struct without getting in each other's knickers too much.
15:17:39 <gjanssens> Ah, that might even make more sense yes
15:20:01 <linas> warlord dnssec should now be OK again.
15:20:51 <linas> The dnssec tools seem t be fragile, flakey, unmaintained
15:21:25 <gjanssens> The csvimporter should own it and the assistant will own the csv importer so it can get/set the properties as needed
15:21:37 <jralls> Since you'd need only a single instance of the properties struct for a particular import operation, the Assistant could create a std::shared_ptr of it on the heap without a significant performance penalty and pass that to the import/export engine. When they're both done with it it will clean up after itself.
15:21:47 <linas> the log file said the zone records updated on 24 may but the actuall files were not updated. file perms look OK
15:24:20 <gjanssens> jralls ok, I'll keep that in mind when I move to the c++ part of the importer again
15:24:21 <gjanssens> tx
15:24:25 <jralls> gjanssens: Remember, no raw pointers. Ownership is either std::unique_ptr, so only one object can play with it, or std::shared_ptr if more than one needs to.
15:25:05 <gjanssens> jralls: ok. In my experiments so far I hadn't needed any pointer at all yet
15:25:10 <gjanssens> It was all still stack based
15:28:26 *** himaxx has joined #gnucash
15:32:20 <jralls> gjanssens: Hmm. That's doable, but you'd need to be careful about lifetimes if the user goes back-and-forth in the Assistant pages. Maybe create the assistant, struct, and importer in the top frame and have the assistant's pages and importer functions called from that frame or subframes so that all three stay in scope.
15:32:28 *** himaxx has quit IRC
15:34:55 <gjanssens> jralls: oh, looks like you were already thinking further than I... The assistant was indeed still creating the csv importer class on the heap and destroying it when closing
15:35:54 <gjanssens> The assistant is still firmly in Gtk gui code so C language
15:36:18 <jralls> gjanssens: That's OK, as long as it does it as soon as it starts and destroys it on all exit paths.
15:37:00 <gjanssens> It does have kind of a constructor/destructor just like most Gtk objects have which is indeed used for such tasks
15:37:25 <gjanssens> Should I use std::unique_ptr/std::shared_ptr in there as well then ?
15:38:23 <jralls> Yes, it does. It takes a lot of hand work: https://developer.gnome.org/gobject/stable/chapter-gobject.html.
15:39:06 <kimmo2> hrm, I might have some time to contribute
15:39:52 <gjanssens> kimmo2: code or insight ?
15:40:03 <kimmo2> both I guess
15:40:07 <jralls> Rats, you're right. You can't use std::anything in C. C can only use raw ptrs.
15:40:26 <gjanssens> yay kimmo2 :D
15:40:58 <kimmo2> it's been 5 years since my last visit with C but as a 20 year programming veteran, it's just a matter of brushing up the syntax
15:41:08 <gjanssens> jralls: oh well, I'll have to be careful then with raw ptrs in the assistant's constructor/destructor
15:41:22 <kimmo2> also as a small business owner I'm quite proficient with accounting
15:41:33 <gjanssens> kimmo2 a good combination
15:41:41 <kimmo2> I guess
15:41:49 * gjanssens is actually in a similar situation :)
15:42:19 <gjanssens> Though I wouldn't call me "proficient" with accounting by any means
15:42:32 <kimmo2> I've done my own books for 17 years now
15:42:33 <gjanssens> I still rely on a good accountant for the important parts
15:43:10 <gjanssens> But I do the basic parts myself (for 3 businesses actually)
15:43:10 <kimmo2> I outsourced 2 commpanies' books 3 years ago mainly cause I wanted to get rid of the archival needs
15:44:29 <gjanssens> Trouble here is that I'm proficient in my accounting habits, but I'm not always up to speed which rules I follow because they're convenient for my particular business or which ones are required for proper accounting
15:46:03 <kimmo2> I have a slight case of OCD looking out for me
15:46:32 <kimmo2> the one time I got audited, the local IRS guy couldn't believe his eyes
15:47:08 <gjanssens> :)
15:47:16 <kimmo2> I was the first small business owner in his 30 years in the trade who actually had all the nuances covered
15:47:17 *** fabior has joined #gnucash
15:47:36 <gjanssens> Impressive
15:48:02 <kimmo2> yeah well my biggest stress generator is uncertainty about future finances
15:48:52 <kimmo2> the auditor also commented that even he thought it was weird that their random generator chose me, since my turnover at the time was 150k€, and profit was 60k€
15:49:02 <kimmo2> there's not much left to hide
16:26:58 *** MechtiIde has quit IRC
16:28:02 *** dgm has quit IRC
16:37:59 *** gncbot has joined #gnucash
16:38:04 *** hanazuki has joined #gnucash
16:38:26 *** Simon has joined #gnucash
17:09:50 *** fabior has quit IRC
17:13:26 *** fabior has joined #gnucash
17:15:24 *** gjanssens has quit IRC
17:21:12 *** fabior has quit IRC
17:27:20 *** warlord has quit IRC
17:27:29 *** warlord has joined #gnucash
17:34:32 *** fabior has joined #gnucash
17:49:02 *** rickoehn1 has quit IRC
18:13:20 *** warlord has quit IRC
18:44:17 *** fabior has quit IRC
19:20:07 *** josePHPagoda has quit IRC
19:20:17 *** josePHPagoda has joined #gnucash
19:25:01 *** himaxx has joined #gnucash
20:21:07 *** ErKa has quit IRC
21:10:12 *** ErKa has joined #gnucash
21:23:56 *** ErKa has quit IRC
22:11:35 *** ErKa has joined #gnucash
22:53:24 *** ErKa has quit IRC
23:54:18 *** ErKa has joined #gnucash