On Wed, Apr 17, 2019 at 6:38 PM Eli Schwartz via aur-general <aur-general@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-lib... 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