IRC channel logs
2024-12-28.log
back to list of logs
<dodoyada>so `guild compile -W0` will spit out warnings useful for linting BUT it'll say issues within an expression are on the line where the expression starts. For example, if you `define module` and have a bunch of unused `#:use-module` it'll report as if they're all on the `define module` line instead of on the actual line within the file. I imagine this is just due to how the compiler reads the file, but is there a way to get it per <dodoyada>unrelated: so I'm trying to fix artanis into my clojure-world perspective and see that the request context (rc) is a struct instead of something like an alist, which I assume would be a more natural scheme/guile fit. So why would I use a struct over an alist? <dodoyada>also just to throw this out there, I love srfi-197's `chain`, it's so much better than the clojure ->, ->>, threading macros imo (I know a bunch of languages have this concept, I just learned it from clojure). I have had a bunch of times in clojure programming where I need to finagle lambdas to make a string of inconsistent-arg functions work together. `chain` accomodates that in a great way <leon-p>I am using a dynamically loaded C library from guile and am using procedure->pointer to create callback functions from guile which the C library calls in response to certain events. This functions as expected, however it segfaults non-deterministically (i.e. after what seems to be a random amount of event and subsequent callback function invocations, sometimes on READ soemtimes on WRITE (the C library in turn wraps libwayland)). Sometimes I even get SIGILL. A <leon-p>san, valgrind and gdb turned out to be useless in finding this issue. An equivalent C program using the same library in the same way does not have this issue, so it likely is somewhere either in how I load the library from guile or in guile itself. What is the best way to debug this? <leon-p>huh, disabling the gc prevents the segfaults, maybe it sweeps the callback functions since they are defined inline? <mwette>leon-p: Are you generating any arguments for the foreign calls that might be collected? If so, try using a guardian. Just curious, if a public library, what library? <leon-p>mwette: the problem turned out to be that the callback functions were collected. I had the definition in the foreign call. Somehow I assumed the GC could keep track of them even if the pointers were in the libraries memory. I have defined them as toplevel vars now which fixed the issue <leon-p>the library is one I am currently developing against river's (a Wayland server) new window management protocol, explicitly designed to be bound by high-level languages so you can write window managers in f.e. guile <mwette>I need to check my helper. I usually generate global "typedefs" for the callbacks. <leon-p>almost, river uses wlroots to be the display server, my library conencts to river to be the window manager <leon-p>while commonly Wayland display servers include hardcoded window management, nothing in the protocol actually prevents one from having an external widnow manager and that's what we are trying right now in river <leon-p>I'll take a look, thanks for the link! <rlb>dodoyada: don't know artanis, but of course clojure's very opinionated about making everything a map, barring extenuating circumstances, but it's more integrated there, wrt destructuring, support functions, etc. They're also more general purpose (perf-wise) and you can more or less transparently switch them to records for the storage/perf. <rlb>(So I'd very randomly guess artanis might have chosen records for any number of various reasons (pattern matching, compactness, api's it wanted to use, "typing", ...).) <rlb>dodoyada: oh, and I hadn't seen chain -- that's interesting. At first I thought of as->, but I see it's more than that.