IRC channel logs
2025-02-09.log
back to list of logs
<mwette>mra: others have had issues w/ nyacc in this regard; is this nyacc ffi-helper? <mwette>if so, you can add `#:search-path '(list of dirs) to the call to load-foreign-library <mwette>The next (2.02) version of nyacc will add the libdirs from pkg-config in generated .scm files <daviid>mwette: nix and guix do not use pkg-config, on those systems, they just patch related files so they have absolute path <daviid>mra: that's what you have to do, no other way around, on both guix and nix, you must substitute where neeeded, relative path with absolute path - see the g-golf package in guix, the nix pkg will land very soon now (or look into any other pkg on nix ofc ...) <mra>daviid: thank you very much! <cow_2001>why is there no PEG for raw bytes, just strings? <taylan>cow_2001: you can use e.g. utf8->string to turn a bytevector into a string, if that helps <cow_2001>taylan: but then the u8vector would have to be utf8 <taylan>cow_2001: there's also utf16->string and utf32->string ... if I glanced over #systemcrafters correctly, this is for parsing IRC messages? not sure if servers nowadays can guarantee an encoding at connection time... <cow_2001>taylan: do you think using the Guile PEG mechanism is not a good idea? <taylan>no idea, never used a PEG parser before <taylan>I see there's a generic bytevector->string that accepts some extra argument to specify a "conversion strategy". this may be what you want. I think it ought to have a way to deal with invalid UTF-8 sequences without crashing out. <cow_2001>taylan: i will just go with utf8 for now <cow_2001>could you express this Augmented BNF rule in Guile PEGs? "nospcrlfcl = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF" <rlb>cow_2001, taylan: while I'd like to help improve the options, at least for now you can use latin-1 to allow processing of arbitrary bytes without risking crashes due to unencodable byte sequences, but then you have to track the original encoding, and only the ascii (7-bit) chars are easy to refer to in the resulting intermediate string. <rlb>(It's also potentially awkward wrt threads and the locale switching in some places, iirc, but I might have misremembered that.) <rlb>i.e. convert the bytes to latin-1, do whatever you need to with string apis (if that's feasible), then convert back. <rlb>And of course depending on what you're doing, that may only work for incoming bytes that represent an ascii superset or are actually latin-1, or... <dsmith> cow_2001 Might be easier to code that as not #x00 #x0a #x20 #x3a <cow_2001>(native-eol-style) should return lf, no? <ttz>I was trying to hash some data earlier using the gcrypt and realized that the much allocation was performed upon converting bytevectors to pointers using bytevector->pointer. I don't know pretty much anything about Guile's FFI so is this behavior an expected behavior? <graywolf>Hi :) I am on 3.0.9 and am getting this error: system/repl/debug.scm:72:40: In procedure string->number: Wrong type argument in position 1 (expecting string): #f <sneek>graywolf, you have 1 message! <sneek>graywolf, nckx says: There's something you're not saying, that error shouldn't happen if you just invoke ./guix-install.sh. As for ‘non-interactive’: see the code block just under that error, i.e. yes | ./guix-install.sh. That will always select the default. <graywolf>Since the line is (let ((w (false-if-exception (string->number (getenv "COLUMNS"))))), I do not understand how is that possible :-O <ttz>is the COLUMNS environment variable set? <graywolf>Is not, but should the error not be ignored with false-if-exception? <graywolf>Oh, it happens *only* if I am running the code from exception handler. <graywolf>env -u COLUMNS -- guile -c '(with-exception-handler (lambda _ (backtrace)) (lambda () (error 1)))' <graywolf>So... false-if-exception does not work in exception handler? :-O <daviid>graywolf: but why not (and=> (getenv "COLUMNS") string->number) <graywolf>That is not my code. That is code in system/repl/debug.scm from 3.0.9 guile.