Decimal string to floating point conversion with correct half-to-even rounding

[H. S. Teoh]

On Tue, Jul 07, 2020 at 03:08:33PM +0000, Adam D. Ruppe via Digitalmars-d-announce wrote:
> On Tuesday, 7 July 2020 at 13:00:04 UTC, Steven Schveighoffer wrote:
> > Doing that these days would be silly. You can depend on a specific
> > version of a repository without problems.
> 
> I always have problems when trying to do that. git submodules bring
> pretty consistent pain in my experience.

git submodules serves a very specific niche; using it for anything
outside of that most definitely brings in gigantic pain.

That very specific niche is this: there's an external repository R that
contains code you'd like to use, BUT that you'll never edit (unless you
wish to push it back upstream).  You check it out in some subdirectory
of your source tree, say ./someRepo/*, and add it as a submodule. This
adds the SHA hash of the exact revision of the code in .gitmodules,
meaning that you depend on that exact version of R.  Occasionally, you
want to update R to some (presumably newer) version, so you do a `git
submodule foreach git pull ...` to pull the revision you want. This
updates .gitmodules to point to the new revision.

What you do *not* want to do is to edit the contents of the submodule,
because that will start creating diverging branches in the submodule,
which generally leads to a gigantic mess, like when somebody checks out
your code and tries to fetch submodules, they may not find the revision
being referred to (you haven't pushed the commits upstream, upstream
rejected it, etc).

Basically, git submodules let you refer to a specific commit in a
specific repo.  Don't expect it to do anything else for you, including
housekeeping that you *thought* it ought to do.

I've used git submodules quite happily for my own projects, where I want
to pull in code from another project but don't want to have to worry
about version compatibility and all of that dependency hell. Basically
you update a submodule to a new revision when and only when *you*
initiate it, and don't commit the submodule update until you've verified
that the new revision didn't break your code.  The submodule SHA ensures
that you'll get the exact version of the submodule that you last checked
in, not some random new version or some corrupted/edited version that
some unreliable network source have given you instead.


> But it probably isn't so bad if the submodule rarely changes.

Yeah, you do *not* want to use submodules if you're interested in
keeping up with the latest bleeding edge from upstream.  Well I mean you
*can*, but just don't expect it to automate anything for you. The onus
is upon you to test everything with the new revision before committing
it.

Oh, and another point: it's *probably* a good idea to git clone (i.e.
fork in github parlance) the submodule into a local copy, so that if the
network source vanishes into the ether, you aren't left with
uncompilable code.  Don't laugh, the way modern software development is
going, I will be SO not surprised when one day some obscure project that
everyone implicitly depends on suddenly vanishes into the ether and the
rest of the world collapses because everybody and his neighbour's dog
blindly assumed that "if it's on the network, it'll be there forever".


> Just for 100% control anyway nothing beats copy/paste. Then there's
> zero difference between you writing it yourself.

I highly recommend this approach when your dependency is small. Or if
you want to ensure no external dependencies.  There have been far, FAR
too many times IME in the past few years where I encountered a project
that was no longer compilable because one or more dependencies have
vanished into the ether.  Or the code no longer compiles with the
dependency because the latest version of said dependency has migrated to
a brand new codebase, and the old revision that the project depended on
is not compatible with the new version.  Or said project itself has
moved on and happily broke functionality I depended on.

These days, my policy is: download the danged source code for the
specific version of the specific project I'm depending on, AND download
the danged source code of the danged dependencies of that project, etc.,
and keep a local copy of the whole recursive dependency tree so that I
can ensure I can always build that specific version of that specific
project with that specific functionality that I'm using.  Trying to keep
up with projects that gratuitously break stuff, or abandoned projects
whose dependencies are no longer compatible with it, etc., is a hell I
wish to have no part in.  I've lost faith in the emperor's code reuse
clothes; copy-n-paste is what gives the real guarantees.

And I'm not alone in this -- I've noticed that quite a few open source
projects are distributing a copy of the sources of the librar{y,ies}
they depend on in their own source tree as a fallback, in case the
target system's version of that library doesn't exist, or is hard to
find, or is somehow incompatible with the version they're expecting to
use.


> I kinda wish the D upstream were more willing to do that. My view is
> it shouldn't be on independent developers to add stuff to Phobos, for
> example, instead the Phobos team should just be copying and testing
> modules they are interested in on their own.

+1, this guarantees Phobos doesn't (directly) have dependencies outside
of itself.  As a standard library, that's a no-no (cf. the repeated
problems we had over the years with libcurl, zlib, etc.). Just keep a
copy of the source code in some dedicated subdirectory that can be
easily replaced when we need to upgrade to a new version -- that's what
open source is for!!!


T

-- 
People tell me I'm stubborn, but I refuse to accept it!