Merging pending pull requests

[tueda]

Perhaps, first we need to merge

• Upgrade macOS 12 to 13 in CI #597

to keep the CI working.

Maybe, is it also fine to merge minor fixes in scripting and README?

• build: fix git-version-gen script to use LC_ALL instead of LANG for the locale setting #534
• Fix examples in README #572

[jodavies]

Yes, I think those are all fine to merge. Then next I think

• Write term size in compress buffer in GetOneTerm when reading from fi… #592
• Fix sign error for wildcard powers of dotproducts involving negative vectors #583

don't need any additional changes and could go in also.

Most of the other stuff perhaps needs some tweaks or additional bugfixes etc.

[tueda]

#592 is fine to me.

For #583, I'm not sure if its test is sufficient.
It is a bit unclear which pairs of terms should be cancelled, and accidental cancellations could potentially occur.
And, tests for, e.g., f(-p?,x?) is not necessary?

[jodavies]

Maybe this is a bit more comprehensive. Can you think of any other interesting patterns in this context?

#-
Off Statistics;

Symbol x;
Vector D,p,q,r,s;
CFunction tag;
CFunction f,g,h,i,j,k,l,m;
CFunction F,G,H,I,J,K,L,M;

Local test =
	#do i = -3,3
		+ f(p,`i')
		+ f(-q,`i')
		+ f(p,q,`i')
		+ f(-p,r,`i')
		+ f(p,-q,`i')
		+ f(-p,-s,`i')
	#enddo
	;
Identify f(?a) =
	+ f(?a) - F(?a)
	+ g(?a) - G(?a)
	+ h(?a) - H(?a)
	+ i(?a) - I(?a)
	+ j(?a) - J(?a)
	+ k(?a) - K(?a)
	+ l(?a) - L(?a)
	+ m(?a) - M(?a)
	;
.sort

* Use tags to make sure the cancellation is unique
Identify f(p?,x?) = D.p^x * tag(f,p,x);
Identify f(p?,q?,x?) = p.q^x * tag(f,p,q,x);
Identify g(p?,x?) = D.p^-x * tag(g,p,x);
Identify g(p?,q?,x?) = p.q^-x * tag(g,p,q,x);

Identify h(p?,x?) = (D.p)^x * tag(h,p,x);
Identify h(p?,q?,x?) = (p.q)^x * tag(h,p,q,x);
Identify i(p?,x?) = D.p^(x) * tag(i,p,x);
Identify i(p?,q?,x?) = p.q^(x) * tag(i,p,q,x);

* And with - signs on the pattern vector:
Identify j(-p?,x?) = D.p^x * tag(j,p,x);
Identify j(-p?,-q?,x?) = p.q^x * tag(j,p,q,x);
Identify k(-p?,x?) = D.p^-x * tag(k,p,x);
Identify k(-p?,-q?,x?) = p.q^-x * tag(k,p,q,x);

Identify l(-p?,x?) = (D.p)^x * tag(l,p,x);
Identify l(-p?,-q?,x?) = (p.q)^x * tag(l,p,q,x);
Identify m(-p?,x?) = D.p^(x) * tag(m,p,x);
Identify m(-p?,-q?,x?) = p.q^(x) * tag(m,p,q,x);

* Cancel all terms, with no pattern for the power
#do i = -3,3
	Identify F(p?,`i') =  D.p^`i' * tag(f,p,`i');
	Identify F(p?,q?,`i') = p.q^`i' * tag(f,p,q,`i');
	Identify G(p?,`i') = D.p^-`i' * tag(g,p,`i');
	Identify G(p?,q?,`i') = p.q^-`i' * tag(g,p,q,`i');

	Identify H(p?,`i') =  (D.p)^`i' * tag(h,p,`i');
	Identify H(p?,q?,`i') = (p.q)^`i' * tag(h,p,q,`i');
	Identify I(p?,`i') = D.p^(`i') * tag(i,p,`i');
	Identify I(p?,q?,`i') = p.q^(`i') * tag(i,p,q,`i');

	Identify J(-p?,`i') = D.p^`i' * tag(j,p,`i');
	Identify J(-p?,-q?,`i') = p.q^`i' * tag(j,p,q,`i');
	Identify K(-p?,`i') = D.p^-`i' * tag(k,p,`i');
	Identify K(-p?,-q?,`i') = p.q^-`i' * tag(k,p,q,`i');

	Identify L(-p?,`i') = (D.p)^`i' * tag(l,p,`i');
	Identify L(-p?,-q?,`i') = (p.q)^`i' * tag(l,p,q,`i');
	Identify M(-p?,`i') = D.p^(`i') * tag(m,p,`i');
	Identify M(-p?,-q?,`i') = p.q^(`i') * tag(m,p,q,`i');
#enddo

Print +s;
.end

[tueda]

Perhaps, it is simpler to assign tags before the .sort?

Identify f(?a) =
	+ (f(?a) - F(?a)) * tag(f,?a)
  ...

[jodavies]

Sure, that is true.

[jodavies]

OK, these are now all in master and 4.3.

[tueda]

Thanks!

[tueda]

Perhaps we can merge:

• Improve Windows build #511.

Currently, there are no test failures in the deploy workflow.

The key decision to be made is the level of native Windows support:

1. Do not publish the native Windows binaries to GitHub Releases.
2. Publish the native Windows binaries as is (regardless of whether or not they pass the test cases) to GitHub Releases (* the current code of the PR).
3. (2) + Ensure that the native Windows binaries pass all the test cases in the CI pipeline.

I would also like to confirm whether my understanding and the fixes for #602 and #605 are correct.

After merging #511, if you agree, I will consider

• Enhance test suite #587
  • check/README.md should be updated.
• Run-time deprecation warning for native Windows, 32-bit systems, ParFORM and Checkpoint #573
  • Create 3 issues for deprecating native Windows, 32bit builds and ParFORM.
  • Rewrite the issue URLs in the deprecation warnings.

Note that these modify the build/test/CI files, which would conflict with #524 or flint-prf, for example.

[tueda]

Merging #511 and #587 in the current form should be OK, though the description of subdirectories (check/forcer) should be modified when considering #524.

#549 (related to 32-bit) is also OK when the remaining cast-function-type warnings are fixed.

Then #573. We will also add Checkpoint to the deprecated features and see if people would complain.

[tueda]

I have some time today and tomorrow, so I will finally merge #511 and #587. Both will also be merged into the v4.3 branch. (I hope I haven't missed anything...)

[tueda]

When merging #511, somehow Issue512_3 unexpectedly failed for valgrind tvorm -w2:

https://github.com/vermaseren/form/actions/runs/12949561952/job/36120559486

TFORM 5.0.0-beta.1 (Jan 24 2025, v5.0.0-beta.1-108-g42de574) 2 workers  Run: Fri Jan 24 12:30:31 2025
    #-

Time =       0.11 sec    Generated terms =      52500
            test         Terms in output =      52500
                         Bytes used      =    1267016
Please increase SmallExtension setup parameter.
Program terminating in thread 1 at 1.frm Line 15 -->

while the 2nd run successfully finished.

[jodavies]

Interesting. I can reproduce this about 1% of the time, outside of valgrind, with tform and tvorm. Presumably it depends on exactly how many terms end up in each thread. I'll try to adjust the test to be more robust.

[jodavies]

It should suffice to set the SmallExtension to, say, 30720000. Then it still crashes in b3f84b4 but I can't reproduce the crash any more on the master branch.

[jodavies]

For option 3, how many failing cases are there? Since native windows support will have "deprecated" status I would think option 2 suffices, as long as we don't introduce any additional failures between now and the release of FORM5 (i.e., anyone who using a native windows build in the current state, shouldn't find things suddenly requiring further workarounds).

Simple fixes for current issues (such as #602) should of course go in.

[tueda]

For option 3, how many failing cases are there?

No failing cases:

285 tests, 916 assertions, 0 failures, 0 errors, 6 pendings, 6 omissions, 0 notifications

https://github.com/vermaseren/form/actions/runs/12524774133/job/34935643956

On the master branch, there are many failing cases in Test, but the CI ignores errors (non-zero exit code) in Build/Test on Windows:

form/.github/workflows/deploy.yml

Line 140 in 8abec49

continue-on-error: ${{ runner.os == 'Windows' }}

283 tests, 892 assertions, 34 failures, 0 errors, 5 pendings, 1 omissions, 0 notifications

https://github.com/vermaseren/form/actions/runs/12255276916/job/34188347926

Another option 3b could be: ensuring the Build succeeds on Windows while allowing the CI to ignore errors in the Test step.