Implementing Runno

[LukePrior]

Hi Ben,

I just wanted to thank you for the wonderful and prompt support that you have offered.

My current prototype

I'm just having a look at your example currently and must say they look very nice, I am going to look into implementing the code marking features that you have also displayed as I think these would be helpful.

You can find my very basic prototype here: https://comp1511-guide.vercel.app/ (running on Vercel so that the headers work)

Styling Ideas

I think I will redo my page to follow the same layout as your example so I have a good base to build from.

The main problem I'm running into currently is the styling issue when code in the editor is longer than the allocated space.

This is how it looks with the default inputs on your site:

The problem occurs when too many lines of code are entered:

The total element size remains the same but the terminal shrinks to accommodate the increased lines of code. I would like the ability to set the total element height and the height of the terminal, the code editor should show a scrollbar if it all cannot be displayed however the current behaviour is this:

I'm sure you agree that this isn't the best way to handle this so I suggest that you update the CSS for runno-editor to enable overflow:auto. This results in the previous scenario becoming:

This is only marginally better with the element now keeping its specified height however the terminal needs some more formatting so that it is always positioned correctly. I have found that this is most easily done by giving runno-terminal a CSS height style of above 15px. This results in the following:

This is now reaching a point which I believe to be very useable but I think the scrollbars for the code editor and terminal could do with some more styling. Not too sure on what to do for this so I will leave that to your discretion.

Thanks,
Luke

[taybenlor]

Thanks Luke, yeah I'd like to get a solution that works well for a web component, and also works well in the iframe. You can see that with the iframe version the editor collapses and starts scrolling:

The iframe is just a <runno-run> element set to a height and width of 100%. So I need to figure out what is different that causes the alternate behaviour outside of the iframe.

[taybenlor]

PS: Would love to hear more about your use case. Looks like it's for a programming course?

[taybenlor]

I've improved the default styling of the web component so that the terminal has a minimum height, and the editor resizes nicely. This means it's not necessary to set a fixed height on the web component. If you do set a fixed height the two areas will share the space 60:40. There was also a bug I fixed in the styling of the editor that made it take up more than its fair share of space.

The change is in #189

I'll cut a release soon as well.

[taybenlor]

These changes are available in @runno/runtime:0.3.1 and documented at https://runno.dev/#component-elements

[LukePrior]

Thanks, they were just the thing I was looking for!

[LukePrior]

I'm not sure if I'm just doing this wrong or if it's a bug but when I edited your example to use clang instead of Python I'm running into an error with the check code examples:

const { result } = await provider.headlessRunCode("clang", program, stdin);

I get the following error when the above code is run:

runtime.es.js:9 Error: No such file or directory: ./program.wasm

[taybenlor]

That looks like the code didn't successfully compile (the program.wasm is output by clang). What happens if you run the code normally? (not headless)

[LukePrior]

The code is just a simple Hello World and runs correctly when run normally.

[taybenlor]

Okay that sounds like it's a bug with the way headless running works. I can look at fixing that later (probably won't be tonight).

A workaround would be to run each of the clang steps manually. You'll need to look at provider.ts inside the runtime package to see how it works.

Basically the idea is to run each of the following steps:

prepare: [
        `clang -cc1 -Werror -triple wasm32-unkown-wasi -isysroot /sys -internal-isystem /sys/include -ferror-limit 4 -fmessage-length 80 -fcolor-diagnostics -O2 -emit-obj -o ./program.o ${entryPath}`,
        `wasm-ld -L/sys/lib/wasm32-wasi /sys/lib/wasm32-wasi/crt1.o ./program.o -lc -o ./program.wasm`,
],
run: `wasmer run ./program.wasm`,

You can do that by using headlessUnsafeCommand, collecting the fs which is returned and then passing it to the next command.

The bug will be happening because the fs is not being passed between steps in this process.

[LukePrior]

No rush, just something I stumbled upon during testing.

[taybenlor]

Could you file this as an issue? That'll help me keep track of it.

[LukePrior]

I've also encountered an issue with detecting EOF (Ctrl D) as the web terminal doesn't seem to register this like a normal terminal would.

You can see the behaviour here.

Do you know of any solutions or workarounds, I can't really change the code as it needs to be the same as what runs normally.

[taybenlor]

Thanks, yeah okay I think this should be possible. I can't think of a workaround the way things work currently. I'll need to add a handler specifically for ctrl + D and end the interactive capture of STDIN.

[taybenlor]

Can you file this as an issue?