[wasm] write test as single line via base64

[pavelsavara]

No description provided.

[radical]

What kind of errors is this guarding against? Invalid xml only? We should catch those specific exceptions then.

[radical]

Oops, forgot to submit!

[pavelsavara]

After the last observation I realized that

• we still have multiple lines of console.log and therefore WS send with STARTRESULTXML and ENDRESULTXML on separate lines.
• we still have multiple lines because xml file could contain <![CDATA[some \n stuff]]>

Therefore I made it really one line, which also simplified dealing with race condition (with lines from Chrome DevTools Protocol) on receiving side.

[radical]

Were you able to reproduce the issue locally? And does this fix it?

We should probably come up with a better way of doing this. Can we read files from the VFS after the app exits, but the page is still open?

[radical]

The results file for System.Memory.Tests is ~12MB, which becomes ~16M in base64. If @lewing's dotnet/runtime#61854 works, with a chrome update from dotnet/runtime#61856 , then we should use that, and write lines as we did earlier.

[pavelsavara]

The results file for System.Memory.Tests is ~12MB, which becomes ~16M in base64. If @lewing's dotnet/runtime#61854 works, with a chrome update from dotnet/runtime#61856 , then we should use that, and write lines as we did earlier.

I commented on 61854, I doubt it would help.

I think that 16MB should be fine. The ugly part is that emscripten stdout will do put_char on all of that, but we already have this problem and I only made it slightly worse.

If we get back to writing multiple lines, we need to prevent the race condition with lines from "chrome devtools protocol" by other means. My previous adding isWebSocket is one possible way.

[pavelsavara]

Were you able to reproduce the issue locally?

No, not yet. Were you ?

We should probably come up with a better way of doing this. Can we read files from the VFS after the app exits, but the page is still open?

The shell JS like V8 doesn't have this issue as far as I could tell.

For the browser, we could replace this with HTTP POST to xharness web server and save it there.
It would avoid all the contention and also all the buffering of stdout.
I'm not sure what would it take to bring HttpClient as new dependency of ThreadlessXunitTestRunner

on request

[maraf]

For the browser, we could replace this with HTTP POST to xharness web server and save it there.
It would avoid all the contention and also all the buffering of stdout.
I'm not sure what would it take to bring HttpClient as new dependency of ThreadlessXunitTestRunner

I really like this HTTP idea.

[radical]

For the browser, we could replace this with HTTP POST to xharness web server and save it there.
It would avoid all the contention and also all the buffering of stdout.
I'm not sure what would it take to bring HttpClient as new dependency of ThreadlessXunitTestRunner

I really like this HTTP idea.

we could even write it back over a different web socket, if we want to avoid using HttpClient.

[pavelsavara]

The problem is in how to get out of wasm into JS. In JS the http is the easy part.
Currently we are abusing stdout.
Instead C# httpClient we could also recognize the pattern in JS at same place we have WS proxy and POST it from there.

I would merge this one so that we could iterrate with testing in in CI and will create another PR exploring this idea.

[pavelsavara]

we could even write it back over a different web socket, if we want to avoid using HttpClient.

I would like to avoid using C# HttpClient because I don't want to force the DLL dependency on all users of ThreadlessXunitTestRunner. On the other hand abusing stdout is no great either.

[pavelsavara]

I realized that we could combine multiple ideas.
@radical mentioned VFS.
We could use it to get data into JS and then we collect it via JS and upload with HTTP POST.

[radical]

We could call a js function which would return the contents of the file from the VFS, or we could write that to some dom element, and read it from XHarness. We connect through selenium, so we can "talk" to the page.