Skip to content
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

Tweak build script #5

Closed
wants to merge 6 commits into from
Closed

Tweak build script #5

wants to merge 6 commits into from

Conversation

jpaquim
Copy link
Contributor

@jpaquim jpaquim commented Nov 17, 2022

Hey @ianthehenry, first of all great work on the project!

I've been tweaking the build script a bit, fixing a couple of issues I was having with running it on macOS, and a few minor nitpicks.

Feel free to revert any of it, in particular 57109a0 as I know POSIX compatibility is probably not a relevant concern.

Also, let me know if you prefer keeping the options as --js-only, --wasm-only, --html-only, I was on the fence given the slight difference between what was described on the README, and the implemented flags.

@ianthehenry
Copy link
Owner

ianthehenry commented Nov 18, 2022

Oh hi! You have stumbled onto a very strange shell script that just kept growing long after it should have morphed into something else.

I have to sheepishly admit that I am not very good at GitHub, and I don't know how to effectively collaborate on a pull request from a remote repository. There are some things that I would change here, and the workflow that I am used to normally is that I would just make those changes and push them and we could review them together, but I don't actually know how I can do that without pulling your branch directly, making changes, and pushing them myself, bypassing this pull request altogether.

So instead I'm just going to say words:

  • Overall most of this is just uncontroversially good, so thanks for that!
  • I think that we should just use shasum unconditionally; I don't think there's any reason to favor sha256sum
  • TIL you can for without an in. I wonder why I was shifting before. That's weird isn't it.
  • I think you have to set build_html=true when rebuilding --wasm or --js, or else the new fingerprinted scripts won't actually be linked from the <head>. I think build_html is basically instantaneous so this is not really a bad thing.
  • When you rebuild --wasm, I think that you still have to rebuild the JS files in order to link the generated module into the final typescript bundle. I don't think there's a way to do that incrementally. I'm pretty sure this is why I took that flag out and then forgot to update the README.
  • I would prefer to keep the script in bash, because although this script happens to be pretty tame right now I don't want to have to think twice about reaching for bash-isms in the future.
  • I just realized I never documented the fact that I added a dependency on pandoc. Whoops.
  • I haven't done anything to promote Bauble in a while and I'm kind of curious how you heard about it / why you decided to hack on it, if you wanted to share.

@jpaquim
Copy link
Contributor Author

jpaquim commented Nov 18, 2022

Hey @ianthehenry! Thanks for the feedback, I'll reply to each comment inline:

I haven't done anything to promote Bauble in a while and I'm kind of curious how you heard about it / why you decided to hack on it, if you wanted to share.

I first saw Bauble back in September, a friend sent me the reference. It was a bit love at first sight, I am very into Lisps and was starting to dive deeper into Janet at the time, and I just love SDF-based graphics stuff (i.e. magic). I went to my first demoscene party a few weeks ago, and since then have been itching to work on a demo to submit next time, and Bauble seems like a good candidate to use as a basis for the graphics.

As an experiment, yesterday I started to work on a Svelte version of the UI code here: https://github.com/jpaquim/svelte-bauble (deployed here: https://svelte-bauble.vercel.app)

The Solid to Svelte migration ended up being much easier than I was anticipating, it should already match what's available in Bauble, including the /about and /help routes. I'm using Svelte stores as an equivalent of the Solid signals you used, but in practice it can still be simplified quite a lot by instead using Svelte's reactive variables.

There are some things that I would change here, and the workflow that I am used to normally is that I would just make those changes and push them and we could review them together, but I don't actually know how I can do that without pulling your branch directly, making changes, and pushing them myself, bypassing this pull request altogether.

I think the "right way" to do that would be for you to git remote add jpaquim https://github.com/jpaquim/bauble and then push to my main branch directly. Given that I checked "allow edits by maintainers", GitHub should validate that the push is ok.

I think that we should just use shasum unconditionally; I don't think there's any reason to favor sha256sum

Ok, I'll make that change, and test that nothing breaks on Linux.

TIL you can for without an in. I wonder why I was shifting before. That's weird isn't it.

Also learned that yesterday as well! It's very convenient to easily iterate on the CLI args

I think you have to set build_html=true when rebuilding --wasm or --js, or else the new fingerprinted scripts won't actually be linked from the . I think build_html is basically instantaneous so this is not really a bad thing.
When you rebuild --wasm, I think that you still have to rebuild the JS files in order to link the generated module into the final typescript bundle. I don't think there's a way to do that incrementally. I'm pretty sure this is why I took that flag out and then forgot to update the README.

