2014-01-24 GnuCash IRC logs

00:24:15 *** fell has quit IRC
00:28:18 *** fell has joined #gnucash
00:28:19 *** gncbot sets mode: +o fell
00:34:32 *** fell has quit IRC
00:59:45 *** ErKa has joined #gnucash
01:23:11 *** Neptune has quit IRC
02:00:34 *** gncbot has joined #gnucash
02:18:58 *** ErKa has quit IRC
02:47:46 *** linas__ has quit IRC
02:48:17 *** linas__ has joined #gnucash
02:50:24 *** Krzysiek_K1 has left #gnucash
03:40:04 *** jmd has joined #gnucash
03:56:31 *** jmd has quit IRC
04:09:21 *** jralls has quit IRC
05:12:23 <gjanssens> jralls, warlord: I was not home yesterday evening
05:12:35 <gjanssens> re swig and guile 2
05:13:41 <gjanssens> I think the new set of conditions to apply the patch is a good idea:
05:13:52 <gjanssens> - swig > 2.0.10
05:14:47 <gjanssens> - not windows (the patch tool in our windows build chain is too old, it works with a more recent one which I can't install without completely overhauling mingw/msys)
05:15:05 <gjanssens> - the patch hasn't been applied to swig itself yet
05:15:24 <gjanssens> If the patch is not applied, make dist should fail
05:15:42 <gjanssens> Now to the specific questions:
05:16:16 <gjanssens> The requirement is really swig > 2.0.10 (for guile 2 support)
05:16:51 <gjanssens> it's fairly recent but not brand new: swig 2.0.10 is 8 months old by now.
05:19:49 <gjanssens> I'd be interested to know how many developers we have that work on a platform that doesn't ship swig 2.0.10 yet
05:25:54 <gjanssens> warlord you're clearly one of those.
05:26:09 * gjanssens is looking at the package history of fedora 18
05:26:27 <gjanssens> Apparently swig 2.0.10 was never packaged for that distro version
05:28:45 <gjanssens> That's too bad, because fedora 18 was still fully supported when swig 2.0.10 came out which is still a minor release in most aspects
05:28:56 <gjanssens> Anyway that's how it is
05:30:23 <gjanssens> Next question: why didn't I deal with scm_from_utf8_string() in guile-mappings.h ?
05:31:00 <gjanssens> It's in there as well, but scm_to/from_locale/utf8_string is not the core of he issue
05:31:17 <gjanssens> That's just part of the patch to prevent lots of deprecation warnings
05:32:45 <gjanssens> The core issue is a guile to c string conversion function that's used internally in swig
05:33:44 <gjanssens> If the guile string has utf-8 characters this function will improperly determine the string length and return an invalid (utf-8 wise) string to c
05:34:02 <gjanssens> That is so for guile 2 and not for guile 1.8
05:34:14 <gjanssens> The internal string handling has changed between those two versions
05:34:36 <gjanssens> My patch replaces this swig-internal function with one that works for both versions
05:35:08 <gjanssens> The patch is really intended for swig itself, but I'll have to include some test cases before it's accepted upstream
05:35:32 <gjanssens> I discovered this issue pretty late (one of the last gnucash betas)
05:35:40 <gjanssens> The options I had were:
05:36:42 <gjanssens> - submitting a patch to swig, wait for the patch to get released in swig and then wait one more year before we could formally announce guile 2 support in Gnucash
05:37:09 <gjanssens> - hack gnucash to apply the patch now already on the swig generated files, and still keep the guile 2 feature for this release
05:37:59 <gjanssens> The first option would have meant that we could only announce guile 2 support for gnucash 2.8/3.0 which is still 2-3 years in the future
05:38:38 <gjanssens> That didn't seem like a good idea as most distros have already switched to guile 2 as default
05:41:39 *** gncbot has joined #gnucash
05:51:55 *** gjanssens sets mode: +o gncbot
05:53:31 <gjanssens> By the way I didn't see a way to deal with this function breakage from within guile-mappings.h
05:53:43 <gjanssens> The function is internal in the swig generated code
05:54:31 <gjanssens> jralls: regarding the added setlocale(LC_ALL, "")
05:54:43 <gjanssens> I was told to do so on the guile irc channel by the guile devs
05:55:46 <gjanssens> Without it guile uses C as the default locale, which resulted in utf-8 characters not being displayed properly with guile 2
05:56:15 <gjanssens> The guile devs explicitely stated that I was lucky it worked at all under guile 1.8 before
05:56:35 <gjanssens> So yes, we need it
05:57:49 <gjanssens> It would be interesting to know if guile 2 is equally fragile when it encounters an invalid locale
05:58:05 <gjanssens> If not we could indeed resort to only set it for guile 2
06:01:21 <mikee-afk> gjanssens: I am one of the developers without swig 2.0.10, Fedora18.
06:01:29 *** mikee-afk is now known as mikee
06:02:29 <mikee> I made a reversing patch so I could compile. It gets applied, then reversed in my custom build script.
06:03:31 <mikee> I'm not intending to upgrade Fedora any time soon, it causes far too many issues every time time I do.
06:06:13 *** jmd has joined #gnucash
06:07:44 *** Jimraehl1 has left #gnucash
06:10:30 *** mikee is now known as mikee-afk
06:13:01 *** jmd has quit IRC
06:13:24 <gjanssens> mikee: got it. I'm currently looking at warlords commit to see if this covers all cases
06:13:46 <gjanssens> you won't get guile 2 support on your fedora 18 box then obviously
06:19:04 <gjanssens> JFY I have upgraded one of my fedora boxes from f18 to f20 using fedup
06:19:50 <gjanssens> The only issue I encountered was that I had a separate /var partition
06:20:17 <gjanssens> So I had to make sure fedup used a cache and lib directory on my / partition instead
06:20:26 <gjanssens> That's a documented issue btw
06:20:55 <gjanssens> Other than that the update was smooth and the new system works very well
06:31:15 <gjanssens> warlord: to clarify
06:31:50 <gjanssens> In makefile.am I test for "define scm_from_utf8_string" to check if the patch is in swig already or not
06:32:35 <gjanssens> I just needed a random sequence of characters that for sure does not happen in swig generated files
06:32:40 <gjanssens> But that would be added by the patch
06:32:57 <gjanssens> I chose this one although it could have been another one
06:33:26 <gjanssens> That is not to say that the define scm_from_utf8_string is actually why the patch is applied
06:36:48 *** Jimraehl1 has joined #gnucash
06:43:39 *** aqua___ has quit IRC
07:10:58 *** mikee-afk is now known as mikee
07:11:35 <mikee> gjanssens: OK now with Warlords commit.
07:12:15 * mikee hates upgrading.
07:18:21 *** fell has joined #gnucash
07:18:21 *** gncbot sets mode: +o fell
07:48:50 <warlord> mikee: I'm with you on upgrading.. I upgrade my desktop every ~1.5 - 2 years.. So I'm "out of date" for 1/2-1 year
07:48:59 <warlord> gjanssens: thanks for the clarifications.
07:51:37 <gjanssens> warlord np
07:51:57 <gjanssens> It looks like your patch is doing the job
07:52:19 <gjanssens> It worked fine on my system with swig 2.0.10 and guile 1.8
07:52:29 <gjanssens> I'm currently rebuilding with guile 2
07:52:37 <gjanssens> No compile issues so far
07:52:48 <warlord> And with swig-2.0.10 and guile-1.8 you successfully were able to "make dist"?
07:53:13 <warlord> (with 2.0.8/1.8 "make dist" throws an error for me)
07:53:23 <warlord> ... which is what it is supposed to do
07:56:58 *** aqua___ has joined #gnucash
07:57:01 <warlord> mikee, this means you wont need to reverse the patch anymore ;)
07:57:34 <mikee> warlord: Awsome, thanks.
07:57:59 <warlord> i.e., trunk built for me on F18 cleanly
07:58:07 <mikee> Just found a bug in invoice page. Fixing now.
07:58:59 <mikee> Noticed guile issue while fixing bug
08:03:12 * gjanssens is restarting the build with guile 1.8 to run make distcheck
08:14:36 *** aqua___ has quit IRC
08:35:48 <gjanssens> distcheck runs fine for swig 2.0.10/guile 1.8 combo
08:39:07 <gjanssens> Actually sunglare on my screen made me misread
08:39:27 <gjanssens> warlord make distcheck fails:
08:39:30 <gjanssens> make dist-bzip2 dist-gzip am__post_remove_distdir='@:'
08:39:32 <gjanssens> make[2]: Entering directory `/kobaltnet/janssege/Development/Builds/gnucash-f19-trunk/gnucash-2.6.0/_build'
08:39:33 <gjanssens> You cannot build the dist with your version of swig
08:39:35 <gjanssens> make[2]: *** [swig-dist-fail] Error 1
08:39:36 <gjanssens> make[2]: Leaving directory `/kobaltnet/janssege/Development/Builds/gnucash-f19-trunk/gnucash-2.6.0/_build'
08:39:38 <gjanssens> make[1]: *** [dist] Error 2
08:39:39 <gjanssens> make[1]: Leaving directory `/kobaltnet/janssege/Development/Builds/gnucash-f19-trunk/gnucash-2.6.0/_build'
08:39:41 <gjanssens> make: *** [distcheck] Error 1
08:43:24 <gjanssens> But I do have swig 2.0.10
08:44:46 <gjanssens> Is make dist-bzip2 called from the make run on the dist tarball or from svn/git ?
08:44:50 *** noughth has quit IRC
08:44:53 *** noughth has joined #gnucash
08:44:56 <gjanssens> It looks like the former to me
08:45:53 <warlord> Oh. Hmm... I don't know.
08:46:47 <warlord> If it's called from inside the dist tarball then there's a problem... I have to move the test.
08:47:55 <warlord> (or find a different way to hook into 'dist' besides hooking into EXTRA_DIST)
08:48:50 <warlord> alas, there is no 'dist-hook'
08:48:54 <gjanssens> I don't know either :(
08:49:27 <gjanssens> I don't immediately find where the make dist-bizp2 dist-gzip rule is specified
08:50:03 <warlord> It's auto-generated by automake into the top-level Makefile.in
08:51:22 <gjanssens> Found it, and also this (as explanation with distcheck):
08:51:25 <gjanssens> # This target untars the dist file and tries a VPATH configuration. Then
08:51:27 <gjanssens> # it guarantees that the distribution is self-contained by making another
08:51:28 <gjanssens> # tarfile.
08:51:50 <gjanssens> So it seems the tarball is effectively generated in the make call in the dist directory
08:53:46 <warlord> okay.. so the test needs to be outside the 'building from svn'.. Basically move the first AX_PKG_SWIG outside the BUILDING_FROM_SCM test.
08:56:36 <gjanssens> Hmm, wouldn't that mean that users would need to have swig installed even when building from a tarball ?
09:00:04 <warlord> Nope
09:00:13 <warlord> Only if they wanted to "make dist" from the tarball
09:00:26 <warlord> (the test doesn't error out if SWIG isn't found)
09:04:07 <warlord> at least, it doesn't error out the way I've written it ;)
09:13:55 <gjanssens> Indeed.
09:14:06 <gjanssens> But it's becoming quite an ugly hack
09:14:34 <gjanssens> If a user wants to run distcheck on the release tarball, he needs swig installed, but it's not used
09:14:36 <warlord> True...
09:14:58 <warlord> But why would someone want to run "distcheck" on a release tarball instead of just "check"?
09:15:19 <gjanssens> Beats me, I'm just evaluating possible scenarios
09:15:49 <warlord> The other option would be to move the existing AM_CONDITIONAL inside the if BUILDING_FROM_SVN and then add an 'else' condition where the AM_CONDITIONAL is always true.
09:16:10 <warlord> So "make dist" from the tarball will always work.
09:16:26 <gjanssens> I like the logic of that more
09:16:40 <gjanssens> At least it stays clear we only need swig to build from svn
09:17:19 <warlord> Okay..
09:17:24 <warlord> Can you do it? I need to run.
09:23:18 <gjanssens> Ok
09:24:40 <fell> DimStar: https://bugzilla.gnome.org/show_bug.cgi?id=721822#c13
09:27:18 *** ambimorph has joined #gnucash
09:27:44 *** lawsa has joined #gnucash
09:37:39 <gjanssens> jralls: regarding the lilipond/gnucash interaction over guile
09:37:49 <gjanssens> is that on linux as well ? or only on Windows ?
10:01:46 *** jralls has joined #gnucash
10:01:46 *** gncbot sets mode: +o jralls
10:14:23 <fell> gjanssens: Isn't Jqplot java based?
10:16:33 <gjanssens> fell: no jqplot is javascript based
10:16:51 <gjanssens> Although both include the term "Java" there's a world of difference between those
10:17:08 <gjanssens> javascript is a scripting language
10:17:10 <fell> Yep
10:17:15 <gjanssens> java is a compiled language
10:22:20 *** ErKa has joined #gnucash
10:25:04 <lawsa> gjanssens: pardon, lilipond ? Music writing software ?
10:26:03 *** fell_ has joined #gnucash
10:26:04 *** gncbot sets mode: +o fell_
10:30:15 *** fell has quit IRC
10:33:59 <gjanssens> Iawsa: interference is probably a better term
10:34:30 <gjanssens> On Windows, when lilipond and gnucash are both installed, gnucash erroneously uses the guile libraries that ship with lilipond
10:34:42 <gjanssens> That is due to the way lilipond gets installed on Windows
10:35:15 <gjanssens> jralls seems to suggest this issue also exists on linux which triggered my question
10:36:26 <lawsa> ahh, gotcha
11:05:08 *** benoitg has joined #gnucash
11:08:39 <warlord> gjanssens: I'm back.
11:13:41 <DimStar> fell_: gnucash uses webkit.. and webkit is stupid: it loads all plugins that are available...
11:15:52 *** fell_ is now known as fell
11:16:23 <fell> DimStar, thanks for the explaination.
11:23:46 <warlord> why is that "stupid"?
11:24:18 <gjanssens> warlord: just committed the fix for make distcheck
11:25:10 *** Yawar has joined #gnucash
11:25:16 <gjanssens> warlord DimStar's reply was about bug 721822 mentioned above
11:25:31 <fell> warlord: load on demand would be smarter.
11:25:46 <gjanssens> on fell_'s system webkit loads java at gnucash startup
11:26:04 <gjanssens> (fell_ is fell again...)
11:26:20 <warlord> Oh. Weird.
11:26:31 <warlord> Yeah, load-on-demand would be smarter.
11:26:51 <warlord> (but it does give a bit less of a good user experience because there are delays when accessing a page)
11:27:07 <warlord> So you either get the delay at startup or a delay on page-display.
11:29:09 <fell> In our case we have no java modules, but the first report rendered by webkit loads a javaVM
11:31:23 <warlord> WEIRD
11:33:09 <warlord> Hey Yawar
11:33:31 *** ErKa has quit IRC
11:33:48 <Yawar> warlord: hi. i'm doing a little scheme report hacking :-)
11:35:05 <warlord> I noticed :)
11:38:48 <Yawar> warlord: looking at the conversations in -devel recently, it seems like ppl are planning to change a lot of internals? also APIs?
11:43:30 <warlord> It certainly sounds like there are some plans for major overhauls over the next few years.
11:47:07 *** petaspeedbeaver has joined #gnucash
11:47:14 <Yawar> warlord: i've been playing with this idea that i can build a declarative style API on top of the current scheme reports functions. so trying to make something like a markup DSL for reports.
11:50:56 <Yawar> warlord: so it seems like ppl are moving away from implementing stuff in gnucash in scheme and rather moving towards c/c++. i think the last major scheme functionality was the business features that you added?
11:51:28 <warlord> Yawar: I think a more interesting solution would be something that could generate XML, and then we could translate that XML into HTML and make it pretty.. The latter half would be easier for novices to template, etc.
11:51:45 <warlord> Nope, the biz features were all C
11:51:51 <warlord> only the biz reports were Scheme.
11:52:07 <warlord> The last major feature to be implemented in Scheme was the QIF importer, and that was done, oh, 10+ years ago
11:52:25 <warlord> (not counting "new reports" -- I dont consider those "new features")
11:52:44 <Yawar> warlord: ah ... yes, of course :-)
11:53:17 <Yawar> warlord: although, don't they say that xml is just a bastardised form of lisp? :-)
11:53:42 <warlord> XML isn't a langauge, per se.
11:53:57 <warlord> It's a Markup Language, closer to HTTP than Scheme/Lisp
11:54:07 <warlord> it's not a programming language
11:54:56 <Yawar> warlord: well, a lot of ppl would say that lisp is a meta-language for creating prog langs. so there's some similarity....
11:55:44 <warlord> Nah, XML isn't a programming langauge, it's a markup langauge. Very different.
11:55:58 <warlord> XML is more like LaTeX than PERL
11:56:10 <warlord> (or even postscript)
11:56:19 <warlord> XML doesn't have "procedures" or "functions"
11:57:16 <Yawar> warlord: well, it's probably moot but, let me illustrate my point:
11:57:39 <Yawar> warlord: <report name="My Report">...</report>
11:58:05 <Yawar> warlord: (report 'name "My Report" ...)
11:59:40 *** petaspeedbeaver has quit IRC
12:00:12 <warlord> So you're saying that "gee, if I convert from parens to gt/lt symbols they look the same"?
12:03:10 <Yawar> warlord: exactly. in fact lispers have been saying this ever since sgml: http://blogs.oreilly.com/digitalmedia/2004/12/lisp-is-better-than-xml-but-wo.html
12:03:34 <warlord> Perhaps.. but That's not what *I* am talking about
12:04:06 <warlord> I'm talking about concepts. XML conceptually is a tree.
12:04:21 <warlord> Scheme/LISP, conceptually, is a set of named lists.
12:04:30 <warlord> Not really the same
12:04:48 <warlord> Sure, you can model each in the other
12:04:55 <Yawar> warlord: a lisp program is a representation of an AST. so: a tree :-)
12:07:37 *** jmd has joined #gnucash
12:08:55 <Yawar> warlord: in any case i think a tech-savvy user, given a set of simple declarative scheme functions, can put them together almost like a markup language and come up with a report.
12:09:17 <warlord> Ah, but here you've hit the rub: "tech-savvy user"
12:09:26 <warlord> We need to deal with the NON tech-savvy users..
12:09:38 <warlord> They are the ones that want to "make it look pretty" easily
12:11:58 <Yawar> warlord: ah, that's another beast. the first thing that's obvious is that generated reports should be styled with css. then, providing an easy way to 'make it look pretty' means providing some ui to manipulate the stylesheet
12:12:57 <Yawar> warlord: what i'm focusing on right now is a set of declarative, composeable (to a certain extent) scm functions for building reports
12:13:26 <gjanssens> I think we'd come a long way already if we manage to make our reports use a consistent html structure
12:13:34 <warlord> That was my original point: if the report "engine" generates XML then there could be a simple translation to HTML + CSS where they can choose which parts to actually display. It means you don't have to regenerate the report when you e.g. hide/unhide a column..
12:14:05 <gjanssens> Use proper html id's/attributes and uses them consistently
12:14:18 <gjanssens> most of our reports date from a time where we couldn't use css
12:14:26 <warlord> True, that would be a big step forward.
12:14:27 <warlord> BIAB
12:14:53 <gjanssens> with a consistent html structure it becomes much easier to write css that works for all reports
12:15:06 <gjanssens> and we can start distributing real (css) stylesheets
12:15:21 <gjanssens> and even invite webdesigners to contribute some
12:15:31 <gjanssens> that's something you can find people for
12:15:47 <gjanssens> writing someting in scheme much less so
12:16:01 <Yawar> gjanssens: aren't the scm html generator functions generating standard html?
12:16:32 * gjanssens sometimes wonders if we can't eliminate guile completely if we wrap our api for javascript access
12:16:47 <gjanssens> Yawar: they are
12:17:20 <gjanssens> But there's no consistent structure across reports
12:17:27 <Yawar> gjanssens: so, what's stopping us from writing css now?
12:17:40 <gjanssens> The e-guile reports were a first step in the good direction, but was never picked up
12:17:51 <Yawar> gjanssens: i mean, for reports that use the scm gnucash html functions
12:18:15 <gjanssens> Yawar: that no reports set id's or classes which you need for decent css coding
12:18:28 <gjanssens> s/coding/styling
12:19:10 <gjanssens> And that each report uses a different structure
12:19:16 *** ErKa has joined #gnucash
12:19:23 <gjanssens> Some use a table, others use div's
12:19:34 <gjanssens> Things like that
12:19:38 <Yawar> gjanssens: ah ... i wonder if the html gen functions let us specify ids/classes. i'll look into that.
12:20:33 <Yawar> gjanssens: so, the thing is, if i use the same set of declarative scheme functions to write all my reports, then all my reports will have the same general structure, classes etc.
12:21:00 <Yawar> gjanssens: and suddenly _every_ new report being written would automatically be styleable
12:22:07 <Yawar> gjanssens: where by 'declarative scheme functions' i mean the thing i'm trying to work on right now ... see github.com/yawaramin/gc-decl-reports.scm if you want more details....
12:22:36 <Yawar> gjanssens: oops, that s/b github.com/yawaramin/gc-decl-reports
12:23:06 <gjanssens> Yawar: have you looked at the e-guile reports ?
12:23:20 <gjanssens> Aren't they doing something similar already ?
12:23:34 <gjanssens> Just to avoid you'd reinvent the same wheel...
12:24:26 <Yawar> gjanssens: admittedly, no :-) but my understanding is that they're supposed to be html templates with guile code insertable throughout. to me that violates the separation of content and design
12:25:15 <Yawar> gjanssens: i'm trying to come up with something at a higher level so that you never actually need to deal with html
12:26:05 <gjanssens> Yawar: there's very little "code" in the html templates
12:26:19 <gjanssens> Most of the code is in a separate file
12:26:29 <gjanssens> The templates are really templates
12:26:42 <gjanssens> But indeed, you still need to deal with html
12:29:53 <Yawar> gjanssens: looking at balsheet-eg.eguile.scm, there seems to be a _lot_ of embedded scm code
12:30:33 <Yawar> again, it breaks the separation of content and format
12:31:22 <gjanssens> What you call embedded code, I would interpret as 'data insertion'
12:31:29 <gjanssens> That's how a template system works
12:32:10 *** TradeBorG113 has joined #gnucash
12:32:12 <gjanssens> I'd be interested to see how you can do that differently in a declarative language
12:33:33 <Yawar> granted, though i am trying to avoid mixing the template (form) and the 'data insertion'. the best example i can think of right now is R's basic plotting commands as opposed to the higher-level 'ggplot2' graphing library which provides building blocks for graphs and charts
12:33:49 <Yawar> ... not sure if you've come across R, so not the ideal example
12:35:01 <Yawar> i'd be interested to see what i can come up with myself :-) still trying to wrap my head around the scm functions....
12:36:23 *** Krzysiek_K has joined #gnucash
12:36:50 *** ambimorph has quit IRC
12:36:56 <gjanssens> Heh, don't tell me
12:37:15 <gjanssens> I got lost more than once in the html and stylesheet code of gnucash
12:37:41 <gjanssens> And even today I still don't get it
12:38:01 <Yawar> yikes
12:39:51 <gjanssens> To be completely honest: I wouldn't mind if it got rewritten one day in C/C++
12:40:05 <gjanssens> But that's not happening anytime soon yet...
12:41:23 <Yawar> i have to admit i like the idea of gnucash being architected as scm code on top of a solid c base. potentially makes it very customiseable
12:42:42 <warlord> Yawar: except the # of scheme devs out there to do said customization is VERY small, and shrinking
12:43:11 <gjanssens> and add to that there is no clean api for guile to build upon
12:43:20 <gjanssens> It's currently all spaghetti
12:43:34 <warlord> keep in mind that back in gnucash-1.6 days, it *WAS* a scheme app!
12:43:44 <warlord> "gnucash" was a scheme program
12:43:46 <gjanssens> where sometimes guile is reponsible for a piece of data and sometimes the c code is
12:43:51 <Yawar> warlord: unfortunately lispers/schemers are not plentiful. but i think lisp/scheme is going to enjoy a resurgence. look at clojure, racket e.g.
12:43:53 * gjanssens is well aware of this
12:44:08 <warlord> gjanssens: I was informing Yawar
12:44:17 <gjanssens> That gnucash was a guile program that is
12:44:21 <warlord> I know YOU were well aware.. IIRC you did a lot of the work to fix that
12:44:31 <gjanssens> :)
12:44:39 <gjanssens> I'm still doing that
12:44:42 <warlord> LOL
12:44:53 <Yawar> hah :-0
12:45:14 <warlord> Making the GnuCash API visible through Javascipt sounds interesting, although I think it's important to be able to "save" an HTML output.
12:45:39 <gjanssens> Agreed
12:46:28 <gjanssens> It's only a half-baked idea that woud need a lot more thought before being anything useful
12:46:46 <Yawar> has anyone ever made noise about making report reloading easier, e.g. not having to restart gnucash every time?
12:47:22 <warlord> Yawar: yes, and there has, at times, been code to "reload report" under a Debug Menu option. unfortuntely it doesn't work well consistently.
12:47:57 <Yawar> warlord: thanks. i'll take a look at the git commits, see if i can find something
12:49:41 <warlord> Yawar: you'll probably need to go back ~10 years...
12:49:57 <warlord> I know I had sometihng in there when I was originally working on the biz features..
12:50:07 <warlord> (but that was all 200x, for x < 5)
12:51:00 <Yawar> easy enough to search through the commit messages ... if they're topical ;-)
12:55:51 <warlord> "if"
13:06:02 *** ambimorph has joined #gnucash
13:15:41 *** benoitg has quit IRC
13:44:16 *** bpburns has joined #gnucash
13:48:10 <fell> gjannsens, you are to fast in answering on bugzilla. ;-) But now I am ready. At least I think so.
13:49:03 <warlord> :)
13:53:13 <warlord> BIAB...
13:53:20 *** warlord has quit IRC
14:00:42 <gjanssens> fell: :)
14:08:58 *** aqua___ has joined #gnucash
14:13:29 *** warlord has joined #gnucash
14:13:29 *** gncbot sets mode: +o warlord
14:29:28 <Yawar> warlord, gjanssens: so just to give everyone an idea of what i'm talking about: if you run your Income Statement report, the output you see is what i'm trying to capture right now in a general, declarative model
14:29:33 <Yawar> so far i have this:
14:29:49 <Yawar> (d:table
14:29:50 <Yawar> (d:periods
14:29:52 <Yawar> '(("General" "Start date" "General" "End date"))
14:29:53 <Yawar> (d:subtotal "Net income for period"
14:29:55 <Yawar> (d:subtotal "Total Revenue"
14:29:56 <Yawar> (d:account-group "Account Groups" "Revenues"))
14:29:58 <Yawar> (d:subtotal "Total Expenses"
14:29:59 <Yawar> (d:account-group "Account Groups" "Expenses")))))
14:31:31 <Yawar> where the periods and account groups have been defined earlier in the file
14:33:35 *** ambimorph has quit IRC
14:34:52 *** ambimorph has joined #gnucash
14:37:14 *** ambimorph1 has joined #gnucash
14:37:21 <warlord> Yawar: you should really look at eguile.. it's pretty much doing this already.
14:37:27 <gjanssens> Yawar: it's probably me but I can't help to find this very similar to the templating approach
14:37:35 *** ambimorph has quit IRC
14:37:43 <warlord> gjanssens: nope, not just you
14:38:15 *** ambimorph has joined #gnucash
14:38:23 <gjanssens> Except that with your approach I have to learn a new "declarative" language in addition to the guile functions to extract the data from the engine
14:38:55 <gjanssens> With the eguile templating system, at least we have a structuring language that many people understand: html
14:42:49 *** ambimorph1 has quit IRC
14:46:33 <warlord> Yawar: I agree with gjanssens that I think you're going down the wrong path. Let's take a step back and talk about what the reporting requirements are.
14:47:08 <warlord> I think that the #1 requirement is that users want to make reports look-and-feel how they want. This is the job of CSS -- so we need to be more consistent with generation to make CSS work well
14:47:19 <warlord> #2, users need to define what's actually displayed in reports
14:47:40 <warlord> #3, users often want to see multiple periods in multiple columns for the same report
14:48:15 <warlord> #4 *MAY* be users writing new reports, but I may have that higher than reality
14:49:41 <Yawar> warlord: i am targetting the last three points _directly._ the first will happen indirectly because if everyone is using a common declarative language to define reports, then this language can make sure all reports have a common html structure, classes, ids, etc. which makes applying css very easy
14:51:28 <Yawar> gjanssens: doesn't an eguile report developer have to do _all_ the calculations of getting data out of the engine, _in addition to_ writing the html and css templates?
14:52:30 <warlord> Yawar: EVERY report writer will have to do the calculations, unless said calculations have already been written somewhere.
14:52:55 <warlord> ... the issue is that said calculations HAVE NOT been written somewhere... or rather, each report has unique calculation requirements..
14:53:04 <warlord> That wont change even in your "declarative language"
14:53:22 <Yawar> warlord: that's what i'm trying to do: reduce the possible set of calculations to some common building blocks
14:53:40 <warlord> then refactor the existing reports and create a scheme library.
14:53:44 <Yawar> e.g., get account balance for a period. get budget for a period. get invoices for a period
14:54:31 <Yawar> warlord: _exactly_ what i'm trying to do :-)
14:55:26 <Yawar> the best-case scenario is to have something simple and powerful enough that we can redefine all the existing reports in terms of it...
14:56:50 <Yawar> ... and if that happens, suddenly all the output html will have the exact same structures and classes (and probably ids)
14:56:57 <warlord> Yawar: then don't define a new language.
14:57:02 <warlord> Take the existing reports and refactor them
14:57:21 <warlord> there was already an attempt to do that once (e.g. some of the generic 'table' APIs) ... but not all reports migrated over.
14:57:33 <warlord> There is no point in coming up with a completely new API.
14:57:54 <warlord> Just extend the existing ones, one API at a time, and migrate those single-API-changes through all the reports.
14:58:07 <Yawar> well, when we say 'language', we might be talking about different things. i really mean an API simple enough and declarative enough that it can be reasoned about as a markup language
14:58:10 <warlord> Of course, the fact that we don't have a test harness to actually TEST the output of reports makes that much more challenging.
14:58:30 <warlord> Yeah, you're never going to get there, so don't waste your time trying.
14:58:35 <warlord> Reports cannot be declarative.
14:58:41 <warlord> TEMPLATES can be declarative
14:58:46 <warlord> C.f. eguile
14:58:50 <gjanssens> That's how I see it as well
14:59:00 <warlord> But the reports themselves require computation, and computation cannot be declarative.
14:59:23 <Yawar> well, this is just a fun thing for me to hack on. so i think i'll keep going as long as i can....
14:59:47 <gjanssens> That of course is your free choice :)
15:00:13 <Yawar> ... or at least until someone completely gets rid of all guile from gnucash :-)
15:00:37 <gjanssens> That will probably never happen...
15:01:19 <gjanssens> But I have it as a long term goal to make the guile-bindings an optional feature, just like python is
15:01:34 <gjanssens> As long as there's core functionality in there, that is not possible of course
15:01:48 <Yawar> btw, computation _can_ be declarative: SQL
15:02:29 <warlord> SQL cannot give you a Balance Sheet
15:03:45 <warlord> (or if it can, I wouldn't want to think about how hard it would be to encode the query to do so -- would be much easier to write in a real programming language)
15:04:22 <Yawar> the reason SQL can't give me a balance sheet is that it's a general-purpose declarative language. it's not _specialised_ for accounting concepts
15:05:24 <Yawar> in fact, it's surprisingly easy to get a balance sheet with SQL if you don't mind getting the results back as a flat table
15:07:07 <warlord> Like I said before, I think you'd be better served taking the existing reports, finding commonality, and refactoring. You'll get more traction that just coming up with (yet another!) way to build a report.
15:08:02 <Yawar> let's see.
15:09:05 <warlord> Trust me.. e-guile didn't take off, and it makes it MUCH easier to format reports as desired.
15:10:51 <Yawar> warlord: to me that says we need something _even_ simpler than eguile
15:11:34 <warlord> Maybe.. maybe not...
15:13:11 <Yawar> maybe another reason the scheme side of things isn't taking off is that ppl are working on their own scheme projects separately, unaware of others ... i can probably count on one hand the number of times someone has said anything serious about scheme report dev on the -devel list
15:13:59 <Yawar> there are about four or five scheme report git repos on github, and a smattering of websites where ppl put up some (outdated) gnucash/scheme knowledge
15:14:00 <warlord> Part of the issue is that scheme is effectively dead. There are very few schemers around.
15:14:27 <warlord> If I were to do it from scratch today I'd go with Ruby or Python (I'd choose Ruby personally because I like it better, and we could base it more on Rails-like templates)
15:15:12 <Yawar> and maybe i'd start with clojure :-) anyway take a look at http://www.reddit.com/r/scheme/ or http://www.reddit.com/r/racket/
15:15:20 <Yawar> there are definitely a lot of schemers out there
15:15:28 <Yawar> we're just not reaching them
15:15:47 <warlord> If they aren't part of this community then they are irrelevant.
15:16:02 <warlord> If you can bring them into this community, only then do they become relevant
15:16:18 <Yawar> no--if they aren't part of this community, we can reach out to them to try to bring them in
15:16:56 <Yawar> actually it's the other way around now: _they_ are part of the community, _we_ (gnucash/guile) are irrelevant
15:17:24 <Yawar> b/c we haven't made any progress with the scheme/guile that we have
15:17:26 <warlord> Either of which means we shouldn't encourage more scheme use
15:17:38 <Yawar> progress will encourage interest
15:17:40 <warlord> and should change to something that makes more sense for the community we have
15:17:45 <warlord> Unlikely.
15:18:07 <warlord> There have been multiple step of progress over the past decade, none of which has spurred significant increased interest
15:18:36 <warlord> Generally we've had one person at a time step up and try to make signifcant progress, only to eventually burn out.
15:18:58 <warlord> and most of the core devs don't really hack scheme.
15:19:33 <warlord> so why not use something that the core devs DO know?
15:20:05 <Yawar> it comes back to what i was saying before: there's been no common area for gnucash schemers to aggregate their work. there's no scheme community within gnucash
15:20:55 <Yawar> because most of the 'extensible' parts of gnucash--the reporting stuff--is in scheme. and if we attract ppl to contribute to it, it takes the burden off the core devs
15:21:06 <warlord> Sure there is: the source cofde
15:21:07 <Yawar> who can then go back to wrangling w/ data structures in c/c++
15:21:32 <warlord> Anytime someone writes a new report (which happens... rarely)... we include it
15:21:41 <warlord> GnuCash itself *IS* the shared repository
15:22:00 <warlord> We haven't HAD many contributors.
15:22:14 <warlord> Perhaps it's a chicken-and-egg problem, but I don't think the issue is the lack of a "contrib repository"
15:22:38 <Yawar> as i said: lack of a schemers contrib _community_
15:23:15 <Yawar> i mean a common area, like a watering hole
15:23:32 <warlord> Like 127.0.0.1?
15:24:11 <warlord> (I'm not sure what kind of "watering hole" you could create on the Internet)
15:24:26 <Yawar> like a mailing list ... or a google group ... or g+ community ... or subreddit ... or all of them
15:25:02 <Yawar> somewhere ppl can come and show off a bit
15:25:07 <warlord> like, oh, gnucash-devel? gnucash-user?
15:25:34 <Yawar> yes, except _focused_ on contrib stuff like scheme reports
15:26:02 <warlord> So you mean let's fracture the community?
15:26:20 *** gjanssens is now known as gjanssens_
15:27:14 <Yawar> we already have 'fracturing' in the form of separate lists for users and devs, and for core :-)
15:28:06 <Yawar> that kind of fracturing is not actually fracturing, it's distributing out the burden of maintaining the community over different 'subsystems' if you will
15:29:01 <Yawar> oh, and not to mention the gnucash google+ community
15:29:18 <Yawar> the point is they're all under the gnucash umbrella
15:30:42 <warlord> Do people use the g+ community?
15:30:44 * warlord doesn't
15:31:41 <warlord> as for -devel v -user... there is a large crossover, but the questions themselves generally fall into specific categories.. I don't see how a gnucash-schemers list would fall out of the -devel list..
15:31:53 <Yawar> i know you're not on google+, but the community has 891 members there
15:31:59 <warlord> Perhaps it can start in -devel and, if it turns into a large subcommity, then split it out.
15:32:13 <warlord> I actually am on G+ (I have 2 different G+ accounts, which I never use)
15:32:17 <warlord> I used it when it was... early
15:32:25 <warlord> then gave up when it was effectively duplicating FB
15:32:46 <Yawar> i personally am not (active) on facebook, but i do know there's a gnucash group there as well probably with another boatload of members
15:33:40 <warlord> However I don't think a "build it and they will come" methodolgy makes sense. Making the mailing list is easy, getting people to subscribe is hard.. So lets do the work to get people to subscribe, but use -devel. If it turns out we really have a large commiunity then we can easily create a new list.
15:33:54 *** Sam__ has joined #gnucash
15:33:57 * warlord doesn't follow either group, honestly.
15:34:22 <Yawar> the facebook group is pretty activ
15:34:39 <Yawar> i can ask around to see if anyone is interested in a -schemers or -contrib subcommunity...
15:34:46 <warlord> Sure.
15:35:04 <warlord> Or if they would be willing to be subsumed into the -devel community
15:35:30 <Yawar> which is the case now.
15:36:38 <warlord> Well, if it's true that your claim is that we haven't reached out.... go ahead and reach out.
15:37:04 <warlord> I still dont think that the reason we don't have a large schemer community is that we don't have a 'schemers' list.
15:37:54 <Yawar> actually you're right in the sense that it's not the _only_ reason
15:38:28 <Yawar> developing gnucash reports is _hard_ not just b/c of the language/api, but also because the development cycle is punishingly difficult
15:40:39 <Yawar> that's why i want to look into fast reloading of reports, easier custom report management, etc.
15:41:41 <warlord> I agree, developing reports is hard.
15:42:17 <warlord> We dont have good APIs or tools to make it easier... which is why both gjanssens_ and I were suggesting you work on those APIs. There was some effort towards that, but it wasn't applied to *all* the reports.
15:42:37 <warlord> Someone will need to make a concerted effort to port *all* reports to the "newer, better" APIs, as they get created.
15:43:06 <warlord> But I still think that you're doing it wrong trying to design the API first; it will necessarily have to grow organically as you add more reports that use it.
15:44:26 <Yawar> actually, i think i haven't explained what i'm trying to do properly. i'm starting by looking at the _actual_ reports that are distributed w/ gnucash and trying to organically develop a declarative model that can cover all of them
15:44:46 <Yawar> then it's a matter of processing the declarative model and turning it into html output
15:45:15 <Yawar> i'm doing this one report at a time, so am starting with the Income Statement
15:46:35 *** Sam___ has joined #gnucash
15:52:32 *** Sam__ has quit IRC
15:56:52 *** Sam___ has quit IRC
15:57:02 *** benoitg has joined #gnucash
15:57:43 *** aqua___ has quit IRC
16:06:35 *** aqua___ has joined #gnucash
16:18:58 *** Sam__ has joined #gnucash
16:23:27 *** Sam___ has joined #gnucash
16:29:00 *** Sam__ has quit IRC
16:33:58 *** Sam___ has quit IRC
16:50:39 *** todd has quit IRC
16:50:42 *** todd has joined #gnucash
17:20:14 *** TradeBorG113 has quit IRC
17:21:35 *** gjanssens_ has quit IRC
17:28:58 *** lawsa has quit IRC
17:39:21 *** Yawar has quit IRC
17:53:53 *** haclong has joined #gnucash
18:08:38 *** noughth_ has joined #gnucash
18:12:34 *** noughth has quit IRC
18:22:49 *** kpreid has quit IRC
18:23:26 *** kpreid has joined #gnucash
18:42:12 *** Yawar has joined #gnucash
18:55:12 <fell> http://wiki.gnucash.org/wiki/Git#Committers_.28for_svn-backed_repositories.29
18:55:38 <fell> I don't understand: Edit it so that the path to the git library directory (5th line) is correct for your installation or set $GITPERLLIB in your environment to point to the location of Git.pm.
18:58:05 <fell> jralls, can you explain it?
18:58:15 <jralls> It means that the script needs to find Git.pm and that there are two ways for it to do so.
18:58:33 <fell> Ok, thx
18:58:41 <jralls> There's actually a third, to add the path to $PERL5LIB.
18:59:51 <jralls> But that whole section goes away when we do the new "code" comes up. No more SVN, no more git-update, no more git svn dcommit.
19:00:15 <jralls> Just git push, like St. Linus intended.
19:00:55 <fell> But I have now a bunch of commits laying around.
19:01:19 <jralls> Oh, OK. Fire away, then.
19:02:10 <fell> (I try to update wiki:Eclipse for git while I configre mine)
19:02:45 <jralls> If you do, leave out the bits about SVN.
19:03:41 <fell> It starts with: # Only for commiters of gnucash and gnucash-docs until 2014-02-01:
19:04:41 <jralls> It seems silly to work on writing about that so late.
19:55:53 <warlord> I dont think we're going to get any new devs between now and Feb 1st
19:56:32 <warlord> So I would just focus on the Git side, if you're upgrading docs.
20:17:07 <fell> It's not silly, its yoga. According Murphy's law I have to use another machine next week and then I have to try out everything again? No, I will write it down - additional I can memorize things better after I wrote them down.
20:18:41 <fell> Before I go shopping I make note, which I usually forget on the kitchen table, but then I know what I had to buy. :-P
20:32:57 <warlord> LOL
20:38:08 *** benoitg has quit IRC
21:23:47 *** jmd has quit IRC
21:24:09 *** haclong has quit IRC
21:53:37 *** ErKa has quit IRC
22:03:08 *** Yawar has quit IRC