IRC channel logs
2023-07-17.log
back to list of logs
<yewscion>Hello #guile! I'm looking for an elegant way to include large, multiline raw strings in my guile code, without needing to run them through a regexp to escape any special characters in order to do so. I found https://github.com/lloda/guile-raw-strings, but it doesn't seem to play nice with Geiser. Is there another library out there I'm missing? <flatwhatson>yewscion: why not keep your large multiline raw strings in separate text files, and use ports to read them? <flatwhatson>you can't embed raw strings without *some kind* of quoting or delimiter <yewscion>flatwhatson: I would rather not create a separate file for each string, as there are a lot of them. And if I am going to be parsing them anyway, I would rather they be preparsed in code than in small, scattered text files. <yewscion>I'm not against quoting or delimiting the strings as a whole, I would just like to avoid having to go through each string and double all backslashes, escape all double quotes, etc. <yewscion>The above library uses a syntax like #R-(Raw String Text)- to do this, which works fine when using Guile by itself. It's just in Geiser that it can't be parsed, which is slowing down my process a bit. <rlb>yewscion: if the constraint is just that you don't want to have a lot of separate files, but would be OK with one, you could put all (or multiple) strings in a separate file each referred to via a unique key of some sort, and then use whatever syntax you like, for example, load them via read-delimited, or... <rlb>But I could imagine you don't really want the indirection. <rlb>And using constant strings is going to be better compiler-wise, of course. <rlb>(if that matters at all) <yewscion>rlb: Matters a bit, though not extremely. Giving (ice-9 rdelim) a look, the only reason it doesn't meet my use-case is that I would have to rely on the structure of the read file (that is, the order) rather than a semantic value like a symbol. If I could just use constant strings, each could be tied to a symbol at their definition, and so long as that symbol exists unmodified I can be sure that the data I expect to be there is <flatwhatson>yewscion: it seems the problem is that geiser checks for a complete expression in emacs, before passing to the scheme interpreter which actually understands the reader extension <flatwhatson>eg. i can evaluate this in a geiser repl with raw-strings loaded: '(#R-()-) <yewscion>flatwhatson: That makes sense. Maybe I can override that behavior somehow, perhaps with a custom elisp procedure. Thanks for the idea! <flatwhatson>that quoting trick seems to work for many cases (eg. embedded quotes and newlines), but not for unbalanced parens <flatwhatson>you might find a lower-level "send" function in geiser that you can call <daviid>yewscion, flatwhatson maybe ask on #geiser <janneke> ((_ (statement0 statement1 statement2 ...)) <janneke> (list "list 0 1 2...:" (statement0 statement1 statement2 ...))))) <janneke>match: (sequence* 'atom), and also (expected): this: (sequence* '(a b c)) <janneke>iow, how would i discriminate between a list passed to sequence* and an atom? <spk121>janneke: no idea. You would think that would work. But you could have two rules (_ foo) and (_ foo ...) and then call it as (sequence 'atom) or (sequence* 'a 'b 'c) <janneke>spk121: hmm, with inputs 'atom or '(a b c), only (_ foo) matches (obviously) <janneke>i don't want to change the arguments, that's the whole point of sequence* <old>is the pointer returned by bytevector->pointer enough to keep the bytevector alive? <old>or should I keep a reference to the bytevector itself <old>for example, make-c-struct only returns a pointer to the bytevector <spk121>janneke: Yeah, i figured. Well, the following can't be the right answer, but, it is a sort of answer <janneke>ACTION had something quite like that using syntax-rules, but that would evaluate the expression twice <spk121>old: holding the pointer should be enough, as I understand it. But a little paranoia wouldn't hurt... <old>I know that for procedure I need to keep the pointer tho <old>right. I have this make-c-struct/protected which is wrapper around make-c-struct but with extra arguments that are kept in a list for parnoid reasons <civodul>hmm the output of ,optimize or ,pp is kinda broken for me as of 896960dadeba7770ebbad97514ec6c4d7f18212d <spk121>civodul: FYI, I pushed a tiny fix for building on Ubuntu