2007-01-30 GnuCash IRC logs
01:07:28 *** AlonzoTG has quit IRC
03:36:01 *** ErKa has joined #gnucash
03:42:34 *** aj has joined #gnucash
04:12:12 *** ceplma has joined #gnucash
06:46:51 *** anothergu1 has joined #gnucash
06:59:35 *** twunder has joined #gnucash
07:00:30 *** cstim has joined #gnucash
07:00:30 *** gncbot sets mode: +o cstim
07:03:34 <cstim> .
07:03:34 <gncbot> cstim: Sent 15 hours and 57 minutes ago: <andi5> have you ever tried ORBit2 v2.14.4.zip?
07:04:10 <cstim> @tell andi5 Thanks for the hint - indeed in ORBit2 2.14.4 and 2.14.5 make check runs successfully. Maybe this issue is solved now.
07:04:10 <gncbot> cstim: The operation succeeded.
07:08:54 *** twunder has quit IRC
07:08:54 *** anothergu1 has quit IRC
07:09:55 *** twunder has joined #gnucash
07:11:47 *** twunder has quit IRC
07:20:01 *** wizkid238 has quit IRC
07:44:49 *** ceplma has quit IRC
07:45:43 *** ceplma has joined #gnucash
08:19:25 *** wizkid238 has joined #gnucash
08:42:26 *** twunder has joined #gnucash
08:44:39 *** andi5 has joined #gnucash
08:44:39 *** gncbot sets mode: +o andi5
08:53:44 <cstim> andi5: hi
08:55:05 <andi5> hiho
08:55:36 * cstim is installing lastest compiled gnucash...
08:55:41 <cstim> (on win32, that is)
08:55:46 <andi5> good, that is
09:20:08 <warlord-afk> :)
09:20:10 *** warlord-afk is now known as warlord
09:20:12 <warlord> hi
09:20:24 <cstim> hi warlord
09:20:29 <andi5> hiho
09:20:33 *** wizkid238 has quit IRC
09:21:14 <cstim> interesting presentation about porting gtk software to windows: http://www.saunalahti.fi/tlillqvi/fosdem-2006.pdf
09:23:23 <cstim> @$&%! On make install, I get these "libfoo.lai file missing" errors several times.
09:23:23 <gncbot> cstim: Error: "$&%!" is not a valid command.
09:24:14 <andi5> cstim: i have never seen those :(
09:26:02 <andi5> cstim: there is no chance to reproduce that error? .... maybe some file could not be written to because i was still opened by another process? (sometimes make install fails because of that for me)
09:26:35 <andi5> but i do not think it prints anything about missing .lai files
09:28:14 <cstim> yes, it does *not* print anything about this - it just stops "make install" with "error 1". But it is caused by a missing .lai file.
09:28:42 <cstim> and yes, this could very well be caused by a not-yet-closed file.
09:29:46 <andi5> what system do you test and build on?
09:30:17 <cstim> win2000
09:30:22 <andi5> maybe there is some difference between winxp and win2000?
09:31:09 <cstim> no idea
09:31:20 <cstim> (and no motivation to track this down...)
09:33:03 <andi5> maybe we should all go out and bye vista ...
09:33:14 <cstim> aaaaaarg
09:33:42 <andi5> bye != buy by ..... the way
09:34:15 <cstim> buy it and bye bye. you're totally right.
09:34:23 <cstim> .-)
09:34:38 <andi5> did somebody shoot you in the eye?
09:34:46 <warlord> Aye!
09:34:52 <andi5> ;-)
09:39:45 <cstim> re make install: It isn't reproducible. Once I force a rebuild by removing the libfoo.la in the respective directory, after the rebuild the .lai file is there.
09:40:20 <warlord> Weird.
09:40:32 <warlord> Heisenbug! I hate 'em
09:45:20 <cstim> oops. /me wanted to type rm *~<enter> but it ended up as rm *<enter>~
09:45:42 <andi5> *g*
09:45:59 <cstim> Note to self: really really insert one extra second of thought when starting to type "rm ..."
09:49:08 <jsled> That's why 'rm' is so short: so you have time to re-read the command thrice before hitting enter.
09:50:49 <andi5> jsled: but what about rm-can-do-you-harm-do-not-use-this-if-you-have-not-read-man-rm-can-do....
09:52:35 <jsled> heh
10:00:43 <jsled> Hmm. Any idea why trunk spins for 20 seconds on startup doing scm_* calls?
10:02:34 <andi5> i see... there is a date that gets converted and then converted back... now it differs by 3600 seconds... surprise surprise :)
10:05:33 <warlord> andi5: that's what "rm-<tab>" is for..
10:06:40 <andi5> warlord: create these names in /bin for one inode: rm, rm-can, rm-can-do, rm-can-do-you .... you know what i mean :)
10:06:55 <warlord> LOL
10:18:06 *** andi5 has quit IRC
10:36:57 *** ErKa has quit IRC
11:14:58 *** ceplma has quit IRC
11:16:04 *** cstim has quit IRC
12:31:56 *** ErKa has joined #gnucash
12:44:56 *** ErKa has quit IRC
13:41:23 *** MrN has joined #gnucash
14:13:35 *** ErKa has joined #gnucash
14:33:17 *** andi5 has joined #gnucash
14:33:18 *** gncbot sets mode: +o andi5
14:37:05 *** ErKa has quit IRC
14:55:01 *** sjc has joined #gnucash
15:07:02 *** |gunni| has joined #gnucash
15:07:31 *** |gunni| has joined #gnucash
15:26:32 <andi5> hi... i want to propose http://pastebin.ca/raw/333272 .... it fixes "make check" in src/backend/file, but maybe needs some tester(s) .... it is shamelessly (will add comment) from glib 2.12
15:31:17 <warlord> andi5: does that work with dates before, during, and after 2000?
15:33:32 <andi5> i will try to test that
15:41:57 *** prock_ is now known as prock
16:00:17 *** esodan has joined #gnucash
16:01:39 <esodan> Hi all, I have a question: the QofObject seams to be the equivalent of GObjectClass, then Do I need to keep it? or Can I deprecate its use?
16:11:16 *** esodan has left #gnucash
16:12:33 *** ceplma has joined #gnucash
16:17:32 *** andi5 has quit IRC
16:49:04 *** benoitg has joined #gnucash
17:05:22 *** ceplma has quit IRC
17:10:28 *** twunder has quit IRC
17:14:27 *** benoitg has left #gnucash
17:16:25 *** esodan has joined #gnucash
17:17:04 <esodan> Hi all
17:17:11 <warlord> Hi esodan
17:17:36 <esodan> warlord do you have my pub key?
17:17:37 *** benoitg has joined #gnucash
17:18:06 *** benoitg has left #gnucash
17:18:16 <warlord> Yes, I got your email. I just need your preferred username. I assume the email address you sent is where you want mail sent to <yourname>@cvs.gnucash.org to forward to?
17:20:46 <warlord> esodan: to answer your other question.. I think most of QofObject can be deprecated, but obviously some of the contents would need to get migrated, perhaps into the GObjectified QofEntityClass or QofInstanceClass.
17:20:48 <esodan> Yes that will be my e-mail, do you need I send you my username by e-mail? or I can tell you here...
17:21:03 <warlord> You can tell me here.
17:21:23 <esodan> "esodan" is Ok :)
17:21:47 <warlord> Okay. :)
17:22:22 <esodan> About QofObject, then I'll review its code
17:23:04 <warlord> esodan: Just look at the definition of the structure! You have to have those function pointers stored SOMEWHERE..
17:24:00 <esodan> warlord: please wait, I review in a moment and back soon...
17:24:10 <warlord> okay
17:28:03 <esodan> The functions I found is related to a Book... mmmmm, then I can see it's like a GInterfase or just a virtual funtions that some derived object need to implement... correct?
17:29:03 <warlord> pretty much, yes.
17:29:57 <warlord> QofObject is the "QOF Object Registration System", which effectively let's you enumerate all the QOF Objects..
17:30:15 <warlord> It's how you get a runtime list of each of the different kinds of objects.
17:30:24 <warlord> So when you want to save your state you could do something like:
17:30:29 <warlord> print_file_header();
17:31:03 <esodan> print_file_header ( QofObject *object ) ?
17:31:17 <warlord> for-each type in qof-object-list { for-each object in book-collection-of-<type> { save_object(); } }
17:31:20 <warlord> print_file_footer();
17:32:50 <esodan> Ok, Then I need to Create a top level abstract object QofObject where a QofIntance is derived from... right?
17:33:26 <warlord> No... Like I said, a QofObject is a class definition, it's not an instance. So it's more like QofInstanceClass
17:34:21 <warlord> (or, rather, it more "belongs" in QofInstanceClass)
17:34:22 <esodan> Ahhh mmmm, then this virtual functions must be declared in QofInstance object, and implemented by its derived classes...
17:34:51 <esodan> of course in the QofInstanceClass...
17:35:05 <warlord> Yes, which is what I thought I said the first time you asked that.. (or you could define some 'default' implementations of those functions.. that subclasses can re-implement)
17:36:18 <esodan> Ok thats easy, but I'll need to modify the actual API and/or use #define macros to override the actual QofObject definitions...
17:37:13 <warlord> I think small API changes like that are probably fine..
17:37:27 <warlord> (or we could use macros.. depends on how much you need to change the API)
17:39:19 <esodan> Well at moment I have to modify some thinks in QofInstance, QofBook and QofCollection (I realy don't know how much, after I test it) in order to insure a good construction/destruction and have a good control about the access to its internal variables... ;)
17:40:51 <esodan> I have merged QofEntity into QofInstance, and add API functions to allow QofBook be the way to access its internal QofCollections not allowing to access directly this objects...
17:41:47 <esodan> And now QofCollection is a GObject derived class, to allow (may be) emit signals about any changes...
17:43:46 <warlord> esodan: Have you audited all of gnucash to make sure that we always have a QofInstance where the old API asked for a QofEntity?
17:46:23 <esodan> Well not for the moment, but I will...
17:46:26 *** Demitar__ has joined #gnucash
17:46:46 <warlord> I think you should before you actually merge QofEntity into QofInstance.
17:46:59 <warlord> Or perhaps a QofEntity shouldn't be a GObject?
17:48:13 <esodan> I'm auditing the objects derived from QofInstance to forse them to use the QofInstance's and QofBook's API and not access to its internal variables directly as actual done by, for example, Account object...
17:48:15 <warlord> (although that means you couldn't easily pass a QofInstance as a QofEntity anymore, which would kinda suck)
17:50:26 <esodan> QofInstance have the same functionality that QofEntity (it stores the GUID, manage the object's types, and so)... Then I think I can typedef QofInstance QofEntity... but I need see where it is used and how...
17:51:51 <esodan> For the moment I found QofEntity used by the QofInstance objects derived, but I need to see... I realy need to do this changes in order to ensure a correct functionality...
17:52:13 *** benoitg has joined #gnucash
17:52:22 * jsled wonders if/when milter on lists.gnucash.org is going to try MX prio=30 ... the one that actually accepts delivery. :/
17:52:34 <warlord> esodan: You're missing the point.. A QofEntity MIGHT be used in a place where /ALL/ you have is the GUID and Type.. you don't have the rest of the object!
17:52:51 <warlord> jsled: is that not the highest prio?
17:53:21 <esodan> At the begining QofEntity was a GObject, but it loses the QofIdType and QofEntity has a pointer to the Book then you realy can use this object in order to work with the QofCollection where the object is stored...
17:53:21 <jsled> I've a prio=20 for phoenix.asynchronous.org which intentionally won't deliver, and prio=30 for my actual mailhost.
17:53:58 <jsled> Did I forget how the prio sorts...?
17:54:16 <warlord> Maybe. prio=20 will be tried first.
17:54:20 <warlord> (lowest prio wins)
17:54:41 <jsled> Yeah. The theory is that spam will only try the 20, but Real Mail Hosts will try at least two hosts (as per rfc).
17:55:21 <esodan> warlord: You have them: QofInstance have a pointer to its GUID and if you need to know the object's type you can use G_OBJECT_TYPE macro (I'm using it alot in order to find objects in the book and in its collections)
17:55:28 <warlord> jsled: well, it's quite possible that milter-sender doesn't try multiple MXes.. It's probably a bug, but the author changed the license on updates to milter-sender so it's no longer free.. So I can't really update.
17:55:36 <jsled> :/
17:55:58 *** bonez39 has joined #gnucash
17:55:59 *** Demitar_ has quit IRC
17:56:17 * jsled will poke through the config in more detail; a quick reading indicated that it would try more than one.
17:56:19 <warlord> esodan: you have it backwards.. It's the other way around. It's not that I want to find the GUID from an instance... It's that I already HAVE the GUID (e.g. I loaded it from a saved report configuration) and I want to pass it down with the type.
17:56:32 <warlord> jsled: it's quite possibly a bug..
17:59:38 <warlord> esodan: any preference what you want your development branch called? gobject-dev?
18:00:13 <esodan> Well for example if you already have the GUID and you have the type, you can even find the object becouse now you have a qof_book_get_element (QofBook*, GType, GUID), this function will find the correct collection and lookup for an object with that GUID (the type is determinated by G_OBJECT_TYPE macro or using the QOF_TYPE_object defined in each object)
18:00:52 <esodan> gobject-core-dev, may be... :)
18:01:12 <esodan> or gobject-engine-dev... :)
18:01:53 <warlord> like I said, I think you should go audit the code and see where QofEntity is really being used as a QofEntity and NOT a QofInstance..
18:02:36 *** twunder has joined #gnucash
18:03:03 <warlord> esodan: just tell me what you want it called and I'll make it, branching off trunk.
18:03:45 <esodan> gobject-engine-dev, please...
18:04:57 <esodan> Yes don't worry I'll audit the entry code to find QofEntity use and modify it...
18:05:17 *** benoitg has left #gnucash
18:07:13 <warlord> esodan: I still don't think you understand.. I don't think you CAN modify some of the usages because you don't HAVE a QofInstance to work with.
18:08:45 *** benoitg has joined #gnucash
18:12:12 <esodan> warlord: Then what do I have? Please remember that QofEntity now is a QofInstance, all you had with a QofEntity now is a QofInstance... but any way I'll audit the code and try to find this before begin to test... if you know any plase where you want to know how will work or how I preted to solve please tell me to consider it...
18:13:13 <warlord> I'm trying to tell you that making a QofEntity into a QofInstance might not work in all cases where a QofEntity is used in the code..
18:16:05 <esodan> Yes I know, I'm modifing all this parts...
18:16:26 <warlord> How can I create a QofInstance with just a GUID and GType?
18:18:55 <esodan> Actually you can call g_object_new (QOF_TYPE_INSTANCE, "book", book), and then use qof_instance_set_guid... the first function creates a new instance, set the book and assings a new GUID; the second sets a new GUID...
18:19:24 *** andi5 has joined #gnucash
18:19:24 *** gncbot sets mode: +o andi5
18:20:57 <jsled> might be nice to have a convenience constructor, but that's minor.
18:21:19 <jsled> It'll be nice to see the code...
18:21:23 <warlord> esodan: That's not useful, because now I might have two QofInstances of the same GUID, which I definitely DONT want!
18:21:52 <andi5> FYI, given that time_t will probably only work until 2038, "my" patch should work reasonable well, because 2100 is the first special non-leap year after 1970...
18:22:07 <warlord> andi5: heh.
18:22:19 <warlord> I think we have other "year 2100" problems in the code.
18:23:00 <andi5> do not we have year 2038 problems lying around everywhere? (maybe i am missing something...)
18:23:47 <MrN> andi5: you only need to buy a 64-bit computer! :)
18:23:57 <andi5> MrN: guess what i use
18:24:07 <MrN> the same architecture as i do? :)
18:24:14 <warlord> andi5: I dont know. I think it depends on the underlying time_t and time() implementations
18:24:27 <andi5> i guess the cheapest 64bit architecture available, is not it?
18:24:42 <esodan> warlord: Nop!, you create a new instance, to a correct constructions it assings a book and a new GUID, but know you can overwrite this GUID with yours using qof_instance_set_guid, this function remove the instance from the collection, sets the new GUID and add this instance again to the collection...
18:24:46 <MrN> shall we not assume typedef long time_t;
18:25:02 <andi5> well, the code i pasted works until 2100 on 64bit comps, and until 2038 on others...
18:25:35 <andi5> hm? we should not assume anything imho
18:26:24 <MrN> well we must... but that's rather philosophical :D
18:26:33 <warlord> esodan: again, that's not what I want.
18:26:57 *** sylvus has joined #gnucash
18:27:09 <andi5> jsled: do you have some spare time (5 minutes?) to test my patch? it would help even more if you tricked HAVE_TIMEGM (say MAVE_TIMEGM)
18:27:25 <jsled> andi5: sure.
18:27:29 <andi5> cool :)
18:28:15 *** sylvus has left #gnucash
18:28:23 <jsled> andi5: looks like I need to rebuild `make check` from the top-level, thouhg, so it might be a few more than 5 minutes.
18:28:45 <andi5> ok :)
18:31:12 <jsled> andi5: what's the failing test in src/file/backend/, though?
18:31:13 <esodan> warlord: could you tell me more please, consider that I realy leave the things like you do now, I don't invent a new way, just porting to GObject... I've studied the code and reproduce the same secuence keeping as much as possible the same code (just modify it to use GObject)
18:31:24 <andi5> make-date-converting or so
18:31:43 <andi5> test-date-convert.exe actually
18:31:50 <jsled> andi5: [[[
18:31:50 <jsled> PASS: test-date-converting
18:31:51 <jsled> Executed 101 tests. All tests passed.
18:31:54 <jsled> ]]] - without patch.
18:32:04 <jsled> just fyi.
18:33:15 *** solidago_ has joined #gnucash
18:33:34 <andi5> hm.... it executes only 20 tests here...
18:34:32 <andi5> ah, you meant test-dom-converters1
18:35:05 <jsled> andi5: Ah, so I did! I was used to junit ordering from a while ago...
18:35:15 <jsled> Yes, 20 tests here. All passed.
18:35:54 <solidago_> question: double entered pmt, then reconciled one half in 1st; other half in 2nd
18:35:58 <andi5> :) ... your test environment rocks... you tell it to run 20 times, but it always gives 110%
18:37:07 <solidago_> is there some way to unreconcile one, and rereconcile the unrecced half in the other?
18:39:27 <jsled> andi5: with patch, both with HAVE_TIMEGM and MAVE_TIMEGM (:), the tests check out fine.
18:39:33 <warlord> solidago_: I dont understand.
18:39:46 <andi5> jsled: great :) ... will apply then
18:39:57 <andi5> thanks!
18:42:13 <solidago_> warlord: heh. I've never done irc; I entered DR credit card/CR bank for credit card twice
18:42:31 <solidago_> warlord: then I reconciled the bank side in one, and credit card in other other.
18:43:33 <solidago_> and now I have a mess: two *half* reconciled payments. So of course my checking acct is down by 2nd `virtual' pmt
18:44:14 <esodan> warlord: Hey!!! I saw the code in Account and found that you sets the pointers in QofObjects to a actual functions in Account object, then this is equivalent to GInterface, I'll do a QofObject as a GInterfase and attach it to the GObjects, then you can use any QofInstance derived object as a QofObject, of course implementing its functions... :)
18:45:15 <warlord> solidago_: oh, you should just delete one of the transactions and then re-reconcile the other one.
18:46:10 <solidago_> I tried that, and it screwed up the beginning balance of my checking account!
18:46:12 <warlord> I suppose we could use GInterface instead of Class pointers.. But I think it probably does belong in QofInstanceClass, because EVERY QofInstance subclass needs to define it.
18:46:30 <solidago_> During my next reconcile, I mean...that was scary.
18:46:32 <warlord> solidago_: then you deleted the wrong transaction.
18:46:55 <warlord> Oh, yeah, of course it's going to do that! Ignore the "starting" balance, just worry about the ending balance.
18:47:14 <solidago_> I'm not explaining this well. I transferred, let us say $1000 from checking to discover.
18:47:39 <solidago_> I made this $1000 entry *twice*. Let us say, once on 14th, once on 15th, just for convenience.
18:47:51 <solidago_> Then I reconciled the checking account on the 14th entry...
18:48:15 <solidago_> and the discover account on the 15th entry. Hence the twice half reconciliation.
18:48:45 *** twunder has quit IRC
18:48:52 <solidago_> And deleting either one messes up the initial balance of the opposite account.
18:49:21 <solidago_> Now, I *think* I could kludge something by carefully trying stuff on a backup and exiting without saving...
18:49:24 <warlord> solidago_: You're perfectly clear; I'm telling you to ignore the "initial balance" of the reconciliatoin dialog.
18:50:06 <solidago_> Ok, but suppose my initial balance on my credit card reconciliation is now 500 instead 1500, and ending balance is 2000
18:50:36 <solidago_> If I clear the 500usd I actually purchased, the ending balance isn't going to be right.
18:51:00 <warlord> solidago_: the new one will; you'll just reconcile the correct $1000
18:52:03 <warlord> Just do what I'm telling you to do and stop thinking so hard about it.
18:52:11 <esodan> warlord: Could you see the code in lib/libqof/qof/qofobject.h and in qofobject-p.h, this both refer to a (*is_dirty) (QofCollection*) but in the private header defines qof_object_is_dirty (QofBook*), WHY?
18:52:15 <warlord> It will do the right thing.
18:52:40 <solidago_> ok. I've spent about 2--3 hours re-entering stuff from this problem. Don't want to go thru that again...
18:53:44 <warlord> esodan: qof_object_is_dirty() really means qof_book_all_objects_test_dirty()
18:54:08 <warlord> solidago_: just delete one transaction and re-reconcile the other account. Ignore the starting balance. Just make sure the ending balance is correct.
18:54:42 <esodan> warlord: if I define the functions in QofObject as virtual functions in QofInstance, I'll need to define for example qof_instance_is_dirty (add its code calling the object derived function) but to keep the actual API in QofObject I'll need to #define qof_object_is_dirty (obj) qof_instance_is_dirty (obj)
18:55:20 <warlord> esodan: Um, okay...
18:55:32 <jsled> esodan: you should work to commit asap, I think.,
18:55:54 <jsled> It seems like it'll make other discussions easier.
18:56:26 <warlord> Yeah.. So let's decide on the branch name, and then you can commit code, and then we can discuss this in more concrete terms.
18:56:34 <warlord> The language barrier is way large.
18:56:52 <esodan> jsled: I'll do ASAP, I just want to create the basic structure (before to test or compile it) to try avoid missunderstanding about what I pretend...
18:56:54 <warlord> Mi español es muy malo.
18:57:03 <jsled> warlord: <esodan> gobject-engine-dev, please...
18:57:09 <warlord> okay.
18:58:22 <andi5> my 2ct: nobody says that the first branch must be a true success.... if there are unsolvable issues, retry on another branch :)
18:58:32 <warlord> That's true.
18:58:37 <warlord> Branches are cheap.
18:59:22 <andi5> All 13 tests passed .... I love it :)
19:04:50 <warlord> andi5: cool.
19:05:02 <warlord> Let me go fix the test-numeric test..
19:08:10 <andi5> aaaaaaaaaah.... why the heck did no i see it before.... the code will work perfectly, even after 2100 :)
19:08:47 <andi5> or not? /me stops shouting
19:09:06 <solidago_> warlord: thank you very much: this worked.
19:09:17 <warlord> :)
19:09:38 <warlord> andi5: W00t! The test-numeric test now works even when you force it to 30.
19:10:10 <andi5> Executed 8881 tests. There were 1532 failures. ..... but at least 1 of 6 tests failed overall
19:10:37 <andi5> cool :)
19:13:53 *** MrN has quit IRC
19:14:13 <esodan> warlord: Sorry but I have my preliminary implementation as complete as possible, QofClass, it apears that defines some kind of GObject properties, and a way to get them... is it correct?
19:18:03 <warlord> andi5: okay, try r15473.
19:22:28 <esodan> warlord: If so, I'll need to implement the same properties in the objects and #define this functions, the problem is that it is using the QofIdType, but GObject needs the object directly, well I'll implement the same properties and modify the code when needed...
19:23:44 <warlord> esodan: QofIdType -> GType
19:23:55 <warlord> GNC_ID_XXX -> gnc_xxx_get_type()
19:24:58 <warlord> esodan: In terms of your first question -- I dont know. What king of GObject properties do you think QofClass defines? (maybe it does. I dont know.
19:29:37 <esodan> QofClass defines some functions to get a getter or setter for parameters (QofParameter) or get a parameter struct with pointers to get a value in the object (this is basicaly the same concept behind GObject properties), Then I'll need to audit the code to sustitude this functions to use g_object_get (GObject*, "property_name"), becouse I'll eliminate the process to register objects into QOF and just use GObject system...
19:30:17 <warlord> esodan: you still need a registration because we need to enumerate all the QOF objects.
19:30:32 <esodan> And I'll install the same properties in the GC's GObjects
19:31:03 <andi5> hm.... looking at xaccParseAmount[Extended], is in_str allowed to contain currency symbols or not?
19:31:19 <esodan> warlord: enumarate coul you tell me where do you do that?...
19:31:34 <warlord> esodan: Sure, look in src/backend/file/
19:31:46 <esodan> Ok I'll see...
19:33:40 <esodan> warlord: Could you tell me witch file I need to inspect?
19:35:51 <warlord> Hmm, I guess there's another registry for that.. But the qof_class_* functions are used.
19:35:59 <warlord> (just not qof_class_foreach...)
19:39:32 <warlord> the backend uses qof_object_foreach_backend()
20:02:27 *** wizkid238 has joined #gnucash
20:04:32 <andi5> warlord: arrg, it looked good, make check passed 4 times... but then i got "FAILURE expected <ERROR> [4626 / 0] = <ERROR> [22843188 / 0] ../../../../repos/src/engine/test/test-numeric.c:235"
20:06:10 <jsled> Alright, simple poll. The gnc dense cal is supposed to be dense. As such, I have it setup to take the current style's font and basically modify the size by -2 pt.
20:06:17 <jsled> So, the same font, but a relative size change.
20:06:30 <jsled> Reasonable? Or should it just leave the users settings alone.
20:06:30 <jsled> ?
20:06:46 <warlord> jsled: that's probably reaosnable.
20:06:50 *** rearnsha has quit IRC
20:07:13 <warlord> andi5: at 235?!?
20:07:29 <andi5> yes
20:08:08 <andi5> got them again... FAILURE expected [8787 / 11138] = <ERROR> [-1 / 0] = reduce(<ERROR> [0 / 0]) ../../../../repos/src/engine/test/test-numeric.c:231
20:08:09 <andi5> FAILURE expected [8787 / 11138] = <ERROR> [0 / 0] ../../../../repos/src/engine/test/test-numeric.c:235
20:09:11 <andi5> oh, and i am right now looking at some really weird issue... print_info before function calls differs from the info that arrives at the function.... weeeeird
20:10:08 <warlord> andi5: very weird. I dont understand how it's passing gnc_numeric_eq() but failing gnc_numeric_equal()
20:13:03 <andi5> well, just assume that deno==0
20:13:48 <warlord> Oh. Hmm.. We should probably disallow that.
20:14:13 <andi5> indeed
20:16:50 <andi5> arrg, that is not enough :( ...
20:17:39 <andi5> it probably fixes the first error, but not the one on line 231
20:17:55 *** esodan has quit IRC
20:18:41 <warlord> andi5: you need to make sure both deno and mult are > 0
20:18:46 * andi5 tests "if (deno==0 || mult==0) continue;" now
20:19:08 <warlord> I would do:
20:19:25 <warlord> if (deno == 0 || mult == 0) { i--; continue }
20:19:54 <prock> well I had been delaying emailing my patch in because of a segfault but now that I can reproduce the crash on trunk...
20:20:34 <andi5> before i lose them... see http://pastebin.ca/raw/333659
20:20:42 <andi5> prock: what crash?
20:20:52 <prock> ... this crash is sx related, should I just file a bug report or should I also email gnucash-devel?
20:20:55 <prock> I'll pastebin
20:21:06 <jsled> just pastebin it for the moment; we'll decide fr omtehre.
20:22:48 <warlord> andi5: looks like the same issue, need to make sure > 0
20:23:16 <andi5> yeah.... *hopes*
20:23:29 <prock> http://pastebin.com/871715
20:23:42 <prock> happened while deleting a sx
20:24:34 <jsled> prock: yeah. Did you have an sx list page open, then close it?
20:24:47 <prock> yes, then reopen and delete the sx
20:24:53 <jsled> yeah. There's a bug in there.
20:25:09 <jsled> I think it isn't really unrefing the old sx instance model when the page is closed.
20:25:19 <jsled> I should probably look at that sooner rather than later.
20:25:25 <jsled> For the moment, don't close the page.: )
20:25:27 <jsled> :), even.
20:25:28 <prock> I've been scratching my head because I thought it was one I had created in my wc. Then I just tried it on trunk to be sure and *poof*
20:28:21 <prock> Does it try to re-use the InstanceModel when you close and reopen the list?
20:28:51 <jsled> it shouldn't, no.
20:29:02 <jsled> It should create another (and cleanup the first)
20:29:19 <jsled> I mean, clearly, the crash is due to a qof event getting delivered to the should-have-been-trashed instance model.
20:29:27 <jsled> Which means it's dispose isn't getting called.
20:29:32 <jsled> which means it's not getting unref'ed.
20:30:06 <warlord> jsled: or it's not removing the qof-event registration
20:30:42 <jsled> warlord: that bug I fixed a long time ago; it's clearly in the dispose for the GncSxInstanceModel
20:32:04 <warlord> Okay.
20:33:13 <jsled> yeah ... just break'ed on gnc_sx_instance_model_dispose ... never called.
20:33:23 <jsled> prock: fwiw, I should be able to take a look at this tonight, in a bit.
20:33:30 <jsled> and I doubt it'll be too hard.
20:33:44 <prock> no worries, I'm going to send my patch to -devel now anyway
20:33:46 <jsled> (famous last words, I know. :)
20:34:54 *** warlord is now known as warlord-afk
20:45:31 <prock> should you be able to have multiple sx lists open?
20:46:54 *** sjc has quit IRC
20:47:12 <andi5> can somebody please explain http://pastebin.ca/raw/333703 to me?
20:47:52 *** franz has joined #gnucash
20:51:38 <jsled> prock: yes
20:52:30 <prock> jsled: why would this be necessary?
20:52:39 <jsled> prock: it's not necessary, but it's possible.
20:52:48 <jsled> prock: they might be showing different things.
20:52:57 <jsled> (once a "show this time range" options gets added)
20:52:57 <prock> ok
20:54:12 <prock> that makes sense
21:21:50 *** andi5 has quit IRC
21:23:06 <jsled> Grr. I always get confused by g_return_value_if_fail(boolean)
21:23:13 <jsled> Or whatever it is.
21:23:20 <jsled> I hates it.
21:25:29 *** twunder has joined #gnucash
21:27:21 <jsled> prock: fixed in 15476
21:29:40 *** franz has quit IRC
21:41:26 <prock> yay tnx
21:42:03 -jsled- foo
21:45:47 *** warlord-afk is now known as warlord
21:45:54 <warlord> jsled: Hey! How did you do tha?
21:46:09 <jsled> Oh, the -jsled- foo? /notify #gnucash foo
21:46:27 <prock> I was wondering that myself...
21:47:00 <jsled> Er. /notice <user> <msg>
21:47:32 <warlord> jsled: Yes indeed, it's exactly what gncbot should use to tell people about EVERYTHING, including the /topic.
21:48:15 <jsled> yup
21:48:32 <warlord> Cool!
21:48:49 <jsled> going to laptop; should be back in a bit.
22:51:32 *** prock_ has joined #gnucash
23:00:04 *** prock has quit IRC
23:00:10 *** prock_ is now known as prock
23:14:18 *** twunder has quit IRC
23:45:08 *** rhowe has quit IRC
23:58:01 *** warlord2 has joined #gnucash
23:58:02 *** gncbot sets mode: +o warlord2