lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [lmi-commits] master e6009c1 5/5: Demote an assertion to a con


From: Greg Chicares
Subject: Re: [lmi] [lmi-commits] master e6009c1 5/5: Demote an assertion to a conditional
Date: Mon, 30 Jul 2018 15:29:11 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 2018-07-30 12:31, Vadim Zeitlin wrote:
> On Mon, 30 Jul 2018 07:23:16 -0400 (EDT) Greg Chicares <address@hidden> wrote:
> 
> GC> branch: master
> GC> commit e6009c1c7d01b51386a11c8ced4b6a75d79b3bfc
> GC> Author: Gregory W. Chicares <address@hidden>
> GC> Commit: Gregory W. Chicares <address@hidden>
> GC> 
> GC>     Demote an assertion to a conditional
> GC>     
> GC>     Replaced, in effect,
> GC>       assert(is_safe_to_execute_next_statement); foo();
> GC>     by
> GC>       if(is_safe_to_execute_next_statement) {foo();}
> GC>     
> GC>     The assertion has been observed to fail:
> GC>     
> GC>     https://lists.nongnu.org/archive/html/lmi/2018-07/msg00020.html
> GC>     | Assertion '0 <= ci.col_width - column_margin()' failed.
> GC>     
> GC>     and the obvious workaround is to bypass the block where it fails, so
> GC>     it really should be a conditional: if there's no room for an elastic
> GC>     column, then is should be omitted, silently.
> 
>  I'm sorry but I don't understand at all the rationale for the last
> statement. Is it really a good idea to silently generate wrong reports?
> Because I don't see how could silently producing a report not showing the
> names at all (I use names column as an example as it's is the only elastic
> columns we have currently) could be considered a good outcome?

Really good question. There's a general and a particular aspect.

In general, elastic columns occupy any (horizontal) space not needed
by inelastic columns. Let X represent the leftover space available for
elastic columns. Before this change:
  if X == 0 em then an assertion failed
  if X == 1 em then elastic columns are in effect omitted: only a margin
    is printed, and that's blank (eagle-eyed end users might notice that
    the blank 1-em area is surrounded by vertical ruling, but that might
    just appear to be heavy ruling--and most users won't even notice it)
  if X == 2 em then much the same thing happens: left and right margins
    are shown, but any actual content is clipped
  if X == 3 em then only one em of actual content is shown, which looks
    rather strange
The effect of this change is only to treat the first case the same as
the second and third. As before, if X < 0, then there wasn't enough
space for all inelastic columns, so an error message was given before
this code could be reached.

If we want to treat that as a problem, then we need to specify a minimum
width for elastic columns. For a personal name, perhaps anything less
than five em might be considered inadequate. However, only one column is
elastic in practice--the group-quote "Participant"--and AFAIK the design
of group quotes is such that there's always room for a dozen or two
characters in that column.

What we must avoid at all costs is a report that misrepresents what's
being sold. Giving you an accurate quote, with a premium that's correct
for the birthdate shown, with all required footnotes, cannot be a
misrepresentation even if it refers to you as "V" or "Z" or " ": that
might be silly, but it meets all regulatory requirements, so it's not
actually wrong in any legal sense. In fact, it's not uncommon to omit
all personal names, for privacy reasons: anonymous illustrations and
premium quotes are valid.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]