Re: [GNC-dev] merging failing tests

[John Ralls]

Carsten:

Distilling this to the core, “Why will we not merge a PR with failing tests?”

Simple: If you have a test that exposes a bug, then fixing the bug is part of 
the job. The branch isn’t ready to merge until it’s fixed. That’s because the 
point of unit tests is to tell developers when they’ve broken something and the 
only way that that can work is for all tests to always pass. If there are 
failed tests then the TravisCI email about failing tests on every push becomes 
routine and the exercise becomes pointless.

It’s a bit disingenuous of you to cite PR391 when the comments about failing 
tests and not writing proper SRFI-64 tests were on PR404. Your latest push to 
PR391, which I hadn’t had time to review until now, is much better. It looks 
from the output on TravisCI that there’s one actual problem with gnc-html, that 
it outputs   when it should output #f, and 
several with your expected html. 

PR404 needs at least the same makeover. If you can figure out how to break up 
tests 6-9 into tests that are smaller than whole documents they’d be a lot more 
useful and easier to diagnose problems. Trying to find the discrepancy between 
two 70-line strings when only 32 lines are visible on a TravisCI web page will 
be an exercise in futility.

Regards,
John Ralls

> On Sep 5, 2018, at 2:12 PM, Carsten Rinke  wrote:
> 
> Hi John,
> 
> I transfer this thread to this channel because I think this is not PR 
> specific but more a general issue.
> 
> Let me start by saying that I do not want to "fight to get it merged". For me 
> it is an interesting point to exchange views upon.
> 
> It is specifically about "We're not merging failing tests".
> 
> Example: PR#391
> I have tried to follow your advice how to write SRFI-64 as good as I can at 
> this point of time (I'm sure you will still find room for improvement, and 
> that is fully ok).
> 
> In the test result from travis you can now see which tests are failing, and 
> why, and I even mentioned the bug reports that I opened for it.
> 
> That the tests are not merged straight away is expected, no discussion about 
> it, especially as long as the indicated bugs are not finally accepted as bugs.
> 
> But assume we agree that some bugs are really bugs, meaning, the test is 
> correct, and it is correct that it is failing because the code is wrong:
> Why not merging a failing test? Why waiting for the code fix?
> 
> Just to repeat: Please take these as open questions, I am not suggesting an 
> answer here.
> 
> BTW:
> I think I can propose fixes for most of the indicated bugs in PR#391, but I 
> was planning to forward them as separate PRs. Good that you mention that I 
> should place them into the existing PR.
> 
> /Carsten
> 
> 
> Am 05.09.2018 um 01:29 schrieb John Ralls:
>> 
>> Since you haven't followed my instructions about how to write a SRFI-64 test 
>> it's impossible to tell from the output what is the problem... including 
>> knowing whether there's actually a bug in the gnc-html code or if it's in 
>> your tests. Yes, that's a defect in most of the Scheme test code, but fixing 
>> it was one of the main goals of adopting a proper unit test framework.
>> 
>> If your tests did find bugs then the PR needs to include fixes as separate 
>> commits. We're not merging failing tests and we're not merging non-tests. 
>> Consider that both of the failing tests in this PR seem not to matter: All 
>> of the existing report tests pass and the line charts work in use. If an 
>> important jqplot module isn't present or if the line chart plotting code was 
>> actually defective on Arch Linux that wouldn't be the case.
>> 
>> —
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub 
>> , or 
>> mute the thread 
>> .
>> 
> 
> ___
> 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] merging failing tests

[Christopher Lam]

Hi

As an untrained hacker, I think the issue is whether these "bugs" are 
really worth fixing at all.


I can imagine the history of the dark ages; and html was being refined, 
and previously the reports were outputting plaintext or directly to 
screen via X calls; the hackers decide to start outputting html via a 
new upcoming framework called gtkhtml, with fancy tables, italics, font 
sizes... GTKhtml comes with an over-engineered api to accept x/y 
coordinates, font families, headers, pre-CSS style-sheets, paper size. 
The hacker succeeds in outputting reports and uses the api calls to 
render a nice report, helpfully reusing gtkhtml terminology.


Time has evolved, and gtkhtml is now obsolete. The api calls must be 
changed to output html. The next hacker tries to fix the minimum code to 
remove gtkhtml code, but every time a change happens, some reports break 
or dataloss occurs. Therefore they fix the minimum code to move away 
from gtkhtml and leave large swathes of dead old code around. "If it's 
not broke, don't fix it!"


