Re: [GNC-dev] Tax schedule report outputting entries outside of selected date range

[Jeff]

On 3/19/23 8:46 PM, Alex Aycinena wrote:

Jeff,

What is the type of the account that this particular out-of-date-range 
transaction is listed for (i.e., Income, Expense, Asset, or Liability)?


It would help me to know in order to try to reproduce the problem. Is 
it an Asset or Liability?


From memory, for Asset or Liability accounts, the report is supposed 
to show: the beginning balance, all transactions for the year, and the 
ending balance. The beginning balance for the TXF code, that the 
account is reported under, should correspond to the reported amount on 
last year's return, the listed transactions allow you to verify that 
the change for this year is correct, and the ending balance is the 
amount to report for this year, once the verification process is complete.


Thanks,

Alex

On Fri, Mar 17, 2023 at 2:21 AM Jeff  wrote:

On 3/16/23 5:39 PM, Alex Aycinena wrote:




-- Forwarded message --
From: Jeff 
To: gnucash-devel 
Cc:
Bcc:
Date: Thu, 16 Mar 2023 01:18:08 -0500
Subject: [GNC-dev] [GNC] Tax schedule report outputting
entries outside of selected date range
I'm trying to generate a tax report (federal 1040) for entry
into my tax software, as I do every year and have never ran
into this issue.

Not sure of the version of GNC I'm running on Windows 10. 
Running Version 4.13 Build ID: Flathub 4.13 Finance Quote:
1.5301 under Ubuntu 20.04 LTS.

Both versions are including a transaction from 07/02/2020
when the date range for the report is 01/01/2022 to
12/31/2022. The transaction of concern is listed as "Tax
Report Only - No TXF Export".

I have limited internet access right now so I can not confirm
that this is a known bug.  My concern is that the report may
also be skipping transactions from 2022.  I have exported the
report as a pdf file with no options selected other than the
time frame, and the transaction shows up there as well.  If I
edit the options to suppress $0, no printing of full account
names/action:memo data/transaction detail, and print TXF
export parameters, the errant transaction shows up.

Any ideas why?

-- 
--JEffrey Black M.B.A.



What is the TXF code on the report for the errant transaction?
'000' or ' N000'? That is the only TXF code that has that
description (Tax Report Only - No TXF Export).

If you go to the account that the report has that transaction
listed under in the Edit->Tax Report Options panel, is the
account set as 'Tax Related'? If so, should it be? And if it
should be, should it have another Form/Schedule item selected? If
changes to this account are warranted and made, does the errant
transaction still appear or go away?

Before entry into your tax software, you can get comfortable that
the other Income Tax Report totals are correct by comparing the
account totals to totals for the year of other reports. If there
are unexpected differences (there shouldn't be), the transaction
detail in the Tax Report can help you figure out what it is.

There is a TXF code, 521 for 'Federal estimated tax, qrtrly'
which has special date processing for calendar date ranges, as
explained in the description for that code, to catch the Jan 15
payment made the next year. Other than that, all splits selected
to generate the report should be in the date range.

In any case, I don't understand why a 07/02/2020 transaction
should appear in the report if the specified date range is
01/01/2022 to 12/31/2022. I will try to replicate the error with
test data and look at the code to see if I can figure it out.

Look forward to your response to my questions above.

Alex


The TXF code for that account is '000'.  This particular account
was required on a prior years return (actually the number of
payments was required, not the sum total) but; there is no
corresponding tax form/line number for it, hence the reason for
selecting "Tax Report Only - No TXF Export".  The only reason I
caught it in the report, is that it was for Covid related income,
and I knew that there was none in 2022.

The 'Income Tax Identity' is set for 'Individual, Joint, etc. -
Files US form 1040'.

Just as an experiment I added a transaction for $1 into that
account for '03/17/2021' and it summed it to the total as well in
the report for 2022. If I remove the account from the tax related
entries it disappears.

So far, this one account is the only trouble maker that I have
discovered.

As for the TXF code, 521 for 'Federal estimated tax, qrtrly', I
have not had to use it in years.  Now I remember why the need for
special date processing (thanks for the refresher).

Re: [GNC-dev] Tax schedule report outputting entries outside of selected date range

[Jeff]

On 3/16/23 5:39 PM, Alex Aycinena wrote:




-- Forwarded message --
From: Jeff 
To: gnucash-devel 
Cc:
Bcc:
Date: Thu, 16 Mar 2023 01:18:08 -0500
Subject: [GNC-dev] [GNC] Tax schedule report outputting entries
outside of selected date range
I'm trying to generate a tax report (federal 1040) for entry into
my tax software, as I do every year and have never ran into this
issue.

Not sure of the version of GNC I'm running on Windows 10. Running
Version 4.13 Build ID: Flathub 4.13 Finance Quote: 1.5301 under
Ubuntu 20.04 LTS.

Both versions are including a transaction from 07/02/2020 when the
date range for the report is 01/01/2022 to 12/31/2022. The
transaction of concern is listed as "Tax Report Only - No TXF Export".

I have limited internet access right now so I can not confirm that
this is a known bug.  My concern is that the report may also be
skipping transactions from 2022.  I have exported the report as a
pdf file with no options selected other than the time frame, and
the transaction shows up there as well.  If I edit the options to
suppress $0, no printing of full account names/action:memo
data/transaction detail, and print TXF export parameters, the
errant transaction shows up.

Any ideas why?

-- 
--JEffrey Black M.B.A.



What is the TXF code on the report for the errant transaction? '000' 
or ' N000'? That is the only TXF code that has that description (Tax 
Report Only - No TXF Export).


If you go to the account that the report has that transaction listed 
under in the Edit->Tax Report Options panel, is the account set as 
'Tax Related'? If so, should it be? And if it should be, should it 
have another Form/Schedule item selected? If changes to this account 
are warranted and made, does the errant transaction still appear or go 
away?


Before entry into your tax software, you can get comfortable that the 
other Income Tax Report totals are correct by comparing the account 
totals to totals for the year of other reports. If there are 
unexpected differences (there shouldn't be), the transaction detail in 
the Tax Report can help you figure out what it is.


There is a TXF code, 521 for 'Federal estimated tax, qrtrly' which has 
special date processing for calendar date ranges, as explained in the 
description for that code, to catch the Jan 15 payment made the next 
year. Other than that, all splits selected to generate the report 
should be in the date range.


In any case, I don't understand why a 07/02/2020 transaction should 
appear in the report if the specified date range is 01/01/2022 to 
12/31/2022. I will try to replicate the error with test data and look 
at the code to see if I can figure it out.


Look forward to your response to my questions above.

Alex


The TXF code for that account is '000'.  This particular account was 
required on a prior years return (actually the number of payments was 
required, not the sum total) but; there is no corresponding tax 
form/line number for it, hence the reason for selecting "Tax Report Only 
- No TXF Export".  The only reason I caught it in the report, is that it 
was for Covid related income, and I knew that there was none in 2022.


The 'Income Tax Identity' is set for 'Individual, Joint, etc. - Files US 
form 1040'.


Just as an experiment I added a transaction for $1 into that account for 
'03/17/2021' and it summed it to the total as well in the report for 
2022. If I remove the account from the tax related entries it disappears.


So far, this one account is the only trouble maker that I have discovered.

As for the TXF code, 521 for 'Federal estimated tax, qrtrly', I have not 
had to use it in years.  Now I remember why the need for special date 
processing (thanks for the refresher).


Ah-ha.  I see what it is doing, just not how to get rid of it in the 
report, short of adding a t account to zero it.  Most of the accounts 
that I have set for "Tax Report Only - No TXF Export" have transactions 
posted in 2022 and behave as I expected.  I just noticed that I have not 
manually entered the depreciation in some specialty accounts for 2022 so 
I end up with the last balance that the account had (irregardless of the 
date of the last entry), not $0.00 if no entries for 2022.  That is why 
the Covid payment is showing up, there have been no entries since it was 
posted so it gives me the current amount still in that account.  Thus, 
any of the deprecation accounts that have no entries for 2022 are 
showing me misleading values for 2022 if they have never been updated or 
brought to a balance of $0.00.  I will have to manually go through every 
account of type "Tax Report Only - No TXF Export" and enter the 
balancing transactions that I missed.


--
--JEffrey Black M.B.A.
___
gnucash-devel mailing list
gnucash-devel@gn

[GNC-dev] [GNC] Tax schedule report outputting entries outside of selected date range

[Jeff]

I'm trying to generate a tax report (federal 1040) for entry into my tax 
software, as I do every year and have never ran into this issue.

Not sure of the version of GNC I'm running on Windows 10.  Running Version 4.13 
Build ID: Flathub 4.13 Finance Quote: 1.5301 under Ubuntu 20.04 LTS.

Both versions are including a transaction from 07/02/2020 when the date range for the 
report is 01/01/2022 to 12/31/2022. The transaction of concern is listed as "Tax 
Report Only - No TXF Export".

I have limited internet access right now so I can not confirm that this is a 
known bug.  My concern is that the report may also be skipping transactions 
from 2022.  I have exported the report as a pdf file with no options selected 
other than the time frame, and the transaction shows up there as well.  If I 
edit the options to suppress $0, no printing of full account names/action:memo 
data/transaction detail, and print TXF export parameters, the errant 
transaction shows up.

Any ideas why?

--
--JEffrey Black M.B.A.

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

Re: [GNC-dev] [GNC] GnuCash 4.900 Released

[Jeff]

On 1/10/23 12:14 AM, Adrien Monteleone wrote:
Lots of great improvements already and I'm sure more to look forward 
to. (some new reports too!)


But of the list so far, my money is on this one getting the most sighs 
of relief and smiles:


"The description field quickfill in the register now displays a 
drop-down list of possible completions instead of just one inline 
completion."


(of course, a Stock Assistant is majorly cool too...)

Thanks to all!

Regards,
Adrien

___
gnucash-user mailing list
gnucash-u...@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


I missed something here, not surprising with the last 48 hour days I 
have spent.  All of the messages I see are Re.[GNC] GnuCash 4.900 
Released.  I cannot find the original message in any of the e-mails I 
down loaded.  Is there a new version or not?


And how do I find it under Ubuntu 22.04.1 LTS?

--
--JEffrey Black M.B.A.

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

Re: [GNC-dev] Just curious, images to file or MySQL

[Jeff]

On 12/8/21 10:48 AM, john wrote:



On Dec 7, 2021, at 10:27 PM, Jeff  wrote:

On 12/7/21 11:38 AM, john wrote:



On Dec 7, 2021, at 1:40 AM, Jeff  wrote:

Since GNC is based on XML and MySQL, how hard would it be to 
upgrade to link the code to a MySQL database format for document 
saving (i.e.check images) instead of just an XML hard link to a file?


Even though there seems to be a limit on the number of transactions 
that you can convert from XML to MySQL. 3 years works, 30 doesn't. 
 I have 30+ in my ledger and cannot get it to convert from XML to 
MySQL. My dad's only has less than 4 years and converts fine to MySQL.


Saving to an image file currently limits you to one drive and a 
specific file.  MySQL would allow saving to wherever the database 
of images exists as a list of blobs.  Hard drive upgrades would be 
much simpler.


Again just curious.
There is no programmatic limit in GnuCash on the number of 
transactions that GnuCash can store using the MySQL backend, so 
you're most likely hitting some limitation on the server side. You 
can run GnuCash with --log gnc.backend.sql=debug to get details of 
the insert queries and server error responses; combined with your 
MySQL logs you should be able to pretty quickly diagnose the 
problem. If you find that GnuCash's backend is doing something dumb 
please file a bug.


As for document image links they're URIs so you can put them 
anywhere that you can access with a URI. A web server on your LAN is 
an easy to implement option.


Regards,
John Ralls

.


I understand the direct link to a file or URL but; how does one 
specify a URI?


URI means Uniform Resource Identifier, see 
https://en.wikipedia.org/wiki/Uniform_Resource_Identifier. It's a more 
general term than URL, or Uniform Resource Locator.


Regards,
John Ralls

Sorry John Ralls, if my reply comes directly to you, my email client no 
longer lets me easily reply directly to the list only.


I have not been able to convert my data to an sql file, period. 30 years 
worth.  Works for other sets of books with much fewer years of data.


What I am after is a way to link images to a transaction but not via a 
specific filename.  Like many others I am sure, I'd like to access the 
images from any drive, including a replacement drive. I just had 2 hard 
drive failures back to back on external drives. Now not only do I have 
to hire a forensic company to try and recover them, I have lost all 
images saved to them.  And yes, they were both unfortunately system back 
up drives. 12 terabytes for those 2.


In fewer words, I need a method of attaching images to a stand alone 
database.  I have never had a successful build of GNC.  Some stupid 
mistake on my part I am sure.  I would be more than happy to write such 
program but I do not understand the GNC code well enough to change the 
image link from a file to a call to a standalone database program 
running in the back ground.


--JEffrey Black M.B.A.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Just curious, images to file or MySQL

[Jeff]

On 12/7/21 11:38 AM, john wrote:



On Dec 7, 2021, at 1:40 AM, Jeff  wrote:

Since GNC is based on XML and MySQL, how hard would it be to upgrade to link 
the code to a MySQL database format for document saving (i.e.check images) 
instead of just an XML hard link to a file?

Even though there seems to be a limit on the number of transactions that you 
can convert from XML to MySQL. 3 years works, 30 doesn't.  I have 30+ in my 
ledger and cannot get it to convert from XML to MySQL. My dad's only has less 
than 4 years and converts fine to MySQL.

Saving to an image file currently limits you to one drive and a specific file.  
MySQL would allow saving to wherever the database of images exists as a list of 
blobs.  Hard drive upgrades would be much simpler.

Again just curious.

There is no programmatic limit in GnuCash on the number of transactions that 
GnuCash can store using the MySQL backend, so you're most likely hitting some 
limitation on the server side. You can run GnuCash with --log 
gnc.backend.sql=debug to get details of the insert queries and server error 
responses; combined with your MySQL logs you should be able to pretty quickly 
diagnose the problem. If you find that GnuCash's backend is doing something 
dumb please file a bug.

As for document image links they're URIs so you can put them anywhere that you 
can access with a URI. A web server on your LAN is an easy to implement option.

Regards,
John Ralls

.


I understand the direct link to a file or URL but; how does one specify 
a URI?


--
--JEffrey Black M.B.A.

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

[GNC-dev] Just curious, images to file or MySQL

[Jeff]

Since GNC is based on XML and MySQL, how hard would it be to upgrade to 
link the code to a MySQL database format for document saving (i.e.check 
images) instead of just an XML hard link to a file?


Even though there seems to be a limit on the number of transactions that 
you can convert from XML to MySQL. 3 years works, 30 doesn't.  I have 
30+ in my ledger and cannot get it to convert from XML to MySQL. My 
dad's only has less than 4 years and converts fine to MySQL.


Saving to an image file currently limits you to one drive and a specific 
file.  MySQL would allow saving to wherever the database of images 
exists as a list of blobs.  Hard drive upgrades would be much simpler.


Again just curious.

--
--JEffrey Black M.B.A.

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

Re: [GNC-dev] gnucash 3.906-1 fails to launch on clicked icon

[Jeff Earickson]

Ok. Will do later today. Thanks
Jeff

On Tue, Jun 23, 2020 at 08:49 Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Get your wiki account and add it.
>
> Regards
> Frank
>
> Am 23.06.20 um 14:34 schrieb Jeff Earickson:
> > Can I suggest an FAQ addition, see attached, right after 2.3.1 in
> > https://wiki.gnucash.org/wiki/FAQ please?
> >
> >
> > Jeff Earickson
>
-- 
Sent from Gmail Mobile
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] gnucash 3.906-1 fails to launch on clicked icon

[Jeff Earickson]

John,

I get:

*spctl --assess -vv /Applications/Gnucash/Gnucash.app*

*/Applications/Gnucash/Gnucash.app: accepted*

*source=Notarized Developer ID*

*origin=Developer ID Application: John D Ralls (Y9EHT5WMK7)*


and


*xattr -p com.apple.quarantine /Applications/Gnucash/Gnucash.app*

*0181;5eefb4fd;Chrome;E0D8DF2D-DB87-4025-A211-260183ECA9D9*


*So, clearing the xattr attribute:*


*su - admin (enter passwd)*

*rongovia:~ admin$ xattr -d -r com.apple.quarantine
/Applications/Gnucash/Gnucash.app*

*rongovia:~ admin$ xattr -p com.apple.quarantine
/Applications/Gnucash/Gnucash.app*

*xattr: /Applications/Gnucash/Gnucash.app: No such xattr:
com.apple.quarantine*


After that I could click on the application and it fired right up.
Hooray!  Thank you!!


Can I suggest an FAQ addition, see attached, right after 2.3.1 in
https://wiki.gnucash.org/wiki/FAQ please?


Jeff Earickson

On Mon, Jun 22, 2020 at 11:20 PM John Ralls  wrote:

> I'd go with some security issue. Check it with
>   spctl --assess -vv /Applications/Gnucash.app
>   xattr -p com.apple.quarantine /Applications/Gnucash.app
>
> I get
>   /Applications/Gnucash.app/: accepted
>   source=Notarized Developer ID
>   origin=Developer ID Application: John D Ralls (Y9EHT5WMK7)
>
> and
>   01c1;5eeff24b;Firefox;BC474A13-F338-4CD7-BD10-3FB16BB8BFEE
>
> You can force acceptance with
>   spctl --add --label 'Approved' /Applications/Gnucash.app
>   xattr -d -r com.apple.quarantine /Applications/Gnucash.app
>
> *But* if spctl fails something is wrong with the download as it should be
> cryptographically signed with my Apple certificate and notarized by Apple.
>
> Regards,
> John Ralls
>
> > On Jun 22, 2020, at 4:10 PM, Jeff Earickson  wrote:
> >
> > John,
> >
> > I fired up the console and looked in Crash Reports.  Nothing from
> gnucash.
> >
> > Doing "open Gnucash.app --args --debug" works great.  The app fires up
> and acts normally.  I get a trace file (attached).  I get a normal
> termination when closing out.  No system.log complaints.
> >
> > So I created a new user (no admin capabilities), logged in, and tried to
> fire up Gnucash.  It did not work via click nor via open from the command
> line.  Both gave the err code 1 to system.log like before.  However it also
> worked just fine via "open Gnucash.app --args --debug" as well, and I got a
> tracefile there too.  I went thru the new account setup, no crashes, no
> problems, looked good.
> >
> > Gnucash seems to get stomped by the OS during launch really early,
> before gnucash gets to the point of opening files like the trace file or
> doing anything useful.  Almost like the fork/exec of the process fails, or
> some security setting someplace just says NOPE to the process.
> >
> > Jeff
> >
> > On Mon, Jun 22, 2020 at 4:58 PM John Ralls  wrote:
> > No doubt the crash left a crash report in Console, please open a bug (
> https://wiki.gnucash.org/wiki/Bugzilla#Commenting_on_existing_bugs_or_entering_new_ones)
> and attach it.
> >
> > Try
> >   open Gnucash.app --args --debug
> >
> > And check the trace file again.
> >
> > You might also try creating a new user and trying to start GnuCash as
> that user just in case there's something about your user configuration
> that's triggering the problem.
> >
> > Regards,
> > John Ralls
> >
> > > On Jun 22, 2020, at 12:22 PM, Jeff Earickson 
> wrote:
> > >
> > > John,
> > >
> > > "open Gnucash.app" via command-line gives the same error code 1 in
> system.log, nothing else happens.
> > >
> > > I had to hunt for a gnucash.trace file by walking the root directory
> with find.  Finally found something in
> /System/Volumes/data/private/var/folders/(other stuff)/gnucash.trace.  I
> zeroed out the tile via "cat /dev/null > gnucash.trace" then started
> clicking and trying to open the app via command-line.  Not a single byte
> went to this file.  Just the errcode 1 to system.log.
> > >
> > > Then I tried via the commond-line, running the executable:
> > >
> > > cd /Applications/Gnucash/Gnucash.app/Contents/MacOS
> > > ./Gnucash --debug --extra --logto /tmp/gnucash.trace
> > >
> > > The application opened up, wanted me to create a new account, I
> clicked thru the "next" buttons to do so, and then it crashed.  I realize
> this may be a different problem than the "fail to open" issue, but the
> latter problem refuses to cough up a tracefile anyplace.  See attached.
> > >
> > > Thanks,
> > > Jeff Earickson
> > >
> > >
> > > On Sun, 

Re: [GNC-dev] gnucash 3.906-1 fails to launch on clicked icon

[Jeff Earickson]

John,

My System Preferences is (and was) as you recommend, and has been for a
while.  I've seen this behavior with programs before, including Gnucash,
where it flops on the first launch but works thereafter.  So, I tried this
"jiggle the handle" approach here.  No go in this case.

Gnucash 3.906 launches flawlessly via command-lien, but coughs up the err
code 1 in system.log via clicking every time.  No love from it in this
corner.  :(

Jeff Earickson

On Sun, Jun 21, 2020 at 7:57 PM John Ralls  wrote:

>
>
> > On Jun 21, 2020, at 2:35 PM, Jeff Earickson  wrote:
> >
> > Releases 3.905-1 and previous 3.9x releases
> >
> > OS: MacOS 10.15.5 (Catalina) MacBook Pro and Mac Mini hardwares
> >
> > System log says (/var/log/system.log):
> >
> > *Jun 21 17:15:55 rongovia com.apple.xpc.launchd[1]
> > (com.apple.xpc.launchd.oneshot.0x1001.Gnucash[602]): Service exited
> > with abnormal code: 1*
> >
> >
> > (could not find other references to Gnucash in any other syslogs)
> >
> > The problem: When you click on the application icon to launch Gnucash,
> you
> > get the "verifying Gnucash" scrollbar, then -- nothing.  Checking the
> > syslogs, you see the message above.  This is true when the program is
> > installed in /Applications, or clicked on directly from the mounted
> volume
> > from the dmg.
> >
> > However, the program will start up correctly if you open a terminal
> window
> > and launch it via command-line, ie
> >
> > cd /Applications/GnucashGnucash.app/Contents/MacOS
> > ./Gnucash
> >
> > I get:
> >
> > *rongovia:MacOS jaearick$ ./Gnucash*
> >
> > *Application Path
> > /Applications/Gnucash/Gnucash.app/Contents/MacOS/./Gnucash*
> >
> >
> > *(process:878): gnc.gui-**WARNING** **: **17:30:10.516**:
> > [mac_set_languages()] Language list: en:en_US:C*
> >
> >
> > and the splash screen and everything else appears normally.
> >
> >
> > I googled about this topic, and it has appeared in the past, but I did
> not
> > find an actual fix to the problem.
> >
> >
> > FYI, before this turns into a real 4.0 release.
>
> This is pretty common, the verification blocks the launch. It generally
> starts right up on the second and subsequent launch attempts, as it did for
> me just now. Do make sure that you have "App Store and identified
> developers" checked in System Preferences>Security & Privacy>General under
> Allow apps downloaded from:.
>
> Regards,
> John Ralls
>
>

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

[GNC-dev] gnucash 3.906-1 fails to launch on clicked icon

[Jeff Earickson]

Releases 3.905-1 and previous 3.9x releases

OS: MacOS 10.15.5 (Catalina) MacBook Pro and Mac Mini hardwares

System log says (/var/log/system.log):

*Jun 21 17:15:55 rongovia com.apple.xpc.launchd[1]
(com.apple.xpc.launchd.oneshot.0x1001.Gnucash[602]): Service exited
with abnormal code: 1*


(could not find other references to Gnucash in any other syslogs)

The problem: When you click on the application icon to launch Gnucash, you
get the "verifying Gnucash" scrollbar, then -- nothing.  Checking the
syslogs, you see the message above.  This is true when the program is
installed in /Applications, or clicked on directly from the mounted volume
from the dmg.

However, the program will start up correctly if you open a terminal window
and launch it via command-line, ie

cd /Applications/GnucashGnucash.app/Contents/MacOS
./Gnucash

I get:

*rongovia:MacOS jaearick$ ./Gnucash*

*Application Path
/Applications/Gnucash/Gnucash.app/Contents/MacOS/./Gnucash*


*(process:878): gnc.gui-**WARNING** **: **17:30:10.516**:
[mac_set_languages()] Language list: en:en_US:C*


and the splash screen and everything else appears normally.


I googled about this topic, and it has appeared in the past, but I did not
find an actual fix to the problem.


FYI, before this turns into a real 4.0 release.


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

Re: [GNC-dev] [GNC] Convincing my credit union to support online importing

[Jeff Albrecht]

The question dated 4/19/2018 was originally posted on gnucash-user I 
post response to my own question here on gnucash-devel hoping to help my 
Credit Union learn how to appear in the OFX DirectConnect User Setup wizard.

...

Very cool. I now have my GNUCash checking and savings accounts connected 
online to my credit union (cu).


After discussing with them at the annual meeting, the cu actually 
installed it (I suggested 2.6.21 rather than 3.0) they reported; 
"Version 2.6.21 installed cleanly, thank you for the tip.  We completed 
a review of the application including information security and 
integration options.  It’s a very complete solution."


The configuration isn't ready for prime time yet for all cu members, 
however the cu want's to learn how / where to add itself so that they 
show up in the OFXConnect wizard.


They asked me; "Do you know where GNUcash sources the financial 
institution list?  http://www.ofxhome.com looks to be the best 
reference.  I wonder if we add redactedcu there, then the GNUcash setup 
wizard might pick up the settings." Can someone help me answer them?



Thanks, - Jeff


On 4/19/2018 7:55 AM, Jeff Albrecht wrote:
Here in Arizona, USA Tuesday I attend the annual meeting of my credit 
union. I met with the Senior VP / Chief Information officer. We spoke 
about Quicken and it's rapid price hikes and move to subscription 
model. I told him a bit about GnuCash and that I had just converted to 
GnuCash and had imported a decade of Quicken data. I gave him some old 
school paper with some resources and my contact info. I asked if it 
would be possible to support online banking to support GnuCash. They 
do have a .OFX export. Yesterday he emailed to me;


   "... Intuit has ratcheted up their pricing model for several
   years and good to know there are viable options in the
   marketplace. We have connected with the team here at ___ and
   will look into GNUCash over the next few business days. Can I
   get back with you by Friday, April 27^th ? My contact
   information is listed below.  Please don’t hesitate to reach out
   with additional ideas or questions."

They seem genuinely interested. I would like to gather up information 
that may be valuable to the credit union in researching and deciding 
to support it, and perhaps links to implementation resources.


Does anyone have links etc. I might want to read and share with my 
Credit Union? Beyond


 * "Setting up OFXDirectConnect in GnuCash 2"
https://wiki.gnucash.org/wiki/Setting_up_OFXDirectConnect_in_GnuCash_2#The_AqBanking_Set-up_Wizard
 * "AqBanking" https://wiki.gnucash.org/wiki/AqBanking

I'm also looking for

 * Press
 o public looking for their banks to support it
 o banks that have implemented
 + Success stories
 * Technical
 o Resources
 * ???

Has anyone on the list worked with a bank to convince and/or implement 
support for online connections?



Thanks, - Jeff

___
gnucash-user mailing list
gnucash-u...@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.

-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


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

Gnucash 2.6.8-1 and MacOS 10.11 - bad news

[Jeff Earickson]

Hi,

I have bad news for Gnucash users who upgrade to Mac OSX 10.11 (El
Capitan).  The program will not launch.  In non-admin mode, you get the
splash screen and the spinning beachball of death; you have to kill it via
Force Quit.  In admin mode, you get this plus a black console window with
nothing in it.  I upgraded my laptop to test 10.11 and quickly found this
out.  My main system will remain 10.10 for awhile.

This may have something to do with the version of Xcode that it was built
with (v 7 has had issues), or it may be something deeper.

FYI, another of my favorite programs, Totalspaces2 (
http://totalspaces.binaryage.com/) has really
fundamental problems because of 10.11's new System Integrity Protection.
See http://totalspaces.binaryage.com/elcapitan for this author's unhappy
recommendation.  I would not expect SIP to affect Gnucash, but you never
know.

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

Re: Using LibreOffice for Documentation

[Jeff Warnica]

Git can automatically unpack the zips and do the needful on this raw XML.
Apparently.

https://tante.cc/2010/06/23/managing-zip-based-file-formats-in-git/
On Sep 4, 2015 8:26 AM, "Mike Evans"  wrote:

> On Fri, 04 Sep 2015 11:48:16 +0200
> Geert Janssens  wrote:
>
> > I never new something as a master document existed in libreoffice. I'm
> learning a lot from this
> > thread :)
> >
> > Other than the concerns Tommy Trussell already mentioned I worry about
> merging.
> >
> > Can you run this test:
> > 1. make two branches
> > 2. Make independent changes in both branches
> > 3. merge from one branch to the other
> >
> >
> > Regards,
> >
> > Geert
>
> This breaks things.
>
> My simple test:
> git checkout -b 1
> edit
> git ci -a
> git checkout master
> git checkout -b 2
> edit
> git ci -a
>
> git merge 1
>
> warning: Cannot merge binary files: ch_loans.odt (HEAD vs. 1)
> Auto-merging ch_loans.odt
> CONFLICT (content): Merge conflict in ch_loans.odt
> Automatic merge failed; fix conflicts and then commit the result.
>
> Note the cannot merge part.
>
> I guess that resolves that then.  No to LibreOffice docs, or I guess any
> non-plain text file format.
>
> I know we could unzip the odt files to get the plain text content and work
> with that but I'm it's not really a practical solution is it?
>
> Mike E
>
> --
> PGP key:
> http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53
> ___
> 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

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

[Jeff Kletsky]

then continue.

*** success *** [65/65]

=

Once I get a reliable build process, I'm going to throw ccache in. I 
don't think it will help the build of guile though -- expect that to 
take a while and chew up all the cores your machine has in the process.


=

OK, so now that it's built, I am unable to successfully run it. There is 
no gnucash-launcher in either ~/gtk/bin or ~/gnucash-stable/bin as 
called out on http://wiki.gnucash.org/wiki/MacOSX/Quartz. In fact, 
there isn't one anywhere that

find ~ -name gnucash-launcher
can find.

So, trying ~/gnucash-stable/bin/gnucash results in the UI starting to 
render, then nearly immediately dying with


~/gnucash-stable$ ./bin/gnucash
main: Error on gnc_gbr_init: Unable to open /proc/self/maps for reading.
2015-03-15 15:31:51.392 gnucash[74284:507] *** WARNING: Method 
userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It 
should not be used in new applications. Use convertRectToBacking: instead.

Backtrace:
In unknown file:
   ?: 19 [apply-smob/1 #catch-closure a121650]
   ?: 18 [call-with-input-string (use-modules (gnucash engine)) ...]
In ice-9/boot-9.scm:
2401: 17 [save-module-excursion #procedure a5f8090 at 
ice-9/eval-string.scm:65:9 ()]

In ice-9/eval-string.scm:
  44: 16 [read-and-eval #input: string a0fe7e0 #:lang ...]
  37: 15 [lp (use-modules (gnucash engine))]
In ice-9/eval.scm:
 505: 14 [#procedure a0150e0 at ice-9/eval.scm:499:4 (exp) 
(use-modules #)]

In ice-9/psyntax.scm:
1106: 13 [expand-top-sequence ((use-modules (gnucash engine))) () ...]
 989: 12 [scan ((use-modules (gnucash engine))) () ...]
 279: 11 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...]
In ice-9/boot-9.scm:
3597: 10 [process-use-modules (((gnucash engine)))]
 702: 9 [map #procedure a0f10b0 at ice-9/boot-9.scm:3597:25 
(mif-args) ((#))]

3598: 8 [#procedure a0f10b0 at ice-9/boot-9.scm:3597:25 (mif-args) (#)]
2864: 7 [resolve-interface (gnucash engine) #:select ...]
2789: 6 [#procedure a0eece0 at ice-9/boot-9.scm:2777:4 (name #:optional 
autoload version #:key ensure) # ...]

3065: 5 [try-module-autoload (gnucash engine) #f]
2401: 4 [save-module-excursion #procedure a206b58 at 
ice-9/boot-9.scm:3066:17 ()]

3085: 3 [#procedure a206b58 at ice-9/boot-9.scm:3066:17 ()]
In unknown file:
   ?: 2 [primitive-load-path gnucash/engine ...]
In engine.scm:
   7: 1 [#procedure a167030 ()]
In unknown file:
   ?: 0 [load-extension libgncmod-engine scm_init_sw_engine_module]

ERROR: In procedure load-extension:
ERROR: In procedure dynamic-link: file: libgncmod-engine, message: 
file not found


Again, no libgncmod-engine in ~/gnucash-stable nor is there any 'engine' 
directory to be find-ed under ~ other than the source directory, 
gtk/source/gnucash-2.6.5/src/engine



So, Question 1:

=== What am I missing here in the build process?



Past that, it looks like the bundler is inconsistent with the actual 
output.


  data dest=${bundle}/Contents/Resources/lib/
${prefix}/lib/libgnc-qof.la
  /data

  data dest=${bundle}/Contents/Resources/lib/
${prefix}/lib/libgnc-*.la
  /data

Currently, .dylib libraries are being built, not .la libraries. When I 
get to the point of having a running GnuCash...



Question 2:

=== Should these references be changed to .dylib, or is there something 
else that needs to be done to get .la libraries?




Thanks,

Jeff


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

Re: gnucash-2.6.5 crash on Mac

[Jeff Earickson]

John,

I just downloaded 2.6.5-3 onto my work Mac and fired it up.  It bahaved.  I
will try it on my home Mac tonight.  Both are Intel, Mac 10.10.

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

gnucash-2.6.5 crash on Mac

[Jeff Earickson]

John et al,

Gnucash 2.6.5-1 crashed and burned on initial launch on my Mac, both as
admin and non-admin accounts.  The crash reporter output is attached.

I installed on a Win 8.1 system, and it launched fine there.

Merry Christmas,
Jeff Earickson


gnucash-2.65.crash
Description: Binary data
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash maint: Remove bare percent sign in taxinvoice.scm, replace with English.

[Jeff Earickson]

Geert,

Well, 10 percent and 32 pixels are literal examples too.  In my efforts
on getting the Indic language translations to compile, poedit and/or the
compile sequence always seems to choke on this spot.  The English
translation of:

:... e.g. 10% or 32px

ends up in the following translated string as:

[characters in Devanagari]% [more chars] 32px [more chars]

and the compiler sees the % as a bare character when it expects %d or
%s or \% or %% or something in proper C format.  Compiler error.

I have tried all of the usual C/perl forms of making it a compilable
string, like \%, %%, adding a space in front of it -- no success.  My
usual work-around is to simply remove the percent sign, which is wrong.  I
am open to suggestions here.

I am hoping/assuming that most languages would have some equivalent of the
English word percent that could be used, even if it reads as parts per
hundred in the native language.  I am less concerned about changing px
to pixel, but I like proper English.

--- Jeff Earickson

On Tue, Oct 21, 2014 at 11:28 AM, Geert Janssens geert.gnuc...@kobaltwit.be
 wrote:

 On Monday 13 October 2014 13:53:51 John Ralls wrote:
  commit 289bfc2aefdf203881bc3e130cc98aa720e558df
  Author: Jeff Earickson jaear...@colby.edu
  Date:   Sun Oct 12 22:29:40 2014 -0400
 
  Remove bare percent sign in taxinvoice.scm, replace with English.
 
  The bare percent sign in this string messes with po translation
  files and causes difficulties compiling without backslashes and
  other pain.  Cleans up the English by using real words.
 
 I'm still pondering if this patch should have been applied or not.

 The '10%' and '32px' are literal examples of values to enter in the text
 box. '10 percent' and '32
 pixels' are not so the help message lost some of its helpfulness.

 What problems do you experience during translation ?

 Geert

  diff --git a/src/report/business-reports/taxinvoice.scm
  b/src/report/business-reports/taxinvoice.scm index 106f8d7..ce7c0ed
  100644
  --- a/src/report/business-reports/taxinvoice.scm
  +++ b/src/report/business-reports/taxinvoice.scm
  @@ -193,7 +193,7 @@
   (N_ Name of a file containing a logo to be used on
  the report.) ))
 (add-option (gnc:make-string-option
  -displaypage optname-logo-width f (N_ Width of the
  logo in CSS format, e.g. 10% or 32px. Leave blank to display the logo
  at its natural width. The height of the logo will be scaled
  accordingly.) )) +displaypage optname-logo-width
  f (N_ Width of the logo in CSS format, e.g. 10 percent or 32
  pixels. Leave blank to display the logo at its natural width. The
  height of the logo will be scaled accordingly.) )) (add-option
  (gnc:make-simple-boolean-option   displaypage
  optname-border-collapse 
  g (N_ Border-collapse?) #f)) (add-option
  (gnc:make-string-option   displaypage
  optname-border-color-th h (N_
  CSS color.) black)) (add-option
  (gnc:make-string-option   displaypage
  optname-border-color-td i (N_
  CSS color.) black))
 
 
 
  Summary of changes:
   src/engine/gnc-budget.c| 6 --
   src/report/business-reports/taxinvoice.scm | 2 +-
   2 files changed, 5 insertions(+), 3 deletions(-)
 
  ___
  gnucash-changes mailing list
  gnucash-chan...@gnucash.org
  https://lists.gnucash.org/mailman/listinfo/gnucash-changes

 ___
 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 maint: Remove bare percent sign in taxinvoice.scm, replace with English.

[Jeff Earickson]

Derek,

Hmmm...  Trying to reproduce here.  Sometimes msgfmt will compile the po
file fine, but poedit will complain, so the two are not consistent.

In the case I just tried, poedit said:

Error: 'msgstr'' is not a valid C format string, unlike 'msgid'.  Reason:
the character that erminates the directive number 1 is not a valid
conversion specifier.

But that same exact file just compiled with msgfmt just fine.  Ugh.


---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---

On Tue, Oct 21, 2014 at 12:20 PM, Derek Atkins de...@ihtfp.com wrote:

  Could you provide the exact compiler error you get, including the
 commands to reproduce it?

 -derek

 Sent on my mobile. Please forgive any typos.

 - Reply message -
 From: Jeff Earickson jaear...@colby.edu
 To: Geert Janssens geert.gnuc...@kobaltwit.be
 Cc: Gnucash-devel gnucash-devel@gnucash.org
 Subject: gnucash maint: Remove bare percent sign in taxinvoice.scm,
 replace with English.
 Date: Tue, Oct 21, 2014 11:56 AM

 Geert,

 Well, 10 percent and 32 pixels are literal examples too.  In my efforts
 on getting the Indic language translations to compile, poedit and/or the
 compile sequence always seems to choke on this spot.  The English
 translation of:

 :... e.g. 10% or 32px

 ends up in the following translated string as:

 [characters in Devanagari]% [more chars] 32px [more chars]

 and the compiler sees the % as a bare character when it expects %d or
 %s or \% or %% or something in proper C format.  Compiler error.

 I have tried all of the usual C/perl forms of making it a compilable
 string, like \%, %%, adding a space in front of it -- no success.  My
 usual work-around is to simply remove the percent sign, which is wrong.  I
 am open to suggestions here.

 I am hoping/assuming that most languages would have some equivalent of the
 English word percent that could be used, even if it reads as parts per
 hundred in the native language.  I am less concerned about changing px
 to pixel, but I like proper English.

 --- Jeff Earickson

 On Tue, Oct 21, 2014 at 11:28 AM, Geert Janssens geert.gnuc...@kobaltwit.be
  wrote:

  On Monday 13 October 2014 13:53:51 John Ralls wrote:
   commit 289bfc2aefdf203881bc3e130cc98aa720e558df
   Author: Jeff Earickson jaear...@colby.edu
   Date:   Sun Oct 12 22:29:40 2014 -0400
  
   Remove bare percent sign in taxinvoice.scm, replace with English.
  
   The bare percent sign in this string messes with po translation
   files and causes difficulties compiling without backslashes and
   other pain.  Cleans up the English by using real words.
  
  I'm still pondering if this patch should have been applied or not.
 
  The '10%' and '32px' are literal examples of values to enter in the text
  box. '10 percent' and '32
  pixels' are not so the help message lost some of its helpfulness.
 
  What problems do you experience during translation ?
 
  Geert
 
   diff --git a/src/report/business-reports/taxinvoice.scm
   b/src/report/business-reports/taxinvoice.scm index 106f8d7..ce7c0ed
   100644
   --- a/src/report/business-reports/taxinvoice.scm
   +++ b/src/report/business-reports/taxinvoice.scm
   @@ -193,7 +193,7 @@
(N_ Name of a file containing a logo to be used on
   the report.) ))
  (add-option (gnc:make-string-option
   -displaypage optname-logo-width f (N_ Width of the
   logo in CSS format, e.g. 10% or 32px. Leave blank to display the logo
   at its natural width. The height of the logo will be scaled
   accordingly.) )) +displaypage optname-logo-width
   f (N_ Width of the logo in CSS format, e.g. 10 percent or 32
   pixels. Leave blank to display the logo at its natural width. The
   height of the logo will be scaled accordingly.) )) (add-option
   (gnc:make-simple-boolean-option   displaypage
   optname-border-collapse 
   g (N_ Border-collapse?) #f)) (add-option
   (gnc:make-string-option   displaypage
   optname-border-color-th h (N_
   CSS color.) black)) (add-option
   (gnc:make-string-option   displaypage
   optname-border-color-td i (N_
   CSS color.) black))
  
  
  
   Summary of changes:
src/engine/gnc-budget.c| 6 --
src/report/business-reports/taxinvoice.scm | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
  
   ___
   gnucash-changes mailing list
   gnucash-chan...@gnucash.org
   https://lists.gnucash.org/mailman/listinfo/gnucash-changes
 
  ___
  gnucash-devel mailing list
  gnucash-devel@gnucash.org
  https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 
 ___
 gnucash-devel mailing 
 listgnucash-devel@gnucash.orghttps

Re: gnucash maint: Remove bare percent sign in taxinvoice.scm, replace with English.

[Jeff Earickson]

Buddha is right.  It says in CSS format right there in the message
string.  Cascading Style Sheets did not register in my mind, I was too
focused on the % sign.  I will withdraw this in bugzilla.

- Jeff Earickson

On Tue, Oct 21, 2014 at 12:11 PM, Buddha Buck blaisepas...@gmail.com
wrote:

 But in the message to be translated, 10% and 32px are not English,
 they are CSS. Translating them as if they were English would give the wrong
 result -- you can't, in a Chinese-translated version, enter 10百分 into the
 text box specified and have it work right; it has to be 10%. The same
 goes with the 32px as well.

 If the % is giving trouble, there are other CSS width specifiers that
 could work as alternative examples: 2em, 24pt, 1cm, etc. None are
 equivalent to either 10% or 32px, but neither of those are equivalent
 to each other, either.


 On Tue, Oct 21, 2014 at 11:56 AM, Jeff Earickson jaear...@colby.edu
 wrote:

 Geert,

 Well, 10 percent and 32 pixels are literal examples too.  In my
 efforts
 on getting the Indic language translations to compile, poedit and/or the
 compile sequence always seems to choke on this spot.  The English
 translation of:

 :... e.g. 10% or 32px

 ends up in the following translated string as:

 [characters in Devanagari]% [more chars] 32px [more chars]

 and the compiler sees the % as a bare character when it expects %d
 or
 %s or \% or %% or something in proper C format.  Compiler error.

 I have tried all of the usual C/perl forms of making it a compilable
 string, like \%, %%, adding a space in front of it -- no success.  My
 usual work-around is to simply remove the percent sign, which is wrong.  I
 am open to suggestions here.

 I am hoping/assuming that most languages would have some equivalent of the
 English word percent that could be used, even if it reads as parts per
 hundred in the native language.  I am less concerned about changing px
 to pixel, but I like proper English.

 --- Jeff Earickson

 On Tue, Oct 21, 2014 at 11:28 AM, Geert Janssens 
 geert.gnuc...@kobaltwit.be
  wrote:

  On Monday 13 October 2014 13:53:51 John Ralls wrote:
   commit 289bfc2aefdf203881bc3e130cc98aa720e558df
   Author: Jeff Earickson jaear...@colby.edu
   Date:   Sun Oct 12 22:29:40 2014 -0400
  
   Remove bare percent sign in taxinvoice.scm, replace with English.
  
   The bare percent sign in this string messes with po translation
   files and causes difficulties compiling without backslashes and
   other pain.  Cleans up the English by using real words.
  
  I'm still pondering if this patch should have been applied or not.
 
  The '10%' and '32px' are literal examples of values to enter in the text
  box. '10 percent' and '32
  pixels' are not so the help message lost some of its helpfulness.
 
  What problems do you experience during translation ?
 
  Geert
 
   diff --git a/src/report/business-reports/taxinvoice.scm
   b/src/report/business-reports/taxinvoice.scm index 106f8d7..ce7c0ed
   100644
   --- a/src/report/business-reports/taxinvoice.scm
   +++ b/src/report/business-reports/taxinvoice.scm
   @@ -193,7 +193,7 @@
(N_ Name of a file containing a logo to be used on
   the report.) ))
  (add-option (gnc:make-string-option
   -displaypage optname-logo-width f (N_ Width of the
   logo in CSS format, e.g. 10% or 32px. Leave blank to display the logo
   at its natural width. The height of the logo will be scaled
   accordingly.) )) +displaypage optname-logo-width
   f (N_ Width of the logo in CSS format, e.g. 10 percent or 32
   pixels. Leave blank to display the logo at its natural width. The
   height of the logo will be scaled accordingly.) )) (add-option
   (gnc:make-simple-boolean-option   displaypage
   optname-border-collapse 
   g (N_ Border-collapse?) #f)) (add-option
   (gnc:make-string-option   displaypage
   optname-border-color-th h (N_
   CSS color.) black)) (add-option
   (gnc:make-string-option   displaypage
   optname-border-color-td i (N_
   CSS color.) black))
  
  
  
   Summary of changes:
src/engine/gnc-budget.c| 6 --
src/report/business-reports/taxinvoice.scm | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
  
   ___
   gnucash-changes mailing list
   gnucash-chan...@gnucash.org
   https://lists.gnucash.org/mailman/listinfo/gnucash-changes
 
  ___
  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

Indic Language Kannada translation file (new)

[Jeff Earickson]

All,

I have opened the following enhancement at Bugzilla for the Kannada
translation file:

*Bug 738827* https://bugzilla.gnome.org/show_bug.cgi?id=738827 - Addition
of Indic Language Kannada Translation file

The appropriate files are in git format-patch format, against git-master.

---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Gujarati Translation file submitted

[Jeff Earickson]

All,

The Gujarati translation file has been cleaned up so it will compile, and
submiited as:

*Bug 738828* https://bugzilla.gnome.org/show_bug.cgi?id=738828 - Addition
of Indic Language Gujarati translation

in the usual git format-patch form.

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

Konkani Latin script translation

[Jeff Earickson]

All,

The (new/revised) Konkani translation in Latin script has been submitted as:

*Bug 738829* https://bugzilla.gnome.org/show_bug.cgi?id=738829 - Indic
Language Konkani translation in Latin Script (new)

to Bugzilla for further processing.

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

Re: GNUCash translations (2.6.3)

[Jeff Earickson]

Dear Mr. Dhutadmal,

I took a quick look at the four po files tonight with poedit.  My comments:

Kannada: the percent error in poedit, explained below.
Asamese: the po file is clean and ready to go according to poedit.
Gujarati: poedit complains about 20 errors in this file, so it needs to be
looked at.
Konkani-roman: 6 errors

I urge your team to use the handy program poedit (http://poedit.net) to
test your po files and look for errors via the validate button.
Please, please download this program and use it.

The most common problems I see are:

1) a msgstr ending with {space} instead of  (no space).  Poedit tends
to be obscure about this, but I find and fix these issues with vi.

2) The line

msgid Width of the logo in CSS format, e.g. 10% or 32px.

always causes problems because of that percent sign (%) in there.  The
percent sign gets reinterpreted by the compiler (eg, %s means string in
C), so I wish it were not there in the translation files.  Just for the
sake of better English, the line should say:

Width of the logo in CSS format, e.g 10 percent or 32 pixels...

So far, I generally just remove the percent sign from the translated
language, which may cause confusion.

I will work on these four files in the near future as I get time.


---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---

On Wed, Oct 8, 2014 at 12:12 AM, chandrakant dhutadmal 
cpdhutad...@yahoo.com wrote:

 Dear Team, Please find the translations of few new languages. Following
 are the languages for which GNUCash (2.6.3) translations are available and
 are attached for further development process.
 1. Gujarati
 2. Konkani (Roman Script)

 Regards,Chandrakant Dhutadmal.C-DAC, Pune. India.Mobile- 982305012.

 ___
 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: ***UNCHECKED*** Indic Language git-format files (enhancement bug 737398)

[Jeff Earickson]

Geert,

Sorry about that.  I went back and touched all of the po files that I added
and did a rebuild via the jhbuild shell.  Both the kok.po and mr.po had
problems, now fixed.  I have posted a gzipped tarfile indic-fix.tar.gz to
bugzilla, ie Attachment 287217 added to Bug 737398.  I hope this gets the
Indic languages going.  Thank you.

--- Jeff Earickson

On Fri, Sep 26, 2014 at 1:03 PM, Geert Janssens geert.gnuc...@kobaltwit.be
wrote:

 On Thursday 25 September 2014 22:08:24 Jeff Earickson wrote:
  All,
 
  At the risk of annoying people, I am sending a gzipped tarfile of
  git-format patches to the mailing list for bugzilla enhancement
  737398. Bugzilla rejected my attachment as too large, I hope this
  email does not suffer the same fate.
 
  Jeff Earickson
 Hi Jeff,

 Thank you for the patches. I have applied them locally to test.
 Unfortunately I get a couple of build errors:

 /kobaltnet/janssege/Development/gnucash/gnucash/po/kok.po:15312: 'msgid'
 and 'msgstr' entries do not both begin with '\n'
 /usr/bin/msgfmt: found 1 fatal error
 file=`echo nl | sed 's,.*/,,'`.gmo \
rm -f $file  /usr/bin/msgfmt -o $file
 /kobaltnet/janssege/Development/gnucash/gnucash/po/nl.po
 make[2]: *** [kok.gmo] Error 1
 make[2]: *** Waiting for unfinished jobs
 /kobaltnet/janssege/Development/gnucash/gnucash/po/mr.po:5285: 'msgid'
 and 'msgstr' entries do not both begin with '\n'
 /kobaltnet/janssege/Development/gnucash/gnucash/po/mr.po:5313: 'msgid'
 and 'msgstr' entries do not both begin with '\n'
 /kobaltnet/janssege/Development/gnucash/gnucash/po/mr.po:18465: 'msgid'
 and 'msgstr' entries do not both end with '\n'
 /kobaltnet/janssege/Development/gnucash/gnucash/po/mr.po:19025: 'msgid'
 and 'msgstr' entries do not both end with '\n'
 /usr/bin/msgfmt: found 4 fatal errors


 Can you look into these ?

 Thank you.

 Geert

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

Re: GNUCash Translation Files- Additional Languages

[Jeff Earickson]

All,

I got gnucash recompiled last night (boost slowed me down), so I am hoping
to grab the po files this evening and add them to the code base, then open
a bug in bugzilla to add them in git-patch mode for others to pick up.

--- Jeff Earickson

On Thu, Sep 25, 2014 at 10:16 AM, Geert Janssens geert.gnuc...@kobaltwit.be
 wrote:

 Hi Chandrakant,

 I did not see the e-mail you refer to.

 List, did someone else see such mail ? Just to be sure it didn't get
 blocked by my ISP's mail filter.

 Geert

 On Wednesday 24 September 2014 21:35:54 chandrakant dhutadmal wrote:
  Hi Geert.
 
  Did you get my yesterday's mail with all updated and renamed PO files
  ? reason behind asking is that i got a failure message in delivering
  it to your email id. Also, it would be great if you can cross check
  with someone if the developer list got the mail.
 
  Regards
  Chandrakant Dhutadmal
  C-DAC, Pune, India.
 
 
 
 
  On Wednesday, September 24, 2014 12:47 PM, Geert Janssens
  geert.gnuc...@kobaltwit.be wrote:
  On Tuesday 23 September 2014 20:52:10 chandrakant dhutadmal wrote:
   Hi Geert.
  
   Question- First, I notice you have sent the same translations
   yesterday already. What made you send them again ?
  
   Answer- I had sent them from my another email id, which was not
   subscribed to the mailing list. Since i thought, my email may not
   get
   delivered to the list, i subscribed from my yahoo mail and sent it
   again. Sorry for inconvenience and confusion.
 
  Hi Chandrakant,
 
  That's reasonable. I didn't notice the different e-mail addresses.
  Both submissions eventually made it to the list because we have a
  great moderator that manually separate the spam from real messages
  from people not subscribed to the list. (BTW, thanks for that effort
  Liz !)
 
  I'm looking forward to your updated submissions.
 
 
  Regards,
 
  Geert

 ___
 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

Translation files, ISO 639-1 or 639-2 prefered?

[Jeff Earickson]

All,


What is the preferred language code for the po directory, 639-1 (two
letter) or 639-02 (three letter)?  Should something like Hindi be hi.po
or hin.po?

I am looking at the pile of Indian translations sent in tonight.  The po
files are nice and clean, some of the new ones will replace earlier
releases.

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

Re: Translation files, ISO 639-1 or 639-2 prefered?

[Jeff Earickson]

Gang,

For those Indic languages that have 639-1 codes, I used them.  Otherwise, I
used the 639-2 codes.  This seemed to be the convention that I saw in the
po subdirectory.

Most Indic languages have two-letter codes.

Jeff Earickson

On Thu, Sep 25, 2014 at 9:32 PM, David T. sunfis...@yahoo.com wrote:

 The problem is that ISO has multiple code versions, and Jeff wants to know
 which version GnuCash will use. According to ISO:

ISO 639 is composed of six different parts

- Part 1 (ISO 639-1:2002) provides a 2 letter code that has been
designed to represent most of the major languages of the world.
- Part 2 (ISO 639-2:1998) provides a 3 letter code, which gives more
possible combinations, so ISO 639-2:1998 can cover more languages.
- Part 3 (ISO 639-3:2007) provides a 3 letter code and aims to give as
complete a listing of languages as possible, including living, extinct and
ancient languages.
- Part 4 (ISO 639-4:2010) gives the general principles of language
coding and lays down guidelines for the use of ISO 639.
- Part 5 (ISO 639-5:2008) provides a 3 letter code for language
families and groups (living and extinct).
- Part 6 (ISO 639-6:2009) provides a 4 letter code, useful when there
is a potential need to cover the entire range of languages, language
families and groups and language variants in a system.

 All 5 languages listed originally have both two and three letter codes.


 David

 On Sep 25, 2014, at 5:49 PM, Derek Atkins de...@ihtfp.com wrote:

 Probably the former, 2-letter codes...
 Whatever the official locale codes are.

 -derek

 Sent on my mobile. Please forgive any typos.

 - Reply message -
 From: Jeff Earickson jaear...@colby.edu
 To: gnucash-devel@gnucash.org
 Subject: Translation files, ISO 639-1 or 639-2 prefered?
 Date: Thu, Sep 25, 2014 7:34 PM

 All,


 What is the preferred language code for the po directory, 639-1 (two
 letter) or 639-02 (three letter)?  Should something like Hindi be hi.po
 or hin.po?

 I am looking at the pile of Indian translations sent in tonight.  The po
 files are nice and clean, some of the new ones will replace earlier
 releases.

 Jeff Earickson
 ___
 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: GNUCash Translation Files- Additional Languages

[Jeff Earickson]

Geert,

I was hoping to look at Mr. Dhutadmal's new submissions in the next couple
of days, and go through the setup/compile/test/submit procedure for them.
Right now I am struggling to get gnucash to compile since I didn't do
anything over the summer (travel/work/sun) and technology has changed in
MacOS with newer versions of MacOS and Xcode.  He and I had worked on a
couple of Indian language translations earlier this Spring, which I hope
will appear in the next release.

---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---

On Tue, Sep 23, 2014 at 10:38 AM, Geert Janssens geert.gnuc...@kobaltwit.be
 wrote:

 Hi Chandrakant Dhutadmal,

 Thank you for your submission of these translations.

 I have a few questions for you.

 First, I notice you have sent the same translations yesterday already.
 What made you send them again ?

 Secondly, to include the files in gnucash I would need to know the iso
 abbreviation of each of the languages.

 There is one I know: for Konkani in Devnagari script we use 'kok'. Can
 you provide me the proper codes for Bodo, Hindi, KashmiriDV, Marathi,
 Tamil, Telugu and Urdu ?

 Next I notice that most of the header sections are incomplete:
 Can you fill in the missing pieces ? These parts need some additional
 info in all the files you have submitted:

 # SOME DESCRIPTIVE TITLE.
 # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
 # This file is distributed under the same license as the PACKAGE
 package.
 # FIRST AUTHOR EMAIL@ADDRESS, YEAR.
 #
 msgid 
 msgstr 
 Project-Id-Version: PACKAGE VERSION\n
 Report-Msgid-Bugs-To: \n
 POT-Creation-Date: 2014-04-24 10:10-0400\n
 PO-Revision-Date: 2014-06-06 17:45+0530\n
 Last-Translator: a b\n
 Language-Team: Tamil kde-i18n-...@kde.org\n
 Language: \n
 MIME-Version: 1.0\n
 Content-Type: text/plain; charset=UTF-8\n
 Content-Transfer-Encoding: 8bit\n
 Plural-Forms: nplurals=2; plural=n != 1;\n

 You can look at the already existing translation files to learn what
 this header typically looks like. The existing translations can be found
 here:
 https://github.com/Gnucash/gnucash/tree/master/po
 If in doubt, feel free to ask for some additional help.

 And finally, it would help a lot if the files were already named using
 the iso abbreviation of the language, just like it is done with the
 translations in the above link. So for example the Konkani file would be
 named kok.po.

 If you can correct these small issues, I'd be more than happy to include
 these great contributions in our code !

 Thank you for this effort.

 Geert

 On Tuesday 23 September 2014 03:14:23 chandrakant dhutadmal wrote:
  Dear Team,
 
  We have come up with the translations of few new languages. Following
  are the languages for which GNUCash (2.6.3) translations are
  available and are attached for further development process.
 
  1. Marathi
  2. Tamil
  3. Telugu
  4. Urdu
 
  Regards,
  Chandrakant Dhutadmal
  C-DAC, Pune. India.

 ___
 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: Compiling on OSX (was: GNUCash Translation Files- Additional Languages)

[Jeff Earickson]

John,

I could never get gnucash to compile with Xcode 5.x, I remained at 4.x last
Spring.  I just discovered that my work box had 5.1 (I thought it had 4.x),
so I bumped it up to Xcode 6.0.1 and I am trying a gnucash compile again,
starting from scratch.  If I get things to work here, then I will duplicate
the effort on my home box, which is where I spend my quality Gnucash time.
I'm currently at Mac OS 10.9.5.

---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---

On Tue, Sep 23, 2014 at 11:07 AM, John Ralls jra...@ceridwen.us wrote:


 On Sep 23, 2014, at 7:51 AM, Jeff Earickson jaear...@colby.edu wrote:

  Geert,
 
  I was hoping to look at Mr. Dhutadmal's new submissions in the next
 couple
  of days, and go through the setup/compile/test/submit procedure for them.
  Right now I am struggling to get gnucash to compile since I didn't do
  anything over the summer (travel/work/sun) and technology has changed in
  MacOS with newer versions of MacOS and Xcode.  He and I had worked on a
  couple of Indian language translations earlier this Spring, which I hope
  will appear in the next release.

 Jeff,

 If the problem you're having with building on OSX is with Xcode 5.1 and
 Guile hanging, pull the latest gnucash-on-osx. I just got last Thursday a
 patch from the Guile folks that fixes the hang; in the process I've
 switched to Guile2. With that I was able to build GC on Yosemite.

 If you're having other problems I can probably help with that, too.

 Regards,
 John Ralls


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

Re: Compile error current master

[Jeff Earickson]

On a Mac (10.9.2, Xcode 5.0.2) I get a slightly different error:

Making all in qof
Making all in .
/bin/sh ../../../libtool  --tag=CC   --mode=compile
/Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DHAVE_CONFIG_H -I.
-I../../..  -I../../../lib/libc -I../../../src -D_REENTRANT
-I/Users/jaearick/gnucash-project/gnucash-git/include/glib-2.0
-I/Users/jaearick/gnucash-project/gnucash-git/lib/glib-2.0/include
-DG_LOG_DOMAIN=\qof\
-I/Users/jaearick/gnucash-project/gnucash-git/include
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-xc++ -Werror -Wdeclaration-after-statement -Wno-pointer-sign
-D_FORTIFY_SOURCE=2 -arch i386
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-mmacosx-version-min=10.9 -Wno-unused -MT libgnc_qof_la-gnc-date.lo -MD -MP
-MF .deps/libgnc_qof_la-gnc-date.Tpo -c -o libgnc_qof_la-gnc-date.lo `test
-f 'gnc-date.c' || echo './'`gnc-date.c
libtool: compile:  /Applications/Xcode.app/Contents/Developer/usr/bin/gcc
-DHAVE_CONFIG_H -I. -I../../.. -I../../../lib/libc -I../../../src
-D_REENTRANT -I/Users/jaearick/gnucash-project/gnucash-git/include/glib-2.0
-I/Users/jaearick/gnucash-project/gnucash-git/lib/glib-2.0/include
-DG_LOG_DOMAIN=\qof\
-I/Users/jaearick/gnucash-project/gnucash-git/include
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-xc++ -Werror -Wdeclaration-after-statement -Wno-pointer-sign
-D_FORTIFY_SOURCE=2 -arch i386
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-mmacosx-version-min=10.9 -Wno-unused -MT libgnc_qof_la-gnc-date.lo -MD -MP
-MF .deps/libgnc_qof_la-gnc-date.Tpo -c gnc-date.c  -fno-common -DPIC -o
.libs/libgnc_qof_la-gnc-date.o
mv -f .deps/libgnc_qof_la-gnc-date.Tpo .deps/libgnc_qof_la-gnc-date.Plo
make[5]: *** No rule to make target `gnc-numeric.c', needed by
`gnc-numeric.lo'.  Stop.


---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---


On Sat, Apr 26, 2014 at 6:25 AM, Herbert Thoma 
herbert.th...@iis.fraunhofer.de wrote:

 Am 26.04.2014 11:13, schrieb Geert Janssens:

 On Saturday 26 April 2014 11:07:50 Herbert Thoma wrote:

 Hi,

 I get the following error when I try to build the current master
 branch:

 make[5]: Entering directory
 `/home/tma/gnucash/gnucash_cvs/gnucash/src/libqof/qof' /bin/sh

 ...

 [-Werror] cc1plus: error: command line option '-Wmissing-prototypes'
 is valid for C/ObjC but not for C++ [-Werror] cc1plus: all warnings
 being treated as errors
 make[5]: *** [libgnc_qof_la-gnc-date.lo] Fehler 1
 make[5]: Leaving directory
 `/home/tma/gnucash/gnucash_cvs/gnucash/src/libqof/qof'

 When did we start with C++?

  Yesterday.

 John committed the first few patches to compile libqof as a c++ library.

 But apparently there's an issue with gcc and these patches. See also bug
 https://bugzilla.gnome.org/show_bug.cgi?id=729001


 Ah I see.

 BTW: if I supply --disable-error-on-warning to configure, it does not get
 much
 further:

 kvp_frame.c: In function 'KvpFrame* get_trailer_make(KvpFrame*, const
 char*, char**)':
 kvp_frame.c:329:38: error: invalid conversion from 'const char*' to
 'char*' [-fpermissive]
 kvp_frame.c: In function 'const KvpFrame* get_trailer_or_null(const
 KvpFrame*, const char*, char**)':
 kvp_frame.c:371:38: error: invalid conversion from 'const char*' to
 'char*' [-fpermissive]
 make[5]: *** [libgnc_qof_la-kvp_frame.lo] Error 1

 C++ is much stricter with types than plain C ...

  Herbert.

  Geert

  ___
 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

Konkani translations, bugzilla 728768

[Jeff Earickson]

John et al,

Following the instructions at
http://wiki.gnucash.org/wiki/Translation#Naming_Convention, I have opened
bug 728768 as an enhancement and attached my git format-patch files from
my konkani
branch, relative to the current master, to the bugzilla info.

I have been going back and forth via email with Chandrakant Dhutadmal to
get issues fixed from his original po files that prevented his versions
from compiling, and fixed other issues at my end with poedit.  My compiled
version of gnucash works with Konkani in the Devanagari script when I set
the primary language on my Mac to Konkani via System Preferences.

I hope this helps the cause.

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

Re: Translations of GNUCash into Konkani Language

[Jeff Earickson]

John,

Per your input, I have renamed the two files (for the moment)
k...@devanagari.po and k...@latin.po.  After poking around in
/usr/share/locale on various systems for clarification and googling, maybe
k...@devanagari.po should simply be kok.po -- the language in its
commonly used alphabet.

I am still puzzling over how to get gnucash to run.  I converted my Mac
into Spanish via System Preferences-Language/Region and had no problems
with gnucash in Spanish.  No fiddling with LANG/LANGUAGE/LC variables.  Muy
bien.  I then selected Konkani as my primary language on my Mac (not much
changed except for dates and times).  No go with gnucash.  I stared at
http://wiki.gnucash.org/wiki/Locale_Settings and I am still experimenting.


---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---


On Sat, Mar 29, 2014 at 12:54 PM, John Ralls jra...@ceridwen.us wrote:


 On Mar 29, 2014, at 8:39 AM, Jeff Earickson jaear...@colby.edu wrote:

  John,
 
  I searched around in my Fedora 20 system for any sign of kok files and
 did not find any as an example.
  Would kok_IN.po (for devanagari) and kok_roa_IN.po be acceptable?  I
 find at signs in file names distasteful.

 No, and your personal taste is immaterial.

 For an example of two scripts for a single language on Fedora, see
 /usr/share/locale/uz@Latn and /usr/share/locale/uz@cyrillic, or
 en@cyrillic, en@hebrew, en@piglatin, etc.

 Country codes are generally only used on po files when there are different
 forms of the language used in different countries. Common examples are
 en_US vs. en_GB and pt_PT vs. pt_BR.


 
  Everything compiles, but no go at launch time.  I get:
 
  k$ LANG=kok_IN LC_ALL=kok_IN ./gnucash
  Application Path
 /Users/jaearick/gnucash-project/gnucash-git/bin/./gnucash
 
  (process:5279): Gtk-WARNING **: Locale not supported by C library.
  Using the fallback 'C' locale.
 
  Backtrace:
  In
 /Users/jaearick/gnucash-project/gnucash-git/share/gnucash/guile-modules/gnucash/main.scm:
76: 0* [setlocale 0 ]
 
 
 /Users/jaearick/gnucash-project/gnucash-git/share/gnucash/guile-modules/gnucash/main.scm:76:1:
 In procedure setlocale in expression (setlocale LC_ALL ):
 
 /Users/jaearick/gnucash-project/gnucash-git/share/gnucash/guile-modules/gnucash/main.scm:76:1:
 Invalid argument
 
  Does this mean fiddling with the gtk library or some issue with gnucash
 itself?  Is some initial setting needed in src/scm/main.scm for LANG?

 It means setlocale() can't find entries for all of the required LC_FOO
 subdirectories, so it fails. The way to use an unsupported language is to
 include it in $LANGUAGE so that it's visible to gettext but not to
 setlocale().

 Regards,
 John Ralls


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

Re: Translations of GNUCash into Konkani Language

[Jeff Earickson]

John,

I can get the Spanish version of (devel) gnucash to work fine if I change
System Preferences-Language/Region to Spanish as the primary language and
then reboot my Mac.  But if I don't do this, and I want to get the
(development) version of gnucash to run in Spanish, no setting of
LANG/LANGUAGE/LC_* seems to do it.  The following of:

LANGUAGE=es LANG=es ./gnucash
(process:377): gnc.gui-WARNING **: [set_mac_locale()] Apple Locale is set
to a value en_IN not supported by the C runtime
(process:377): gnc.gui-WARNING **: [set_mac_locale()] Using en_IE instead.
(process:377): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
Backtrace:
In
/Users/jaearick/gnucash-project/gnucash-git/share/gnucash/guile-modules/gnucash/main.scm:
  76: 0* [setlocale 0 ]
/Users/jaearick/gnucash-project/gnucash-git/share/gnucash/guile-modules/gnucash/main.scm:76:1:
In procedure setlocale in expression (setlocale LC_ALL ):
/Users/jaearick/gnucash-project/gnucash-git/share/gnucash/guile-modules/gnucash/main.scm:76:1:
Invalid argument

Even if I explicitly define all of the LANG/LANGUAGE/LC_* environment
variables, same error.  Totally puzzled...

-Jeff

On Sun, Mar 30, 2014 at 11:20 AM, John Ralls jra...@ceridwen.us wrote:


 On Mar 30, 2014, at 7:40 AM, Jeff Earickson jaear...@colby.edu wrote:

 John,

 Per your input, I have renamed the two files (for the moment) 
 k...@devanagari.po and k...@latin.po.  After poking around in
 /usr/share/locale on various systems for clarification and googling, maybe 
 k...@devanagari.po should simply be kok.po -- the language in its
 commonly used alphabet.

 I am still puzzling over how to get gnucash to run.  I converted my Mac
 into Spanish via System Preferences-Language/Region and had no problems
 with gnucash in Spanish.  No fiddling with LANG/LANGUAGE/LC variables.  Muy
 bien.  I then selected Konkani as my primary language on my Mac (not much
 changed except for dates and times).  No go with gnucash.  I stared at
 http://wiki.gnucash.org/wiki/Locale_Settings and I am still experimenting.


 You need a plain kok.po because that's what's in the language list when
 you add it in system preferences. The easy way to test is to just add a
 symlink in $PREFIX/share/locale, e.g.:
   ln -s $PREFIX/share/locale/kok@devangari $PREFIX/share/kok

 Regards,
 John Ralls


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

Re: Translations of GNUCash into Konkani Language

[Jeff Earickson]

John,

Hah!  You were right!  It got gnucash to fire up without problems in the
Devanagari script when I did the following:

* put the kok symlink in share/locale to kok@devanagari
* set the primary language on my Mac to Konkani and rebooted
* then fired up gnucash with no fiddling of LANG or LC variables.

This may or may not be acceptable to you developers, but at least I'm
getting there.  This indicates that kok.po should be the filename, no?

--- Jeff

On Sun, Mar 30, 2014 at 11:20 AM, John Ralls jra...@ceridwen.us wrote:


 On Mar 30, 2014, at 7:40 AM, Jeff Earickson jaear...@colby.edu wrote:

 John,

 Per your input, I have renamed the two files (for the moment) 
 k...@devanagari.po and k...@latin.po.  After poking around in
 /usr/share/locale on various systems for clarification and googling, maybe 
 k...@devanagari.po should simply be kok.po -- the language in its
 commonly used alphabet.

 I am still puzzling over how to get gnucash to run.  I converted my Mac
 into Spanish via System Preferences-Language/Region and had no problems
 with gnucash in Spanish.  No fiddling with LANG/LANGUAGE/LC variables.  Muy
 bien.  I then selected Konkani as my primary language on my Mac (not much
 changed except for dates and times).  No go with gnucash.  I stared at
 http://wiki.gnucash.org/wiki/Locale_Settings and I am still experimenting.


 You need a plain kok.po because that's what's in the language list when
 you add it in system preferences. The easy way to test is to just add a
 symlink in $PREFIX/share/locale, e.g.:
   ln -s $PREFIX/share/locale/kok@devangari $PREFIX/share/kok

 Regards,
 John Ralls


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

Re: Translations of GNUCash into Konkani Language

[Jeff Earickson]

John,

I searched around in my Fedora 20 system for any sign of kok files and did
not find any as an example.
Would kok_IN.po (for devanagari) and kok_roa_IN.po be acceptable?  I find
at signs in file names distasteful.

Everything compiles, but no go at launch time.  I get:

k$ LANG=kok_IN LC_ALL=kok_IN ./gnucash
Application Path /Users/jaearick/gnucash-project/gnucash-git/bin/./gnucash

(process:5279): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.

Backtrace:
In
/Users/jaearick/gnucash-project/gnucash-git/share/gnucash/guile-modules/gnucash/main.scm:
  76: 0* [setlocale 0 ]

/Users/jaearick/gnucash-project/gnucash-git/share/gnucash/guile-modules/gnucash/main.scm:76:1:
In procedure setlocale in expression (setlocale LC_ALL ):
/Users/jaearick/gnucash-project/gnucash-git/share/gnucash/guile-modules/gnucash/main.scm:76:1:
Invalid argument

Does this mean fiddling with the gtk library or some issue with gnucash
itself?  Is some initial setting needed in src/scm/main.scm for LANG?

--- Jeff Earickson

On Sat, Mar 29, 2014 at 1:08 AM, John Ralls jra...@ceridwen.us wrote:


 On Mar 28, 2014, at 6:55 PM, Jeff Earickson jaear...@colby.edu wrote:

  Gnucash developer team,
 
  I have been looking at Mr. Dhutadmal's submission of two po files for the
  Konkani language (see his posting of March 19).  Per the discussion of
  http://wiki.gnucash.org/wiki/Translation,
  I have been working on his roman version of his po file, to get it to
  compile and work.  I am not there yet (compiles but won't execute with
  LANG=), but I have some questions.
 
  First: what to call his files?  The Konkani language has no ISO 639-1
 code,
  and a 639-2 code of kok.  How does one differentiate the same language
 with
  two alphabets, for the same country?
  I would guess kok_IN.po, but I need two files for the two alphabets.
  kok_roa_IN.po and kok_dev_IN.po?  Help...
 
  My plan (if I can get all of this to work), is to submit final changes
 back
  to the devel list as git format-patch files.
 
  Mr. Dhutadmal,
 
  Please find an attached diff of my resulting changes to your original
  file (konkani-roman-script.po) versus the file that I got to compile
  correctly in gnucash.  Please look over these changes.  Some of them were
  typos (extra \ characters or missing \n), but a couple would not
  compile without more serious changes.  Note my guesses for lines 495-501,
  12047-12053, 16574-16580.
 
  I have not tried to compile the devnagari script file yet.  Also please
  understand that I do not speak any language of India (other than
 English).
  And also please understand that I am fairly new to gnucash -- I am trying
  to help both you and the developers.
 

 I think you want to use kok for one and kok@roman or kok@devanagari for
 the other.
 This RedHat bug is germane:
 https://bugzilla.redhat.com/show_bug.cgi?id=458949

 Note that Gtk doesn't have a Konkani translation, so the standard controls
 will
 all be in English.

 Regards,
 John Ralls


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

Re: Translations of GNUCash into Konkani Language

[Jeff Earickson]

Gnucash developer team,

I have been looking at Mr. Dhutadmal's submission of two po files for the
Konkani language (see his posting of March 19).  Per the discussion of
http://wiki.gnucash.org/wiki/Translation,
I have been working on his roman version of his po file, to get it to
compile and work.  I am not there yet (compiles but won't execute with
LANG=), but I have some questions.

First: what to call his files?  The Konkani language has no ISO 639-1 code,
and a 639-2 code of kok.  How does one differentiate the same language with
two alphabets, for the same country?
I would guess kok_IN.po, but I need two files for the two alphabets.
kok_roa_IN.po and kok_dev_IN.po?  Help...

My plan (if I can get all of this to work), is to submit final changes back
to the devel list as git format-patch files.

Mr. Dhutadmal,

Please find an attached diff of my resulting changes to your original
file (konkani-roman-script.po) versus the file that I got to compile
correctly in gnucash.  Please look over these changes.  Some of them were
typos (extra \ characters or missing \n), but a couple would not
compile without more serious changes.  Note my guesses for lines 495-501,
12047-12053, 16574-16580.

I have not tried to compile the devnagari script file yet.  Also please
understand that I do not speak any language of India (other than English).
And also please understand that I am fairly new to gnucash -- I am trying
to help both you and the developers.

---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---


the.diffs
Description: Binary data
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: build gnucash-git woes with Mac OS, Xcode 5.1

[Jeff Earickson]

John,

Yes, I turned off optimization.  No go with 5.1.  Traditionally I always
used -g -O for gcc compiles.

I had wondered if the upgrade from 5.0.2 to 5.1 went ok on my home machine
(slow network), so I did a start-from-scratch build on my work box this
morning (which also has Xcode 5.1).  Same deal, it hangs at guile, trying
to create guile-procedures.texi.

Since I spend most of my time trying to get up to speed on gnucash at home,
I am going to leave Xcode 5.02 there.  I found the --force option for
jhbuild last night, so my first mission is to get a clean compile of
everything using the same compiler.  Having different chunks of the code
compiled with different versions of gcc/clang sounds like a recipe for
misery.


---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---


On Mon, Mar 17, 2014 at 10:42 PM, John Ralls jra...@ceridwen.us wrote:


 On Mar 17, 2014, at 2:46 PM, Jeff Earickson jaear...@colby.edu wrote:

  John,
 
  Bad news...  This is an XCode/gcc/lang feature/bug with guile.  I'll bet
 if you clean and rebuild your guile directory with 5.1 that it will choke
 (save a copy first).
 
  I removed Xcode 5.1 (using AppZapper) and reinstalled 5.0.2.  Then I
 fired up jhbuild build and guile flew past its previous hang point, happy
 as clam.  The info for Xcode 5.1 is:
 
  Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
 --with-gxx-include-dir=/usr/include/c++/4.2.1
  Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
  Target: x86_64-apple-darwin13.1.0
  Thread model: posix
 
  The info for Xcode 5.0.2 is:
 
  Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
 --with-gxx-include-dir=/usr/include/c++/4.2.1
  Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
  Target: x86_64-apple-darwin13.1.0
  Thread model: posix
 
  I'm going to do a jhbuild clean and recompile everything tonight so that
 I am using the same compiler version throughout.

 Thanks for troubleshooting. I've got lots of compilers, and I use the real
 gcc-4.2 from Xcode3.2 for releases, so I'm not overly worried.

 Did you try turning off optimization before you nuked 5.1?

 Regards,
 John Ralls


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

Re: build gnucash-git woes with Mac OS, Xcode 5.1

[Jeff Earickson]

John,

Bad news...  This is an XCode/gcc/lang feature/bug with guile.  I'll bet if
you clean and rebuild your guile directory with 5.1 that it will choke
(save a copy first).

I removed Xcode 5.1 (using AppZapper) and reinstalled 5.0.2.  Then I fired
up jhbuild build and guile flew past its previous hang point, happy as
clam.  The info for Xcode 5.1 is:

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

The info for Xcode 5.0.2 is:

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

I'm going to do a jhbuild clean and recompile everything tonight so that I
am using the same compiler version throughout.

---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---


On Sun, Mar 16, 2014 at 10:50 PM, John Ralls jra...@ceridwen.us wrote:


 On Mar 16, 2014, at 5:05 PM, Jeff Earickson jaear...@colby.edu wrote:

 John,

 Can you tell me what version of XCode you have installed?  5.0.2?  version
 of gcc? (Xcode 5.1 gives you 4.2.1 with clang = clang-503.0.38).  If you
 have not upgraded to XCode 5.1 (5B130a), then I suggest avoiding it.
 Aarrgh I just discovered that gdb is not available in Xcode with
 Mavericks.

 This issue of hanging at guile-procedures.texi seems to be known, see:
 http://gnu-guile.7481.n7.nabble.com/guile-2-0-9-build-on-mingw-td16967.html

 This URL didn't give me any real insight, except that others have seen it
 even with 2.x of guile.

 I tried various permutations of dropping into the jhbuild shell at
 failure, rerunning .configure with --enable-guile-debug (that gave other
 compiler errors), configure with --without-threads (suggested by the URL
 above, no help); trying to fiddle with CFLAGS in the Makefile to change
 compiler options, even in the libguile subdir where guile is built -- no
 love.  The compiler flags -g -O' did not change its behavior.

 I also downloaded guile-2.0.9, and wedged it into gtk/source like so:

 bash-3.2$ ls -ld guile*
 lrwxr-xr-x   1 jaearick  staff11 Mar 16 19:27 guile-1.8.8 -
 guile-2.0.9
 drwxr-xr-x  45 jaearick  staff  1530 Mar 16 19:40 guile-1.8.8.last
 drwxr-xr-x@ 49 jaearick  staff  1666 Mar 16 19:41 guile-2.0.9

 then jhbuild build.  It says configure: error: GNU libunistring is
 required, please install it.  So, I'm stuck for he moment.


 Both of my machines have upgraded to Xcode 5.1 already.

 If you want an older version you can get a free developer account from
 Apple and download an older version of Xcode from developer.apple.com.

 Xcode 4 and 5 have no gcc, only llvm, but Xcode 4 has a compatibility
 front end, llvm-gcc. Apparently llvm 3 rolled this into clang so that gcc
 is a link to clang, and if arg[0] is 'gcc' it runs in gcc compatibility
 mode.

 I'm busy with a Gramps problem ATM and won't have time to look at this
 until later next week.

 Regards,
 John Ralls


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

jhbuild complete clean and recompile?

[Jeff Earickson]

I did jhbuild clean and it seemed to do a make clean thru all
directories, but jhbuild build just checks for new versions to download
and then stops.  How to do a complete clean and recompile of all code?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

build gnucash-git woes with Mac OS, Xcode 5.1

[Jeff Earickson]

John et al,

I upgraded Xcode on my Mac (10.9.2) to Xcode 5.1 this week (gcc 4.2.1), and
I have tried a total-start-from-scratch build of gnucash-git.  My woes with
this:

* ~/gtk/source/webkit-1.6.1/GNUmakefile.am is missing -stdlibc=libstdc++
on line 120. (previously reported, and I know how to work around this).

* guile 1.8.8 hangs forever trying to create a texi file in libguile.  To
reproduce, I can do by hand:

$ pwd
/Users/jaearick/gtk/source/guile-1.8.8/libguile

$ cat *.doc | GUILE=/Users/jaearick/gtk/source/guile-1.8.8/pre-inst-guile
../scripts/snarf-check-and-output-texi
ERROR: Unbound variable: define  (hangs forever)
^C

The problem lies in the snarf-check-and-output-texi script, but I have no
idea what this does.  I tried to fake out this portion of the build by
simply doing cat *.doc  guile-procedures.texi, which will get the rest
of guile to build, with a bogus texi file.

* The build of gnucash-git did not like my fakery with guile, because it
will then hang during the configure for gnucash:

checking for GUILE... yes
checking for guile... /Users/jaearick/gnucash-git/bin/guile
checking for guile-config... /Users/jaearick/gnucash-git/bin/guile-config
checking for guile-tools... /Users/jaearick/gnucash-git/bin/guile-tools
checking if (www main) is available... (hangs forever)

^C*** Error during phase configure of gnucash-git: ## Error running
./autogen.sh  ./configure --prefix /Users/jaearick/gnucash-git --libdir
'/Users/jaearick/gnucash-git/lib' --enable-ofx --enable-aqbanking
--enable-binreloc --enable-dbi --with-html-engine=webkit  *** [62/62]

Any ideas please?

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

Re: build gnucash-git woes with Mac OS, Xcode 5.1

[Jeff Earickson]

John,

I took things down to the bare walls.  I rm'ed .git, gtk, gnucash*
everything.  I did not re-download .jhbuildrc-custom (because I had modifed
it), or gtk-osx-build-setup.sh, but everything else got nuked.  I was
trying to get everything herded into one subdirectory of my homedir, so I
didn't have .git, gnucash-git, and gtk scattered there (that didn't work).
  So I started by running gtk-osx-build-setup.sh, then the python build,
then bootstrap, then jhbuild build.  I was wondering if the XCode upgrade
would perturb life.

I will continue poking at guile and report back if I get anywhere.

BTW, I bought the O'Reilly book on Git and have been studying it, so I will
(hopefully) quit asking stupid questions there.  Git verges on magical in
terms of what it does.

Jeff

On Sun, Mar 16, 2014 at 1:58 PM, John Ralls jra...@ceridwen.us wrote:


 On Mar 16, 2014, at 8:37 AM, Jeff Earickson jaear...@colby.edu wrote:

  John et al,
 
  I upgraded Xcode on my Mac (10.9.2) to Xcode 5.1 this week (gcc 4.2.1),
 and
  I have tried a total-start-from-scratch build of gnucash-git.  My woes
 with
  this:
 
  * ~/gtk/source/webkit-1.6.1/GNUmakefile.am is missing
 -stdlibc=libstdc++
  on line 120. (previously reported, and I know how to work around this).

 Have you run gtk-osx-build-setup.sh since the last time? I fixed this in
 .jhbuildrc instead of the moduleset.

 
  * guile 1.8.8 hangs forever trying to create a texi file in libguile.  To
  reproduce, I can do by hand:
 
  $ pwd
  /Users/jaearick/gtk/source/guile-1.8.8/libguile
 
  $ cat *.doc |
 GUILE=/Users/jaearick/gtk/source/guile-1.8.8/pre-inst-guile
  ../scripts/snarf-check-and-output-texi
  ERROR: Unbound variable: define  (hangs forever)
  ^C
 
  The problem lies in the snarf-check-and-output-texi script, but I have no
  idea what this does.  I tried to fake out this portion of the build by
  simply doing cat *.doc  guile-procedures.texi, which will get the rest
  of guile to build, with a bogus texi file.

 I've never seen this problem before, but I haven't done any builds since
 the Xcode upgrade. That could be a serious problem.

 
  * The build of gnucash-git did not like my fakery with guile, because it
  will then hang during the configure for gnucash:
 
  checking for GUILE... yes
  checking for guile... /Users/jaearick/gnucash-git/bin/guile
  checking for guile-config... /Users/jaearick/gnucash-git/bin/guile-config
  checking for guile-tools... /Users/jaearick/gnucash-git/bin/guile-tools
  checking if (www main) is available... (hangs forever)
 
  ^C*** Error during phase configure of gnucash-git: ## Error
 running
  ./autogen.sh  ./configure --prefix /Users/jaearick/gnucash-git --libdir
  '/Users/jaearick/gnucash-git/lib' --enable-ofx --enable-aqbanking
  --enable-binreloc --enable-dbi --with-html-engine=webkit  *** [62/62]
 
  Any ideas please?

 Without a clean Guile, Gnucash is hopeless, so you've got to get Guile to
 work without fakery. Unfortunately Guile2 doesn't build clean either and
 I haven't taken time to work on that; filing a bug against Guile 1.8 isn't
 going to get us anywhere.

 I've no doubt that the snarf-check... scheme program was revealing a
 problem in C; upgrading clang wouldn't have any effect on the scheme, it's
 going to affect the interpreter.

 Try turning off optimization when building Guile, that's often the source
 of weird results. If it still hangs, add a debugging flag and run
 snarf-check... in the debugger and see why it's hanging.

 Regards,
 John Ralls




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

Re: build gnucash-git woes with Mac OS, Xcode 5.1

[Jeff Earickson]

John,

Can you tell me what version of XCode you have installed?  5.0.2?  version
of gcc? (Xcode 5.1 gives you 4.2.1 with clang = clang-503.0.38).  If you
have not upgraded to XCode 5.1 (5B130a), then I suggest avoiding it.
Aarrgh I just discovered that gdb is not available in Xcode with
Mavericks.

This issue of hanging at guile-procedures.texi seems to be known, see:
http://gnu-guile.7481.n7.nabble.com/guile-2-0-9-build-on-mingw-td16967.html

This URL didn't give me any real insight, except that others have seen it
even with 2.x of guile.

I tried various permutations of dropping into the jhbuild shell at failure,
rerunning .configure with --enable-guile-debug (that gave other compiler
errors), configure with --without-threads (suggested by the URL above, no
help); trying to fiddle with CFLAGS in the Makefile to change compiler
options, even in the libguile subdir where guile is built -- no love.  The
compiler flags -g -O' did not change its behavior.

I also downloaded guile-2.0.9, and wedged it into gtk/source like so:

bash-3.2$ ls -ld guile*
lrwxr-xr-x   1 jaearick  staff11 Mar 16 19:27 guile-1.8.8 - guile-2.0.9
drwxr-xr-x  45 jaearick  staff  1530 Mar 16 19:40 guile-1.8.8.last
drwxr-xr-x@ 49 jaearick  staff  1666 Mar 16 19:41 guile-2.0.9

then jhbuild build.  It says configure: error: GNU libunistring is
required, please install it.  So, I'm stuck for he moment.


---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---


On Sun, Mar 16, 2014 at 1:58 PM, John Ralls jra...@ceridwen.us wrote:


 On Mar 16, 2014, at 8:37 AM, Jeff Earickson jaear...@colby.edu wrote:

  John et al,
 
  I upgraded Xcode on my Mac (10.9.2) to Xcode 5.1 this week (gcc 4.2.1),
 and
  I have tried a total-start-from-scratch build of gnucash-git.  My woes
 with
  this:
 
  * ~/gtk/source/webkit-1.6.1/GNUmakefile.am is missing
 -stdlibc=libstdc++
  on line 120. (previously reported, and I know how to work around this).

 Have you run gtk-osx-build-setup.sh since the last time? I fixed this in
 .jhbuildrc instead of the moduleset.

 
  * guile 1.8.8 hangs forever trying to create a texi file in libguile.  To
  reproduce, I can do by hand:
 
  $ pwd
  /Users/jaearick/gtk/source/guile-1.8.8/libguile
 
  $ cat *.doc |
 GUILE=/Users/jaearick/gtk/source/guile-1.8.8/pre-inst-guile
  ../scripts/snarf-check-and-output-texi
  ERROR: Unbound variable: define  (hangs forever)
  ^C
 
  The problem lies in the snarf-check-and-output-texi script, but I have no
  idea what this does.  I tried to fake out this portion of the build by
  simply doing cat *.doc  guile-procedures.texi, which will get the rest
  of guile to build, with a bogus texi file.

 I've never seen this problem before, but I haven't done any builds since
 the Xcode upgrade. That could be a serious problem.

 
  * The build of gnucash-git did not like my fakery with guile, because it
  will then hang during the configure for gnucash:
 
  checking for GUILE... yes
  checking for guile... /Users/jaearick/gnucash-git/bin/guile
  checking for guile-config... /Users/jaearick/gnucash-git/bin/guile-config
  checking for guile-tools... /Users/jaearick/gnucash-git/bin/guile-tools
  checking if (www main) is available... (hangs forever)
 
  ^C*** Error during phase configure of gnucash-git: ## Error
 running
  ./autogen.sh  ./configure --prefix /Users/jaearick/gnucash-git --libdir
  '/Users/jaearick/gnucash-git/lib' --enable-ofx --enable-aqbanking
  --enable-binreloc --enable-dbi --with-html-engine=webkit  *** [62/62]
 
  Any ideas please?

 Without a clean Guile, Gnucash is hopeless, so you've got to get Guile to
 work without fakery. Unfortunately Guile2 doesn't build clean either and
 I haven't taken time to work on that; filing a bug against Guile 1.8 isn't
 going to get us anywhere.

 I've no doubt that the snarf-check... scheme program was revealing a
 problem in C; upgrading clang wouldn't have any effect on the scheme, it's
 going to affect the interpreter.

 Try turning off optimization when building Guile, that's often the source
 of weird results. If it still hangs, add a debugging flag and run
 snarf-check... in the debugger and see why it's hanging.

 Regards,
 John Ralls




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

Mac OSX: i386 vs x86_64 in setup_sdk?

[Jeff Earickson]

Why does setup_sdk in .jhbuildrc-custom specify i386 and not x86_64 for
Macs?  I run on a modern Mac (3.3 GHz Intel Core i3, Mac OSX 10.9.2).
uname -m says x86_64, but arch says i386; I would guess that the
setup_sdk line specifies what arch is set to for the build, right?  I
want 64 bits if I can get it.

How do I start fresh on a rebuild of everything, gtk and gnucash?  jhbuild
clean?  Or if I fiddle with setup_sdk, do I have to go back to the
beginning of sh gtk-osx-build-setup.sh; jhbuild build python; jhbuild
bootstrap?

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

Re: MacOSX: how to rebuild after source code change

[Jeff Earickson]

John,

I have (with a little struggle) built the Mac code from git source, made my
trivial mod to line 622 of ~/gtk/source/gnucash-2.6.2/
src/app-utils/gnc-ui-util.c, rebuilt, and seen my change in the rebuilt
code (without a core dump).  Hooray!

Should stupid how-do-I-build questions like this go to gnucash-devel or
gnucash-users lists?  What's my limit? :)

---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---


On Wed, Mar 5, 2014 at 10:50 PM, John Ralls jra...@ceridwen.us wrote:


 On Mar 5, 2014, at 6:22 PM, Jeff Earickson jaear...@colby.edu wrote:

  Hi,
 
  After I successfully got jhbuild to work on my Mac, I want to experiment
  with source code changes.
 
  So I modified line 622 of
  ~/gtk/source/gnucash-2.6.2/src/app-utils/gnc-ui-util.c to change the
  reconciled flag from 'y' to 'Z', then wanted to rebuild.  So I tried
  jhbuild build again (no change),
  make from ~/gtk/source/gnucash-2.6.2 (glib-compile-schemas: command
 not
  found).  I know this is something simple, what's the trick?

 If you want to work on the code:
 * Use git rather than a tarball as the source, even if you don't plan to
 contribute your changes back to the project, using a VCS is a good way to
 keep track of what you've done and since git is a distributed VCS you have
 repo in your working directory. No hassles with setting up a server
 somewhere. The simple way to do that is to change your .jhbuildrc-custom to
 build the gnucash-git module instead of gnucash.

 * Rather than re-running jhbuild build, run jhbuild shell, cd to your
 build directory, and run make  make install from there.

 It appears that either something went wrong with your path or you managed
 to uninstall glib-compile-schemas. I'm sure you know how to figure that
 out. Again, jhbuild shell will duplicate the environment of jhbuild build
 and allow you to probe what happened without having to wait for the build
 to error out so that you can select 4.

 Regards,
 John Ralls




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

Re: MacOSX: how to rebuild after source code change

[Jeff Earickson]

John,

I'm struggling now with git (I'm a newbie to git, but we are moving to it
at work).

$ git status
On branch master

Initial commit

Untracked files:
  (use git add file... to include in what will be committed)

.gnucash/
NOTES
gnucash-git/
gnucash-stable/
gnucash/
tmp-jhbuild-revision

nothing added to commit but untracked files present (use git add to track)

So, I want to make a branch like on the wiki:

$ git checkout master
error: pathspec 'master' did not match any file(s) known to git.
$ git branch working-master
fatal: Not a valid object name: 'master'.

I installed git version 1.9.0 in /usr/local and am using that instead of
Mac's 1.8.3.4, but this doesn't seem to make a difference.
After installing git version 1.9, all I did was git init, set up git
config info with my name and email, then git clone... for gnucash.
It starting pulling code, no real problems after that, until I try to make
a branch.  Then no love.

---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---


On Sat, Mar 8, 2014 at 9:05 PM, John Ralls jra...@ceridwen.us wrote:


 On Mar 8, 2014, at 5:11 PM, Jeff Earickson jaear...@colby.edu wrote:

  John,
 
  I have (with a little struggle) built the Mac code from git source, made
 my trivial mod to line 622 of ~/gtk/source/gnucash-2.6.2/
  src/app-utils/gnc-ui-util.c, rebuilt, and seen my change in the rebuilt
 code (without a core dump).  Hooray!
 
  Should stupid how-do-I-build questions like this go to gnucash-devel or
 gnucash-users lists?  What's my limit? :)

 Congratulations!

 Devel is better, I think. The only reason I can see to build it yourself
 is to develop, so after you build you're likely to have code questions
 anyway, so the sooner you get introduced here, the better.

 Regards,
 John Ralls


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

Re: Trying to build gnucash on Mac 2.9.2 using jhbuild: help?

[Jeff Earickson]

John,

I modified ~/gtk/source/webkit-1.6.1/GNUmakefile.am like so:

bash-3.2$ diff -c GNUmakefile.am.orig GNUmakefile.am
*** GNUmakefile.am.orig2014-03-05 09:45:45.0 -0500
--- GNUmakefile.am2014-03-05 09:46:17.0 -0500
***
*** 118,124 


  global_cxxflags += \
! -fno-rtti

  # -no-undefined required for building DLLs on Windows
  # It breaks the build on other platforms, so we use it conditionally
--- 118,124 


  global_cxxflags += \
! -fno-rtti -stdlib=libstdc++

  # -no-undefined required for building DLLs on Windows
  # It breaks the build on other platforms, so we use it conditionally

and then jhbuild build successfully completed, giving me a gnucash 2.6.2
executable that I could start from the terminal window.  Success!
Thank you.

---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---


On Wed, Mar 5, 2014 at 12:08 AM, John Ralls jra...@ceridwen.us wrote:


 On Mar 4, 2014, at 6:53 PM, Jeff Earickson jaear...@colby.edu wrote:

  John,
 
  I gave it major effort tonight.  In the first round, I reran
 gtk-osx-build-setup.sh, reran jhbuild (failed), selected wipe directory
 and clean, retried (failed again).
 
  In round 2, I removed everything related to gnucash/jhbuild from my home
 directory (.jhbuild* files, gtk*, Source, .local, gnucash-stable,
 .subversion) and started from scratch: download gtk-osx-build-setup.sh,
 download new .jhbuildrc-custom, follow the instructions on the wiki from
 the beginning.  Same error in Webkit, see attached.  I wondered what pull
 the latest gnucash-on-mac meant; I thought starting from scratch would do
 that anyway.

 There are two repositories involved: http://git.gnome.org/gtk-osx and
 https://github.com/jralls/gnucash-on-osx. The latter has the moduleset
 and .jhbuildrc-custom specific to building GnuCash.  I'd forgotten that the
 .jhbuildrc-custom there uses the gnucash.modules directly from the repo, so
 you're OK, there's nothing more to download.

 The supposed fix for the webkit problem isn't working, though. It's
 supposed to add -stdlib=libstdc++ to the CXXFLAGS. If you know your way
 around configure well enough you can try adding it by hand; otherwise I
 won't have time to look at it again until Thursday.

 Regards,
 John Ralls


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

MacOSX: how to rebuild after source code change

[Jeff Earickson]

Hi,

After I successfully got jhbuild to work on my Mac, I want to experiment
with source code changes.

So I modified line 622 of
~/gtk/source/gnucash-2.6.2/src/app-utils/gnc-ui-util.c to change the
reconciled flag from 'y' to 'Z', then wanted to rebuild.  So I tried
jhbuild build again (no change),
make from ~/gtk/source/gnucash-2.6.2 (glib-compile-schemas: command not
found).  I know this is something simple, what's the trick?

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

Trying to build gnucash on Mac 2.9.2 using jhbuild: help?

[Jeff Earickson]

Hi,

I am trying to build gnucash-stable on my Mac (10.9.2, Intel, XCode 5.0.2
installed) following the instructions at:

http://wiki.gnucash.org/wiki/MacOSX/Quartz

I am stuck at the jhbuild of WebKit:

2 errors generated.
make[1]: ***
[Tools/DumpRenderTree/Programs_DumpRenderTree-PixelDumpSupport.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [all] Error 2
make -j 5
*** Error during phase build of WebKit: ## Error running make -j 5
*** [46/56]

  [1] Rerun phase build
  [2] Ignore error and continue to install
  [3] Give up on module
  [4] Start shell
  [5] Reload configuration
  [6] Go to phase wipe directory and start over
  [7] Go to phase configure
  [8] Go to phase clean
  [9] Go to phase distclean
choice:

I have tried various choices: no go.  If I give up on the module then
gnucash won't build. Help please?

Some other comments about the webpage above:

1) I had to modify the line setup_sdk(10.5, 10.5,[i386]) in
.jhbuildrc-custom to reference 10.9 in my case.  Maybe this should be noted
on the webpage?

2) jhbuild build python flunked with:

jhbuild build: failed to unpack
/Users/jaearick/gtk/source/pkgs/Python-2.7.3.tar.xz

After I untarred the file and put it one level up in the directory
structure, and restarted -- it worked.

---
Jeff A. Earickson, Ph.D
Senior Server System Administrator
Colby College,
4214 Mayflower Hill,
Waterville ME, 04901-8842
207-859-4214 (fax 207-859-4186)
Eastern Time Zone, USA
---
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Someone is attempting to sell GnuCash.

[Jeff Warnica]

As just a home user, its unlikely your accounting package could lead you
down a path to tax trouble. It follows well established (international)
accounting practices. Gnucash isn't going to advise you on weird Cap-Gains
claims or moving losses forward over years at all, let alone in a way
dangerous WRT the Canadian Revenue Agency.

You can do the CRA short T1 from the back of napkins.

On the other hand, commercial accounting packages integrate with their
partner'd tax software. I've never actually gotten this to be useful,
however. The commercial packages might provide better starting charts of
accounts, with an eye towards the CRA, but especially as a home user, the
difference would be slight, if any.


On Fri, Jan 4, 2013 at 1:50 PM, Geoff Hilton geoffhil...@gmail.com wrote:

 This is a great question! Personally, I like to have everything in a
 product to be functionally usable for my purposes regardless of my
 current needs, simply on the premise of if I ever need to use it,
 it's there, so on that basis I would say I'd like full compatibility,
 whatever that means with GnuCash. To be more specific though, my
 current needs are simple home accounting and financial planning.

 Mind you I'm no accountant so I wouldn't necessarily currently know
 what formulas to use and where to use them, but I can learn. I imagine
 I might be able to contribute in some respect though.

 Geoff

 On Thu, Jan 3, 2013 at 7:03 PM, David T. sunfis...@yahoo.com wrote:
  What sort of compatibility functions would you need?
 
  I ask because for my needs, it is only necessary to create my account
  structure in a way to enable me to identify tax-related transactions and
  accounts. In my jurisdiction (the U.S.), I have designated certain
 accounts
  as tax-related, run a summary report on those accounts and plug in
 numbers
  into the appropriate tax forms.
 
  Users from Australia, the UK, Germany and the Netherlands all have
 discussed
  various aspects of tax-compliance on the list; perhaps they can guide you
  further...
 
  David
 
 
  
  From: Geoff Hilton geoffhil...@gmail.com
  To: John Ralls jra...@ceridwen.us
  Cc: gnucash-devel@gnucash.org
  Sent: Thursday, January 3, 2013 11:20 AM
  Subject: Re: Someone is attempting to sell GnuCash.
 
  Ah. To be honest I haven't tried GnuCash yet beyond running it once,
  but had been looking into financial software I could use, I'm Canadian
  though so it doesn't look like GnuCash would work without
  compatibility with Canadian tax laws and such(?) based on what I read
  from a post somewhere. I hadn't looked at the license yet, but
  presumed it was strictly GPL v2 which I erroneously thought meant it
  couldn't be resold (I checked the faq about the GPL on gnu.org). I do
  think it would be interesting to find out if that shareware site meets
  all the conditions of the GPL as explained on the faq.
  http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMoney
 
  If I wanted to contribute to make GnuCash work better for Canadians
  what would I need to change, exactly?
 
  On Thu, Jan 3, 2013 at 9:48 AM, John Ralls jra...@ceridwen.us wrote:
 
  On Jan 2, 2013, at 11:35 AM, Geoff Hilton geoffhil...@gmail.com
 wrote:
 
  This is unrelated to server  e-mail outages or translation problems,
  but I thought it would be good for you folks to be made aware of these
  people who are attempting to sell GnuCash (which is obviously illegal
  given the license).
 
  Here's the link:
  http://www.bestshareware.net/software/gnucash-financial-software.htm
 
 
  Well, no, selling GPL-licensed software isn't prohibited by the license,
  provided that the price reflects reasonable distribution costs. At $500,
  he's rather exceeding that. Since Gnucash is readily available for free,
  this is more a consumer fraud issue.
 
  Here's the whois contact information:
 
 Registrant:
 Marker Seven
 9288 Beach Road
 Silverwater Via
 MORISSET, New South Wales 9988
 Australia
 
 Administrative Contact:
   Seven, Marker  bestsharew...@ymail.com
   9288 Beach Road
   Silverwater Via
   MORISSET, New South Wales 9988
   Australia
   002498331988  Fax -- 002498331988
 
 Technical Contact:
   Seven, Marker  bestsharew...@ymail.com
   9288 Beach Road
   Silverwater Via
   MORISSET, New South Wales 9988
   Australia
   002498331988  Fax -- 002498331988
 
  Perhaps someone in Australia will take it up with whatever
  consumer-protection agency exists there.
 
  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 for ChromeOS

