IRC channel logs
2024-08-21.log
back to list of logs
<old>Easiest way then is to juste overload open(2) and change the string pointer to something else if matches the harcoded value <old>then just LD_PRELOAD it, will work even if the file is opened through C <old>that or you could start messing with ptrace .. I wouldn't recommend <old>would be nice if guile tracepoints would allow to change registers value <lilyp>Arsen, old, mwette: I think fractions with 10 in the divisor are all periodic; safe for increments of 0.5 <Xeroine>How can I read the response body from a HTTP request? I'm using `http-request` and it returns the headers fine, for some reason it returns a port to read the body from despite #:streaming? being #f. So I tried to get the port using `response-body-port` and then pass it to any of the port reading functions, I also tried `read-response-body` on the <Xeroine>response but neither of them work, I just get a "In procedure %read-line: Wrong type argument in position 1 (expecting open input port): #<closed: file 7fb3cbc8c0>" but `input-port?` does return #t for it so I don't get what the issue is. <Xeroine>Here's what I have https://bpa.st/RFAA I'm connecting to a UNIX domain socket on "/tmp/podman.sock", that's a podman socket I started to interact with it through it's HTTP API. <Xeroine>The `res` that I set there is just so it's easier to debug for me from a REPL since I'm writing this in a module <Xeroine>The response is returned with the 200 OK status and I can see the request to podman worked, I just wanna get the response body now because it has the build steps it took shown in there, I can see them if I just curl the same request <Xeroine>If anyone wants to replicate this, I ran podman with `podman system service -t 0 unix:///tmp/podman.sock` btw. <ray1729>Xeroine: http-request returns two values, so somehing like (let-values (((res body) (http-request ...))) ...) should work, or you could use (ice-9 receive) <lilyp>you should really be using srfi-71 let tho; much clearer than the alternatives <Xeroine>thanks, didn't know about it but it looks useful <lloda>srfi-71 should be built in imo <ray1729>I hadn't come across it before today, thanks for the pointer. <lilyp>lloda: well, it is shipped with guile, so that's that <Xeroine>by the way, what is `response-body-port` meant to be used for then? I just tried a `http-request` with `#:streaming? #t` and it returns the port where the body would be returned. <Xeroine>Can the response be somehow stored into a single value and then `response-body-port` is used to extract the port if `#:streaming` is `#t`? <ray1729>Xeroine: response-body-port is used internally by http-request, I think it would only be useful to you if you are working at a lower level. <Xeroine>Well thanks for the help everyone, have a wonderful day <3 <rlb>wingo: not sure they were relevant, but in case it's useful to know, I did try your recent changes yesterday, and they didn't improve things on i386. And wrt the debian deadline, if nothing changes, I'll probably start the "backout" work early next week to have some time to deal with any difficulties (before guile's removed from debian, and it gets even more complex). <old>rlb: Guile is been removed from Debian?? <rlb>(Since I'm not sure I've ever downgraded a package in unstable.) <old>sorry, I'm out of context here <rlb>No, that's what I'm going to prevent :) <rlb>Summary - guile's a "key" package, and 3.0.10 is broken on all 32-bit archs right now (I think not just in debian), but I only found that out *after* I packaged it and uploaded to unstable. <old>How so is it broken on 32 bit hm <rlb>So it's scheduled for autoremoval, but of course the right answer is to either fix 3.0.10, or to downgrade for now. <rlb>I've just been putting off the latter, in the hope we might hae a fix before the deadline, because it'll be a little odd, i.e. we'll have a "3.0.10...really3.0.9-1" version for a while, and it'll make some flavor of mess in debian's guile repo, but it's not the end of the world. <rlb>(compilation problem, early in the build) <rlb>ACTION guesses long vs u/i64 vs arch issue <rlb>I poked at it a *little*, but I don't know the relevant code nearly well enough to be very useful there yet. <rlb>If *you* do, you can easily reproduce it in a i386 chroot/unshare/vm/whatever :) <dsmith>rlb, Is it just x86 32bit or is it *all* 32bit? <dsmith>rlb, Did you say you were able to bisect that to a certain commit? <rlb>Of course, that might or might not be the culprit :)