Re: [GNC-dev] gnucash-devel Digest, Vol 190, Issue 31

[John Ralls]

> On Jan 24, 2019, at 8:02 PM, Alex Aycinena  wrote:
> 
> Are you off your meds again?
> 
> I suggest anyone responding to his emails, including myself, is off his
> meds as well.

Or on the self-prescribed sort.

Regards,
John Ralls


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

Re: [GNC-dev] gnucash-devel Digest, Vol 190, Issue 31

[Alex Aycinena]

> -- Forwarded message --
> From: Wm 
> To: gnucash-de...@lists.gnucash.org
> Cc:
> Bcc:
> Date: Thu, 24 Jan 2019 17:37:30 +
> Subject: Re: [GNC-dev] Alphavantage strategies
> On 22/01/2019 15:16, John Ralls wrote:
>
> > Wm,
> >
> > F::Q has had a commit to add 6 seconds between requests in its git repo
> for almost a year, but the maintainer hasn’t been able to make time to do a
> new release. This has been discussed several times on the user list.
>
> Naughty F::Q ... don't be silly, the notion exists, it got used but not
> implemented.  I don't think we (gnc and other people that use F::Q)
> should presume they should protect us from being bad citizens.
>
> And something else, the 6 seconds is growing, 16 seconds, maybe 61
> seconds soon, I don't know what the back off should be but I know for
> sure gnc is not suitable for trading (by that I mean prices within a day
> or maybe within a few days).
>
> > There’s also already a price-priority built into GnuCash.
>
>  > >There are several levels, but the significant ones are
> > transaction-creation,
>
> I certainly know about that one and expect most people experience it
> ordinarily in buying food, etc
>
> > finance-quote,
>
> I think you have the order wrong
>
> > price-editor.
>
> I think an actual price overrides.
>
> >Sources to the right can replace sources to their left
>
> my reading of what you are saying is that the price-editor should
> override the actual, but I'm not convinced that is really what you mean.
>
> >and themselves but not sources to the right, so e.g. once  you’ve created
> a price in the price editor >that’s the one for the day.
>
> Hmmmn, I'm going to pause and think about that.
>
> I think that is a wrong-thing: I think the actual human level price is
> the price for the day for a person or small or modest sized organisation
> rather than the price editor price, if you toss in the ordinary stuff
> like some people and organisations can't get prices at the moment, what
> do you think is the right price for the day?
>
> Is it the market price (big wide world) or the price they could achieve
> at the time on the day they attempted to get a price?
>
> I am genuinely unsure about this, JohnR [99] , I think the price I have
> for something must be the price for the day *because* the gnc model of
> last price falls apart if it is supplanted.
>
> [99] and other sensible commentators, remote as they may be
> ===
>
> I live in London, I don't vote for Trump, if it matters I think Brexit
> is dumb, I have access to market prices.
>
> I'm generally ok with a price a person creates being prime (if I buy an
> option on DogFood and Wall at USD200 per kg of federal_employee that is
> my price for supporting Trump, right?) [1]
>
> > I don’t want GnuCash to make assumptions about what F::Q does
> internally,
>
> My break: I agree
>
> I also think it will be very expensive for gnc and similar applications
> that utilize F::Q to start from scratch.
>
> > so I think the algorithm you’re proposing would look like:
> >
> > 1 Make list of commodities to retrieve from Alphavantage
>
> doesn't gnc do that anyway? if that wasn't true we wouldn't be fucking
> about choosing which source we wanted a quote from, FFS
>
> > 2 Check for prices for today, splitting the above list into have-price
> and don’t-have-price
>
> I think this is a good approach but it breaks if many people ask the
> same question at or about the same time or repeatedly.
>
> I don't know the answer to gnc and F::Q *not* being asked
> ===
> alphabet share price
> ===
> I don't use gnc or F::Q for that but I expect many people do.
>
> > 3 Request the don’t-have-price list. If it partly fails, wait 60 seconds
> and return to 2.
>
> Almost, I think the person should get a list, similar to the one
> presented at presented that says,
> "we couldn't get the price for
> FuckwitAndCompany
> MayAndIdiots
> CorbynAndWeird"
>
> but instead of asking the dumb question about storing the prices it may
> have obtained
>
> think about this
>
> at the moment the gnc model gets good prices and throws them away!
>
> How fucking idiotic and Trump like is that?
>
> You have information?
>
> What is the best thing to do?
>
> I know!  Discard it!
>
> Duh
>
> Sensible people store information, prices, etc  why is gnc *discarding*
> what it does get?  I simply don't understand this.  Maybe someone else
> is whacking F::Q for a perfect complete set of all their data and
> someone else is just trying to work out if their small business is
> likely to get fucked by Brexit.
>
> Why does gnc not store the prices it did get and then ask "do you want
> me to try again, the sources may be fucked, I may not be able to get a
> price again for a day or so because the fuckwit Trump is holding things
> up" or whatever excuse you have but here is the question
>
> WHY IS GNC *NOT* STORING PRICES IT DOES GET?
> WHY IS GNC *DISCARDING* PRICES WHEN WE KNOW THEY ARE BECOMING MORE
> EXPENSIVE?
>
> > 4 Wait 60 

Re: [GNC-dev] Test failure

[Stephen M. Butler]

On 1/24/19 7:36 PM, Christopher Lam wrote:
> Revert is a git terminology, not a gnucash one. Welcome to version
> control.

That's the manual to which I referred.  It meant something else to my
mind when I first saw your post.  But, after further thought, my
previous thought was faulty.


My first boss after college would draw a picture to describe the
difference between a bug and a feature.

I can't draw so a word will have to do (at less than a thousand words)!

BUG:  draw stick figure.


FEATURE:  Add pants, tie, gloves, shoes and a top hat.


MORAL:  A feature is a bug all dressed up and ready to go out.

>
> Please remember this revert is reverting a buggy code with a previous
> buggy code, so, cannot be consisted safe to package; best wait until
> the clever devs can find a proper fix for gnc-date.
>
> On Fri., 25 Jan. 2019, 05:46 Stephen M. Butler   wrote:
>
> OH!  Light bulb on!
> OK.  I understand what you said earlier.  I'll put the patches
> back into
> the packaging.
>
> Thanks for clearing that up.
>
> --Steve
>
> PS Looking in manual for 'revert' command.
>

-- 
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8


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

Re: [GNC-dev] Test failure

[Christopher Lam]

Revert is a git terminology, not a gnucash one. Welcome to version control.

Please remember this revert is reverting a buggy code with a previous buggy
code, so, cannot be consisted safe to package; best wait until the clever
devs can find a proper fix for gnc-date.

On Fri., 25 Jan. 2019, 05:46 Stephen M. Butler  OH!  Light bulb on!
> OK.  I understand what you said earlier.  I'll put the patches back into
> the packaging.
>
> Thanks for clearing that up.
>
> --Steve
>
> PS Looking in manual for 'revert' command.
>
>
>
> On 1/24/19 1:06 PM, Christopher Lam wrote:
> > Because e31f4c3f9 is causing errors on my build as well in different
> > ways.
> >
> > PS e31f4c3f9 must not be reverted for your packaging - please be
> > patient while a proper fix is pending.
> >
> > On 25/1/19 3:48 am, Stephen M. Butler wrote:
> >> On 1/24/19 2:32 AM, Christopher Lam wrote:
> >>> Stephen this bug is in 3.4 and was fixed in commit 95bee405c
> >>>
> >>> Could you try "git revert e31f4c3f9" as a test for your "31/12/70"
> >>> test-transaction errors?
> >>
> >> That worked.  Thank you.  BTW, how did you find that it was fixed?  I
> >> ask, because there is another one: 01/24/2019
> >>
> >> -rw-r--r-- 1 steve steve 461 Jan 23 14:16
> >> test--skip-test-stress-options.patch
> >>
> >>   cat test*
> >> Last-Update: 2018-10-02
> >> Forwarded: not-needed
> >> Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=796877
> >> Author: Dmitry Smirnov 
> >> Description: skip broken test
> >>
> >> --- a/gnucash/report/standard-reports/test/CMakeLists.txt
> >> +++ b/gnucash/report/standard-reports/test/CMakeLists.txt
> >> @@ -13,9 +13,8 @@
> >> test-income-gst.scm
> >>   )
> >> set(scm_test_with_textual_ports_SOURCES
> >> -test-stress-options.scm
> >>   )
> >> set(GUILE_DEPENDS
> >> scm-gnc-module
> >>
> >> ==
> >>
> >> Any way I can search and see if this patch is already in maint?
> >>
> >>
> >>> On 24/1/19 3:05 am, Stephen M. Butler wrote:
>  Found this patch on the debian version for 3.4
> 
>  Origin: upstream, https://bugs.gnucash.org/attachment.cgi?id=373094
>  Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=797008
>  Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918057
>  From: Maxim Cournoyer 
>  Date: Wed, 2 Jan 2019 14:46:28 -0500
>  Subject: tests: Fix a test failure in test-transaction.scm.
> 
>  With the New Year upon us, a test which was hard-coded to use 2018 now
>  failed.
> 
>  Fixes issue #797008 (see:
>  https://bugs.gnucash.org/show_bug.cgi?id=797008).
> 
>  * gnucash/report/standard-reports/test/test-transaction.scm:
>  (trep-tests): Use the current year in the test string instead of a
>  static one.
> 
>  --- a/gnucash/report/standard-reports/test/test-transaction.scm
>  +++ b/gnucash/report/standard-reports/test/test-transaction.scm
>  @@ -4,8 +4,9 @@
> (use-modules (gnucash report standard-reports transaction))
> (use-modules (gnucash report stylesheets))
> (use-modules (gnucash report report-system))
> (use-modules (gnucash report report-system test test-extras))
>  +(use-modules (srfi srfi-19))
> (use-modules (srfi srfi-64))
> (use-modules (gnucash engine test srfi64-extras))
> (use-modules (sxml simple))
> (use-modules (sxml xpath))
>  @@ -642,18 +643,20 @@
>   (set-option! options "General" "Common Currency" #t)
>   (set-option! options "General" "Show original currency
>  amount" #t)
>   (set-option! options "Sorting" "Primary Key" 'date)
>   (set-option! options "Sorting" "Primary Subtotal for Date
>  Key" 'none)
>  -  (let* ((sxml (options->sxml options "dual columns")))
>  +  (let* ((sxml (options->sxml options "dual columns"))
>  + (current-year (date->string (current-date) "~y")))
> (test-equal "dual amount column, with original currency
>  headers"
>   (list "Date" "Num" "Description" "Memo/Notes" "Account"
> "Debit (USD)" "Credit (USD)" "Debit" "Credit")
>   (get-row-col sxml 0 #f))
> (test-equal "dual amount column, grand totals available"
>   (list "Grand Total" "$2,280.00" "$2,280.00")
>   (get-row-col sxml -1 #f))
> (test-equal "dual amount column, first transaction correct"
>  -  (list "01/03/18" "$103 income" "Root.Asset.Bank" "$103.00"
>  "$103.00")
>  +  (list (string-append "01/03/" current-year) "$103 income"
>  +"Root.Asset.Bank" "$103.00" "$103.00")
>   (get-row-col sxml 1 #f)))
>   ) 01/24/2019
>   (test-end "display options")
> 
> 
> >>> ___
> >>> gnucash-devel mailing list
> >>> gnucash-devel@gnucash.org
> >>> 

Re: [GNC-dev] Test failure

[Stephen M. Butler]

OH!  Light bulb on!
OK.  I understand what you said earlier.  I'll put the patches back into
the packaging.

Thanks for clearing that up.

--Steve

PS Looking in manual for 'revert' command.



On 1/24/19 1:06 PM, Christopher Lam wrote:
> Because e31f4c3f9 is causing errors on my build as well in different
> ways.
>
> PS e31f4c3f9 must not be reverted for your packaging - please be
> patient while a proper fix is pending.
>
> On 25/1/19 3:48 am, Stephen M. Butler wrote:
>> On 1/24/19 2:32 AM, Christopher Lam wrote:
>>> Stephen this bug is in 3.4 and was fixed in commit 95bee405c
>>>
>>> Could you try "git revert e31f4c3f9" as a test for your "31/12/70"
>>> test-transaction errors?
>>
>> That worked.  Thank you.  BTW, how did you find that it was fixed?  I
>> ask, because there is another one: 01/24/2019
>>
>> -rw-r--r-- 1 steve steve 461 Jan 23 14:16
>> test--skip-test-stress-options.patch
>>
>>   cat test*
>> Last-Update: 2018-10-02
>> Forwarded: not-needed
>> Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=796877
>> Author: Dmitry Smirnov 
>> Description: skip broken test
>>
>> --- a/gnucash/report/standard-reports/test/CMakeLists.txt
>> +++ b/gnucash/report/standard-reports/test/CMakeLists.txt
>> @@ -13,9 +13,8 @@
>>     test-income-gst.scm
>>   )
>>     set(scm_test_with_textual_ports_SOURCES
>> -    test-stress-options.scm
>>   )
>>     set(GUILE_DEPENDS
>>     scm-gnc-module
>>
>> ==
>>
>> Any way I can search and see if this patch is already in maint?
>>
>>
>>> On 24/1/19 3:05 am, Stephen M. Butler wrote:
 Found this patch on the debian version for 3.4

 Origin: upstream, https://bugs.gnucash.org/attachment.cgi?id=373094
 Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=797008
 Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918057
 From: Maxim Cournoyer 
 Date: Wed, 2 Jan 2019 14:46:28 -0500
 Subject: tests: Fix a test failure in test-transaction.scm.

 With the New Year upon us, a test which was hard-coded to use 2018 now
 failed.

 Fixes issue #797008 (see:
 https://bugs.gnucash.org/show_bug.cgi?id=797008).

 * gnucash/report/standard-reports/test/test-transaction.scm:
 (trep-tests): Use the current year in the test string instead of a
 static one.

 --- a/gnucash/report/standard-reports/test/test-transaction.scm
 +++ b/gnucash/report/standard-reports/test/test-transaction.scm
 @@ -4,8 +4,9 @@
    (use-modules (gnucash report standard-reports transaction))
    (use-modules (gnucash report stylesheets))
    (use-modules (gnucash report report-system))
    (use-modules (gnucash report report-system test test-extras))
 +(use-modules (srfi srfi-19))
    (use-modules (srfi srfi-64))
    (use-modules (gnucash engine test srfi64-extras))
    (use-modules (sxml simple))
    (use-modules (sxml xpath))
 @@ -642,18 +643,20 @@
  (set-option! options "General" "Common Currency" #t)
  (set-option! options "General" "Show original currency
 amount" #t)
  (set-option! options "Sorting" "Primary Key" 'date)
  (set-option! options "Sorting" "Primary Subtotal for Date
 Key" 'none)
 -  (let* ((sxml (options->sxml options "dual columns")))
 +  (let* ((sxml (options->sxml options "dual columns"))
 +     (current-year (date->string (current-date) "~y")))
    (test-equal "dual amount column, with original currency
 headers"
  (list "Date" "Num" "Description" "Memo/Notes" "Account"
    "Debit (USD)" "Credit (USD)" "Debit" "Credit")
  (get-row-col sxml 0 #f))
    (test-equal "dual amount column, grand totals available"
  (list "Grand Total" "$2,280.00" "$2,280.00")
  (get-row-col sxml -1 #f))
    (test-equal "dual amount column, first transaction correct"
 -  (list "01/03/18" "$103 income" "Root.Asset.Bank" "$103.00"
 "$103.00")
 +  (list (string-append "01/03/" current-year) "$103 income"
 +        "Root.Asset.Bank" "$103.00" "$103.00")
  (get-row-col sxml 1 #f)))
  ) 01/24/2019
      (test-end "display options")


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


-- 
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

___
gnucash-devel mailing list
gnucash-devel@gnucash.org

Re: [GNC-dev] Test failure

[Christopher Lam]

Because e31f4c3f9 is causing errors on my build as well in different ways.

PS e31f4c3f9 must not be reverted for your packaging - please be patient 
while a proper fix is pending.


On 25/1/19 3:48 am, Stephen M. Butler wrote:

On 1/24/19 2:32 AM, Christopher Lam wrote:

Stephen this bug is in 3.4 and was fixed in commit 95bee405c

Could you try "git revert e31f4c3f9" as a test for your "31/12/70"
test-transaction errors?


That worked.  Thank you.  BTW, how did you find that it was fixed?  I
ask, because there is another one:

-rw-r--r-- 1 steve steve 461 Jan 23 14:16
test--skip-test-stress-options.patch

  cat test*
Last-Update: 2018-10-02
Forwarded: not-needed
Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=796877
Author: Dmitry Smirnov 
Description: skip broken test

--- a/gnucash/report/standard-reports/test/CMakeLists.txt
+++ b/gnucash/report/standard-reports/test/CMakeLists.txt
@@ -13,9 +13,8 @@
    test-income-gst.scm
  )
  
  set(scm_test_with_textual_ports_SOURCES

-    test-stress-options.scm
  )
  
  set(GUILE_DEPENDS

    scm-gnc-module

==

Any way I can search and see if this patch is already in maint?



On 24/1/19 3:05 am, Stephen M. Butler wrote:

Found this patch on the debian version for 3.4

Origin: upstream, https://bugs.gnucash.org/attachment.cgi?id=373094
Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=797008
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918057
From: Maxim Cournoyer 
Date: Wed, 2 Jan 2019 14:46:28 -0500
Subject: tests: Fix a test failure in test-transaction.scm.

With the New Year upon us, a test which was hard-coded to use 2018 now
failed.

Fixes issue #797008 (see:
https://bugs.gnucash.org/show_bug.cgi?id=797008).

* gnucash/report/standard-reports/test/test-transaction.scm:
(trep-tests): Use the current year in the test string instead of a
static one.

--- a/gnucash/report/standard-reports/test/test-transaction.scm
+++ b/gnucash/report/standard-reports/test/test-transaction.scm
@@ -4,8 +4,9 @@
   (use-modules (gnucash report standard-reports transaction))
   (use-modules (gnucash report stylesheets))
   (use-modules (gnucash report report-system))
   (use-modules (gnucash report report-system test test-extras))
+(use-modules (srfi srfi-19))
   (use-modules (srfi srfi-64))
   (use-modules (gnucash engine test srfi64-extras))
   (use-modules (sxml simple))
   (use-modules (sxml xpath))
@@ -642,18 +643,20 @@
     (set-option! options "General" "Common Currency" #t)
     (set-option! options "General" "Show original currency
amount" #t)
     (set-option! options "Sorting" "Primary Key" 'date)
     (set-option! options "Sorting" "Primary Subtotal for Date
Key" 'none)
-  (let* ((sxml (options->sxml options "dual columns")))
+  (let* ((sxml (options->sxml options "dual columns"))
+     (current-year (date->string (current-date) "~y")))
   (test-equal "dual amount column, with original currency
headers"
     (list "Date" "Num" "Description" "Memo/Notes" "Account"
   "Debit (USD)" "Credit (USD)" "Debit" "Credit")
     (get-row-col sxml 0 #f))
   (test-equal "dual amount column, grand totals available"
     (list "Grand Total" "$2,280.00" "$2,280.00")
     (get-row-col sxml -1 #f))
   (test-equal "dual amount column, first transaction correct"
-  (list "01/03/18" "$103 income" "Root.Asset.Bank" "$103.00"
"$103.00")
+  (list (string-append "01/03/" current-year) "$103 income"
+        "Root.Asset.Bank" "$103.00" "$103.00")
     (get-row-col sxml 1 #f)))
     )
     (test-end "display options")



___
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: [GNC-dev] Test failure

[Stephen M. Butler]

On 1/24/19 2:32 AM, Christopher Lam wrote:
> Stephen this bug is in 3.4 and was fixed in commit 95bee405c
>
> Could you try "git revert e31f4c3f9" as a test for your "31/12/70"
> test-transaction errors?


That worked.  Thank you.  BTW, how did you find that it was fixed?  I
ask, because there is another one:

-rw-r--r-- 1 steve steve 461 Jan 23 14:16
test--skip-test-stress-options.patch

 cat test*
Last-Update: 2018-10-02
Forwarded: not-needed
Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=796877
Author: Dmitry Smirnov 
Description: skip broken test

--- a/gnucash/report/standard-reports/test/CMakeLists.txt
+++ b/gnucash/report/standard-reports/test/CMakeLists.txt
@@ -13,9 +13,8 @@
   test-income-gst.scm
 )
 
 set(scm_test_with_textual_ports_SOURCES
-    test-stress-options.scm
 )
 
 set(GUILE_DEPENDS
   scm-gnc-module

==

Any way I can search and see if this patch is already in maint?


>
> On 24/1/19 3:05 am, Stephen M. Butler wrote:
>> Found this patch on the debian version for 3.4
>>
>> Origin: upstream, https://bugs.gnucash.org/attachment.cgi?id=373094
>> Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=797008
>> Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918057
>> From: Maxim Cournoyer 
>> Date: Wed, 2 Jan 2019 14:46:28 -0500
>> Subject: tests: Fix a test failure in test-transaction.scm.
>>
>> With the New Year upon us, a test which was hard-coded to use 2018 now
>> failed.
>>
>> Fixes issue #797008 (see:
>> https://bugs.gnucash.org/show_bug.cgi?id=797008).
>>
>> * gnucash/report/standard-reports/test/test-transaction.scm:
>> (trep-tests): Use the current year in the test string instead of a
>> static one.
>>
>> --- a/gnucash/report/standard-reports/test/test-transaction.scm
>> +++ b/gnucash/report/standard-reports/test/test-transaction.scm
>> @@ -4,8 +4,9 @@
>>   (use-modules (gnucash report standard-reports transaction))
>>   (use-modules (gnucash report stylesheets))
>>   (use-modules (gnucash report report-system))
>>   (use-modules (gnucash report report-system test test-extras))
>> +(use-modules (srfi srfi-19))
>>   (use-modules (srfi srfi-64))
>>   (use-modules (gnucash engine test srfi64-extras))
>>   (use-modules (sxml simple))
>>   (use-modules (sxml xpath))
>> @@ -642,18 +643,20 @@
>>     (set-option! options "General" "Common Currency" #t)
>>     (set-option! options "General" "Show original currency
>> amount" #t)
>>     (set-option! options "Sorting" "Primary Key" 'date)
>>     (set-option! options "Sorting" "Primary Subtotal for Date
>> Key" 'none)
>> -  (let* ((sxml (options->sxml options "dual columns")))
>> +  (let* ((sxml (options->sxml options "dual columns"))
>> +     (current-year (date->string (current-date) "~y")))
>>   (test-equal "dual amount column, with original currency
>> headers"
>>     (list "Date" "Num" "Description" "Memo/Notes" "Account"
>>   "Debit (USD)" "Credit (USD)" "Debit" "Credit")
>>     (get-row-col sxml 0 #f))
>>   (test-equal "dual amount column, grand totals available"
>>     (list "Grand Total" "$2,280.00" "$2,280.00")
>>     (get-row-col sxml -1 #f))
>>   (test-equal "dual amount column, first transaction correct"
>> -  (list "01/03/18" "$103 income" "Root.Asset.Bank" "$103.00"
>> "$103.00")
>> +  (list (string-append "01/03/" current-year) "$103 income"
>> +        "Root.Asset.Bank" "$103.00" "$103.00")
>>     (get-row-col sxml 1 #f)))
>>     )
>>     (test-end "display options")
>>
>>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


-- 
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

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

Re: [GNC-dev] Debian files

[Stephen M. Butler]

On 1/24/19 8:21 AM, Colin Law wrote:
> That is working well for me (on a virgin 18.10 system).
>
> Excellent work.
>
> Colin


Thanks Colin and everyone else for your pointers and help along the way.

>
> On Wed, 23 Jan 2019 at 23:15, Stephen M. Butler  wrote:
>> On 1/23/19 12:55 PM, Colin Law wrote:
>>> Steve, are you sure it is worth all this effort? If the flatpak
>>> nightly and stable builds become available then they will be perfectly
>>> acceptable for Ubuntu.
>>>
>>> Colin
>>
>> Excellent question!  Probably not.  But then, I have some success this
>> afternoon (US West Coast).
>>
>> I did the following and it worked for me.  I've uploaded the three deb
>> files (along with the ddeb and changes, etc) to:
>>
>> https://drive.google.com/open?id=1fV_fURy6c77e7gf6S41lTacM7dFyy7VD
>>
>> I still need to figure out how to package this for Launchpad -- but I
>> think I just crossed over the biggest hurdle.
>>
>> Besides, how else am I supposed to learn this stuff?  <>
>>
>> Items I see still need to be done:
>>
>> 1.  Script the steps I made so I can automate it and avoid typing mistakes.
>>
>> 2.  Push to launchpad so they can rebuild it.
>>
>> Probably not worth it -- but it feels good to have accomplished this so far!
>>
<>
>> V3.4 came up just fine.

<>

-- 
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

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

Re: [GNC-dev] Alphavantage strategies

[Wm via gnucash-devel]

On 22/01/2019 15:16, John Ralls wrote:


Wm,

F::Q has had a commit to add 6 seconds between requests in its git repo for 
almost a year, but the maintainer hasn’t been able to make time to do a new 
release. This has been discussed several times on the user list.


Naughty F::Q ... don't be silly, the notion exists, it got used but not 
implemented.  I don't think we (gnc and other people that use F::Q) 
should presume they should protect us from being bad citizens.


And something else, the 6 seconds is growing, 16 seconds, maybe 61 
seconds soon, I don't know what the back off should be but I know for 
sure gnc is not suitable for trading (by that I mean prices within a day 
or maybe within a few days).


There’s also already a price-priority built into GnuCash. 


> >There are several levels, but the significant ones are
transaction-creation, 


I certainly know about that one and expect most people experience it 
ordinarily in buying food, etc



finance-quote,


I think you have the order wrong


price-editor.


I think an actual price overrides.

Sources to the right can replace sources to their left 


my reading of what you are saying is that the price-editor should 
override the actual, but I'm not convinced that is really what you mean.



and themselves but not sources to the right, so e.g. once  you’ve created a price 
in the price editor >that’s the one for the day.


Hmmmn, I'm going to pause and think about that.

I think that is a wrong-thing: I think the actual human level price is 
the price for the day for a person or small or modest sized organisation 
rather than the price editor price, if you toss in the ordinary stuff 
like some people and organisations can't get prices at the moment, what 
do you think is the right price for the day?


Is it the market price (big wide world) or the price they could achieve 
at the time on the day they attempted to get a price?


I am genuinely unsure about this, JohnR [99] , I think the price I have 
for something must be the price for the day *because* the gnc model of 
last price falls apart if it is supplanted.


[99] and other sensible commentators, remote as they may be
===

I live in London, I don't vote for Trump, if it matters I think Brexit 
is dumb, I have access to market prices.


I'm generally ok with a price a person creates being prime (if I buy an 
option on DogFood and Wall at USD200 per kg of federal_employee that is 
my price for supporting Trump, right?) [1]


I don’t want GnuCash to make assumptions about what F::Q does internally, 


My break: I agree

I also think it will be very expensive for gnc and similar applications 
that utilize F::Q to start from scratch.



so I think the algorithm you’re proposing would look like:

1 Make list of commodities to retrieve from Alphavantage


doesn't gnc do that anyway? if that wasn't true we wouldn't be fucking 
about choosing which source we wanted a quote from, FFS



2 Check for prices for today, splitting the above list into have-price and 
don’t-have-price


I think this is a good approach but it breaks if many people ask the 
same question at or about the same time or repeatedly.


I don't know the answer to gnc and F::Q *not* being asked
===
alphabet share price
===
I don't use gnc or F::Q for that but I expect many people do.


3 Request the don’t-have-price list. If it partly fails, wait 60 seconds and 
return to 2.


Almost, I think the person should get a list, similar to the one 
presented at presented that says,

"we couldn't get the price for
FuckwitAndCompany
MayAndIdiots
CorbynAndWeird"

but instead of asking the dumb question about storing the prices it may 
have obtained


think about this

at the moment the gnc model gets good prices and throws them away!

How fucking idiotic and Trump like is that?

You have information?

What is the best thing to do?

I know!  Discard it!

Duh

Sensible people store information, prices, etc  why is gnc *discarding* 
what it does get?  I simply don't understand this.  Maybe someone else 
is whacking F::Q for a perfect complete set of all their data and 
someone else is just trying to work out if their small business is 
likely to get fucked by Brexit.


Why does gnc not store the prices it did get and then ask "do you want 
me to try again, the sources may be fucked, I may not be able to get a 
price again for a day or so because the fuckwit Trump is holding things 
up" or whatever excuse you have but here is the question


WHY IS GNC *NOT* STORING PRICES IT DOES GET?
WHY IS GNC *DISCARDING* PRICES WHEN WE KNOW THEY ARE BECOMING MORE 
EXPENSIVE?



4 Wait 60 seconds and request the have-price list.


if someone needs minute by minute prices I think they should pay for 
that,  I'm ok with once a day at best.



The code would go into libgnucash/scm/price-quotes.scm.


at which point it would be obscure to me.  I'd know if it worked or not 
afterwards so who are you trying to impress?


===

[1] Trump has moved beyond stupid to 

Re: [GNC-dev] Debian files

[Colin Law]

That is working well for me (on a virgin 18.10 system).

Excellent work.

Colin

On Wed, 23 Jan 2019 at 23:15, Stephen M. Butler  wrote:
>
> On 1/23/19 12:55 PM, Colin Law wrote:
> > Steve, are you sure it is worth all this effort? If the flatpak
> > nightly and stable builds become available then they will be perfectly
> > acceptable for Ubuntu.
> >
> > Colin
>
>
> Excellent question!  Probably not.  But then, I have some success this
> afternoon (US West Coast).
>
> I did the following and it worked for me.  I've uploaded the three deb
> files (along with the ddeb and changes, etc) to:
>
> https://drive.google.com/open?id=1fV_fURy6c77e7gf6S41lTacM7dFyy7VD
>
> I still need to figure out how to package this for Launchpad -- but I
> think I just crossed over the biggest hurdle.
>
> Besides, how else am I supposed to learn this stuff?  <>
>
> Items I see still need to be done:
>
> 1.  Script the steps I made so I can automate it and avoid typing mistakes.
>
> 2.  Push to launchpad so they can rebuild it.
>
> Probably not worth it -- but it feels good to have accomplished this so far!
>
> steve@SteveLaptop:~/Projects/GnuCash$ /*ls -Fal *.deb*/
> -rw-r--r-- 1 steve steve 3901212 Jan 23 14:29 gnucash_3.4_amd64.deb
> -rw-r--r-- 1 steve steve 5027024 Jan 23 14:29 gnucash-common_3.4_all.deb
> -rw-r--r-- 1 steve steve  268880 Jan 23 14:29 python3-gnucash_3.4_amd64.deb
>
>
> steve@SteveLaptop:~/Projects/GnuCash$ */sudo apt install ./*.deb/*
> [sudo] password for steve:
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Note, selecting 'gnucash' instead of './gnucash_3.4_amd64.deb'
> Note, selecting 'gnucash-common' instead of './gnucash-common_3.4_all.deb'
> Note, selecting 'python3-gnucash' instead of
> './python3-gnucash_3.4_amd64.deb'
> The following additional packages will be installed:
>   gnucash-docs libclass-inspector-perl libclass-singleton-perl
> libcommon-sense-perl libdate-manip-perl libdatetime-locale-perl
> libdatetime-perl libdatetime-timezone-perl libfile-sharedir-perl
>   libfinance-quote-perl libhtml-tableextract-perl libjs-jquery
> libjson-perl libjson-xs-perl libtypes-serialiser-perl
> Suggested packages:ls -Fal *.deb
>   libdbd-mysql libhtml-element-extended-perl
> Recommended packages:
>   pythone3-gnucash
> The following NEW packages will be installed:
>   gnucash gnucash-common gnucash-docs libclass-inspector-perl
> libclass-singleton-perl libcommon-sense-perl libdate-manip-perl
> libdatetime-locale-perl libdatetime-perl libdatetime-timezone-perl
>   libfile-sharedir-perl libfinance-quote-perl libhtml-tableextract-perl
> libjs-jquery libjson-perl libjson-xs-perl libtypes-serialiser-perl
> python3-gnucash
> 0 upgraded, 18 newly installed, 0 to remove and 3 not upgraded.
> Need to get 0 B/98.5 MB of archives.
> After this operation, 227 MB of additional disk space will be used.
> Do you want to continue? [Y/n] Y
> Get:1 /home/steve/Projects/GnuCash/gnucash-common_3.4_all.deb
> gnucash-common all 1:3.4 [5,027 kB]
> Get:2 /home/steve/Projects/GnuCash/gnucash_3.4_amd64.deb gnucash amd64
> 1:3.4 [3,901 kB]
> Get:3 /home/steve/Projects/GnuCash/python3-gnucash_3.4_amd64.deb
> python3-gnucash amd64 1:3.4 [269 kB]
> Selecting previously unselected package libjs-jquery.
> (Reading database ... 232220 files and directories currently installed.)
> Preparing to unpack .../00-libjs-jquery_3.2.1-1_all.deb ...ls -Fal *.deb
> Unpacking libjs-jquery (3.2.1-1) ...
> Selecting previously unselected package gnucash-common.
> Preparing to unpack .../01-gnucash-common_3.4_all.deb ...
> Unpacking gnucash-common (1:3.4) ...
> Selecting previously unselected package libhtml-tableextract-perl.
> Preparing to unpack .../02-libhtml-tableextract-perl_2.15-1_all.deb ...
> Unpacking libhtml-tableextract-perl (2.15-1) ...
> Selecting previously unselected package libclass-inspector-perl.
> Preparing to unpack .../03-libclass-inspector-perl_1.32-1_all.deb ...
> Unpacking libclass-inspector-perl (1.32-1) ...
> Selecting previously unselected package libfile-sharedir-perl.
> Preparing to unpack .../04-libfile-sharedir-perl_1.104-1_all.deb ...
> Unpacking libfile-sharedir-perl (1.104-1) ...
> Selecting previously unselected package libdatetime-locale-perl.
> Preparing to unpack .../05-libdatetime-locale-perl_1%3a1.17-1_all.deb
> /sudo apt install ./*.deb/...
> Unpacking libdatetime-locale-perl (1:1.17-1) ...
> Selecting previously unselected package libclass-singleton-perl.
> Preparing to unpack .../06-libclass-singleton-perl_1.5-1_all.deb ...
> Unpacking libclass-singleton-perl (1.5-1) ...
> Selecting previously unselected package libdatetime-timezone-perl.
> Preparing to unpack
> .../07-libdatetime-timezone-perl_1%3a2.18-1+2018d_all.deb ...
> Unpacking libdatetime-timezone-perl (1:2.18-1+2018d) ...
> Selecting previously unselected package libdatetime-perl.
> Preparing to unpack .../08-libdatetime-perl_2%3a1.46-1_amd64.deb ...
> Unpacking libdatetime-perl (2:1.46-1) ...
> 

Re: [GNC-dev] Bugs Web site

[Derek Atkins]

Geert Janssens  writes:

> Hi Bob,
>
> I see the missing icon as well. It should be a large version of our bugzilla-
> gnucash logo IMO.

Hmm, the page source has an empty data in there.  There's no  tag,
so it's not that the graphic is missing, it's just not configured.
I'm not sure where this is supposed to be configured so I'm not sure how
to fix it.

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] New Budget Bar Chart Not Displaying

[Adrien Monteleone]

Okay, disregard other message that just crossed this one.

Regards,
Adrien

> On Jan 24, 2019, at 5:43 AM, Christopher Lam  
> wrote:
> 
> Best build entire branch because of new chartjs dependencies
> 
> On 24/1/19 7:35 pm, Adrien Monteleone wrote:
>> I haven’t built from git yet. (no time like the present) Do I build the 
>> entire branch or can I just dl and build the report?
>> 
>> Regards,
>> Adrien
>> 
>>> On Jan 24, 2019, at 5:09 AM, Christopher Lam  
>>> wrote:
>>> 
>>> Perhaps you can beta-test the budget-barchart, with the report start/end 
>>> dates options removed.
>>> 
>>> This also includes chartJS preview ;-)
>>> 
>>> https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart
>>> 
>>> On 24/1/19 1:42 am, Adrien Monteleone wrote:
 Good question — I think the budget reports are fine, it seems to be the 
 chart that is the odd one out.
 
 As it is currently, for all of the budget reports, you choose the budget 
 you want to report on and the range is determined accordingly. You can’t 
 set it independently. I have no problem with this. I can’t see why someone 
 would want to select a budget to report or chart, but want GC to use 
 transactions from out of the budget period. (well, for comparing 
 performance, sure, but it doesn’t work that way anyway, the Transaction 
 Report is better suited there - see below)
 
 But for the chart, you can choose, as in my example, last year’s budget 
 (or anything other than current year) but the default date window is for 
 this year, which would render no data. Since you can select the budget and 
 date range separately, you can easily end up with either no results, 
 incomplete results, or possibly non-sensical results.
 
 For consistency, the chart should probably pull the date range from the 
 budget choice like the reports do and not offer the options to set the 
 range independently.
 
 -
 
 Now, if the reports and charts allowed you to independently select a 
 budget and date-range for comparison of budget vs. actual (of the chosen 
 period) that would be much more versatile. As it presently stands, you 
 have to copy or re-do your budget each year/quarter. But if you could 
 report a static budget against variable periods, you could have budgets 
 based on something other than dates. (such as different scenarios, 
 regardless of the period)
 
 Making the change that direction would not remove the ability to produce 
 and analyze budget performance on a period basis though. If that route is 
 chosen, I’d suggest some sort of default report/chart page to explain what 
 options need to be chosen to get a desired result. (similar to how some 
 other reports tell you that you need to select some accounts or certain 
 options, rather than just dumping you to a blank page. Note, this would be 
 a good improvement for any report/chart that requires setting options to 
 get a usable result or non-blank page.)
 
 I’m not sure how difficult it would be to have the reports and chart look 
 for budgeted amounts statically but actual performance based on a 
 separately specified range. This might also necessitate some change to the 
 budget options where you would assign values for a generic period without 
 regard to a specific year.
 
 While that all might be nice, the easiest thing to fix right now, I think 
 would be to pattern the General tab of the budget chart similar to the 
 various budget reports.
 
 Regards,
 Adrien
 
> On Jan 23, 2019, at 10:14 AM, Christopher Lam  
> wrote:
> 
> Directed towards Adrien- how should the budgeting reporting options look 
> like?
> 
> Budget has start-date and num(periods)
> 
> Budget-report-date has its own start-date and end-date -- they should be 
> removed?
> 
> I don't use the budgeting tools myself.
> 
> (ytd-budget.scm from years back seems to be a good report)
> 
> On 23/1/19 11:37 pm, Adrien Monteleone wrote:
>> This means the date range for the report (default is start & end of 
>> current accounting period) does not match the budget.
>> 
>> For example, I opened a chart for the 2018 budget and got a blank page.
>> 
>> When I changed the date range to start & end of previous year, I got 
>> charts for my selected accounts with budget and actual bars.
>> 
>> Regards,
>> Adrien
>> 
 ___
 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: [GNC-dev] [GNC] New Budget Bar Chart Not Displaying

[Adrien Monteleone]

I see looking deeper there is a budget-barchart.scm.

Can I just grab that and add it as a custom report? or do I still need to build 
something (or everything) from your branch?

Sorry for the noob git questions.

Regards,
Adrien

> On Jan 24, 2019, at 5:35 AM, Adrien Monteleone 
>  wrote:
> 
> I haven’t built from git yet. (no time like the present) Do I build the 
> entire branch or can I just dl and build the report?
> 
> Regards,
> Adrien
> 
>> On Jan 24, 2019, at 5:09 AM, Christopher Lam  
>> wrote:
>> 
>> Perhaps you can beta-test the budget-barchart, with the report start/end 
>> dates options removed.
>> 
>> This also includes chartJS preview ;-)
>> 
>> https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart
>> 
>> On 24/1/19 1:42 am, Adrien Monteleone wrote:
>>> Good question — I think the budget reports are fine, it seems to be the 
>>> chart that is the odd one out.
>>> 
>>> As it is currently, for all of the budget reports, you choose the budget 
>>> you want to report on and the range is determined accordingly. You can’t 
>>> set it independently. I have no problem with this. I can’t see why someone 
>>> would want to select a budget to report or chart, but want GC to use 
>>> transactions from out of the budget period. (well, for comparing 
>>> performance, sure, but it doesn’t work that way anyway, the Transaction 
>>> Report is better suited there - see below)
>>> 
>>> But for the chart, you can choose, as in my example, last year’s budget (or 
>>> anything other than current year) but the default date window is for this 
>>> year, which would render no data. Since you can select the budget and date 
>>> range separately, you can easily end up with either no results, incomplete 
>>> results, or possibly non-sensical results.
>>> 
>>> For consistency, the chart should probably pull the date range from the 
>>> budget choice like the reports do and not offer the options to set the 
>>> range independently.
>>> 
>>> -
>>> 
>>> Now, if the reports and charts allowed you to independently select a budget 
>>> and date-range for comparison of budget vs. actual (of the chosen period) 
>>> that would be much more versatile. As it presently stands, you have to copy 
>>> or re-do your budget each year/quarter. But if you could report a static 
>>> budget against variable periods, you could have budgets based on something 
>>> other than dates. (such as different scenarios, regardless of the period)
>>> 
>>> Making the change that direction would not remove the ability to produce 
>>> and analyze budget performance on a period basis though. If that route is 
>>> chosen, I’d suggest some sort of default report/chart page to explain what 
>>> options need to be chosen to get a desired result. (similar to how some 
>>> other reports tell you that you need to select some accounts or certain 
>>> options, rather than just dumping you to a blank page. Note, this would be 
>>> a good improvement for any report/chart that requires setting options to 
>>> get a usable result or non-blank page.)
>>> 
>>> I’m not sure how difficult it would be to have the reports and chart look 
>>> for budgeted amounts statically but actual performance based on a 
>>> separately specified range. This might also necessitate some change to the 
>>> budget options where you would assign values for a generic period without 
>>> regard to a specific year.
>>> 
>>> While that all might be nice, the easiest thing to fix right now, I think 
>>> would be to pattern the General tab of the budget chart similar to the 
>>> various budget reports.
>>> 
>>> Regards,
>>> Adrien
>>> 
 On Jan 23, 2019, at 10:14 AM, Christopher Lam  
 wrote:
 
 Directed towards Adrien- how should the budgeting reporting options look 
 like?
 
 Budget has start-date and num(periods)
 
 Budget-report-date has its own start-date and end-date -- they should be 
 removed?
 
 I don't use the budgeting tools myself.
 
 (ytd-budget.scm from years back seems to be a good report)
 
 On 23/1/19 11:37 pm, Adrien Monteleone wrote:
> This means the date range for the report (default is start & end of 
> current accounting period) does not match the budget.
> 
> For example, I opened a chart for the 2018 budget and got a blank page.
> 
> When I changed the date range to start & end of previous year, I got 
> charts for my selected accounts with budget and actual bars.
> 
> Regards,
> Adrien
> 
>>> 
>>> ___
>>> 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

Re: [GNC-dev] [GNC] New Budget Bar Chart Not Displaying

[Christopher Lam]

Best build entire branch because of new chartjs dependencies

On 24/1/19 7:35 pm, Adrien Monteleone wrote:

I haven’t built from git yet. (no time like the present) Do I build the entire 
branch or can I just dl and build the report?

Regards,
Adrien


On Jan 24, 2019, at 5:09 AM, Christopher Lam  wrote:

Perhaps you can beta-test the budget-barchart, with the report start/end dates 
options removed.

This also includes chartJS preview ;-)

https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart

On 24/1/19 1:42 am, Adrien Monteleone wrote:

Good question — I think the budget reports are fine, it seems to be the chart 
that is the odd one out.

As it is currently, for all of the budget reports, you choose the budget you 
want to report on and the range is determined accordingly. You can’t set it 
independently. I have no problem with this. I can’t see why someone would want 
to select a budget to report or chart, but want GC to use transactions from out 
of the budget period. (well, for comparing performance, sure, but it doesn’t 
work that way anyway, the Transaction Report is better suited there - see below)

But for the chart, you can choose, as in my example, last year’s budget (or 
anything other than current year) but the default date window is for this year, 
which would render no data. Since you can select the budget and date range 
separately, you can easily end up with either no results, incomplete results, 
or possibly non-sensical results.

For consistency, the chart should probably pull the date range from the budget 
choice like the reports do and not offer the options to set the range 
independently.

-

Now, if the reports and charts allowed you to independently select a budget and 
date-range for comparison of budget vs. actual (of the chosen period) that 
would be much more versatile. As it presently stands, you have to copy or re-do 
your budget each year/quarter. But if you could report a static budget against 
variable periods, you could have budgets based on something other than dates. 
(such as different scenarios, regardless of the period)

Making the change that direction would not remove the ability to produce and 
analyze budget performance on a period basis though. If that route is chosen, 
I’d suggest some sort of default report/chart page to explain what options need 
to be chosen to get a desired result. (similar to how some other reports tell 
you that you need to select some accounts or certain options, rather than just 
dumping you to a blank page. Note, this would be a good improvement for any 
report/chart that requires setting options to get a usable result or non-blank 
page.)

I’m not sure how difficult it would be to have the reports and chart look for 
budgeted amounts statically but actual performance based on a separately 
specified range. This might also necessitate some change to the budget options 
where you would assign values for a generic period without regard to a specific 
year.

While that all might be nice, the easiest thing to fix right now, I think would 
be to pattern the General tab of the budget chart similar to the various budget 
reports.

Regards,
Adrien


On Jan 23, 2019, at 10:14 AM, Christopher Lam  wrote:

Directed towards Adrien- how should the budgeting reporting options look like?

Budget has start-date and num(periods)

Budget-report-date has its own start-date and end-date -- they should be 
removed?

I don't use the budgeting tools myself.

(ytd-budget.scm from years back seems to be a good report)

On 23/1/19 11:37 pm, Adrien Monteleone wrote:

This means the date range for the report (default is start & end of current 
accounting period) does not match the budget.

For example, I opened a chart for the 2018 budget and got a blank page.

When I changed the date range to start & end of previous year, I got charts for 
my selected accounts with budget and actual bars.

Regards,
Adrien


___
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: [GNC-dev] [GNC] New Budget Bar Chart Not Displaying

[Adrien Monteleone]

I haven’t built from git yet. (no time like the present) Do I build the entire 
branch or can I just dl and build the report?

Regards,
Adrien

> On Jan 24, 2019, at 5:09 AM, Christopher Lam  
> wrote:
> 
> Perhaps you can beta-test the budget-barchart, with the report start/end 
> dates options removed.
> 
> This also includes chartJS preview ;-)
> 
> https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart
> 
> On 24/1/19 1:42 am, Adrien Monteleone wrote:
>> Good question — I think the budget reports are fine, it seems to be the 
>> chart that is the odd one out.
>> 
>> As it is currently, for all of the budget reports, you choose the budget you 
>> want to report on and the range is determined accordingly. You can’t set it 
>> independently. I have no problem with this. I can’t see why someone would 
>> want to select a budget to report or chart, but want GC to use transactions 
>> from out of the budget period. (well, for comparing performance, sure, but 
>> it doesn’t work that way anyway, the Transaction Report is better suited 
>> there - see below)
>> 
>> But for the chart, you can choose, as in my example, last year’s budget (or 
>> anything other than current year) but the default date window is for this 
>> year, which would render no data. Since you can select the budget and date 
>> range separately, you can easily end up with either no results, incomplete 
>> results, or possibly non-sensical results.
>> 
>> For consistency, the chart should probably pull the date range from the 
>> budget choice like the reports do and not offer the options to set the range 
>> independently.
>> 
>> -
>> 
>> Now, if the reports and charts allowed you to independently select a budget 
>> and date-range for comparison of budget vs. actual (of the chosen period) 
>> that would be much more versatile. As it presently stands, you have to copy 
>> or re-do your budget each year/quarter. But if you could report a static 
>> budget against variable periods, you could have budgets based on something 
>> other than dates. (such as different scenarios, regardless of the period)
>> 
>> Making the change that direction would not remove the ability to produce and 
>> analyze budget performance on a period basis though. If that route is 
>> chosen, I’d suggest some sort of default report/chart page to explain what 
>> options need to be chosen to get a desired result. (similar to how some 
>> other reports tell you that you need to select some accounts or certain 
>> options, rather than just dumping you to a blank page. Note, this would be a 
>> good improvement for any report/chart that requires setting options to get a 
>> usable result or non-blank page.)
>> 
>> I’m not sure how difficult it would be to have the reports and chart look 
>> for budgeted amounts statically but actual performance based on a separately 
>> specified range. This might also necessitate some change to the budget 
>> options where you would assign values for a generic period without regard to 
>> a specific year.
>> 
>> While that all might be nice, the easiest thing to fix right now, I think 
>> would be to pattern the General tab of the budget chart similar to the 
>> various budget reports.
>> 
>> Regards,
>> Adrien
>> 
>>> On Jan 23, 2019, at 10:14 AM, Christopher Lam  
>>> wrote:
>>> 
>>> Directed towards Adrien- how should the budgeting reporting options look 
>>> like?
>>> 
>>> Budget has start-date and num(periods)
>>> 
>>> Budget-report-date has its own start-date and end-date -- they should be 
>>> removed?
>>> 
>>> I don't use the budgeting tools myself.
>>> 
>>> (ytd-budget.scm from years back seems to be a good report)
>>> 
>>> On 23/1/19 11:37 pm, Adrien Monteleone wrote:
 This means the date range for the report (default is start & end of 
 current accounting period) does not match the budget.
 
 For example, I opened a chart for the 2018 budget and got a blank page.
 
 When I changed the date range to start & end of previous year, I got 
 charts for my selected accounts with budget and actual bars.
 
 Regards,
 Adrien
 
>> 
>> ___
>> 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: [GNC-dev] [GNC] New Budget Bar Chart Not Displaying

[Christopher Lam]

Perhaps you can beta-test the budget-barchart, with the report start/end 
dates options removed.


This also includes chartJS preview ;-)

https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart

On 24/1/19 1:42 am, Adrien Monteleone wrote:

Good question — I think the budget reports are fine, it seems to be the chart 
that is the odd one out.

As it is currently, for all of the budget reports, you choose the budget you 
want to report on and the range is determined accordingly. You can’t set it 
independently. I have no problem with this. I can’t see why someone would want 
to select a budget to report or chart, but want GC to use transactions from out 
of the budget period. (well, for comparing performance, sure, but it doesn’t 
work that way anyway, the Transaction Report is better suited there - see below)

But for the chart, you can choose, as in my example, last year’s budget (or 
anything other than current year) but the default date window is for this year, 
which would render no data. Since you can select the budget and date range 
separately, you can easily end up with either no results, incomplete results, 
or possibly non-sensical results.

For consistency, the chart should probably pull the date range from the budget 
choice like the reports do and not offer the options to set the range 
independently.

-

Now, if the reports and charts allowed you to independently select a budget and 
date-range for comparison of budget vs. actual (of the chosen period) that 
would be much more versatile. As it presently stands, you have to copy or re-do 
your budget each year/quarter. But if you could report a static budget against 
variable periods, you could have budgets based on something other than dates. 
(such as different scenarios, regardless of the period)

Making the change that direction would not remove the ability to produce and 
analyze budget performance on a period basis though. If that route is chosen, 
I’d suggest some sort of default report/chart page to explain what options need 
to be chosen to get a desired result. (similar to how some other reports tell 
you that you need to select some accounts or certain options, rather than just 
dumping you to a blank page. Note, this would be a good improvement for any 
report/chart that requires setting options to get a usable result or non-blank 
page.)

I’m not sure how difficult it would be to have the reports and chart look for 
budgeted amounts statically but actual performance based on a separately 
specified range. This might also necessitate some change to the budget options 
where you would assign values for a generic period without regard to a specific 
year.

While that all might be nice, the easiest thing to fix right now, I think would 
be to pattern the General tab of the budget chart similar to the various budget 
reports.

Regards,
Adrien


On Jan 23, 2019, at 10:14 AM, Christopher Lam  wrote:

Directed towards Adrien- how should the budgeting reporting options look like?

Budget has start-date and num(periods)

Budget-report-date has its own start-date and end-date -- they should be 
removed?

I don't use the budgeting tools myself.

(ytd-budget.scm from years back seems to be a good report)

On 23/1/19 11:37 pm, Adrien Monteleone wrote:

This means the date range for the report (default is start & end of current 
accounting period) does not match the budget.

For example, I opened a chart for the 2018 budget and got a blank page.

When I changed the date range to start & end of previous year, I got charts for 
my selected accounts with budget and actual bars.

Regards,
Adrien



___
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: [GNC-dev] Test failure

[Christopher Lam]

Stephen this bug is in 3.4 and was fixed in commit 95bee405c

Could you try "git revert e31f4c3f9" as a test for your "31/12/70" 
test-transaction errors?


On 24/1/19 3:05 am, Stephen M. Butler wrote:

Found this patch on the debian version for 3.4

Origin: upstream, https://bugs.gnucash.org/attachment.cgi?id=373094
Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=797008
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918057
From: Maxim Cournoyer 
Date: Wed, 2 Jan 2019 14:46:28 -0500
Subject: tests: Fix a test failure in test-transaction.scm.

With the New Year upon us, a test which was hard-coded to use 2018 now
failed.

Fixes issue #797008 (see:
https://bugs.gnucash.org/show_bug.cgi?id=797008).

* gnucash/report/standard-reports/test/test-transaction.scm:
(trep-tests): Use the current year in the test string instead of a
static one.

--- a/gnucash/report/standard-reports/test/test-transaction.scm
+++ b/gnucash/report/standard-reports/test/test-transaction.scm
@@ -4,8 +4,9 @@
  (use-modules (gnucash report standard-reports transaction))
  (use-modules (gnucash report stylesheets))
  (use-modules (gnucash report report-system))
  (use-modules (gnucash report report-system test test-extras))
+(use-modules (srfi srfi-19))
  (use-modules (srfi srfi-64))
  (use-modules (gnucash engine test srfi64-extras))
  (use-modules (sxml simple))
  (use-modules (sxml xpath))
@@ -642,18 +643,20 @@
    (set-option! options "General" "Common Currency" #t)
    (set-option! options "General" "Show original currency amount" #t)
    (set-option! options "Sorting" "Primary Key" 'date)
    (set-option! options "Sorting" "Primary Subtotal for Date Key" 'none)
-  (let* ((sxml (options->sxml options "dual columns")))
+  (let* ((sxml (options->sxml options "dual columns"))
+     (current-year (date->string (current-date) "~y")))
  (test-equal "dual amount column, with original currency headers"
    (list "Date" "Num" "Description" "Memo/Notes" "Account"
  "Debit (USD)" "Credit (USD)" "Debit" "Credit")
    (get-row-col sxml 0 #f))
  (test-equal "dual amount column, grand totals available"
    (list "Grand Total" "$2,280.00" "$2,280.00")
    (get-row-col sxml -1 #f))
  (test-equal "dual amount column, first transaction correct"
-  (list "01/03/18" "$103 income" "Root.Asset.Bank" "$103.00"
"$103.00")
+  (list (string-append "01/03/" current-year) "$103 income"
+        "Root.Asset.Bank" "$103.00" "$103.00")
    (get-row-col sxml 1 #f)))
    )
  
  (test-end "display options")




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