GNU bug report logs - #31999
[PATCH 1/7] gnu: Add volume-key.

Previous Next

Package: guix-patches;

Reported by: Pierre Neidhardt <ambrevar <at> gmail.com>

Date: Thu, 28 Jun 2018 21:33:02 UTC

Severity: normal

Tags: patch

Done: Pierre Neidhardt <ambrevar <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Marius Bakke <mbakke <at> fastmail.com>
To: Pierre Neidhardt <ambrevar <at> gmail.com>, 31999 <at> debbugs.gnu.org
Subject: [bug#31999] [PATCH 3/7] gnu: Add libbytesize.
Date: Thu, 12 Jul 2018 22:20:43 +0200
[Message part 1 (text/plain, inline)]
Pierre Neidhardt <ambrevar <at> gmail.com> writes:

> * gnu/package/c.scm (libbytesize): New variable.

[...]

> +    (description
> +     "The goal of this project is to provide a tiny library that would
> +facilitate the common operations with sizes in bytes.  Many projects need to
> +work with sizes in bytes (be it sizes of storage space, memory...) and all of
> +them need to deal with the same issues like:
> +
> +@itemize
> +@item How to get a human-readable string for the given size?
> +@item How to store the given size so that no significant information is lost?
> +@item If we store the size in bytes, what if the given size gets over the
> +MAXUINT64 value?
> +@item How to interpret sizes entered by users according to their locale and
> +typing conventions?
> +@item How to deal with the decimal/binary units (MB vs. MiB) ambiguity?
> +@end itemize
> +
> +Some projects have all the above questions/concerns addressed well, some have
> +them addressed partially some simply don't care.  However, having (partial)
> +solutions implemented in multiple places every time with a different set of
> +bugs, differences in behaviour and this or that missing is a waste of time and
> +effort.  We need a generally usable solution that could be used by every
> +project that needs to deal with sizes in bytes.
> +
> +Since the goal is to provide a solution as much generally usable as possible
> +the implementation has to be small, fast and written in a language that can be
> +easily interfaced from other languages.  The current obvious choice is the C
> +language with thin bindings for other languages.")

Woah.  I wonder if we should shorten this a bit (for once!).  It's a lot
to digest for the curious user.  Can you try to provide a summary?  :-)
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 6 years and 290 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.