<yewscion>Hello dadinn! (ignore CB, was WM command, my bad) <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>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?