IRC channel logs
2025-07-05.log
back to list of logs
<veqq>dodoyada: Whats your business working on? Anything we can do to help <dodoyada>unrelated: is there a way to do project level defines? I would like to do things like make base level syntax rules available without use-module, and swaps like replace define with define* <veqq>dodoyada: look at (language brainfuck) and make a super minimal language which redefines everything <veqq>(it's a guide to show how to do this, via literate rogramming) <veqq>dodoyada: why do you want to avoid use-module though? <dodoyada>I have a few syntax rules, like clojure-style `(comment ...)` and end up having to write `#:use-module (xyz abc util)` in every file. It's not a huge deal and I do like being more explicit but I would definitely move it to some sort of project define level if possible, again only for things I would consider baked into the language <dodoyada>I would also like to disallow certain things like unspecified use-module and make it so you would always use either select or prefix. Is there a linter? I could do it that way <dodoyada>ArneBab: no and I'm not really understanding <ArneBab>dodoyada: recent guile versions introduced declarative modules, so when you change top-level bindings, that change may not turn up in procedures using them. You can disable that and then connect to a running Server and replace bindings in the running server. <ArneBab>⇒ you may not need to recreate your router for every request if you make your module non-declarative. <dodoyada>ArneBab: oh, gotcha. I thought it had to do with something like the code in the module is updated but when used in a separate module it needs to be 'refreshed'. I will look into it because I would rather leave modules as declarative, I just need the reload capability for dev <ArneBab>declarative modules have a performance advantage, AFAIK, but I don’t know how much. <dpk>rlb: if you have questions about SRFI 207 i’m happy to answer <mwette>I've been updating my C parser. It's so nice working this in Scheme. I was able to make a simple one-line update to handle some complex typedef cases. <rlb>dpk: I was just chatting days ago with wingo about a guile port https://codeberg.org/rlb/guile/commits/branch/tmp/srfi-207 and he was contemplating tagging the instances returned by those constructors such that they'd be rendered (written) as bytestrings, while I'd assumed from the srfi that they were intended to be indistinguishable from bytevectors. <dpk>yes, SRFI 207 does not define any new data type <dpk>i argued against both the name ‘bytestring’ in the procedures, and indeed against including the procedure library in that SRFI instead of making it a separate SRFI, precisely because of this potential confusion <dpk>but my co-authors disagreed <dpk>what would be the purpose of taggibg them? if the ‘tag’ made them a disjoint type, that would be non-conforming <rlb>I'm assuming it was in part in the context of "system data", i.e. so (getcwd 'bytes) (or however we provide a bytes flavored getcwd) might return bytevectors with that marker, so you'd see them in a likely more readable format in most locales, etc. <dpk>ah, that might be a reasonable (and interesting) extension <rlb>Hmm, now that I think about it, I suppose that might be a backward compatible (enough) extension, i.e. perhaps we don't have to decide that before we add srfi-207 at all... <rlb>Though we'd need to decide if we wanted the print-enable either way, or I'd need to take that out, for now. <rlb>If I did, then of course you'd have reader support, but not writer for now. <dpk>that would also be absolutely okay, yes <rlb>I've warmed to wingo's suggestion -- ideally, I'd think that for things like paths, a scheme would be much better off writing a standard, ascii-oriented representation like bytestrings (e.g. in error messages, etc.). <rlb>Hmm, could it be a completely out-of-band (infectious?) flag for bytevectors... <dodoyada>what is the ideal way to stop a `(@ (web server) run-server)`? I am trying to start it using `call-with-new-thread` and then stop it using `(system-async-mark (lambda () (raise SIGINT)) server-thread)`. The server stops responding immediately but the thread keeps going and seems to depend on me making a new request to shut down. I assume it has to do with hanging onto the network connection, should I be detecting the close and <dodoyada>sending "Connection: close" in requests as it's going down? <dodoyada>at this point I'm thinking I should just implement run-server myself so I can use close-server directly <ArneBab>dodoyada: are you already using fibers? <ArneBab>(for higher performance, though they carry the risk of never reducing memory use) <dodoyada>I was using fibers but I moved to (web server) for now since I wasn't using fibers features (yet) <dodoyada>I don't understand the implication of nonblocking ports entirely. Right now I'm running (web server) in a separate thread. If I set the server port as nonblocking could I manage it all in one thread or would I need to still use a separate thread? <ArneBab>dodoyada: The main advantage for me are channels, because they provide reliable communication between asynchronously runningcode. <dodoyada>I know fibers would be good, I'm just trying to keep my project as simple as possible. I love channels but don't need them <ArneBab>I understand that well -- adding fibers increases the complexity when deploying to non-guix. <ArneBab>Having to run on a debian stable was a bit annoying (but that’s the cheapest webserver I could get) <dodoyada>I had a really nice setup using fibers web server but the way it uses `run-fibers` meant my dev setup had to be inverted so that my repl started inside of the fibers context and restarting the server was a matter of killing my repl. I'm trying to flip it around so I start my repl and can start/stop the server without restarting the repl. I'm technically there but the threading approach has some rough edges