IRC channel logs
2025-03-07.log
back to list of logs
<lechner>mange / thanks! that was part of my problem <lechner>Hi, may I use procedure docstrings with match-lambda* as in (define name docstring (match-lambda* clause1 clause2 ...)) ? <mange>Doesn't look like it. But (match-lambda* clauses ...) is just (lambda expr (match expr clauses ...)), so you can just manually expand it and do (define name (lambda expr docstring (match expr clause1 clause2 ...))). <cow_2001>i have adapted the (ice-9 peg) to work on bytevectors, right? now i think i could parameterise the code over any traversable datastructure, bytevectors, strings, u8, i8, u16, whatever. will you be interested in it? <lloda>who can update g-wrap to look for 3.0 :-/ <ft>Hm. No mmap for guile? Sadness. <dsmith>No? I thought that .go files where mmap'ed into memory... Maybe no public interface <ft>I've seen a couple of attempts from mwette on the mailing-list. But there's nothing in the code that makes me think I can use it. <ft>The loader is implemented in C still, I think. <ft>I wanted to write a parser for doom's WAD files for fun. And mmap would have been convenient. :) <ft>mwette: Ah. Does that look similar to your patch from '23? :) <ft>I'd want the WAD think to work without many dependencies. <ft>WAD is basically just a mapping of short names to offsets and lengths. So it works okay without mmap. <ft>It would just be so convenient. :) <old>ft: why would foreign-interface not work here? <ft>It might. But I feel like mmap need enough magic number macros that I shouldn't have to. <rlb>...I imagine there's at least the traditional "what are the 'enum' values" issue that'd make a native implementation more desirable, e.g. MAP_* PROT_*. <old>hmm with-coverage seems to be useless at best. I get 0 line coverage for every files <old>s/with-coverage/with-code-coverage <old>ah I see, Guile needs to be started with --debug <mwette>maybe mmap could be done via ffi; the mmap patch for guile had some activitiy, but the patch review hit the back burner <ft>old: The flags are made up from macros though. <old>just write the value in variable <old>that's what every ffi interface does <ft>There seems to be too much hope involved. <ft>The ffi helper that has a C parser could help with that. <ft>But I'm not going to be the one. <old>the mmap interface is so small I don't think that manually adding the flags is a pain <rlb>(In general, I'm always concerned about cross-platform flag values over time.) <dsmith>Linus is very militant about keeping the Linux kernel<->userland abi stable, so I would be surprised if the flags change. <dsmith>Now the *bds's could be a different story.