in reply to Re: Influencing the Gconvert macro
in thread Influencing the Gconvert macro
If you can't or won't spend time in fixing compline/d_gconvert.U, the best approach will be to create your own Policy.sh which defined d_Gconvert exactly as you want it.
The -D argument might work, but I am always scared of interpolation when requiring quotes. The tricky parts are the callback units.
Setting this using env does not work.
Enjoy, Have FUN! H.Merijn
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^3: Influencing the Gconvert macro
by syphilis (Archbishop) on Sep 30, 2020 at 14:27 UTC | |
If I can fix it, then I will undertake to do so. At the moment, however, I have no idea how d_gconvert.U fits into "the scheme of things". AFAICS, it's not part of the perl source. ... but I am always scared of interpolation when requiring quotes I bothers me a bit, too. Although the configure option that I used seems to have done the trick, it wasn't exactly noiseless: Of course, I probably should at least run make test before I start getting too excited about how successful it has been ;-) Cheers, Rob | [reply] [Watch: Dir/Any] [d/l] [select] |
by Tux (Canon) on Sep 30, 2020 at 14:54 UTC | |
But it is dear hacker, it is! (free interpretation of Jethro Tull's "But you can Guru, You can" in the story of the Hare who lost his spectacles) Please see d_gconvert.U. Short summary, these units are parsed, selected and ordered according to the requirements of the perl source itself and than remodelled into the script that is called Configure. If you dare start the journey, read the README to start this early in the perl configuration process. Enjoy, Have FUN! H.Merijn | [reply] [Watch: Dir/Any] [d/l] |
by hv (Prior) on Oct 01, 2020 at 04:00 UTC | |
I've seen such warnings in smoke logs a number of times, and tried to investigate at least a couple of times without success; I'd love (someone) to get to the bottom of it, at least to understand if it's a real problem (that needs to be fixed by increasing a buffer size). I've never seen anyone report an actual problem relating to the warning though. Hugo | [reply] [Watch: Dir/Any] |
by syphilis (Archbishop) on Oct 01, 2020 at 07:38 UTC | |
I can verify that the "%.*g" formatting still works ok when the buffer size needs to be bigger than 127. For example, with this patched perl, perl -le 'printf "%.751g\n", 2 ** - 1074;' prints out all 751 mantissa digits correctly and displays the exact decimal rendition of the value 2 ** -1074.
Actually, I can add a little to that. I hacked the source to print out the size of the buffer, and I've just discovered that, so long as I ask for no more than 91 digits, the buffer size is 127 - which should be sufficient. But as soon as I ask for more than 91 digits, the buffer size is not displayed - indicating that the processing has switched to a different block. Incredibly, when I ask for more than 91 digits, I've also just now realized that the "%.*g" formatting works fine on Ubuntu-18.04 perls. That is, the bug exists only when I request 18 to 91 (inclusive) digits. If I request a number outside of that range, it works fine on a standard (unpatched) perl-5.32.0 on Ubuntu-18.04: So it looks to me that the concern surrounding the 127-byte buffer is unfounded, because the processing switches to a different block as soon as we ask for more than 91 digits. But I'm not prepared to claim that I've actually proved anything ;-) Cheers, Rob | [reply] [Watch: Dir/Any] [d/l] [select] |
by hv (Prior) on Oct 01, 2020 at 13:24 UTC | |
by syphilis (Archbishop) on Oct 02, 2020 at 03:55 UTC | |
|