***heroux_ is now known as heroux
<cbaines>Hey, any suggestions on how to check using Guile if a particular port is in use? e.g. is there something bound to port 8080? <wingo>cbaines: make a nonblocking socket and try to bind to that port? <paroneayea>wingo: I think I'm starting to get a handle on this <paroneayea>wingo: one thing is that I would need to "pass along" the fnctl bit if someone wanted to make the gnutls-wrapped port nonblocking, but maybe I should actually do that in the gnutls port itself? dunno <paroneayea>I don't think it's possible to do that in guile currently so I guess I should just have an option to set the underlying port to be nonblocking <wingo>why would you want to do that? <wingo>the current non-blocking fcntl incantation only works with file ports <paroneayea>wingo: basically I need to set it on sockets still though right? <paroneayea>I guess I should just do that when setting up the underlying socket <wingo>paroneayea: yes do it on the underlying socket <wingo>ACTION has a patch that might work for that quadratic stack-marking issue... <paroneayea>wingo: so I guess if we switch from c_read/write -> scm_read/write then we might even be able to use the suspend'ability of the underlying port anyhow <paroneayea>because if using c_read/write, I'm guessing it'll pass through C, and then it can't suspend <paroneayea>but if using scm_read/write, it might actually just be able to take advantage of the suspending of the underlying port anyway...? <wingo>well if the read/write functions can return -1 then they can suspend <paroneayea>wingo: right, well... I can do that too, but then I guess I have to do some more careful bit-fiddling than the lazier get-bytevector-some and put-bytevector approach we're currently taking with the underlying port <paroneayea>since I guess we need to "watch for" if the parent socket returns -1 on read/write so we can "forward" that <wingo>hoo, been a month or more since programming in C... <cmaloney>not like riding a bike where you just pick up and go? <paroneayea> - Return -1 from the existing read/write and just add the read/write_wait_fd. But this means that we "detect" the read/write from the parent port. <paroneayea> - Switch from c_read/c_write to scm_read/scm_write and take advantage of the parent port suspending. But I can't figure out how to do this; it looks like the right procedures are scm_set_port_scm_read and scm_set_port_scm_write, but I can't figure out how to run them on individual ports. <paroneayea>presumably I'd want ot add it in make_custom_binary_(i/o)_port C procedures <cmaloney>Ho you have some code that an idiot (like myself) can take a peek at? <paroneayea>I don't have useful code written, but you can look at the make_custom_* procedures in libguile/r6rs-ports.c <cmaloney>Feh, doesn't work on the tablet that I'm on. ;( <paroneayea>maybe I need to do SCM_PORT_TYPE(port) before passing that in to scm_set_port_scm_read/write <cmaloney>I feel like an American trying to understand Cricket in this code <cmaloney>I carry the burdens of the USA trying to understand Cricket and miserably failing <cmaloney>(please don't explain Cricket to me. ;)) <cmaloney>What's the best way to build a debugging version of guile? (eg: gcc -g ... ) ? CFLAGS=-g? <paroneayea>it seems like scm_read and scm_write apply to the whole port type <paroneayea>I'm not sure how to set them on each custom binary i/o port :\\