Re: [GNC-dev] Debug build in production?
On Sat, May 05, 2018 at 07:25:49AM -0400, John Ralls wrote: > Sounds like some projects are using asserts in places that more graceful > runtime checks would be more appropriate... Indeed. Also memory-access-checking libraries and the like; and in other ways that I can't recall offhand, explicitly hammering the code harder in debug builds to try to provoke bugs into showing themselves. - Eric ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Debug build in production?
On Fri, May 04, 2018 at 10:37:22PM +0200, Geert Janssens wrote: > A debug build will tell the compiler to avoid several optimizations. > [thus bigger and slower] Cool; that I'm perfectly OK with. I guess what I mostly had in mind was warnings I've seen in some projects that debug builds are less stable than release builds (due to extra error-checking code, I believe). Sounds like GnuCash doesn't do that, though. Thanks, - Eric ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Debug build in production?
Is there any particular reason to avoid using a CMAKE_BUILD_TYPE=Debug build of GnuCash in production? The reason *to* do that, of course, is to have the debugging symbols available in case of need. (This is independent of the choice of which git commit to build *from*; those pros-and-cons I'm well familiar with...) This is on Linux, in case that's relevant. Thanks much, - Eric ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Register + Unicode (was Re: emojis everywhere...)
On Fri, Apr 27, 2018 at 02:43:25PM -0400, Eric Siegerman wrote: > On Fri, Apr 27, 2018 at 03:24:35PM +0200, Geert Janssens wrote: > > It think it's worth reporting as a bug, though of low priority. > > Done: https://[deleted] The emojis in my bug report screwed up my previous attempt to submit this. I've closed that one and resubmitted it (sans emojis) as: https://bugzilla.gnome.org/show_bug.cgi?id=795614 - Eric ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Register + Unicode (was Re: emojis everywhere...)
On Fri, Apr 27, 2018 at 03:24:35PM +0200, Geert Janssens wrote: > It think it's worth reporting as a bug, though of low priority. Done: https://bugzilla.gnome.org/show_bug.cgi?id=795613 Thanks, - Eric ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Bye-bye Unstable
On Wed, Apr 18, 2018 at 10:29:23AM +0200, Geert Janssens wrote: > In the 2.7 > development cycle we experimented with an extra "unstable" *branch* to do the > unstable releases from. Which is pretty standard practice -- except for the name. Intuitively, I'd expect a branch called "unstable" to be *less* stable than master, not more so. Perhaps this caused some of the confusion that has been expressed both here and in the similar thread over in -user. I imagine the branch got its name as the source of the "unstable" release series, but still... > For future unstable releases we will probably just do > them from the master branch instead and forget an unstable branch ever > existed. Makes sense. Since (as it appeared to me as a lurker) the whole team switched over to stabilization mode, with dev work toward 4.x on hold for the duration, the additional branch likely didn't add much value. But should you ever change your minds, may I suggest calling the third branch "stabilization" -- or a shorter quasi-synonym, e.g. "beta". - Eric ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Register + Unicode (was Re: emojis everywhere...)
On Sat, Apr 07, 2018 at 08:20:35PM -0700, John Ralls wrote: > Depends on what you see as the bug. The bug is the inconsistency. I have opinions, for what they're worth, on how it should behave: - Reverting to the old value is better than clobbering to zero; if it can't change the field to what I asked for (because what I asked for was bogus) it shouldn't change it at all - Leaving the bogus input in Debit, and only cleaning it up on exit from Credit, is kind of ugly and could be confusing But far outweighing those is that all variations should behave the *same* way. None of the current behaviours give incorrect results in the end; it's just a usability thing -- which is why I called my complaint nitpicky. > I suppose there should be a message box when you hit instead of just > leaving you focused on the erroneous field with no clue that GnuCash is > declining to process your bogus input. What I personally would prefer instead of a dialog that one has to dismiss is a simple beep, like vi used to do on error, when you were using an actual serial terminal. But I pretty much expect to be outvoted on that... > Another problem that you didn’t explore is that GnuCash may recognize only > code points 0x2b-0x39 as numbers, delimiters, and operators, so users trying > to use localized number representations may fail. That would be a libc > failure rather than a GnuCash one, but I don’t have a lot of confidence in > libc’s localization mechanisms. You're right; I can see that being a problem. If it's libc's fault, though, it's likely to be platform-dependent, isn't it? That adds another dimension to the difficulty of trying to fix it in application code. > Perhaps fortunately I think most of the world is resigned to using European > numbers and symbols for representing money. Semi-resigned. I have some souvenir Nepali and UAE currency left over from a trip, and each country's bills contain both their own and Western[*] numbers, and their own and English text. I suspect you're right, though, that people are rather more resigned to doing things our way when computers are involved. [*] We call our numerals "Arabic", but most(?) of the Arab world actually uses different ones -- somewhat related to ours, but not closely enough to be very legible to my Anglo eyes. I believe ours are descended from a regional variant that was, and is, used only in parts of North Africa -- and thus in Moorish Spain, from where the rest of Europe got them. - Eric ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Register + Unicode (was Re: emojis everywhere...)
On Sat, Apr 07, 2018 at 07:31:38AM -0700, John Ralls wrote:
> > On Apr 6, 2018, at 11:11 PM, Wm via gnucash-devel
> > wrote:
> > gnc 3.0 allows emojis in places I think inappropriate
In poking at this, I've discovered some inconsistency in the
register's handling of (what I believe to be) invalid input.
This isn't new; it's the same in GNC 3.0 and 2.6.18.
In a text field (I've tested a txn's description and a split's
memo), both U+e9 ("é", e-acute) and U+1f600 ("😀", grinning-face
emoji) are accepted, displayed, and stored correctly as UTF-8 by
the XML back end. OK so far.
But in a currency-amount field (I've tested specifically a
split's Debit field, and all of the following cases are described
in those terms):
I type Result
== ==
abcd Each of these behaves like "0":
abcd - Debit becomes blank (ie. zero)
- Focus moves as appropriate for
a5 as above
5a Nothing happens. The Debit field
containing "5a" remains focused, even
after repeated s
5a 1. I get an error dialog: "An error
occurred while processing 5a."
2. When I dismiss the dialog, GNC focuses
the Credit field, leaving the
"5a" in the Debit field (the former
is somewhat surprising; the latter
very much so!)
3. When I then or out of
the Credit field, Debit returns to its
previous value
- N.B.: This is unlike "abcd",
which sets Debit to zero
unconditionally
An e-acute it treated like "5a" above (even if I don't type any
digits):
abécdAs for "5a" (except that the cursor
jumps to just before the offending "é")
abécd As for "5a"
If I repeat the previous two cases with the grinning-face emoji
(U+1f600) in place of the e-acute, the emoji is ignored
completely -- it doesn't display, and exiting the field behaves
as if I'd typed "abcd", i.e. as if I'd typed nothing at all, i.e.
it gets forced to zero.
All of those are invalid inputs for Debit, I presume. So it's
not a problem that they're all rejected -- only that they're
rejected differently.
Testing context:
- Ubuntu 16.04
- GNC 3.0 and GNC 2.6.18 (same results with both)
- XFCE (not sure if that matters)
- Locale-related bits of GNC's environment:
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_COLLATE=C
- Autosplit Ledger mode in effect for the account in question
Nitpicky details, to be sure. Is any of it worth filing a bug
about?
- Eric
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: emojis everywhere, seeking understanding / clarity / opinion
On Sat, Apr 07, 2018 at 07:31:38AM -0700, John Ralls wrote: > > On Apr 6, 2018, at 11:11 PM, Wm via gnucash-devel > > wrote: > > gnc 3.0 allows emojis in places I think inappropriate > > account names > > account codes > > securities > Filtering for meaning is Way Too Hard. It would be too hard just in English, > every additional localization squares it. > > Besides, if a user wants to have an emoji as (part of) an account name, isn’t > that the user’s business? It’s all Unicode, so from a text processing > standpoint no different from Chinese. What @John says makes sense to me. One can conceive of someone coming up with an "SFW" subset of Unicode for a given locale (assuming there's tooling to support Unicode subsets), and of GNC honouring that subset if requested -- but devising it doesn't seem like GNC's job. However... > > and offers them in places it shouldn't > > e.g. > > dates > > numbers Could you explain "offers" (as opposed to "allows")? I've been looking, and don't see them coming up in dropdown lists or the like. And when I try to type one directly into a numeric field (e.g. Debit), it's ignored completely. (That's in the register, on Linux, though; Windows or Mac OS might be different, as might different areas of GNC.) If emojis were being offered and/or accepted in a numeric field, though, shouldn't they be rejected as syntactically invalid? In this case, what they are is beside the point; it's what they *aren't*, i.e. numeric, that matters. - Eric ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: BUILDING_FROM_VCS
On Sat, Mar 10, 2018 at 11:36:13PM +0100, Geert Janssens wrote: > Make dist is called all the time by developers to test the creation of a dist > tarball, so the info would get updated more frequently then intended. Or it > would require manual intervention, which brings us back at square one. I think I was unclear. What I was trying to say was that any changes to (or exclusions of) the sentinel file should occur *only* in the distribution tarball (or whatever); the file in the source tree shouldn't be modified by "make dist".[*] (That might be non-trivial for an in-source-tree build, but you recommend against those anyway.) [*] That's why the source-tree version shouldn't say "I'm from git commit 123abc", but should statically say merely "I'm from git". > Unfortunately it does matter. Github allows you to download any commit as a > tarball. That tarball would also include the sentinel... This, however, does seem to be a showstopper for the idea :-( - Eric ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: BUILDING_FROM_VCS
On Sat, Mar 10, 2018 at 09:00:29AM -0800, John Ralls wrote:
> One possible solution would be to test the value of `git remote -v 2>
> /dev/null | grep "origin.*(fetch)"`. If it’s either code or the Github mirror
> then we set the version from `git describe`, otherwise it’s the ${VERSION} as
> set in CMakeLists.txt.
This seems fragile. (1) If someone's building from a clone of a clone, it will
fail. (2) The remote might not be called "origin" (e.g. I typically use
"upstream").
Here's an idea: add a sentinel file to the git repo, but exclude it from the
dist tarballs etc. If the file exists in the source tree, you're building from
the official git repo or a (possibly indirect) clone of same. If it doesn't
exist, you're building from something else (and I don't think it matters what
variety of something-else -- tarball, tarball-checked-into-git, etc.) The
sentinel's content is irrelevant (unless for extra certainty you want the
git-repo check to verify it); it's the file's presence or absence that matters.
This has the advantage of being VCS-agnostic, since it only looks at the
working tree.
Or the sentinel could always exist, but its contents could provide the needed
info. E.g. it's in the source tree with (hard-coded and git-committed) contents
that say basically "I'm from git". But the dist build puts into the tarball a
variant that says, "My ultimate source is {release 2.7.5|official git commit
123abc|}, but I'm not directly from there". Not in
those exact words, obviously.
What makes gnc-version.h and gnc-vcs-info.h unsuitable is that they're
regenerated on a normal "make all" build, if necessary. The key would be that
the sentinel I'm suggesting is only generated at "make dist" time:
- if you're building from an official repo (or clone), the file never changes
- if you're building from a tarball, the file still never changes
It only changes at the transition between those two states, i.e. "make dist".
> ChangeLog is a bit harder [...] or maybe it should be simply dropped.
That would be unfortunate. Even though the info is available elsewhere, it's
good to have it encapsulated with the rest of the distribution.
- Eric
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: An improvement on the "search list archive" 404's
On Fri, Nov 03, 2017 at 10:55:05AM -0400, Derek Atkins wrote: > The attachment, while claiming to be an HTML document, just came across > as a text document? Looks like the mailing list sanitized it -- the copy in my Sent folder has the HTML, but the copy I got back has plain text and this header: X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Not surprising in hindsight. I'll try sending it to you privately. - Eric ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
An improvement on the "search list archive" 404's
[Moved from gnucash-user to gnucash-devel] On Fri, Oct 06, 2017 at 11:30:17AM -0400, Derek Atkins wrote: > Eric Siegerman writes: > > I get that there are no immediate plans to (re)implement search > > locally, and that's cool; but more helpful than just returning a > > 404 error would be to put a static page at that URL that explains > > what to do instead. > > Send me an HTML file that looks good and I'll put it in place. Rather belatedly, attached is a version for you to consider/critique. Things to note: - I was going to apply the gnucash.org styling, but couldn't find styles to suit what I wanted. So instead I added a bit of inline placeholder CSS, just to not be using and the like. Look for the "fixme-xyz" class names. - If (as expected) someone arrives at this page from the "search Archives" button on a list's Mailman info page, there's JavaScript that will modify the search-engine HREFs to only search the list in question. (I don't know how you feel about JavaScript in general, but I noticed that there is a little of it on the site. If you'd rather it go away, that's fine; I knew I was writing it "on spec".) - Even without JavaScript, the static HREFs arrange to search only the GNC lists -- but all of them in that case. - For Google, that consists of adding a "q=site:whatever" query parameter, which Google then stuffs into the search-form field. ISSUE: They don't put a space after it, so users will have to type one. It's a minor nit, but it is an annoyance. If anyone knows how to convince google.com to add the trailing space, so much the better! - I replaced Yahoo with Nabble: - Yahoo doesn't seem to be indexing the GNC lists any more. I tried searching for a couple of phrases chosen out of random list posts, and Yahoo couldn't find anything - A lot of folks here seem to use Nabble, so that served as a recommendation for what to offer instead If you want changes, just let me know. (Or feel free to make them yourself; I'm good either way.) I presume that in either case, once it's ready to go, you'll have to do some slicing and dicing to put its head and body pieces into whatever CMS you're using. - Eric No local search Currently, there is no on-site mechanism to search the GnuCash mailing lists. Instead, you can search the lists using one of these external sites: * [1]Google * [2]Nabble These links prepopulate the search form with the list you want to search. If for some reason that didn't happen (e.g. if JavaScript is disabled): For Google In the search bar, type site:lists.gnucash.org/pipermail/list-name to search a specific list, or site:lists.gnucash.org to search them all For Nabble By default, all of the lists will be searched. The individual lists can be found at the Sub-forums link References 1. https://www.google.ca/?q=site:lists.gnucash.org 2. http://gnucash.1415818.n4.nabble.com/ ___ 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)
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
Separate-build-directory "make check" fails in po/
Versions: - GnuCash 2.6.11 (and many older versions -- basically as far back as I can build with my current toolchain) - Ubuntu 12.04 - Ubuntu's intltool 0.50.2-2 package I'm getting a "make check" failure when I try to build GnuCash in a separate build directory -- but only if the build directory is within the source tree (e.g. $HOME/src/gnucash/build). It dies in po/, complaining about build-directory files that aren't listed in POTFILES.skip. (If the build directory is *not* under the source tree (e.g. $HOME/src/gnucash/../build, "make check" passes.) N.B.: It's only "make check" that fails; "make" and "make install" are fine. The underlying issue seems to be an intltool bug: https://bugs.launchpad.net/intltool/+bug/1117944 intltool doesn't know to ignore the source(ish) files that get created in the build tree, even if the corresponding source-tree file is listed in POTFILES.skip. Is this a known problem? It's mighty suspicious that it (a) is triggered by the very practice that's recommended on the wiki, (b) is something that the selftests catch, but even so, (c) seems to have been around for a very long time. Makes me wonder whether I'm being especially dumb... I was going to update the wiki to recommend *against* this specific setup (instead of *for* it :-/ ), but wanted to check with others first what's known about the situation. Thanks, - Eric ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