[Jeff Tipton]

I would like to see a Gnucash for ChromeOS (Chromebook) app developed.
 Maybe there is such an app but if so I cannot find it.  Just a thought.

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

Re: For The Love Of Bitcoin

[Jeff Warnica]

When making an argument, you need to highlight what is important to the
listener, not to you.

There is a reasonable workaround to day to use Bitcoin with Gnucash.
Developers need to do absolutely nothing.

Bitcoin should not be included because it isn't a real currency. Gnucash is
not a political movement; you may have a very reasonable political argument
to make, this is not the forum for it.

If you want to have Gnucash recognize Bitcoin as a real currency, then
you need to get bitcoin recognized as a real currency. That is between you
and the ISO, and has nothing to do with Gnucash. Is that difficult? Sure.
Is that a corrupt process? Well, maybe. Is that Gnucash's problem? No.

If/when ISO recognizes it, as a matter of course, it will show up in
Gnucash.




On Fri, Feb 17, 2012 at 1:32 PM, karmicads karmic...@bitcoin2pay.comwrote:

 ¨And in the process produce tons more rough.¨

 And you blame *ME* for your inability to find gems Derek?

 All bad tradesmen blame their tools. Not that Iḿ a tool or anything. LOL.

 ¨Try limiting yourself to 2-5 sentences per point?¨

 Oooor, we could try, you not being chief superintendent verbosity Nazi.
 When
 I open my mouth to speak, I like to ensure that my words will be understood
 regardless of how terse or verbose the message (gratuitous ramblings and
 incidental redundancy included ), may be required, for it to properly be
 conveyed. I Hope it might be of less importance to you in the future, my
 friend, but I assure you, in the best spirit of equanimity; that it takes
 as
 least as much time for me to write it, as it takes for you to read it.
 Nuff,
 said

 --
 View this message in context:
 http://gnucash.1415818.n4.nabble.com/For-The-Love-Of-Bitcoin-tp4348895p4397920.html
 Sent from the GnuCash - Dev mailing list archive at Nabble.com.

 ___
 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: For The Love Of Bitcoin

[Jeff Warnica]

Price quotes are fetched using an external library, specifically the Perl
module Finance::Quote (F::Q). Quoting it's manual: module gets stock
quotes from various internet sources, including Yahoo! Finance, Fidelity
Investments, and the Australian Stock Exchange

It would be relatively easy to add support for pulling BTC rates from some
exchange, the exchange specific modules are only about 100-400 lines each.
But that assumes that publicly accessible feeds exist.



On Fri, Feb 17, 2012 at 3:29 PM, karmicads karmic...@bitcoin2pay.comwrote:

 ¨because I suspect that the Currency
 Quote Source from F::Q does not provide BTC prices¨

 Sorry?!! I don´t follow you.

 *WHAT* currency quote source? But more importantlly  /!!!WHY /Would
 there *only* be one?

 Seriously... Am I fiscally, technologically and politically retarded, or is
 there something everybodyś not telling me?  H?

 If the answer is ´politically retarded´, I´ll take it on the testicles, not
 just the chest. LOL.


 --
 View this message in context:
 http://gnucash.1415818.n4.nabble.com/For-The-Love-Of-Bitcoin-tp4348895p4398227.html
 Sent from the GnuCash - Dev mailing list archive at Nabble.com.

 ___
 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: For The Love Of Bitcoin

[Jeff Warnica]

Well, the 400 line solution really hooks into the otherwise normal
processes of GNC... Redefining currency is a larger problem, which I would
guess at requiring a total rewrite off all accounting programs everywhere.

But how valuable this would be is an open question. For a scenario where
the user owns securities (stocks), it is nice to know the current market
value of them. When the user makes an actual trade, then that transaction
would have a manually entered price (or exchange rate). Because the market
rate for MSFT at 12:36 EST that finance.yahoo.com reports may not be
(almost definitely is not) what you got for it at 12:38 EST from your
broker.


On Fri, Feb 17, 2012 at 4:01 PM, karmicads karmic...@bitcoin2pay.comwrote:

 ¨Price quotes are fetched using an external library, specifically the Perl
 module Finance::Quote (F::Q)¨

 OH! Thanks Jeff. I was hoping to count on somebody with more technical
 expertise than myself. As I understand it, this is not unfeasible at all;
 even down to the using of bitcoin as a meta-currency. I do imagine there
 may
 be some class re-modifications in the code that defines currency and so
 on   Hmmm... What exactly does that involve? Anybody like to help out
 here?



 --
 View this message in context:
 http://gnucash.1415818.n4.nabble.com/For-The-Love-Of-Bitcoin-tp4348895p4398320.html
 Sent from the GnuCash - Dev mailing list archive at Nabble.com.

 ___
 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 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: 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

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: Strategy

[Jeff Warnica]

As with Donald, I haven't contributed any code, but I would tend to agree
that there is a problem.

A rewrite from scratch is a drastic solution to that not quite as drastic
problem.

The roadmap on the Wiki is more like a wishlist, and the schedule is, well,
non existent. Sorry, I see that there is a documented and very wide
guideline, but the history doesn't show that being hit. And maybe bug fix
releases should be an as-needed basis; regardless, its indication of a
problem.

There is a big difference between a collection of (mostly/largely... trying
to be apolitical) people working on a shared chunk of code, and a project
producing a specific product. That is a bit of a false dichotomy, but on
that spectrum, where as something like Gnome seems to have a project wide
vision, schedule, plans; something like the Linux kernel has at least a
pretty regular cycle of integrating random factions.

Questions about the use of library versions (and major versions Gnome/GTK 3
being the obvious white elephant here) seem to flair up and die out, but no
real resolution I can see. Carrying on as normal, not targeting new base
libraries, isn't an answer, it is just not doing anything.

I don't see a project goal/vision saying that it (we) target long-term
platforms (which, while I would disagree with, at least is
something tangible to measure against). Of course, compounding
this unsolvable question is that there is no release schedule for 2.6 (or
3.0).

Maybe all the devs implicitly agree on most everything. I think that that
is great. The open source mantra of devs scratching an itch is a bit
simplistic... Sure, fixing bug #whatever might be doable; others want, for
lack of a better word, belonging, as much as any technical problem solved.
I doubt that many potential developers are aware of this; but getting
contributions more then just bug #x being squashed... getting new project
contributions... really requires a solid project to latch on to.

To that end, before  you (we?) move to GTK 3, or port Guile to Python, or
whatever:

Capture and document high level technical and feature goals; prioritize
them; mapped to versions, and dates. Time box that (features will slip),
but try to get out major feature versions (or versions with major technical
changes), say, every 6 months.



On Sun, Dec 4, 2011 at 12:35 PM, Graham Leggett minf...@sharp.fm wrote:

 On 03 Dec 2011, at 11:40 PM, Donald Allen wrote:

  Gnucash has been around
  for a long time, and its life-span covers the development of a lot of
  tools. If you were going to start with a blank sheet of paper today, I
  doubt very much whether you would do a lot of the system as it is
  today. The big question is, when is it worth it to cut your losses and
  start over?

 I use gnucash because a) it's been around a long time, and b) because
 gnucash is likely to be around a long time still.

 Anyone can start over at any time - that's called a new product - but when
 people decide to abandon what they have and start over, that's when you
 lose faith in the project and start to look somewhere else.

 Sure, new fandangled languages are shiny, but will they still be popular
 in 5 years? No idea. I am happy to bet that C will be around in 5 years, so
 investing in the language as unsexy as it might be for me is a good
 investment.

 I think gnucash needs a heavy set of refactoring. I'd like to see a proper
 libgnucash split out as a separate library that I can depend on in other
 software. I'd like to use a libgnucash library as a basis for a restful
 service that will allow me to share gnucash with others, like my
 accountant. But I don't think gnucash needs to be started over.

 Regards,
 Graham
 --


 ___
 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 Dev teams

[Jeff Warnica]

Replying, also not as a dev, but a mostly lurker on the list.

The issue with OSS projects is that while some project level
vision/strategy/goals/direction is very helpful (and I think GNUCash could
improve on), on the day-to-day level, developers pick and choose based on
their own personal preference. Near the end of a release cycle, developers
may tend towards bugfixes as opposed to new features, it is also the
case that some developers may only ever work on new features, and others may
only ever work on bugfixes/refactoring/stabilization.

I think that it is the industry trend (or one trend) towards no specific
stabilization/bugfix cycle. Scrum, agile, XP type would say that software
should always be in a releaseable state. Which isn't true on
a tactical level, of course, but if it was once standard practice that from
saying go to released taking 6+ months, under Scrum you are never more
then a week or two from release. In OSS projects, the Linux kernel is of
course the biggest project, and filled with case study material in PMing;
forcing developers to fix bugs instead of building new features, at
least on the project level, is pretty much impossible. With Linux, its split
up by time as opposed to role, but during the stabilization phase, people
working on new features continue to do so, they just don't tell you until
the new feature phase.

The recent discussion here on how and when to branch out trunk vs 2.4
highlights some of the issues local to this group.

On Tue, Feb 1, 2011 at 11:32 AM, Sebastien Daniel 
sebastien.dan...@sebweb.ca wrote:

 Hello to all Devs.

 I recently joined the GnuCash -devel list, hoping I could contribute in
 some manner.

 The experience I can give is related to business management, accounting and
 my academics, which are in the field of business administration and
 information technologies.
 As a note, I am by no means a developper, I only know html/CSS (for now).

 This is also my first shot at contributing in an opensource project, so my
 methods might not be the most appreciated, if so, simply point it out
 (nicely pls :P ) and i'll adapt.

 My first contribution would be to attempt a certain form of organisation,
 this being on a voluntary basis, everyone should make their own decision on
 which team they would want to be.

 *The idea:
 *Have two teams, each contributing in a different manner.
 Team A would work on known issues, bugs and stability.
 Team B would work on fonctionnality requests, general GnuCash improvement.

 I believe this would help drive GnuCash efforts all in the same direction
 (in sorts).
 This is an idea, please give your feedback.

 /
 Askarii/
 ___
 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: 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

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

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 account number Bank bank number if both are present

* Account account number if only the account is present

* Bank bank number 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

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: ~/.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 ~/.appname  is no longer the
recommended place to store such information.

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

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\user\Application Data\gnucash
- Windows Vista/7: c:\Documents and Settings\user\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: ~/.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/.appname  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 ~/.appname   is no longer
the recommended place to store such information.

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

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\user\Application Data\gnucash
- Windows Vista/7: c:\Documents and
Settings\user\AppData\Roaming\gnucash - OS X: ?

I would obviously have to provide some conversion code as well, that
would

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=gnucashold=19971new_path=gnucashnew=19974

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




___
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:the real revision
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

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 Kletskygnuc...@allycomm.com  wrote:


From: Jeff Kletskygnuc...@allycomm.com
Subject: Re: New Budget Report
To: Phil Longstaffplongst...@rogers.com
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]

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]

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: 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: 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: 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 Atkinswarl...@mit.edu  wrote:

Geert Janssensjanssens-ge...@telenet.be  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: 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: 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=detailaid=3152613group_id=23824atid=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

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

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: [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 Stimmingstimming  changed:

What|Removed |Added

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

--- Comment #32 from Christian Stimmingstimm...@tuhh.de  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 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]

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 mhoeni...@users.sourceforge.net
  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]

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 https://bugzilla.gnome.org/show_bug.cgi?id=627831;
   Database lock still needed
   http://lists.gnucash.org/pipermail/gnucash-devel/2010-August/029177.html;
   Linux: #611936 https://bugzilla.gnome.org/show_bug.cgi?id=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]

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: 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 Atkinsde...@ihtfp.com  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: Future of Gnucash

[Jeff Warnica]

I had a long, rambling message, but I'll summarize. Please excuse the
bluntness. I'm not a Gnucash developer, but could be. My opinions might be
technically wrong, and make me a self-destructive asshole, but I'm happy
with that.

The question shouldn't be C++ or not, but what is the best
2nd/runtime/scripting language?

In 2010/2011, a move to C++ might be a move to easier development for those
versed in C  C++, but also a move to relative obscurity. The developers you
have might be more productive, but there is a smaller pool of potential
developers to pick from.

In 2010/2011, given that Gnucash isn't a game, there is really only one
choice: Javascript. While http://live.gnome.org/Gjs seems rather dead,
http://live.gnome.org/GnomeShell is obviously committed to Javascript (and
Gjs as the binding toolkit). The low-level infrastructure is there, Gnome
3.0/GnomeShell 1.0 time frame is shorter then Gnucash 2.6, at the very
least.

Concerning the stick with Gnome question, that is always a tricky one.
Except to acknowledge that I know that the Gnome types have annoyed a lot of
people, the general question is a common one. Stick with HEAD, and ignore
let users of older systems? Or try to maintain some long lifecycle for users
of older systems. The Gnucash project generally has decided on providing new
features to existing users, supporting relatively older low-level
packages. For the users who don't want their systems to change, my view is
to give them that, and only provide bugfixes; if you want new features, then
upgrade to the new version. And if you need to upgrade your distribution, so
be it. Within reason, of course. But as a user of OpenSuSE, within 1 minor
version of their most current, I have had to dig around for old version of
system libraries to build 2.3.x, and have had to do similar over the past 5
years as well. So no only am I not getting the new features of system
library X, I actually have to work to find an old version of system library
X. IMHO,  the balance is off.

Gnome 3 is due out in a few months. It will likely be in current versions
of distributions about this time next year. OpenSuse, Fedora, Ubuntu, maybe
even Debian unstable, testing for sure. If 2.6 is due 22 months from
now, that leaves a full 10 month overlap (up to 2 point releases for
OpenSUSE and Fedora, depending timing).  My personal view is that it is
entirely reasonable that you can tell a potential user of 2.6.0 that they
will have to have upgraded the OS in the previous year. And it isn't just
the functionality (now) provided by Gnome; there are other dependent
packages that don't quickly come to mind which are far from current. Not to
trivialize those details, but my argument isn't about details :) If
polishing low level interfaces up to provide for multiple front ends, then
saying 3.0 isn't a bad idea, and with that label, unpleasantness at least
has a nice smokescreen. You have to draw a line somewhere, obviously it is
best to do that at the beginning of a development cycle.


On Tue, Dec 28, 2010 at 10:52 AM, Phil Longstaff plongst...@rogers.comwrote:

 The subject sounds a bit ominous, but I don't mean it to be.

 2.4.0 is now out the door.  Already there are ideas rolling in about the
 next enhancements.  I was just about to tackle one of the enhancements
 when instead, I thought I would (again) raise a broader issue.

 A few months ago, Christian Stimming started CuteCash with the aims of
 replacing gtk by Qt/C++.  The idea was that development in gtk/C was too
 slow and cumbersome.

 So, the big question is: should we set a direction to have CuteCash
 replace GnuCash, and if so, what are the steps/milestones to get there?

 Obviously, since this is all open-source, it's not either/or.  One group
 could continue with GnuCash as it is while the other develops CuteCash.
 Personally, I like the idea of CuteCash and would prefer to develop for
 Qt/C++ rather than gtk/C.  On the other hand, until CuteCash catches up
 in features to GnuCash, if I want any new functionality, it has to go
 into GnuCash.

 So, among the questions I will raise:
 1) Does the current set of engine objects make sense?  They currently
 are gobjects and CuteCash has C++ wrappers.  I guess they need to stay
 that way until CuteCash replaces GnuCash, at which point the C++
 wrappers could become the official public API.

 2) Does QOF still make sense?  Back in the earlier days of the SQL
 backend, there was a proposal to replace qof with libgda (gnome data
 access layer) which might be a step toward gnucash as a database app.

 3) Should I hesitate to introduce new gobjects?  One thing I want to do
 is replace the current preferences with a better system for managing
 global vs per-file preferences on a system vs per-user basis.  My idea
 is a GncPrefs gobject interface with
 get_int()/set_int()/get_string()/set_string()/... functions.  These
 could be implemented to use gconf on linux, the registry on windows, etc
 to better tie into native 

Re: i need access to the gnucash source code and a recommendation of a good IDE

[Jeff Warnica]

http://wiki.gnucash.org/wiki/Windows seems to have what (little) Windows
specific development documentation there is. It doesn't mention any specific
IDE. I really have no idea, but I would guess that most Gnuchash developers
are using something which might be what comes to mind when one thinks IDE.
That is, something like Emacs which is a really really fancy text editor,
but doesn't do continuous builds, or procedure/method completion and inline
documentation one gets with Java and Eclipse, say.

You aren't going to get much help unless you help yourself. I'd try to see
what happens, trying to compile using http://www.mingw.org/. Or trying to
setup a cygwin environment, and compiling with that (though, that might not
count as being Windows...) IDE wise, there is no silver bullet. Get
something better then notepad plus a command box. Jedit is reasonable.
Eclipse with CDT might be worth trying. CDT does have those fancy 21st
century IDE features, but (I havent tried with Gnucash), for C/C++ stuff
they do tend to require a very specific coding approach, Gnucash sources
perhaps being too complicated for the fancyness to work.

Most of the documentation for the source is in the source, I would guess.
Extending the source is easy: get a text editor, and extend it. If you have
some specific question, I'm sure you will get help. But helping you with
setting up a development environment really isn't any Gnucash devs job.


On Mon, Jul 5, 2010 at 10:36 AM, adekoya adekunle adekunleadek...@gmail.com
 wrote:

 i would want to know of specific documentation that could help a
 developer that intends to extend the source code.

 i mean if i could get a link to download a documentation  that does
 proper explanation of the source code and how to extend.


 i would be glad that my questions are each and specifically treated so
 i could minimize iterations in resolving the issues of source code
 edits.

 thanks



 On Mon, Jul 5, 2010 at 3:21 PM, adekoya adekunle
 adekunleadek...@gmail.com wrote:
  i have just downloaded something from :
  http://www.gnucash.org/pub/gnucash/sources/stable/gnucash-2.2.9.tar.bz2
 
  i want to know if that link contains a valid source for windows platform
 ?
 
  i also want to know how to load the source code in any of the free
  open source IDE.
 
 
  i also have qt on my machine. can i use qt as my IDE ?
 
 
  i also want to know the file name that contains the entry-point
  function for the gnucash sofware ?
 
  knowing the entry-point function would help me in doing proper trace
  of the application execution path.
 
  please help on those specific questions.
 
 
  thanks
 
  'kunle
 
 
  On Mon, Jul 5, 2010 at 3:09 PM, Ankur Sinha sanjay.an...@gmail.com
 wrote:
  On Mon, 2010-07-05 at 15:01 +0200, adekoya adekunle wrote:
  hello,
 
  i have tried using gnucash in the last few  weeks.
 
  we plan to be able to make a few customizations/extensions to gnucash
  to fit our purpose.
 
  i want you guys to show me where i can download the source code for
  gnucash( to be run on Ms Windows  XP) .
 
  i also want you to show me where i can get a free IDE with compiler
  for compiling and executing the source.
 
  i hope to start making some customizations to the source code in the
  next few weeks.
 
  before then, i want to study the source and do some experimentation
  with source edits.
 
  any help ?
 
  thanks
 
  'kunle
 
  hello,
 
  Have you looked at the main website[1]??
 
  [1]
  http://www.gnucash.org/
 
  regards,
  Ankur
 
  ___
  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: 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 
stimm...@tuhh.de wrote:



Zitat von Jeff Kletsky gnuc...@allycomm.com:

#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 glib/gi18n.h
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 glib/gi18n.h
#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 glib/gi18n.h
#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

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

[Jeff Kletsky]

Derek Atkins wrote:

Jeff Kletsky gnuc...@allycomm.com 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]

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

Jeff Kletskygnuc...@allycomm.com  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

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

https://bugzilla.gnome.org/show_bug.cgi?id=537476
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 
http://www.mathstat.dal.ca/~selinger/accounting/gnucash.html


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

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

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

[Jeff Kletsky]

In src/libqof/qof/qofbookslots.h

http://svn.gnucash.org/trac/browser/gnucash/trunk/src/libqof/qof/qofbookslots.h?rev=18464

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 glib/gi18n.h
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

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 gnuc...@allycomm.com:

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

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))

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

unnamed port: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 glib/gi18n.h
-#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: 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))

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

unnamed port: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 glib/gi18n.h
-#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

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: 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 QD 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

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 
http://svn.gnucash.org/trac/browser/gnucash/trunk/src/libqof/qof/qofbookslots.h?rev=18464 
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