2007-02-14 GnuCash IRC logs

00:53:33 *** hampton is now known as hampton|away
00:54:26 *** Wilddev has quit IRC
01:32:58 *** hampton|away has quit IRC
01:34:03 *** adrigen has joined #gnucash
01:34:21 <adrigen> anyone:
01:34:44 <adrigen> anyone: I am trying to edit /usr/share/gnucash/scm/reports/invoice.scm but the reports folder doesnt exsist... what can I do?
01:55:20 <dbr> in my installation, that report is in $PREFIX/share/gnucash/guile-modules/gnucash/report/invoice.scm
01:56:36 *** dbr has quit IRC
02:44:59 *** chris has quit IRC
03:21:13 <adrigen> though youll never hear it. Thnaks Dbr
03:21:26 <adrigen> Ooh, luck he didnt hear that.
03:21:33 *** adrigen has left #gnucash
03:37:59 *** sishen has joined #gnucash
03:46:05 *** ErKa has joined #gnucash
04:00:00 *** ceplma has joined #gnucash
04:30:27 *** Esaj has joined #gnucash
05:19:43 *** sishen has quit IRC
06:12:36 *** exper has joined #gnucash
06:17:27 *** exper_ has quit IRC
06:28:20 *** exper_ has joined #gnucash
06:28:59 *** IanL has joined #gnucash
06:31:55 *** exper has quit IRC
07:15:43 *** writerz_ has joined #gnucash
07:21:58 *** exper_ has quit IRC
07:23:32 *** twunder has joined #gnucash
07:40:46 *** twunder has quit IRC
07:41:27 *** exper has joined #gnucash
07:48:09 *** writerz_ has quit IRC
08:32:37 *** twunder has joined #gnucash
08:43:01 *** chris has joined #gnucash
08:43:02 *** gncbot sets mode: +o chris
08:43:45 *** chris has quit IRC
08:46:42 *** chris has joined #gnucash
08:46:42 *** gncbot sets mode: +o chris
08:48:32 <jsled> gncbot: tell dbr adrigen said: <adrigen> though youll never hear it. Thnaks Dbr <adrigen> Ooh, luck he didnt hear that.
08:48:32 <gncbot> jsled: The operation succeeded.
08:52:03 *** exper_ has joined #gnucash
08:57:24 *** IanL has quit IRC
08:58:59 *** exper has quit IRC
09:02:00 *** warlord-afk is now known as warlord
09:02:22 *** keith has left #gnucash
10:11:45 <jsled> blizzard. hmmf.
10:12:00 <jsled> It's good to work from home. :)
10:14:16 <BC^bd> jsled: does have its downsides too
10:14:27 <BC^bd> at least imho
10:14:39 <jsled> Oh, it does, true.
10:16:01 <warlord> I'm glad I'm still in FL.
10:16:51 <BC^bd> warlord: isn't it like 6 in the morning there?
10:17:04 <warlord> No.. it's 10:15
10:17:30 <BC^bd> doh! east coast :)
10:18:03 <warlord> Um, yeah! Florida is right below Georgia.. ;)
10:18:29 <warlord> I'm about 6 miles from the Atlantic Ocean ;)
10:20:38 <BC^bd> well no sea here but the alps are well around the corner. not much help this year because there is no snow
10:23:21 <warlord> :(
10:31:39 *** Jack has joined #gnucash
10:31:45 *** Jack has left #gnucash
10:57:03 <prock> warlord: you tried compiling with my macintel patch and it failed, correct? do you recall what it failed on?
10:57:20 <warlord> prock: I didn't try, but it fails on win32
10:57:49 <prock> I tried compiling a patched version on debian and it fails on gnucash-bin but it's easily fixed by adding a couple lines to src/bin/Makefile.am
10:58:35 <prock> @tell cstim you mentioned that my 'macintel' patch caused the win32 build to fail. Where/how did it fail?
10:58:35 <gncbot> prock: The operation succeeded.
10:59:11 <warlord> prock: it probably fails in libgncmod-register-gnome because you dont link the main register library in.
10:59:17 <warlord> on win32 you HAVE to link it.
10:59:42 <warlord> I find it odd that the code works everywhere EXCEPT Mac/x86. Mac/PPC works fine!
11:10:23 <prock> I agree that it's weird but I'm still not convinced that gnucash isn't doing something wrong that other compilers are being more forgiving about.
11:10:51 <prock> every other project that I've found that has come across this has been able to work around it in some way.
11:11:26 <warlord> I dont know whether gnucash is in the right or wrong..
11:11:45 <warlord> I'm certainly willing to change gnucash if necessary.. But it still needs to work on all the platforms.
11:12:08 <warlord> The fact that it works on Mac/PPC, Linux, BSD, and win32 but NOT Mac/x86 seems to point to something weird with that one platform.
11:12:09 * prock nods
11:12:38 <warlord> So, basically... You can't just not link the libraries. That breaks win32 because win32 can't have undefined symbols.
11:14:17 <warlord> The reason 2.0 works is because we use libltdl instead of g_module, and libltdl stripped off the LTX_<module>_<symbol> prefix automagically.
11:15:16 <prock> g_module is gnucash or glib?
11:16:23 <warlord> glib
11:16:40 <warlord> see src/gnc-module/
11:16:43 <warlord> (in gnucash)
11:17:20 <warlord> now.. architecturally gnucash is "broken" in that the line between a "shared library" and "module" isn't drawn very cleanly.
11:17:45 <warlord> ... and this architectural flaw DOES need to get fixed, eventually.
11:17:49 <prock> what is a module anyway?
11:18:42 <warlord> --> webster module
11:18:42 <warlord> mod.ule \'ma:j-(.)u:(*)l\ n [L modulus] 1: a standard or unit of
11:18:42 <warlord> measurement 2: the size of some one part taken as a unit of measure by
11:18:42 <warlord> which the proportions of an architectural composition are regulated 3: a
11:18:42 <warlord> usu. packaged functional assembly of wired electronic components for use
11:18:43 <warlord> with other such assemblies
11:18:45 <prock> the docs I've looked at in trunk/doc and trunk/src/doc mention the modular design of gnucash but I couldn't find where a module is defined
11:18:55 <prock> well yeah.
11:19:01 <prock> I mean as far as gnucash is concerned.
11:19:14 <warlord> the gnucash definition is... unclear.
11:20:19 <warlord> Ask three developers and you'll probably get five answers.
11:20:45 <warlord> But basically, a GncModule is a shared object that gets loaded at runtime and has runtime/loadtime initialization routines.
11:21:44 <jsled> gncbot: tell esodan The gobject-dev branch doesn't build right now, really early on; should it?
11:21:44 <gncbot> jsled: The operation succeeded.
11:25:16 <prock> what's the motivation for modules?
11:25:37 <prock> i.e. what's the motivation for GncModule?
11:25:44 <jsled> modularity. :)
11:25:54 <prock> :\
11:27:09 <warlord> Seriously, that's a good question. In many cases it's to allow/enable optional functionality. You should be able to run a gnucash application without the UI, without the business features, without various importers, without various backends, etc.
11:29:11 <prock> that sounds like a nightmare for testing...
11:29:34 <prock> it makes for a large number of potential configurations.
11:30:06 <jsled> I'd argue it makes testing easier, since the boundries are more clear.
11:30:51 <jsled> That is, if you're testing foo in the arrangement of foo,bar,baz or foo,baz,quuz modules, it shouldn't change the results.
11:30:59 *** ceplma has quit IRC
11:31:02 <prock> but is that not what shared libraries are for? What warlord has described to me is something that is supposed to be able to turned on or off at the users' discretion.
11:31:48 <jsled> I don't think so. The user doesn't control what backends or import modules are arranged.
11:31:53 <jsled> The packager/builder/developer does.
11:32:08 <warlord> a module is like a shared library.. think "plugin"
11:32:21 <jsled> Uh.
11:32:33 <jsled> "Plugin" means a lot more to me.
11:32:37 <warlord> true.
11:32:50 <warlord> but it might get prock to think in the right direction.
11:32:59 <jsled> I think of xchat or evolution plugins. Things independently built and really dynamically loaded by the user.
11:33:07 <jsled> Or mozilla extensions.
11:33:08 <warlord> anyways, I need to head out.. I'll be back in an hour.
11:33:12 *** warlord is now known as warlord-afk
11:33:14 <jsled> I argue that that's not something gnucash needs.
11:34:08 <jsled> I.e., there's no need to load -- say -- hbci at runtime, vs. ./configuring it into the build.
11:35:42 <jsled> I think the key phrasing is "run a gnucash application [...]". Not necessarily run /usr/bin/gnucash, but maybe a separately-configured gnucash-cli or gnucash-httpd or something.
11:36:29 <prock> In the case of gnucash-cli or gnucash-httpd... shared libraries still make sense.
11:36:36 <jsled> The common requests are for: - a way to post invoices/transactions from a script; - a way to generate a report via a cronjob.
11:36:39 <jsled> yup.
11:37:26 <jsled> prock: the module system we inherited is overkill. It's also arguably at the wrong level of granularity, per directory rather than per functional unit.
11:38:32 <prock> The only useful thing I see the modules doing for gnucash at this time that shared libraries is giving an easy way to enable/disable features without using #ifdefs.
11:38:33 <jsled> though that last point's debatable. I think if we worked on it, we might elide only a couple of dirs. app-utils vs. core-utils ... gnome-utils vs. gnome ... register-core vs. ledger-core.
11:39:51 <jsled> (and then, is it worth it...?)
11:39:52 <jsled> prock: right.
11:40:07 *** esodan has joined #gnucash
11:40:15 <jsled> hey esodan
11:41:36 *** dbr has joined #gnucash
11:42:08 <esodan> hey jsled, how are you?
11:42:08 <gncbot> esodan: Sent 12 hours and 32 minutes ago: <warlord> Sorry, I was out to dinner when you PM'd me. You can always have gncbot give me a message.
11:42:09 <gncbot> esodan: Sent 20 minutes ago: <jsled> The gobject-dev branch doesn't build right now, really early on; should it?
11:42:20 <jsled> esodan: good. how're you?
11:43:01 <prock> when are modules loaded/unloaded? during initialization/cleanup or throughout program execution?
11:43:10 <esodan> Very well and best now I can summit my current work...
11:43:37 <jsled> prock: they're all loaded at startup, I believe.
11:43:55 <jsled> esodan: It's "submit". "summit" is the top of a mountain.
11:44:21 <esodan> OOOhmm sorry, thanks...
11:45:09 <prock> where does the list of modules to load come from?
11:45:39 <esodan> Have you time to review some of my current, unfinished work?
11:47:29 <esodan> prock: are you interested in a particular module?
11:47:53 <prock> esodan: quite the contrary, I assure you ;)
11:48:29 <jsled> prock: src/bin/gnucash-bin.c:load_gnucash_modules looks like the place
11:49:16 <jsled> though IIRC the engine tries to load the postgres backend explicitly, and some of the scheme/reports code is modules as well.
11:49:51 <esodan> jsled: If you see my work you could find that my port to GObject have made to deprecate most of QOF actual object enviroment, events, and so...
11:50:06 *** twunder has quit IRC
11:50:07 <jsled> esodan: we've been talking about the modules generically; http://lists.gnucash.org/logs/ if you want to read the back-talk.
11:50:33 <jsled> esodan: yeah, I've seen some of it, but it's hard to get it all, and I've been busy with some changes of my own.
11:50:40 <jsled> esodan: is it supposed to build, right now?
11:50:50 *** twunder has joined #gnucash
11:51:15 * jsled is biab; need to dig something out of the car before we get too much more snow.
11:53:02 <esodan> jsled: not yet, It's realy dificult to port, becouse the actual code access directly to the members in its parents, theres a lot of functions in util that must be API functions in some objects, try to understand the registration way (actualy deprecated not used any more)... and so...
11:54:31 <esodan> I'm working object by object, finding the calls and where is the best plase to use, in most of the cases becouse this functions access internal members in the object and now you can't do so, you need to use the API...
11:55:13 <esodan> You'll find new API in QofInstance, QofBook and QofBackend...
11:56:23 <esodan> I'm currently working in the Account object, when I go to the next object I allways find that I need to go back to the QofInstance, QofBook or others...
11:57:04 <esodan> implement a new API and/or merge code from qofutil.c/h file for example...
11:59:02 <esodan> I hope that when I finish the Transaction object, the API in the base (QofInstance) will be stable enough...
12:00:29 <esodan> I realy working a lot to port the actual code to GObject, and I hope that QOF will be in the past and remain the ones used by GC...
12:02:12 <jsled> What's wrong with accessing members in parents?
12:02:19 <jsled> Why are you changing things like that?
12:03:03 <esodan> Becouse this work I think that is better to rename the QofInstance object (the base for all objects in GC) to GncObject... if we try to do so after finish the port will be too late, will be too may work to do at that point...
12:03:04 <jsled> "the registration way"?
12:04:38 <esodan> jsled: 1fst Q: This will protect the object against unauthorized access to its members
12:04:40 <jsled> I don't understand what renaming QofInstance to GncObject has to do with accessing member variables.
12:04:55 <jsled> "unauthorized"?
12:05:21 <esodan> jsled: 2nd. Q: This is recomended way to create new GObject derived objects...
12:07:10 <jsled> Right, but again, you're not creating new GObjects.
12:07:17 <jsled> You're adapting a huge mess of existing code.
12:07:34 <jsled> And you just don't need to change those things right now.
12:07:39 <esodan> jsled: Qofinstance to GncObject? Now I'm using QOF_INSTANCE (object) to cast from one object to QofInstance (this is more clear and recomended way to access to the QofInstance parent object)
12:08:13 <jsled> Right. So Instead of ((QofInstance*)foo)->bar, you're just saying QOF_INSTANCE(foo)->bar? That's fine.
12:08:54 <esodan> This is a work do it again and again in each object, then is better to do it with the final object name...
12:09:16 <jsled> I don't think that is necessarily true. Two steps that work are better than one that doesn't.
12:10:55 <jsled> I'm not sure that you want to make this change right now:
12:10:55 <jsled> +#define qof_book_destroy (b) g_object_unref (b)
12:11:03 <jsled> I don't think the semantics are necessarily the same.
12:12:01 <esodan> Right, but in a way to make the things more clear to me, and may to the others, I doing this changes, and more some objects like GncBudget and others use a private members to protects it's members ( I find that the resent added objects use the GObject recomendations)...
12:12:12 <jsled> Changing the eventing code to signals is probably premature as well.
12:12:39 <jsled> Right. Remember that much of QOF was written before gobject existed.
12:12:44 <jsled> And gnucash,
12:14:34 <esodan> The event code is better to be deprecated and easy to change to g_signals, theres no more that 10 files that use the qofevents to register handlers, change that code to use g_signal_connect it's easy...
12:15:47 <esodan> the qofevents are three, no more and are realted to the QofIntance objects...
12:16:16 <jsled> There's 49 .c files that contain the string "qof_event"
12:16:53 <jsled> I'm not arguing that we should retain qof eventing forever. I'm saying do it later.
12:18:01 <jsled> There's no need to change that. Or object names. Or file names. Or using ref-counting. Before you even have the first change done and the system compiling again.
12:18:20 <esodan> In most of the cases theres a one line, easy to change see /src/gnome-utils/gnc-tree-model-commodity.c
12:18:24 <jsled> Don't try to do too much at once. This project has a real risk of collapsing under its own weight.
12:18:53 <jsled> 1000 one-line changes will add up...
12:19:42 <jsled> esodan: what are you referencing in gnc-tree-model-commodity?
12:20:10 <esodan> May be the qofevent could wait some few time, but the creating/destroying of objects must change in order to insure a correct work and memory leaks or some of that...
12:20:27 <jsled> No, it doens't.
12:20:31 <jsled> doesn't, even.
12:20:35 <jsled> Well, yes it does.
12:20:38 <jsled> But it doesn't need to change right now.
12:20:52 <jsled> Stop trying to make everything the Perfect GObject way.
12:21:06 <esodan> jsled: see the line 228, it just register a callback that's is easy to change to g_singnal_connect, but again may not for now...
12:21:22 <jsled> We don't need refcounting right now. The explicit memory alloc is silly, but it works reasonably well right now.
12:22:15 <esodan> My point in discusion is that I want to change the QofInstance to GncObject, becouse I doing changes now to use the actual and new QofInstance API, and I want to do it for GncObject...
12:22:30 <jsled> Right. That's the *easy* line. :) Look at the event handler on line 1201. There's 3 different signals, there...
12:23:50 <jsled> And qof events behave differently than gobject signals.
12:24:03 <jsled> There's different rules about how they're combined, and different ways to supress their generation.
12:24:25 <esodan> Yes, but I don't need to touch this code too much becouse I can create a handler in GLib that calls this callback with this arguments...
12:25:34 <jsled> Well, the other option is to not touch it at all, until you're ready to change it. :)
12:25:58 <esodan> Again, may isn't time to discuss about events, this isn't my point today, I want to use GncObject instead QofInstance... :)
12:27:51 <esodan> jsled: yes for the moment I don't deleting the code for event generation... I'm keeping them
12:28:23 <jsled> I don't think I have a problem with using GncObject instead of QofInstance for converting the types into GObject types. I'd suggest it on -devel.
12:29:27 <jsled> Though the code already says QofInstance ...
12:29:30 <esodan> (I promise to improve my english ASAP) :-D
12:30:13 <jsled> esodan: your native language is spanish?
12:32:06 <esodan> jsled: Yes I begin using QofInstance, but the actual is quiet diferent from the original and I think is better to do the change now before continue to work in the remaining objects
12:32:24 <esodan> jsled: Yes I'm mexican...
12:32:45 <jsled> esodan: your english is much better than my spanish, so don't worry about it! :)
12:33:26 <esodan> jsled: Thanks... :-D
12:33:47 <esodan> Then I begin to change to GncObject...
12:34:01 <jsled> esodan: perhaps. I never know how to feel about rototilling code like that. I mean, it looks like -- in gnc-commodity for instance -- that it's already QofInstance.
12:34:20 <jsled> (where a GObject[Class] or GncObject[Class] would be.)
12:34:23 *** hampto1 has joined #gnucash
12:34:23 *** gncbot sets mode: +o hampto1
12:34:28 <jsled> So, what's the problem with using QofInstance...?
12:38:08 *** warlord-afk is now known as warlord
12:38:17 <warlord> esodan: I'd hold off changing the name of GncInstance.
12:38:22 *** ceplma has joined #gnucash
12:38:35 <warlord> Don't worry about changing the semantics of QofInstance
12:38:48 <warlord> It's easy to write a sed/perl script to change the name later.
12:39:10 <esodan> I can use typedef GncObject QofInstance, and start to use the API with gnc_object enstead qof_instance...
12:39:16 <warlord> I'd rather you make small changes that WORK than make major changes all at once that don't.
12:39:38 <warlord> esodan: Do that later. Get it working with QofInstance first as a gobject.
12:39:53 <warlord> The more you change at once (without it /working/) the greater the chance the port to gobject will fail.
12:40:23 <warlord> It may SEEM like more work to do it in multiple steps, and perhaps it IS more work.. But it means you have WORKING CODE in the intermediate steps.
12:42:46 <esodan> warlord: Aaagggrrr, you right (again), I realy want to changes the the code at one (reference) while I work and keep the unchanged one using the QofInstance (using typedef)....
12:43:06 <warlord> Dont do that.
12:43:17 <warlord> If you want to keep a reference copy, you've got trunk
12:43:22 <warlord> Just change QofInstance in place.
12:43:35 <warlord> Remember, we want to make as FEW changes as possible..
12:43:44 <warlord> The goal: get it working.
12:43:50 <warlord> Cleanup can happen AFTER you get it working.
12:44:15 <esodan> Ok... I'll continue the actual work...
12:44:24 <esodan> Have you see it?
12:45:56 *** ErKa has quit IRC
12:46:36 <esodan> I want your point about the changes in Account.c, qofinstance.c and qofbackend.c
12:50:50 <esodan> many things has happend: the qof_begin_edit/commit_edit are now part of QofInstance API, and for Account the xaccCommitEdit doesn't exist any more...
12:51:10 <esodan> becouse you will call qof_instance_commit_edit, ...
12:51:30 <esodan> and the methods xaccAccountSortSplits and xaccAccountRecomputeBalance are called when the QofInstance object emits a "commited" event...
12:51:57 <esodan> this is in order to ensure a correct construction/destruction of the GncAccount object...
12:52:43 <warlord> that seems reasonable, I think.
12:55:03 <esodan> This modifications makes me to review the actual QofBackend error handling, and find a not finished code to handle multiple errors in the object operations...
12:55:55 <warlord> Yeah, we dont stack errors well.
12:56:01 <esodan> becouse actually this object just handle one deep error, I deprecated this code to use GError...
12:56:53 <warlord> Probabaly a good idea.
12:58:12 <esodan> Now when you call qof_backend_run_begin / run_commit you must add a GError** pointer in order to know if an error exists...
12:59:00 <warlord> Um, just think about what that would mean for the Scheme API..
12:59:11 <jsled> Probably true, but probably not something that needs to change right now.
12:59:12 <warlord> (why can't you just return a GError*?)
12:59:42 <warlord> e.g. typedef GError* QofBackendError
12:59:59 <warlord> Esaj: true, this change (again) doesn't need to happen right now.
13:00:16 <jsled> esodan: btw, if you're not subscribed to gnucash-changes, you might want to. If only to see changes on trunk or other branches that might conflict in the future.
13:00:48 <esodan> Well if you don't need to handle the error you can pass a NULL pointer... and becouse this is method used in GLib's objects...
13:01:02 * hampto1 hopes his changes to remove the group structure don't conflict too badly
13:01:38 <hampto1> warlord: All the glib libraries use GError** as the last argument to a function that may return an error.
13:02:46 <hampto1> Can anyone tell me when I dropped off? I'm unable to change my nick to hampton and am wondering if my previous session just hasn't timed out yet.
13:04:08 <warlord> Well, I wonder what SWIG would do with that?
13:04:18 <warlord> (just something to think about)
13:05:22 <jsled> hampto1: ping timeout (600 seconds) at 1:33 EST.
13:05:23 <jsled> (am)
13:06:05 <esodan> warlord: This change is becouse xaccAccountBeginEdit checks for errors, I simple change this code in order to show the actual PERR errors messages, even qof_instance_commit_edit use a GError** and sets it if an "unbalanced call" happends...
13:06:34 <hampto1> warlord: I whould think swig would have already handled this. glib uses this all over the place.
13:08:00 <warlord> Okay... Also we might need to think about how we're going to swigify the commit_edit calls! I dont think guile/swig supports the gobject-style polymorphism.
13:08:16 *** ErKa has joined #gnucash
13:10:58 *** hampto1 has quit IRC
13:11:06 <esodan> For now I can't see that but I think could happend in a way (In the future I'll see at swing)...
13:11:35 <warlord> esodan: I said "swig" -- it's the guile wrapper.
13:12:36 <warlord> In the short term I think xaccAccountCommitEdit() should continue to exist.. Even if all it does is call qof_instance_commit_edit(). If you change the APIs for functions exported to guile/scheme then LOTS of stuff will break. Remember: make as few changes as necessary!
13:13:53 *** hampton has joined #gnucash
13:13:53 *** gncbot sets mode: +o hampton
13:14:17 *** mnoir has joined #gnucash
13:15:08 <warlord> esodan: have you ever sailed?
13:16:18 <esodan> warlord: I have #define xaccAccountBeginEdit qof_instance_begin_edit, then the API will continue to work...
13:17:55 <warlord> esodan: I.... dont know if that will still work with swig.
13:20:07 <esodan> warlord: Could you help me? Could you review swig?
13:20:36 <warlord> esodan: i would, but your branch doesn't build.. which is where jsled started this all!
13:21:04 *** MrN has joined #gnucash
13:21:33 <MrN> hi
13:22:07 <esodan> warlord: please just see the code and check if swig could handle this or not...
13:23:10 <warlord> Well, honestly, I dont know if swig will properly wrap a #define
13:23:14 <warlord> maybe chris knows
13:24:04 <MrN> "properly wrap a #define"? that's, like, impossible :P
13:25:04 <esodan> If there's a problem, may (when I try to compile) I can create dummy functions or see if swig can handle GObject's polymorphic
13:25:28 <warlord> I'm pretty sure it wont handle the polymorphism.
13:27:43 <esodan> Well if we want to use GObject may is time to see how we can do swig to work with GObject...
13:29:13 <warlord> esodan: I dont agree with that statement.. Remember: change as little as possible. This means that we can just keep the existing API, even if a function, e.g. xaccFooDoBar() just turns around and calls qof_instance_do_bar()..
13:29:25 <esodan> Well boys I'll continue to work and sent more commits...
13:29:27 <warlord> Then you dont have to change ANY of the callers of xaccFooDoBar().
13:31:04 <esodan> warlord: I agree, if this is an unsolved problem becouse swig, then I'll make the necesary wraps to keep swig to work...
13:31:42 <warlord> esodan: I think it's easier to keep the wrappers now.. It means fewer changes to the code.
13:31:43 <esodan> Even if this means to create dummy functions...
13:31:54 <warlord> What dummy functions? The functions already exist.
13:33:00 <esodan> well first see if swig will work well or not, I have too much work in front and I can goback when necesary, but please tell me exactly the problem and how it could be solved...
13:33:26 <esodan> Don't worry I working in the first Objects then we have time...
13:33:29 *** franz has joined #gnucash
13:33:57 <warlord> esodan: it's easy to backout a changeset. You've only made two commits.
13:34:02 <esodan> I'm refering to your comment about xaccFooDoBar() example...
13:34:30 <warlord> well, xaccFooDoBar() would already exist in the current code...
13:35:12 <warlord> I'm just saying that you shouldn't remove xaccFooDoBar().
13:35:34 <esodan> warlord: if I need to call a Foo() becouse a problem in swig, then I'll call Foo() even if it just call other polimorphic function...
13:36:00 <esodan> Yes, I don't...
13:36:17 <esodan> But just if swig can't manage it... please tell me...
13:36:34 <warlord> Don't use #defines, just leave the functions there.
13:37:49 <warlord> I dont know if swig can handle it.. And I dont really want to do that research right now. It's just easier to leave the API in place.
13:42:08 *** exper_ has quit IRC
13:42:08 <chris> swig can handle the #defines just fine.
13:42:31 <chris> We already handle a lot of adapted apis that way.
13:44:01 <warlord> chris: but will it handle gobject polymorphism?
13:44:23 <warlord> (or do you have to explicitly tell swig what the wrapped api SHOULD look like?)
13:46:02 <chris> esodan: just to clarify... you don't have to convince us about the value of all these changes to the GObject-way. We agree, really. But we have to push back about the incremental nature of the changes. You really need to be ruthless about making the smallest possible changes. That doesn't mean you can't make all the changes you want over time.
13:46:57 <chris> esodan: It just means that there needs to be working intermediate steps in between. Remember what jsled said - "Two changes that work are better than one that doesn't".
13:47:11 * jsled nods
13:47:30 * warlord nods too
13:49:21 <chris> warlord: It has some methods of handling polymorphism, but I don't think I used them.
13:50:29 <warlord> Okay..
13:50:43 <chris> I think I ended up wrapping prototypes with the derived types, but there are other ways, too.
13:51:24 <warlord> I just think that for now we should just keep the full-functions that already exist, even if it's a trivial function that calls the polymorphic API.
13:51:30 <chris> It doesn't _automatically_ figure out the inheritance relationships from the code, though.
13:51:51 <warlord> that's what I thought.
13:52:20 <chris> yeah, keeping functions that wrap the parents functions is a good idea for now.
13:54:10 <esodan> Ok, the I'll keep the actual functions just to wrap the GObject migration and keep the smallest the changes...
13:55:20 <esodan> I don't want to changes too things, realy (may be for moments I lose the control, but I'll take it don't worry :))...
13:56:23 <esodan> My changes will be on the creating/destruction and get/update from the backend, but just if could be a potencial conflict...
13:57:32 <esodan> I'll try to write notes with TODO (outside the code near all cases) with future improvements...
13:59:51 <chris> esodan: focus on keeping the tree buildable. It's not really a good sign to make > 3kb of changes and not have a buildable tree.
14:00:59 <prock> how are register-core and register-gnome supposed to be related? Is register-gnome a child of register-core?
14:01:00 <esodan> I'll do, but for now I need to finish the GC's Objects modifications to sync with the work in the parent...
14:01:20 <jsled> prock: pretty much. It's the gnome-specific implemntations of the cells.
14:01:35 <jsled> (for the most part)
14:01:44 <warlord> prock: yeah, register-core is UI agnostic. register-gnome isnt
14:01:56 <warlord> esodan: I'd even ignore the backend get/update!
14:01:58 <esodan> I hope to finish ASAP, and try to compile...
14:02:05 <jsled> well ... toolkit-agnostic, anyways.
14:04:42 <esodan> warlord: OK, I just see them if they have potencial conflicts... no more unnecesary changes...
14:08:03 <warlord> We'll deal with conflicts as the arrise.
14:08:15 <warlord> Changing to GObject (without ANY OTHER CHANGES) shouldn't cause conflicts.
14:15:17 <esodan> The QOF's code has the answers...
14:16:20 <warlord> Yeah. You should be able to change the code in lib/qof without having to make changes most anywhere else!
14:21:14 <esodan> I have a problem, in GLib/GObject and other GC's objects like GncBudget, the object protects its struct members using a Private pointer, then just the functions for this object (in the same .c file) have access to this members...
14:21:47 *** andi5 has joined #gnucash
14:21:47 *** gncbot sets mode: +o andi5
14:22:01 <warlord> esodan: go on...
14:22:47 <esodan> warlord: Ok, then I'll modify most GC's objects, I'm now on Account, next Transaction and so...
14:23:18 <warlord> esodan: I mean, go on with stating the problem....
14:23:40 <hampton> For now those fields should be in the public definition of the object. at some point they should be moved to the private definition and only be available through accessor functions. The decision needs to be field by field.
14:24:09 <hampton> (Leaving them public for now allows for a smaller change set.)
14:24:51 <andi5> hampton: hi... do you run fc6?
14:25:21 *** mnoir has quit IRC
14:25:46 <esodan> Ok, I forget for other objects, the change is done at Account...
14:26:10 <hampton> yes
14:26:49 <andi5> hampton: do you have any idea what #364946 is about, have you ever seen it?
14:27:04 * hampton goes to look at bugzilla
14:32:51 <hampton> Never seen it. The bug appears to be that some sort model and filter model have gotten out of sync with each other. I've fixed similar problems in the past. I wonder if something changed between gtk2.8 and 2.10 that started causing these bugs (or tightened the rules so that gnucash no longer is compliant).
14:34:06 <andi5> any idea how to fix that bastard?
14:35:00 * andi5 trashed his fc6 accidentally, but somehow does not feel like installing it once more :)
14:35:53 <hampton> lots of tedious stepping through gnc_tree_xxx and gtk_tree_xxx in gdb. :-(
14:53:34 <warlord> :(
14:53:41 <warlord> can't use a 'watch' point?
14:54:58 <hampton> don't know that I've tried. helps walking through the code several times to see what the normal path is, then its easier to spot a broken path.
14:55:30 <hampton> reference counted objects would allow the gnucash TreeModel code to be a whole lot cleaner
14:56:56 <andi5> jsled: 1 day? ... what about 7?
14:57:33 <jsled> What about 7? It seems like you need the most recent 2 backups ... anything else is up to your, uh, backup system.
14:58:17 <jsled> Or maybe even just *a* backup ... the state of the file before the recent session.
14:59:15 <hampton> speaking of backups.....
14:59:24 * hampton starts his backup running
14:59:42 <jsled> heh.
14:59:47 <jsled> gotta cron those. :)
15:00:00 <andi5> hm.... i do not feel flooded, but like the backups..... sometimes i clean up a bit, ok
15:00:29 <andi5> well, but the question is not what i like, i know
15:00:51 <warlord> I would prefer the default being 7-10
15:01:06 <warlord> hampton: indeed, refcounting would be useful.
15:01:22 <jsled> Nor me, of course. I do think we get the "what the fsck are all these files?!?" more often than we need to, though.
15:01:40 <hampton> I think 1 week is a better default
15:01:59 <warlord> Well, I also think there's a bug in that .log files aren't being deleted.
15:02:12 <hampton> jsled: I would except they're to an external disk that is usually powered off
15:02:22 <jsled> hampton: Ah.
15:02:29 * warlord needs a better, automated backup syste,
15:07:38 <warlord> for example, I've got a .log file dated Nov 2006 still sticking around..
15:07:56 <warlord> Then again I've got a .xac file dated June 3, 2006
15:08:35 <andi5> warlord: i will try to take a look at it....
15:09:22 *** andi5 has quit IRC
15:10:04 <jsled> It seems to here. I open my datafile every week, with a retention of 7 days, and only have log (and xac) files going back as far.
15:10:21 <jsled> (for 2.0.4 proper, at least)
15:11:03 <warlord> I just opened my personal datafile with 2.0-branch and even though I've got 30 days configured I still see Personal-2007.20070114225322.xac
15:11:22 <jsled> Oh, except for a lone .xac backup that's a bit older; maybe there's an off-by-one error....
15:13:18 <warlord> Ahh, I just clicked "save" and all of them went away except for one.. Yeah, looks like an off by one error.
16:09:25 *** bab__ has joined #gnucash
16:10:08 <bab__> anyone know if there is a way to get a projection of assets and net worth based on a budget?
16:10:39 <warlord> i dont think we have any projection reports
16:10:55 <bab__> warlord, oh all right. that's too bad
16:11:18 <warlord> nobody has written one. care to try?
16:11:25 <bab__> hehe, what would it involve?
16:11:40 <warlord> a little scheme hacking..
16:12:00 <bab__> hmm... i haven't programmed in scheme before. i started to read up on lisp last summer and didn't get very far
16:12:22 <bab__> for someone who's done most OO languages (and some C, assembly, and bash) how hard would it be to pick up scheme?
16:12:29 <bab__> *mostly
16:13:01 <warlord> if you're at all intelligent you can learn the syntax in a day.
16:13:14 <bab__> hehe all right
16:13:17 <warlord> and pick up the basics of the semantics in a week.
16:13:20 <elb> learning to use scheme paradigmatically is a different story ;-)
16:13:27 <warlord> true..
16:13:32 <bab__> i see
16:13:48 <elb> making scheme work for you in this limited context shouldn't be hard for any programmer
16:14:02 <bab__> all right
16:14:07 <bab__> maybe i will give it a shot then
16:14:13 <elb> learning to write *good* scheme that other people will want to read and modify is somewhat more difficult, if you do not have a functional programming background in any other language
16:14:13 <bab__> what documentation would be helpful?
16:14:45 <bab__> i have a fair amount of programming experience, but not in scheme
16:14:59 <elb> there are a zillion scheme tutorials on the web
16:15:03 <warlord> google for mit scheme reference
16:15:05 <bab__> okay
16:15:08 <elb> I think MIT has the texts for an entire semester scheme course online, too
16:15:22 <bab__> got it
16:15:52 <bab__> where should i look in the gnucash code for this sort of functionality (by that I mean: where should it be added)?
16:17:52 <warlord> src/reports/standard-reports/
16:18:06 <bab__> all right
16:19:00 <bab__> i'll look into it
16:19:04 <bab__> thanks for the pointers :)
16:19:21 <warlord> good luck!!
16:19:36 <bab__> thanks
16:48:24 *** esodan has quit IRC
16:48:53 *** bab__ has quit IRC
16:59:36 *** wizkid238 has quit IRC
16:59:39 *** Esaj has quit IRC
17:04:12 <chris> [ot] does OSX have an equivalent to /proc/{$pid}/cwd ?
17:05:50 <warlord> I dont think so.
17:05:58 *** wizkid238 has joined #gnucash
17:11:07 *** twunder has quit IRC
17:28:23 *** esodan has joined #gnucash
17:28:37 <esodan> hi all I have a question... in the Transaction.c file in the function xaccTransGetReadOnly line 1703, theres a note acout that GetReadOnly should be cached in the transaction (I understand as a member in the object struct), can I make this change... and other...
17:28:40 <esodan> When you set a transaction read only...?
17:29:34 <esodan> in line 1866 you set readonly when it is "voided", Is this mean "empty" or what?
17:33:18 *** ceplma has quit IRC
17:33:38 <warlord> esodan: You mean cache in the transaction as opposed to in the kvp? Or in addition to?
17:33:52 <jsled> No, voided transactions are ones that are invalid or reversed, but are still on the books.
17:34:16 <jsled> Like, you screwed up, and need to void the transaction, but deleting the screwed up thing leaves no trail.
17:36:28 <esodan> jsled: thanks, then this mean the Transaction exist in the book, but I can't modify it... right?
17:37:28 <warlord> esodan: the Transaction code should already handle that..
17:37:37 <esodan> warlord: in the code you set the ReadOnly state usign KVP, but in the note like 1703 sugest to use a member in the Transaction struct (I think this is ok)...
17:38:40 <esodan> Even I can leave it *as is* for now, I need to know if I need to check before if the object is readonly...
17:39:42 <esodan> Do you know any case a QofInstance could be readonly? if so I can add a gboolean readonly; variable and check it before to begin_edit and commit...
17:40:36 <jsled> why would you do that?
17:41:52 <warlord> esodan: no, we dont need a readonly flag in qof_instance.
17:41:56 <warlord> You're thinking too hard, again!
17:42:42 <warlord> PLease... stop trying to migrate Where/How data is stored.
17:42:48 <warlord> Leave the APIs as they are.
17:43:02 <esodan> Hmmmm!, Ok I need to check how to implement the ReadOnly check in a Transaction before to destroy it...
17:43:03 <warlord> I dont know how many times I, Chris, Jsled, and Hampton have to repeat this to you
17:43:12 <warlord> No, you dont.
17:43:21 <warlord> You can still destroy a readonly transaction. The current code does it.
17:43:50 <warlord> Follow the existing logic.
17:44:45 <warlord> Seriously, you should NOT have to make many source-code changes outside of lib/libqof/qof
17:44:49 <esodan> I'm doing see the code at:
17:44:53 <warlord> (at least in the first pass)
17:47:09 <esodan> See at /src/engine/Transaction.c, line 969
17:47:40 <warlord> Line 969 is a blank line...
17:47:55 <warlord> In between these lines:
17:47:57 <warlord> g_list_free(slist);
17:47:57 <warlord> xaccTransWriteLog (trans, 'C');
17:48:16 <esodan> Then Let me update, please...
17:48:23 * warlord is looking at trunk
17:49:55 * warlord has to leave in about 5 minutes.
17:51:01 <esodan> The current line is 847, at xaccTransDestroy function...
17:52:51 <warlord> Ahh, Right... See, the same functions are used to try to delete a transaction from the current book, and to free memory when you're shutting down.
17:52:53 <esodan> is review the Trunk
17:53:24 <warlord> The logic here is that you can only destroy the transaction if it's NOT readonly or if you're shutting down the book and just clearning memory.
17:54:17 <esodan> Ok, then I need to check is this Transaction is ReadOnly before to try to destroy it... right?
17:54:39 <warlord> You need the exact same logic..
17:54:45 <jsled> Why do you need to change this code at all? What's wrong with the way it is?
17:55:01 <warlord> yeah, why DO you need to change this code?
17:56:18 <esodan> I'm cheking how I can call qof_instance_destroy for any kind of object, and have a correct object destruction...
17:56:25 <warlord> You cant.
17:56:28 <warlord> Dont do that.
17:56:44 <warlord> leave the existing xaccFooDestroy() APIs.
17:57:06 <esodan> Any specific reason?
17:58:23 <warlord> Because you dont have to.
17:58:38 <warlord> Er, because you can. Because you dont HAVE to change these APIs..
17:58:46 <warlord> Because changing these APIs are more work.. More unknowns..
17:59:02 <warlord> and puts the initial GObject work even further off.
17:59:11 <warlord> What part of "MINIMAL CHANGES" are you failing to understand?
17:59:17 <jsled> esodan: is there somewhere that calls qof_instance_destroy without knowing what type of object it is?
17:59:23 <esodan> Ok, Ok, Ok, I leave it...
17:59:55 <warlord> jsled: I can't imagine there is otherwise the existing code wouldn't work.
18:01:50 <esodan> jsled: It's easy all object are derived by QofInstance, then the GObject allways know the type of object and knows how to destroy it (each object has a _finalize function)...
18:02:28 <esodan> then when you use g_object_unref (G_OBJECT (object)), the correct functions and in the correct order are called...
18:02:55 <jsled> Right. We know how gobject destruction ideally works.
18:03:14 *** Esaj has joined #gnucash
18:03:16 <esodan> You just need to be sure about this process is correct (and that's I'm trying to do)
18:03:48 <jsled> It's going to be very hard to make sure that process is correct at this point.
18:03:49 <warlord> esodan: we understand that EVENTUALLY that's where we want to be.. BUt it's a long road. Many miles to drive to get there.
18:03:59 <jsled> That should probably be one of the last things to cahnge.
18:04:22 * warlord thinks we might want to start over again from scratch..
18:04:43 <jsled> What, with gnucahs?
18:05:16 <warlord> ... re-start from current trunk and try to keep ALL your changes into lib/libqof/qof
18:05:22 <jsled> Ah. Heh.
18:05:34 <warlord> (sorry, jsled.. was typing slowly)
18:05:55 <esodan> well I hope not... :-$
18:05:55 <warlord> so, the first step: keep all changes in libqof without changing the (compile-time) QOF API.
18:06:14 <warlord> esodan: Hey, sometimes you have false starts and need to start over.
18:06:51 <warlord> Seriously.. The fact that you're questioning xaccTransDestroy() means you have the WRONG idea of where we're trying to get to in step-1.
18:06:54 <esodan> I don't think I need to restart... I can continue at the point I am...
18:07:18 <warlord> Can you?
18:07:27 <warlord> Can you limit changes to lib/libqof/qof?
18:07:51 <warlord> ... and get the code working?
18:07:56 <esodan> If I question the actual code, and TALK with you, is becouse I want to be in the right way....
18:08:58 <warlord> I think we all understand what the "right" way is.. But the "right" way isn't necessarily what we want the "FIRST" way to be.
18:09:03 <esodan> Not in just qof, sorry, the mechanism in QOF to destroy objects and construct have problems with g_object_unref...
18:09:05 <warlord> This is GOING to be a multi-step process.
18:09:23 <jsled> esodan: yes, it does.
18:09:39 <warlord> Anyways, I need to go. jsled, hopefully you can take over from here..
18:09:42 *** warlord is now known as warlord-afk
18:09:44 <jsled> warlord-afk: cheers.
18:09:58 <esodan> then I'm changing the construction/destruction methods, but now with less modifications if they don't affect the correct way g_object_unref works...
18:10:00 <jsled> esodan: the first many milestones aren't going to be able to use ref-counting.
18:10:16 <jsled> why are you changing them at all?
18:11:06 <jsled> What's wrong with leaving xaccTransactionDestroy() calls in place?
18:11:16 <esodan> Becouse I need to be shure that the GObject parent is destroied correctly...
18:11:31 <jsled> no, no you don't. That'd be nice, but it's not necessary.
18:11:45 <esodan> Nothing, I have leave it as is for now... and most things will be...
18:13:46 *** exper has joined #gnucash
18:13:54 <esodan> I have modified the code shortly to use GObject, I just need to move some code from xaccFooInit() to the GObject _init() and xaccFree() to finalize...
18:14:59 <esodan> For example, leaven xaccTransDestroy as is, I have finished the Transaction object, and continue to the next object
18:15:12 <jsled> Why do you need to do that? Why do we need non-empty "GObject" _init and _finalize methods?
18:15:40 <jsled> I'd strongly recommend making the system compile before moving on to the next object.
18:19:47 <esodan> Ok, I review the code and see if this doesn't couse any problem... If you see the actual revision, the code to destroy the parent object is there, may be I can begin to make the system compile...
18:21:51 <jsled> esodan: instead of trying to get each type to be fully GObject-ized in sequence, it might be better to get each "feature" of gobject used across all the objects in turn...
18:22:12 <jsled> For instance, to start, the qof core is gobject ized. Milestone 1.
18:22:35 <jsled> Then, all the gnc engine types are gobject static intialized. milestone 2.
18:24:24 <jsled> Then, all the ... I don't know... all the g_new and g_free calls are changed to ref/unref. milestone 3.
18:26:21 <jsled> But if you try to get Transactions (for example) fully following all the gobject rules at once, it'll mean everything else does too. When the Transaction finalizer is called, in needs to unref Splits, which means the splits need to be ref-counted, which means their commodities do to, which means everything had to have been initialized in the first place.
18:26:24 <esodan> The current status is: QOF core is GObjet-ized, All the GC's object are GObject-ized, using the current QOF API...
18:27:23 <esodan> Becouse All GC's are QofInstance, now the qof_instance_release calls g_object_unref...
18:29:17 <esodan> I had stablished the basic structure of a GObject in each GC's objects, this is necesary becouse the Type system in QOF is completly diferent to GType, the each GC's object has a GType now, and the QofBook's collections can handle this types not the QOF's one...
18:29:48 <jsled> great!
18:38:24 *** vaix has joined #gnucash
19:00:33 *** franz has quit IRC
19:05:03 *** andi5 has joined #gnucash
19:05:03 *** gncbot sets mode: +o andi5
19:07:13 <andi5> jsled: i did not understand this off-by-one error ... looks like all backup files that are old enough and related to file A are removed correctly once you save A....
19:19:22 *** Esaj has quit IRC
19:24:22 *** MrN has quit IRC
19:24:27 <andi5> i have got the weird feeling that gnome packages switch from libgnomeprint{,ui} to gtkprint, because those will be declared as deprecated in gnome 2.18.... but they just add a dependency on gtk+-unix-print-2.0.... smells suboptimal / like_work to me
19:24:48 <andi5> yelp does the same...
19:27:18 <andi5> i remember having read about gnucash depending on stuff not (yet) available in major distributions... the same may be true soon, but this time because we depend on "too old" stuff... *grrr*... but maybe i am just too pessimistic
19:28:46 <andi5> [ot] what the heck is a "control centre"? is gnome british now?
19:29:31 *** jpeach has joined #gnucash
19:31:04 *** jpeach has left #gnucash
19:31:17 *** zerocool has joined #gnucash
19:31:29 <zerocool> hi
19:32:36 <zerocool> can somebody tell me if i can compile gnucash in windows? or do i have to make modifications?
19:32:58 <andi5> zerocool:
19:32:59 <andi5> http://wiki.gnucash.org/wiki/Windows
19:33:02 <andi5> oops
19:33:14 * zerocool is Back from (auto-away after 2hrs of inactivity) - (Gone: 1min 58secs)
19:33:32 <zerocool> ohh jeje sorry
19:34:20 <zerocool> i just looked in the mai page... didn't look in the wiki yet... and sorry if i bothered you...
19:34:33 <andi5> oh, do not mind
19:40:45 *** zerocool has quit IRC
19:41:35 *** twunder has joined #gnucash
20:00:09 <jsled> andi5: Hmm. IIRC I fixed a log deletion bug in the past, but don't recall any off-by-one (or "obi-wan", as I like to call them :) error... line number?
20:02:46 <jsled> andi5: you're saying there will be a rename and a new version dependency along with it? (re: print gnome libs?)
20:03:27 <andi5> that is no rename, gtk has a new print ui since... 2.10?
20:03:32 <andi5> ui = api
20:04:00 <jsled> ah. fun.
20:04:23 <jsled> Yeah ... I'd rather we had regular releases, so we could justify depending on updated libs.
20:04:48 <jsled> We're close to that point; it's too bad it seems like it's going to be about a year between 2.0 and 2.2...
20:04:53 <andi5> ahem, what line number shall i give you? ... my problem is that i cannot understand your problems with left-over backups :)
20:05:25 <andi5> maybe we should adapt the gnome release planning?
20:05:55 <jsled> Oh, heh. :) Well, I don't care too much. But it does seem that if you have a naturally ordered list of timestamped backups, the 0th indexed one is not deleted, even if it's too old as per the retain_days gconf key/policy.
20:06:40 <andi5> only with 2.0 or trunk too? i cannot see a difference in the code base here
20:06:54 <jsled> IIRC the gnome release policy is 6 month releases?
20:06:58 <andi5> yes
20:07:04 <jsled> We did want to have the 2.2 release a few months ago, but it just didn't materialize.
20:07:53 <jsled> Even with the good development momentum we've had in the past 1.5 years, it doesn't seem like we have enough for 6mo cycles.
20:07:58 <jsled> 1 yr cycles are pretty good, though.
20:09:16 <andi5> you are probably right... *missing hampton & chris a bit*
20:09:21 <jsled> Aye.
20:14:19 <andi5> jsled: i just tried on trunk: have empty, empty.20070201000000.xac and empty.20070201000000.log.... load that file, save it -> only 20070215021236.xac is left (retain_days == 5)
20:20:10 <jsled> I think you lie.
20:20:16 <andi5> huh?
20:20:27 <jsled> It's a cruel trick. You're trying to make me think I'm seeing things.
20:20:43 <jsled> Not funny, andi5. Not funny.
20:20:44 <andi5> and do you?
20:21:02 <jsled> andi4 and andi6 do not lie to me.
20:21:20 *** andi5 is now known as andi4
20:21:22 <andi4> sure?
20:21:27 <jsled> OH NOES!
20:21:33 <andi4> :-)
20:22:06 <jsled> I really do have to figure out how xchat colors nicks ... when you went from andi5 to andi4, your nick-color got just a shade darker.
20:22:12 <jsled> Quite appropriate, really.
20:23:04 <andi4> jsled: and then you use that algorithm in your logger script :)
20:24:00 <andi4> well, it is late... see you
20:24:05 <jsled> cheers.
20:24:23 * andi4 searches the gaim icon... ah, it is at the top, unlike ... well, i have found it
20:24:34 *** andi4 has quit IRC
20:25:02 *** esodan has quit IRC
20:31:58 *** Wilddev has joined #gnucash
20:31:58 *** gncbot sets mode: +o Wilddev
20:39:54 *** ErKa has quit IRC
20:48:31 *** Wilddev has quit IRC
21:25:38 <vaix> is there a way to import a CSV file instead of qif?
21:30:51 *** exper has quit IRC
21:34:01 *** exper has joined #gnucash
21:37:05 <dbr> vaix: aqbanking theoretically has a way to do that, but I don't know how to do it, and apparently there's some setup required
21:37:05 <gncbot> dbr: Sent 12 hours and 48 minutes ago: <jsled> adrigen said: <adrigen> though youll never hear it. Thnaks Dbr <adrigen> Ooh, luck he didnt hear that.
21:45:43 <vaix> I find something called CALC2QIF - Seems like a circuitious route, but it should work: http://xl2qif.chez-alice.fr/calc2qif_en.php
21:55:58 <dbr> that'll probably be faster for you now than trying to figure out aqbanking. If you search the irc logs for the last couple days, cstim and warlord were discussing the csv issue. cstim knows more than anyone about aqbanking's capabilities.
21:56:33 <dbr> at least anyone besides the primary author
21:57:26 <vaix> nice - thanks
22:00:50 *** twunder has quit IRC
22:06:54 <jsled> vaix: <http://wiki.gnucash.org/wiki/FAQ#Q:_How_do_I_convert_from_CSV.2C_TSV.2C_XLS_.28Excel.29.2C_or_SXC_.28.21OpenOffice.org_Calc.29_to_a_QIF.3F> has a procedure which might be feasible for you.
22:08:20 <jsled> Wow. I can see about 6 sq. inches of my car through the snow.
22:09:45 <vaix> jsled - i think that is where i got the link posted
22:10:12 <vaix> jsled - where are you? we got nasty snow also (usa: pa)
22:11:04 <dbr> jsled: yeah, I've never had to remove 6 inches of sleet before. 250 miles south makes it a little denser. At least it wasn't freezing rain.
22:13:39 <dbr> he's in vermont. I'm in allentown
22:14:09 *** egsavage has joined #gnucash
22:16:38 <egsavage> i noticed something strange in 'printing' a report in gnucash to a PDF
22:17:40 <egsavage> The preview looks fine. But when I open the actual PDF (created with PDFCreator), the text is backwards! Does this issue ring a bell with anyone?
22:18:02 <vaix> word - west chester
22:18:56 <egsavage> when I saw backwards text, I mean flipped
22:19:10 <egsavage> saw->say
22:20:08 <dbr> I've had problems with the default gnome printing settings. Have you looked at all the options before you hit Print?
22:21:02 <egsavage> I looked through most of them ... not sure what would flip the text but leave the graphics as you would expect
22:21:31 <dbr> I certainly wouldn't expect flipping only text and not graphics.
22:21:52 <egsavage> yeah, thats what strange... and the preview looks fine
22:23:54 <egsavage> other caveat - this is on windows
22:24:48 <dbr> ooh. I haven't even tried to print there yet.
22:25:15 <egsavage> maybe thats the issue then, the windows port
22:27:48 <egsavage> I tried another PDF printer (Cute PDF) and it produced the same thing - flipped text
22:27:49 <dbr> give me a couple minutes, I'll see if my windows copy is serviceable.
22:30:08 <egsavage> ok, thx
22:33:43 <dbr> I just printed an income statement (no graphics) to pdf on windows, then printed from adobe reader, and the text turned out fine.
22:35:34 <dbr> But now I'm jealous. On my mac, none of my installed printers makes it through to gnome print, so I have to print to the generic postscript device. Bummer. All my printers showed up in the print dialog box on the windows machine.
22:37:56 *** warlord-afk is now known as warlord
22:38:10 <warlord> vaix: FYI, the AqBanking CSV importer is only in gnucash trunk, not in 2.0.x
22:38:38 <egsavage> How about a bar chart or pie chart - something with graphics?
22:38:49 <egsavage> I'll try a text only printout to PDF and see what I get
22:39:33 <egsavage> everything is still flipped
22:39:38 <egsavage> hmm, very strange
22:41:33 <warlord> The gtkhtml + printing is pretty weird/broken.. And has beeen for a while.
22:41:44 <warlord> We really need some developer to step up and bring a better solution.
22:42:39 <egsavage> This time I didn't select PDFCreator and instead selected "Create a PDF document"... The text was not flipped with that option
22:43:05 <egsavage> I didn't see that selection my first go around in the print dialog
22:44:25 <egsavage> Must be something in that Win32 type printer selection
22:44:57 <warlord> Could be
22:45:00 <dbr> sounds like it. The "Create a PDF Document" is a gnome created option.
22:45:14 <egsavage> that one worked fine
22:45:30 <egsavage> including a report with graphics (as expected)
22:47:23 <dbr> another data point. I just printed to PrimoPDF (freebie) and got the flipped text
22:48:25 <dbr> I don't have the 'real' Adobe pdf printer driver on this machine. I'll test that sometime soon.
22:48:47 <egsavage> neither do I - that isn't freeware, is it?
22:49:06 <dbr> nope. way more expensive than it ought to be...
22:49:15 <egsavage> agreed there
22:49:27 <dbr> That's the reason it's not on my clunker laptop at home.
22:50:01 <egsavage> well, at least i have an option that works now to get a PDF that I can then print from Windows
22:52:19 <egsavage> I haven't explored the custom reports much... Is there a way to produce a graphical type of budget report like the income or expense ones that are available?
22:52:57 <warlord> nope
22:52:58 <dbr> I haven't done anything with budgets.
22:55:10 <warlord> me, either. i only recently started using sx
22:55:52 <egsavage> are budgets fairly new in gnucash?
22:55:59 <warlord> new in 2.0
22:56:09 <egsavage> ah, ok - I didn't know that
22:56:58 <warlord> now you do ;)
22:57:23 <egsavage> lots of great features to explore, thats for sure
22:59:30 <egsavage> well thanks for your help!
22:59:50 <warlord> you're welcome
23:24:20 *** prock_ has joined #gnucash
23:33:23 *** prock has quit IRC
23:39:20 *** rlaager has joined #gnucash
23:52:57 *** warlord is now known as warlord-afk