Re: Version Numbering

[Jeff Kletsky]

On 3/23/15 12:20 AM, John Ralls wrote:
What about API breaks in the Scheme and Python bindings? Not something 
most users care about, but folks with custom scripts sure do. We've 
always said that we don't guarantee API stability between major 
versions, but we also promote the bindings pretty heavily.


I suspect that users care most about file compatibility. We've done 
pretty well on that through the 2.x series, but along with multi-user 
will come a shift from default XML to default SQL, and going forward 
from that we'll want to normalize the schema, especially to move stuff 
out of slots.


The two combined would be a useful guideline: first-number changes 
mean that you'll have to revisit your scripts or your database will be 
upgraded so that it's not readable by the previous version except the 
closeout release.



From a consumer perspective, as well as speaking as a product manager 
for enterprise software, I generally expect that (after the database 
upgrade has run):


* Major version number release
* Meaningful improvement in functionality
* Database schema may have changed and *likely not* be even 
readable by previous versions of software with the previous major 
version number (even in last of prior major version's releases)
* API may have changed extensively, and may not be backwards 
compatible


* Minor version number release
* Some improvement in functionality beyond bug fixes
* Database schema may have changed and *may not* be read/write 
compatible with previous versions of software with the same major/minor 
version number.
* API may have been extended and certain features may have been 
deprecated (but still functional)


* "Point" release
* Primarily bug fixes
* Database schema may have changed, but still read/write compatible 
with previous versions of the software with the same major/minor version 
number.
* API may have been extended and certain features may have been 
deprecated (but still functional)


If a non-backwards-compatible database schema change is absolutely 
required for a point release, I'd consider first making it a minor 
release. If that wasn't appropriate, very clear messaging in the app 
prior to running the database upgrade, along with prominent information 
in the release notes would be my approach.




Going along with this are the usual tenants of using mission-critical 
software:


* It is the user's responsibility to back-up data before upgrading 
(though I don't object to a warning before running the database upgrade 
triggers)


* It is the user's responsibility to test, evaluate, and consider the 
impact of upgrading to a new major version to determine if it provides 
benefits sufficient to outweigh unforeseen impact of changes in 
functionality, database, API, and the like *prior* to committing 
production data to the new version


* The user should be able to review release notes that clearly outline 
any deprecations, removals or significant changes in functionality, 
including API changes. These release notes ideally will indicate when a 
change has been made to the database schema.


* The user should have confidence that software vendor has tested the 
new versions against data loss, as well as unexpected regressions or 
changes in behavior. Further, that the vendor will any bugs or 
unexpected behavior should be addressed promptly.




As a consumer example, I never "expect" that if I upgrade an Android 
application that I'll be able to restore a previous version of the app 
and have it work with the database and other data from the newer version.




Personally, I'd rather more time go into the 3.x line utilizing the 
database backing store to improve performance, than having to make sure 
that "2.last" can somehow understand the new schema and revert it to XML 
or what have you.


My 2 cents, or pence, at the moment...

Jeff
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Building Mac OS X GnuCash and run-time failures -- file: "libgncmod-engine", message: "file not found"

[Jeff Kletsky]

Well, it's been an interesting journey trying to get GnuCash to build 
and run under Mac OS X.

(Yes, I need to do this.)

First off, thanks to John Ralls for quickly merging in my patch to use 
the current repository for xmlsec!


For anyone trying to do this on their own, this is what I've found:

I'm using a "throw-away" account just in case the build/install process 
pollutes the environment in some unexpected way. So far, it looks like 
the only directories touched are in ~/.local (don't delete as other 
apps/processes use it) and in ~/gnucash-on-osx and ~/gtk -- this is a 
*good* thing, in my opinion. Thanks for that in the build scripts!


After you've downloaded the gtk-osx and gnucash-on-osx, you need to 
modify gnucash-on-osx/.jhbuildrc-custom to reflect the Mac OS X SDK 
level that you want to use. As a word of warning, you can't build 
against the 10.10 (Yosemite) SDK on a 10.9 (Mavericks) machine, 
apparently since the build process needs to /run /some of the 
executables itself. If you're getting failures in gobject-introspection, 
this may be your problem.


Since recent versions of Mac OS X include the openssl libraries, I would 
rather not have another version lined into the application. That way I 
only have to update the OS version, not rebuild every time there is a 
security update. Unfortunately, I suspect that there are things like 
GNUTLS built in as well, which need their own patching. John Ralls said 
on IRC that one could also skip openssl with a command-line argument, 
but I prefer to have it be the "always" case.


I also modified it to re-point to my local build manifest, rather than 
pulling the one from jralls' github.


===

diff --git a/.jhbuildrc-custom b/.jhbuildrc-custom
index 940dd1e..ec7353d 100644
--- a/.jhbuildrc-custom
+++ b/.jhbuildrc-custom
@@ -21,9 +21,16 @@ modules = ["meta-gtk-osx-bootstrap", 
"meta-gtk-osx-core", "gnucash"]

 #"ppc". Don't try to do a universal build, it doesn't work. x86_64 is
 #untested. Users on systems later than 10.6 will need to replace both
 #instances of "10.5" below with their OS version:
-setup_sdk("10.5", "10.5",["i386"])
+setup_sdk("10.9", "10.9",["i386"])

-moduleset = 
"http://github.com/jralls/gnucash-on-osx/raw/master/modulesets/gnucash.modules"; 


+# 10.7 and later already have openssl
+# 
https://mail.gnome.org/archives/gtk-osx-users-list/2015-January/msg1.html

+# Note that it is skip.append(), not skip.add()
+skip.append('openssl')
+
+# moduleset = 
"http://github.com/jralls/gnucash-on-osx/raw/master/modulesets/gnucash.modules";

+
+moduleset = 
"/Users/gnucash-build/Documents/devel/gnucash-on-osx/modulesets/gnucash.modules"


===

Note that "gnucash-build" the the user name in the full path to 
gnucash.modules -- this would need to be modified for your path, or just 
leave moduleset alone and take the current version from github.


I recommend symlinking ~/.jhbuilrd-custom to 
path/to/gnucash-on-osx/.jhbuildrc-custom so that you have only one 
version of it on your file, and it is in your local git repo when you 
change it.


I'm under the belief that this should be done *before* building the gtk 
tools, as it sets the SDK, architecture, and  bit-ed-ness (32, at this 
point). If/when one goes to build 64-bit versions, you'd likely need to 
rebuild the tools as 64-bit as well.


I then build the tools. While Python has been updated on Mac OS X, I 
haven't been able to build the libxml2 wrapper required in a virtualenv, 
so I just deal with another full copy of python dedicated for this purpose.


I then run my prebuild script -- everything here *should* go smoothly

===
#!/bin/sh -v

cd ~/Documents/devel/gtk-osx

/bin/sh gtk-osx-build-setup.sh

PATH=~/.local/bin:$PATH

jhbuild build python && jhbuild bootstrap

===

With the tools built, you should be able to *start* building GnuCash. It 
*will* fail the first time through...


===
#!/bin/sh -v

cd ~/Documents/devel/gnucash-on-osx

PATH=~/.local/bin:$PATH

jhbuild build

===

In libsoup, it will crap out with something along the lines of

... gobject-introspection/giscanner/sourcescanner.py", line 302, in _parse
 proc.stdin.write('#ifndef %s\n' % (define, ))

This one is a good puzzle, and thanks to Philip Chimento, found at


> Here’s the weird part, and the work-around. They’re the same:

> Select 4 to open a shell. cd to glib-networking. Run
>   make uninstall && make install
> Quit the shell and select 1, rerun build. All will be well.

> How’s that for weird?

Yep -- do that and scratch your head as to why. Gotta love 
gobject-introspection.


It *should* complete the build.

I have run into another problem with interrupted or second builds:

** Checking out bdw-gc *** [63/65]
git remote set-url origin git://github.com/ivmai/bdwgc
git remote update origin
Fetching origin
*** Error during phase checkout of bdw-gc: Refusing to switch a dirty 
tree. *** [63/65]


Here the resolution is to open a s

Budgeting [Was: GNUCash Development Plan?]

[Jeff Kletsky]

Looks like book-closing transaction flag was introduced in 
http://svn.gnucash.org/trac/changeset/19945 -- Thanks!


On 02/13/2012 04:12 PM, Jeff Kletsky wrote:

On 02/13/2012 02:10 PM, Phil Longstaff wrote:
Budgeting is one area I want to work with.  What, specifically are 
you fighting with?


Phil


From my perspective, which may or may not be well-aligned with other 
perspectives, and what I remember from the past years:


* Need a way that my wife and I can quickly see how we are doing 
against budget
  - Scheme rendering is painfully slow -- 
https://bugzilla.gnome.org/show_bug.cgi?id=612215
  - Existing reports are hard to read and have poor usability, even on 
desktop screens
  - Single-user access means that you can't just "pop in" to see a 
report, even if it were usable


* Would prefer if we could access current actual-vs-budget numbers 
from any modern browser, including iPad, iPhone, and Android


* Budget creation UI has severe usability issues including:
  - Rendering/scrolling (column and row headers disappear is the most 
annoying)

  - Can't "tab" to next cell for quick entry
  - Can't "fill right"

* Budget code is just messed up with respect to internal 
representations vs. UI display -- 
https://bugzilla.gnome.org/show_bug.cgi?id=612214


* Budget should distinguish between "no budget established" and "zero 
budget set" -- For example, I may have a budget on Expenses:Gifts at 
$100, but not have a budget set for either Expenses:Gifts:Alice or 
Expenses:Gifts:Bob. Having an expense in Expenses:Gifts:Alice of $50 
should not be an "over-budget" situation for that account, nor should 
having $60 in Expenses:Gifts:Bob of $60, but I should see an issue at 
the Expenses:Gifts roll-up level.


* In some cases it would be beneficial if a budget could either or 
both indicate a limit on the total at a roll-up point, as well as an 
incremental amount (You can spend $100 on gifts, in total, but no more 
than $10 on gifts that haven't been assigned to a sub-account)


* The ability to determine if a budget is balanced (and, if not, the 
residual difference and sign), especially while working on the budget, 
is difficult. The reports related to budget balance have the same kind 
of problems as the actual-vs-budget reports. I define "balanced" when 
my budgeted changes to assets, liabilities, expenses, and income are 
zero-sum in an accounting sense.


* Because the tools within GNUCash for budgeting are so rough, I end 
up working up my budgets in Excel. It would be on my wish list to have 
an import/export feature.


* As I recall, for example, budgeting income going into a non-cash 
investment account that increased in value (especially non-realized 
gain) was a puzzle that crossed my eyes and made my head spin. It is 
that funny mix of trying to deal with cash-flow budgeting when the 
budget is looking only at the change in the account's balance.


* Until there is a way to identify a set of transactions as 
book-closing transactions, either the last periods of the previous 
year, or the first periods of the current year will be "corrupted" by 
those transactions. Unfortunately, there "hack" of putting those 
transactions on January 1st doesn't work too well if you have "real" 
transactions on that day (as most individuals and some companies do).




I know it is a pretty long list, but I'd be happy to contribute 
thought or design feedback either here, on a wiki page, or directly, 
as it most makes sense. I've looked at the C code in the past and 
thought about some approaches, but the edict that everything needed to 
be backward compatible made things pretty horrendous. Especially after 
looking at the SQL schema in my current plan to implement off-line 
budgeting and reporting, I really dislike KVPs as ad hoc object 
extensions.


Let me know how I can help.

Jeff Kletsky
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GNUCash Development Plan?

[Jeff Kletsky]

On 02/13/2012 02:10 PM, Phil Longstaff wrote:
Budgeting is one area I want to work with.  What, specifically are you 
fighting with?


Phil


From my perspective, which may or may not be well-aligned with other 
perspectives, and what I remember from the past years:


* Need a way that my wife and I can quickly see how we are doing against 
budget
  - Scheme rendering is painfully slow -- 
https://bugzilla.gnome.org/show_bug.cgi?id=612215
  - Existing reports are hard to read and have poor usability, even on 
desktop screens
  - Single-user access means that you can't just "pop in" to see a 
report, even if it were usable


* Would prefer if we could access current actual-vs-budget numbers from 
any modern browser, including iPad, iPhone, and Android


* Budget creation UI has severe usability issues including:
  - Rendering/scrolling (column and row headers disappear is the most 
annoying)

  - Can't "tab" to next cell for quick entry
  - Can't "fill right"

* Budget code is just messed up with respect to internal representations 
vs. UI display -- https://bugzilla.gnome.org/show_bug.cgi?id=612214


* Budget should distinguish between "no budget established" and "zero 
budget set" -- For example, I may have a budget on Expenses:Gifts at 
$100, but not have a budget set for either Expenses:Gifts:Alice or 
Expenses:Gifts:Bob. Having an expense in Expenses:Gifts:Alice of $50 
should not be an "over-budget" situation for that account, nor should 
having $60 in Expenses:Gifts:Bob of $60, but I should see an issue at 
the Expenses:Gifts roll-up level.


* In some cases it would be beneficial if a budget could either or both 
indicate a limit on the total at a roll-up point, as well as an 
incremental amount (You can spend $100 on gifts, in total, but no more 
than $10 on gifts that haven't been assigned to a sub-account)


* The ability to determine if a budget is balanced (and, if not, the 
residual difference and sign), especially while working on the budget, 
is difficult. The reports related to budget balance have the same kind 
of problems as the actual-vs-budget reports. I define "balanced" when my 
budgeted changes to assets, liabilities, expenses, and income are 
zero-sum in an accounting sense.


* Because the tools within GNUCash for budgeting are so rough, I end up 
working up my budgets in Excel. It would be on my wish list to have an 
import/export feature.


* As I recall, for example, budgeting income going into a non-cash 
investment account that increased in value (especially non-realized 
gain) was a puzzle that crossed my eyes and made my head spin. It is 
that funny mix of trying to deal with cash-flow budgeting when the 
budget is looking only at the change in the account's balance.


* Until there is a way to identify a set of transactions as book-closing 
transactions, either the last periods of the previous year, or the first 
periods of the current year will be "corrupted" by those transactions. 
Unfortunately, there "hack" of putting those transactions on January 1st 
doesn't work too well if you have "real" transactions on that day (as 
most individuals and some companies do).




I know it is a pretty long list, but I'd be happy to contribute thought 
or design feedback either here, on a wiki page, or directly, as it most 
makes sense. I've looked at the C code in the past and thought about 
some approaches, but the edict that everything needed to be backward 
compatible made things pretty horrendous. Especially after looking at 
the SQL schema in my current plan to implement off-line budgeting and 
reporting, I really dislike KVPs as ad hoc object extensions.


Let me know how I can help.

Jeff Kletsky
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

GNUCash Development Plan?

[Jeff Kletsky]

Once again, it is the beginning of the year and I'm fighting with 
GNUCash budgeting to the point where I need to find a solution that is 
functional for me. I'd like to be able to return the work to the 
community, but I don't have a good idea of what is planned for major 
functionality changes in GNUCash in coming releases. For example, I 
found an email from John Ralls on 2011/09/26 that suggested that there 
was some thought of moving off the C-driven queries and allowing things 
to be handled by the back end.


Is there a wiki page somewhere that suggests what major changes are 
planned for upcoming releases?


Also, at one point, there was a development directive that any changes 
had to be backward compatible in that previous versions of GNUCash 
*must* be able to read newer versions of the data store without failing. 
This seems to have resulted in the use of KVP as a generic extension 
method, rather than changing the schema and providing upgrade triggers. 
Is that still the case?


Thanks,

Jeff Kletsky

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: I can't find working libdbi version

[Jeff Kletsky]

Something isn't quite right there yet:

the_datetime_tz: in:'2001-12-31 23:59:59 -10:00' out:0-0-0 0:0:0
the_time_tz: in:'23:59:59-10:00' out:0:0:0


Unfortunately, the libdbi test does not identify "wrong" values



On 01/27/2011 01:36 AM, Christoph Holtermann wrote:

Hello !

make check with libdbi-drivers-0.8.3-1 shows:

Test 8: Retrieve data:
 Got result, try to access rows
 this should cause a column type mismatch...
type mismatch errflag=-7: The requested variable type does not match what 
libdbi thinks it should be
 this should cause a bad name error...
bad name errflag=-5: An invalid name was passed to libdbi
the_datetime_tz: test skipped for this driver.
time_tz: test skipped for this driver
the_char: in:-127 out:-127<<
the_uchar: in:127 out:127<<
the_short: in:-32768 out:-32768<<
the_ushort: in:32767 out:32767<<
the_long: in:-2147483648 out:-2147483648<<
the_ulong: in:2147483647 out:2147483647<<
the_longlong: in:-9223372036854775807 out:-9223372036854775807<<
the_ulonglong: in:9223372036854775807 out:9223372036854775807<<
the_float: in:3.402823466E+38 out:3.402820e+38<<
the_double: in:1.7976931348623157E+307 out:1.797693e+307<<
the_driver_string: in:'Can 'we' "quote" this properly?' out:'Can 'we' "quote" this 
properly?'<<
the_quoted_string: in:'Can 'we' "quote" this properly?' out:'Can 'we' "quote" this 
properly?'<<
the_quoted_string_copy: in:'Can 'we' "quote" this properly?' out:'Can 'we' "quote" 
this properly?'<<
the_escaped_string: in:'Can 'we' "escape" this properly?' out:'Can 'we' "escape" this 
properly?'<<
the_escaped_string_copy: in:'Can 'we' "escape" this properly?' out:'Can 'we' "escape" 
this properly?'<<
the_empty_string: out:''<<
the_null_string: out:'(null)'
the_datetime: in:'2001-12-31 23:59:59' out:2001-12-31 23:59:59
the_datetime_tz: in:'2001-12-31 23:59:59 -10:00' out:0-0-0 0:0:0
the_date: in:'2001-12-31' out:2001-12-31
the_time: in:'23:59:59' out:23:59:59
the_time_tz: in:'23:59:59-10:00' out:0:0:0
the_quoted_binary: in: 65-66-0-67-39-68- out: 65-66-0-67-39-68-<<
the_escaped_binary_copy: in: 65-66-0-67-39-68- out: 65-66-0-67-39-68-<<

this is correct, isn't it ?

regards,

Christoph Holtermann
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Interactive Javascript + Canvas (Flot) powered graphs

[Jeff Kletsky]

On 01/24/2011 01:18 AM, Christian Stimming wrote:

[...]

I do have an extremely simple module thrown
together so that python can be used from within gnucash,

You have? I'd be interested to see that. Even if it can't be used for
replacing scheme reports by python reports at this point in time, I would be
interested to see whether other scriptable tasks within gnucash can be done
through python already.




I'm at the point with scheme and eguile of just writing a "report" that 
calls out to Perl and takes the HTML on a pipe. Perlembed isn't much 
harder, at least once bindings are done.


I was hoping that I would be able to read directly from the database, 
but the abundance of KVP usage makes the schema too far from the objects 
for my taste, at least past simple reporting.


I'm planning on Perl bindings, at least to some extent, as I would like 
to be able to more cleanly integrate with Mason, Moose, and Catalyst 
sites, at least for reporting.


One thing that would be a huge help for anyone writing bindings would be 
a better-defined API. Unfortunately, there isn't a "libgnucash" to link 
against.


Jeff

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

"Account unknown Bank unknown" patch available

[Jeff Kletsky]

https://bugzilla.gnome.org/show_bug.cgi?id=640233

At least for the online OFX sources I use in the US, downloaded
transactions are populated with memos of

"Account unknown Bank unknown"

Past being annoying, this can cause improper "matches" when comparing
transactions.

The root cause is found in src/import-export/aqbanking/gnc-ab-utils.c
in the function gnc_ab_memo_to_gnc where the code seems to check for
the existence of a remote account number from the aqbanking
transaction

if (ab_other_accountid && *ab_other_accountid)

and appears to intend to return the empty string if one is not present.

However, an earlier line in the code sets ab_other_accountid to
"unknown" so that the test always returns true.

This patch should return:

* "Account  Bank " if both are present

* "Account " if only the account is present

* "Bank " if only the bank is present

* "" if neither is present

Additionally, ordering of trimming was changed to handle the
possibility that the leading and/or trailing character(s) were stripped
as invalid UTF-8, resulting in an untrimmed string.



NOTE: This patch should be checked using online sources that *do*
populate the account/bank fields to confirm that it is working as
intended in those situations.

Jeff

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

OFX not translated?

[Jeff Kletsky]

Digging into the source of the "Account unknown Bank unknown" string 
(that annoys me immensely), I looked at


src/import-export/ofx/gnc-ofx-import.c

and find it laden with UI-destined strings that aren't translated. For 
example:


case OFX_DEBIT:
strncpy(dest_string, "Generic debit", 
sizeof(dest_string));

break;
case OFX_INT:
strncpy(dest_string, "Interest earned or paid 
(Note: Depends on signage of amount)", sizeof(dest_string));

break;
case OFX_DIV:
strncpy(dest_string, "Dividend", sizeof(dest_string));
break;


Is there a reason (past time and effort) that these were not gettext-ified?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: get quotes broken?

[Jeff Kletsky]

I recently had problems trying to run gnucash --add-price-quotes from a 
cron job.


If that is the case (or you are not running under X), you may need to 
start dbus, similar to


env `dbus-launch` sh -c 'trap "kill $DBUS_SESSION_BUS_PID" EXIT; 
/usr/local/bin/gnucash --add-price-quotes /path/to/file.gnucash'


Jeff



On 01/18/2011 02:07 PM, Herbert Thoma wrote:

Hi,

did anything change in the code that handles online retrieval of
stock prices with finance-quote? It does not work any more for me.

The last successful stock price download was on Jan. 7th, but I
don't do this every day so I don't know exactly when it stopped
working. My current GnuCash is built from SVN r20106.

gnc-fq-dump shows reasonable results.

Is there anybody else having problems? Any suggestions what might
have changed and how to debug this?

 Herbert.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: What svn rev is 2.4.0?

[Jeff Kletsky]

Thanks for clarifying things so I can get working again and reference 
"the right" 2.4.0 as a branch point and in diffs.


No clue why svnversion -c returns
2135:
but, to me, whatever it returns seems like what should be in the build 
(it does indicate local modifications as well, from svnversion --help)


r2135 seems pretty uneventful; some reformatting of code, so no clue why 
it turns up as a "mixed revision working copy"




jeff@fx:/usr/local/src/gnucash-2.4.0$ diff -qs -r -x .svn trunk-19971 
trunk-2135 | fgrep identical


Files trunk-19971/doc/gnome-hackers.txt and 
trunk-2135/doc/gnome-hackers.txt are identical





On 01/16/2011 11:05 AM, Geert Janssens wrote:

On Sunday 16 January 2011, Jeff Kletsky wrote:

Which SVN revision is "officially" 2.4.0?

Tagged is r19971


This is the official version.


The source tarball builds as r19974


That was probably the latest svn revision at the time the tarball was created.
That doesn't mean the tarball was created from revision r19974 though.

I think this is the result of the way subversion works and how we are
extracting the revision information.


An svn checkout of 2.4.0 builds as r20008


Same issue here.


$ svn info
Path: .
URL: http://svn.gnucash.org/repo/gnucash/tags/2.4.0
Repository Root: http://svn.gnucash.org/repo
Repository UUID: 57a11ea4-9604-0410-9ed3-97b8803252fd
Revision: 20008
Node Kind: directory
Schedule: normal
Last Changed Author: plongstaff
Last Changed Rev: 19971
Last Changed Date: 2010-12-20 10:00:29 -0800 (Mon, 20 Dec 2010)


Your svn info shows that at the time you checked out 2.4.0 (or last updated
your working directory) r20008 was the most recent svn revision. Yet, the Last
Changed Rev shows that the directory you checked out was last modified in
r19971. That's the parameter that is relevant to determine the svn revision
that was used to create the tarball.

Unfortunately the script that checks the actual svn version during tarball
creation uses the Revision parameter instead. Which just increases with every
commit *anywhere* in the repository. So even if the contents of the tagged
directory is not changed, the Revision number does.

There is a way to get the Last Changed Rev as well (by calling svnversion -c
instead of plain svnversion), but for some reason that outputs two revision
numbers, not one. I don't know why that is. The latter of those two is indeed
the actual Last Changed Rev.

Perhaps we can try to work with that instead of Revision ?

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

What svn rev is 2.4.0?

[Jeff Kletsky]

Which SVN revision is "officially" 2.4.0?

Tagged is r19971

The source tarball builds as r19974

An svn checkout of 2.4.0 builds as r20008

$ svn info
Path: .
URL: http://svn.gnucash.org/repo/gnucash/tags/2.4.0
Repository Root: http://svn.gnucash.org/repo
Repository UUID: 57a11ea4-9604-0410-9ed3-97b8803252fd
Revision: 20008
Node Kind: directory
Schedule: normal
Last Changed Author: plongstaff
Last Changed Rev: 19971
Last Changed Date: 2010-12-20 10:00:29 -0800 (Mon, 20 Dec 2010)

There seem to be differences between r19971 and r19974
http://svn.gnucash.org/trac/changeset?old_path=gnucash&old=19971&new_path=gnucash&new=19974

as well as between r19974 and r20008
http://svn.gnucash.org/trac/changeset?old_path=gnucash&old=19974&new_path=gnucash&new=20008




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: ~/.gnucash and XDG default directories

[Jeff Kletsky]

I'm a Product Manager by day...

From my perspective, changing the location of the preference files on 
Unix-like platforms doesn't provide significant value either to the end 
user or to making the code more accessible to prospective developers.


I'd much rather see development time go into things that provide more 
tangible benefit.




On 01/16/2011 09:12 AM, Geert Janssens wrote:

Thanks for your feedback.

On Sunday 16 January 2011, Jeff Kletsky wrote:

In my opinion, adopting a "standard" that

* goes counter to long-established practice


 From what I've read is serves a different target audience. The XDG base
specification was created to cater for a new breed of users: ordinary desktop
users that don't know/care about config files or user specific application
data. As such the intended target applications for this spec are desktop
applications. I think GnuCash falls into that category. The long-established
practice still holds as far as I'm concerned for anything more power user
(things like mutt, lynx, vi, emacs,...).


* isn't widely accepted


This is mostly a chicken-and-egg problem. Not adopting a new standard because
it's not widely accepted will never get it widely accepted.


will cause more problems than it is worth.


There is a significant documentation change cost for GNUCash.


6 lines in the Help Manual and Concepts Guide combined
7 comment lines in the code
A number of entries in the wiki
What did I miss ?


There is a significant coding/test cost (either auto-upgrade, or
checking two locations, and possibly having both present)


There are examples that can be reused. Rhythmbox has implemented a silent
migration, Comix does a migration after asking the user.

There is a significant support cost ("Where are the config files? They
aren't where everything else is.")


Again the chicken and egg issue. As more GUI apps start using the XDG
standard, the config files will be in the expected location.

As far as I can tell, there is nothing that I use on FreeBSD that uses
~/.local/share (they are very adamant about non-base applications
installing system-wide data into /usr/local/etc, not letting everything
throw into crap into /etc) and on Ubuntu, only webkit's icons and
gvfs-metadata are found there.


As far as I can see, you are mixing things up here. The choice between /etc or
/usr/local/etc has nothing to do with the user. Both are for system wide
preferences. Moving from $HOME/.  to .local/share or .config (thanks
John for pointing that out) is for user specific data generated by the
application.

I see more and more applications that start to adhere to this specification.
There is a proposed GnomeGoal as well, though it's not approved yet.
Considering Gnome is part of the Freedesktop platform (as is KDE and Qt) I
expect them to come through with the spec at some point.

But I also see this spec stirs up a lot of discussion so probably it's best to
let the dust settle before we make our final decision. There's no hurry. I
didn't intend to make these changes before 2.6 anyway.


On Mac, things generally go into ~/Library/Application Support (though I
haven't read developer docs for OS X in ages).


I would expect g_get_user_config_dir or g_get_user_data_dir to return that
path by default, but I'm afraid I don't know how glib on OS X works.

Geert


Jeff

On 01/16/2011 07:19 AM, Geert Janssens wrote:

Historically, GnuCash has always stored its user specific application
data in ~/.gnucash based on old linux (unix ?) conventions.

This didn't work really well on Mac OS X/Quartz, so John has overridden
this path on OS X to make more sense there.

Now there's a bugreport that indicates this isn't the best place on
Windows either [1].

I could override the path on Windows as well and be done with it, but in
my investigation I found that even on linux ~/.   is no longer
the recommended place to store such information.

According to the XDG Base Directory Specification [2] the preferred
location is ~/.local/share/.

The nice thing is, glib has a convenience function g_get_user_config_dir,
which by default returns ~/.local/share on linux and the equivalent and
proper ~\Application Data (Windows XP) or ~\AppData\Roaming (Windows
Vista/7).

I don't know what this routine returns on OS X, but I would expect it to
return the proper location for user specific application data there as
well. If not that should be reported as a bug againse glib on OS X.

In this light I would like to update the GnuCash code to make use of the
g_get_user_data_dir function on all platforms and rename the directory
from .gnucash to gnucash. That would give a better experience on all
platforms IMO. This is what the directories would become:
- Linux: ~/.local/share/gnucash
- Windows XP: c:\Documents and Settings\\Application Data\gnucash
- Windows Vista/7: c:\Documents and
Settings\\AppDat

Re: ~/.gnucash and XDG default directories

[Jeff Kletsky]

In my opinion, adopting a "standard" that

* goes counter to long-established practice

* isn't widely accepted

will cause more problems than it is worth.


There is a significant documentation change cost for GNUCash.


There is a significant coding/test cost (either auto-upgrade, or 
checking two locations, and possibly having both present)



There is a significant support cost ("Where are the config files? They 
aren't where everything else is.")



As far as I can tell, there is nothing that I use on FreeBSD that uses 
~/.local/share (they are very adamant about non-base applications 
installing system-wide data into /usr/local/etc, not letting everything 
throw into crap into /etc) and on Ubuntu, only webkit's icons and 
gvfs-metadata are found there.



On Mac, things generally go into ~/Library/Application Support (though I 
haven't read developer docs for OS X in ages).


Jeff


On 01/16/2011 07:19 AM, Geert Janssens wrote:

Historically, GnuCash has always stored its user specific application data in
~/.gnucash based on old linux (unix ?) conventions.

This didn't work really well on Mac OS X/Quartz, so John has overridden this
path on OS X to make more sense there.

Now there's a bugreport that indicates this isn't the best place on Windows
either [1].

I could override the path on Windows as well and be done with it, but in my
investigation I found that even on linux ~/.  is no longer the
recommended place to store such information.

According to the XDG Base Directory Specification [2] the preferred location
is ~/.local/share/.

The nice thing is, glib has a convenience function g_get_user_config_dir,
which by default returns ~/.local/share on linux and the equivalent and proper
~\Application Data (Windows XP) or ~\AppData\Roaming (Windows Vista/7).

I don't know what this routine returns on OS X, but I would expect it to
return the proper location for user specific application data there as well.
If not that should be reported as a bug againse glib on OS X.

In this light I would like to update the GnuCash code to make use of the
g_get_user_data_dir function on all platforms and rename the directory from
.gnucash to gnucash. That would give a better experience on all platforms IMO.
This is what the directories would become:
- Linux: ~/.local/share/gnucash
- Windows XP: c:\Documents and Settings\\Application Data\gnucash
- Windows Vista/7: c:\Documents and Settings\\AppData\Roaming\gnucash
- OS X: ?

I would obviously have to provide some conversion code as well, that would
copy the old .gnucash contents to .local/share/gnucash to guarantee continuity
for the users.

I also think this change may be better for 2.5/2.6 than 2.4.1.

Does anyone have any objections to this ?

Geert

[1] see https://bugzilla.gnome.org/show_bug.cgi?id=503722
[2] see http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New Budget Report

[Jeff Kletsky]

Thanks, that was it -- I hadn't noticed the page changed since I was 
adding reports last spring.


Jeff


On 01/14/2011 10:23 AM, Geert Janssens wrote:

On Friday 14 January 2011, Jeff Kletsky wrote:

(load-from-path "/home/jeff/gnucash-reports/psl-budget.scm")

in ~/.gnucash/config.user, as described on that page causes the error.
Commenting out the line allows GNUCash to start without the error.


Using load-from-path is discouraged. Use load instead. Read the wiki page
David refers to to get more details.

Geert



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New Budget Report

[Jeff Kletsky]

(load-from-path "/home/jeff/gnucash-reports/psl-budget.scm")

in ~/.gnucash/config.user, as described on that page causes the error. 
Commenting out the line allows GNUCash to start without the error.




On 01/14/2011 09:31 AM, David T. wrote:

I was able to get this report working by following the instructions for adding 
a report to my user space at:

http://wiki.gnucash.org/wiki/Custom_Reports

David

--- On Thu, 1/13/11, Jeff Kletsky  wrote:


From: Jeff Kletsky
Subject: Re: New Budget Report
To: "Phil Longstaff"
Cc: gnucash-devel@gnucash.org
Date: Thursday, January 13, 2011, 11:03 PM
When I add it to the load path and
try to start GNUCash, I get

Backtrace:
In current input:
1: 0* [gnc:main]
In /opt/share/gnucash/guile-modules/gnucash/main.scm:
  208: 1* (gnc:initialize-config-vars)

/opt/share/gnucash/guile-modules/gnucash/main.scm:208:3: In
expression (gnc:initialize-config-vars):
/opt/share/gnucash/guile-modules/gnucash/main.scm:208:3:
Unbound variable: gnc:initialize-config-vars

any suggestions?

Thanks,

Jeff


On 01/13/2011 05:27 PM, Phil Longstaff wrote:

On Thu, 2011-01-13 at 08:18 -0800, Jeff Kletsky

wrote:

On 01/12/2011 12:07 PM, Phil Longstaff wrote:

[...] I distributed an advanced
budget report via e-mail recently.  It

provided 3 sets of columns:  1) current

month, 2) YTD, 3) full year and for each set

of columns,

budget/actual/difference.  I found it to

be much more useful than the regular

budget report.

I wasn't able to find your report in my archives

of GNUCash mail. Would

it be possible to send it out again?

Attached.  Called PSL Budget Report because those

are my initials.  I

suppose I should pick a better name for it.  On

the General tab, you can

pick the period (month) to use.  I think it

defaults to 9.  Should make

it work off the current date.  I think the

numbers are 1-12 for Jan

through Dec.  Known issues: no shading, headings

for 2nd and 3rd sets of

columns are "Multiple periods" - should be more

informational.

Phil


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel






___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New Budget Report

[Jeff Kletsky]

When I add it to the load path and try to start GNUCash, I get

Backtrace:
In current input:
   1: 0* [gnc:main]
In /opt/share/gnucash/guile-modules/gnucash/main.scm:
 208: 1* (gnc:initialize-config-vars)

/opt/share/gnucash/guile-modules/gnucash/main.scm:208:3: In expression 
(gnc:initialize-config-vars):
/opt/share/gnucash/guile-modules/gnucash/main.scm:208:3: Unbound 
variable: gnc:initialize-config-vars


any suggestions?

Thanks,

Jeff


On 01/13/2011 05:27 PM, Phil Longstaff wrote:

On Thu, 2011-01-13 at 08:18 -0800, Jeff Kletsky wrote:

On 01/12/2011 12:07 PM, Phil Longstaff wrote:

[...] I distributed an advanced
budget report via e-mail recently.  It provided 3 sets of columns:  1) current
month, 2) YTD, 3) full year and for each set of columns,
budget/actual/difference.  I found it to be much more useful than the regular
budget report.

I wasn't able to find your report in my archives of GNUCash mail. Would
it be possible to send it out again?

Attached.  Called PSL Budget Report because those are my initials.  I
suppose I should pick a better name for it.  On the General tab, you can
pick the period (month) to use.  I think it defaults to 9.  Should make
it work off the current date.  I think the numbers are 1-12 for Jan
through Dec.  Known issues: no shading, headings for 2nd and 3rd sets of
columns are "Multiple periods" - should be more informational.

Phil


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New Budget Report

[Jeff Kletsky]

I'd be happy just to get a budget report that was correct, rendered in a 
lot less than the current 20-30 seconds (scheme sucks for HTML the way 
it builds tables right now), and I could actually print out the results.


I'd enjoy seeing either of these reports under 2.4. I am s close to 
just reading everything directly from the database (since the idea of 
writing wrappers for the dozens of .so isn't terribly appealing either).


I've got a little time, I'm hand-entering hundreds of numbers for my 
2011 budget.


On 01/12/2011 01:33 PM, Phil Longstaff wrote:

Hmmm  Yeah.  Another useful column for my report might be "same month last
year" and/or "YTD last year"

Well, given a flexible enough engine, it would be easy to take column values
from different years or different budgets.

I like the colouring idea.  I think that ultimately, we might want a generic
report engine which provides various things (columns, rows, totals, colouring).
Since we now have webkit which supports css and javascript, we can have
collapsing columns and rows (e.g. expand/collapse the income section).  On top
of this base engine, build a budget report engine.  On top of that, a budget
report.

  Phil
-
I used to be a hypochondriac AND a kleptomaniac. So I took something for it.


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Public Git repo

[Jeff Kletsky]

On 01/10/2011 08:28 AM, Geert Janssens wrote:

On Monday 10 January 2011, Jeff Kletsky wrote:

At least as I understand it, branches in git are nothing more than a
pointer to the "head" commit and, structurally, are pretty much the same
(if not identical) to tags. A branch in git is a tag on point in
development that is moved to other commits if you commit "to" that
branch. In simpler words, it is a tag that gets conveniently moved each
time you commit. You really aren't "working on/in a branch" but are more
moving what the notion of the head of the branch is. Yeah, it's really
different from svn that way.

While there is the notion of "parent" and "child" commits (which can be
multiple) in git, one of the things that is different about git branches
is that there is no notion of a "branch point" or a "branch history" the
way there is in svn, for example. Sure, as long as you don't merge the
branch, you can determine where it diverges from another branch.
However, once you merge, that gets dicey to impossible.

I don't know about the command line tools, but the graphical tool gitk seems
to have no problems with that ? As far as I know it nicely shows where
branches diverge and merge together again ?

Perhaps you have a specific use case in mind that is easier to handle in svn
that in git ?

Geert


git and svn are just "different" on things
which is "better" depends on how you work
(that said, I personally prefer git for my local work)

1) You're somewhere along in development

- A - B - C

Branch 1 => C


2) You Create Branch 2

