A few things that come to mind

1. Show commands spawned by ncu
2. Show HTTP request response, in particular responses that could not be parsed as JSON (e.g. when Jenkins authorization fails, it returns XML)
3. Pipe stdout and stderr, also do not use spinners if verbosity is on in case the output is overwritten

The wasmtime repo's WASI test suite uses Rust as the source language, which fails by panicking. It will print messages to stdout and eventually hit the unreachable opcode. Our test harness captures guest stdout and stderr, and prints any of them that are non-empty when the instance traps.

This doesn't do you much good if your implementation doesn't have basic stuff like writing to stdio working, but in my experience that is usually the first thing you get working.

If we could bundle additional files with the tests and were allowed to use these files in <basename>.arg (or even statically in the test, I guess), that would seem easiest. What do you think?

You could but this also introduces a lot of extra unrelated dependencies in your tests that can be avoided.

Different toolchains have different mechanisms for it but it can be quite trivial to embed the data. In Rust for example one could use the include_bytes macro.

const model_1 = include_bytes!("model_1.tensor")

Other toolchains have their ways too.

One open ended question is how do we handle printing diagnostics to the test runner.

Assertions which just call unreachable aren't that great but it It would be preferable to NOT depend on output_stream in every single test to print the failure before aborting.

extend\F{_}\sx isn't an operator, but extend_\sx is.

@nodejs/next-10 would be great to get a review so that I can land this.

Time

UTC Thu 21-Jan-2021 16:00 (04:00 PM):

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Next%2010%20Years%20team+Meeting+2021-01-21&iso=20210121T1600
• or https://www.wolframalpha.com/input/?i=04PM+UTC%2C+Jan+21%2C+2021+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1_CT2pybgWqwVdZiNCAy590kGjxFqDmhPQVelyqpi584/edit

Agenda

Extracted from next-10-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/next-10

• Key Technical Areas - Brainstorm to generate list #39
• Needs/want of constituencies #20
• Next 10 years for collaborators #16
• Revisit time slots #13

Invited

*Next 10 years team: @nodejs/next-10

Observers/Guests

Notes

The agenda comes from issues labelled with next-10-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/99950131676

• For those who just want to watch: We stream our conference call straight to YouTube so anyone can listen to it live, it should start playing at https://www.youtube.com/c/nodejs+foundation/live when we turn it on. There's usually a short cat-herding time at the start of the meeting and then occasionally we have some quick private business to attend to before we can start recording & streaming. So be patient and it should show up.

• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

PR for minutes: https://github.com/nodejs/next-10/pull/44

Signed-off-by: Michael Dawson mdawson@devrus.com

One of the next steps in addition to discussing in the next meeting: https://github.com/nodejs/next-10/issues/43

@darcyclarke just went to look at adding the picture,very happy to see it already there, thanks!

Possible approach

• Create copy of the board we created today
• Tweet/promote asking people to add in their own thoughts.
• Compare results and incorporate what we've missed.

Time

UTC Thu 21-Jan-2021 21:00 (09:00 PM):

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Technical%20Steering%20Committee%20(TSC)+Meeting+2021-01-21&iso=20210121T2100
• or https://www.wolframalpha.com/input/?i=09PM+UTC%2C+Jan+21%2C+2021+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1JkI1rPLBvzgAVvezcHCYSmgbX6nflnw_JMNs77toAAE/edit

Agenda

Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/node

• TLS: improve compliance with shutdown standard, remove hacks #36111
• Rename default branch from "master" to "main" or something similar #33864

nodejs/docker-node

• Publish packages to GitHub Registry #1410

nodejs/TSC

• any interest in an RFC process? #962

nodejs/security-wg

• Potential stagnation of open issues on h1 bounty program #654

Invited

• Anatoli Papirovski @apapirovski (TSC)
• Beth Griggs @BethGriggs (TSC)
• Ruben Bridgewater @BridgeAR (TSC)
• Сковорода Никита Андреевич @ChALkeR (TSC)
• Colin Ihrig @cjihrig (TSC)
• Shelley Vohr @codebytere (TSC)
• Daniel Bevenius @danbev (TSC)
• Franziska Hinkelmann @fhinkel (TSC)
• Gabriel Schulhof @gabrielschulhof (TSC)
• Gireesh Punathil @gireeshpunathil (TSC)
• James Snell @jasnell (TSC)
• Joyee Cheung @joyeecheung (TSC)
• Mary Marchini @mmarchini (TSC)
• Matteo Collina @mcollina (TSC)
• Michael Dawson @mhdawson (TSC)
• Myles Borins @MylesBorins (TSC)
• Michaël Zasso @targos (TSC)
• Tobias Nießen @tniessen (TSC)
• Rich Trott @Trott (TSC)

Observers/Guests

Notes

The agenda comes from issues labelled with tsc-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

Zoom link: https://zoom.us/j/611357642 Regular password

Public participation

We stream our conference call straight to YouTube so anyone can listen to it live, it should start playing at https://www.youtube.com/c/nodejs+foundation/live when we turn it on. There's usually a short cat-herding time at the start of the meeting and then occasionally we have some quick private business to attend to before we can start recording & streaming. So be patient and it should show up.

Many of us will be on IRC in #node-dev on Freenode if you'd like to interact, we have a Q/A session scheduled at the end of the meeting if you'd like us to discuss anything in particular. @nodejs/collaborators in particular if there's anything you need from the TSC that's not worth putting on as a separate agenda item, this is a good place for that.

Invitees

Please use the following emoji reactions in this post to indicate your availability.

• :+1: - Attending
• :-1: - Not attending
• :confused: - Not sure yet

We cancelled as we did not have enough attendees this week.

Yes, any decisions that affect float precision/behavior should be baked into the Wasm module by the tools. New instructions can be added for behavior that cannot be expressed with the current ones.

Another reason to embed any data the test needs to that it avoid the dependency on the filesystem API, making the test more precise and less fragile. It should be fairly straight forward to embed data in wasm, I think there are a few different ways you can do this if you are using an llvm-based toolchain.

Link/reference to the funretro board we put together here: https://easyretro.io/publicboard/cLBIBu3wA2Um7qIziXq1zmC4gdi1/f2334393-fe0f-4202-8ee5-0ef677e0ff9e

Github tooling is in place to do this. Unless there are objections I'll go ahead and do it.

Once we do that we should also do for node-addon-api

Any progress on this?

Depends on the previous question but probably just define some fuzzy asserters in the source language. Internal logic should be handled internally IMO.

Sounds good.

I'm not sure what wasi-nn needs, not that familiar with the proposal but seems it just loads models from memory?

That's right but, practically speaking, those models/weights/tensors are large and are easier to manage as separate files than static data sections in a compiled Wasm file. It's not an exact corollary, but in an example over in Wasmtime I load this data from files before using them in wasi-nn. If we could bundle additional files with the tests and were allowed to use these files in <basename>.args (or even statically in the test, I guess), that would seem easiest. What do you think?

Agenda: TBD based on related issue below

Facilitator: @tobie @SaraJo @joesepi Related issue(s): #699 Doodle link: N/A Date: 2012-01-26 1700 UTC Zoom link: https://zoom.us/j/91398697172?pwd=QVgxRUFXdmtHVUNiODhoSU11ejF0QT09

Please wait for your meeting to be added to the OpenJS Foundation calendar before using the Zoom meeting. If there are two conflicting meetings, please note that the meeting on the calendar takes precedence.