IRC channel logs
2025-01-25.log
back to list of logs
<jlicht>hey guile! What's a clean one-liner to run delete-file on something, and not error out if the file does not exist? <rlb>jlicht: if you're on a posix host, (system* "rm" "-rf" file)... There's also false-if-exception, but it's not discriminating wrt ENOENT. <rlb>...and with system* you'd perhaps still want to check the status:exit-val <graywolf>Hello :) Do we have a name for the non-optional and non-keyword arguments? Python calls them "positional" I believe, do we use the same term? Specifically, given (define* (foo . args #:key x y)), what term should I use for 'a and 'b in (foo 'a #:x 'x 'b #:y 'y) when documenting the procedure? <jlicht>rlb: I was afraid that was the case, but thanks anyway :-) <graywolf>Does (when (file-exists? f) (delete-file f)) count as one-liner? <jlicht>graywolf: It could still fail in certain circumstances, but it's what I'm going with for now indeed <graywolf>True, there is small race window between the check and the delete. <cow_2001>how do i (define-method (foo (some-srfi-111-box box?)) ...) the srfi-111 box has no class, so i think maybe use the box? predicate... but that just does not work <cow_2001>is this how you do it? (define box-class (class-of (box '())))? would that work as expected? <cow_2001>are there any reasons why one should not do it? <cow_2001>why would (define-method ((setter foo) ...) ...) work in regular guile but not within a r7rs-small library? <cow_2001>i open a guile repl and run (import (oop goops)) (define-method ((setter foo) ...) ...) and it works, but when i put this syntax in a r7rs-small library, it fails <dsmith>cow_2001, A guess: curried definitions? <dsmith>I was thinking ((setter foo) ..) looked a lot like a curried def to me. Was thinking maybe those are disabled with r7rs. But it's probably not that. <graywolf>I just noticed there does not seem to be bytevector-null? predicate. So I guess I am expected to define my own (define (bytevector-null? bv) (= 0 (bytevector-length bv)))? <graywolf>Or did I miss some part of documentatino? <wizard>googling for this is extremely difficult, but is there anything like clojure's threading macro in guile? <graywolf>Would anyone know why this does not work: (format #f "~[~:;~:*~a~]" 1) ? <wizard>srfi-197 looks exactly what i need, ty :) <graywolf>Hm, I can do (format #f "~[~*~:;~a~]" 1 1) instead. Still not sure why the original does not work, but at least I have way forward. <rlb>cow_2001: don't know offhand, not sure I've ever tried to use goops for setters, and also, my comment was just "in passing". I don't really know whether we'd want to use goops here. I'd suggest raising a discussion on the list if you're planning to pursue it in earnest. <rlb>i.e. also might be that we can just start with the standard implementation and worry about anything else later. It only got my attention because I had to implement something related for the clj dialect, and all of that was via goops, but it's syntactically simpler, and doesn't need to work "everywhere" in guile. <rlb>Right -- I vaguely suspect we might not want to use goops, or at least we don't right now iirc in many places in guile itself? Mostly I was just concerned you might go to a lot of effort based on my offhand comment, only to find that the standard implementation would be the one wanted. But if you're doing it say because you're curious, well that's entirely different :) <cow_2001>rlb: think this is a good message? "Currently I have removed the `cond-expand`s in the SRFI-123 example implementation in `./srfi/srfi-123.scm` and experimenting with an implementation in GOOPS in `./srfi/srfi-123/goops.scm`." <cow_2001>oh, and i ask for "any input whatsoever" <mwette>canonicalize-path is not idempotent; shouldn't it be? <mwette>Not the issue: it's the fact that scm_open_file_with_encoding (aka open-file) calls canonicalize_filename and scm_canonicalize_path (aka canonicalize-path) calls canonicalize_file_name (note underscore). So, (canonicalize-path (port-filename port)) raises an exception for me, because port-filename is nonsensical for my use case. <mwette>Something weird going on. Disregard until I narrow it. <mwette>I'm getting (port-filename (open-input-file "foo.h")) => "bar/baz/foo.h" <mwette>port-filename is sensitive to the %load-path