- A - B - C

Branch 1 => C
Branch 2 => C


3) Make some commits on Branch 2

- A - B - C - D - E - F

Branch 1 => C
Branch 2 => F


4) Make some commits on Branch 1

- A - B - C - D - E - F
   \
\ G - H

Branch 1 => H
Branch 2 => F


5) Someone else makes a topic branch, Branch 3, off commit B
(maybe that was the last released version) and makes some commits

/ I -  J
   /
- A - B - C - D - E - F
   \
\ G - H

Branch 1 => H
Branch 2 => F
Branch 3 => J


6) You merge in some of the changes from Branch 3 into Branch 2

/ I - J -- \
   /\
- A - B - C - D - E - F - K
   \
\ G - H

Branch 1 => H
Branch 2 => K
Branch 3 => J


Sooo, where is the "branch point" for Branch 2? Was it commit B or 
commit C?


Also, from git's perspective, commmits I and J are just as much "on 
Branch 2"

as are commits D, E, and F.

From svn's perspective, there was a branch made at point C
and some additional changes were introduced in commit K

When I remember, I tag the branch points when I make them.







___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Public Git repo

[Jeff Kletsky]

At least as I understand it, branches in git are nothing more than a 
pointer to the "head" commit and, structurally, are pretty much the same 
(if not identical) to tags. A branch in git is a tag on point in 
development that is moved to other commits if you commit "to" that 
branch. In simpler words, it is a tag that gets conveniently moved each 
time you commit. You really aren't "working on/in a branch" but are more 
moving what the notion of the head of the branch is. Yeah, it's really 
different from svn that way.


