-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
include shell source instead of shell binary in boot #89
Milestone
Comments
Parzival-3141
added a commit
that referenced
this issue
Jan 25, 2024
Working towards #89 Target dependant imports (e.g. `jsutil` or `syscall/js`) should be placed in their own file, with a `//go:build` directive for the target platform. I also fixed the error handling logic to not ignore real errors.
progrium
pushed a commit
that referenced
this issue
Jan 25, 2024
* build: assert regexes will compile * build: attempt to fix toolchain issue Needs testing, will revert if it doesn't work. * build: attempt 2 at fixing toolchain thing Using `GOTOOLCHAIN=local` should disable downloading. * build: defer creating pkg until after successfully building the archive Prevents `pkg.zip` from lingering after build failure, creating a false positive in subsequent builds. * build: compile a single package instead of a single file Closes #87 Doesn't support subpackages yet, though it's certainly possible with this setup. * shell: fix `mv` description * build: include imports for shell and fix error printing Working towards #89 Target dependant imports (e.g. `jsutil` or `syscall/js`) should be placed in their own file, with a `//go:build` directive for the target platform. I also fixed the error handling logic to not ignore real errors. * fs: implement `/sys/tmp` as a `memfs` Closes #65 Closes #55 Changed `exportapp.sh` to use the temp directory instead of polluting `/sys/export`. * build: remove dead code
Parzival-3141
added a commit
that referenced
this issue
Feb 8, 2024
I needed to make some changes to initdata for #89, and in the process made it simpler. Now the list of files is in one place, and we always embed them into the bootloader. However, for debug builds we default to embedding just the filepaths instead of their contents, and fetching them at runtime. You still have the option of embedding the file contents by setting the `PROD` environment variable. This supports previous behavior while simplifying the codepaths.
Parzival-3141
added a commit
that referenced
this issue
Feb 8, 2024
…ctories Closes #88 Closes #89 I though it was a bit silly casting `s.fsys` everywhere, so I modifed `fs.go` to store the `watchfs` seperately. There was also an issue in `wasm.js:writeSync()` where it would be passed a null value for `buf` after the build tool finished in `proc.go:Spawn()`. I added a catch-all fix, but perhaps its a bug that the null is passed in the first place. There's still some kinks to work out before you can edit the shell seamlessly, namely using better heuristics for when files should be updated/rebuilt. We can use mtime/ctime for those.
progrium
pushed a commit
that referenced
this issue
Feb 8, 2024
* dev: refactor initdata I needed to make some changes to initdata for #89, and in the process made it simpler. Now the list of files is in one place, and we always embed them into the bootloader. However, for debug builds we default to embedding just the filepaths instead of their contents, and fetching them at runtime. You still have the option of embedding the file contents by setting the `PROD` environment variable. This supports previous behavior while simplifying the codepaths. * Embed shell source instead of binary and make spawn build source directories Closes #88 Closes #89 I though it was a bit silly casting `s.fsys` everywhere, so I modifed `fs.go` to store the `watchfs` seperately. There was also an issue in `wasm.js:writeSync()` where it would be passed a null value for `buf` after the build tool finished in `proc.go:Spawn()`. I added a catch-all fix, but perhaps its a bug that the null is passed in the first place. There's still some kinks to work out before you can edit the shell seamlessly, namely using better heuristics for when files should be updated/rebuilt. We can use mtime/ctime for those. * kernel: compare `mtime`'s when building source or copying files from `initfs` Closes #66 Enables proper live editing within Wanix! `proc.Spawn` will rebuild commands from source if it's been modified, and `kernel.fs` will copy in `initfs` files if they've been modified externally *(note this will overwrite local files inside Wanix)*.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This would allow us to edit and recompile the shell from inside Wanix!
The text was updated successfully, but these errors were encountered: