Sure, it's 10 times bigger, but it actually implements arbitrary-precision
math, implements all of the dc commands except 1, and (this is probably the
biggest thing) implements dc strings properly, including being able to
*execute* them, conditionally and unconditionally.
I personally feel like
On 6 December 2018 22:38:45 CET, Gavin Howard wrote:
>On Thu, Dec 6, 2018 at 2:30 PM Michael Conrad
>wrote:
>>
>> On 12/6/2018 11:48 AM, Gavin Howard wrote:
>>
>> > you are going to have to make the bc not give good error messages
>and/or not check for errors as thoroughly (a massive chunk of
On Thu, Dec 6, 2018 at 2:30 PM Michael Conrad wrote:
>
> On 12/6/2018 11:48 AM, Gavin Howard wrote:
>
> > you are going to have to make the bc not give good error messages and/or
> > not check for errors as thoroughly (a massive chunk of the parser, which is
> > the largest portion, is
On 12/6/2018 11:48 AM, Gavin Howard wrote:
you are
going to have to make the bc not give good error messages and/or not
check for errors as thoroughly (a massive chunk of the parser, which
is the largest portion, is dedicated to error checking), reduce the
quality of the code, reduce the
On Thu, Dec 6, 2018 at 5:49 PM Gavin Howard wrote:
> To reduce the size significantly (Denys has reduced it some already,
> though in my mind, some of those changes are up in the air), you are
> going to have to make the bc not give good error messages and/or not
> check for errors as thoroughly
Hello,
I am the original bc author, so take my words with a grain of salt.
Of course, I will understand if busybox decides to write its own
implementation, I just wouldn't suggest it.
First of all, it is important to remember everything that must be in a
bc implementation:
1) Lexer
2) Parser
Hi,
Are you sure this is a good idea?
I was under the impression that it would be much more sane to write bc from
scratch given the extraordinary size of the proposed implementation.
Thanks,
On 5 December 2018 15:40:38 CET, Denys Vlasenko
wrote:
>commit:
