IRC channel logs

2023-10-27.log

back to list of logs

<RhodiumToad>getlogin means something completely different to getuid
<apteryx>it'd be nice to have 'mkdir-p' in the standard library, no?
<old>apteryx: yes for (mkdir #:parents? #t)
<RhodiumToad>eh
<RhodiumToad>mkdir -p is a whole lot more complex than a mkdir() call, not sure it belongs in the same function
<old>why not. It's just a flag for the user
<RhodiumToad>the way that permissions work in mkdir -p is not obvious
<RhodiumToad>the intermediate dirs either require separate mkdir+chmod or you have to mess with the umask (which is not thread-safe)
<old>you can mess with umask pretty easily by forking a process and using it only for doing the umask
<old>not quite the best option, but that's the state of multi-threading with process wide state
<old>or do manual chmod after every mkdir ; can't be that hard
<old>if python has it ..
<RhodiumToad>forking the process is not thread-safe either.
<RhodiumToad>(and if you're going to fork, you might as well exec mkdir -p after)
<rlb>and forking for a mkdir is "a lot more complex" :)
<old>there are way of forking in multi-thread that are safe
<old>sure but now you rely on coreutils
<old>shifting the problem else where
<rlb>I mostly just sympathize with having some module that's a fairly close mapping to the actual POSIX calls, though might be fine to glom the paths together in one function as long as the docs were very clear that "this path is much more complicated".
<old>the forking is actually something that has been done by project and it works if you know what you can do
<rlb>ACTION also would like to have time to examine our code with respect to the possibility of using the fooat() when they're available.
<old>althought, it is probably easier in C than Guile
<RhodiumToad>forking in threaded programs is a whole can of worms. yes, you can do some things safely. but note that malloc() is not one of those things
<rlb>"fooat() calls" I mean, i.e. mkdirat(), openat(), etc. -- if we're not already.
<rlb>e.g. wrt tree walking, etc.
<daviid>fwiw, guix has several implementations of those, mkdir-p, mkdir-p* and mkdir-p/perms, all defined mnore then once in diff modules
<RhodiumToad>no doubt they are all subtly wrong in different ways :-)
<daviid>:-) - didn't know it was that complicated, what about (system "mkdir -p foo/bar")? i understand apteryx wants a scheme version, but ...
<RhodiumToad>well, it's not actually that complicated, so I may be exaggerating
<RhodiumToad>obviously using system breaks on weird filenames unless you pay a lot of attention to quoting :-)
<rlb>ACTION would also like to add a solid (posix-sh-quote . args) or whatever we want to call it, assuming we don't already have one.
<rlb>or (posix-sh-quote args) -- whatever
<RhodiumToad>ACTION generally goes with "replace ' with '\'' and put '...' around the value" rather than trying to be Clever
<rlb>And then an maybe an rx-quote if/when we ever have a "standard" rx string syntax.
<rlb>ACTION doesn't care whether it's clever, just that it's *correct*
<RhodiumToad>the method I gave is correct :-)
<RhodiumToad>that said, it may not handle some "dangerous" multibyte charsets, but I'm not sure that those work safely in _any_ context
<rlb>Yeah, that's great -- I couldn't recall the exact rules. The main thing is to have a named function so that it's easy to get right.
<RhodiumToad>"dangerous" charsets are ones where \ or possibly ' can appear as a non-initial byte of a multibyte char.
<rlb>...ouch?
<RhodiumToad>almost nothing handles them safely.
<RhodiumToad>of the ones I know of, only Johab encoding of Korean can have ' as a non-initial byte
<RhodiumToad>(I think it can, anyway, haven't checked)
<RhodiumToad>several encodings for chinese and japanese have \ as a non-initial byte,
<RhodiumToad>I have not had to test it for these cases, but i believe the quoting method I gave is correct as long as ' cannot occur as a non-initial char
<RhodiumToad>s/char/byte
<apteryx>does someone know how to skip a whole test series (not an individual test), using srfi-64?
<apteryx>RhodiumToad: Interesting that mkdir-p has that many gotchas; but as old mentioned, since Python has it, it should be possible to review/adapt its implementation into Guile, if it's sane.
<tohoyn>daviid: BTW, what version number are you going to use for the "final release" of g-golf?
<haugh>good morning
<sneek>Welcome back dsmith-work!
<dsmith-work>sneek, botsnack
<sneek>:)
<dsmith-work>Happy Friday, Guilers!!
<apteryx>hi! any clue as to how to make this work? https://paste.debian.net/1296445/
<apteryx>(defined? 'm) always return #f
<apteryx>for some reasons
<civodul>apteryx: no, it cannot work
<civodul>‘defined?’ is for top-level variables only
<civodul>and only those that haven’t been inlined
<civodul>the ‘or’ pattern in match clauses effectively expands to two clauses
<apteryx>thanks
<apteryx>yeah, 2 clauses for each makes more sense... and forces me to refactor things into a helper
<daviid>tohoyn: this information is in every single email, ever since i started to release, the first sentence of every email :)
<tohoyn>daviid: so is it 0.8.0?
<daviid>why do you ask
<daviid>i answered your question
<apteryx>is this test not supposed to fail? (use-modules (srfi srfi-64)) (test-begin "test") (test-error "testing" 'oops (throw 'quit)) (test-end "test")
<apteryx>there's a TODO in the testing.scm sources which suggests it's half-baked currently, but I'd like to understand the half that works
<haugh>apteryx are you specifically trying to contain a quit-exception?
<apteryx>I want to test for a specific exception type using srfi-64
<apteryx>but it seems currently unimplemented, reading testing.scm
<apteryx>it'll mark the test as passed for *any* error, whatever the 2nd argument passed, which is supposed to be the exception type
<apteryx>the source simply states: ";; TODO: decide how to specify expected error types for Guile."
<apteryx>ACTION falls back to good old test-assert + guard
<haugh>okay but using something other than 'quit works for me
<haugh>it's just that (throw 'quit) generates a quit-exception which terminates Guile
<apteryx>ah? then I'm reading testing.scm wrong
<haugh>well I haven't even read that so grain of salt and all :)
<apteryx>it always seems to pass for me, e.g.: (use-modules (srfi srfi-64)) (test-begin "test") (test-error "testing" 'bad (throw 'oops)) (test-end "test")
<haugh>oooooookay I see the issue, it doesn't match
<haugh>yes
<apteryx>is there already a bug report for it? I suspect it could be fixed by using this implementation instead: https://codeberg.org/taylan/scheme-srfis/src/branch/master/srfi-tests/srfi-64.body.scm, but I haven't tried it
<apteryx>the workaround is not exactly elegant: https://paste.debian.net/1296459/
<apteryx>leaves a lot of places to shoot oneself in the foot :-)
<apteryx>ACTION writes a macro for it
<apteryx>doesn't seem reported against guile; will do
<mirai>apteryx: I think it's reported in a devel thread
<mirai>I recall reading some SRFI-64 threads in the guile MLs
<graywolf>This is interesting, in REPL, when value is set as a result of a meta command, the following command using it warns about "possibly unbound variable $1".
<graywolf>Is that expected or should I bug-repost it?
<apteryx>issue was created as bug#66776
<apteryx>mirai: ^
<apteryx>is there a way to express a match pattern to not match a symbol starting with ',' e.g. (not ('unquote (? symbol?))) ?
<apteryx>here's exactly what I'd like to fix: https://paste.debian.net/1296467/
<apteryx>I don't understantd why ,guile-git matches against the ((? symbol? module) ...) pattern
<haugh>does this answer your question? ',foo
<haugh>I think you want ((not 'unquote) (? symbol) ...)
<apteryx>do I need an ((and (not 'unquote) (? symbol) ...)) there ?
<apteryx>or it's implicit
<haugh>it's only the first element of the list that can be unquote, PRESUMABLY, though this does raise questions about your input
<haugh>s/symbol/symbol?
<apteryx>yes! thanks
<haugh>cool
<apteryx>hold on...
<haugh>you need two clauses with an `or' I think
<apteryx>this pattern seems to be what I want: ((? string? guix-spec) ((and (not 'unquote) (? symbol? m)) ...))
<haugh>yes but in the extremely unlikely event that one of your module path branches is named "unquote" you're hosed, which again points to questionable input
<apteryx>then it doesn't match '("guile-git" ,guile-git) but it does match '("guile-git" (git))
<apteryx>haugh: ah, I see what you
<apteryx>mean
<haugh>We have multiple match clauses for very good reasons! (match '("foo" ,bar) (((? string?) ('unquote . _)) (error "What are you feeding this thing?")) (((? string? spec) ((? symbol module) ...)) module))
<haugh>s/symbol/symbol?/ dangit
<haugh>I do that approximately a dozen times a day
<apteryx>thanks, I seem to keep trying to comprehend everything in a single clause ^^'
<haugh>I have written some bonkers matches when many simple clauses would have been better; I think it's a healthy part of the learning process :)
<haugh>Same with syntax-case.