IRC channel logs


back to list of logs

<rekado>I keep having problems relating to fibers
<rekado>I’m using the fibers web server, and I keep getting occasional errors in ice-9/suspendable-ports.scm
<rekado>e.g. when I use guile-redis inside the HTTP handler
<rekado>is there a general way to avoid these problems when using the fibers web server?
<rekado>I feel that using the fiber web server is a bit too much of a hassle, because I just can’t anticipate what procedures end up breaking with suspendable ports.
<civodul>rekado: what kind of error do you get?
<rekado>it reminds me of that other problem I had, where I used http-head inside a HTTP handler.
<rekado>I ended up doing (uninstall-suspendable-ports!) before and (install-suspendable-ports!) after.
<civodul>so that file port was closed, but is it "fibers' fault"?
<civodul>there's a common idiom that could lead to that
<civodul>basically if you use dynamic-wind to automatically close ports; see Guix commit 8ed597f4a261fe188de82cd1f5daed83dba948eb for example
*rekado checks
<rekado>that was helpful, thank you
<rekado>I did use dynamic-wind and closed ports there; I assumed fibers involvement because a) it was hard to reproduce reliably and b) the backtrace mentioned suspendable ports
<civodul>good, let's hope it fixes the issue!
<rekado>hmm, unfortunately it keeps happening even though I don’t close the connection to redis at all.
<rekado>need to figure out a reliable way to reproduce this.
***X-Scale` is now known as X-Scale
<dsmith-work>Morning Greetings, Guilers
<cwebber>heya civodul, how are ya
*cwebber should be programming on other things but kinda burnt out, porting Terminal Phase from Racket to Guile
<cwebber>however now I'm a bit lost
<cwebber>I put the following in, which is mostly just me monkey-see-monkey-do'ing
<cwebber>levelsdir = $(pkgdatadir)/levels
<cwebber>dist_levels_DATA = \
<cwebber> levels/level1.txt \
<cwebber> levels/level2.txt
<cwebber>not sure how to use that info though
<cwebber>I figure the data goes in there somethow
<cwebber> seems like it's like, yeah, there's a way to do that, but I can't figures out what it tis
<cwebber>I guess the myprog-paths.h example is probably what should be done
<rekado>cwebber: what are you trying to do? (I’m not able to extract a question, and I don’t want to assume and explain something you already know.)
<cwebber>rekado: what I want to do is to have something like
<cwebber>where I can have
<cwebber>(define levels-dir "@levelsdir@")
<cwebber>or something...
<rekado>a complication with this sort of thing is that these variables are often defined in terms of other variables
<rekado>so @levelsdir@ might not be expanded to an absolute file name
<rekado>it might contain references to other variables such as $prefix.
<cwebber>rekado: so what's the solution?
<cwebber>I tried this in
<cwebber> terminal-phase/install-paths.scm
<cwebber>terminal-phase/install-paths.scm: Makefile
<cwebber> echo '(define-module (terminal-phase install-paths) #:export (levels))' >$@
<cwebber> echo '(define levels-dir "$(levelsdir)")' >>$@
<cwebber>which I guess... kinda works
<rekado>hence gross things like this:
<rekado>yes, this is a common alternative: to generate a file at “make” time where these variables can be resolved
<rekado>guix also does this at make time:
*cwebber brain breaks in half
<cwebber>I guess that does work
<cwebber>doesn't feel awesome tho
*rekado nods
<tohoyn>this is a test. please ignore.