IRC channel logs
2025-01-15.log
back to list of logs
<ttz>How can I measure the size of a record in bytes? And how can I know if its members are unboxed? <dthompson>ttz: you can't, at least not from scheme. and fields are boxed. <rlb>I think we may need a better discriminator for the seek-data/hole tests in ports.test -- I know filtering was just added for darwin, but it's really up to the filesystem, and just had it crash on one of the debian buildds, guessing because it was using something unusual in the unshare envt. <rlb>i.e. probably either need to mark it unresolved, or figure out a way to tell if the fs is intended to support it. <rlb>But that's just a guess -- will try to investigate further if/when I get time. <sepeth>Hey Guile! Is there a way to invoke the repl from a running program? Like debugger statement in JS, or Python's pdb.set_trace(). <lilyp>you have the modules (system repl repl), (system repl server) and (system repl coop-server) at your disposal <graywolf>Hi :) Would anyone have an example how to do a HTTP request with a timeout (maximum run time)? I failed to find a way in the documentation... <ray1729>graywolf: I don't see anything in the docs, but you could spawn a thread to do the request and use join-with-timeout <graywolf>ray1729: Oh, look interesting. I just need to extend it to somehow use cancel-thread (I hope it will work when the thread is blocked in IO), will experiment with it in the evening <ray1729>You're right about the need to cancel the thread on timeout (I thought maybe join-thread would do that automagically, but experimentation shows otherwise). <ray1729>I tested this by adding an iptables rule to block requests to the host in the URL, seems to work as desired. <sepeth>lilyp: (system repl repl) / start-repl worked beautifully, thank you ^-^ <morenonatural>hey, y'all ... is there a path-join procedure already defined? like (path-join "/a" "/b" "c" "d") 👉🏾 "/a/b/c/d" <lechner>mwette / thanks for the expanded cdata interface. everything works as advertised, thank you! you made my life a lot easier. would you welcome any comments beyond that? <lechner>dthompson / i looked at your bstruct and likewise think that's an interesting effort. how would you describe the differences to mwette's cdata, please? <lechner>also, is wingo's effort in that direction available anywhere? <rlb>civodul: I had to mark the http inter-protocol attack test as unresolved in debian because it fails intermittently (here and on the buildds) like this: <rlb>ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - arguments: ((system-error "fport_write" "~A" ("Broken pipe") (32))) <rlb>I can also reproduce it fairly quickly (if it's the same cause) with: <rlb> $ parallel -j 3 ./check-guile -- 00-repl-server.test 00-repl-server.test \ <rlb> 00-repl-server.test <rlb>The failure is thrown from the write request. <rlb>(Wondered if that might ring any bells.) <dthompson>lechner: idk I haven't used cdata, admittedly. <rlb>civodul: also, ports.test is failing on one of the buildds in "seek from within hole" with "10", indicating I think, that the buildd's fs doesn't do holes. So I'm wondering if we should change that test to either only run when we know the fs should support the data/hole semantics we expect, or mark it as unresolved/untested/etc.? <civodul>rlb: could you try to get more info about the file system etc.? this test is already skipped on macOS due to weird sparse file semantics <rlb>I do have some code to detect the fs type, though it's not excellent because afaik, there aren't good portable ways to do that... <rlb>The errno value was 0 <rlb>i.e. it wasn't an exception it was 10 != 4096 for the seek data from hole case. <rlb>(That bup code likely works on linux, some of the bsds and macos at least because I we hear from them when it breaks :) but that's as much as I know.) <civodul>would be great if you could email the details to bug-guile, for asynchronous processing :-) <civodul>it might be that we can just change the test to tolerate that behavior <rlb>Sure. And I'll probably just hack the test on debian for now -- may be about to get 3.0.10 back into debian... <rlb>Right -- and I think that behavior is allowed, and what we'd expect when the fs doesn't do holes. I suppose it depends on what the tests are trying to achieve. If it's "does our api work whenever the fs has support", then we probably do need some out of band way to know what to expect. <rlb>civodul: I'll file one for the inter-protocol attack too -- just wanted to see if you might already know something in case it was something I might fix quickly right now. <lechner>dthompson / same is true for me, except the other way around. i like bstruct's design but don't know if it works <dthompson>it works for me on the dozens of types I am working with in my guile-sdl3 project, if that means anything <dthompson>no worries if you don't want to use it, though :) <rlb>civodul: repl-test failure was already reported #32671 -- will reply to that. <rlb>(M-x debbugs-gnu is handy) <dthompson>graywolf isn't here right now, but I saw their message from earlier about http requests with timeouts which made me think to mention this: guile's web client does not work nicely with suspendable ports right now <dthompson>open-socket-for-uri with an https:// uri returns a gnutls port <ray1729>dthompson: does that mean the call-with-new-thread/join-thread approach I suggested won't work? <dthompson>but it's a shame that async i/o in the same thread won't work <dthompson>since the gnutls port is a custom port you can't set the nonblocking flag like you could on a socket <dthompson>furthermore, you can't use 'select' on it to wait until there's data to read on that port <dthompson>so things like fiber's wait-until-port-readable-operation don't work <dthompson>as a workaround, I use (ice-9 ports internal) to access the read-wait-fd and use fdes->inport to get something I can wait on. it's gross! <lechner>dthompson / I'm not sure switching to bstruct is worthwhile for me. Nyacc's FFI defines all the types for me <lechner>something about you interface strikes me as more elegant, or scheme-y, however <lechner>dthompson / actually, i'd to sell some of your stuff to mwette <lechner>cooperate, merge and become part of the foreign function interface in Guile <dthompson>yeah would be good to converge on something that could be in guile itself. sounds like a lot of work though ;) <dthompson>it would be good to see if a third party library can emerge as the most preferred option <fnat>What's the idiomatic way to locally bind all the key-values in an alist? I.d. anything more concise than (let ((a (assoc-ref alist 'a)) ...)). <dthompson>fnat: you could write a macro to help with this but you have to know what all the keys are and specify them in the code <dthompson>sounds like you want a different data structure though, like a record <dthompson>more generally, sounds like you want an ordered data structure <fnat>Haha! Amazing, thanks, let me parse all this info, ty so much! <fnat>Ok, that solved my problem, thanks. :) <fnat>lechner: It solved my problem in a meta-way, i.e. it confirmed there's so super super simple way of doing this and that I wasn't missing anything. Since I was putting together a very little script, I ended up repeating (assoc-ref ...) a couple of times in my (let ...). <lechner>fnat / okay, thanks! just wanted to make sure proper credit is given. dpk helped with the first one. civodul wrote the second, i believe <ArneBab>sneek later tell apterix: did I miss a patch from you that I should still review? (I remember something but am not sure what) <sneek>I last saw apteryx in #guix one day and 20 hours ago, saying: and it's been processing ever since: SWH vault: requested bundle cooking, waiting for completion...\nSWH vault: Processing... [...]. <mwette>lechner: off-topic Q; I'm trying to add CAP_SYS_NICE to myself on login; I have `pam optional pam_cap.so' in /etc/pam.d/common-auth, and `cap_sys_nice mwette' in /etc/security/capability.conf, but I don't get the capability on login. Any ideas what's going on? how to get help? <mwette>yes. Oh, getpcaps for my login process gives: cap_sys_nice,cap_setfcap=i <mwette>even with that `setcap cap_sys_nice+i file' gives 'Operation not permitted' <lechner>are you the only one using that machine? <rlb>2.5 days to build on m68k, 16h on hppa, and 20m on arm64/amd64. <rlb>(quite the spectrum) <rlb>I'd hope that m68k would go much faster than that in qemu on typical current hardware... <rlb>I did try s390x in qemu on my laptop, and that was much faster than "days". <mwette>I have good memories of the old Sun 3/60 days. <rlb>(and yes, I have a local fix for the new hurd-i386 failure -- but that'll just get it back to broken "later") <mwette>I even hacked on a Sun 1. The same box on which Brian Fox created bash. <lechner>mwette / i don't want to steer you in the wrong direction, but there is a point where you might simply install pam_guile.so and explore or set capabilities from there <mwette>lechner: I'll read up. Now there's a thought. I did compile-ffi libcap. It exposed an oversight in compile-ffi which I've fixed in 2.01.5: callbacks declared as non pointers (i.e., `int (foo)(void *)') were not handled. <mwette>not handled in that compile-ffi issues an error and does not convert that function