The added tests should pass for MoarVM/MoarVM#1507. Edit: the final diff is confusing, please consider viewing each commit for the actual changes.

Currently the NQP and Rakudo builds use a hard-coded list, but this is prep work for getting their builds to actually use data taken from the MoarVM build they're using.

On various CI jobs different tests files are failing with the mentioned error, apparently being some MoarVM level failure.

Recent examples are:

https://dev.azure.com/MoarVM/MoarVM/_build/results?buildId=578&view=logs&j=d36c29d8-9236-5cd5-d848-768a0b8a3eb3&t=159b5397-e4a5-5784-febd-35f9e657944a

t/02-rakudo/06-is.t                                           (Wstat: 256 Tests: 0 Failed: 0)
  Non-zero exit status: 1
  Parse errors: No plan found in TAP output
Files=112, Tests=1835, 188 wallclock secs ( 0.77 usr +  0.33 sys =  1.09 CPU)
Result: FAIL

https://dev.azure.com/MoarVM/MoarVM/_build/results?buildId=578&view=logs&j=d0f6403b-d137-5ae0-a533-f4bebafcc251&t=608d3b9b-a763-5670-6013-39559d8f7fdf

t/04-nativecall/13-cpp-mangling.t                             (Wstat: 256 Tests: 0 Failed: 0)
  Non-zero exit status: 1
  Parse errors: No plan found in TAP output
Files=112, Tests=1816, 110 wallclock secs ( 0.48 usr  0.12 sys + 194.46 cusr 18.49 csys = 213.55 CPU)
Result: FAIL

https://dev.azure.com/MoarVM/MoarVM/_build/results?buildId=576&view=logs&j=4def8e43-62b3-5cca-1c32-fbd5a1f0442a&t=6f17dd53-63e8-5611-e660-0bfbef84498f

t/02-rakudo/10-nqp-ops.t                                      (Wstat: 256 Tests: 0 Failed: 0)
  Non-zero exit status: 1
  Parse errors: No plan found in TAP output
Files=112, Tests=1839, 155 wallclock secs ( 0.77 usr +  0.25 sys =  1.02 CPU)
Result: FAIL

https://dev.azure.com/MoarVM/MoarVM/_build/results?buildId=565&view=logs&j=70f6b8a1-f3cf-5727-bd79-d08ddb1caf67&t=f59a17df-92a9-5d7f-18bb-7f81f1c720a8

t/05-messages/moar/01-errors.t                                (Wstat: 256 Tests: 0 Failed: 0)
  Non-zero exit status: 1
  Parse errors: No plan found in TAP output
Files=112, Tests=1840, 212 wallclock secs ( 1.06 usr +  0.25 sys =  1.31 CPU)
Result: FAIL

Test for cases:

role R[::T] is T {}
role R[::T] does T {}

In support of rakudo/rakudo#4407

Test for cases:

role R[::T] is T {}
role R[::T] does T {}

In support of rakudo/rakudo#4407

Thanks! :100:

https://docs.raku.org/type/IO::Path#method_child was updated from noting an eventual deprecation to a specific deprecation in 6.d - but that deprecation doesn't exist in rakudo or roast.

We should remove the deprecation warning entirely.

https://docs.raku.org/type/IO::Path#method_child was updated from noting an eventual deprecation to a specific deprecation in 6.d - but that deprecation doesn't exist in rakudo or roast.

We should remove the deprecation warning entirely.

The problem

Text in Callable:

If the object needs to be stored in a &-sigiled container, is has to implement Callable.

(my emphasis).

Solution provided

the one-character change

is has to -> it has to

<!--

The template below contains optional suggestions. Simply omit it
if you think it does not apply to this PR.

Please state clearly in "The problem" what you are addressing with this
pull request, referencing the issue(s) where it is described.

In "Solution provided", tell us what you have done to address the
problem.

-->

1. Use x64 version
2. Try those winetricks:

   mfc42
   vcrun6
   

   Hopefully they'll help

