Hi,

I'm trying to build the image locally with the command docker build -t rustpad .. However it exits with the following error:

=> ERROR [wasm 6/6] RUN wasm-pack build --target web rustpad-wasm                                                                                                                                                                                                                                                                                                                                                   187.6s
------
 > [wasm 6/6] RUN wasm-pack build --target web rustpad-wasm:
#15 187.5 Error: Error during execution of `cargo metadata`:     Updating crates.io index
#15 187.5 
------
executor failed running [/bin/sh -c wasm-pack build --target web rustpad-wasm]: exit code: 1

Any clues how this could be solved? Thanks!

Hey!

Given the technologies used in this project, and that I already run code-server just fine on it, this should be running just fine on an Raspberry-Pi (at least versions >=3).

With that in mind, and seeing that the official Docker-Image just works on amd64, I cloned the repository and tried around a bit.

Btw, from what I've seen its a nice code-basis. The tsx-Code (the JS part of the frontend) could use a few folders but otherwise real nice, insofar as I'm a good judge of that.

Well, I saw some good and some problematic stuff, but the problematic stuff should be possible to work around. The good stuff is that rustpad-server builds just fine.

The problem is that wasm-pack seems to REALLY not like arm64. I was able to fix some issues by installing wasm-pack via cargo install instead of the install script, and switching from rust:alpine with musl to the debian based rust:latest. After this (and loong build-times, even on my raspi 4 with an SSD, but thats Rust) it failed because of another binary wasm-pack looking for AFTER most of the compilation of the project - not wasm-pack but your rustpad-server-, wasm-opt. Now, I could fix that too, and I think it should be fine after this - I guess this does some kind of link-time-optimization? -, but I'm unsure what influence that might have on performance, and given how long it took to get here to start, and that this should be avoidable (see later), I think it would be great to solve this on an project-level.

Because given that the purpose of that step is to generate some architecture-independent wasm-"binary", and Rusts excellent cross-compilation support, I'm sure there is a way to just create

1. the architecture-independent wasm, js etc artifacts
2. and the architecture-dependent binary

In your pipeline and either at least distribute these artifacts, or better yet find a way to make the pipeline build an arm64 docker-image that also gets distributed via docker-hub.

After all once you have these artifacts all thats left to do is copy these into the image, switch the user and declare the entrypoint, all that in a simple "scratch" container.

Now, the reason I post this here, and don't just do it and make a PR, is that

1. I have no experience with docker-multiarch etc, so if someone has some comments on this/wants to help I'd love that
2. This would influence the pipeline quite a bit, and I wanted to check with you that such changes would even be accepted/ generally hear what your feeling is about all this.

Sam.

It appears that the current implementation keeps the state table in volatile memory (RAM) rather than committing it to disk. As such, deploying this in a scenario where the service's lifetime is not guaranteed (container orchestration, e.g. kubernetes) the state would be lost in an eviction scenario.

It would be nice if there was a way to offload the state table into a somewhat more persistent datastore or use something like sqlite with a pvc in kubernetes to help maintain state.

Would solve #36. Most things seems to work as intended, very sparse detection of languages for now, a few questions are open, and I think the amount of code in App.tsx asks for a refactor, moving out code.

I would love to use rustpad for my hardware live coding project. Is it possible to connect a third-party client via WebSocket to rustpad? If you can point me to any examples or resources it would be great.

Thank you.

Hey!

I saw that rustpad has fixed values for the cleanup intervals:

https://github.com/ekzhang/rustpad/blob/64d0b632ac72143c4e94fce1ecaf5db94bb90547/rustpad-server/src/lib.rs#L82-L83

I think it would be nice to make them configurable via dotenv or any other solution. Do you think it's applicable? If so, I'd like to submit a PR.

Hi, I really love your application because it's simplicity. The application works great on large screen devices like computers and tablets. However, when I open it using my phone (iPhone 7), the left panel seem to cover all the screen that users like me can not see the text content. Do you have any plan to add Mobile Responsive in the future?

Thank you and stay safe!

Hey, I've used this Application a bit now, and I've got a few ideas.

As my Exams are coming up I will not be able to contribute much to these, but I wanted to record them here nonetheless.

First there were 2 things that I wondered about, that were already addressed, or likely out of scope, and that are persistent files/sessions (so it can work as a kind of pastebin) (it seems #6 addresses that), and multi-file workspaces are probably widely out of scope.

But I had another thought that should not be too hard to implement, and IMO would significantly increase ergonomics.

"File"-Upload and Download does not seem to be implemented, unless I missed it. The way I imagine it, is that one would be able to "Upload" a text-file via drag and drop, this would just paste in the content, and ideally also determine the Programming-language via file-extension. To download, I've seen websites that intercept the Ctrl-S command to save files (eg drawio). I'm not actually sure how they do it, but it appears there is a way, and that would be ideal IMAO.

Thanks, Sam.

Not a bug, but a feature request. I LOVE the editor abilities of this, but would like the option to share it as read-only. I suppose an approach to having this work so that the author can still make changes, is perhaps a new link that references the original "tag", but is one that, when de-referenced, renders the code in a read-only console.

Or, if it can generate a new link "tag", of which it's read only? Not sure how it's implemented internally but either way, I would love this option if considered. Thanks.

When using this I've stumbled upon an issue. I'm not sure if my suggested fix is actually always a good idea, or how easy it would be to solve, so this should probably be discussed.

If multiple persons work in different areas of a file, this can lead to conflicts, when the person that is closer to the beginning of the file inserts/deletes newlines, or with both in a single line just when it enters anything.

Because this will not change the position of the cursor of the other person in the file, meaning its cursor will move in relation to the context the person was working on, since that context is indirectly moved by the other person.

This can be fairly disrupting, if one was currently writing something, it might be spread over multiple lines or be... interlaced with the past characters.

The fix would be to move the cursor accordingly, depending on its current position. If its on the same line and past the other cursor, it has to be moved forward, if its simply below, it has to be moved down, if its above or generally before the other cursor, it doesn't get influenced.

Changes

• Add multi-platform build to the CI pipeline, currently specifying linux/amd64,linux/arm64 QEMU targets.
• Specify amd64/ prefixes for the frontend build stages to avoid wasm-pack compatibility failures.

This fixes #31. It should allow ARM users to pull the image from Docker Hub.

The only downside is that this will probably make the CI / build step about twice as slow, but that seems like a reasonable tradeoff to me. Thanks GitHub for sponsoring free Actions time for public repositories. :)

It seems like when using Sqlite to retain pads beyond the memory storage limit they are stored indefinitely?

Would it be possible to add some configuration option to discard old pads after 30 days or so from the Sqlite storage?

Thanks!

Really nice project by the way!