IRC channel logs

<csepp>dpk: you don't necessarily need a JIT compiler in the usual sense, just multi-stage compilation. An actor's code could be optimized to an IR and when certain parameters become known, you can run only the necessary optimization passes on the resulting IR and do code generation from there.

<csepp>There was a demo of multi-stage compilation for LLVM a while ago, there is also an ML variant that has some syntax and compiler extensions for it.

<mala>hey folks, https://www.ocapn.org/ 's certificate is broken -- it's serving up the spritely certif

<dthompson>mala: interesting... thanks for letting us know

<dthompson>we haven't deployed in awhile. not sure what happened but it's serving up the spritely site instead of the ocapn site. bleh.

<dthompson>will figure it out.

<dthompson>mala: ahhh "www", that's why. it's just "ocapn.org". I'll add www.ocapn.org to our nginx config, though, to avoid this happening in the future.

<mala>excellent --i found it because it's the second hit on https://kagi.com/search?q=ocapn for ocapn (after online court assistance program :) )

<chitochi>tiny update about the flutter guile goblins thing, it works! but now that we (we are two doing this) started using guile we don't want to go back to dart and flutter at all, so now we are trying to do our tiny budget app using guile and goblins only :p

<dthompson>chitochi: lol nice!

<dthompson>glad it's working

<chitochi>it's working but it's really a shame for guile, you can't use a repl for example :'(

<chitochi>(it could be done i think, but not easy to do a good integration with the flutter hot reload / restart)

<dthompson>chitochi: I've been interested in flutter lately but haven't actually used it. would be curious to know your experience.

<dthompson>I've been intrigued by their widget layout algorithm

<dthompson> https://docs.flutter.dev/ui/layout/constraints

<chitochi>i worked three years with flutter for a dating app, it's really good i think, but it still have a lot of shortcomings. i really like the widget layout algorithm too! honestly the thing i dislike the most is how google is everywhere in the project :/

<mala>i was looking at everybody singing Dear ImGUI's praises just now (but noting that it is not good on accessibility and good looks), and dreaming of a neater accessible but still simple GUI system for Guile, learning from all of these great tools

<mala> https://slint.dev/ is doing some interesting work too

<chitochi>one issue is with flutter is #51752 on the flutter official repo, "Reusing statel ogic is either too verbose or too difficult"

<chitochi>i am really interested in slint too!

<dthompson>mala: I've been doing some research on various UI styles lately as I try to figure out what to do in my personal game projects.

<mala>i feel like you could go a long way by piggy-backing off one of these declarative systems and just having hooks for Guile -- LQML goes a long way using that approach with Common Lisp (ECL) and Qt's declartive bindings https://gitlab.com/eql/lqml

<dthompson>something combining imgui and flutter concepts may work well for games.

<mala>I will note that the last time I successfully wrote something with anything like a GUI, it was in dthompson's https://dthompson.us/projects/chickadee.html :)

<dthompson>but that's for a very specific use-case of realtime games.

<dthompson>I'm reasonably happy with the virtual DOM approach for web UIs

<chitochi>i am trying to do an ui library using chickadee right now \o/

<chitochi>is chickadee made for ui?

<mala>part of the appeal of Guile is that it's /very/ unexplored territory hahaha

<dthompson>chitochi: it's not made for anything in particular. it just gives you the pieces.

<mala>Batteries included? Here, we MAKE OUR BATTERIES FROM MINING OUR OWN LITHIUM

<dthompson>I have done some simple retained mode UI stuff in the past with my unreleased engine, catbird

<chitochi>dthompson: that's exactely what i was looking for when is searched \o/

<mala>dthompson, yep, Elm architecture + declarative something something

<dthompson>Elm is a no-go for me.

<dthompson>functional everything is just too much overhead

<mala>mental overhead or CPU overhead?

<dthompson>it's a nice idea, though. something that preserved some of the good parts would be nice. I have done experiments in frp in the past.

<chitochi>i like the idea of using signals

<dthompson>mala: too much gc

<dthompson>it's an elegant model that performs very poorly

<chitochi>what did you learn with your experiments in frp? :o

<dthompson>here's a nearly 10 year old blog post about it https://dthompson.us/functional-reactive-programming-in-scheme-with-guile-2d.html

<chitochi>ow nice!!

<mala>i feel like that may be lack of support in underlying data structures, but I bet that is an even deeper rathole!

<dthompson>I even wrote a game using this style https://davexunit.itch.io/lisparuga

<mala>dthompson did you follow Elm after they kind of abandoned raw FRP and came up with the Elm architecture to simplify it

<dthompson>not really, they lost me with the new stuff. didn't seem particularly interesting anymore.

<dthompson>for me, the main thing I'm after is a programming interface that eliminates app state <-> ui syncing bugs.

<mala>ah, it's kind of a nice way of thinking about things, and inspired a lot of stuff like React. It doesn't feel particularly functional or FRP, though I don't know to what degree it would have to involve passing around large data structures instead of mutation

<encryptedwhisper>I had some good experiences experimenting with RELM4 which is the elm architecture in rust (and gtk)

<dthompson>ui being a function of app state is the key thing, doesn't have to be frp that makes that happen. imperative imgui works too.

<dthompson>the problem with the react style is that you're generating some amount of garbage with each update to the UI.

<mala>i think you would really like the Elm architecture thing, then, despite the name. I think it ended up being the major innovation that came out of that whole experiment

<encryptedwhisper>imgui is very popular for programmers, but i have found that it fails if you have a bigger project that needs designers to mess with things, since you are embedding all the logic directly in the code, almost always

<dthompson>encryptedwhisper: yeah, if you need those gui designer tools it doesn't really work

<encryptedwhisper>Well, you don't need gui designer tools, it can just be a separate markup

<dthompson>sure

<encryptedwhisper>I do have some thoughts about how I'd like to create something like the elm architecture for hoot/web stuff, and possibly integrate it with goblins/ocaps as well

<encryptedwhisper>but, of course i only have so much free time

<dthompson>for my personal stuff it's a use-case I don't care about because I don't work with designers

<chitochi>oh wow that would be really cool :O

<mala>encryptedwhisper, yeah the message-based nature of elm architecture makes me think there's a goblin-y way of implementing it

<encryptedwhisper>Yeah imgui and immediate mode is awesome for prototyping and for programmer interfaces

<dthompson>the best reactive ui library I've ever come across was mithril

<encryptedwhisper>It's extremely powerful and fast, and I like the idea for that aspect

<encryptedwhisper>it's also used by certain very large game studios, so it's definitely very stable and effective

<encryptedwhisper>Furnace is an awesome tracker made entirely in imgui, as well.

<encryptedwhisper>(music tracker)

<encryptedwhisper>But I'm digressing too much :)

<chitochi>(nah thanks for furnace i will look at this)

<dthompson>my biggest complaint about dear imgui is that event handling is coupled with the rendering calls.

<encryptedwhisper>The UI library I've used the most has been Angular, and, well, it's powerful, but it's also rather clunky and complicated.

<dthompson>like you call the button function and it returns true if the button was clicked. no like.

<encryptedwhisper>Ah, yeah well that's the whole idea behind immediate mode.

<dthompson>I did a lot with angular 1 back in the day. sucked.

<encryptedwhisper>I have used Angular the most just because it's what I use at work.

<encryptedwhisper>I haven't tried Angular 1 but it looks really sucky, yeah.

<encryptedwhisper>I wouldn't use Angular for a personal project, though.

<dthompson>previous job used vue, which is a nicer react alternative. for small stuff mithril is underrated.

<dthompson>it has the closest thing to sxml I've ever seen in js

<dthompson>no jsx nonsense

<encryptedwhisper>I thought Vue was really nice seeming. I didn't get much further with it than basic tutorials/demos. I have trouble coming up with ideas for single-page web applications :)

<chitochi>i feel guile hoot will be the perfect thing to experiment in these things

<chitochi>the tiny virtual dom is a perfect example xD

<encryptedwhisper>Do you know much about htmx? It doesn't solve all the problems, but I think it's a rather elegant way to avoid javascript and other complexities

<dthompson>I looked at htmx, haven't used it.

<dthompson>I did not love what I saw.

<encryptedwhisper>(yes, it uses JS internally but in theory it wouldn't need to, which I think is neat)

<dthompson>namely the introduction of a new language called hyperscript

<dthompson>which apparently is optional but every time I see an example it's used

<chitochi>is used htmx without hyperscript in practice it's really optional, htmx is really simple

<chitochi>i*

<dthompson>it seems fine for very basic stuff

<chitochi>you can do some nice things like a tiny chat in a really tidy way

<encryptedwhisper>Hmm, interesting. I can't see any mention of hyperscript on the htmx docs

<dthompson>but my hunch is that it will be painful once you outgrow it

<encryptedwhisper>Ah I found it under the scripting section

<dthompson> https://htmx.org/docs/#hyperscript

<dthompson>oops

<dthompson>you already found it

<dthompson>too slow

<chitochi>i think the idea is that you can then add a little javascript, but i never had to to do that for what i used it so i don't know :/

<encryptedwhisper>Yeah it's not really meant to be as complex as a full single-page webapp

<encryptedwhisper>But yeah I don't like the hyperscript syntax, just based on a very quick glance

<chitochi>it reminds me of some sql ideas :x

<dthompson>it's getting a lot of hype right now which activates my skepticism

<dthompson>it seems good very small things

<dthompson>good for*

<encryptedwhisper>The part I like about it is just, that the requests return html, so you don't have all the complicated transformation going on, it's just straightforward and simple. And, that it could theoretically be a first-class browser feature, which I like because of how it allows for moving away from JS.

<dthompson>and that they felt the need to add a scripting language is a sign that it's too limited

<chitochi>i think so actually, and when i used it i didn't used the scripting thing at all because i think that's the nice way to use it

<encryptedwhisper>I don't think hyperscript is built-in or anything, it's just an option that happens to work: https://htmx.org/docs/#scripting

<dthompson>yeah it's not built-in but the developers felt the need to provide it for a reason

<encryptedwhisper>I guess you mean the hx-on attribute?

<encryptedwhisper>hmm seems, that doesn't even support htmx

<dthompson>here's an example https://htmx.org/docs/#trigger-modifiers

<dthompson>hx-trigger="keyup changed delay:500ms"

<dthompson>they've created a new language here

<encryptedwhisper>Ah, that's not hyperscript I don't think, but some sort of not-well defined language

<encryptedwhisper>Yeah that seems messy

<dthompson>yeah this isn't even getting into hyperscript

<chitochi>i forgot this one :x

<dthompson>I like what htmx is trying to do, but I think they're immediately running into an expressivity ceiling

<dthompson>would be interesting to try to build an htmx-like with hoot

<dthompson>because with lisp we actually can reasonably create new languages

<chitochi>i was thinking about that xD

<dthompson>with structure! and not embedded into attribute strings

<encryptedwhisper>Yeah. I was just going to say this too

<dthompson>preserve the "talk to the server to update components" model

<encryptedwhisper>I know full well how deep you can get with attribute strings, having used Angular. But it is messy for sure.

<dthompson>replace the language

<chitochi>sxml is perfect for this

<dthompson>I look forward to seeing your implementations next week ;)

<encryptedwhisper>haha ... maybe if I had a functional laptop to use during my vacation!

<dthompson>this conversation has helped me understand better what I like and don't like about htmx

<chitochi>same \o/

<dthompson>a hoot version of this could send sxml back which is then transformed into dom nodes using a similar style to the react-like stuff we've already shown

<dthompson>rather than an html string

<chitochi>it could even be pretty agnostic of the rendering

<dthompson>how so? I'm curious

<chitochi>wait it's not the good word?? i meant generic maybe?

<dthompson>generic in what way? curious what you have in mind

<dthompson>encryptedwhisper: we'll overnight a laptop to you for this assignment ;)

<chitochi>i feel like it just need the learn triggers and to send back sxml in some way?

<encryptedwhisper>I think for it to work effectively as htmx does, you'd want it to be pretty tied to the visual representation of the page, but it would be separate from the actual rendering because the rendering requires proper html

<chitochi>to learn*

<dthompson>if you use sxml on the server, you can easily embed the fancy trigger stuff without resorting to strings

<encryptedwhisper>Yeah. I'm thinking it would be sxml everywhere, except the actual DOM which is by necessity html. Until a browser comes around that can just natively support sxml :)

<chitochi>but can't it just parse the server html, and get sxml back?

<dthompson>right. so the server-side templating is sxml, which is then rendered to html and sent to the client. then the hoot-tmx library traverses the page and initializes the interactive elements.

<chitochi>like sxml -> html -> sxml -> html

<dthompson>then for updates, you can send sxml back directly and let the client create the element tree and do a replaceWith or whatever

<chitochi>really cool

<dthompson>this is actually seemingly very feasible...

<chitochi>and the trigger can just be scheme i guess?

<encryptedwhisper>Yeah it doesn't sound too difficult at all, really.

<encryptedwhisper>I suppose the triggers would have to be *interpreted* hoot code, given that they are coming dynamically from the server.

<dthompson>the trigger stuff would be some kind of s-expression... but you wouldn't want it to be full scheme

<dthompson>encryptedwhisper: right

<encryptedwhisper>and yeah you could restrict the language allowed there.

<dthompson>but it could be a simple combinator language

<encryptedwhisper>that's similar to Angular though. Angular's expressions inside strings are not full featured JS expressions

<chitochi>interesting :o

<dthompson>it's the embedded as strings part that I don't like, not the domain-specific language

<dthompson>since it's all s-expressions it will be pleasant to write

<dthompson>arbitrarily complex expressions will be nice and tidy

<encryptedwhisper>Angular also has "pipes" which are an .. interesting way of transforming data. But I think it could be lispified a bit cleaner. like, the threading macro from janet/clojure https://janetdocs.com/-%3E%3E

<dthompson>a basic threading macro is easy in scheme

<encryptedwhisper>yeah, for sure

<encryptedwhisper>the syntax for angular pipes is horrid :)

<dthompson>I imagine the trigger stuff could be a lot like the sicp picture language

<encryptedwhisper>birthday | date:'fullDate':'anotherparam' | uppercase

<dthompson>ooh fun fun lol

<encryptedwhisper>the 'magic' of pipes is that they only transform when needed. I think this would be the critical feature to getting these trigger expressions to work well. Is making sure they have similar 'immutable' support such that they are only evaluated when their input changes or such.

<dthompson>things are starting to come into focus for me here... I think this could be a very enlightening experiment

<dthompson>encryptedwhisper: right, wouldn't want needless computation

<encryptedwhisper>(there is an escape hatch for pipes where you can say that the transformation is not 'pure', and so the pipes must be invoked every time, but by default they are considered 'pure' transformations)

<chitochi>can't pure subset scheme with a tailored stdlib that would be preloaded on the client be the most flexible thing?

<chitochi>wouldn't a*

<dthompson>chitochi: now we're entering ocap territory :)

<chitochi>oh woow that's true

<dthompson>yes, an evaluator that was ocap safe would be perfect for this

<chitochi>the server could give capabilities to the client to call him back and a given endpoint

<chitochi>them*

<dthompson>the easiest option right now that preserves security is a small DSL that gets "compiled" to some composition of combinators

<chitochi>i don't know much about combinators, i will read more about that :o

<dthompson>like in those htmx examples you have delay, throttle, once, etc.

<dthompson>those could be some primitives

<dthompson>and then you'd also have a way to combine them

<chitochi>ok i see

<dthompson>(delay (ms 500) (changed (keyup)))

<cwebber>Wow holy moly

<cwebber>Hello from the road

<cwebber>Lots of exciting looking backscroll tho lol

<cwebber>Will have to catch up soon

<dthompson>uh yeah we kind of went wild over here lol

<dthompson>mala pointed out some bad nginx config on our server (that I have since made an internal PR for), thanks again mala!

<cwebber>Yay ty mala

<dthompson>and then chitochi probably didn't know what they were getting themselves into by bringing up flutter in here ;)

<cwebber>Lol

<cwebber>Oh boy

<chitochi>xD it's perfect this way

<dthompson>everybody has some neat ideas about UI stuff

<cwebber>I wonder if there's any mention of propagators in the backscroll :3

<dthompson>almost! we were getting there with frp stuff

<cwebber>In Alexey Radul's dissertation he shows how propagators make a powerful substrate for FRP

<dthompson>but the tl;dr is that htmx came up and we collectively have some ideas about how to use hoot to keep the good parts of htmx and replace the ad-hoc DSL stuff going on

<cwebber>And shows an example of how they handle cycles beautifully in a way many other systems don't

<cwebber>Oh heck yeah

<chitochi>i feel like it's possible to have the server side callbacks (in some sxml tree) be serialized and sent to the client when the page is loaded

<cwebber>You know what I love to say

<cwebber>"lisp is clay"

<cwebber>I ought to write a blogpost about that

<dthompson>mud, meet ball of mud

<cwebber>"lisp is clay: the power of composable DSLs"

<chitochi>that sounds good xD

<dthompson>better than my title: "rolling in the mud with lisp"

<dthompson>(yeehaw)

<e-snail>hi, what am I missing? `guix install: error: guile-goblins: unknown package`

<dthompson>e-snail: hmm, not sure. does `guix show guile-goblins` display anything?

<e-snail>`guix show: error: guile-goblins: package not found`

<dthompson>is your guix very out of date? guile-goblins has been available in the default guix channel for quite some time.

<dthompson>have you run `guix pull` recently?

<e-snail>all I've done is install guix from debian repos and guix pull (which took an hour to finish)

<dthompson>e-snail: a-ha, debian must have an ancient guix.

<dthompson>try running `hash guix` and then `guix show guile-goblins`

<dthompson>sometimes after the first `guix pull` your shell doesn't know how to use the updated binary

<dthompson>and `hash guix` tends to fix it

<dthompson>`which guix` should return something like "/home/e-snail/.config/guix/current/bin/guix"

<e-snail>oh, after logging in to a new shell it shows up

<cwebber>Yeah logging out and in again tends to...

<cwebber>Yup

<e-snail>this is a rather byzantine process

<dthompson>I mean, it's cool that guix is in debian... but guix moves fast so you got a very very old version

<cwebber>It would be cool if our tools were in Debian too some day

<dthompson>yeah you should eventually be able to just to 'apt install guile-goblins'

<dthompson>just do*

<dthompson>but so far no one from debian has packaged our stuff

<cwebber>Heck some day when we have better resources towards sysadmin infrastructure I would love it if our build system shipped nightly .deb and .rpm packages

<cwebber>But alas we are a bit off from that

<dthompson>yeah that would be nice

<cwebber>Guix actually could help with that tho

<e-snail>maybe I will try to understand this project for the n+1th time in another 6 months...

<dthompson>e-snail: oh is it still not working?

<dthompson>we can try to help :)

<e-snail>there's just been enough friction in getting to a hackable state that I just don't feel like moving forward anymore

<dthompson>sorry to hear that. has the friction mainly been with using guix?

<e-snail>well guix was the main thing but I also haven't found the docs overly accessible (e.g. I cloned and built a single-page HTML version of the guile-goblins manual because the page-per-node lacks adequate navigation furniture IMO, and the choice to use wisp has put me off reading the whitepaper on multiple attempts)

<dthompson>well thanks for the feedback. those are all things we'd like to improve.

<cwebber>The wisp choice has been debated quite a bit

<cwebber>We have considered making a second version with s-expressions instead but haven't had time

<chitochi>i think having the choice on a web version would be cool, with some hoot repl

<cwebber>It would be even nicer if you could toggle it on the same page

<chitochi>this

<cwebber>Ooohhhh yes we have discussed that a lot

<dthompson>+1 for toggling it on the same page

<chitochi>imagine running the goblins example how mind blowing that would be

<cwebber>The Scheme Primer will probably be repl'ified first

<dthompson>yeah that's the easier one

<dthompson>a lot less surface area

<cwebber>But you aren't alone in these concerns about the docs btw

<cwebber>encryptedwhisper started working on something relevant to that recently

<chitochi>good choice i think to start with the scheme primer

<cwebber>And yeah if you compare the racket docs with the Guile ones

<cwebber>Racket's docs vs Guile's (both for the languages and Goblins) in terms of navigability

<cwebber>It's clear that Racket is ahead in their doc system

<cwebber>Aside that you can read the Guile ones in emacs which is an incredible experience but admittedly one that fee people know how to use

<e-snail>I put off learning racket for a long time (because ew nonstandard scheme?) but I found the docs very helpful when I finally got to it

<cwebber>*few

<cwebber>Loved seeing all the chat in here today

<cwebber>Now to hack on Brainy (propagators implementation) :)

<chitochi>oo i scrolled on the brainy gitlab readme once, tbh i still don't really understand it, but it sounds cool

<jfred>One tricky thing about reading the docs in emacs: afaik it only works if you have the guile-goblins package installed in your user profile. If you instead use `guix shell` with a manifest file in your project's directory then `M-x info` won't be able to find them

<encryptedwhisper>Yes, takev and I are attempting to create a web-based interface for guile's documentation in general, which could also be adapted to goblins and such. with a playground/repl for examples, and eventually ability for folks to submit examples as well. It's still very much early days, though.

<dthompson>\o/ go team go!

<chitochi>this collaborative examples idea is really nice

<encryptedwhisper>It was taken from https://janetdocs.com and https://clojuredocs.org/ - great inspirations/ideas

<mala>this is the point where I ask everybody to think of maintainability as part of the experimentation! what would be like to have great docs that would still be great docs in 10 years time

<mala>i am like the ghost of Christmas Past

IRC channel logs

2023-12-20.log