the test is dependent on information not directly known to it. It is assumed [...] To make it really reliable it must look like: [...] $*VM.constants<PATH_MAX>

That's true. However, having such constant correctly defined, i.e. specifically for each file system (instead of just hardcoding to a number with one or two known exceptions) is nontrivial. In addition, directory creations used by this test suite is making other assumptions as well, e.g. make-temp-file relies on PATH_MAX to be at least some certain number due to the inclusion of some prefixes and timestamps. Therefore, I wonder if it is OK to not let perfect be the enemy of good here and allow an assertion that probabilistically always do the right job and a patch to MoarVM that (IMHO) correct the semantic that has been broken for at least half a decade. Of course the opposite could have been said, that if it stayed broken for so long then it's probably OK to leave it that way, but I'd much prefer the other outcome.

I think you missed my comment of it is about the directory/filename length limit, not total path name.

Basically, my note extends well to other system-level constants too.

The primary point is that the test is dependent on information not directly known to it. It is assumed, but there is no proof of correctness. Thus we can't trust test outcome. To make it really reliable it must look like:

my $path = make-temp-dir.add("foobar").add("a" x ($*VM.constants<PATH_MAX> + 1));

@vrurg, I think you missed my comment of it is about the directory/filename length limit, not total path name. Though, I want to bring up that mkdir is inherently platform dependent, e.g. the file permission concept on Windows is quite different from the three-byte POSIX one mkdir on Raku uses. In other words, if Reiser (some of the few file systems known by Wikipedia to have filename length limit greater than 255) is supported we might want a special indicator in the test case.

Greetings!

First off, apologies if this isn't the best place to ask for advice trouble-shooting a particular VST -- just let me know if there is a better outlet for this kind of thing and I would be happy to close this issue and move the discussion there.

I was wondering if you might have any suggestions for how to trouble-shoot an issue I'm encountering when attempting to install the free Valhalla Supermassive VST?

Attempting to run the installer produces an error message:

wine internal error cannot expand "autocf64" constant on this version of windows.

It seems like it may be an issue with the Inno Setup installer used?

I tried installing Inno Setup itself, just in case, but that had no effect.

I also tried installing an earlier version of Supermassive (1.0.0) which includes 32-bit support, but the result was the same.

Any ideas what the issue might be, or more generally, what might be a good approach to try and track down the problem?

Any suggestions you can provide would be greatly appreciated.

Regardless, thank you for taking the time to create and share LinVst! I'm looking forwarding to never having to boot a non-linux machine again :)

@niner It looks like we have no legal way to find out what the value of PATH_MAX is and I'd say it's important enough to be available in a non-platform, non-backend dependable way.

Bumps postcss from 7.0.27 to 7.0.36. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/postcss/postcss/releases">postcss's releases</a>.</em></p> <blockquote> <h2>7.0.36</h2> <ul> <li>Backport ReDoS vulnerabilities from PostCSS 8.</li> </ul> <h2>7.0.35</h2> <ul> <li>Add <a href="https://github.com/postcss/postcss/wiki/PostCSS-8-for-end-users">migration guide link</a> to PostCSS 8 error text.</li> </ul> <h2>7.0.34</h2> <ul> <li>Fix compatibility with <code>postcss-scss</code> 2.</li> </ul> <h2>7.0.33</h2> <ul> <li>Add error message for PostCSS 8 plugins.</li> </ul> <h2>7.0.32</h2> <ul> <li>Fix error message (by <a href="https://github.com/admosity"><code>@​admosity</code></a>).</li> </ul> <h2>7.0.31</h2> <ul> <li>Use only the latest source map annotation (by <a href="https://github.com/emzoumpo"><code>@​emzoumpo</code></a>).</li> </ul> <h2>7.0.30</h2> <ul> <li>Fix TypeScript definition (by <a href="https://github.com/nex3"><code>@​nex3</code></a>)</li> </ul> <h2>7.0.29</h2> <ul> <li>Update <code>Processor#version</code>.</li> </ul> <h2>7.0.28</h2> <ul> <li>Fix TypeScript definition (by <a href="https://github.com/nex3"><code>@​nex3</code></a>).</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/postcss/postcss/blob/main/CHANGELOG.md">postcss's changelog</a>.</em></p> <blockquote> <h2>7.0.36</h2> <ul> <li>Backport ReDoS vulnerabilities from PostCSS 8.</li> </ul> <h2>7.0.35</h2> <ul> <li>Add migration guide link to PostCSS 8 error text.</li> </ul> <h2>7.0.34</h2> <ul> <li>Fix compatibility with <code>postcss-scss</code> 2.</li> </ul> <h2>7.0.33</h2> <ul> <li>Add error message for PostCSS 8 plugins.</li> </ul> <h2>7.0.36</h2> <ul> <li>Backport ReDoS vulnerabilities from PostCSS 8.</li> </ul> <h2>7.0.35</h2> <ul> <li>Add migration guide link to PostCSS 8 error text.</li> </ul> <h2>7.0.34</h2> <ul> <li>Fix compatibility with <code>postcss-scss</code> 2.</li> </ul> <h2>7.0.33</h2> <ul> <li>Add error message for PostCSS 8 plugins.</li> </ul> <h2>7.0.32</h2> <ul> <li>Fix error message (by <a href="https://github.com/admosity"><code>@​admosity</code></a>).</li> </ul> <h2>7.0.31</h2> <ul> <li>Use only the latest source map annotation (by Emmanouil Zoumpoulakis).</li> </ul> <h2>7.0.30</h2> <ul> <li>Fix TypeScript definition (by Natalie Weizenbaum).</li> </ul> <h2>7.0.29</h2> <ul> <li>Update <code>Processor#version</code>.</li> </ul> <h2>7.0.28</h2> <ul> <li>Fix TypeScript definition (by Natalie Weizenbaum).</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/postcss/postcss/commit/67e3d7b3402c5d3d036ab7c1e781f86910d6ca72"><code>67e3d7b</code></a> Release 7.0.36 version</li> <li><a href="https://github.com/postcss/postcss/commit/54cbf3c4847eb0fb1501b9d2337465439e849734"><code>54cbf3c</code></a> Backport ReDoS vulnerabilities from PostCSS 8</li> <li><a href="https://github.com/postcss/postcss/commit/12832f3d203474bd273bd06bd3b2407567bfe09e"><code>12832f3</code></a> Release 7.0.35 version</li> <li><a href="https://github.com/postcss/postcss/commit/4455ef6baf84ceea87cb662131f95d798063896c"><code>4455ef6</code></a> Use OpenCollective in funding</li> <li><a href="https://github.com/postcss/postcss/commit/e867c794b5d646839350dd4b76f3cc81423413e6"><code>e867c79</code></a> Add migration guide to PostCSS 8 error</li> <li><a href="https://github.com/postcss/postcss/commit/32a22a98bc4de9c7a2489041ceae24eedc62144f"><code>32a22a9</code></a> Release 7.0.34 version</li> <li><a href="https://github.com/postcss/postcss/commit/22939829688574b9acdbd29106ca2ec9470b2b17"><code>2293982</code></a> Lock build targets</li> <li><a href="https://github.com/postcss/postcss/commit/2c3a111a940b373a60fae196e63931b3b6e9d8ca"><code>2c3a111</code></a> Release 7.0.33 version</li> <li><a href="https://github.com/postcss/postcss/commit/4105f21b48d75847e822e89746633792c478922b"><code>4105f21</code></a> Use yaspeller instead of yaspeller-ci</li> <li><a href="https://github.com/postcss/postcss/commit/c8d02a0da503f9fa5d96a854a2c9244710c18c72"><code>c8d02a0</code></a> Revert yaspeller-ci removal</li> <li>Additional commits viewable in <a href="https://github.com/postcss/postcss/compare/7.0.27...7.0.36">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+1 from me