True, I was wondering how to best approach these problems, on how to keep the rest of the "build pipeline" happy when something upstream changes. I'll try to think of a better way, I think it will help to modularize these top-level steps into functions, make it all a bit more manageable.

I would prefer to keep the script in bash, because although this script happens to be pretty tame right now I don't want to have to think twice about reaching for bash-isms in the future.

Fair enough, I'll revert the hashbang, should I revert the [ conditionals as well?

I just realized I never documented the fact that I added a dependency on pandoc. Whoops.

Indeed, in my SvelteKit version I'm using marked to do the .md -> .html conversion, it's comparatively slimmer when compared to pandoc. I still need to find a way to generate the table-of-contents though.

Cheers!

@jpaquim
Copy link
Contributor Author

jpaquim commented Nov 18, 2022

BTW, as part of the process of getting it deployed on Vercel, I published bauble-runtime as an npm package here: https://www.npmjs.com/package/bauble-runtime

Based on this branch: https://github.com/jpaquim/bauble/tree/package-json

Let me know if this is ok with you, I can definitely help out with the maintenance of the package.

@ianthehenry
Copy link
Owner

I went to my first demoscene party a few weeks ago, and since then have been itching to work on a demo to submit next time, and Bauble seems like a good candidate to use as a basis for the graphics.

Oh neat! Let me know if you make something; I love seeing things that people do with Bauble. I've been meaning to add a gallery submission thing, but I just haven't had any cycles for Bauble lately.

I have a couple in-progress branches to add custom resolutions, anti-aliasing, and mp4 export. But they've kinda just been languishing for a while. I don't know if any of that is useful for demo stuff.

Fair enough, I'll revert the hashbang, should I revert the [ conditionals as well?

Yeah, I think I'd just drop that commit altogether. There's a lot more to making the script POSIX compatible (no set -o pipefail for example, = instead of ==, probably lots of other trivia that I can't remember) and I'd rather just lean into all the good bash features.

Ok, I'll make that change, and test that nothing breaks on Linux.

Oh yeah I should have mentioned -- I actually tested it on Linux before I wrote that.


Your Svelte port is very impressive! I poked around and couldn't find any difference with the original UI. I don't know anything about Svelte but maybe diffing these two would be a good way to learn. (I had never used SolidJS before this project, so I'm not really attached to it, although I found it to be generally fine.) Not something I'll have time to look at for a while, though...

Let me know if this is ok with you, I can definitely help out with the maintenance of the package.

I have no objections to this. I've never heard of Vercel before, so I don't understand why it needs a published package, but regardless it seems fine. I don't think I want to maintain such a package officially yet -- I don't want to guarantee any sort of stability or commit to a versioning scheme for Bauble yet. But if you want to keep it updated I'm perfectly happy with that.

@jpaquim
Copy link
Contributor Author

jpaquim commented Nov 22, 2022

Oh neat! Let me know if you make something; I love seeing things that people do with Bauble. I've been meaning to add a gallery submission thing, but I just haven't had any cycles for Bauble lately.

I have a couple in-progress branches to add custom resolutions, anti-aliasing, and mp4 export. But they've kinda just been languishing for a while. I don't know if any of that is useful for demo stuff.

Will do! Still thinking on how to best approach it, whether to try to do the full sequencing within Bauble, or somehow export the individual shaders and sequence them using JS. As for the features you mentioned, they would all be welcome, let me know if I can give a hand somehow.

Yeah, I think I'd just drop that commit altogether. There's a lot more to making the script POSIX compatible (no set -o pipefail for example, = instead of ==, probably lots of other trivia that I can't remember) and I'd rather just lean into all the good bash features.

Ok, I removed it. I did test using bash in --posix mode and it was working well, but I did not test with other stricter-than-bash POSIX shells.

Your Svelte port is very impressive! I poked around and couldn't find any difference with the original UI. I don't know anything about Svelte but maybe diffing these two would be a good way to learn. (I had never used SolidJS before this project, so I'm not really attached to it, although I found it to be generally fine.) Not something I'll have time to look at for a while, though...

Thank you! I've cleaned it up quite a bit today, using reactive variables instead of Svelte stores, and a few other details like using let-over-lambda style instead of classes. Take a look and let me know what you think of it, I was also thinking of maybe using the emscripten npm package to try and simplify the build process, make it self-contained within node. If any of this is interesting to you as well, I can open a PR to upstream it 🙂 I find Svelte incredibly fast to work with, give a spin and see how you find the dev experience when compared to Solid.

I have no objections to this. I've never heard of Vercel before, so I don't understand why it needs a published package, but regardless it seems fine. I don't think I want to maintain such a package officially yet -- I don't want to guarantee any sort of stability or commit to a versioning scheme for Bauble yet. But if you want to keep it updated I'm perfectly happy with that.

I had other, more cumbersome alternatives, such as just committing the generated out/janet.js bundle, or otherwise try to get the emscripten build correct on the Vercel pipeline. Publishing the package seemed like the simplest way though, in terms of versioning for now I was just using the rule of thumb that 0.0.* is a guarantee of lack of stability 😄

@ianthehenry
Copy link
Owner

ianthehenry commented Nov 29, 2022

Will do! Still thinking on how to best approach it, whether to try to do the full sequencing within Bauble, or somehow export the individual shaders and sequence them using JS. As for the features you mentioned, they would all be welcome, let me know if I can give a hand somehow.

There's a feature that I've been meaning to add to Bauble, which is that if your Bauble script returns a function, then Bauble will invoke it on every tick with the current timestamp (recompiling the shader afterwards if it returns a different shape). This would be quite slow/jerky when livecoding, but of course you wouldn't be able to tell in an offline video export.

But I started a new job a few weeks ago and I've just been very busy, and I don't know when I'll have time to implement that with the holidays coming up. I have a flight next week... that seems like a one flight project...

I think that I don't want to merge this branch until the rebuild flags build all the right things -- I like the instinct to make things call functions for the things they depend on. That happens to work optimally for this simple linear dependency graph, but in general I think I should just switch to something like make. I just... have never met a make-like thing that I didn't hate. Is there a good version of make?

@xrd
Copy link
Contributor

xrd commented Apr 11, 2023

Hi, FWIW, I love the idea of using Svelte with this project. Can we revive this PR? Can I help?

@jpaquim
Copy link
Contributor Author

jpaquim commented Apr 11, 2023

Hey @xrd! Thank you for the feedback, I can update my Svelte version and open a PR for it if there's interest in it, @ianthehenry what do you think?

@ianthehenry
Copy link
Owner

Hey! I think this particular PR is a little bit outdated -- I completely rewrote the Bauble build system since this was opened so that it's not just a giant hacky shell script anymore, so I don't think it makes sense to merge this.

But on the Svelte rewrite -- I am still open to switching to Svelte, but I don't know Svelte, and I haven't had time to learn it :) I'm doing some front-end work at my job now in yet another new framework, and I just haven't had the extra mental cycles to learn a fourth one in my spare time. I've been meaning to try adding some features to the Svelte port as a way to see if I like it, but the top priorities on my Bauble plate don't really involve the UI very much, and I haven't been giving Bauble very much attention lately anyway...

@jpaquim
Copy link
Contributor Author

jpaquim commented Apr 18, 2023

@ianthehenry I agree that this particular PR isn't relevant anymore, I'll close it.

On the Svelte port, I guess most of the concepts from Solid translate very well to Svelte equivalents, as they're both primarily based on reactivity primitives, so you shouldn't expect a significant friction from the framework change. It's more expressive and succinct in many ways when compared to other frameworks, but you do need to get used to the non-standard semantics implied by the injected reactivity, as well as the templating syntax.

I would gladly keep contributing if you'd like to collaborate on the UI code, and maybe @xrd would appreciate it as well. Let me know if I should bring the Svelte port up to date, and make it into a PR :)

@jpaquim jpaquim closed this Apr 18, 2023
@xrd
Copy link
Contributor

xrd commented Apr 18, 2023

I was just thinking of this PR. After some thinking I realized I should probably spend time learning solid before asking @ianthehenry to learn an entirely new JS toolkit! I need to put in the work before asking for a massive amount of work to be integrated and discussed.

@jpaquim I'm very interested in working on this with you in a private fork for now. Please let me know. We can even do it in Portuguese, but I'll be using my sotaque brasileiro. ;)

@jpaquim jpaquim mentioned this pull request Apr 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants