IRC channel logs

2024-06-05.log

back to list of logs

<mwnaylor>Are there window managers for *nix written in (and extendible by) guile?
<Arsen>none that I know of, closest IME is stumpwm in CL but AFAIK that's X-only unfortunately
<dthompson>there's guile-wm (xorg, old) and dwl-guile (wayland, new) though the latter is just for configuring dwl
<rlb>also from way back: https://en.wikipedia.org/wiki/Scwm
<cpli>i'm currently writing a parser for the kdl document language; and using lalr-parser to do it
<cpli>since its grammar reads whitespace in a context dependent manner (nodes may wrap lines, iff the line ends in "\\") i sort of need to use whitespace as terminals in the parser, which is unsightly
<cpli>another quirk is subexpression comments, much like `#;` in scheme, where `/-` will comment the next node/identifier/group
<cpli>essentially, i will hesitantly finish an implementation with lalr-parser, but are there more flexible/elegant solutions, akin to say cl's esrap for scheme/guile
<cpli>*-?
<mwette>cpli: You could look at nyacc, https://savannah.nongnu.org/projects/nyacc. With it you can declare tokens to be "skip-if-unexpected". You'd then put space in your grammer where it matters and otherwise the parser will skip it.
<mwette>WRT window manager, I was thinking of making one for wayland using ffi bindings to wlroots.
<mwette>cpli: check the c parser in module/nyacc/c99/{mach,parser}.scm
<daviid>mwette: is wlroots still maintained?
<mwette>the repo shows updates from 4 hours ago
<daviid>i looked at a wrong one then, what is the 'good repo'?
<mwette> https://gitlab.freedesktop.org/wlroots/wlroots
<daviid>tx
<mwette>yw
<lechner->i can't wait to see it
<cpli>mwette, that looks great
<cpli>daviid: yes by emersion, the same person maintaining sway
<mwette>cpli: I used it in my c99 parser to parse comments "in the usual places" but if comments show up elsewhere they are skipped
<cpli>mwette: pragmatic, but not exactly elegant q-q
<lechner->mwette / Hi, with this nyacc-generated FFI code I can unwrap a pam_handle_t* before passing to C with ((fht_unwrap pam_handle_t*) handle) but how may I "wrap" a raw handle in C that I plan to pass to Guile, please? https://bpa.st/GZTA
<lechner->before I pass it to Guile
<ArneBab>lechner-: "#:declarative? in the reference" → sounds like an oversight. Maybe send a patch?
<mwette>lechner: not sure what you mean by "passing to Guile" but maybe (make-pam_handle_t* obj)
<lechner->mwette / thanks! i'd like the scheme code to receive a wrapped pam_handle_t* and will try your code in C.
<mwette>If you want to do it w/o the ffi-helper Guile has define-wrapped-pointer-type
<lechner->mwette / i'd love to do it without loading the FFI-generated code. Is that possible?
<mwette>of course, but you'll want to use Guile's foreign-library-function for the function interfaces
<lechner->actually, i just meant the wrapping of the pointer.
<lechner->the C module is LGPL while my Guile code is GPL
<mwette>got it
<lechner->can i do it by copying the (define-wrapped-pointer-type ...) verbatim into my C code, or will those two types be distinct?
<lechner->now i see what you mean by use foreign-library-function
<lechner->it helps to scroll down
<mwette>maybe not, from C->scheme ? I think there is a SCM_PACK_POINTER() macro
<lechner->i have a pointer already. i just wish to do the reverse of fht_unwrap
<lechner->have an SCM pointer that is
<lechner->i think
<lechner->fht_unwrap does not complain when it receives an unwrapped pointer but it would be cleaner
<lechner->i go back and forth between C and Scheme a lot, and some code is called from either. for calling this routine from Scheme, for example, I have to fht_unwrap. When called from C fht_unwrap quietly does nothing https://codeberg.org/lechner/guile-pam/src/commit/2149b50e07000d61e36f8d3c972c3344cdaeda37/scm/pam/legacy.scm#L56-L59
<lampilelo>hello, so i have this snippet of code - https://dpaste.com/7PAHS7BSG.txt - and the first method of making a pre-unwind handler for displaying backtrace doesn't produce any output unless COLUMNS env variable is explicitly set in the shell, can anyone reproduce this? also, when using the first method and compiling with level 2 optimization, with more complicated code it results in an error being thrown from (backtrace) call but i don't
<lampilelo>have a minimal example for this
<lampilelo>i'm experimenting and don't really know what's an idiomatic way of handling exceptions without skipping the backtrace
<old>lampilelo: I had the same problem in the past. I would like also a solution, but it might actually be a bug
<old>(backtrace without COLUMNS environment)
<lampilelo>definitely a bug since the method with catch seems to be working perfectly fine
<lechner->Hi, what's an appropriate license for nyacc-generated FFI bindings?