Fix windows

[edwardalee]

For some reason, Windows tests are disabled for PRs, which results in a bunch of recent merges that are incompatible with Windows. This is an attempt to get things working again in master. However, this PR is also not running Windows tests, so I don't know how to test whether this solves the problem. Apparently, the Windows tests are only run if you push something to reactor-c (see test failures here).

Pathetically, we seem to be using an antique C compiler in Windows that does not support C99, in particular, variable size arrays on the stack. The test/C/src/Mutable.lf has to use a constant rather than a parameter for a mutable multiport input. To implement this without variable size arrays on the stack would be very painful. It would have to be malloc'd, and some sort of special hook would have to be added to free it. Can we upgrade the C compiler on Windows instead?

[lhstrh]

You can trigger the Windows/macOS platforms by manually triggering the workflow. We had disabled them because everyone was perpetually watching progress bars.

A manual run revealed there are still problems with Python and TypeScript on Windows. The TypeScript failure is sus and might be a nondeterministic one. @vinzbarbuto, the Python failure has to do with paths:

Running: src\lingo_imports\FederatedTestImportPackages.lf (51%)
    0    [Test worker] ERROR xt.linking.lazy.LazyLinkingResource  - resolution of uriFragment '|0' failed.
    java.nio.file.InvalidPathException: Illegal char <:> at index 4: file:/D:/a/lingua-franca/lingua-franca/test/Python/src/lingo_imports/FederatedTestImportPackages.lf

[vinzbarbuto]

A manual run revealed there are still problems with Python and TypeScript on Windows. The TypeScript failure is sus and might be a nondeterministic one. @vinzbarbuto, the Python failure has to do with paths:

Running: src\lingo_imports\FederatedTestImportPackages.lf (51%)
    0    [Test worker] ERROR xt.linking.lazy.LazyLinkingResource  - resolution of uriFragment '|0' failed.
    java.nio.file.InvalidPathException: Illegal char <:> at index 4: file:/D:/a/lingua-franca/lingua-franca/test/Python/src/lingo_imports/FederatedTestImportPackages.lf

I’m not sure what’s causing this error. It looks like it’s related to the path resolution, but I’m wondering why it didn’t happen in the other test we ran. Maybe it has something to do with the Windows path? How can I reproduce this error?

[lhstrh]

A manual run revealed there are still problems with Python and TypeScript on Windows. The TypeScript failure is sus and might be a nondeterministic one. @vinzbarbuto, the Python failure has to do with paths:

Running: src\lingo_imports\FederatedTestImportPackages.lf (51%)
    0    [Test worker] ERROR xt.linking.lazy.LazyLinkingResource  - resolution of uriFragment '|0' failed.
    java.nio.file.InvalidPathException: Illegal char <:> at index 4: file:/D:/a/lingua-franca/lingua-franca/test/Python/src/lingo_imports/FederatedTestImportPackages.lf

I’m not sure what’s causing this error. It looks like it’s related to the path resolution, but I’m wondering why it didn’t happen in the other test we ran.

It's the : in the path that's the problem.

[vinzbarbuto]

It's the : in the path that's the problem.

Yes, it seems to be the Windows path issue. Do you know how I can reproduce the error on macOS so I can fix this?

[lhstrh]

It's the : in the path that's the problem.

Yes, it seems to be the Windows path issue. Do you know how I can reproduce the error on macOS so I can fix this?

Nope. If you have no access to a Windows machine, your best bet would probably be to guess and debug in CI.

[lhstrh]

The path issue has been resolved, but other issues remain (including the one this PR meant to address, it seems). See: https://github.com/lf-lang/lingua-franca/actions/runs/11308047484/job/31450473838

[vinzbarbuto]

The path issue has been resolved, but other issues remain (including the one this PR meant to address, it seems). See: https://github.com/lf-lang/lingua-franca/actions/runs/11308047484/job/31450473838

I believe the problem outlined here is related to federated execution on Windows. To test the new import statement, I added:

• src/LingoFederatedImport.lf to test the new import statement for federated programs in the src folder
• src/lingo_imports/FederatedTestImportPackages.lf to test the new import statement for federated programs in a subfolder of src

However, since Edward moved LingoFederatedImport.lf to src/federated/LingoFederatedImport.lf to skip federated execution on Windows, the latter file is already in a subdirectory of src. Therefore, we can remove src/lingo_imports/FederatedTestImportPackages.lf since is a redundant test and avoid the error related to federated execution on Windows.

[lhstrh]

The path issue has been resolved, but other issues remain (including the one this PR meant to address, it seems). See: https://github.com/lf-lang/lingua-franca/actions/runs/11308047484/job/31450473838

I believe the problem outlined here is related to federated execution on Windows. To test the new import statement, I added:

* `src/LingoFederatedImport.lf` to test the new import statement for federated programs in the `src` folder

* `src/lingo_imports/FederatedTestImportPackages.lf` to test the new import statement for federated programs in a subfolder of `src`

However, since Edward moved LingoFederatedImport.lf to src/federated/LingoFederatedImport.lf to skip federated execution on Windows, the latter file is already in a subdirectory of src. Therefore, we can remove src/lingo_imports/FederatedTestImportPackages.lf since is a redundant test and avoid the error related to federated execution on Windows.

Sorry, I do not understand what you mean. Does it mean that you can fix it? 😄

[vinzbarbuto]

Sorry, I do not understand what you mean. Does it mean that you can fix it? 😄

Yes, @edwardalee said:

Indeed, the Windows tests cannot pass because of this file:

test/Python/src/LingoFederatedImport.lf

which fails under Windows. Windows does not support federated execution. This should be in the federated subdirectory so it is excluded by the Windows tests.

Therefore, we should place all federated tests in the federated subdirectory to prevent Windows from failing to execute them. Edward moved LingoFederatedImport.lf to federated/LingoFederatedImport.lf, but that wasn't the only test I added for federated executions. I also added this file: src/lingo_imports/FederatedTestImportPackages.lf, which is now failing:

 Failed: src\lingo_imports\FederatedTestImportPackages.lf in 0.00 seconds

The solution could be either to add this test to the federated directory or remove it. I suggest removing it since it’s redundant; I initially used it to test two corner cases, but now federated/LingoFederatedImport.lf is sufficient.

[lhstrh]

OK, please go head 👍

[vinzbarbuto]

OK, please go head 👍

Done. This should solve at least the Python tests

[erlingrj]

Looks good. But not sure if there is anything we can do about variable length arrays on Windows. This blog post says that even if the support C11 and C17 they will not support variable-length arrays.

Astute readers will note that VLAs are also not supported. Variable length arrays are generally less efficient than comparable fixed sized arrays, and generally inefficient compared to equivalent malloc(), when safely and securely implemented. VLAs provide attack vectors comparable to those of the infamous gets() — deprecated and destined to removal — for opportunities of “shifting the stack” and other exploits. For these reasons we intend not to support VLAs as an optional feature in C11.
https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/

The question has been posed before, but, do we really need Windows-support?