While there is the notion of "parent" and "child" commits (which can be 
multiple) in git, one of the things that is different about git branches 
is that there is no notion of a "branch point" or a "branch history" the 
way there is in svn, for example. Sure, as long as you don't merge the 
branch, you can determine where it diverges from another branch. 
However, once you merge, that gets dicey to impossible. As long as you 
don't really care where you came from and how, git branches are fine. 
They can take care of

* most recent 2.2-Release version
* most recent 2.4-Release version
* most recent Stable version
* most recent Current (bleeding-edge) version

Git tags are really the "static" things to take care of the concept of:
* what are all the 2.2-Release versions?
* what are all the 2.4-Release versions?




On 01/10/2011 07:38 AM, Colin Law wrote:

On 10 January 2011 15:12, Derek Atkins  wrote:

Geert Janssens  writes:


On Wednesday 05 January 2011, Jeff Kletsky wrote:

I don't like that history is a pretty flexible thing and that "branches"
are just pointers to specific commits, rather than the kind of
"followable path" that svn provides.


That's interesting, because I feel exactly the oposite. I don't like it that
for svn a branch or tag is a path into the repository. It has always felt
artificial to me and if not treated with proper care could put you into very
unwanted situations like people inadvertently committing changes to a tagged
release.
I guess this is mostly a matter of taste and what you are most used to
though...

I like that branches are paths, because you DO want to be able to make
additional commits into a branch.  So I don't agree with you there.

I am not sure what you are suggesting here.  Using git there is no
problem committing to a branch, just checkout the branch, make the
changes, and commit.  The changes go onto the branch.


However, I do agree with you about tags.

IMHO branches and tags are (and should be) fundamentally different.  A
branch should be a path, but a tag is, well, a tag.

I believe they *are* different in git, at least in terms of the normal
usage via the git commands and utilities.

Colin
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Challenging python coders: Who can create a gnucash-like GUI in python in a few weeks?

[Jeff Kletsky]

In my opinion, it is great that Scheme and Guile are on the way out.

I would suggest though, that something more than how few lines of code 
are needed go into the determination of the language for the UI. 
Otherwise, APL is going to win hands down. Even the presence of bindings 
doesn't sway me much. The amount of UI code (and proper re-factoring of 
business logic out of the UI) is probably going to be much larger than 
the bindings. Part of me also cringes at the thought of using two 
different languages for one application unless there is a good reason.




I'd argue for at least the following:



* Modern, object-oriented code

This one really goes without saying, I hope.

I'd personally prefer one that handles "multiple inheritance" in a 
reasonable way and clearly supports anonymous functions, closures, and 
"lazy build" functionality.




* Popular among developers

You want people to already have the skills to be able to contribute to 
the project. The Open Source world is not really much different than the 
commercial world. Now matter how slick "your" language is, it is going 
to be much easier to, for example, find top-notch Java programmers, than 
some niche language (unless it is deemed "the next great thing").




* "xPad" aware

Consider that I wouldn't be surprised if there are more iPads out there 
than Linux desktops. Android is on the upswing. The increasing number of 
handheld devices, to some extent, argues against heavyweight 
interpreters. Why should the user have to not only download an app, but 
also another language interpreter, and potentially another GUI 
framework? I'm not saying that GNUCash must be in Objective C, but 
thinking about platform support and impact is worthwhile.




* Understandability and Maintainability

I guess that rules out APL...




On 01/10/2011 02:24 AM, Christian Stimming wrote:

Dear all,

We've been discussing various future directions for gnucash, including 
a switch to a different programming language for the GUI code [1]. GUI 
coding in C sucks. Because of this, I've experimented with C++/Qt and 
was able to write up a usable gnucash-like register window GUI in 2-3 
weeks which already includes features that are unavailable in 
"conventional gnucash" [2]. I chose C++/Qt because I'm very familiar 
and productive with that platform.


However, a scripting language might be even more suitable for writing 
the GUI code of a project like gnucash. The language Python is a 
particularly good candidate here because gnucash already has python 
wrappers for most of its underlying data type and storage code, 
thankfully provided by Mike Evans and others. See 
src/optional/python-bindings/ and the doxygen output [3] and the 
example scripts in python-bindings/example_scripts/, in particular 
scripts like simple_book.py: Loading an existing file, modifying some 
of the data, and writing again, all in 12 lines.




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Make check fails at dbi test

[Jeff Kletsky]

"...but the amounts always show zero [using SQL back end]"

If you're using SQLite3 on Ubuntu 10.10 and a 32-bit system, you 
probably have a broken libdbi.


Hold on, they're making a new package for us; I'm guessing later this 
week you'll be able to get it using synaptic, apt-get, or your favorite 
package updating tool.


Jeff


On 01/09/2011 04:29 PM, Bill Hammond wrote:

Ah.  Sorry.  I figured it out.  How 'bout 0.8.3-ubuntu1?

[...]

Hello!

I am having a problem with make check on r20048 (and a few versions
before that).  I am also having problems with gnucash 2.4.0 storing
accounts as an SQL database.  The transaction dates and descriptions
are
displayed in the register but the amounts always show zero.

Here's the error I get when I run make check.  There are no errors
during the ./autogen / ./configure / make phases of building.

I'm running Ubuntu 10.10 with sqlite3 3.7.0.  I believe I have all the
dbi stuff installed. I'm still running gnucash 2.2.9 with no problems.

What version of libdbi do you have?  This looks like the "libdbi
fastmath
bug" issue

-derek


Many thanks for your help.

Bill


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Fwd: [Bug 673307] Re: libdbi / libdbd-sqlite3 returns incorrect values for several data types

[Jeff Kletsky]

Now "In Progress" for Ubuntu:

Clint Byrum wrote on 2011-01-06: #6

Oh so it appears the test suite actually doesn't "fail", its just 
letting these incorrect numbers through. Crazy.


The Fedora fix seems to be the way to go, will push that out ASAP. I 
actually think this may affect natty too.

Changed in libdbi-drivers (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Clint Byrum (clint-fewbar)


Clint Byrum wrote on 2011-01-06: #7

This is actually a bug in libdbi, not libdbi-drivers. Redirecting as such.
affects: libdbi-drivers (Ubuntu) → libdbi (Ubuntu)


Clint Byrum wrote on 2011-01-06: #8

Reported the bug to libdbi upstream here

https://sourceforge.net/tracker/?func=detail&aid=3152613&group_id=23824&atid=379806




From: https://bugs.launchpad.net/ubuntu/+source/libdbi/+bug/673307



On 01/05/2011 04:57 PM, Jeff Kletsky wrote:

Progress...


Setting Importance to High. I think this only affects maverick, as the
build in natty runs the full test suite for mysql, pgsql, and sqlite3
and does not report this failure.

** Changed in: libdbi-drivers (Ubuntu)
   Importance: Undecided =>  High


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Fwd: [Bug 673307] Re: libdbi / libdbd-sqlite3 returns incorrect values for several data types

[Jeff Kletsky]

Progress...


Setting Importance to High. I think this only affects maverick, as the
build in natty runs the full test suite for mysql, pgsql, and sqlite3
and does not report this failure.

** Changed in: libdbi-drivers (Ubuntu)
   Importance: Undecided =>  High

--
You received this bug notification because you are a direct subscriber
of the bug.
https://bugs.launchpad.net/bugs/673307

Title:
  libdbi / libdbd-sqlite3 returns incorrect values for several data types

Status in “libdbi-drivers” package in Ubuntu:
  Confirmed

Bug description:
  This is related to
- Gnome's bugzilla bug 611936 https://bugzilla.gnome.org/show_bug.cgi?id=611936
- https://bugzilla.redhat.com/show_bug.cgi?id=629964 in Fedora's bugtracker

It seems that the 8.3 version of libdbd-sqlite3 delivered with Ubuntu 10.10 
i386 is complied with optimisation -ffast-math which causes all the numeric 
values in gnucash 2.3.15  (svn r19751) with SQLite backend to be retrieved as 
zero.

This problem only started after I upgraded from Ubuntu 10.04 to 10.10.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: libdbd-sqlite3 0.8.3-1-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-22.35-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic i686
Architecture: i386
Date: Wed Nov 10 11:40:17 2010
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100427.1)
ProcEnviron:
 LANG=en_AU.utf8
 SHELL=/bin/bash
SourcePackage: libdbi-drivers

To unsubscribe from this bug, go to:
https://bugs.launchpad.net/ubuntu/+source/libdbi-drivers/+bug/673307/+subscribe

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Public Git repo

[Jeff Kletsky]

I maintain my own, local git repository and have a mixed love/hare 
relationship with git.


For me, I like the lightweight branching and merge capabilities. I like 
the built-in bisection to locate introduced changes in result (generally 
bugs, but sometimes enhancements as well). For local development, it is 
now my VC of choice (over svn, but I haven't recently looked at git's 
"competitors").


I don't like that history is a pretty flexible thing and that "branches" 
are just pointers to specific commits, rather than the kind of 
"followable path" that svn provides.


I understand, but detest oh-great-dictator-Linus' decision to 
intentionally lose all information related to file-modification times 
and dates.


I personally don't care what the "master" repository format is, within 
reason. The huge upside of svn is that it works and there isn't a 
transition cost associated with staying with it.





In case it is of some use to someone here, these are some of my notes on 
how I cloned the master svn for my own use:


$ git svn init --stdlayout http://svn.gnucash.org/repo/gnucash gnucash
$ cd gnucash
$ git svn fetch

(about 5 hours later on 18 Mbps line)

That's it...

$ git branch local
$ git checkout local

Where did the branches and tags go?

$ git branch -a

$ git svn rebase

$ git repack -a -d -f --window=100




and some notes of inserting tags and .gitignore



Update tags on git-svn clone

$ git for-each-ref refs/remotes/tags | cut -d / -f 4- | xargs -n 1 -I % 
git tag -f % tags/%


-f since tags can move in svn



Create .gitignore to correspond with svn:ignore

$ git svn create-ignore



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [Bug 611936] Sqlite3: assertion `gnc_numeric_check(amt) == GNC_ERROR_OK' failed

[Jeff Kletsky]

In my opinion, since this is an OS-distribution-related problem rather 
than a core-to-the-library problem, spending a lot of valuable dev time 
on "fixing" it seems inappropriate.


I would suggest something along the lines of testing for the library 
bug, alerting the user if it exists (with a checkbox for "Don't tell me 
again"), and disabling the SQLite3 option if it exists.


There is test code distributed in 
libdbi-drivers-0.8.3-1/tests/test_dbi.c that may be useful, perhaps 
combined with tempfile. I don't know if there is a Windows equivalent of 
tempfile; another option would be to disable the test on Windows builds 
(or only enable it for Linux, as it seems to have only surfaced with 
Linux builds of the library).


Running test_dbi on an "Intel(R) Atom(TM) CPU  330   @ 1.60GHz"
user0m0.028s
sys 0m0.008s

so it would seem that the "overhead" of performing the test for the 
"bad" data types:


the_longlong: in:-9223372036854775807 out:0<<
the_ulonglong: in:9223372036854775807 out:0<<

the_double: in:1.7976931348623157E+307 out:0.00e+00<<

the_datetime: in:'2001-12-31 23:59:59' out:2001-12-31 0:0:0
the_datetime_tz: in:'2001-12-31 23:59:59 -10:00' out:2001-12-31 0:0:0

the_time: in:'23:59:59' out:0:0:0
the_time_tz: in:'23:59:59-10:00' out:0:0:0

on each start-up would not be a huge burden.

Jeff


On 01/04/2011 04:14 AM, GnuCash (bugzilla.gnome.org) wrote:

https://bugzilla.gnome.org/show_bug.cgi?id=611936
   GnuCash | SQL Backend | SVN

Christian Stimming  changed:

What|Removed |Added

  Status|RESOLVED|REOPENED
  CC||stimm...@tuhh.de
  Resolution|NOTGNOME|

--- Comment #32 from Christian Stimming  2011-01-04 12:14:30 
UTC ---
Reopening because it's a bug that seems to hit an increasing number of users,
and we need to find a better way around it than just saying "try a different
libdbi version".



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Splitting the slots table

[Jeff Kletsky]

John Ralls writes:

"I think that the first step is to work through all of the code and make 
an ERD for the existing model, documenting the use and structure of KVP. 
(Pretend for the purpose of this exercise that every use of KVP is a 
separate entity). Then we can normalize it into a good relational model 
and work out a transition path."


This, to my ears, is great news!

Getting the code objects to more closely agree with business objects and 
the database representation of those objects to more closely represent 
the structure of the objects is a valuable step in a direction that, in 
my opinion means:


* A more comprehensible and testable code base -- which indirectly means 
that becoming a contributor is a lot easier
* A database structure that allows the SQL layer to optimise queries, 
rather than having all kinds of "custom" search/select logic in the code

* A database structure that reports can be generated against
* A database structure that can allow multi-user access (be it exclusive 
or opportunistic locking of objects, rather than the whole database)


To me, this is a critical "next step" even if/when the languages of 
choice are changed.


Perhaps another topic that will need to be discussed is the "end-user 
contract." As I understand it, previously it was "A data file from 
version Y will be usable an older version X, although all data may not 
be understood." To me, that sort of locks one in the past (case in 
point, budgets, which have some significant structural problems right 
now, such as being unaware of the difference between data-storage sign 
and UI sign). The "way around" that, as I understand it, is to stuff 
anything new into KVPs, which, as John points out, doesn't work well 
with relational databases.


I think it is reasonable to:

1) Restrict any major non-backwards-compatible-for-read changes to 
objects or database representation to major releases (2.4, 2.6,...) -- 
Namely reporting and data-extraction tools that work against the 
database for 2.4.0 should work for 2.4.x without changes


2) Require database upgrade triggers to be run for any release, major or 
minor -- This means that once you upgrade to Version Y, you're done with 
Version X


3) Violate "Rule 1" when "critical bugs" related to data integrity or 
security dictate


4) Drop XML file support -- If people want a lightweight, single-file 
transport/backup approach, then SQLite is a great option. (Without this, 
GNUCash is either just using the database as a data store, or would need 
to maintain two versions of search/select logic.)


Part of the proposed end-user contract is that the end user "must" only 
use the matching version of the app to /write/ to the database. However, 
they may use other apps to /read/ from it for their own needs.


Yes, "Rule 2" means that you need to decide which releases you are going 
to take and that adoption of the "latest and greatest" may be a bit 
slower. It also means that code and data structures can be refactored as 
appropriate. In the widely-used Open-Source world, Wordpress does this 
with great success. My "day job" is administration and billing systems 
for large insurance carriers and this approach works for them as well.




On 01/02/2011 05:23 PM, John Ralls wrote:

[...]
We need to re-think KVP entirely: It doesn't match up very well with the 
relational model.

A couple of examples:

Splits use KVP to store memos. Good, because not everyone uses them on every 
split, and there's no point wasting the space. But we can provide a split-memo 
table with a foreign key into the splits table (or vice-versa). That will be 
much faster to query (no WHERE name= clause in the join) and the data design 
will be clearer.

The HBCI (online banking) setup, on the other hand, is contained entirely in a 
hierarchy of KVPs. This makes some amount of sense in XML, but it's insane in 
an RDB. RDBs don't like recursion, and there's no way to do arbitrary 
hierarchies without recursion. HBCI needs its own tables.

I think that the first step is to work through all of the code and make an ERD 
for the existing model, documenting the use and structure of KVP. (Pretend for 
the purpose of this exercise that every use of KVP is a separate entity). Then 
we can normalize it into a good relational model and work out a transition path.

I have some more Gtk stuff to do over the next couple of weeks, but I'll start 
on the ERD after that.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: 2.4 and sqlite...

[Jeff Kletsky]

It isn't just numbers that have problems -- here's a diff of Ubuntu 
10.10 and FreeBSD output from the driver test code distributed with source


The Ubuntu bug #673307 link is 
https://bugs.launchpad.net/ubuntu/+source/libdbi-drivers/+bug/673307





j...@fx:~$ diff -u test_dbi.output*
--- test_dbi.output 2011-01-01 10:42:03.707828037 -0800
+++ test_dbi.output.freebsd 2011-01-01 10:43:55.856451151 -0800
@@ -2,15 +2,15 @@
 Driver information:
 ---
  Name: sqlite3
- Filename: /usr/lib/dbd/libdbdsqlite3.so
+ Filename: /usr/local/lib/dbd/libdbdsqlite3.so
  Desc: SQLite3 database support (using libsqlite3)
  Maintainer: Markus Hoenicka 
  URL: http://libdbi-drivers.sourceforge.net 
<http://libdbi-drivers.sourceforge.net>

  Version: dbd_sqlite3 v0.8.3-1
- Compiled: Aug 7 2010
+ Compiled: Jan 1 2011

 Successfully connected!
- Using database engine version 30702 (numeric) and 3.7.2 (string)
+ Using database engine version 30704 (numeric) and 3.7.4 (string)

 Test 1: List databases:
  Got result, try to access rows
@@ -47,10 +47,10 @@
 the_ushort: in:32767 out:32767<<
 the_long: in:-2147483648 out:-2147483648<<
 the_ulong: in:2147483647 out:2147483647<<
-the_longlong: in:-9223372036854775807 out:0<<
-the_ulonglong: in:9223372036854775807 out:0<<
+the_longlong: in:-9223372036854775807 out:-9223372036854775807<<
+the_ulonglong: in:9223372036854775807 out:9223372036854775807<<
 the_float: in:3.402823466E+38 out:3.402823e+38<<
-the_double: in:1.7976931348623157E+307 out:0.00e+00<<
+the_double: in:1.7976931348623157E+307 out:1.797693e+307<<
 the_driver_string: in:'Can 'we' "quote" this properly?' out:'Can 'we' 
"quote" this properly?'<<
 the_quoted_string: in:'Can 'we' "quote" this properly?' out:'Can 'we' 
"quote" this properly?'<<
 the_quoted_string_copy: in:'Can 'we' "quote" this properly?' out:'Can 
'we' "quote" this properly?'<<

@@ -58,11 +58,11 @@
 the_escaped_string_copy: in:'Can 'we' "escape" this properly?' 
out:'Can 'we' "escape" this properly?'<<

 the_empty_string: out:''<<
 the_null_string: out:'(null)'
-the_datetime: in:'2001-12-31 23:59:59' out:2001-12-31 0:0:0
-the_datetime_tz: in:'2001-12-31 23:59:59 -10:00' out:2001-12-31 0:0:0
+the_datetime: in:'2001-12-31 23:59:59' out:2001-12-31 23:59:59
+the_datetime_tz: in:'2001-12-31 23:59:59 -10:00' out:2002-1-1 9:59:59
 the_date: in:'2001-12-31' out:2001-12-31
-the_time: in:'23:59:59' out:0:0:0
-the_time_tz: in:'23:59:59-10:00' out:0:0:0
+the_time: in:'23:59:59' out:23:59:59
+the_time_tz: in:'23:59:59-10:00' out:9:59:59
 the_quoted_binary: in: 65-66-0-67-39-68- out: 65-66-0-67-39-68-<<
 the_escaped_binary_copy: in: 65-66-0-67-39-68- out: 65-66-0-67-39-68-<<



On 01/01/2011 11:48 AM, John Gray wrote:

Same here, rebuilding libdbd-sqlite3 didn't fix the problem, and libdbi
isn't building.

how frustrating.

John

On 01/01/2011 12:58 PM, Jeff Kletsky wrote:

It does look to be the same issue with libdbi/libdbd. Recompiling and
installing libdbd-sqlite3 hasn't resolved the problem, and I'm having
problems with recompiling libdbi (openjade is croaking on the doc
generation) to determine if that will resolve it.

If anyone knows how to resolve the openjade problem, I'd like to be
able to confirm that removing the -ffast-math optimisation "fixes"
GNUCash and SQLite3.

I hope we can get a more generic illustration of the problem because,
as it is reported now, my guess is that it won't get much attention.
It is a little surprising to me that GNUCash is the only app running
into problems with this. Unfortunately Perl links to libsqlite3 and
I'm guessing that the Mozilla products carry their own set of
libraries, so it may need a "simple" C program to show that this is a
"generic" problem.

Jeff




On 12/31/2010 06:36 PM, John Ralls wrote:

On Dec 31, 2010, at 5:18 PM, Derek Atkins wrote:


Er.. check the archives and look for fastmath, iirc.


To save you the trouble:
https://bugzilla.gnome.org/show_bug.cgi?id=611936#c28
https://lists.gnucash.org/pipermail/gnucash-devel/2010-August/029141.html


Jeff Kletsky has opened a new Gnucash bug for this:
https://bugzilla.gnome.org/show_bug.cgi?id=638414

Good memory, Derek.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: 2.4 and sqlite...

[Jeff Kletsky]

It does look to be the same issue with libdbi/libdbd. Recompiling and 
installing libdbd-sqlite3 hasn't resolved the problem, and I'm having 
problems with recompiling libdbi (openjade is croaking on the doc 
generation) to determine if that will resolve it.


If anyone knows how to resolve the openjade problem, I'd like to be able 
to confirm that removing the -ffast-math optimisation "fixes" GNUCash 
and SQLite3.


I hope we can get a more generic illustration of the problem because, as 
it is reported now, my guess is that it won't get much attention. It is 
a little surprising to me that GNUCash is the only app running into 
problems with this. Unfortunately Perl links to libsqlite3 and I'm 
guessing that the Mozilla products carry their own set of libraries, so 
it may need a "simple" C program to show that this is a "generic" problem.


Jeff




On 12/31/2010 06:36 PM, John Ralls wrote:

On Dec 31, 2010, at 5:18 PM, Derek Atkins wrote:


Er.. check the archives and look for fastmath, iirc.


To save you the trouble:
https://bugzilla.gnome.org/show_bug.cgi?id=611936#c28
https://lists.gnucash.org/pipermail/gnucash-devel/2010-August/029141.html

Jeff Kletsky has opened a new Gnucash bug for this:
https://bugzilla.gnome.org/show_bug.cgi?id=638414

Good memory, Derek.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: 2.4 and sqlite...

[Jeff Kletsky]

I'm seeing data corruption under Ubuntu 10.10 and SQLite3 on builds from 
tag 2.4.0 -- in my case budgets are unable to display their values 
properly. I'm not seeing that using MySQL 5.1 on the same system.


If http://wiki.gnucash.org/wiki/Release_Schedule is still current, then 
I wouldn't be surprised if there are SQLite3 issues in general.


   SQL (dbi) backend with SQLite3 Generally: Still occasional reports
   about data parts which disappear when saving into sqlite, e.g.
   #627831 ;
   Database lock still needed
   ;
   Linux: #611936 ,
   OSX: Stable



Jeff


On 12/31/2010 01:51 PM, John Gray wrote:

This morning I built 2.4 from source on an x64 Ubuntu 10.10 box.  I read
in the xml file and wrote out a sqlite file.  Everything seemed to work
fine.

Then I built 2.4 on a x86 Ubuntu 10.10 box, and it doesn't display any
data when reading in a sqlite file.  Not the one generated on the x64
box, or a fresh one generated from the xml.

I talked someone else today who was seeing this too.

We are the guys working on a version for android.  Looks like sqlite
will be much easier to deal with under android, but its not helpful if
it doesn't work reliably on our desktops.

Speaking of the android implementation, can anybody tell me what the
Collation on the sqlite data is? I have android reading in the sqlite,
but something isn't just right, I suspect its a collation mismatch.  Is
it unicode?  utf8 maybe?

Thanks,
John
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Can't find slib?

[Jeff Kletsky]

Some hints on Slackware at 
http://www.linuxquestions.org/questions/slackware-14/gnucash-guile-slib-dont-get-along-848185/


   Look in the directory /var/log/scripts for the file starting with
   slib. What happens if you run the first line in that file as root on
   your machine?

   On mine (Slackware64 13.1), that file (slib-3b2-x86_64-2_SBo)
   contains...

   Code:

   #!/bin/sh

   guile -q -s /usr/doc/slib-3b2/guile-slibcat.script

   ( cd usr/lib64/slib ; rm -rf mklibcat )
   ( cd usr/lib64/slib ; ln -sf mklibcat.scm mklibcat )
   ( cd usr/share/guile ; rm -rf slib )
   ( cd usr/share/guile ; ln -sf ../../lib64/slib slib )
   ( cd usr/share ; rm -rf slib )
   ( cd usr/share ; ln -sf ../lib64/slib slib )

   ...and I would want you to run the equivalent of the...
   Code:

   guile -q -s /usr/doc/slib-3b2/guile-slibcat.script


I haven't found the equivalent on Ubuntu 10.10 yet (or even the 
guile-slibcat.script file).


It looks like this kind of thing has been a problem going back as far as 
2005, if not earlier http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=328243


The closest I can find under Ubuntu 10.10 is

j...@fx:/var/lib/dpkg/info$ cat slib.postinst
#!/bin/sh

set -e

# OK.  This is bad because it really should be in the guile config or
# in some emacs-common sort of package.  Now we conditionally run it.
# one of these probably shouldn't exist, but don't know which and
# probably should support the older.

if [ -x /usr/sbin/guile1.4-slibconfig ] ; then
echo guile1.4-slibconfig
guile1.4-slibconfig
fi

if [ -x /usr/bin/guile-1.6 -a -e /usr/share/guile/1.6/slib ] ; then
rm -f /usr/share/guile/1.6/slibcat

guile-1.6 -c "(use-modules (ice-9 slib)) (require 'new-catalog)"

if [ -e /usr/share/guile/1.6/slibcat ] ; then
  chmod 644 /usr/share/guile/1.6/slibcat
fi
fi

if [ -x /usr/bin/scm ] ; then
rm -f /usr/lib/scm/slibcat
scm -c "(require 'new-catalog)"

if [ -e /usr/lib/scm/slibcat ] ; then
  chmod 644 /usr/lib/scm/slibcat
fi
fi

Running this as root doesn't help --HOWEVER -- this works

$ *sudo ln -s  /usr/share/slib /usr/share/guile/slib*  # This symlink 
still appears to be needed


$ guile --version
Guile 1.8.7
Copyright (c) 1995, 1996, 1997, 2000, 2001, 2002, 2003, 2004, 2005, 
2006, 2007, 2008 Free Software Foundation

Guile may be distributed under the terms of the GNU General Public Licence;
certain other uses are permitted as well.  For details, see the file
`COPYING', which is included in the Guile distribution.
There is no warranty, to the extent permitted by law.

$ guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)"   # Have 
to be root, apparently

ERROR: In procedure open-file:
ERROR: Permission denied: "/usr/share/guile/1.8/slibcat"

$ *sudo guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)"*

$ ls -l /usr/share/guile/1.8/slibcat
-rw-r--r-- 1 root root 8682 2010-12-30 12:09 
/usr/share/guile/1.8/slibcat  # Already 644, so no chmod needed in this case


$ guile -c "(use-modules (ice-9 slib)) (require 'printf)"
(works)






Jeff


On 12/12/2010 07:46 AM, Donald Allen wrote:

On Sun, Dec 12, 2010 at 10:27 AM, Derek Atkins  wrote:


On Sat, December 11, 2010 11:32 pm, Donald Allen wrote:

  Normally your distribution would do this for you, but as you're running
Slackware all bets are off and I'm afraid you're on your own.

  If you were

running Fedora or Ubuntu it would "just work".


[...]

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Can't find slib?

[Jeff Kletsky]

slib isn't functional for GNUCash under Ubuntu 10.10 and the current 
build of guile -- there just isn't a version of slibcat there that I can 
find to symlink to.


Suggestions? I'd really like to get this to work with the current 
versions of guile.


Thanks,

Jeff


j...@fx:/usr/local/src/gnucash-2.4.0/svn-2.4.0$ sudo apt-get install 
guile-1.8 slib

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  guile-1.8-libs
Suggested packages:
  guile-1.8-doc
The following NEW packages will be installed:
  guile-1.8 guile-1.8-libs slib
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 731kB/1,697kB of archives.
After this operation, 7,410kB of additional disk space will be used.
Do you want to continue [Y/n]?
Get:1 http://us.archive.ubuntu.com/ubuntu/ maverick/main guile-1.8-libs 
i386 1.8.7+1-3ubuntu2 [719kB]
Get:2 http://us.archive.ubuntu.com/ubuntu/ maverick/main guile-1.8 i386 
1.8.7+1-3ubuntu2 [11.9kB]

Fetched 731kB in 2s (318kB/s)
Selecting previously deselected package guile-1.8-libs.
(Reading database ... 208421 files and directories currently installed.)
Unpacking guile-1.8-libs (from 
.../guile-1.8-libs_1.8.7+1-3ubuntu2_i386.deb) ...

Selecting previously deselected package guile-1.8.
Unpacking guile-1.8 (from .../guile-1.8_1.8.7+1-3ubuntu2_i386.deb) ...
Selecting previously deselected package slib.
Unpacking slib (from .../archives/slib_3b1-3.1_all.deb) ...
Processing triggers for man-db ...
Processing triggers for menu ...
Processing triggers for doc-base ...
Processing 1 added doc-base file(s)...
Registering documents with scrollkeeper...
Processing triggers for install-info ...
Setting up guile-1.8-libs (1.8.7+1-3ubuntu2) ...
Setting up guile-1.8 (1.8.7+1-3ubuntu2) ...
update-alternatives: using /usr/bin/guile-1.8 to provide /usr/bin/guile 
(guile) in auto mode.

Setting up slib (3b1-3.1) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Processing triggers for menu ...

