-
Notifications
You must be signed in to change notification settings - Fork 7
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
Conversation
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:
|
Hey @ianthehenry! Thanks for the feedback, I'll reply to each comment inline:
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
I think the "right way" to do that would be for you to
Ok, I'll make that change, and test that nothing breaks on Linux.
Also learned that yesterday as well! It's very convenient to easily iterate on the CLI args
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.
Fair enough, I'll revert the hashbang, should I revert the
Indeed, in my SvelteKit version I'm using Cheers! |
BTW, as part of the process of getting it deployed on Vercel, I published 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. |
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.
Yeah, I think I'd just drop that commit altogether. There's a lot more to making the script POSIX compatible (no
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...
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. |
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.
Ok, I removed it. I did test using bash in
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
I had other, more cumbersome alternatives, such as just committing the generated |
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? |
Hi, FWIW, I love the idea of using Svelte with this project. Can we revive this PR? Can I help? |
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? |
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... |
@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 :) |
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. ;) |
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.