2007-06-22 GnuCash IRC logs

01:03:41 *** gunnmjk has quit IRC
01:27:29 *** nbinont has joined #gnucash
01:31:02 *** harnold has joined #gnucash
01:56:37 *** telexicon has joined #gnucash
01:57:48 *** telexicon has joined #gnucash
03:40:39 *** ErKa has joined #gnucash
03:59:46 *** Rolf has joined #gnucash
04:17:31 *** harnold has quit IRC
04:19:35 *** harnold has joined #gnucash
04:20:50 *** roxy_ has joined #gnucash
04:29:46 *** Esaj has joined #gnucash
04:42:56 *** nbinont_ has joined #gnucash
04:51:18 *** nbinont has quit IRC
05:36:18 *** Rolf has quit IRC
05:39:21 *** harnold has quit IRC
05:50:07 *** roxy_ has quit IRC
05:56:01 *** roxy_ has joined #gnucash
06:06:55 *** roxy_ has quit IRC
06:28:02 *** nbinont has joined #gnucash
06:37:06 *** nbinont_ has quit IRC
06:42:28 *** nomeata has joined #gnucash
06:46:33 *** kielein has joined #gnucash
07:10:05 *** IanL has joined #gnucash
07:17:04 *** lasindi_ is now known as lasindi
07:18:01 <lasindi> Is something wrong with svn.gnucash.org? I am having no success checking code out from there.
07:20:39 <IanL> I just updated my local repository without a problem.
07:21:40 <lasindi> IanL: how long ago?
07:21:46 <IanL> just now
07:22:09 <lasindi> Hmmmm
07:22:26 <lasindi> Does this link work for you? http://wiki.gnucash.org/wiki/FAQ
07:22:44 <lasindi> For me, neither wiki.gnucash.org nor svn.gnucash.org appear to work.
07:22:48 <IanL> it surely does
07:22:59 <lasindi> Strange ...
07:23:04 <lasindi> probably a DNS problem?
07:23:08 <IanL> maybe.
07:23:12 <IanL> where are you located?
07:23:19 <lasindi> The US
07:23:26 <IanL> hmm.
07:24:06 <IanL> unless they changed the DNS entries it shouldn't be a problem anyway.
07:25:42 <lasindi> IanL: what IP address do you get with nslookup on svn.gnucash.org?
07:25:57 *** nbinont has quit IRC
07:26:20 <IanL> host gives me: svn.gnucash.org has address 204.107.200.65
07:26:53 <lasindi> I get the same, so it can't be a DNS problem.
07:29:35 <lasindi> Okay, even if I ssh to a remote computer, I can get to wiki.gnucash.org.
07:30:40 <IanL> hmm
07:31:05 <lasindi> I think maybe it's banned my IP address or something ...
07:32:59 <lasindi> warlord-afk: When you return, any ideas why I can't access the server?
08:13:27 *** nomeata has quit IRC
08:14:24 *** roxy_ has joined #gnucash
08:24:53 *** warlord-afk is now known as warlord
08:25:09 <warlord> lasindi: Did you use the wrong SSH username?
08:26:34 <warlord> lasindi: Actually, it looks like you might've killed an SSH/SVN in the process of connecting.
08:26:38 <warlord> I see this in my logs:
08:26:58 <warlord> Make sure you don't kill ssh early.
08:27:01 <warlord> I'll reset you.
08:27:47 <warlord> Okay, lasindi, you should be able to get in again.
08:28:16 <warlord> The server is VERY strict about SSH "failures", or anything that looks like an SSH failure.. And you only get 1 chance before it blocks you.
08:28:48 <lasindi> Ah ok, sorry.
08:29:10 <lasindi> Would this happen if the connection dropped midway through a checkout or something?
08:30:08 <lasindi> Cool, it works again. Thanks
08:32:38 *** andi5 has joined #gnucash
08:32:39 *** gncbot sets mode: +o andi5
08:36:23 <warlord> No, only if you kill the connection before the ssh handshake finishes.
08:37:46 *** RallyU has joined #gnucash
08:41:46 *** nomeata has joined #gnucash
08:41:50 <warlord> okay, i'm going back to bed.
08:41:55 *** warlord is now known as warlord-afk
08:55:58 *** IanL has quit IRC
08:57:36 *** roxy_ has quit IRC
09:23:35 *** IanL has joined #gnucash
10:06:02 *** andi5 has quit IRC
10:26:50 *** ErKa has quit IRC
10:51:55 *** RallyU has quit IRC
12:16:00 *** andi5 has joined #gnucash
12:16:00 *** gncbot sets mode: +o andi5
12:16:22 <andi5> E: Trac detected an internal error ; OperationalError: database is locked
12:23:26 <chris> warlord-afk: Time to get up, sleepyhead.
12:23:45 <andi5> lol
12:24:04 *** warlord-afk is now known as warlord
12:24:15 <warlord> chris: :-P
12:24:36 <andi5> chris: I see messages like "Last fetched revision of refs/remotes/csv-import was r16197, but we are about to fetch: r16197!" all the time when i fetch with git-svn and have to remove the .rev_db.... any idea what that is?
12:25:15 <chris> andi5: no, never seen that.
12:25:32 <andi5> git-svn would be really nice... if i would finally work for me
12:25:42 *** IanL has quit IRC
12:26:59 <warlord> andi5: What URL were you hitting? I cannot reproduce that database lock issue in trac.
12:27:13 <andi5> oh, for clarity... this has nothing to do with the csv-import branch :-)
12:27:27 <andi5> huh... works again
12:27:33 <andi5> timeline
12:28:20 <andi5> warlord: whatever you did, you succeeded ;-)
12:28:43 * warlord and the magic fingers ;)
12:34:27 * warlord still doesn't see what's wrong in his first few GObjectification changes that would break queries...
12:34:50 <andi5> oh, i am going to check that now
12:35:52 <warlord> Thanks!
12:36:05 * andi5 crosses fingers
12:36:38 * warlord crosses fingers, too
12:53:13 *** Esaj has quit IRC
13:00:13 *** jakin has joined #gnucash
13:06:09 <andi5> I: r15772 and r15773 make the difference.... *continuing*
13:08:04 <warlord> andi5: yes, I knew that already ;)
13:08:26 <andi5> well.... you wrote it so you really should ;-)
13:08:45 <warlord> Or are you saying that you narrowed it down to TWO changesets (down from the three I'd narrowed it down to)?
13:08:58 <andi5> yes... 62 works, 73 not
13:09:01 <andi5> 72 does not compile
13:10:23 <warlord> Right. Okay so you narrowed it down to NOT r15778 or r15779
13:10:56 <warlord> Well, that's good to know.
13:22:08 *** franz has joined #gnucash
13:22:35 *** nomeata has quit IRC
13:28:35 *** franz has quit IRC
13:34:08 <andi5> warlord: so the difference is qof_instance_get_guid() .... if you called it with a NULL parameter, it used to return NULL, now it returns guid_null()
13:36:20 *** Esaj has joined #gnucash
13:36:27 <andi5> Q: why not just revert that single line? ... *testing*
13:40:25 <andi5> tada
13:47:21 *** nomeata has joined #gnucash
13:58:52 <warlord> andi5: Hmm...
13:59:07 <warlord> I think the problem was qof_instance_get_guid() vs. qof_entity_get_guid() (maybe?)
13:59:51 *** nomeata has quit IRC
13:59:57 <warlord> i think there are places that used to use qof_entity_get_guid() that ASSUMED that you'd get a non-NULL response.
14:00:13 <andi5> hm...
14:01:15 <warlord> Right, because the old qof_entity_get_guid() had:
14:01:17 <warlord> const GUID *
14:01:17 <warlord> 95 qof_entity_get_guid (const QofEntity *ent)
14:01:17 <warlord> 96 {
14:01:17 <warlord> 97 if (!ent) return guid_null();
14:01:17 <warlord> 98 return &ent->guid;
14:01:18 <warlord> 99 }
14:01:44 <andi5> i liked the easy solution :(
14:01:48 <warlord> whereas qof_instance_get_guid() WOULD return NULL, not guid_null().
14:03:08 <warlord> Well..... I dont particularly care which one we use; we just need to decide on one and then check for "!guid" or "guid == NULL" and change it to a compare to guid_null.. Or we can make it return NULL and then fix the places that assume you wont get NULL.
14:03:44 <warlord> Also, it would be really nice if we could add a test-case for this so we don't regress again.
14:04:29 <andi5> any preference? (biab)
14:04:51 <warlord> andi5: well, I certainly prefer a testcase ;)
14:05:23 <warlord> as for which way, I suspect it would be easier to do what you did, make sure "make check" still works, and then we'll track down the places where it assumes non-NULL because it'll crash ;)
14:20:17 *** _gunni_ has joined #gnucash
14:23:49 <andi5> warlord: is there a difference between NULL and guid_null()?
14:24:01 <warlord> Yes
14:24:08 <andi5> i mean... how to interpret both?
14:24:19 <warlord> see lib/libqof/qof/qofid.*
14:24:57 <warlord> I dont know if you can use == to test against guid_null.
14:25:27 <andi5> guid_equal(guid, guid_null()) seems to be used in that file
14:25:32 <warlord> Yeah
14:25:41 <andi5> i hope to understand when to use what...
14:26:03 <andi5> e.g. guid_to_string depends on guid!=NULL
14:26:08 <warlord> Well, you just need to decide which result the function returns, and then need to audit all uses.
14:26:55 <warlord> Because code that expects it to be guid_null will start failing, unless we change guid_equal() to allow guid_null == NULL
14:27:27 <andi5> well... that may be a solution... dirty though :)
14:27:44 <warlord> True.
14:28:05 <warlord> But it saves you from having to audit every call to qof_instance_get_guid() and make sure it behaves properly.
14:28:39 <warlord> So, change ...get_guid() to return NULL, and change guid_equal().. but I dont know what other collateral damage that might cause.
14:28:43 <warlord> MAN, NEIL!!!!!!!!!
14:28:58 <andi5> my name is ANDI! ;-)
14:29:11 <warlord> Yes, I know; YOU didn't write this mess. NEIL did.
14:29:28 <warlord> WHY in HECK did he write two 'get_guid' functions that behaved DIFFERENTLY.
14:29:29 <warlord> ?
14:29:38 <andi5> hehe
14:30:00 <andi5> is there any place where we ship GUIDs, not (GUID*)s?
14:30:15 <andi5> if not, i wonder what guid_null is good for at all
14:31:56 <andi5> ok, there might be some use i simply do not know yet, like some sorting function that depends on some non-NULL, but zero-like...
14:32:29 <warlord> It USED to be the case that we'd ship a GUID (not GUID*) into Scheme.
14:34:01 <andi5> well, you probably know that already... i strongly dislike disambifications of NULL (like #f vs '() and alike)
14:35:40 <andi5> hehe... make check succeeded :-D
14:45:42 <andi5> Q: for the stability of gnc2.2, i could also add a deperecated function qof_entity_get_guid, working like qof_instance_get_guid, but returning guid_null on NULL
14:48:40 <warlord> andi5: you could... and then revert the changes that called qof_entity vs. qof_instance.
14:48:56 <andi5> exactly
14:49:14 *** Zoolooc has joined #gnucash
14:49:35 <andi5> we can fix this after branching then
14:49:42 <warlord> Sure, that works.
14:49:47 <andi5> 'k
14:53:08 <warlord> Thanks!
15:07:58 *** Esaj has quit IRC
15:15:50 *** Esaj has joined #gnucash
15:22:38 *** cstim has joined #gnucash
15:22:39 *** gncbot sets mode: +o cstim
15:24:46 <andi5> hi cstim
15:26:01 <cstim> hi andi5
15:26:01 <gncbot> cstim: Sent 1 day, 2 hours, and 46 minutes ago: <andi5> great news regarding aqbanking! kudos to you :) oh, i do not know why locale messages should be installed under lib/, but that is a rather standard procedure, so i will probably fix dist_aqbanking at the weekend then...
15:26:16 <cstim> Today's trophy of fixing the most nasty bugs surely goes to andi5 :-)
15:26:26 <andi5> :-D
15:27:15 <cstim> jsled: http://svn.gnucash.org/trac/changeset/16194#file1 when you wanted to mark the char* constants of the array as translatable, why didn't you use N_("...") ?
15:28:04 <andi5> and what to use then? dgettext or _?
15:28:13 <cstim> andi5: both would be fine
15:28:27 <andi5> i think warlord had some clear preference, but i tend to forget which one :)
15:28:35 <cstim> _ is better
15:28:46 <cstim> because with dgettext you still have to specify PACKAGE
15:28:59 <andi5> oh, maybe it was gettext then
15:29:23 <cstim> const char *english_text=N_("english text"); const char *translation = _(english_text);
15:29:24 <andi5> maybe because that works even when NLS is disabled?
15:29:42 <cstim> NLS disabled? Then N_ and _ are no-op macros
15:29:48 <andi5> exactly
15:29:58 <jsled> cstim: Because I usually cargo-cult that, and I don't know about 'N_'.
15:30:22 <cstim> jsled: if you don't mind I'll fix that in a minute.
15:30:26 <cstim> "cargo-cult"...?
15:30:30 <cstim> :-P
15:30:33 <andi5> cstim: aqbanking landing the weekend?
15:30:41 <jsled> cstim: I don't mind at all; I'm happy to do it myself, if you like.
15:30:51 <cstim> jsled: that's even better.
15:31:27 <cstim> jsled: and as you're at it: I'd prefer to have single-word messages all upper-cased; that would be "(Never)" vs. the current "(never)"
15:31:39 <cstim> andi5: do you also want another gwenhywfar release?
15:32:10 <andi5> hm.... does it contain anything non-cross-compiling-related?
15:32:24 <cstim> andi5: no
15:32:30 <andi5> not necessarily then, no
15:32:39 <cstim> ok
15:32:53 <jsled> cstim: http://en.wikipedia.org/wiki/Cargo_cult_programming
15:33:22 <andi5> hehe
15:33:26 *** kielein has quit IRC
15:33:32 <cstim> a "ritual inclusion of code"? uh... :-))
15:34:03 <warlord> yes, I prefer using _() instead of getext()
15:34:35 <cstim> Hamburg is seeing another thunderstorm outside.
15:35:15 <cstim> yesterday at our workplace we had one lightning approx. 100 meters away
15:35:29 <andi5> nice
15:35:34 <cstim> All non-Laptop computers and all network equipment decided to reboot immediately
15:35:58 <cstim> and my shiny new VoIP phone's eth0 port was dead from that moment on :-(
15:36:06 <andi5> oh no =(
15:36:27 <andi5> sounds like bad überspannungsschutz or so?
15:36:31 <warlord> cstim: where is Magdalenenstraße 44, 2000 Hamburg 13 in relation to you?
15:37:05 <cstim> warlord: a four-digit postcode? Those were taken out of circulation in, I believe, 1992
15:37:19 <warlord> Hahaha..
15:37:44 <cstim> Magdalenenstraße is one of the most expensive places in town
15:37:46 *** nomeata has joined #gnucash
15:37:49 <warlord> Well, it WAS from a very old piece of artwork (circa 1979?) .. Apparently it's an art gallery.
15:37:56 <andi5> 1993 actually ..... W-2000 :-)
15:38:38 <cstim> ok. I think in that street there is also the University of music and fine arts
15:39:07 <warlord> Okay.. Just wondering.
15:39:38 <cstim> not fine arts, just music and theatre, actually.
15:40:06 <cstim> It's right next to the Aussenalster, the large lake in town. Not too far from my place, but too far for walking.
15:40:15 <cstim> Rather using a bike or public transport.
15:40:32 <cstim> (for European measures, that is)
15:42:07 <warlord> Right
15:46:17 <jsled> Bah, I still need the '_()', don't I?
15:46:27 <cstim> yes
15:46:29 <jsled> The 'N_(...)' just marks the string for translation.
15:46:33 <cstim> yes
15:46:37 * jsled headslaps.
15:46:53 <cstim> that's why you can use N_(...) in a const char*[] definition
15:48:15 <cstim> what do you think of http://bugzilla.gnome.org/show_bug.cgi?id=366468#c20
15:49:11 <andi5> i wonder whether this bug is still possible with the revised SLR dialog (it is revised, is not it?)
15:49:31 <jsled> it is, and it no longer has a register.
15:49:54 <jsled> so, that problem shouldn't be repeatable.
15:50:20 <cstim> not with a SLR dialog. But aren't there other dialogs that might have a register?
15:50:27 <jsled> Though the SX editor does still have a register.
15:50:56 <andi5> chris reported it, so he has to fix it.... that is my point of view :)
15:51:07 <jsled> heh.
15:51:38 <andi5> well, keep in mind that a bug is non-existing if it has not been reported
15:52:19 <cstim> andi5: you reported we need a new register, didn't you? Are you already writing one?
15:52:26 <andi5> oops
15:52:30 <cstim> just joking ;-)
15:52:50 <andi5> cstim: i muss wohl auch anfangen, im dreck zu wühlen, hm? ;-)
15:53:17 <cstim> jsled: you don't use git-svn or svn-svk, do you? (neither do I)
15:54:37 <jsled> I don't ... I looked at and started using git-svn a few weeks ago when doing a preso about it, but haven't kept up using it.
15:54:54 * cstim uses git-cvs at work
15:55:27 <andi5> sounds like a good idea
15:55:45 <cstim> but basically because the CVS server is so damn slow, it kills all the fun in version control. git brings it back by its shear speed.
15:56:26 <cstim> sheer, not shear.
15:59:33 <andi5> huh... is that intended: http://svn.gnucash.org/trac/browser/gnucash/trunk/lib/libqof/qof/qofreference.c#L42 ?
16:00:38 <warlord> Intersting
16:01:24 <warlord> okay, i gotta run. BIAB
16:01:27 *** warlord is now known as warlord-afk
16:02:33 *** telexicon has left #gnucash
16:04:51 <chris> cstim: off the top of my head, I think your suggested fix would prevent the crash.
16:06:04 <chris> cstim: I think you have better English spelling than most native speakers.
16:06:28 <andi5> ok... dirty handwork continues sunday ... have a nice weekend!
16:07:42 *** andi5 has quit IRC
16:12:16 <cstim> chris: heh... thanks.
16:12:43 * cstim has yet to complete his Ph.D. thesis - in english.
16:34:25 *** ErKa has joined #gnucash
16:38:33 <cstim> chris: well, that was easy.
16:39:58 <cstim> warlord-afk: you care to back-port r16207? It's sooo easy yet fixes a nasty nasty bug.
16:43:25 *** nomeata has quit IRC
16:47:25 *** cstim has quit IRC
17:04:35 *** sjc has joined #gnucash
17:17:27 *** [0x100] has quit IRC
18:11:29 *** ErKa has quit IRC
18:12:06 *** Esaj has quit IRC
18:28:35 *** gunnicom_ has joined #gnucash
18:36:06 *** nomeata has joined #gnucash
18:37:35 *** _gunni_ has quit IRC
18:42:12 *** BlackBsd has joined #GnuCash
19:19:20 *** warlord-afk is now known as warlord
19:19:44 <warlord> @tell cstim Are we even going to have a 2.0.6 release? I suppose I can backport it, but if there's never going to be a 2.0.6 does it matter?
19:19:44 <gncbot> warlord: The operation succeeded.
19:21:10 *** nomeata has quit IRC
19:31:25 *** bonez44 has quit IRC
19:39:35 *** jakin has quit IRC
19:39:43 *** jakin has joined #gnucash
20:07:03 *** david has joined #gnucash
20:07:26 *** david has joined #gnucash
20:09:59 <david> Hello, Is it possible to add a starting balance on a bank account after it has been created? I got around the problem by adding the starting funds by a psuedo-transaction from Unspecified account. But I was wondering if there was a more 'elegant' way to do this. Thanks
20:10:39 <dacc> david: i think the usual way is to create a transaction from Equity:Starting Balances
20:11:04 <dacc> david: i do this at the top of each account
20:11:21 <dacc> e.g. date earlier than first recorded transaction
20:12:06 <david> yeah
20:12:24 <david> ok, I havn;t gotten around using Equity accounts yet
20:12:34 <david> I guess I should go read up on it
20:13:36 <david> from what I understand, they are just arbitrary "ajustment" accounts?
20:13:56 <dacc> that one is kinda special
20:14:08 <dacc> it's the only one i'm using
20:14:44 <jsled> Yeah ... instead of Unspecified, just make it against {Equity:Opening Balances}
20:14:55 <jsled> (and date it appropriately)
20:15:06 <jsled> That's all that the "new account" druid does anyways.
20:15:20 *** jakin has quit IRC
20:16:22 *** sjc has quit IRC
20:16:31 <david> ok, from what I just read it's basically just an account to state your initial networth
20:17:32 <david> Thanks
20:17:33 <jsled> in part, yes.
20:33:07 <david> Humm.. Ok, so I just created an account named Equity in my root, and It is of type: Assets... I used Assets thinking "It's what I had" but now that I think about it, it doesn't really make sense... Idealy I would like to use an account of type:equity in which its negative values would not count towards my net worth...
20:35:41 <david> what account-type does the druid use for the Equity:Starting Balances ?
20:59:44 *** chemaja has joined #gnucash
21:00:56 <warlord> dacc: no, you want type Equity
21:01:02 <warlord> er, david that was to you
21:01:51 <david> hehe, I don't see the Equity account type
21:01:58 <david> in the list af account types
21:02:36 <david> oh
21:02:36 <david> nm
21:02:42 <david> I guess I need better glasses
21:03:26 <warlord> heh
21:03:44 * david needs to find better insurance before getting new glasses
21:05:07 <david> Oh, I just remembered, i have another question
21:05:40 <david> the import qif doesn't seem to be working under windows
21:06:13 <warlord> isn't working how?
21:06:27 <david> im working under debian now so its not an issue, but im running v2.0
21:06:45 <david> well,
21:06:50 <david> and error pops up
21:06:55 <david> lemme see if I can remember...
21:07:04 <david> something about bad qifs...
21:07:18 <david> or maybe cannot read file.. damnit I don<t remember
21:07:49 <warlord> well, i'd need to know the error to help you
21:08:29 <david> Anyways, my question was: If I import under debian with v2.0, will the saved data file work under v2.1 ?
21:09:48 <david> and I I modify things to the data file under windows with v2.1, will it be backwards compatible if I open it under debian with v2.0 ?
21:10:30 <david> basically, I will use 2 computers with different OS's with different versions
21:11:36 <warlord> the first question is "yes".
21:11:42 <warlord> The second... "maybe".
21:12:20 <warlord> if you have any Scheduled Transactions, then no.
21:14:34 <david> ah ok. I guess its better to keep the work under v.2.1 minimal, and to make sure the changes were interpreted correctly under v2.1... or better yet, scrap the windows version and wait until the next stable release...
21:17:17 <warlord> Well, I'd still ask you to test the QIF import on windows because if there IS a problem now is the time to let us know.
21:32:07 *** digdug has joined #gnucash
21:39:20 *** zarchne has quit IRC
21:39:51 *** digdug has left #gnucash
21:49:45 *** zarchne has joined #gnucash
21:50:38 *** chemaja has quit IRC
21:51:30 *** chemaja has joined #gnucash
22:16:07 *** BlackBsd has quit IRC
22:28:03 <david> warlord: Sure, next time I see the error, i'll take note of the message
22:47:49 <warlord> david: thanks. Also, might be useful to keep track of what you were doing when the error occurred, and maybe even a snippet (or copy) of the QIF file.
22:58:35 *** Zoolooc_ has joined #gnucash
23:08:20 *** Zoolooc has quit IRC
23:44:31 *** david has quit IRC
23:45:05 *** nbinont has joined #gnucash