IRC channel logs
2023-12-06.log
back to list of logs
<banna>has anyone here studied pi-calculus at all? <cwebber>banna: I haven't studied it in depth... I remember my brother introduced me to it and I looked at it but didn't get far <ab5tract>hey all, just wanted to drop in and say that I've been digging into some videos from the Spritely team as well as the following the Hoot posts and I'm really impressed with what you all are doing <dthompson>ab5tract: hey, welcome! glad you're digging our stuff! :) <ab5tract>I do have a question though: what specific features make `emacs` a prerequisite for hacking with Goblins? <dthompson>ab5tract: because the geiser emacs extension is the best way to interact with a running guile process <cwebber>Strictly speaking, Emacs is not a requirement. However the reality is that at present Emacs is the only editor that has sufficient support for Guile hacking that we consider to deliver a good experience <dthompson>you don't *have* to use it, but we recommend it. <ab5tract>cweber: hey! I think we may have met years ago at an LGM in Toronto <ab5tract>yeah, that was a whole different goblin :) <cwebber>There's some work happening to add nrepl support and etc to Geiser <ab5tract>it's cool too see where that initial work has led... the potential for goblins is kind of wild <cwebber>That will let Goblins be used in a wider context <ab5tract>I don't know if you all have heard but Helix is adopting Steel Scheme as their extension language <cwebber>If you use the Racket version of Goblins, that has wider editor support and it's own excellent editor <cwebber>The Steel Scheme thing is funny to me <ab5tract>So that's a whole different lisp-y editor that is yet to be born <ab5tract>I'm curious to hear your thoughts on Steel <cwebber>Well, excited to have you here and enthusiastic ab5tract ! <dthompson>I just heard about Steel recently because it was on HN. <cwebber>ab5tract: I don't know much about it but it's entertaining to me because I wrote some posts that got popular a while ago called "Guile Steel" <ab5tract>dthompson: that's probably the same post where I learned about Helix adopting it <cwebber>It's interesting to see such a Scheme revival lately. I wonder if r7rs will become more critical <cwebber>I mean I know that saying that summons dpk ;) <jfred>I hadn't heard about Helix or Steel but I'd be curious what the module API might look like/if it could have a more capability-style API than emacs/elisp does <dthompson>helix and steel seem cool for people that are really into rust. for everyone else, I dunno. <dthompson>steel is an interpreter, not a compiler, and I think I read in the HN comments that it uses reference counting gc. <dthompson>the helix + steel architecture feels kind of old school, in a way. these days you could implement the entire text editor in scheme and call out to C libraries via FFI when you need to. <jackhill>I wonder if it's a history thing. They didn't start out to write it that way, but to write a rust editor, and then came up with a need for an extension language. I don't really know though, other than I had heard of Helix long before I know of Steel. <jackhill>cool it's scheme. I honestly would have expected Lua. <dthompson>jackhill: yeah that could be true. another project re-learns the lesson. <jackhill>ooo, I'd love an editor with a capability-style API over what emacs/elisp do! <ab5tract>I think Lua's shine has faded a bit for these extension language tasks <dthompson>luajit is still very good and the fact that lua's default environment is a safe sandbox are still good selling points. <dthompson>guile should have a "no capabilities by default" mode, too... shame that it doesn't have it. but we will address that at some point. ;) <dthompson>fennel is pretty neat. I'd use it if I were constrained to a lua environment. <jackhill>yep. technomancy's a pretty awesome human though <cwebber>The big thing that lua has going for it is löve <jackhill>lua's in so many places now. It's kind of entrenched like C++. We looked around us at work because someone asked about Lua's maturity (basically if they should invest time into it) and we saw it everywhere <cwebber>For most users they'll want a daemon that sets up everything for them rather than wiring everything manually <ab5tract>I encountered raylib and raygui recently.. it gives every dynamic language a chance to write cross-platform games (or GUIs .. or game/GUI libraries) once a binding generator is written. <ab5tract>not that it discounts löve but it's really dang cool. <chitochi>about the steel scheme thing when i saw the repo i was like "wow, is this the thing cwebber was talking about?" but nope xD <dthompson>ab5tract: I have opinions here :) I think things like raylib are too high up the abstraction ladder. dynamic languages should be trying to reduce dependence on external things like this. <dthompson>imo, anyway. lots of people disagree with me. <ab5tract>I think you are right that sometimes "good enough" stalls development and/or adoption of better solutions <jackhill>(hopefully this isn't too off-topic, I see cwebber's doing actual work…) thinking of the scheme renaissance: what's the zeitgeist on Clojure? I've been attracted to it's emphasis on immutability and pure fuctions (I know that's a popular way to write scheme programs, but clojure seems to encourage it even more). However since Pixie ran out of steam, the other new sexp languages I know (fennel and <jackhill>janet) seem to have not picked up this idea <dthompson>cwebber: I think you're right that it will be too much for beginners, but yeah it's good as reference material. just need more of a quick-start solution. <cwebber>the game library directions that excite me most are still the ones dthompson makes :) <cwebber>that said having spent a lot of time with the ease of making things in Blender has made me realize exactly why Godot is very appealing <cwebber>having a lot of things accessible that you can just kind of wire together with tools that work visually can really be nice <cwebber>jackhill: Clojure has a lot of cool ideas but has a poor license choice (intentionally incompatible with the GPL) and also Rich Hickey burned his community to the ground <chitochi>cwebber: what is the link between blender and godot? :o <cwebber>chitochi: not enough of one in a way <cwebber>I think Blender might end up getting dynamic game support but in a better way than its old engine <dthompson>godot does the usual "write the core in C++ and provide a scripting language" thing <cwebber>it's more that they both are very similar in that they're very "for artists, with code hooks" <dthompson>which is totally fine and good. just not what I'm into. :) <cwebber>obviously more so with Blender than Godot <cwebber>but I have a friend who made a video game that made it pretty big, and I was surprised he chose Unity <cwebber>and he said "unity is game development for artists" <jackhill>cwebber: indeed about license and community, which is why I wanted to see if some clojure ideas would pop up elsewhere <cwebber>I used to work with that person (he later went on to do Kentucky Route Zero!) and another developer who was very snarky who we'll call JB <cwebber>JB was snarking on Blender and said "those people just aren't smart enough to do something like PoVRay, I don't understand why they need all that interface stuff" <cwebber>and the gamedev friend said, very clearly, and I think of it all the time: <cwebber>"Sometimes it makes sense to use your meat hands." <cwebber>that's definitely true in artwork, and it can be true in a lot of things like level design and etc <cwebber>so eg I love things like functional picture languages, and for a while I considered if I should try abstractly scripting the diagrams I did for network flows using them <cwebber>eg the one that appeared at the top of the recent OCapN blogpost <cwebber>but it made much more sense to just use my meat hands <cwebber>that said the right system is probably a combination of the two <cwebber>as in terms of, you pick up your house and you move it around in this very analog way <cwebber>you draw with your hands, as a being constructed of flesh and bone <cwebber>as opposed to the more abstract world of code <chitochi>ok thank you for the explanation i get it now <cwebber>however I think a lot about the Symbolics 3d graphics suite <cwebber>this does tie in with Spritely's present and future stuff in a way <cwebber>if you've never seen it, Symbolics had *the most advanced* 3d software of its time. it's easy to forget that lisp machines wwere very performant, even graphics drivers were written in lisp because of the tagged architecture design <cwebber>part of the power of that was that it was very emacs like at every layer, everything was live hackable <cwebber>the powerful ideas developed there were able to be developed largely because of the power and support for live coding and that you could jump into the code of and modify everything live <cwebber>and here's the part that ties back into how emacs kind of fell at the center of things, even though we don't want it too central: there's a philosophical thread that it's pulling on <cwebber>which is that everything should be alive, everything is clay <cwebber>A lot of the most interesting work ahead for us involves bridging UI work and security work and usability work <chitochi>now i dream of playing with a capability based lisp machine <chitochi>(but i have to learn more about lisp machine, thanks for the youtube link!) <Zarutian_iPad>and if you are intrested in capabilities based hw the uFork might be something you want to look at <chitochi>thanks i will read about that! i scrolled on uFork once but i forget about it, i will look at this again! <chitochi>wow uFork is really cool, i wasn't able to grasp the point the last time i saw this :O <banna>cwebber: process calculi are really interesting to me, but the practical applications are rarely seen in my experience. would love to be proven wrong, lol <sneek>Yey! Zarutian_iPad is back!! <dpk><Monty> bah, it's Zarutian_iPad again :P <jfred>cwebber: I'm learning that there's quite a lot of unexplored territory re: bridging UI/security/usability work for capability systems <jfred>Something that just occurred to me over lunch in that regard; in Horton, the introduction flow relies on your proxy to the message target intercepting messages containing live references and rewriting them. But that does mean that you need to be really sure that the thing you're sending a message to is a Horton proxy, or you'll inadvertently send *your* reference directly rather than introducing it <jfred>Which may ultimately be what you want if the target doesn't speak Horton, but just feels like a potential footgun that the interface is the same in both cases <cwebber>jfred: yeah there may need to be some combination of approaches between certificate ocaps and live reference ocaps <wklew>banna: it seems like we got session types out of process calculi, which are cool. I read Milner's book and tried implementing a little pi interpreter and it was surprisingly hard. <dthompson>dpk: we've been talking a lot about hash tables internally. r6rs has them, r7rs-small doesn't. anything you can share about what r7rs-large might be doing? <dpk>sorry have terrible migraine can’t really do extended chat on this <dthompson>totally fine thank you! hope you feel better <dthompson>we'll compare all this stuff. we were thinking of implementing the r6rs interface for hoot. <dthompson>but we're framing this discussion in terms of what we think guile itself should be switching to since guile's ancient hash table api is terrible. <dpk>i asked wingo recently what the plan is for the future of hashq under his new GC which is moving/compacting but he never got round to answering <dpk>(we have another issue on how to support eq? based hashes) <wingo>dpk: apologies regarding communication :/ <dpk>ask arthur gleckler he’ll tell you i can be just as bad :D <wingo>regarding eq hash tables and new gc for guile: current plan is pinning. problem theoretically is more hashq than eq tables of course -- i.e. exposing the hashq of an object <wingo>but with whippet i can pin on a per-object basis. so anything whose hashq is taken will be pinned for its lifetime <wingo>kidna ugly, prevents use of gc algorithms that require moving, but it's a step anyway <Bagel3000>and I keep getting notices about them expiring. <Zarutian_iPad>hmm... to me the word type has been overloaded with too many meanings <Zarutian_iPad>for a datum like a number we might have an signed twos complements 32 bit most significant bit first integer. This iformation gives us how much space a thing of such takes and how to apply arithmetic operations to it. <Zarutian_iPad>so record part (how the thing is in bits), low semantic part (its an signed integer), middle semantic part (it is a temperture in desidegrees in Celcius), high semantic (its the room temp in spefic room at spefic sensor), and constraints <Zarutian_iPad>now, the last part can be quite interesting and could be checked either at compile, or runtime by something like E guards.