IRC channel logs


back to list of logs

<dadinn>hi all
<yewscion>Hello dadinn! (ignore CB, was WM command, my bad)
<dadinn>I've been playing around with the (ice-9 expect) module and tried to write an interact macro for it:
<dadinn>it's working reasonably well, but I would like some input on edge-cases or opinions
<dadinn>I know it's not a hygenic macro... I'm more of lispy guy, and not that familiar with syntax-rules
<dadinn>and also, the expect macro is quite dependent on capturing variables from the context (i.e. expect-port and expect-char-proc macros all have to be captured from context
<dadinn>also, in my macro implementation the (ice-9 expect) expect procedure has been renamed expect-old ;)
<dadinn>oops, also excuse my French... quite unprofessional of me! ;D
<dadinn>also, excuse my British, I've nothing against French... just a phrase over here, no stereotypes! ;D
<dadinn>to be fair, those French could use some proper bath... that smell on the tube each day!
<dadinn>shit... fuck it, I think I'v lost my PC compliance card long time! :D
<dadinn>anyways, was looking for some feedback on that macro...
<dadinn>obviously, that interact macro doesn't provide terminal-like interface. No shell autocompletion, etc. But can still work with KVM over a serial port!
***Furor is now known as Colere
***chris is now known as Guest2052
<dadinn>hi all
<dadinn>I've been trying to get this interact macro working for (ice-9 expect):
<dadinn>the problem seems to be is that by forking the process, the state hash-table in the top-level let doesn't get shared between the parent and child processes.
<dadinn>is there a way to work around this?
<dadinn>I can see there is a bit of a concurrency problem here, and my hack of trying to use a hash-table for a concurrent shared variable is the problem beneath all.
<mwette>dadinn: I get the feeling you should approach the problem differently. Sharing a hash table among two guile processes is not going to work this way.
<dadinn>mwette: what would you suggest instead?
<dadinn>mwette: also, can you explain what is the reason this is not working? Is this because hash-table doesn't get shared between different threads (not even sure if fork creates threads, or completely separate processes)
<dadinn>mwette: how could I share data between 2 forked processes? maybe I would have to write a file? and check if it exists from the other process?
<mwette>if concurrent guile is your aim why not two threads ?
<mwette>fork make a copy of the process. You get two processes with two separate hash tables.
<mwette>if you really need two processes then maybe a third process that maintains the hash table, accessed via socket api.
<dadinn>mwette: how do I do concurrent guile?
<mwette>dadinn: There are several ways. Maybe start here: