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: 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. :
> 
> 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
>  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 
>> >:
>> 
>> 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: Intended behavior of automatic decimal point (bug 120940)

[David T. via gnucash-devel]

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 
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 
:
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: GNUCash as a maintenance project?

[John Ralls]

> On Jul 26, 2017, at 8:13 AM, Keith Gallagher  wrote:
> 
> hello.
> 
> Keith Gallagher here, software engineering faculty at Florida Inst. of 
> Technology. This coming term I am teaching an advanced course in software 
> maintenance and evolution; upper division undergraduates  and graduate 
> students are enrolled. (10-12 at this point)
> 
> I'm looking for a course project, something I can set the whole class on to 
> work on as a team.   I am looking for something that is mature, with lots of 
> releases,   has a large and ongoing user community,  and, of course, has lots 
> of  "issues" that need to be addressed!  I have contacted Brad Kuhn, and old 
> student of mine,  and he suggested GNUCash as a possibility.
> 
> All of the students in the class are familiar with open source rubrics and 
> guidelines and use of  appropriate repositories.
> 
> But before I send a collection of people  to meddle in the work, I would like 
> to have the approval of the community,  and any guidelines or suggestions  
> (or help) that you might have  or wish to offer.  For instance: should we do 
> this is a group? Should we do this is a collection of individuals? Etc? Etc.?
> The caveat is that once the term is over, it is highly unlikely that any of 
> the individuals involved will continue to contribute.  But I can guarantee,  
> yes guarantee,  that we won't leave it worse than we found it ;-)  and that 
> every issue  that is tackled will be = thoroughly=  vetted and approved 
> before  a merge is requested.
> 
> thanks for listening.

Dr. Gallagher,

This sounds like an interesting project. There are a couple of obstacles to 
work out before you decide to engage with us:

* GnuCash use GObject, Gnome’s attempt to support object-oriented programming 
in pure C, and Guile, GNU’s scheme-based extension language. Both are used 
extensively (and not always correctly) in GnuCash and while we have a long term 
goal of replacing the former with modern C++ and reducing the use of the latter 
they are very much intertwined throughout our present code base. Neither is 
particularly easy to learn.

* The core development team is very small and we’re currently trying to get a 
major release ready. We won’t have much time to support your class. We could 
easily be overwhelmed by pull requests from 12 students working 6 hours a week. 
Your students would undoubtedly find the resulting delays frustrating.

Aside from that we could certainly use the help and we do enjoy working with 
capable students.

This discussion is more appropriate on the developer list, 
gnucash-de...@lists.gnucash.org . I’ve 
added it to the CC, please subscribe and reply there.

Regards,
John Ralls

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

Patches versus Pull Requests

[David T. via gnucash-devel]

Hello,

In going over some of the wiki information, I ran into a section that goes into 
some detail about preparing patches for submission. 

While this is, no doubt, still a valid way of submitting changes, is this: a) 
how the project prefers such changes to be submitted, and b) something that 
anyone is actively using?

If the answers are “no” and “not many,” then perhaps this information could be 
removed from the wiki?

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

Re: Patches versus Pull Requests

[John Ralls]

> On Jul 27, 2017, at 9:45 AM, David T. via gnucash-devel 
>  wrote:
> 
> Hello,
> 
> In going over some of the wiki information, I ran into a section that goes 
> into some detail about preparing patches for submission. 
> 
> While this is, no doubt, still a valid way of submitting changes, is this: a) 
> how the project prefers such changes to be submitted, and b) something that 
> anyone is actively using?
> 
> If the answers are “no” and “not many,” then perhaps this information could 
> be removed from the wiki?

It's still valid and although we do see more pull requests than patches on bugs 
we still need the procedure available as long as we continue to use Gnome's 
bugzilla.

Besides if one is doing a drive-by patch for a bug it's a lot easier to just 
run git format-patch than to fork gnucash in Github and create a PR.

Regards,
John Ralls

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

Fwd: GnuCash page Git has been changed by Sunfish62

[Frank H. Ellenberger]

David,

because it is not the first time you are reverting a bunch of my
commits, I want to ask you for your reason:

a) was it by accident - using some unsynchronized offline editor, or
b) you disliked my changes, then you should explain it, or
c) you dislike me or
d) what else?

