2013-10-02 GnuCash IRC logs

00:16:35 *** fuzzybunny69y has quit IRC
00:17:48 *** fuzzybunny69y has joined #gnucash
01:19:58 *** fuzzybunny69y has quit IRC
01:26:53 *** fuzzybunny69y has joined #gnucash
02:39:22 *** fell_ has joined #gnucash
02:39:22 *** gncbot sets mode: +o fell_
02:40:40 *** fell_ is now known as fell
03:28:01 *** fuzzybunny69y has quit IRC
03:33:57 *** fuzzybunny69y has joined #gnucash
03:48:57 *** fuzzybunny69y has quit IRC
04:04:33 *** fuzzybunny69y has joined #gnucash
04:10:00 *** john has quit IRC
04:13:42 *** Tom has joined #gnucash
04:14:48 *** Tom is now known as Webmanoffesto
04:27:01 *** gjanssens-afk is now known as gjanssens
04:28:48 *** Webmanoffesto has quit IRC
04:39:30 <gjanssens> warlord: I got your comment about migrating to Qt, but a net split dropped it off the logs together with my answer
04:39:47 <gjanssens> Which was:
04:39:56 <gjanssens> Believe me, I'm seriously considering that !
04:40:01 <gjanssens> But not for 2.6 ;)
06:40:37 *** fuzzybunny69y has quit IRC
07:00:21 *** fell_ has joined #gnucash
07:00:22 *** gncbot sets mode: +o fell_
07:05:33 *** fell has quit IRC
07:18:07 *** Jimraehl1 has left #gnucash
07:24:04 *** Jimraehl1 has joined #gnucash
07:45:24 *** fell_ is now known as fell
07:53:51 *** Topcat has joined #gnucash
08:04:15 *** Topcat has quit IRC
08:04:38 *** Topcat has joined #gnucash
08:09:41 *** Topcat has quit IRC
08:10:26 *** Topcat has joined #gnucash
08:22:17 *** Topcat has quit IRC
08:27:39 <warlord> gjanssens: I'm wondering how hard it would be to rewrite GnuCash completely in C++/Qt, effectively starting from scratch? (Perhaps leaving the existing C engine API as a wrapper around the C++)
08:32:21 <warlord> (and perhaps not completely starting from scratch -- perhaps copying some code). But starting from a "DB" perspective, where XML purely is an import/export format.. *ponders* I'm sure it would take a very very long time to get back to the current state
08:43:37 <gjanssens> Yes, very likely
08:44:00 <gjanssens> Especially given the manpower we have currently available
08:45:11 <warlord> Well, if I ever go back to self-consulting again .......
08:45:34 <gjanssens> Still, John already expressed his intentions to rewrite the engine in c++
08:45:44 <gjanssens> And seemed to be optimistic about it
08:46:07 <gjanssens> The GUI is at least as elaborate and complex though
08:46:18 <warlord> Yeah. I'd love to drop gobject and do everything in C++. I wish I had done that with QOF in the first place.. :-/
08:46:56 <warlord> Yeah, I think most of the effort will be in the UI. HOWEVER if we make a successful MVC transition it should be... easier.
08:47:44 <gjanssens> At some point I will probably play with QtQuick/QML
08:47:55 <gjanssens> That would give me some idea on how difficult things would be
08:48:02 <gjanssens> But that's all daydreaming until after 2.6
08:48:20 <gjanssens> I feel we're currently working hard not to become obsolete...
08:48:33 <gjanssens> by dropping deprecated dependencies
08:51:42 <gjanssens> warlord: is that something you are considering ? Self-consulting again ?
09:12:57 <warlord> Not particularly..
09:13:40 <warlord> Last time I did it because I was laid off and didn't have any real prospects.. It wasn't really a voluntary thing. Also, I was in a position where I could, because I got benefits elsewhere.
09:14:36 <warlord> I just have an issue with the Gnome project. They seem to be.. dwindling.. and IMHO keep making bad choices that hurt app developers and hurt users.. I've stopped using Gnome's UI on my new systems.
09:15:44 <warlord> They don't seem to care about API stability, they don't care about user customization. They don't care about non-Linux systems...
09:23:29 <gjanssens> Right, they seem to be focussed on their "Gnome OS"
09:23:44 <gjanssens> From the looks it seems that is going to be some kind of tablet os
09:24:17 <gjanssens> But to be fair, more recent versions do allow more tweaks to get closer to the classic gnome interface
09:24:41 * gjanssens is not using gnome desktop either
09:24:49 <gjanssens> So that's only hearsay
09:43:23 *** soa2ii has joined #gnucash
09:44:53 <soa2ii> Hi. I just played a little with the business features of gnucash (in my regular accounts) but now it looks like there's no way to get rid of customers/receipts … is there no way to delete them so I can start frsh with customer id 000001?
09:45:14 *** mikee_ is now known as mikee
09:45:37 <mikee> @op
09:45:38 *** gncbot sets mode: +o mikee
09:46:21 <mikee> You can just recycle them. Reuse that ID for a real customer.
09:48:09 <soa2ii> mikee: And the receipt too?
09:49:19 <mikee> Them too. Unpost them and just re-use them.
09:56:50 <warlord> soa2ii: no, there is no 'delete'. you can reuse/recycle
10:04:13 <warlord> gjanssens: Given their history of a lack of concern for users I have no intention of actually trying it or believing them.
10:23:35 *** nomeata has joined #gnucash
10:29:13 *** benoitg has joined #gnucash
10:32:08 *** ErKa has joined #gnucash
10:43:47 *** ErKa has quit IRC
10:44:50 *** aqua___ has joined #gnucash
10:56:13 *** john has joined #gnucash
10:56:13 *** gncbot sets mode: +o john
11:10:56 <gjanssens> Hey John, I got gnucash building fine with your fixes
11:11:18 <john> Yay. Does it run?
11:11:28 <gjanssens> Looking into my gsettings issue, it turns out my gsettings code is not called at all on OS X
11:11:47 <john> Well, that would do it. ;-)
11:11:52 <gjanssens> LOL
11:12:40 <gjanssens> I'm currently still trying to figure why that is
11:12:56 <gjanssens> I had set up something like how qof backend works
11:13:20 <gjanssens> A generic struct holding function pointers
11:13:22 <john> I had a look at the gsettings code yesterday, and I'm a bit mystified about how the default backend gets set. And just to make it more confusing, William Hua, who implemented the 'defaults' backend, chose to call it gnextstepsettingsbackend.
11:14:16 <gjanssens> I have written some code to assign these funtion pointers via wrappers to gsettings calls
11:14:28 <gjanssens> That was an attempt to isolate gsettings as much as possible
11:14:40 <gjanssens> I must have done something wrong there
11:14:51 <gjanssens> Because on linux this runs nicely
11:15:34 <gjanssens> On OS X it seems no function pointers are set at all
11:15:45 <gjanssens> I was about to set up some additional tests in that area
11:16:27 <gjanssens> Re the gsetting backend: you got further than I got
11:16:43 <gjanssens> I didn't find the source of the gnextstepsettingsbackend
11:17:19 * gjanssens was looking for something like gdarwinsettingsbackend or gosxsettingsbackend
11:18:06 <john> Yeah, I tried that too. Finally found the answer buried in ChangeLog.
11:18:52 <john> I realized today that I should have just grepped for <Cocoa/Cocoa.h>.
11:24:00 <warlord> nextstep? Hahahah
11:27:41 <john> Why? MacOSX is just NeXTStep rebranded. At least he didn't call it GNUStep!
11:28:32 <gjanssens> Well, at least there's a gsettings backend for OS X
11:29:00 <gjanssens> So there is hopes that it will work (presuming I can figure out why my settings api doesn't)
11:29:51 <john> Did you put any guard macros around the routines that set the virtual function pointers?
11:34:37 <warlord> john: I know. I remember NextStep -- even used it myself.
11:34:59 <john> So why the derisive laughter?
11:35:44 <warlord> Because who under the age of 40 would even think to consider using that name?
11:35:51 *** aqua___ has quit IRC
11:35:54 <warlord> (for OSX)
11:37:20 <john> Who says he's under 40? Besides, everyone writing code for it is constantly reminded by the 'NS' names for most classes.
11:38:40 *** nomeata has quit IRC
11:41:40 * gjanssens sort of made some progress...
11:41:48 <gjanssens> I have partially rewritten my wrapper code
11:42:06 <gjanssens> And now my gsettings calls are effectively being used
11:42:11 <warlord> Yay
11:42:53 <gjanssens> And my debug code shows the nextstep gsettings backend is found and preferred
11:43:03 <john> Sounds like good progress. Are the settings saved?
11:43:30 <gjanssens> But then the app crashes before it reaches a user ready gui
11:43:53 <john> Oh. :-(
11:43:56 <gjanssens> CRIT <GLib> g_ascii_strcasecmp: assertion 's1 != NULL' failed
11:44:02 <gjanssens> CRIT <gnc.core-utils> gnc_uri_create_uri: assertion 'path != 0' failed
11:44:15 <gjanssens> CRIT <GLib> g_ascii_strcasecmp: assertion 's1 != NULL' failed
11:44:16 <gjanssens> Bus error
11:45:00 <john> You'll need to dig a wee bit deeper than that: Where is the null string coming from?
11:45:21 <gjanssens> Yes, I know. I was just reporting where I got so far
11:45:33 * gjanssens is digging now...
11:45:51 <john> BTW, g_assert crashes to make it easy to work the backtrace in gdb...
11:59:43 <gjanssens> john, what did you mean with the guard macros ?
12:00:30 <gjanssens> I'm just testing if the struct instance is allocated
12:00:40 <john> Something like HAVE_FOO from configure
12:00:54 <gjanssens> If not, I allocate it using g_new0
12:01:24 <gjanssens> and the assign the function pointers
12:01:43 <gjanssens> I don't use any HAVE_FOO macros
12:01:53 <gjanssens> I don't think that's necessary
12:02:09 <gjanssens> If gio/glib is not available at configure time, configure fails
12:02:30 <gjanssens> Other than that I don't have to check for anything specific for gsettings
12:02:37 <gjanssens> It should simply be there
12:02:48 <john> Well, configure already has HAVE_GLIB_2_28, 2_32, and 2_36.
12:03:19 <gjanssens> Indeed
12:03:25 <gjanssens> gsettings is available in all of them
12:03:40 <john> But anyway, you obviously found and fixed the bit that was preventing the call.
12:04:24 <john> So the struct is allocated with g_new(), but unless the string member has a string assigned to it, you'll get that assert.
12:05:04 <gjanssens> Got it working ! Woohoo !
12:05:13 <john> What was it?
12:05:14 <gjanssens> Settings are saved and restored on OS X
12:05:19 <john> Yay!
12:06:05 <gjanssens> gnc_file_open assumes the filename it gets passed is either a real filename or NULL
12:06:29 <gjanssens> But gsettings returns an empty string if no value has been set for a string parameter
12:06:59 <gjanssens> So I had to guard gnc_file_open from continuing with an empty string
12:07:18 <warlord> Oops!!
12:07:27 <gjanssens> I suspect there will be more of these wrong assumptions in the code
12:07:29 <john> Probably should go further and check that it's a valid path.
12:07:46 <john> No, really? ;-)
12:08:27 <john> Sorry for the sarcasm, but the quality of our code isn't great.
12:08:41 <john> Not as bad as ORBit2's, though.
12:08:46 <gjanssens> Heh, I meant now that the settings are stored in gsettings, I may have introduced new ones
12:08:58 <warlord> The code is 18 years old...
12:08:59 <gjanssens> gconf could have NULL as default value.
12:09:22 <gjanssens> In fact, I'll try to figure out if gsettings can't have null as default in some way or another
12:09:29 *** TradeBorG has joined #gnucash
12:09:29 <gjanssens> That would help a lot here.
12:09:46 <gjanssens> I"m building the same updated code on Windows now.
12:09:57 <john> >The code is 18 years old... Yeah, and Beck invented Test Driven Development more than 20 years ago.
12:10:02 <gjanssens> I hope it went wrong for the same reasons
12:10:38 <gjanssens> By the way, just out of curiosity:
12:11:08 <gjanssens> I originally wasn't using a pointer to a struct, but an instance of the struct directly
12:11:27 <gjanssens> So I had a header file called gnc-prefs-p.h
12:11:28 <warlord> Grr, why is my program crashing in vsnprintf() -- can't va_list get reused and passed as an argument to a function?
12:11:49 <gjanssens> With a variable definiton like this
12:12:07 <gjanssens> SomeTypeDefdStruct var_name;
12:12:19 <gjanssens> Then that header was included in two source files
12:12:44 <gjanssens> One sourcefile accessed the struct to fill in the struct's members (all function pointers)
12:13:04 <gjanssens> The other source file would call the function pointers (if not NULL)
12:13:12 <warlord> Yeah, that would do it..
12:13:17 <warlord> "extern" is your friend.
12:13:38 <gjanssens> Oh, I missed that one
12:13:56 <gjanssens> I never used extern before.
12:13:59 <PaulFertser> I wonder why doesn't the linker warn about two different exported symbols having same name.
12:14:01 <gjanssens> Learning every day ;)
12:14:22 <gjanssens> Perhaps I should revert to this set up
12:14:22 <john> Yeah, remember that including a header into two source files creates two instances of whatever variables are declared in the header: The source files are
12:14:51 <john> separate compilation units and the compiler can't see the contents of more than one at a time.
12:15:21 <gjanssens> So simply adding 'extern' in front of my variable declaration would have fixed it ?
12:15:38 <john> No.
12:15:48 <gjanssens> Thought so :(
12:16:29 <john> The general rule is that you can't define storage in a header file, just declare symbol names.
12:17:11 * PaulFertser guesses gjanssens is spoiled working with real high-level languages :)
12:17:18 <warlord> You would need to add 'extern' to the header, and then in *one* C file you'd need to declare the struct.
12:17:21 <john> So in one source file you need to declare the struct as 'static' and in the other as 'extern'.
12:17:32 <warlord> no, not 'static'..
12:17:37 <warlord> just declared.
12:17:40 <warlord> (and not "extern")
12:18:06 <john> Oh, right, static would hide it from the other source file.
12:18:21 <warlord> Right
12:18:54 <PaulFertser> static functions improve optimisation a lot on embedded targets. Forget the static and you blow the size up considerably.
12:19:41 <john> But you can declare the struct extern in the other source file and just have the typedef in the header.
12:20:43 <john> PaulFerser: True, but in this case the symbol needs to be visible in more than one compilation unit, so it can't be static. The alternative is to allocate on the heap which is substantially slower.
12:21:03 <PaulFertser> john: obviously, yes
12:21:47 <john> Of course, it would be better still to encapsulate everything using the struct into a single source file and make it static.
12:23:16 <john> The less the outside can see behind the curtain the better.
12:24:52 <gjanssens> That's why it's already in a "private" header
12:25:28 * gjanssens is not spoiled with any language
12:26:03 <gjanssens> I had to learn it all myself, which inevitably leaves some holes in my education :(
12:26:31 <john> But you still have to coordinate changes between two source files, and you pay the size penalty of having the global symbol, even if only two files can see it.
12:27:02 <gjanssens> Unless you meant scripting with high-level languages
12:27:11 <john> Time for me to go to Habitat
12:27:18 <gjanssens> (which I taught myself as well)
12:27:20 <john> Bye.
12:27:30 <gjanssens> Enjoy, and thanks for the guidance :)
12:31:20 <gjanssens> Hmm, encapsulating everything using the struct into a single file will be difficult in this case
12:31:59 <gjanssens> The two files are meant to set up some kind of abstraction
12:32:28 <gjanssens> There's only one file that is really using gsettings calls
12:32:44 <gjanssens> This file fills up the struct
12:33:08 <gjanssens> The other source file exposes a generic settings interface to the rest of gnucash
12:33:34 <gjanssens> But for each function it exposes, it has to call the corresponding function found in the struct
12:33:52 <gjanssens> Bringing these two together defeats the abstraction.
12:34:36 <gjanssens> So to recap, my best solution currently is
12:35:12 <gjanssens> In the prefs abstraction source, I'll declare a variable of the typedefd struct
12:35:32 <gjanssens> In the gsettings file, I declare the same variable, but "extern"
12:36:01 <gjanssens> The struct declaration and typedef will remain in the private header, only included in these two sources
12:36:14 <gjanssens> Is that it ?
12:39:06 <PaulFertser> gjanssens: it's usually better to have extern declaration in some file that's also included by the C source that have the actual variable declaration so that the compiler can verify the types to be the same.
12:39:48 <gjanssens> So I should include the extern in the private header file instead ?
12:40:00 <gjanssens> And nothing in the second source file ?
12:40:12 <PaulFertser> gjanssens: it looks like that to me, yes.
12:40:21 <gjanssens> Ok, I'll try that
12:41:17 <PaulFertser> gjanssens: having something in a header file that's getting included is the same as writing it directly in your source. It's just that you can include the same header file in two different C files to let the compiler know about the types of extern variables and non-static functions.
12:47:12 <gjanssens> PaulFertser: thanks for the details
12:47:27 <PaulFertser> gjanssens: welcome, hth :)
12:47:42 <gjanssens> The work will be for tomorrow though (or perhaps later this evening), I have to leave now
12:47:49 *** gjanssens is now known as gjanssens-afk
12:52:08 *** aqua___ has joined #gnucash
13:07:40 *** mishehu has quit IRC
13:09:14 *** mishehu has joined #gnucash
13:11:42 *** ErKa has joined #gnucash
13:31:45 *** benoitg1 has joined #gnucash
13:31:46 *** benoitg has quit IRC
13:33:02 *** ErKa has quit IRC
13:47:54 *** TradeBorG has quit IRC
14:04:22 *** ErKa has joined #gnucash
14:21:25 *** nomeata has joined #gnucash
14:38:26 *** aqua___ has quit IRC
15:15:17 *** aqua___ has joined #gnucash
15:22:24 *** todd has quit IRC
15:22:39 *** todd has joined #gnucash
15:53:10 *** aqua___ has quit IRC
16:02:44 *** aqua___ has joined #gnucash
16:07:11 *** TradeBorG has joined #gnucash
16:21:49 *** Krzysiek_K has joined #gnucash
16:22:06 *** Krzysiek_K has left #gnucash
16:43:24 *** aqua___ has quit IRC
16:45:10 *** aqua___ has joined #gnucash
16:49:40 *** aqua___ has quit IRC
17:41:55 *** TradeBorG has quit IRC
18:08:25 *** nomeata has quit IRC
19:14:09 *** fuzzybunny69y has joined #gnucash
21:14:38 *** fell has quit IRC
21:26:04 *** ErKa has quit IRC
21:33:30 *** erpingham has joined #gnucash
21:33:59 <erpingham> Is there a way to submit patches to GnuCash other than creating a bug on bugzilla and attaching the patch to the bug?
21:47:00 *** ErKa has joined #gnucash
22:15:29 *** ErKa has quit IRC
22:22:10 *** erpingham has quit IRC
23:29:20 *** benoitg1 has quit IRC
23:53:56 *** ErKa has joined #gnucash