IRC channel logs
2025-01-03.log
back to list of logs
<Zarutian_iPad>I hate Java mainly due to three things: class inheretence, no _methodMissing or equiv, and type ereasure. <dthompson>my last job was ruby primarily. for single dispatch oop it's decent. <Zarutian_iPad>look compiler, if you can not gurantee that a var/arg/return-val is of a type at compile time then emit a type check code there instead of just giving up. <jlicht>sneek: later tell dthompson: Working on getting the node@22 patches functional again + polished up for inclusion in guix; is it okay if I CC you too for some (spritely-related) testing? <dthompson>jlicht: I would love to be CC'd on that. happy to test! <sneek>Welcome back dthompson, you have 1 message! <sneek>dthompson, jlicht says: Working on getting the node@22 patches functional again + polished up for inclusion in guix; is it okay if I CC you too for some (spritely-related) testing? <dthompson>the call stack overflow issue was particularly funny, for some definition of funny <dthompson>it was a death spiral of endlessly raising exceptions until the wasm runtime's call stack blew up <dthompson>for now we just have bleeding edge packages for goblins and hoot <dthompson>but in the future we can also provide demos/apps that we build <jlicht>TIL you could have non-gpl guix channels <cwebber>sure, they just have to be GPL compatible <cwebber>the combined work is effectively under the terms of the GPL <jlicht>ACTION is not a lawyer, and would prefer keeping it that way ;-) <cwebber>ACTION worked for Creative Commons ;) <cwebber>not as a lawyer, but I did some licensing things <cwebber>I kicked off the CC BY-SA 4.0 and GPL 3.0 compatibility efforts <cwebber>and took CC0 1.0 through the FSF and OSI licensing efforts and saw it explode in our faces in the latter category (for semi-good reasons) <jfred>ooh, spritely guix channel is nice <jfred>I love how straightforward it is to make guix channels <jfred>I've got an internal one for work-related software that isn't (or isn't yet) suitable for upstreaming <jfred>it can be a bit of a pain to ensure that packages in a separate channel continue to build as things change in another channel yours depends on though. I wonder if there's a way to have the packages in a custom channel depend on packages from e.g. an inferior of the guix channel <jfred>(though of course that would make using the custom channel for the first time much slower if it's even possible) <dthompson>though it introduces the situation where you have multiple channels depending on different versions of a shared dependent channel <jfred>yeah. that's potentially messy. but it does mean that a specific commit of a channel could refer to a precise version of both the packages in that channel and their dependencies, even if the latter are in another channel <jfred>which is I think how I expected guix to handle channels when I first learned about them, and how they actually work feels looser than I expected haha <weary-traveler>cwebber: when you say "they just have to be GPL compatible", you mean the third-party channel not the packages therein, correct? <dthompson>when I contrast that with just snarfing the package recipes you need to be stable I think I prefer the snarf approach <dthompson>for the first draft of the packages in our channel, I inherited from the ones in guix. then I thought about it a moment and changed them to be standalone. <dthompson>weary-traveler: yeah the code for the channel <dthompson>like when you combine the channel code + the official guix code the sum is gpl <cwebber>more accurately, the terms of requirements for compliance are gpl <cwebber>part of the reason we're using ASL2 is that it's what we use for everything, and we do "surprise reuse" a lot of code across components