Re: Feedback about 2.7.8

[Christoph R]

Hi,

> Am 01.04.2018 um 19:11 schrieb Wm :
> 
> Do you feel this was an anomaly or a general case that needs to be coded for 
> ?  Maybe we should just drop prices far in the past or future ? The price db 
> really isn't that important, it doesn't contain anything real for a person's 
> actual accounts as I very much doubt anyone using gnc gets wholesale market 
> prices on stocks or currencies, etc.

In best case we would do a pop-up to give the user the choice to drop or cancel.


>> Date was 1301-09-13 00:05:08 +0053
>> and it shows up absolutely correct as 13.9.1301 :-)
> 
> You're older than I thought :)

Doing some genealogy accounting ;-)

> Have you had your data in and out of a mysql db ?  I think there was a date 
> thing there (almost no one use postgres and sqlite would have been noticed by 
> too many).

No, never used the sql backend.

But it is possible without any error or warning to create dates like this in 
the price editor of 2.6.

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

Re: 2.7.8: autosizing field width in register too small

[Christoph R]

Done. Bug 794807 <https://bugzilla.gnome.org/show_bug.cgi?id=794807> and 794806 
<https://bugzilla.gnome.org/show_bug.cgi?id=794806>

Gruß,
Christoph

> Am 29.03.2018 um 14:09 schrieb Geert Janssens <geert.gnuc...@kobaltwit.be>:
> 
> Op donderdag 29 maart 2018 12:57:55 CEST schreef Christoph R:
>> Hi Geert et. al.
>> 
>> Playing with the font settings in 2.7.8 I realised that the auto-sizing in
>> the register is not working correctly. When double-clicking the header it
>> resizes just a bit too small.
>> 
> Thanks for reporting all the issues you encounter.
> 
> However can you file them as bugs [1] please ? We can't keep track of issues 
> on the mailing list.
> 
> Thanks,
> 
> Geert
> 
> [1] Refer to http://wiki.gnucash.org/wiki/Bugzilla to learn how to use 
> bugzilla
> 
> 

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

2.7.8: Calendar widget current month shown as (null)

[Christoph R]

Hi Geert et. al.,

in 2.7.8 the calendar widget shows the current month as “(null)”. All other 
months are fine.

Gruß,
Christoph



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

2.7.8: autosizing field width in register too small

[Christoph R]

Hi Geert et. al.

Playing with the font settings in 2.7.8 I realised that the auto-sizing in the 
register is not working correctly. When double-clicking the header it resizes 
just a bit too small.

Cheers,
Christoph

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

Re: Feedback about 2.7.8

[Christoph R]

Hi Geert,

> Am 28.03.2018 um 17:24 schrieb Geert Janssens <geert.gnuc...@kobaltwit.be>:
> 
> Op woensdag 28 maart 2018 15:46:26 CEST schreef Christoph R:
> 
>> It choked on one of my files, which worked fine with 2.6 and was probably
>> created with 2.4 or even earlier.  There was an out-of range date in the
>> price database which I corrected manually. But normal users would have been
>> lost.
> What was the date set to before you corrected it ? And how does it display in 
> gnucash 2.6 if you look at that particular price in the Price editor ?

Date was 1301-09-13 00:05:08 +0053
and it shows up absolutely correct as 13.9.1301 :-)

> 
>> adding “EXTRA_ARGS=--nofile” to Library/Application\
>> Support/Gnucash/gnucashrc does not have any effect any more.
> 
> I never heard of a gnucashrc file. Perhaps that is/was an OS X/Quarz specific 
> extension ? The loading code on OS X has been aligned with Windows and Linux 
> in this development cycle, so perhaps it got lost in that work.

Yes it was parsed by the MacOS launcher script, which apparently is gone now.

>> Changing account or value of a reconciled
>> split gives me the correct warning as needed. Yeah! But I can change the
>> description of a reconciled split without a warning.
> 
> Hmm, a split doesn't have a description, only a memo. Do you mean you get no 
> warning when changing the memo ? Or do you mean you can change the 
> transaction 
> description of a transaction that has reconciled splits ?

I get no warning when changing the memo. I get one when changing the 
transaction description.

> 
>> Fonts and icons are different - due to gtk3 - and not
>> necessarily to my liking. I had customised .gtkrc-2.0.gnucash a bit and of
>> course this does not work any more. Unfortunately I did not figure out how
>> to customise gtk3 on MacOS. Any help would be appreciated
> 
> I have updated the relevant FAQ entry:
> https://wiki.gnucash.org/wiki/FAQ#Q:_How_do_I_change_the_register_colors.3F

Wow, this CSS stuff is cryptic. Can you enlighten me how to set font and font 
size?

Cheers,
Christoph 

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

Re: Feedback about 2.7.8

[Christoph R]

Hi Alen,

> The description is something for me (the user) to add notes about the 
> transaction and is basically irrelevant for anyone else

we might argue about that. 

I find it at least inconsistent since the transaction description is in fact 
protected by the reconciliation of a single split.

Cheers,
Christoph

> Am 28.03.2018 um 15:54 schrieb Alen Siljak <alen.sil...@gmx.com>:
> 
> 
>> Sent: Wednesday, March 28, 2018 at 3:46 PM
>> From: "Christoph R" <subscriptions+lis...@rohland.net>
>> To: gnucash-devel <gnucash-devel@gnucash.org>
>> Subject: Feedback about 2.7.8
>> But I can change the description of a reconciled split without a warning. I 
>> need to file a bug report on that.
> 
> Chris, I'm just wondering - why would a change of description require 
> re-reconciliation? 
> Somehow, I'd expect that the date and amount are the relevant fields. The 
> description is something for me (the user) to add notes about the transaction 
> and is basically irrelevant for anyone else, therefore not requiring 
> re-reconciliation with another account statement (i.e. bank or credit card 
> statement). Just wondering what your case is.
> 
> Cheers,
> 
> Alen

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

Re: Feedback about 2.7.8

[Christoph R]

> Does changing the description of a reconciled split line unreconcile the 
> transaction or does it leave the split reconciled but simply have no warning?

It leaves the split reconciled.

Cheers,
Christoph

> Am 28.03.2018 um 16:03 schrieb David Carlson <david.carlson@gmail.com>:
> 
> Does changing the description of a reconciled split line unreconcile the 
> transaction or does it leave the split reconciled but simply have no warning?
> 
> David C
> 
> On Wed, Mar 28, 2018 at 8:54 AM, Alen Siljak <alen.sil...@gmx.com 
> <mailto:alen.sil...@gmx.com>> wrote:
> 
> > Sent: Wednesday, March 28, 2018 at 3:46 PM
> > From: "Christoph R" <subscriptions+lis...@rohland.net 
> > <mailto:subscriptions%2blis...@rohland.net>>
> > To: gnucash-devel <gnucash-devel@gnucash.org 
> > <mailto:gnucash-devel@gnucash.org>>
> > Subject: Feedback about 2.7.8
> > But I can change the description of a reconciled split without a warning. I 
> > need to file a bug report on that.
> 
> Chris, I'm just wondering - why would a change of description require 
> re-reconciliation?
> Somehow, I'd expect that the date and amount are the relevant fields. The 
> description is something for me (the user) to add notes about the transaction 
> and is basically irrelevant for anyone else, therefore not requiring 
> re-reconciliation with another account statement (i.e. bank or credit card 
> statement). Just wondering what your case is.
> 
> Cheers,
> 
> Alen
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel 
> <https://lists.gnucash.org/mailman/listinfo/gnucash-devel>
> 

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

Feedback about 2.7.8

[Christoph R]

Hi,

since 2.7.8 is deemed a release candidate I am giving it a try on MacOS High 
Sierra. 

here is my feedback so far:
It choked on one of my files, which worked fine with 2.6 and was probably 
created with 2.4 or even earlier.  There was an out-of range date in the price 
database which I corrected manually. But normal users would have been lost.
adding “EXTRA_ARGS=--nofile” to Library/Application\ Support/Gnucash/gnucashrc 
does not have any effect any more. 
Normal accounting with aqbanking and trading accounts seems to work fine. My 
reports are fine.
Finally I can change unreconciled splits in a transaction with reconciled 
splits again. Changing account or value of a reconciled split gives me the 
correct warning as needed. Yeah!
But I can change the description of a reconciled split without a warning. I 
need to file a bug report on that.
Fonts and icons are different - due to gtk3 - and not necessarily to my liking. 
I had customised .gtkrc-2.0.gnucash a bit and of course this does not work any 
more. Unfortunately I did not figure out how to customise gtk3 on MacOS. Any 
help would be appreciated

Besides the nitpicks above it looks pretty good. Thanks for all the good work!

Cheers,
Christoph

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

Bug #771667

[Christoph R]

Hi Devs,

just wondering if something is wrong with the solution provided in 
https://bugzilla.gnome.org/show_bug.cgi?id=771667 
 ?

If I can help in any way to get that into the code line by e.g. creating a pull 
request, I am happy to help.

Cheers,
Christoph

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

Re: Intended behavior of automatic decimal point (bug 120940)

[Christoph R]

> I agree that the only sane way to have auto-decimal is to disable it if the 
> input is a formula. The other sane approach is to remove it completely.

I cast my vote again: I never found the current behaviour buggy. I actually 
think it is pretty consistent: Any number without a point is shifted. Anything 
with a point is normal. Easy to understand for me.

And I would hate to loose the auto-decimal functionality. It saves me a ton of 
typing.

Cheers,
Christoph

> Am 28.07.2017 um 05:24 schrieb John Ralls :
> 
> 
> 
>> On Jul 27, 2017, at 6:27 PM, Eric Siegerman  wrote:
>> 
>> On Thu, Jul 27, 2017 at 08:20:50AM +, David T. via gnucash-devel wrote:
>>> I think of the decimal placement as applying to the final number in the 
>>> field
>>> (as a sort of edit mask, if you will), rather than a preprocessing function
>>> that would apply to every element in an equation.
>> 
>> I'm not sure that would quite work either.
>> 
>> Currently, for simple numbers with no arithmetic, "1000" gets
>> auto-decimal-pointed ("scaled" hereafter), but "4.50" doesn't,
>> which are both just what one wants.  The same should apply in
>> formulas (I think! -- but more about that at the end).  Assuming
>> two auto-decimal places, consider:
>>   1000 + 4.50
>> 
>> I (think I) want the first term to get scaled, but not the
>> second, giving a result of 14.50.
>> 
>> OK, so how about we scale each term separately, so that:
>>   1000 * 3 + 450 -> 34.50
>> but also:
>>   1000 * 3 + 4.50 -> 34.50
>> ("->" meaning "yields a result of", since "=" just looks wrong
>> under the circumstances :-) ).
>> 
>> But then:
>>   10.00 * 3 + 4.50 -> 34.50
>> We didn't want to scale the first term after all.
>> 
>> I've thought of a couple of different approaches:
>> - scale each term's resulting value if the term only contains
>>   integers:
>>   1000*3 + 4000   -> 30 + 40  = 70.00
>>   1000*3 + 4000.  -> 30 + 4000= 4030.00
>>   1000*3. + 4000  -> 3000 + 40= 3040.00
>>   1000*3. + 4000. -> 3000 + 4000  = 7000.00
>> 
>> - scale each term's *first* number if it's an integer,
>>   but never second or subsequent numbers:
>>   1000 * 3   -> 30
>>   1000 * 3.  -> 30
>>   1000. * 3  -> 3000
>>   1000. * 3. -> 1000
>>   This is based on the thought that ($20 * $3) is meaningless;
>>   it only makes sense to multiply money by something that isn't
>>   money
>> 
>> But neither of those works in all situations.
>> 
>> 
>> The easiest way out, I think, is to never scale formulas at all,
>> only simple numbers.  So:
>>   4000   -> 40.00 # as currently happens
>>   40.-> 40.00 # likewise
>> But:
>>   4000+1 -> 4001.00
>> 
>> That's how my truly ancient copy of Excel behaves.  (I don't
>> have access to a modern one.)
>> 
>> 
>> Or perhaps: for formulas, scale the final result (as you say),
>> but only if *all* of the numeric values the user typed are
>> integers:
>>   1000*3 + 4000   -> 70.00
>>   1000*3 + 4000.  -> 7000.00
>>   1000*3. + 4000  -> 7000.00
>>   1000.*3 + 4000  -> 7000.00
>> 
>> That could boil down to:
>>   Scale the final result unless the original input string
>>   contains any "."s (or ","s depending on locale)
>> (without even any need to worry whether it's a number or
>> a formula).
>> 
>> But given that it's not entirely clear how even a simple:
>>   1000 + 4.50
>> should behave, anything with any subtlety at all is going to want
>> a fair amount of testing to see whether people actually find it
>> usable.  So an unsubtle approach like "never scale formulas" is
>> probably the safest place to start.
> 
> I agree that the only sane way to have auto-decimal is to disable it if the 
> input is a formula. The other sane approach is to remove it completely.
> 
> 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: Intended behavior of automatic decimal point (bug 120940)

[Christoph R]

> Put another way, the current behavior would result in the decimal being moved 
> four places on an entry like "1200/35", which would be at variance with the 
> actual setting. 

Actually not since (1200/100)/(35/100) = 1200/35. 
But you are right for 1200*35 which yields 12.0*0.35 = 4.2.

As a stupid user I accepted this behaviour as correct so far :-)

Cheers,
Christoph

> Am 27.07.2017 um 10:20 schrieb David T. <sunfis...@yahoo.com>:
> 
> Christoph,
> 
> I disagree, and clearly the people on the bug don't see it that way either. 
> 
> I think of the decimal placement as applying to the final number in the field 
> (as a sort of edit mask, if you will), rather than a preprocessing function 
> that would apply to every element in an equation. 
> 
> The current behavior yields different decimal placement results in the same 
> register, which is highly confusing. 
> 
> Put another way, the current behavior would result in the decimal being moved 
> four places on an entry like "1200/35", which would be at variance with the 
> actual setting. 
> 
> I can't see how that is appropriate. 
> 
> David
> 
> 
> On Thu, Jul 27, 2017 at 11:04, Christoph R
> <subscriptions+lis...@rohland.net> wrote:
> I do not even see this as a bug. Any number without a decimal point is 
> divided by 100. Which makes the input “20.44/2” in fact 20.44/0.02 which is 
> 1,022.00
> 
> Cheers,
> Christoph
> 
>> Am 26.07.2017 um 09:58 schrieb David T. via gnucash-devel 
>> <gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>>:
>> 
>> Sumit, 
>> As I understand it, the example you gave  (560 becomes 5.60) is intended 
>> behavior. And, as far as I am concerned, the explanation in the help is 
>> sufficient, if not inspiring. 
>> It seems to me the problem in the underlying bug is that the decimal 
>> algorithm needs to be applied after any calculations, but that is not how 
>> it's being done. The age of the bug suggests that the feature is not heavily 
>> used, or that users have worked around the oddity. 
>> David
>> 
>> 
>> 
>>  On Wed, Jul 26, 2017 at 11:50, Sumit Bhardwaj<bhardw...@gmail.com 
>> <mailto:bhardw...@gmail.com>> wrote:   ​Hi,
>> 
>> In an attempt to fix a long-standing bug (
>> https://bugzilla.gnome.org/show_bug.cgi?id=120940 
>> <https://bugzilla.gnome.org/show_bug.cgi?id=120940>), I looked at the code
>> and have a question on intended behavior of automatic decimal point.
>> 
>> From the doc (http://gnucash.org/viewdoc.phtml?doc=help 
>> <http://gnucash.org/viewdoc.phtml?doc=help>), I see this
>> description for automatic decimal point.
>>> *Automatic Decimal Point:* This option will automatically insert a
>> decimal point into numbers you type in.​
>> 
>> It's not clear from the help that "560" will be converted to "5.60" with
>> automatic decimal points set to 2. Is that the intended behavior? If so,
>> should we edit the help?
>> 
>> There is a bug in handling the fractions when auto-decimal points. I can
>> try to fix that, but wanted to get the developers' take on the intended
>> behavior first.
>> 
>> Thanks,
>> Sumit
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel 
>> <https://lists.gnucash.org/mailman/listinfo/gnucash-devel>
>> 
>> 
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel 
>> <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: Intended behavior of automatic decimal point (bug 120940)

[Christoph R]

I do not even see this as a bug. Any number without a decimal point is divided 
by 100. Which makes the input “20.44/2” in fact 20.44/0.02 which is 1,022.00

Cheers,
Christoph

> Am 26.07.2017 um 09:58 schrieb David T. via gnucash-devel 
> :
> 
> Sumit, 
> As I understand it, the example you gave  (560 becomes 5.60) is intended 
> behavior. And, as far as I am concerned, the explanation in the help is 
> sufficient, if not inspiring. 
> It seems to me the problem in the underlying bug is that the decimal 
> algorithm needs to be applied after any calculations, but that is not how 
> it's being done. The age of the bug suggests that the feature is not heavily 
> used, or that users have worked around the oddity. 
> David
> 
> 
> 
>  On Wed, Jul 26, 2017 at 11:50, Sumit Bhardwaj > wrote:   ​Hi,
> 
> In an attempt to fix a long-standing bug (
> https://bugzilla.gnome.org/show_bug.cgi?id=120940), I looked at the code
> and have a question on intended behavior of automatic decimal point.
> 
> From the doc (http://gnucash.org/viewdoc.phtml?doc=help), I see this
> description for automatic decimal point.
>> *Automatic Decimal Point:* This option will automatically insert a
> decimal point into numbers you type in.​
> 
> It's not clear from the help that "560" will be converted to "5.60" with
> automatic decimal points set to 2. Is that the intended behavior? If so,
> should we edit the help?
> 
> There is a bug in handling the fractions when auto-decimal points. I can
> try to fix that, but wanted to get the developers' take on the intended
> behavior first.
> 
> Thanks,
> Sumit
> ___
> 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: Travis test failure in test-import-map

[Christoph R]

I did this, but of course the test did not fail this time

Gruß,
Christoph

> Am 10.03.2017 um 20:37 schrieb John Ralls <jra...@ceridwen.us>:
> 
>> 
>> On Mar 10, 2017, at 11:27 AM, Christoph R <subscriptions+lis...@rohland.net> 
>> wrote:
>> 
>> Hi,
>> 
>> when creating a pull request against master to fix a bug in the taxinvoice 
>> report I get a test failure in test-import-map. 
>> 
>> This does not seem to be at all related to my change. Can somebody confirm 
>> that?
> 
> It's not, it's an intermittent failure that's been driving us nuts for weeks.
> 
> Could you push a change to .travis.yml, adding the line
> after_failure: "cat src/engine/test/test-import-map.log"
> 
> to your fix_taxinvoice_bills branch? If it fails after that push it will at 
> least show what the problem is.
> 
> Regards,
> John Ralls

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

Travis test failure in test-import-map

[Christoph R]

Hi,

when creating a pull request against master to fix a bug in the taxinvoice 
report I get a test failure in test-import-map. 

This does not seem to be at all related to my change. Can somebody confirm that?

Cheers,
Christoph

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

Re: gnucash-on-osx master: Add googletest module, dependency for master branch.

[Christoph R]

Hi Geert and John,

Today I tested the latest changes. The removal of goffice is fine. 

But the change to cmake for gnucash-git did not work for me. First it wanted 
the static libs for boost. I added them to the install and could compile then. 
But the resulting binary failed on me with:
dyld: Library not loaded: 
/Users/christoph/gnucash-unstable/lib/gnucash/libgncmod-ledger-core.dylib
  Referenced from: 
/Users/christoph/gnucash-unstable/_jhbuild/root-gnucash-git/Users/christoph/gnucash-unstable/bin/gnucash
  Reason: image not found

My jhbuild version seems to be different than John's. It lets the install tool 
install into a intermediary directory under $PREFIX/_jhbuild before moving it 
into the final destination. This also makes the boost install step fail if you 
install directly into the final directory.

Cheers,
Christoph

> Am 08.03.2017 um 12:39 schrieb Geert Janssens  >:
> 
> On dinsdag 7 maart 2017 23:15:45 CET John Ralls wrote:
>> Updated   via  https://github.com/Gnucash/gnucash-on-osx/commit/8c590b16 
>> 
>> (commit) from  https://github.com/Gnucash/gnucash-on-osx/commit/7334ab3a 
>> 
>> (commit)
>> 
>> 
>> 
>> commit 8c590b1696bf97a7dfc0d394ea2dfd9392d77b6a
>> Author: John Ralls >
>> Date:   Tue Mar 7 14:14:51 2017 -0800
>> 
>>Add googletest module, dependency for master branch.
>> 
>> 
> This reminds me goffice should no longer be considered a dependency for 
> master 
> branch. I have pushed a fix, but can't test myself right now. Can you let me 
> know on your next build whether my patch was ok ?
> 
> Geert
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org 
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




Gruß,
Christoph

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

Re: Gnucash-git build problems on MacoSX/Quartz

[Christoph R]

Hi John,

that made it! 

I did not see the comment in gnucash-modules. Instead I followed the 
instructions on the wiki page plus google. I will make a reference to 
gnucash.modules for latest instructions in the wiki.

Thanks,
Christoph

> Am 07.03.2017 um 23:05 schrieb John Ralls <jra...@ceridwen.us>:
> 
> 
>> On Mar 7, 2017, at 1:07 PM, Christoph R <subscriptions+lis...@rohland.net> 
>> wrote:
>> 
>> Hi John and others,
>> 
>> I am trying to get the master branch to compile for a week now without real 
>> success.
>> 
>> jhbuild builds most packages fine. 
>> 
>> here are the manual steps I have done:
>> I patched guile to not use clock_getcpuclockid; 
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23870 
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23870>
>> I had to build boost with "./b2 address-model=32 architecture=x86” to get a 
>> i386 build instead of a 64 bit build
>> Several modules choked on git dirty trees, which I fixed with "git reset 
>> --hard HEAD”
>> 
>> But the final build of gnucash-git fails with:
>> "ce-9/boot-9.scm:109:20: In procedure dynamic-link: file: 
>> "libtest-core-guile", message: "file not found"
>> make[3]: *** [unittest-support.go] Error 1”
>> 
>> I can get around this with calling “make -i”. This will build a gnucash 
>> binary. 
>> When starting this it fails with “dyld: Library not loaded: 
>> libboost_regex.dylib”.
>> When starting it with “DYLD_FALLBACK_LIBRARY_PATH=~/gnucash-unstable/lib 
>> ./gnucash-unstable/bin/gnucash” gnucash is starting fine and compiling all 
>> the scheme files.
>> 
>> Calling make with “DYLD_PRINT_LIBRARIES=1” does not show anything.
>> John, you mentioned to build libtool with LD_DEBUG_LOADERS. How do I do that?
>> 
>> Any help is appreciated!
> 
> 
> LT_DEBUG_LOADERS, not LD...
> In a jhbuild shell cd to $PREFIX/src/libtool-2.4.6 and run
>  ./configure --prefix $PREFIX CFLAGS="$CFLAGS -DLT_DEBUG_LOADERS" && make 
> clean && make && make install
> 
> The boost build parameters are in a comment just before the boost module in 
> gnucash.modules. Note that that comment also says that you must run 
> install_name_tool on the result; the full command is in the modules. That 
> fixes the rpaths in the boost libraries so that they'll link without having 
> to set any of the ld flags. You'll need to re-link gnucash and all of its 
> modules afterwards.
> 
> Regards,
> John Ralls
> 

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

Gnucash-git build problems on MacoSX/Quartz

[Christoph R]

Hi John and others,

I am trying to get the master branch to compile for a week now without real 
success.

jhbuild builds most packages fine. 

here are the manual steps I have done:
I patched guile to not use clock_getcpuclockid; 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23870 

I had to build boost with "./b2 address-model=32 architecture=x86” to get a 
i386 build instead of a 64 bit build
Several modules choked on git dirty trees, which I fixed with "git reset --hard 
HEAD”

But the final build of gnucash-git fails with:
"ce-9/boot-9.scm:109:20: In procedure dynamic-link: file: "libtest-core-guile", 
message: "file not found"
make[3]: *** [unittest-support.go] Error 1”

I can get around this with calling “make -i”. This will build a gnucash binary. 
When starting this it fails with “dyld: Library not loaded: 
libboost_regex.dylib”.
When starting it with “DYLD_FALLBACK_LIBRARY_PATH=~/gnucash-unstable/lib 
./gnucash-unstable/bin/gnucash” gnucash is starting fine and compiling all the 
scheme files.

Calling make with “DYLD_PRINT_LIBRARIES=1” does not show anything.
John, you mentioned to build libtool with LD_DEBUG_LOADERS. How do I do that?

Any help is appreciated!

Cheers,
Christoph

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

Re: gncEntryComputeValue exported to python?

[Christoph R]

Hi Derek,

Yeah, I am on that track already. 

So far I focused on the reporting side only. Goal was to show the price before 
taxes in taxinvoice.scm instead of the typed in price. I have a working version 
by adding (and calling) a gncEntryGetInvNetPrice function which calculates this 
from the existing struct entry. Just working out how to provide that patch for 
review.

My next step will be figuring about good ways to solve the original problem of 
correctly adding purchase entries to invoices with differing tax rates. And I 
that without modifying struct entry.

Cheers,
Christoph

> Am 02.02.2017 um 17:57 schrieb Derek Atkins <warl...@mit.edu>:
> 
> Hi,
> 
> Christoph R <subscriptions+lis...@rohland.net> writes:
> 
>> Hi,
>> 
>> while trying to find a way to solve Bug 776380 – Gross value of bills
>> charged back instead of net value
>> <https://bugzilla.gnome.org/show_bug.cgi?id=776380> I digged into
>> gncEntry.c.
>> My idea is to add a ?_net_price variable to struct _gncEntry and
>> modify gncEntryComputeValue to calculate the net price.
> 
> Is there any particular reason not to use the TaxIncluded flag?  Is
> there some reason where the setting of TaxIncluded and your new proposed
> netPrice flags wouldn't be equivalent?
> 
> -derek
> 
> -- 
>   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>   Member, MIT Student Information Processing Board  (SIPB)
>   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
>   warl...@mit.eduPGP key available

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

gncEntryComputeValue exported to python?

[Christoph R]

Hi,

while trying to find a way to solve  Bug 776380 – Gross value of bills charged 
back instead of net value  I 
digged into gncEntry.c.
My idea is to add a ?_net_price variable to struct _gncEntry and modify 
gncEntryComputeValue to calculate the net price.

To my big surprise I found gncEntryComputeValue exported as a python binding. 
Since gncEntryComputeValue operates on a private struct in gncEntry I cannot 
believe that it should be exported to python.

Anything I missed?

Cheers,
Christoph

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