I think that completing the internal framework to successfully implement 
html api code (as you have identified is incomplete) is not time well 
spent. None of the reports will generate html without headers, for 
instance. So, the code for testing headers should be ripped out, rather 
than implemented. And code should be ripped out safely, ensuring no 
tests fail, no dataloss occurs, all reports pass (including the existing 
multicolumn report) and all potential users (including those not 
subscribed to userlist or devel) are unaffected, and no subsequent 
hacker will have to fix.


There is still a need for more hackers, so, I'm sure your efforts are 
appreciated, but it's already a major headache to try understand the 
previous hackers and we don't want the situation to get worse.


I think this helps? I'd love to add more features too but I'm 
constraining myself too because every new code snippet, framework, or 
boolean test is another headache for future maintainers.


On 06/09/18 05:12, Carsten Rinke wrote:

Hi John,

I transfer this thread to this channel because I think this is not PR 
specific but more a general issue.


Let me start by saying that I do not want to "fight to get it merged". 
For me it is an interesting point to exchange views upon.


It is specifically about "We're not merging failing tests".

Example: PR#391
I have tried to follow your advice how to write SRFI-64 as good as I 
can at this point of time (I'm sure you will still find room for 
improvement, and that is fully ok).


In the test result from travis you can now see which tests are 
failing, and why, and I even mentioned the bug reports that I opened 
for it.


That the tests are not merged straight away is expected, no discussion 
about it, especially as long as the indicated bugs are not finally 
accepted as bugs.


But assume we agree that some bugs are really bugs, meaning, the test 
is correct, and it is correct that it is failing because the code is 
wrong:

Why not merging a failing test? Why waiting for the code fix?

Just to repeat: Please take these as open questions, I am not 
suggesting an answer here.


BTW:
I think I can propose fixes for most of the indicated bugs in PR#391, 
but I was planning to forward them as separate PRs. Good that you 
mention that I should place them into the existing PR.


/Carsten


Am 05.09.2018 um 01:29 schrieb John Ralls:


Since you haven't followed my instructions about how to write a 
SRFI-64 test it's impossible to tell from the output what is the 
problem... including knowing whether there's actually a bug in the 
gnc-html code or if it's in your tests. Yes, that's a defect in most 
of the Scheme test code, but fixing it was one of the main goals of 
adopting a proper unit test framework.


If your tests did find bugs then the PR needs to include fixes as 
separate commits. We're not merging failing tests and we're not 
merging non-tests. Consider that both of the failing tests in this PR 
seem not to matter: All of the existing report tests pass and the 
line charts work in use. If an important jqplot module isn't present 
or if the line chart plotting code was actually defective on Arch 
Linux that wouldn't be the case.


—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub 
, 
or mute the thread 
.




___
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

[GNC-dev] merging failing tests

[Carsten Rinke]

Hi John,

I transfer this thread to this channel because I think this is not PR 
specific but more a general issue.


Let me start by saying that I do not want to "fight to get it merged". 
For me it is an interesting point to exchange views upon.


It is specifically about "We're not merging failing tests".

Example: PR#391
I have tried to follow your advice how to write SRFI-64 as good as I can 
at this point of time (I'm sure you will still find room for 
improvement, and that is fully ok).


In the test result from travis you can now see which tests are failing, 
and why, and I even mentioned the bug reports that I opened for it.


That the tests are not merged straight away is expected, no discussion 
about it, especially as long as the indicated bugs are not finally 
accepted as bugs.


But assume we agree that some bugs are really bugs, meaning, the test is 
correct, and it is correct that it is failing because the code is wrong:

Why not merging a failing test? Why waiting for the code fix?

Just to repeat: Please take these as open questions, I am not suggesting 
an answer here.


BTW:
I think I can propose fixes for most of the indicated bugs in PR#391, 
but I was planning to forward them as separate PRs. Good that you 
mention that I should place them into the existing PR.


/Carsten


Am 05.09.2018 um 01:29 schrieb John Ralls:


Since you haven't followed my instructions about how to write a 
SRFI-64 test it's impossible to tell from the output what is the 
problem... including knowing whether there's actually a bug in the 
gnc-html code or if it's in your tests. Yes, that's a defect in most 
of the Scheme test code, but fixing it was one of the main goals of 
adopting a proper unit test framework.


If your tests did find bugs then the PR needs to include fixes as 
separate commits. We're not merging failing tests and we're not 
merging non-tests. Consider that both of the failing tests in this PR 
seem not to matter: All of the existing report tests pass and the line 
charts work in use. If an important jqplot module isn't present or if 
the line chart plotting code was actually defective on Arch Linux that 
wouldn't be the case.


—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub 
, 
or mute the thread 
.




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

Re: [GNC-dev] Wiki FAQ Page

[Adrien Monteleone]

Yeah, those seem to be internal to the wiki, not an external broken link. But 
then, if the page itself isn’t changing, just the named anchor, it might not 
matter. The page still exists, so someone clicking an FAQ link from a mailing 
list message will still get dropped into the same page, but if the named anchor 
is not found, they’ll be focused to the top of the page rather than the 
intended place. Essentially then that named anchor will function as a basic 
page anchor which is just fine.

Regards,
Adrien

> On Sep 5, 2018, at 11:13 AM, Derek Atkins  wrote:
> 
> I feel like MediaWiki also has a way to fix that, too, but it may only
> work at a page level and not at an anchor level.
> 
> c.f. https://meta.wikimedia.org/wiki/Help:Redirect
> and
> https://meta.wikimedia.org/wiki/Help:Section#Section_linking_and_redirects
> 
> -derek
> 
> On Tue, September 4, 2018 12:42 pm, Adrien Monteleone wrote:
>> Broken links can be handled by permanent redirects in the web server’s
>> .htaccess file. I think Derek would be the one to add those in. If you
>> compile the list for him to copy & paste, I’m sure that would help. The
>> end result is someone can click the old link from the mailing list and the
>> server will drop them in the new location.
>> 
>> On a content note, I suspect you could have three separate headings for
>> “Managing GnuCash files”, “Configuring GnuCash” and “Customizing GnuCash”.
>> I’m thinking the latter to be more geared towards things like CSS and
>> where to put custom reports, while ‘Configuring’ is more related to
>> tweaking the app preferences.
>> 
>> Regards,
>> Adrien
>> 
>>> On Sep 4, 2018, at 9:43 AM, David T. via gnucash-devel
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> I am digging in to the FAQ page with an eye to rationalizing the
>>> accumulated mess. My hope is to make it easier for uers to find answers
>>> to their questions.
>>> 
>>> Currently, the structure of the page does not accurately reflect the
>>> content of the questions. For example, the section “Installation
>>> Troubleshooting” covers two broad and disparate question areas.
>>> 
>>> In addition, numerous questions have been placed haphazardly in sections
>>> to which they do not belong. For example, questions about theming do not
>>> belong under Installation (for Mac or Windows), but IMHO under “GnuCash
>>> Files and managing a GnuCash installation”, which itself would be better
>>> named “Configuring and Managing”
>>> 
>>> On a practical level, as I rearrange the FAQ on some pretty substantial
>>> levels, questions and headings on the page will be changed.
>>> 
>>> First issue: I do not see a way to see whether the wiki has any
>>> instances of links to a specific question. Clicking “What links here”
>>> only shows links to the overall FAQ page.
>>> 
>>> Second issue: many links from the mailing lists will no longer work,
>>> which may cause problems for users searching the ML archives and
>>> retrieving the stale links. How should this be handled?
>>> 
>>> Now, on a meta-level, I think the primary headings here might be better
>>> arranged as follows:
>>> 
>>> 1. General Questions
>>> [move “Accounting Questions” to this section]
>>> 2. Installation
>>> 3. Using GnuCash [moved ahead of cunfiguring]
>>> 4. Configuring and Managing
>>> [Move “Customizing" questions from current section 8 to this section]
>>> 5. Troubleshooting
>>> 6. Exporting and Importing Data
>>> 7. Business Features
>>> [Move entire Developing GnuCash section of questions to the pages
>>> established for Developers]
>>> 
>>> I welcome input and feedback.
>>> 
>>> David
>>> 
>>> 
>>> ___
>>> 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
>> 
> 
> 
> -- 
>   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] Wiki FAQ Page

[Derek Atkins]

I feel like MediaWiki also has a way to fix that, too, but it may only
work at a page level and not at an anchor level.

c.f. https://meta.wikimedia.org/wiki/Help:Redirect
and
https://meta.wikimedia.org/wiki/Help:Section#Section_linking_and_redirects

-derek

