Removing output line length limit

[magv]

Hi, all. For pySecDec we use FORM to optimize expressions and #write corresponding C files. Now, #write has a line length limit; it can be changed using the format command, but the docs say:

format Controls the format for the printing of expressions. There is a variety of options. <number> Output will be printed using the indicated number of characters per line. The default is 72. Numbers outside the range 1-255 are corrected to 72. Positive numbers less than 39 are corrected to 39.

Some of our lines are longer than 255 characters, and what FORM does is it simply inserts newlines in the middle of expressions; e.g.:

$ cat >test.frm <<EOF
#write <out> "123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789abcdefg"
.end
EOF
$ form test.frm
$ cat out
123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789ab
cdefg
.end

For years we've used a workaround: we would strip all the whitespace from FORM's output, and use special markers (e.g. #@SecDecInternalNewline@#) to restore some of it... As you might imagine creating this sort of a system was a nightmare in the first place, and trying to make changes to it is an ongoing source of headache.

Could the restriction of 255 characters per line be lifted? I'd like a way to tell FORM not to insert any spurious newlines into the output, ever, anywhere.

I understand that the original motivation for this feature was to make the Fortran compilers happy. Our use case is not limited by this at all, so we'll be happy not to use this part of the code.

[vermaseren]

Somewhere in the code there is a fixed size array and a test on the 255. Those are the ones that should be adapted. It should also be possible to make this a setup parameter. This 255 is a relict of versions 1 and 2. Probably forgotten when version 3 was made. On the other hand: there are editors that do not like extremely long lines.

On 31 Aug 2021, at 16:08, Vitaly Magerya @.***> wrote:

Hi, all. For pySecDec we use FORM to optimize expressions and #write corresponding C files. Now, #write has a line length limit; it can be changed using the format command, but the docs say:

format Controls the format for the printing of expressions. There is a variety of options.

Output will be printed using the indicated number of characters per line. The default is 72. Numbers outside the range 1-255 are corrected to 72. Positive numbers less than 39 are corrected to 39. Some of our lines are longer than 255 characters, and what FORM does is it simply inserts newlines in the middle of expressions; e.g.: $ cat >test.frm < "123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789abcdefg" .end EOF $ form test.frm $ cat out 123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789ab cdefg .end For years we've used a workaround: we would strip all the whitespace from FORM's output, and use special markers (e.g. ***@***.***@#) to restore some of it... As you might imagine creating this sort of a system was a nightmare in the first place, and trying to make changes to it is an ongoing source of headache. Could the restriction of 255 characters per line be lifted? I'd like a way to tell FORM not to insert any spurious newlines into the output, ever, anywhere. I understand that the original motivation for this feature was to make the Fortran compilers happy. Our use case is not limited by this at all, so we'll be happy not to use this part of the code. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub , or unsubscribe . Triage notifications on the go with GitHub Mobile for iOS or Android .

[magv]

I've looked at the source a bit: the line length limit is used in pre.c and message.c, both rely on #define MAXLINELENGTH 256 in fsizes.h. I could of course increase this value, but I don't think this will solve my problem: rather there to be a lager limit, I want there to be no limit -- only in this case can I safely remove the workarounds. So I guess some modifications to writeToChannel() in pre.c and possibly MesPrint() in message.c is needed so that they would not insert newlines. The logic in both is a bit too complicated for me to immediately say what this change should be.

[crmafra]

On Tue, 31 Aug 2021 at 8:01:19 -0700, Jos Vermaseren wrote:

Somewhere in the code there is a fixed size array and a test on the 255. Those are the ones that should be adapted. It should also be possible to make this a setup parameter. This 255 is a relict of versions 1 and 2. Probably forgotten when version 3 was made. On the other hand: there are editors that do not like extremely long lines.

I always apply the following patch to my private copy of FORM to increase the length limit:

diff --git a/sources/fsizes.h b/sources/fsizes.h index d23477f..ad73d76 100644 --- a/sources/fsizes.h +++ b/sources/fsizes.h @@ -181,7 +181,7 @@

define NPAIR1 38

define NPAIR2 89

-#define MAXLINELENGTH 256 +#define MAXLINELENGTH 512

define MINALLOC 32

define JUMPRATIO 4

Would you consider making this change in your repository?

On 31 Aug 2021, at 16:08, Vitaly Magerya @.***> wrote:

Hi, all. For pySecDec we use FORM to optimize expressions and #write corresponding C files. Now, #write has a line length limit; it can be changed using the format command, but the docs say:

format Controls the format for the printing of expressions. There is a variety of options.

Output will be printed using the indicated number of characters per line. The default is 72. Numbers outside the range 1-255 are corrected to 72. Positive numbers less than 39 are corrected to 39. Some of our lines are longer than 255 characters, and what FORM does is it simply inserts newlines in the middle of expressions; e.g.: $ cat >test.frm < "123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789abcdefg" .end EOF $ form test.frm $ cat out 123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789ab cdefg .end For years we've used a workaround: we would strip all the whitespace from FORM's output, and use special markers (e.g. ***@***.***@#) to restore some of it... As you might imagine creating this sort of a system was a nightmare in the first place, and trying to make changes to it is an ongoing source of headache. Could the restriction of 255 characters per line be lifted? I'd like a way to tell FORM not to insert any spurious newlines into the output, ever, anywhere. I understand that the original motivation for this feature was to make the Fortran compilers happy. Our use case is not limited by this at all, so we'll be happy not to use this part of the code. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub , or unsubscribe . Triage notifications on the go with GitHub Mobile for iOS or Android .

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/vermaseren/form/issues/391#issuecomment-909319571

[vermaseren]

It seems that a better option would be to suppress the linefeed in certain printouts. This would have some similarity with how the carriagereturn is treated for windows style output.

On 31 Aug 2021, at 17:23, crmafra @.***> wrote:

On Tue, 31 Aug 2021 at 8:01:19 -0700, Jos Vermaseren wrote:

Somewhere in the code there is a fixed size array and a test on the 255. Those are the ones that should be adapted. It should also be possible to make this a setup parameter. This 255 is a relict of versions 1 and 2. Probably forgotten when version 3 was made. On the other hand: there are editors that do not like extremely long lines.

I always apply the following patch to my private copy of FORM to increase the length limit:

diff --git a/sources/fsizes.h b/sources/fsizes.h index d23477f..ad73d76 100644 --- a/sources/fsizes.h +++ b/sources/fsizes.h @@ -181,7 +181,7 @@

define NPAIR1 38

define NPAIR2 89

-#define MAXLINELENGTH 256 +#define MAXLINELENGTH 512

define MINALLOC 32

define JUMPRATIO 4

Would you consider making this change in your repository?

On 31 Aug 2021, at 16:08, Vitaly Magerya @.***> wrote:

Hi, all. For pySecDec we use FORM to optimize expressions and #write corresponding C files. Now, #write has a line length limit; it can be changed using the format command, but the docs say:

format Controls the format for the printing of expressions. There is a variety of options.

Output will be printed using the indicated number of characters per line. The default is 72. Numbers outside the range 1-255 are corrected to 72. Positive numbers less than 39 are corrected to 39. Some of our lines are longer than 255 characters, and what FORM does is it simply inserts newlines in the middle of expressions; e.g.: $ cat >test.frm < "123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789abcdefg" .end EOF $ form test.frm $ cat out 123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789abcdefg 123456789ab cdefg .end For years we've used a workaround: we would strip all the whitespace from FORM's output, and use special markers (e.g. ***@***.***@#) to restore some of it... As you might imagine creating this sort of a system was a nightmare in the first place, and trying to make changes to it is an ongoing source of headache. Could the restriction of 255 characters per line be lifted? I'd like a way to tell FORM not to insert any spurious newlines into the output, ever, anywhere. I understand that the original motivation for this feature was to make the Fortran compilers happy. Our use case is not limited by this at all, so we'll be happy not to use this part of the code. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub >, or unsubscribe >. Triage notifications on the go with GitHub Mobile for iOS > or Android >.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/vermaseren/form/issues/391#issuecomment-909319571 https://github.com/vermaseren/form/issues/391#issuecomment-909319571 — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/391#issuecomment-909338131, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJPCEWR4JBN74UG2QJ4XCLT7TXVJANCNFSM5DEGSA6Q. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[magv]

I've looked into the code that inserts these newlines, and I'm afraid it's too tangled for me to fix it without knowing which parts is it OK to break. The complication is that the code is duplicated in 9 places in writeToChannel() in pre.c and 12 more places in MesPrint() in message.c, with at least three different (conflicting?) ways of doing it, and some code in between to fill in the leading spaces and trailing & and \ characters. To allow for no newlines one would need to unify all of this in a single place, and allow for an optional disable there.

[vermaseren]

It should actually not be too difficult. The culprit routine is WriteString in tools.c. If it gets a string of n characters and str[n-1] is an ASCII zero it does not write the linefeed Similarly we can add a variable to AO that could block this, given the proper Format option, or better yet, adds a zero to this string in the place where FORM composes the string and decides to write the incomplete string. I have added it to the exercises for the workshop this week.