j...@fx:/usr/local/src/gnucash-2.4.0/svn-2.4.0$ guile -c "(use-modules 
(ice-9 slib)) (require 'printf)"

ERROR: In procedure open-file:
ERROR: Permission denied: "/usr/share/guile/1.8/slibcat"

j...@fx:/usr/local/src/gnucash-2.4.0/svn-2.4.0$ sudo ls -l 
/usr/share/guile/1.8/slibcat

ls: cannot access /usr/share/guile/1.8/slibcat: No such file or directory

j...@fx:/usr/local/src/gnucash-2.4.0/svn-2.4.0$ sudo find /usr -name 
'slibcat'

j...@fx:/usr/local/src/gnucash-2.4.0/svn-2.4.0$



On 12/12/2010 07:27 AM, Derek Atkins wrote:

[...]q NM
It does.  On Fedora and on Ubuntu, the slib package comes pre-configured
with a working slibcat file that gets created as part of the package
installation.  I'm not sure if it's created when the package is built or
when the package is installed, but the end result is the same, a working
slibcat when you install the slib package.

-derek




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Translatable strings in .h file -- best way to resolve?

[Jeff Kletsky]

On 3/18/2010 8:04 AM, Derek Atkins wrote:

Jeff Kletsky  writes:

   

So then when I submit a patch for things like src/business/business-utils/
business-utils.scm -- the existing usages of (N_ "some string") probably
should be converted to (_ "some string") -- correct? I was puzzled by that as,
at least as I understand it, in C N_(string) is a noop marker and _() is the
gettext () call.
 

N_ is a noop marker in both C and Scheme
_ is the gettext call in both C and Scheme
Where you place the paren is based on the language.

   

(define gnc:*business-label* (N_ "Business"))
(define gnc:*company-name* (N_ "Company Name"))
(define gnc:*company-addy* (N_ "Company Address"))
(define gnc:*company-id* (N_ "Company ID"))
(define gnc:*company-phone* (N_ "Company Phone Number"))
(define gnc:*company-fax* (N_ "Company Fax Number"))
(define gnc:*company-url* (N_ "Company Website URL"))
(define gnc:*company-email* (N_ "Company Email Address"))
(define gnc:*company-contact* (N_ "Company Contact Person"))
 

These are fine here because these string constants are defined in
Scheme.  This would be a no-op, so it would mark these strings
are translatable but wouldn't translate them immediately.  This
is important if you want to use them as a key to a database entry (which
should always use the untranslated string) but also put it in the UI
(which should always use the translated string).

   

(export gnc:*business-label* gnc:*company-name* gnc:*company-addy*
gnc:*company-id*
 gnc:*company-phone* gnc:*company-fax* gnc:*company-url*
 gnc:*company-email* gnc:*company-contact*)

(define gnc:*option-section-accounts* (_ OPTION-SECTION-ACCOUNTS))
(define gnc:*option-name-trading-accounts* (_ OPTION-NAME-TRADING-ACCOUNTS))

(export gnc:*option-section-accounts* gnc:*option-name-trading-accounts*)

(define gnc:*option-section-budgeting* (_ OPTION-SECTION-BUDGETING))
(define gnc:*option-name-default-budget* (_ OPTION-NAME-DEFAULT-BUDGET))

(export gnc:*option-section-budgeting* gnc:*option-name-default-budget*)
 

These calls would define these options as the translated versions of
these strings.  I'm not sure this is correct.  So long as the OPTION
strings are defined as N_ in the C code you don't need to translate them
here unless you ONLY want access to the translated version of the
string.

-derek

   


Ah, I didn't realize that the translation was being handled 
transparently in the rendering layer. It was really bothering me that 
the KVP keys seemed to be language-dependent. Looking at 
src/gnome-utils/dialog-options.c a little more carefully I now see 
constructs like _(*raw), _(label), and _(description) sprinkled in there.


Thanks to all for helping me through my first shot at Gnu-style i18n.

Jeff

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Translatable strings in .h file -- best way to resolve?

[Jeff Kletsky]

Derek Atkins wrote:

Jeff Kletsky  writes:

[snip]
  

#define OPTION_SECTION_ACCOUNTSN_("Accounts")
#define OPTION_NAME_TRADING_ACCOUNTS   N_("Trading Accounts")

#define OPTION_SECTION_BUDGETING   N_("Budgeting")
#define OPTION_NAME_DEFAULT_BUDGET N_("Default Budget")



We should absolutely use N_() in the header files here (with your
included SWIG fix).  And then use _() in the .c and (_ ) in the scheme
files as necessary.

Doing:

(N_ OPTOIN-SECTION-ACCOUNTS) in the scheme is just... wrong.

-derek

  


So then when I submit a patch for things like 
src/business/business-utils/business-utils.scm -- the existing usages of 
(N_ "some string") probably should be converted to (_ "some string") -- 
correct? I was puzzled by that as, at least as I understand it, in C 
N_(string) is a noop marker and _() is the gettext () call.


(define gnc:*business-label* (N_ "Business"))
(define gnc:*company-name* (N_ "Company Name"))
(define gnc:*company-addy* (N_ "Company Address"))
(define gnc:*company-id* (N_ "Company ID"))
(define gnc:*company-phone* (N_ "Company Phone Number"))
(define gnc:*company-fax* (N_ "Company Fax Number"))
(define gnc:*company-url* (N_ "Company Website URL"))
(define gnc:*company-email* (N_ "Company Email Address"))
(define gnc:*company-contact* (N_ "Company Contact Person"))

(export gnc:*business-label* gnc:*company-name* gnc:*company-addy* 
gnc:*company-id*

   gnc:*company-phone* gnc:*company-fax* gnc:*company-url*
   gnc:*company-email* gnc:*company-contact*)

(define gnc:*option-section-accounts* (_ OPTION-SECTION-ACCOUNTS))
(define gnc:*option-name-trading-accounts* (_ OPTION-NAME-TRADING-ACCOUNTS))

(export gnc:*option-section-accounts* gnc:*option-name-trading-accounts*)

(define gnc:*option-section-budgeting* (_ OPTION-SECTION-BUDGETING))
(define gnc:*option-name-default-budget* (_ OPTION-NAME-DEFAULT-BUDGET))

(export gnc:*option-section-budgeting* gnc:*option-name-default-budget*)

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Translatable strings in .h file -- best way to resolve?

[Jeff Kletsky]

Mike Alexander wrote:
--On March 16, 2010 10:17:37 AM +0100 Christian Stimming 
 wrote:



Zitat von Jeff Kletsky :

#define ACCOUNT_OPTIONS_SECTION "Accounts"
#define TRADING_ACCOUNTS_OPTION "Trading Accounts"

Presently, make-gnucash-potfiles.in does not look at .h files for
translatable strings, so even after adding
#include 
and marking the strings, they don't make it into POTFILES.in

What approach is recommended for resolving this?

* Add an exception to make-gnucash-potfiles.in


Yes.


* Use _(ACCOUNTS_OPTIONS_SECTION) and don't translate the raw define


Yes. In the #define lines, the strings should be marked with the N_(
... ) macro, so they are still just a const char* literal for the
compiler's point of view, but they make it into gnucash.pot:

#include 
#define ACCOUNT_OPTIONS_SECTION N_("Accounts")

Subsequently, in places where the defines are being used for
human-visible display, they need to be translated writing
_(ACCOUNTS_OPTIONS_SECTION).


* Change .h to .c and leave people wondering why a .c file is being
#include-d


No.



This is my fault.  These #defines are used in two places.  One is 
qofbook.c where they are used to access the slot holding the value of 
this option.  These should, of course, not be translated.  The other 
is in business-prefs.scm where they are used as the section and name 
parameters to gnc:make-simple-boolean-option.  The other calls to 
gnc:make-...-option in this file use (N_ ...) for the name and section 
parameters.  These parameters are used for both slot access and for 
the UI.  There must be some special magic to cause them to be 
translated for the one case and not the other.


I think the correct fix is to leave the #defines alone (the C code 
only uses these for slot access) and change the two lines in 
business-utils.scm to read


(define gnc:*book-label* (N_ ACCOUNT-OPTIONS-SECTION))
(define gnc:*trading-accounts* (N_ TRADING-ACCOUNTS-OPTION))

Unfortunately I've been out of town for the last month and I need to 
do a bunch of updating and building before I can test this fix.  
However it makes things consistent with the other constants defined in 
business-utils.scm and used in business-prefs.scm so it may be ok.


It would probably also be ok to include the N_(...) on the #defines 
but doing it like I describe would be more consistent with the other 
strings used in business-prefs.scm.


I think things do mostly work the way they are, except that the 
strings probably aren't marked for translation as they should be.  
When I added this code I tested it by adding a fake translation for 
"Trading Accounts" and it showed up in the UI.


This is all very confusing to me.  All of the calls to 
gnc:make-...-option use (N_ ...) for the section, name, and 
description parameters, but somehow they get translated anyway.  I 
think I tracked this down once, but I've forgotten how it works now.


 Mike
 


I've got it running here (though have yet to confirm translation works) 
-- the last little trick was to get Swig to recognize the #define 
N_("some string to be translated") construct so that the variable would 
be created in the Guile side of the house. (I also changed to 
KVP_OPTIONS_PATH to be more consistent with usage elsewhere in the code, 
as well as a naming convention for the section/option that was a little 
more understandable to me when extended.)




#ifndef SWIG /* swig doesn't see N_() as a string constant */
#include 
#else
#define N_(string) string
#endif

[...]

#define KVP_OPTION_PATH  "options"

/*
* Various option sections and options within those sections
*
* At least through 2.3.10, the key and the display string are tied,
* coupling the data with its representation in the UI
* and is not locale-independent (translated strings used as keys)
*/

#define OPTION_SECTION_ACCOUNTSN_("Accounts")
#define OPTION_NAME_TRADING_ACCOUNTS   N_("Trading Accounts")

#define OPTION_SECTION_BUDGETING   N_("Budgeting")
#define OPTION_NAME_DEFAULT_BUDGET N_("Default Budget")


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Better name for "Accounts" tab and "Trading Accounts" option?

[Jeff Kletsky]

I've been poking around with setting a default budget and find myself in 
qofbookslots.h which was apparently introduced for


which, at least as I understand it, implements "trading accounts" to 
handle multi-currency and multi-commodity transactions. I've been able 
to mainly resolve the swig-guile-gettext interactions related to getting 
the strings to translate, which I'm hoping to get in with some of the 
default-budget changes here in a couple days.


There is further discussion as well at 



The option appears in the book-level preferences, along with the 
business-related fields. Right now, the tab is labeled "Accounts" with 
"Trading Accounts" (as the only option so far) which left me puzzled. 
Any better suggestions for these?


Now would be the time to make them, since they end up being both UI 
strings, as well as the keys for the KVP data, so, once set, shouldn't 
be changed (until there is some future support for decoupling the UI 
label from the data key).


"Multi-Currency"
"Use trading accounts"

or

"Multi-Commodity"
"Use trading accounts"

make a little more sense to me, but even "Multi-Currency" is a tad long 
(but do-able). Setting the tab label to something somewhat generic 
provides a place for future book-level preferences that are related.



Suggestions welcomed,

Jeff





___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Translatable strings in .h file -- best way to resolve?

[Jeff Kletsky]

In src/libqof/qof/qofbookslots.h



two #define statements were added

#define ACCOUNT_OPTIONS_SECTION "Accounts"
#define TRADING_ACCOUNTS_OPTION "Trading Accounts"

which need to be translatable (they are the option section and option 
name for Guile-driven options screens, so the are not only keys to the 
options KVP, but also rendered in the UI as the title on the tab and the 
name of the option). These are a bit funky as they are needed both in 
the C and the Guile world.


Presently, make-gnucash-potfiles.in does not look at .h files for 
translatable strings, so even after adding

#include 
and marking the strings, they don't make it into POTFILES.in

What approach is recommended for resolving this?

* Add an exception to make-gnucash-potfiles.in
* Use _(ACCOUNTS_OPTIONS_SECTION) and don't translate the raw define
* Change .h to .c and leave people wondering why a .c file is being 
#include-d

* Do something else I haven't thought of in a .c file

The first seems the cleanest, the second has the "advantage" of alerting 
later coders that this really isn't a constant across all locales.


Suggestions from the maintainers on coding style for this would be 
greatly appreciated.


-Jeff

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Possible to start Guile interactive debugger from running code?

[Jeff Kletsky]

gdb works well at letting me poke around in the C portions of the code, 
but, not unexpectedly, doesn't seem to be able to let me do the same for 
Guile.


I'm aware of (display foo) as well as (gnc:debug more-foo), but is there 
a way that an interactive Guile debugger can be invoked from the running 
Guile code?


-Jeff

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Unpredictable make -- possibly related to intl-scm/guile-strings.c

[Jeff Kletsky]

On 3/11/2010 2:32 AM, Christian Stimming wrote:

Zitat von Jeff Kletsky :

I can, for example,
[...]
4) Checkout edd8b26 and have it work (as it should)
5) Checkout df0f85d and have it work (which it does NOT if built in a 
"fresh" directory)


From what I can tell, the only file different in the source tree 
between (1) and (3) in this case was intl-scm/guile-strings.c


I also do not have any idea what this behavior might be caused by. But 
the file intl-scm/guile-strings.c has clearly no implication on the 
build and the resulting binaries whatsoever - instead, the content of 
that file is used solely when running "make pot" and generating a new 
translation template (which is subsequently merged with the currently 
existing translation po files). In all other cases the content of that 
file is ignored completely.


Do you run make with the -j switch, hence using multiple jobs in 
parallel? If you do, I'm not sure whether this is implemented 
correctly everywhere.


Regards,

Christian


Based on a suggestion from Derek, it looks like it is related to swig 
not always being run.


My current work-around is

find path/to/source/ -name '*.i' -exec touch '{}' \;

Thanks for thinking about this one!

Jeff
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Unpredictable make -- possibly related to intl-scm/guile-strings.c

[Jeff Kletsky]

This pretty much looks like a build system problem:

# Clean everything out
# the build directory

rm -rf gnucash-build/
mkdir gnucash-build

# and the working repository

cd gnucash-devel/
rm -rf *
rm .gitignore

# Get the "good" version, totally fresh

git checkout edd8b26
git reset --hard

# Build the good version

./autogen.sh
cd ../gnucash-build/
cat /home/jeff/test-builds/test_build.sh
../configure --enable-ofx --enable-aqbanking --prefix=/opt/gnucash 
--with-html-engine=webkit
../gnucash-devel/configure --enable-ofx --enable-aqbanking 
--prefix=/opt/gnucash --with-html-engine=webkit

make -j4
make install

# try the good version -- it is good

/opt/gnucash/bin/gnucash --nofile

# Ok, check out the "broken" version

cd ../gnucash-devel/
git checkout df0f85d

# Build the broken version

cd ../gnucash-build/
../gnucash-devel/configure --enable-ofx --enable-aqbanking 
--prefix=/opt/gnucash --with-html-engine=webkit

make clean
make -j4
make install

# Though it shouldn't, it tests out "good"

/opt/gnucash/bin/gnucash --nofile

# Nail-in-the-coffin -- build from exactly the same source, but from a 
different build directory


cd ..
mkdir gnucash-build2
cd gnucash-build2/
../gnucash-devel/configure --enable-ofx --enable-aqbanking 
--prefix=/opt/gnucash --with-html-engine=webkit

make clean
make -j4
make install

# and, when built from the different directory, it fails, as it "should"

/opt/gnucash/bin/gnucash --nofile


Jeff Kletsky wrote:
I've been running in circles for the last several days with a problem 
that manifests itself when, from what I can tell, the code in engine.i 
tries to create Guile variables using the SET_ENUM construct. The 
console, in my case, reports


Backtrace:
In current input:
1: 0* (set! OPTION-SECTION-ACCOUNTS (OPTION-SECTION-ACCOUNTS))

:1:1: In expression (set! OPTION-SECTION-ACCOUNTS 
(OPTION-SECTION-ACCOUNTS)):

:1:1: Unbound variable: OPTION-SECTION-ACCOUNTS


This has been especially hard to track down as the order of compiling 
different (git) checkouts of the source code changes the result.


I don't know if it is a git/make problem, or something not quite right 
in the GNUCash build process.


I can, for example,
0) Run some builds
1) Checkout df0f85d and have it work
2) Checkout 8b062ba and have it fail
3) Checkout df0f85d (again) and have it fail this time

or

4) Checkout edd8b26 and have it work (as it should)
5) Checkout df0f85d and have it work (which it does NOT if built in a 
"fresh" directory)


From what I can tell, the only file different in the source tree 
between (1) and (3) in this case was intl-scm/guile-strings.c


Compilation is being done out of a different directory than where the 
source resides.


I've confirmed that df0f85d is "bad" by checking it out into a clean 
directory and compiling it either there, or in another build directory.


I've tried:
* make clean
* removing the install target directories
* re-running configure

The non-comment differences between edd8b26 and df0f85d are:

diff --git a/src/libqof/qof/qofbookslots.h 
b/src/libqof/qof/qofbookslots.h

index d01d10b..93287eb 100644
--- a/src/libqof/qof/qofbookslots.h
+++ b/src/libqof/qof/qofbookslots.h

+#include 
-#define KVP_OPTION_PATH "options"
-#define OPTION_SECTION_ACCOUNTS "Accounts"
-#define OPTION_NAME_TRADING_ACCOUNTS "Trading Accounts"
+#define KVP_OPTION_PATH  "options"
+#define OPTION_SECTION_ACCOUNTS_("Accounts")
+#define OPTION_NAME_TRADING_ACCOUNTS   _("Trading Accounts")


There doesn't seem to be any significant differences in the source 
directories between "wrongly working" df0f85d and "properly failing" 
df0f85d:


j...@fx:~$ diff -rq state.16/gnucash-devel/ state.17/should-be-bad/
Files state.16/gnucash-devel/src/doc/design/gnucash-design.info and 
state.17/should-be-bad/src/doc/design/gnucash-design.info differ
Files state.16/gnucash-devel/src/doc/design/stamp-vti and 
state.17/should-be-bad/src/doc/design/stamp-vti differ
Files state.16/gnucash-devel/src/doc/design/version.texi and 
state.17/should-be-bad/src/doc/design/version.texi differ


I'm thinking that something isn't right in the build process, probably 
related to the generation of Guile-related translations.


Does this sound familiar to anyone?

I'd rather not have to do a fresh checkout and compile every time I 
take a step forward.




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Unpredictable make -- possibly related to intl-scm/guile-strings.c

[Jeff Kletsky]

I've been running in circles for the last several days with a problem 
that manifests itself when, from what I can tell, the code in engine.i 
tries to create Guile variables using the SET_ENUM construct. The 
console, in my case, reports


Backtrace:
In current input:
1: 0* (set! OPTION-SECTION-ACCOUNTS (OPTION-SECTION-ACCOUNTS))

:1:1: In expression (set! OPTION-SECTION-ACCOUNTS 
(OPTION-SECTION-ACCOUNTS)):

:1:1: Unbound variable: OPTION-SECTION-ACCOUNTS


This has been especially hard to track down as the order of compiling 
different (git) checkouts of the source code changes the result.


I don't know if it is a git/make problem, or something not quite right 
in the GNUCash build process.


I can, for example,
0) Run some builds
1) Checkout df0f85d and have it work
2) Checkout 8b062ba and have it fail
3) Checkout df0f85d (again) and have it fail this time

or

4) Checkout edd8b26 and have it work (as it should)
5) Checkout df0f85d and have it work (which it does NOT if built in a 
"fresh" directory)


From what I can tell, the only file different in the source tree 
between (1) and (3) in this case was intl-scm/guile-strings.c


Compilation is being done out of a different directory than where the 
source resides.


I've confirmed that df0f85d is "bad" by checking it out into a clean 
directory and compiling it either there, or in another build directory.


I've tried:
* make clean
* removing the install target directories
* re-running configure

The non-comment differences between edd8b26 and df0f85d are:

diff --git a/src/libqof/qof/qofbookslots.h b/src/libqof/qof/qofbookslots.h
index d01d10b..93287eb 100644
--- a/src/libqof/qof/qofbookslots.h
+++ b/src/libqof/qof/qofbookslots.h

+#include 
-#define KVP_OPTION_PATH "options"
-#define OPTION_SECTION_ACCOUNTS "Accounts"
-#define OPTION_NAME_TRADING_ACCOUNTS "Trading Accounts"
+#define KVP_OPTION_PATH  "options"
+#define OPTION_SECTION_ACCOUNTS_("Accounts")
+#define OPTION_NAME_TRADING_ACCOUNTS   _("Trading Accounts")


There doesn't seem to be any significant differences in the source 
directories between "wrongly working" df0f85d and "properly failing" 
df0f85d:


j...@fx:~$ diff -rq state.16/gnucash-devel/ state.17/should-be-bad/
Files state.16/gnucash-devel/src/doc/design/gnucash-design.info and 
state.17/should-be-bad/src/doc/design/gnucash-design.info differ
Files state.16/gnucash-devel/src/doc/design/stamp-vti and 
state.17/should-be-bad/src/doc/design/stamp-vti differ
Files state.16/gnucash-devel/src/doc/design/version.texi and 
state.17/should-be-bad/src/doc/design/version.texi differ


I'm thinking that something isn't right in the build process, probably 
related to the generation of Guile-related translations.


Does this sound familiar to anyone?

I'd rather not have to do a fresh checkout and compile every time I take 
a step forward.




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Running automated or unit tests?

[Jeff Kletsky]

On 3/8/2010 4:59 PM, Jeff Kletsky wrote:
Maybe I'm blind, but I'm not seeing how to run unit/automated testing 
(or how to add more unit tests to the quite).


Would someone point me in the right direction so I can be more 
confident I'm not breaking things?


-j


make check??

The following Q&D patch (and similar to test-resolve-url.c) will fix the 
compile breakage, but looks like the WIP related to r18842 needs to 
complete before they pass.


diff --git a/src/core-utils/test/test-resolve-file-path.c 
b/src/core-utils/test/test-resolve-file-path.c

index 8d89a3b..b6503a4 100644
--- a/src/core-utils/test/test-resolve-file-path.c
+++ b/src/core-utils/test/test-resolve-file-path.c
@@ -104,7 +104,7 @@ main(int argc, char **argv)
 wantout = g_strdup(strs[i].output);
 }