On Tue, September 4, 2018 12:42 pm, Adrien Monteleone wrote:
> Broken links can be handled by permanent redirects in the web server’s
> .htaccess file. I think Derek would be the one to add those in. If you
> compile the list for him to copy & paste, I’m sure that would help. The
> end result is someone can click the old link from the mailing list and the
> server will drop them in the new location.
>
> On a content note, I suspect you could have three separate headings for
> “Managing GnuCash files”, “Configuring GnuCash” and “Customizing GnuCash”.
> I’m thinking the latter to be more geared towards things like CSS and
> where to put custom reports, while ‘Configuring’ is more related to
> tweaking the app preferences.
>
> Regards,
> Adrien
>
>> On Sep 4, 2018, at 9:43 AM, David T. via gnucash-devel
>>  wrote:
>>
>> Hello,
>>
>> I am digging in to the FAQ page with an eye to rationalizing the
>> accumulated mess. My hope is to make it easier for uers to find answers
>> to their questions.
>>
>> Currently, the structure of the page does not accurately reflect the
>> content of the questions. For example, the section “Installation
>> Troubleshooting” covers two broad and disparate question areas.
>>
>> In addition, numerous questions have been placed haphazardly in sections
>> to which they do not belong. For example, questions about theming do not
>> belong under Installation (for Mac or Windows), but IMHO under “GnuCash
>> Files and managing a GnuCash installation”, which itself would be better
>> named “Configuring and Managing”
>>
>> On a practical level, as I rearrange the FAQ on some pretty substantial
>> levels, questions and headings on the page will be changed.
>>
>> First issue: I do not see a way to see whether the wiki has any
>> instances of links to a specific question. Clicking “What links here”
>> only shows links to the overall FAQ page.
>>
>> Second issue: many links from the mailing lists will no longer work,
>> which may cause problems for users searching the ML archives and
>> retrieving the stale links. How should this be handled?
>>
>> Now, on a meta-level, I think the primary headings here might be better
>> arranged as follows:
>>
>> 1. General Questions
>>  [move “Accounting Questions” to this section]
>> 2. Installation
>> 3. Using GnuCash [moved ahead of cunfiguring]
>> 4. Configuring and Managing
>>  [Move “Customizing" questions from current section 8 to this section]
>> 5. Troubleshooting
>> 6. Exporting and Importing Data
>> 7. Business Features
>>  [Move entire Developing GnuCash section of questions to the pages
>> established for Developers]
>>
>> I welcome input and feedback.
>>
>> David
>>
>>
>> ___
>> 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
>


-- 
   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] Wiki FAQ Page

[Adrien Monteleone]

Broken links can be handled by permanent redirects in the web server’s 
.htaccess file. I think Derek would be the one to add those in. If you compile 
the list for him to copy & paste, I’m sure that would help. The end result is 
someone can click the old link from the mailing list and the server will drop 
them in the new location.

On a content note, I suspect you could have three separate headings for 
“Managing GnuCash files”, “Configuring GnuCash” and “Customizing GnuCash”. I’m 
thinking the latter to be more geared towards things like CSS and where to put 
custom reports, while ‘Configuring’ is more related to tweaking the app 
preferences.

Regards,
Adrien 

> On Sep 4, 2018, at 9:43 AM, David T. via gnucash-devel 
>  wrote:
> 
> Hello,
> 
> I am digging in to the FAQ page with an eye to rationalizing the accumulated 
> mess. My hope is to make it easier for uers to find answers to their 
> questions. 
> 
> Currently, the structure of the page does not accurately reflect the content 
> of the questions. For example, the section “Installation Troubleshooting” 
> covers two broad and disparate question areas. 
> 
> In addition, numerous questions have been placed haphazardly in sections to 
> which they do not belong. For example, questions about theming do not belong 
> under Installation (for Mac or Windows), but IMHO under “GnuCash Files and 
> managing a GnuCash installation”, which itself would be better named 
> “Configuring and Managing”
> 
> On a practical level, as I rearrange the FAQ on some pretty substantial 
> levels, questions and headings on the page will be changed. 
> 
> First issue: I do not see a way to see whether the wiki has any instances of 
> links to a specific question. Clicking “What links here” only shows links to 
> the overall FAQ page.
> 
> Second issue: many links from the mailing lists will no longer work, which 
> may cause problems for users searching the ML archives and retrieving the 
> stale links. How should this be handled?
> 
> Now, on a meta-level, I think the primary headings here might be better 
> arranged as follows:
> 
> 1. General Questions
>  [move “Accounting Questions” to this section]
> 2. Installation
> 3. Using GnuCash [moved ahead of cunfiguring]
> 4. Configuring and Managing
>  [Move “Customizing" questions from current section 8 to this section]
> 5. Troubleshooting
> 6. Exporting and Importing Data
> 7. Business Features
>  [Move entire Developing GnuCash section of questions to the pages 
> established for Developers]
> 
> I welcome input and feedback.
> 
> David
> 
> 
> ___
> 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] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[Christopher Lam]

Hi All

The state of balsheet-pnl for now, imho is feature complete and has nicer
well-documented internal functions. However I'm still stumped by various
equity calculations, unsure how to emulate all combinations of
trading/unrealized/realized gains/losses. JRalls has helpfully created some
illustrative tests, but these would need plugging into the new balsheet
which isn't immediately obvious. And for me to spend a few months getting
to understand the formulas.

For this matter I wouldn't be keen to replace the current balsheet yet. I
know some users are keen to maintain the current balsheet's calculations
and I can't guarantee the new one will produce the same equity section.

So, for now, the options are to add the multicolumn balsheet as a new menu
item and seek user feedback about equity calculations, or leave it unmerged
and unfinished, which is another shame.

On Fri, 17 Aug 2018 at 21:20, Christopher Lam 
wrote:

> Hi David
>
> I refer you to a prior discussion:
> https://lists.gnucash.org/pipermail/gnucash-user/2018-June/077758.html
>
> I appreciate balance-sheet is a formal accounting report. The problem is,
> as always, within the details.
>
> Initially I thought we could leave currencies unconverted.
>
> Then Geert reminded me *all* currencies *must* be allowed to convert to a
> user-selected common-currency. Because a balance-sheet is really a
> valuation of all of your assets, into a legal currency of your choice. The
> price used must be either (1) actual transactional prices - either
> average-cost or weighted-average - both terms whose exact definitions
> currently elude me despite looking at code (2) from the pricedb -
> latest/nearest.
> (* PS what's the strategy if accounts are in EUR/USD/GBP, with plenty of
> pricing data in these 3 currencies, but user prefers common-currency to be
> JPY, and pricedb has EUR/USD, USD/GBP, GBP/AUD and AUD/JPY amounts? Answer:
> Internal logic will try to find an intermediate pricedb pair, eg.
> GBP->AUD->JPY at the nearest date available, and EUR/USD will result to 0
> JPY Except my report will convert GBP->JPY correctly and leave EUR/USD
> in original currency )
>
> The next issues are all to do with Equity:
>
> (1) trading-accounts are optional. As we know, trading accounts will
> compute *REALIZED GAINS,* so that EUR>USD>EUR transfers at different
> prices *must* result in a realized-gain recording. If the trading-accounts
> are disabled, the current balance-sheet will make an attempt at computing
> its own Realized Gains. It assumes the user hasn't recorded realized-gains
> during currency conversions. IMHO There's currently a logic error if there
> are trading-accounts in a book with book property trading-accounts
> disabled. Moreover, if trading-accounts are disabled, and the user has
> recorded but underestimated realized gains, I think the balsheet *should*
> report the delta amount as unrealized-gains too???
>
> (2) selection of a report common-currency must compute *UNREALIZED GAINS*,
> e.g. if EUR/USD/GBP accounts are reported for balsheet in JPY, and JPY has
> increased in value between transaction-dates and report-date, presumably
> all amounts must increase? This is not proven correctly handled yet. I
> still think there's an error - the Asset report-currency amount will use
> the higher price, but the unrealized gains are not computed when
> trading-accounts are disabled.
>
> (3) income and expense amounts are technically closed to equity on
> balsheet-date but we don't enforce this, so, their difference must account
> for *RETAINED EARNINGS* or some other similar heading. If user has closed
> books correctly on balsheet-date, then the balsheet should report retained
> earnings to be $0.
> If anyone can help me, please do. Spreadsheets or formula sheets welcome.
> Double-entry is all fun and games until trying to compute a balance-sheet!
> The above, not an accountant yadda yadda.
>
> On 17/08/18 00:27, David T. wrote:
>
> Hi,
>
> I admit that I haven’t been following the details of thsi thread that 
> closely, but it would seem to me that if a user has selected price source 
> “Latest,” then the report will of necessity include an Unrealized Gains line 
> in order to balance, as John said. I agree with his suggestion that 
> Unrealized Gains might not belong in a Balance Sheet report, but I note that 
> as a personal user of GnuCash, I am rather interested in the current value of 
> my empire, ephemeral though it may be. I’m eager to see how rich I am Right 
> Now! Bwa Ha Ha Ha!
>
> Seriously, though, since “Balance Sheet” seems to be a commonly-used term in 
> accounting to refer to a particular general type of report and content (I 
> base this on the fact that Googling “Balance Sheet report definition” yields 
> numerous accounting websites with explanations of what a balance sheet is and 
> does), perhaps there could be a separately-identified and named report to 
> give the armchair trader the putative value of their holdings