IRC channel logs
2025-08-31.log
back to list of logs
<mgd>Hello. Feel like I'm missing something simple here. I'm making a http-get request to an api. I think I understand that I get the reponse headers and status code as one return value and the body as another? I read the response comes as a byte vector but I don't know what that is or how to turn it into JSON? <mgd>Or can the response be converted into a DTO type that Guile can work better with? <identity>mgd: try passing #:streaming? #true to ‘http-get’ and then using that to get the json <identity>if the json contains unicode, you will have to change the port encoding as well, or something to that effect <mgd>identity: what does #:streaming? do? <identity>‘that’ being the response body as a binary port (not a textual one, because Guile does not recognize application/json as a textual mime type) <identity>mgd: returns the response body as a possibly-decoded port <mgd>And sorry, how would I convert that to json? I was looking at the guile-json package? <identity>guile-json has a json->scm procedure that takes a port and returns a scheme value representing the json read from the port <mgd>identity: amazing. I've got the response. Thank you. I think I should be able to write code to pull out the important parts now <mgd>is there a way to make a http-get request but only return the body? <identity>mgd: no, but you could write a helper function that would just discard the headers and return the body <mgd>I'm using ice-9 receive to map each part to separate variable. I don't know if there is a better way yet <identity>mgd: ‘let-values’&co. and sometimes ‘call-with-values’ also work <mgd>Oh cool, you get the response as a list of pairs <mgd>when a variable is surrounded in percentage signs, what does that mean and is it just convention? <identity>it is a convention that definitely means something, and i can never remember what <mgd>when you use ice-9 receive, do the variable extracted only exist in the body of the receive? <identity>mgd: yes, like all other binding forms; you have return the values those variables are bound to from the body to use them outside of it <olivermead>I'm struggling to use the guile REPL's debug commands: with a script file of a single function, I'd like to set a breakpoint at a point in that function to inspect the local variables at that point. I was initially trying to use ,bs in Geiser (No procedures found at [file]:9) and I'm getting the same error with `guile -l file` from a terminal. How is this meant to be used? <olivermead>I've just done the same ,bs command with `guile --debug -l file` with the same result <old>guile 3.0.10 seems to a have break srfi-64 API <old>counting of tests is different <old>before, all tests were count globally <old>now groups are count as a single tests <old>this breaks tests using srfi-64 from 3.0.9 to 3.0.10 and really it's difficult to have compatibility here <old>is this a well known issue already? <euouae>Okay so here's what I'm doing, I have an empty guile buffer now <olivermead>I want to load it into my repl, set to break at line 9 "(apply" and inspect the contents of the-jokes <euouae>how do you set breakpoint at line 9 <olivermead>euouae: that's what seems appropriate from ,help debug <euouae>I wonder if this has to do with modules though <euouae>and you need to export that symbol <olivermead>euouae: is it not enough that I can use it in the repl? <euouae>nah it's not related to modules. I tested <olivermead>Alternatively, is there another way of achieving this that I'm missing? (wihout adding a getter to the existing function) <euouae>I have no idea, last time I tried debugging I thought that it's not very useful <euouae>For example right now I can't figure out how to print the location that the debugger has currently stopped at (the so-called program counter) <euouae>So I'm blindly ,step-ing and ,bt-ing to get a look <olivermead>euouae: if that's the case then it sounds like you've gotten further than my attempts <euouae>olivermead: one thing you can do is this: <euouae>Then you can `,break debug-stop` and use `,up` and `,locals` <euouae>as far as what the issue is with ,break-at-source <euouae>I think it might be related to the path of guile <euouae>where did you debug and what is your backtrace <euouae>I can't figure out break-at-source for the life of me <euouae>I've been looking around at Guile's source code to see how it works, but I dont know what exception is being raised. The error shown is poorly put together, since `,break-at-source nil 42` will give the same error. It does not distinguish between "file not found" and other errors. <euouae>I don't quite get what you're doing with λ args <euouae>oh args is the entire list? anyway <euouae>if you want to see `the-jokes` first you have to do ,up since you put debug-stop deeper than you should <euouae>oh I just noticed that you are using closures with (define) <euouae>well you can't access the-jokes there <euouae>it's captured in the environment <euouae>you can literally write the-jokes in the repl and you'll see it <euouae>olivermead: well, I've run out of ideas. try to contact people who work on Guile. <olivermead>euouae: Thank you very much for your help. I'm at a loss for how any of this is 'supposed' to be done <euouae>Personally after I realized that the macro system makes debugging really hard I sort of gave up on the idea of using it. <euouae>because in guile something like (foo (bar (baz))) could expand to 1000 lines of code <euouae>the debugger is not intelligent enough to "see" the macros <olivermead>So how should I be doing something like this? If I'm adamant about not adding a 'getter' and want to see the list I've got <euouae>that's one way to go about it, I'm not sure what your needs are <euouae>another option is having debug-stop take arguments; and then (debug-stop the-jokes) <olivermead>euouae: interesting, that seems like a pretty powerful way <euouae>I suspect that the guile debugger is mostly useful for those who implement guile itself <rlb>fwiw, I'd typically just print, or create functions, etc. with an eye toward debugging (so I can call them from the repl in relevant ways), or add temporary debugging-related code, or... <rlb>(definitely not saying you shouldn't want a good debugger, I just don't use them much) <euouae>It's a very different experience from C/Python <rlb>I don't use them much there either, but that's perhaps just me :) <identity>if your functions are small, then debugging them is more like writing a few tests <ArneBab>identity: I missed the i686 breakage of 3.0.10 … are there already people working on it? <rlb>ArneBab: it's fixed in main, and the relevant patches can be cherry-picked back into 3.0.10 (that's what I did for debian). <olivermead>with (define debug-stop (lambda debug-args '())) I've got a good thing going I think <rlb>But in the end we just need a 3.0.11 release. <identity>ArneBab: i think that the current master should work on i686, though i am not sure about that <euouae>olivermead_mob: (define (debug-stop . args) '()) <lechner>Hi, anyone have a Pentium handy? What is your value of %host-type, please? <lechner>rlb / sorry, I meant P6. is that i686 or i386? <rlb>Oh, right -- don't know for sure offhand. <lechner>Hi, how does Guile handle the segmented nature of foreign-library-pointers on i686, please? <ArneBab>identity: so we need to release 3.0.11 to update the guile in guix? <mwette>google AI says Pentium 6 is i686 <rlb>or cherry pick those patches for the guix version <lechner>is anyone here running Guile on something other than x86_64?