Regards
Frank

 Weitergeleitete Nachricht 
Betreff: GnuCash page Git has been changed by Sunfish62
Datum: Thu, 27 Jul 2017 16:38:19 +
Von: GnuCash 
Antwort an: bureauc...@gnucash.org
An: Fell 

Dear Fell,

The GnuCash page Git has been changed on 27 July 2017 by Sunfish62, see
https://wiki.gnucash.org/wiki/Git for the current revision.
See
https://wiki.gnucash.org/wiki/index.php?title=Git=next=12840
to view this change.

See https://wiki.gnucash.org/wiki/index.php?title=Git=0=12840
for all changes since your last visit.

Editor's summary: /* Improve sequence of text */
:
___
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)

[Eric Siegerman]

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.

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

Re: Patches versus Pull Requests

[Adonay Felipe Nogueira]

+1, it's a lot easier to just format-patch and send it to some place
related to the project than using GitHub. :)
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Wiki collissions; was: GnuCash page Git has been changed by Sunfish62

[David T. via gnucash-devel]

> On Jul 28, 2017, at 10:24 AM, Frank H. Ellenberger 
>  wrote:
> 
> Hi David,
> Am 28.07.2017 um 05:45 schrieb David T.:
>> Frank,
>> 
>> I beg to differ about reverting your edits. I have never knowingly reverted 
>> any of your edits. (I have had you revert mine, however) 
> 
> ,,, after you replaced wiki:Glossary by a link to Guide/Glossary which
> had only half of its content. ;-) And I reinserted your complements
> after the revert.

My point is that *I* haven’t reverted changes; *you* have. I don’t plan on 
rehashing our differences on the content of  that page.

> My suggestion for Wiki collission:
> 
> When you get the collission meassage, copy your changeset to the talk
> page of the other user and ask him to apply it.
> 
> If you agree, this yould be written to Wiki_Tips or better a new page
> Wiki_Policy.
> 

As I stated before, I was unaware of any collisions in the first place; had I 
been aware of them, I would have waited for you to complete your edits before 
attempting my own. Thus, I don’t see a need for a policy on this—although I 
would welcome a more general discussion about wiki policy, since there are 
definitely differing ideas on what should be in the wiki, how that information 
should be maintained over time, and how it should coordinate with other forms 
of documentation.

David

>> 
>> David
> 
> Frank

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

Wiki collissions; was: GnuCash page Git has been changed by Sunfish62

[Frank H. Ellenberger]

Hi David,
Am 28.07.2017 um 05:45 schrieb David T.:
> Frank,
> 
> I beg to differ about reverting your edits. I have never knowingly reverted 
> any of your edits. (I have had you revert mine, however) 

,,, after you replaced wiki:Glossary by a link to Guide/Glossary which
had only half of its content. ;-) And I reinserted your complements
after the revert.

> It is true that I have changed things you’ve written, to improve their 
> English grammar and readability. I wouldn’t believe that such changes would 
> require any written justifications, beyond the general change name “Editing 
> to improve readability” which is what I have been doing. If you need me to 
> explain the changes to you, point me to one, and I will gladly explain my 
> choices.

In general I appreciate you reviews.

> In this particular case, I received a notice that the Git page on the wiki 
> had been changed by your addition of the sentence explaining the github 
> repository. I looked at that (single) change on the wiki, and thought the 
> sentence belonged in a different spot. Note that I didn’t revert that edit; I 
> moved the text. Further examination of the text turned up areas that I 
> thought needed improvement with the text flow. So I began to edit the content 
> to reflect my ideas. 
> 
> I was not aware that:
> 1) you were still in process of changing the page, 
> 2) the wiki would alert me of your first edit, but none of the following 
> ones, or
> 3) the earlier version would not indicate that there were later edits to 
> consider.
> 
> As a consequence, I edited the earlier form of the page, rather than your 
> last version. I apologize for that. I will be more careful in the future.

It seems, we both dislike the current state of that page after a few
years of uncontrolled grows.

Probably we should split it in something like
How to use Git
How to use Github
How to submit improvements
That might need more discussion.


My suggestion for Wiki collission:

When you get the collission meassage, copy your changeset to the talk
page of the other user and ask him to apply it.

If you agree, this yould be written to Wiki_Tips or better a new page
Wiki_Policy.

> 
> David

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

[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

Re: GnuCash page Git has been changed by Sunfish62

[David T. via gnucash-devel]

Frank,

I beg to differ about reverting your edits. I have never knowingly reverted any 
of your edits. (I have had you revert mine, however) 

It is true that I have changed things you’ve written, to improve their English 
grammar and readability. I wouldn’t believe that such changes would require any 
written justifications, beyond the general change name “Editing to improve 
readability” which is what I have been doing. If you need me to explain the 
changes to you, point me to one, and I will gladly explain my choices.

In this particular case, I received a notice that the Git page on the wiki had 
been changed by your addition of the sentence explaining the github repository. 
I looked at that (single) change on the wiki, and thought the sentence belonged 
in a different spot. Note that I didn’t revert that edit; I moved the text. 
Further examination of the text turned up areas that I thought needed 
improvement with the text flow. So I began to edit the content to reflect my 
ideas. 

I was not aware that:
1) you were still in process of changing the page, 
2) the wiki would alert me of your first edit, but none of the following ones, 
or
3) the earlier version would not indicate that there were later edits to 
consider.

As a consequence, I edited the earlier form of the page, rather than your last 
version. I apologize for that. I will be more careful in the future.

David

> On Jul 28, 2017, at 2:29 AM, Frank H. Ellenberger 
>  wrote:
> 
> David,
> 
> because it is not the first time you are reverting a bunch of my
> commits, I want to ask you for your reason:
> 
> a) was it by accident - using some unsynchronized offline editor, or
> b) you disliked my changes, then you should explain it, or
> c) you dislike me or
> d) what else?
> 
> Regards
> Frank
> 
>  Weitergeleitete Nachricht 
> Betreff: GnuCash page Git has been changed by Sunfish62
> Datum: Thu, 27 Jul 2017 16:38:19 +
> Von: GnuCash 
> Antwort an: bureauc...@gnucash.org
> An: Fell 
> 
> Dear Fell,
> 
> The GnuCash page Git has been changed on 27 July 2017 by Sunfish62, see
> https://wiki.gnucash.org/wiki/Git for the current revision.
> See
> https://wiki.gnucash.org/wiki/index.php?title=Git=next=12840
> to view this change.
> 
> See https://wiki.gnucash.org/wiki/index.php?title=Git=0=12840
> for all changes since your last visit.
> 
> Editor's summary: /* Improve sequence of text */
> :

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

[Sumit Bhardwaj]

Based on all this, I propose we remove auto-decimal feature in v2.8.

Meanwhile, I will look for another bug to fix. Feel free to point me to a
bug that could use some attention.

Thanks,
Sumit

On Thu, Jul 27, 2017 at 8:24 PM, John Ralls  wrote:

>
>
> > 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: Patches versus Pull Requests

[David T. via gnucash-devel]

Thanks John.

I will look at ways to rewrite these sections to reflect current practices and 
preferences. It probably will mostly entail switching the sequence of 
information (putting pull requests first), and then offloading the details of 
the patch process into a separate page for those still wishing to find that.

David

> On Jul 27, 2017, at 10:28 PM, John Ralls  wrote:
> 
> 
>> On Jul 27, 2017, at 9:45 AM, David T. via gnucash-devel 
>>  wrote:
>> 
>> Hello,
>> 
>> In going over some of the wiki information, I ran into a section that goes 
>> into some detail about preparing patches for submission. 
>> 
>> While this is, no doubt, still a valid way of submitting changes, is this: 
>> a) how the project prefers such changes to be submitted, and b) something 
>> that anyone is actively using?
>> 
>> If the answers are “no” and “not many,” then perhaps this information could 
>> be removed from the wiki?
> 
> It's still valid and although we do see more pull requests than patches on 
> bugs we still need the procedure available as long as we continue to use 
> Gnome's bugzilla.
> 
> Besides if one is doing a drive-by patch for a bug it's a lot easier to just 
> run git format-patch than to fork gnucash in Github and create a PR.
> 
> Regards,
> John Ralls
> 

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