[aur-general] New bc

[Yzena Tech]

On Wed, Apr 17, 2019 at 6:38 PM Eli Schwartz via aur-general
<aur-general at archlinux.org> wrote:
>
> On 4/17/19 7:36 PM, Yzena Tech via aur-general wrote:
> > Hello,
> >
> > I am the author of a new implementation of POSIX bc. (
> > https://github.com/gavinhoward/bc) It has all GNU extensions, so it can be
> > used to build the Linux kernel. In fact, it can be a drop-in replacement
> > for the GNU bc.
> >
> > While I believe that my bc is robust enough to be used as the default bc on
> > Arch, I am under no illusion that that will happen right away, if at all.
> > Instead, I have made a PKGBUILD (attached) for my bc as an alternative. It
> > installs alongside the GNU bc without problem, since it is renamed as
> > "bc-gh".
> >
> > This also includes a dc under "dc-gh".
> >
> > Would there be interest in adding my bc as an Arch package?
>
> Well, any Dev/TU can add a new package if they are interested in it. I
> cannot speak for the bc maintainer about whether they want to switch
> implementations, though. They may just decide that the GNU edition is
> good enough that there's no compelling reason to switch.

Of course. I know that it is kind of a long shot, but hey, might as well see.

> Perhaps you could describe any differences between the two that would
> make a person inclined to choose one over the other? Is yours bigger or
> smaller? Does it run faster in average working conditions? Yours seems
> to not depend on readline, which GNU bc does -- is it feature-comparable
> on its own? (I guess this one would not need to be rebuilt in tandem
> with readline, then.)

My bc comes with its own builtin implementation of command-line history.

The differences between my bc and GNU:

* My bc is bigger, but it is smaller than GNU bc and dc combined, and
since it includes both in the binary, that is a more fair comparison.
* Despite being smaller (combined), it implements all GNU extensions
(including void functions and array references) plus a bunch of its
own.
* It is also more robust. Before I release, I make sure that it cannot
crash. It is thoroughly fuzzed and tested. This is, in fact, why I did
the project: I was curious as to exactly how perfect I could make a
piece of software, and I think it is pretty close.
* It actually implements the POSIX standard. (The GNU bc deviates in a
few subtle ways.)
* It still basically matches GNU in speed.
* It actually responds to locales and outputs error messages in the
specified locale (translations welcome!).
* It builds on a bare POSIX-compatible system, but that probably
doesn't matter much.
* It is licensed under the BSD-2-clause rather than the GPL.
* Extra extensions include:
  * It can turn scale, ibase, and obase into stacks (see
https://github.com/gavinhoward/bc/blob/master/manuals/bc.1.ronn#options,
--global-stacks option). What this means is that functions don't need
brittle code to make sure those three global variables are restored
before returning.
  * It accepts numbers in scientific or engineering notation.
  * It also will output numbers in scientific or engineering notation.
  * It has a more extensive math library (see
https://github.com/gavinhoward/bc/blob/master/manuals/bc.1.ronn#extended-library
for all extra functions). A lot of these functions are geared towards
programmers that need to know bit patterns of certain values.
  * It adds the following operators:
    $ (truncation)
    @ (truncation to a certain number of decimal places)
    >> (decimal right shift)
    << (decimal left shift)
    @= (places assignment)
    >>= (decimal right shift assignment)
    <<= (decimal left shift assignment)

> At any rate, it looks like a neat project, and I encourage you to submit
> it to the AUR in order to help people trial it out more conveniently.
> Your PKGBUILD looks pretty good, although I do have two comments:
>
> - Why does the url reference the GNU bc webpage? I would recommend using
>   your github repository as the url, unless you have set up another
>   webpage e.g. Github Pages or something.

Oh, whoops. That was an oversight.

> - The downloaded source filename will be bc-${pkgver}.tar.xz, which may
>   clash with downloaded sources for GNU bc, if someone has built both
>   and used a shared $SRCDEST. Therefore I would advise using a renamed
>   source like such:
>
> source=(${pkgname}-${pkgver}.tar.gz::https://github.com/gavinhoward/bc/releases/download/${pkgver}/bc-${pkgver}.tar.xz)

I was wondering if there was a way to do it...

I have attached a PKGBUILD with the two suggestions implemented.

> ...
>
> Aside: this is the same bc that is now providing the bc implementation
> in recent versions of busybox, isn't it? Nice work!

Yes, it is, thank you, though the busybox maintainer refuses to accept
me as the maintainer of the busybox bc since I want the bc to be
perfect. He prefers focusing on small executable size. As such, he
maintains the busybox bc, not me. I last gave him an update around
1.1.1, I believe. Busybox does not have the extra extensions.

> --
> Eli Schwartz
> Bug Wrangler and Trusted User

Gavin Howard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PKGBUILD
Type: application/octet-stream
Size: 857 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20190417/eb14ed99/attachment.obj>