WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: tce-size broken output caused by changes in dc CL syntax since BusyBox 1.30  (Read 6578 times)

Offline jazzbiker

  • Hero Member
  • *****
  • Posts: 934
Hi, Core people!

Bad news from BusyBox team - they decided to change dc applet command line syntax. They named this "much fuller version". This took place in BusyBox since 1.30 and in the latest TC11, which uses 1.31 I can't write
Code: [Select]
$dc 2 2 add p
and get
Code: [Select]
4

Happy user of the "fuller version" must write
Code: [Select]
$dc -e '2 2 + p'

By the way "add", "sub", "mul" and "div" keywords were thrown out, now we must use only +, -. * and / in string constants. How about * symbol in your commands ?

One of the direct consequencies is that "tce-size" utility ( called by tce ) now is showing rubbish, because it uses dc line calls for extension size arythmetics. Please, forgive my anger, but in order to have proper tce-size output data this script needs to be edited after so many years of excellent functioning.
Maybe there are other cases of dc applet use in TC system stuff. Probably all of them will fail too. (

Offline aw

  • Newbie
  • *
  • Posts: 45
That's a pretty big regression, as I'm sure other programs rely on 'dc'.

There seems to be a busybox option: FEATURE_BC_LONG_OPTIONS which can be enabled and might fix the problem.. see the config http://repo.tinycorelinux.net/11.x/x86_64/release/src/busybox/busybox-1.31.1_config.nosuid

I haven't tested.. it might be useful to look at the 'bc' source code as well: https://git.busybox.net/busybox/tree/miscutils/bc.c
github.com/aw

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14801
 :(

If any dc users would like to test the effect of FEATURE_BC_LONG_OPTIONS it would be much appreciated..

Offline jazzbiker

  • Hero Member
  • *****
  • Posts: 934
HI!

There are no references to bc functions in dc.c, and bc config options will not have any impact on dc behaviour. The main "improvement" is done in dc_main(), and it means, that getopt() is used, so dc command line is tested for the two switches "e" and "f" and no more.
Other "improvement" ( throwing out of keywords sub, add, etc ) is done by commenting with the help of //.
My first glance on the sources of 1.31 and 1.29 BB make me feel, that old dc behaviour can be restored by simply replacing of dc_main() with dc_main() from 1.29. This will eliminate e and f switches processing.

So we have two ways:
1. Patch TC system stuff in order to achieve new dc compatibility.
2. Patch dc in order to restore its native behaviour.

What's the choice?

P.S. As for me personally i will unconditionally patch the dc in order to use TC11

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11594
Hi jazzbiker
... So we have two ways:
1. Patch TC system stuff in order to achieve new dc compatibility.
2. Patch dc in order to restore its native behaviour. ...
3. Remove the  dc  requirement from the system stuff.

Attached are patches for 2 possible ways of removing  dc:

1. The tce-size.sh.diff uses the shells built in math capabilities. It's not floating point math so all the numbers end in  .00  and anything
    smaller than 1 Meg shows up as  0.00. I personally never pay attention to the decimal places. The integer byte count is just to the
    left of the "floating point" number if someone really cares about actual size. This patch runs just as fast as the  dc  version.

2. The tce-size.calc.diff uses the  calc  script which is just a wrapper for  awk  and it does do floating point math. It is a little slower
    than the  dc  version. The time to populate the window when selecting the size tab for  gtk3-dev.tcz  in  Apps  is:

        dc=3 Secs.
        calc=4.5 Secs.

The only effected files I found were  tce-size  and  filetool.sh.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
The calc one looks good.
The only barriers that can stop you are the ones you create yourself.

Offline jazzbiker

  • Hero Member
  • *****
  • Posts: 934
Hi,Rich!

The only effected files I found were  tce-size  and  filetool.sh.

If really only this two files, the trouble is quite small. But if no (and for those like me, who used dc in their scripts) i attach promised patch for BB 1.31.1 dc.c with dc_main() replaced with the dc_main() from BB 1.29.3 and reenabled keywords for arythmetic operations.

Unfortunately, both ways demand rootfs.gz correction (


Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11594
Hi curaga
The calc one looks good.
I have another one. It's a variation of a technique I used on an embedded processor that didn't have space for floating point code.
This is the function that does the work:
Code: [Select]
Fixed3Div()
{
# divide $1 by $2. Return result to 3 decimal places, no rounding.
printf "%d.%03d\n" $(($1 / $2)) $(((($1 % $2) * 1000) / $2))
}
The left side of the decimal point comes from the integer divide --> $(($1 / $2))
The fractional part is derived by dividing the remainder separately after multiplying by 1000 --> $(((($1 % $2) * 1000) / $2))
The  printf  command handles formatting the fractional part with leading zeros and a field width of 3 digits.
If a divisor of 2 Meg or larger is used there is the potential for overflow (sign reversal) of the fractional part. The divisor in
this application is always 1 MEG so it's not an issue.

This version is just as fast as the  dc  version.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14801
Changes added to tc git - thanks

Offline Santos

  • Full Member
  • ***
  • Posts: 106
I love frugality. It's what computing should be.

Offline watt

  • Newbie
  • *
  • Posts: 3
Hi,


The only effected files I found were  tce-size  and  filetool.sh.

Changes added to tc git - thanks

Well, only tce-size was corrected. filetool.sh wasn't and thus doesn't work.

One thing I don't understand is how it was not noticed: nobody uses filetool.sh? Isn't it a tool we should commonly use? What do people use instead?

Offline watt

  • Newbie
  • *
  • Posts: 3
One thing I don't understand is how it was not noticed: nobody uses filetool.sh? Isn't it a tool we should commonly use? What do people use instead?

Answering myself for that point: the calls to dc are only present in the path of the "Dry run" option, so one can use filetool.sh regularly and yet never encounter the bug as long as one doesn't use this option.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14801
If somebody could propose a patch for filetool.sh, it will be added to tc git.

Offline watt

  • Newbie
  • *
  • Posts: 3
If somebody could propose a patch for filetool.sh

Here is one. I simply mimicked the patch that was made for tce-size.

Generated without a leading path with the following command:

Code: [Select]
diff -u filetool.sh.orig filetool.sh.fixedpoint > filetool.sh.fixedpoint.diff
(original version of the file being the one from github)

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Applied, thanks.
The only barriers that can stop you are the ones you create yourself.