--pretty-print vs original: two behaviours

Digi

unread,

Feb 21, 2017, 9:28:26 AM2/21/17

to

Hi!

i have an issue with the script composed by --pretty-print option.
the original source containing more than 30 includes with the total size around 500 kb. so i was needed to compose its into the large single source file. i found that --pretty-print option may be used for this. but the resulted source have different behaviour than the original script. due to huge size of the source currently i have no idea what exactly is wrong with the script generated by the --pretty-print

so here is the question:

is it possible that the script in original form: with the many includes, BEGIN areas and ~ 1K funcs - and the script generated by the --pretty-print option - may have any differences in its behaviours?

thnx
Denis

ps. sorry for my bad english

Bruce Horrocks

unread,

Feb 21, 2017, 1:09:30 PM2/21/17

to

Section 11.3.9 [1] of the Gawk manual includes an example awk program
that does @include pre-processing. You could try using this to process
your script and see if the same issue occurs?

[1]
<https://www.gnu.org/software/gawk/manual/html_node/Igawk-Program.html#Igawk-Program>

--
Bruce Horrocks
Surrey
England
(bruce at scorecrow dot com)

Hermann Peifer

unread,

Feb 21, 2017, 2:37:02 PM2/21/17

to

On 21/02/2017 15:28, Digi wrote:
> Hi!
>
> i have an issue with the script composed by --pretty-print option.
> the original source containing more than 30 includes with the total size around 500 kb. so i was needed to compose its into the large single source file. i found that --pretty-print option may be used for this. but the resulted source have different behaviour than the original script. due to huge size of the source currently i have no idea what exactly is wrong with the script generated by the --pretty-print
>

Which version of Gawk are you using?
Why exactly is a single source file needed?

A source code size of 500k means something like 10000-20000 lines of
code (my best guess). The Gawk manual gives this hint:

> If you find yourself writing awk scripts of more than, say,
> a few hundred lines, you might consider using a different
> programming language.
https://www.gnu.org/software/gawk/manual/html_node/When.html#When

Hermann

Hermann Peifer

unread,

Feb 21, 2017, 2:51:40 PM2/21/17

to

On 21/02/2017 20:37, Hermann Peifer wrote:
> On 21/02/2017 15:28, Digi wrote:
>> Hi!
>>
>> i have an issue with the script composed by --pretty-print option.
>> the original source containing more than 30 includes with the total size around 500 kb. so i was needed to compose its into the large single source file. i found that --pretty-print option may be used for this. but the resulted source have different behaviour than the original script. due to huge size of the source currently i have no idea what exactly is wrong with the script generated by the --pretty-print
>>
>
> Which version of Gawk are you using?
> Why exactly is a single source file needed?
>
> A source code size of 500k means something like 10000-20000 lines of
> code (my best guess). The Gawk manual gives this hint:
>
>> If you find yourself writing awk scripts of more than, say,
>> a few hundred lines, you might consider using a different
>> programming language.
> https://www.gnu.org/software/gawk/manual/html_node/When.html#When
>
> Hermann
>

I forgot to give an example where pretty-printing changes the code, see
below. In earlier versions of gawk, pretty-print would also print
integers with format "%.6g" which might change the code.

# Gawk 4.1.4
$ /opt/local/bin/gawk -o- 'BEGIN{ x = .9999999 }'
# gawk profile, created Tue Feb 21 20:42:21 2017

# BEGIN rule(s)

BEGIN {
x = 1
}

# Gawk from git/master
$ gawk -o- 'BEGIN{ x = .9999999 }'
BEGIN {
x = .9999999
}

Digi

unread,

Feb 21, 2017, 3:43:07 PM2/21/17

to

Hermann Peifer: yes :) i was reading this before. i use actual possibility to doing my tasks. i find gawk very effective language - in case if you have massive infrastructure for the programming. may be this is the point of the question: why two scripts have different behaviour. the source contains many tricks with indirect function calls, a lot amount of special arrays defined. many includes(some contain subincludes). the extremely important thing is the BEGIN's area's sequence - it's contains three level of initializations...
okay. I find the solution suggested by Bruce Horrocks very intresting and will try to get script by that way. will report here about the result.

Digi

unread,

Feb 21, 2017, 3:46:00 PM2/21/17

to

GNU Awk 4.1.4, API: 1.1 (GNU MPFR 3.1.0-p8, GNU MP 5.0.2)
Windows 7x64 6.1.7601

Ed Morton

unread,

Feb 21, 2017, 3:52:09 PM2/21/17

to

On 2/21/2017 2:45 PM, Digi wrote:
> GNU Awk 4.1.4, API: 1.1 (GNU MPFR 3.1.0-p8, GNU MP 5.0.2)
> Windows 7x64 6.1.7601
>

You're posting on netnews, not a web forum, so provide enough context so each
posting stands alone. Right now we're seeing a bunch of disconnected small
bursts of text. I for one have absolutely no idea what most of your posts have
been about the past couple of days and YMMV with getting people to go digging
(no pun intended) through previous posts trying to piece the context together.

Ed.

Digi

unread,

Feb 23, 2017, 1:27:43 PM2/23/17

to

excuse me but i ask the principle question:

is it possible - in principle - that the script in original form and the same script generated by --pretty-print feature - both - may have different ehaviour?

or its wrong anyway?

thank you
Denis S.

Digi

unread,

Feb 23, 2017, 1:40:36 PM2/23/17

to

i'm trying to find any clues - where i should pay my attention primarily - to find the problem. sadly - i can not try to reproduce the issue on Linux because the script will then requiring linux-modules that is not exist.

could you be so kind to send me a link where my question question is more appropriate?

regards
Denis S.

Joe User

unread,

Feb 23, 2017, 2:21:10 PM2/23/17

to

Digi wrote:

> i'm trying to find any clues - where i should pay my attention primarily -
> to find the problem. sadly - i can not try to reproduce the issue on Linux
> because the script will then requiring linux-modules that is not exist.

Debugging is hard.

Get a minimum input that demonstrates the discrepancy.

Then, use the debugger or embedded print statements to find where the
operation of the pretty-printed code deviates from expected operation.

Compare the code preceding the discrepancy with the original code.

Notify this newsgroup of how the pretty-printer is damaging the output code.

Andrew Schorr

unread,

Feb 23, 2017, 6:31:14 PM2/23/17

to

On Thursday, February 23, 2017 at 1:27:43 PM UTC-5, Digi wrote:
> is it possible - in principle - that the script in original form and the same script generated by --pretty-print feature - both - may have different ehaviour?
>
> or its wrong anyway?

I think it's possible if there's a bug in the --pretty-print logic.

Regards,
Andy

Kenny McCormack

unread,

Feb 25, 2017, 12:33:01 PM2/25/17

to

In article <d0d211b9-fa30-47df...@googlegroups.com>,

(To amplify upon this...)

I assume the status of the "--pretty-print logic" is "all known bugs
fixed", which means that only unknown bugs remain. That said, two things
are known:
1) That pretty-print works by reconstructing the source from the
"compiled" (for suitable meanins of this word) internal form of the
script. So, it is not guaranteed to match the original exactly
(and, in fact, is known to not be identical).
2) There was one bug that we know of - where .999999 (in the original)
gets rendered as 1 in the reconstructed version. That bug is
fixed, but we know not what others remain.

--
I am not a troll.
Rick C. Hodgin
I am not a crook.
Rick M. Nixon