-daout = xaccResolveFilePath(dain);
+daout = gnc_resolve_file_path(dain);
 do_test_args(safe_strcmp(daout, wantout) == 0,
  "xaccResolveFilePath",
  __FILE__, __LINE__,


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Running automated or unit tests?

[Jeff Kletsky]

Maybe I'm blind, but I'm not seeing how to run unit/automated testing 
(or how to add more unit tests to the quite).


Would someone point me in the right direction so I can be more confident 
I'm not breaking things?


-j
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0

[Jeff Kletsky]

For me, at least, not having eguile reports and a CSS-compatible 
renderer are show-stoppers. I've seen that the vast majority of time in 
reporting is due to the current HTML-render. 20-30 seconds to render a 
budget report just isn't acceptable for us. Between that and that it 
strips out CSS so you can't even create a decent report to render 
externally, these, for me are beyond critical.


I'm working on patching up the budget code (which is presently blind to 
the UI sign-reversal selections) and would like to try to get them in, 
but I don't know how long it will take to resolve the Scheme/C issues 
related to variables and initialization (for example, the patch in 
 
doesn't look to be localizable), even if the problem with kvp not being 
compatible across different locales (the key generally changes when your 
locale does). While I would like to get this in so that the change in 
budgets is at a major release, I don't want to hold things up.


Jeff


Christian Stimming wrote:

Am Samstag, 6. März 2010 schrieb John Ralls:
  

On Mar 5, 2010, at 2:59 PM, Phil Longstaff wrote:


Do we want to release a stable 2.4.0?  What do we need to finish to do
that.  There are lots of things happening in trunk, all of which will be
useful at some point, but many of which are destabilizing things.
  

My feeling from the users list says they want the dbi backend and the new
 reporting made possible by WebKit, and that they'd like it soon. Maybe we
 should ask them what they want.



That's my understanding as well.

However, dbi already comes with several variants: sqlite3 file, mysql 
bindings, postgresql bindings. Which one of those should work? All three?


So we need to make up lists of features new in 2.4 which need to be verified 
to work correctly:

- webkit reporting
- dbi backend with sqlite3 file
- dbi backend with mysql bindings
- dbi backend with postgresql bindings

There are additional new features, which might still have problems, so we can 
decide whether to disable them for 2.4 or test and fix them:

- eguile reports
- CSV importer (or was this active in 2.2.9 already?)
- QSF export (or was this active in 2.2.9 already?)
- Check printing features (but I think those work without problems)

(As you might have guessed, I need none of those features mentioned above. So 
I neither test them nor care about whether they are included in 2.4.0. But 
that's just my personal motivation here.)


Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
  

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: PATCH: Tweak to gnc-svnversion's bzr section

[Jeff Kletsky]

 On 3/4/2010 1:21 AM, Jesse Weinstein wrote:

The bzr handling code I added to gnc-svnversion turns out to fail when
the top revision isn't an imported svn version; this patch fixes this,
causing the revision returned to be the bzr revno.

I noticed that the About box describes the output of gnc-svnversion as a
SVN revision number, which is now not necessarily true.  I'll see about
sending in a patch to generalize this to refer to whatever VCS is in
use.  Does anyone know if any code relies on the output of
gnc-svnversion being a number (in which case, it would already be broken
on a git revision id, I suppose)?
   


The output of gnc-svnversion is a string, that gets stuffed into a 
format that looks something like "...SVN (r%s %s)" elsewhere in the code


./src/gnome-utils/gnc-splash.c:ver_string = 
g_strdup_printf(_("Version: GnuCash-%s svn (r%s built %s)"),
./src/gnome-utils/gnc-splash.c:ver_string = 
g_strdup_printf(_("Version: GnuCash-%s (r%s built %s)"),



I looked at it briefly and decided that it wasn't worth the time for me 
to change. At least getting a readable version identifier in there was 
enough. You'd need somehow to rework things so that both the string and 
the VC system in use were used. Right now, the output of gnc-svnversion 
is captured into a variable that is used by the make script.




I also figured out how to build gnucash in a different directory; I've
added some details about this to the wiki page:
http://wiki.gnucash.org/wiki/Building

Jesse Weinstein
   



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
   


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: astyle options [Was: Scaheme formatting with astyle]

[Jeff Kletsky]

On 3/3/2010 7:06 AM, Derek Atkins wrote:

Christian Stimming  writes:


I wonder if there's some way we could get the subversion server to
make white space indentation changes when changesets are committed?
Then we'd have a single place where all white space is controlled
(namely, on the server).

I don't think this is a good idea. It would mean the commits are sent
from the client to the server, then modified on the server before
actually committing them, causing a different commit than what the
client previously sent. IIRC the SVN documentation recommends strongly
against this. Instead, they say the server should merely have a allow
/ deny decision up front, but it should not modify the commit
itself. The modification needs to be done by the user before the
actual commit.

In this case I'd stick with the SVN proposals and not have any 
modifications

of the commit on the server side.

Fair enough.  Secondary question: once we have the astyle in place
should we add a pre-commit hook test that verifies that the style is
enforced?


In my experience with this kind of thing being tried or even just 
explored in commercial development environments, there will *always* be 
an exception -- something that programX says is "formatted wrong" but 
that you know is completely right. This always seems to happen when 
closing the last few bugs with under 24 hours left until code freeze...


I think a warning is a good thing, if you want to use the hooks to check 
it. Stuff it in the commented section of the commit message in the 
editor even. That way you can see that the code has been "checked" in 
some way and make a decision as how to proceed.


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Patch for version string for git users

[Jeff Kletsky]

If you're a git user, the splash screen and about screen include the 
full hash of the commit object.

It's a little unwieldy. This patch (also on the bug) changes
1a2528c8ca1d43e8e9e21b0661f844d2b496f47d
to either (the git-standard short hash)
1a2528c
or
1a2528c+
depending on if you have uncommitted changes in your working directory

https://bugzilla.gnome.org/show_bug.cgi?id=611645

$ git diff origin/master
diff --git a/util/gnc-svnversion b/util/gnc-svnversion
index d70c22f..17085ac 100755
--- a/util/gnc-svnversion
+++ b/util/gnc-svnversion
@@ -45,9 +45,11 @@ fi
 # Maybe it's git?
 if test -d "${real_srcdir}"/.git
 then
-  githead=`git --git-dir "${real_srcdir}"/.git rev-parse HEAD 2>/dev/null`
+  githead=`git --git-dir "${real_srcdir}"/.git log -1 --pretty=%h HEAD
2>/dev/null`  # short hash only
   if test $? = 0 ; then
-echo $githead
+echo -n $githead
+git diff HEAD 2>&1>  /dev/null&&  echo -n "+"  # Add a "+" to the hash if
there are unstaged changes
+echo
 exit 0
   else
 exit 1


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Coupling of preferences internal references and UI rendering

[Jeff Kletsky]

When I look at the code for setting preferences, such as in
src/business/business-utils/business-prefs.scm
it appears to me that there is a "hard link" between the access to the 
preference and the UI rendering


(define (book-options-generator options)
  (define (reg-option new-option)
(gnc:register-option options new-option))

  (reg-option
   (gnc:make-string-option
gnc:*business-label* gnc:*company-name*
"a" (N_ "The name of your business") ""))

As I understand it, the combination of gnc:*business-label* 
gnc:*company-name* is used to identify the preference in the code, as 
well as identifying it to be rendered on the gnc:*business-label* tab.


Once an option like this is created, is there any way to have it appear 
(in the future) on a different tab, without having to change all the 
code references to the preference?



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Scheme formatting with astyle [Was: SQL backend performance]

[Jeff Kletsky]

On 2/24/2010 11:50 AM, Christian Stimming wrote:

As for the patch and indentation: Indeed we discussed and agreed on some
common indentation last summer, and we agreed on using the tool astyle to
reformat the code as decided. See
http://lists.gnucash.org/pipermail/gnucash-devel/2009-August/026121.html  
and

my commit r18675 recently.

which links to previous


 As a one-liner:

 $ astyle --indent=spaces=4 --brackets=break --pad-oper  *.[hc]



Is there a project standard for formatting scheme code as well?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

GNUCash compiled against Guile 1.9.x for Guile profiler?

[Jeff Kletsky]

Guile 1.9.x appears to have a "real" profiler, if I can ever get it to 
build on Ubuntu Karmic. Not unsurprisingly, I wasn't successful in my 
admittedly brief efforts in getting the profiler to run with Guile 1.6.


I had searched the archives about Guile 1.9 or 2.0 and found very little 
beyond some patches and concerns about some potential incompatibilities 
with Guile 2.0. Before I spend any more time on getting Guile 1.9.x to 
build, is there any experience already on building GNUCash against 1.9.x?


Jeff



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Budgets and inconsistent handling of account sign reversal.

[Jeff Kletsky]

On 2/23/2010 12:44 PM, Christian Stimming wrote:

[...]
You can always add kvp_frame entries at some of gnucash's top-level objects,
like the Book, Account, Transaction, or Split. See e.g. the Notes field of an
Account in xaccAccountSetNotes / xaccAccountGetNotes in engine/Account.c.

The kvp data is transparently read and written again by all earlier versions.
At least for XML, this is currently our most efficient solution when adding
new fields without breaking backwards compatiblity.

   


Appreciate the pointers as to where to consider looking. I've been 
looking at using "user preferences" and that seemed to work. Always open 
to suggestions.



[...]

Is there supposed to be guaranteed backward compatibility for anything
but the XML backend?
 

As Derek said: The previous stable series 2.2.x only had XML backend, so the
new backends don't have to be backwards compatible to anything. It would be a
good time to build in some functionality to offer such a guarantee in the
future, though...

   


Good to know -- I recall something about PostgreSQL or some other older 
option. Cutting down the test matrix is always a good thing!


Looking forward to making some meaningful contributions here as I learn 
to love gnc-numerics and all their friends.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: More files for .gitignore?

[Jeff Kletsky]

On 2/23/2010 12:29 PM, Christian Stimming wrote:

Am Dienstag, 23. Februar 2010 schrieb Jeff Kletsky:
   

Any good reason not to add these to .gitignore?
 

No good reason. Thanks for sending the patch (though I've added them in the
alphanumeric sorting order).

I think many developers have a separate build directory anyway, which means
those files are not built in src/bin/gnucash-gdb but in build-foo-bar-yadda-
yadda/src/bin/gnucash-gdb etc.

   


Greatly appreciated!

It's been a while since I've done this kind of development, so thanks 
also for the pointer of changing the build directory. I'll look into how 
to do that.


Jeff

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

PATCH: More files for .gitignore?

[Jeff Kletsky]

/usr/local/src/gnucash-svn/trunk$ git diff -t r18708 .gitignore
diff --git a/.gitignore b/.gitignore
index eb1ed52..839f75d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -119,3 +119,8 @@ po/.intltool-merge-cache
src/bin/gnucash-bin.o
gnucash-*.*.*/
gnucash-*.*.*.tar.*
+src/bin/gnucash-ddd
+src/bin/gnucash-gdb
+src/bin/gnucash-setup-env
+src/libqof/backend/file/qsf-dir.h
+src/libqof/qof/qofla-dir.h


Files all confirmed to have ".in" versions and not to exist on trunk.

Jeff Kletsky wrote:

Any good reason not to add these to .gitignore?

# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#src/bin/gnucash-ddd
#src/bin/gnucash-gdb
#src/bin/gnucash-setup-env
#src/libqof/backend/file/qsf-dir.h
#src/libqof/qof/qofla-dir.h
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: More files for .gitignore?

[Jeff Kletsky]

Any good reason not to add these to .gitignore?

# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#src/bin/gnucash-ddd
#src/bin/gnucash-gdb
#src/bin/gnucash-setup-env
#src/libqof/backend/file/qsf-dir.h
#src/libqof/qof/qofla-dir.h
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Budgets and inconsistent handling of account sign reversal.

[Jeff Kletsky]

On 2/22/2010 1:16 PM, Derek Atkins wrote:

Geert Janssens  writes:
Note that schema updates don't depend on string freeze.  HOWEVER you
need to consider forwards and backwards compatibility issues.  For
example, we want files written by 2.4.x to be readable by e.g. 2.2.9.



I agree with that, and that the reports and UI should still function in 
a "reasonable" way if you do downgrade. I've been thinking through some 
ways of accomplishing this.


The addition of a way of denoting the "default budget" should be 
reasonably easy.


Changing the internal storage of budgets seems like it might be best 
left alone (save for copious documentation of the data-model 
inconsistency), but the accessors (and associated UI and reports) be 
modified for consistency with the rest of the app. 3rd-party reports and 
extensions written for pre-2.4.x versions would work fine in pre-2.4.x 
environments, but would likely need to be modified to respect the user's 
UI-level sign-reversal preferences.


(As a side note, it becomes "rather challenging" to maintain backwards 
compatibility when the backend is a database, especially if any columns 
change or are deleted.)


How far back should I be confirming compatibility? 2.2.9? 2.2.0? Before?

Is there supposed to be guaranteed backward compatibility for anything 
but the XML backend?


Does the XML backend "gracefully ignore" tags that it doesn't 
understand? For example, if a "default budget" field is added to the 
book, is it "skipped over" on read if there isn't a corresponding data 
field for its contents to populate?


Can I assume that "backwards compatibility" allows for data that was 
created in a later version, that did not exist in an earlier version, 
not to "magically" be preserved if the user then moves forward in 
version? For example, if 2.4.x adds "default budget" then the saves as 
XML, opens in 2.2.9 (where the field does not exist), saves from 2.2.9, 
then opens in 2.4.x, then the value of "default budget" would likely be 
lost.


Thanks!
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Budgets and inconsistent handling of account sign reversal.

[Jeff Kletsky]

On 2/22/2010 8:16 AM, Derek Atkins wrote:

GnuCash does not handle data format schema updates well.  :-(
   


f...

Should I be scrambling to get in a place to properly store the default 
budget, probably on the book, even though we're past string freeze, so 
that there aren't data model changes once 2.4 comes out?


It's on my "to do list" to be able to have a user set a default budget, 
but that has UI impact that will likely need new strings.


As far as I can tell, src/engine/budget.c deterministically, but not 
easily controllably, selects the "current" budget:


static void just_get_one(QofInstance *ent, gpointer data)
{
GncBudget **bgt = (GncBudget**)data;
if (bgt && !*bgt) *bgt = GNC_BUDGET(ent);
}

gnc_budget_get_default (QofBook *book)
{
QofCollection *col;
GncBudget *bgt = NULL;

g_return_val_if_fail(book, NULL);
col = qof_book_get_collection(book, GNC_ID_BUDGET);
if (qof_collection_count(col) > 0) {
qof_collection_foreach(col, just_get_one, &bgt);
}
return bgt;
}


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Budgets and inconsistent handling of account sign reversal.

[Jeff Kletsky]

Good news?

A budget report using eguile runs in a couple seconds, instead of nearly 
20 using the HTML-renderer classes.


Bad news?

Looks like budgets, as they exist today, are apparently unaware of the 
sign-ed-ness of accounts and "ignore" the sign-reversed options (None, 
Income & Expense, or Credit Accounts).


This means that, depending on how you set those flags in the UI, you may 
be on-target, or off target by a factor of two (positive budget for 
expenses, but with negative expenses, due to UI settings). I haven't 
assessed the breadth of the changes that it would entail, but, in my 
opinion, having budget values behave consistently with account values 
seems like a reasonable objective.


If I do decide to tackle having the "internal" budget numbers consistent 
with their associated accounts, and the UI representations responsive to 
the sign-reversed accounts settings (both the budget entry screen and 
reports need "fixes" from what I can tell), how does GNUCash handle 
schema and/or data upgrades? Is there a precedent for how object 
representations are updated from one version to the next? The "ideal" 
thing from a user perspective would be that nothing is seen, at least 
for those users that have "Credit Accounts" for their selection.


Thanks!

Jeff
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Report Engine Speed

[Jeff Kletsky]

On 2/19/2010 12:06 PM, Christian Stimming wrote:


[...] what I can recall is this:
All the "number collecting calculations" in all of the reports are
horribly inefficient, or more academic: coded in the wrong level of
abstraction. That is, the calculation of the balance difference between start
and end of a reporting period is usually done by obtaining the list of splits
(transactions) in question from within the scheme code, then summing over all
of those splits. Also, the intermediate results are not cached at all, even
during one report generation run, so they are calculated over and over again
when the report is generated. This turns your O(n) problem into an O(n^2)
problem.
   


Thanks for the insight!

It was my first instinct as well was that there was something 
inefficient in the way that the data behind the report was being collected.


Interestingly, crude timing information suggests that the bulk of the 
time is in html-document-render. The renderer in budget.scm (2.2.9, at 
least) is returning in 3.8 wall-clock seconds, but html-document-render 
is taking 13.4 seconds. A quick look at html-object-renderer shows it 
being called 42,019 times in the roughly 12 seconds it takes, with the 
string-append that follows consuming a little over a second. Seems as 
though some structural changes in how the HTML is being generated may 
have some very meaningful improvements!


I'll probably end up taking a stab at an eguile version this weekend.

Jeff




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Report Engine Speed

[Jeff Kletsky]

Always good to know what has gone before and that I'm biting off a 
"challenging" problem.


I'll probably start with a liberal set debug statements with 
gettimeofday to see if I can tell if it's in the collection of the data, 
or the rendering of the data into HTML once all collected.


Including eguile as an option is a significant and welcome improvement, 
in my opinion. While not what I'm used to in web development, it 
certainly makes things a lot easier!


-jeff


On 2/19/2010 7:36 AM, Derek Atkins wrote:


I don't think we've done any profiling of reports to see where it's
spending its time.  Of course, profiling the C and Scheme separately
might be... Challenging.

   


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Report Engine Speed

[Jeff Kletsky]

While we like the professional features found in GNUCash as an 
accounting system, we're at wits end with the reporting system.


Moving to a modern HTML rendering engine is great step in the right 
direction. However, even in 2.3.10, the time to build a simple budget 
report off two-months' of personal data is 15-25 seconds on a dual-core 
Atom 330 running Ubuntu, which seems obscenely long. Its not noticably 
better on a 1.83 GHz Core Duo MacMini. That just isn't going to work for us.


I found the "optimizing reports" thread from October 2007, but not a lot 
since then. Has there been any significant understanding gained since 
then about what is so slow on what should be a relatively 
straightforward task? Was it ever narrowed down to bad algorithms in the 
reporting, or something else? Before I induce any more 6.031 flashbacks, 
is Scheme just too much of a dog to get the task done?


Thanks,

Jeff

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Report Engine Speed

[Jeff Kletsky]

Re-reading, I wanted to make sure that it was understood that my intent 
is to try to fix some of this in a hopefully generally useful way as I 
work through the reports and output I need...


Jeff
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Please back out r18428 - editable 2nd date field

[Jeff Kletsky]

I have to strongly second this request. In my opinion, this is a 
"half-complete" feature.


At a minimum, until there is a preference setting available, in my 
opinion, this should not be part of the trunk.


Arguably, until sorting and searching is also available on the new 
field, similar to the other fields in the UI with similar display and 
prominence, it should not be revealed in the UI in trunk.


I also prefer that the default should "off" -- this feature seems to 
represent a strange mix of cash and accrual accounting that complicates 
the register views and generally reduces their usability.



Jeff

On 2/13/10 3:45 AM, Kim Wood wrote:

The has been some discussion in the user forum at
http://n4.nabble.com/New-Transaction-field-in-the-register-td1476778.html#a1476778 


about patch r18428.  IMHO this patch is particularly bad and should be
removed for two reasons.

Firstly, in double line register display mode, the two dates displayed 
for
each transaction produces an extremely confusing display to the user.  
It is

not at all obvious what the second date's purpose is - and there is no
option to disable it.

Secondly, the editable second date filed allows manipulation of the
underlying transaction data.  GUI manipulation of transaction creation 
date

data surely sets a dangerous precedent.

I understand the patch writer James Raehl was seeking some additional
transaction functionality - but the result is a cluttered and confusing
register, with no option to turn off the second date filed.  I believe 
that

it harms the users experience of the interface rather than enhancing it.

Can this patch be backed out until such time there is an option 
provided to
disable it?  I believe that the default position is that the option 
should

be turned off.

Am I alone in thinking that the register in double line mode now looks 
less

user friendly?

Regards,

Kim Wood


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Close books trashes Income Statement and Net Income on Balance Sheet

[Jeff Kletsky]

This one has tripped me up as well. In the business world, there often 
is either January 1st which is a non-business day to put the 
transactions on. The "fake day" is also another option.


There are implications past just the ones indicated in an earlier post 
-- most accounts are impacted, as are budgets, if they include 
book-close transactions.


Thinking about this a little, I believe that a future solution may take 
the form of a flag that identifies certain transactions as book-close 
transactions, then let the reports decide how to deal with them. I agree 
that use of a "fake date" doesn't make sense in the current era of 
computation.




On 2/7/10 8:31 AM, JT Morée wrote:

"calendar" allowed for the special date "year end". In other
words, we could insert a date in between two (real) calendar
dates that fell after the first but before the second. Think
of it as a December 32 or a Jan 0

Not an easy problem for GnuCash (no way of knowing what the
user's "fiscal year" might be)

Michael D Novack, FLMI
I am not an accountant but I disagree that the best solution is to 
create a fake date or reserve a real date.


I realize my post was long but in short I believe the best solution is 
to have the reports be smarter.  It's not difficult (almost done in 
fact) and it avoids the fiscal year problem you mention.


JT


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel