IRC channel logs
2013-10-15.log
back to list of logs
<mark_weaver>gzg: yeah, the guile-xcb tarball has several problems. you'd best try the latest from git. <mark_weaver>the problem with it looking for guile 2.2 is fixed in git. <madsy>Exactly what happens when guile receives a SIGINT? If I start guile, call (run-server) and then interrupt it while a loop is running, the loop continues, but I get control over the server side again. <madsy>Does it spawn a new thread in the same environment? <wingo>the repl installs a sigint handler <wingo>that handler will queue an exception to be thrown from the thread that set the handler <nalaginrut>madsy: yes it's a new 'thread' but not a regular thread ;-) <madsy>I found a better way to achieve what I want. I can use (spawn-server) instead of (run-server) <madsy>The only problem seems to be that (cancel-thread th) has no effect on the thread made by (spawn-server) <nalaginrut>yes, it's not regular thread as I said, it's delimited-continuation <nalaginrut>there's no way to cancel it in current implementation I think <madsy>nalaginrut: I'm talking about a normal thread from spawn-server in this case <madsy>Nevermind the prompt you get from SIGINT <madsy>As long as threads can share the same environment, I can hotswap running code by just running it in its own thread. So I could use (thread-cancel) in the worst case to kill code. Instead of SIGINT <madsy>But alas, (thread-cancel) doesn't seem to have an effect. (spawn-server) does return a thread handle though. <nalaginrut>so it's can't be canceled in practical? dunno, I haven't met such a situation <nalaginrut>madsy: well, I tried (make-thread (lambda (x) (let lp()(display (+ 1 1))(newline)(lp))) 2), and cancel-thread seems no effect on it, is that the problem you described? <madsy>nalaginrut: Yes. except I'm calling (spawn-server), which returns the thread it creates <nalaginrut>dunno, the document says it'll be cancel in async way, but it's an infinite loop <madsy>Well, I doubt asynch means "wait more than 10 seconds" ;-) *wingo has subrs working, whee <Ankhers>For anyone that is interested in the issue I was having the other day with emacs org-mode not playing nicely with Guile. I simply updated org-mode to the latest version (on ELPA). Keep in mind, if you plan on doing this, you will want to install from a fresh emacs session. There is a bug where if you have executed an org related command, the install gets botched. <saul>Can guile-2.0 coexist with 1.8? <muep>afaik some gnu/linuxes provide both <madsy>Ah, thank the heavens I just regained my sanity <muep>though I am not sure if there are some caveats <muep>I have mostly used just the 2.0 series <saul>Thank you. (FYI, guile-2.9 is in Slackware 14.1 RC1) <madsy>I thought threads in guile 2.0.7 were broken, but it was just spawn-server/start-server who had uncancellable points. <madsy>So cancel-thread didn't work until the connections were dropped <muep>e.g. fedora provides guile 2 in the package named just guile, and guile 1.8 in compat-guile18 <madsy>Finally starting implementing my own types <madsy>If my own types don't have any references to any scheme objects, I don't need to do any gc-magic, right? <madsy>That is, either my functions are pure, or they manipulate internal C data in a Smob with no references to other Smobs <ijp>hmm, I just realised it is 10pm and I haven't done any scheming today <stis>ijp: is there more performant functional datastructures then our dlist and dhash? <ijp>I've never really looked at vhashes <stis>yea I'm using vhashes as a functional hash-map. <stis>Just curious if tree versions are worse or better in any ways