libera/commonlisp - IRC Chatlog
Search
9:27:30
madnificent
nij-: It's been used in the wild since it was written but its use will likely be discontinued.
9:28:01
madnificent
I strongly suspect it could also spit out helpers to allow writing the SXML syntax.
9:28:41
madnificent
It uses context oriented programming at compiletime IIRC, so I guess you could advise it to create different things.
9:32:00
luis
phoe: typing Stelian's nickname on a phone is hard enough without a toddler moving about :D
10:16:42
nij-
madnificent: Thanks for sharing. Does it format the output automatically? Or just plain s-expressions?
10:23:01
madnificent
nij-: It's basically a thing to generate functions from a DTD so that it's easier to write HTML. It should generate documentation if slime is available (iirc). So you should get hints on what input is allowed.
10:24:00
madnificent
But then HTML5 came along and they decided that the lessons we learned shifting away from SGML were for losers and that web devs wouldn't understand simple structure anyways so it's not XML-based anymore.
10:25:08
madnificent
<continued-rant>So we claim that editors should complete any symbol and it's okay to have a myriad of APIs that change whenever with bots that keep our dependencies up to date because it's such a mess, but it's absolutely impossible for an editor to insert a closing term or create a well-formed attribute, that would be far too complex</continued-rant>
10:25:54
madnificent
moon-child: Welcome to the undermining of the W3C. For the shit it gets, it has done an amazing job at pushing our world forward. I'm hoping we can support a bunch of their later efforts to get data back in the hands of people.
10:27:10
madnificent
The WHATWG was created to create HTML5 because the W3C didn't accept changes fast enough. They didn't see a future in xhtml but rather wanted a more free-forming structure where it would be easier to get things accepted.
10:28:07
madnificent
moon-child: You are! But I think the hate for the W3C is largely steered by other interests.
10:29:12
madnificent
The W3C has a structure in place where you can participate as an entity. You know the cost. It gives you single vote. If you're big, you'll pay more, but you don't get more voting rights. That's been a huge thorn in the eyes of some. I think it's a sensible structure.
10:32:11
madnificent
Everyone interprets what they see based on what they want to see, myself included.
16:05:44
citizenajb
Anyone interested in working on a non-FFI Common Lisp QUIC + HTTP/3 implementation? It's a nice big task, but I feel like it helps keep Common Lisp relevant. An FFI version would be OK too, but if all we do is FFI I think we miss opportunities to improve our standard components, like usocket, etc.
16:08:12
madnificent
The discussion on equality has shaped my thinking a littly bit. Thank you. It has also slightly changed my reading of provided methods. The argument to concatenate has received a different place in my head.
16:08:34
phoe
citizenajb: practical question - what issue is there with having a non-CL proxy running between CL and HTTP clients, converting HTTP2 to QUIC?
16:08:56
beach
citizenajb: Great initiative. This is not my domain of expertise, and I am busy with other stuff, but i hope you will get lots of help.
16:09:09
madnificent
citizenajb: I'm not up for the task. I've enjoyed writing an http1.1 implementation at some point but I doubt time will permit from my end. So far we're running Hunchentoot behind a few other services, one being nginx.
16:12:05
madnificent
phoe: Connection handshake is substantially longer. Though with a proxy we keep the TCP connections open longer to mitigate that.
16:12:47
citizenajb
phoe: If the proxy is very local (so that the improvements that QUIC aims at are not relevant) I think that would work OK --- can you point me at an HTTP/3 to HTTP/2 proxy? There is a Common Lisp HTTP/2 server (I think I saw one on github while wandering around)?
16:12:54
madnificent
phoe: given a different transport layer in http/3, I would expect widely different performance characteristics though. Especially on crowded networks.
16:13:36
madnificent
citizenajb: nginx will accept HTTP/3. If it forwards to a backend it negotiates with the server what protocol it should use there.
16:13:53
citizenajb
beach: it is not my domain of expertise either --- but because it would be a hobby project the learning of new things is an acceptable part of the project.
16:14:27
madnificent
I'm not sure how that works together with the push updates in http/2 and http/3. I suspect subtle incompatibilities but I don't know.
16:16:26
citizenajb
madnificent: OK, so there is an extant solution to support Common Lisp as a web server and accept HTTP/3 through proxying, but how about as a client? Eventually HTTP/1.1 will become stone age technology and will help sink Common Lisp with its weight. People choose programming languages for all sorts of reasons, and one major one is "supports 'modern' stuff"
16:17:11
phoe
citizenajb: the general idea is that libraries only happen when somebody makes them, and people usually make them if they need them - a quic client and/or server won't be an exception
16:18:05
madnificent
citizenajb: ah, I only assumed server library. True. I wouldn't expect it to stick with HTTP/3 in the coming years though. We let backwards compatibility loose in HTTP/2 and 6 years later there's already a new very disruptive kit around the block. Given how easy it is to implement, perhaps HTTP1.1 will stick around longer than HTTP/3! XD I generally agree and would love an HTTP/3 implementation though.
16:22:57
citizenajb
madnificent: I think so too, obviously! I just remember how much fun it was when I was younger to work with other people on open source stuff. Now that I'm old and use Common Lisp all day at work I kind of dropped out of the "programming for fun" camp.
16:25:57
semz
"Eventually HTTP/1.1 will become stone age technology and will help sink Common Lisp with its weight." I don't see this at all, honestly.
17:08:39
random-nick
wouldn't implementing http/3 just be a matter of implementing quic (which is called a transport layer protocol but actually just uses UDP) and then implementing http/3 on top of it?
17:22:44
citizenajb
random-nick: usocket isn't perfect. It misses a few features, like auto-close on stream finalization, etc. I'm pretty sure there is some excess copying compared with some of the direct interfaces, but I haven't looked at it in a long time. Nothing specific to UDP or QUIC. Just the more varied users of a library, generally the better something is...
18:39:18
sm2n
for example here: <https://github.com/usocket/usocket/blob/984329e1beb7b4a53fe90957f67bdce6529dc1a1/backend/sbcl.lisp#L28>