IRC channel logs


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, 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.
<yewscion>Ideally it'd be something like, but I guess that isn't implemented in Guile yet.
<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
<sneek>tohoyn: wb!!
<tohoyn>sneek: botsnack
<janneke>why does this macro
<janneke>(define-syntax sequence*
<janneke> (syntax-rules ()
<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)
<spk121>or use m4
<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>spk121: thanks!
<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
<civodul>indentation is off
<wingo>did i break it
<spk121>civodul: FYI, I pushed a tiny fix for building on Ubuntu
<civodul>spk121: neat, thanks!
<civodul>which glibc version is that?