IRC channel logs

2017-02-27.log

back to list of logs

<dsmith-work>{appropriate time} Greetings, Guilers
<amz3`>o/
<amz3>o/
<OrangeShark>o/
<amz3>ijp: what's up?
<amz3>this unicode topic is so massive!
<amz3>I have never seen that
<amz3>It. must. be. interesting.
<amz3>to bad I don't I have summarizer at hand
<amz3>too bad, I don't I have summarizer at hand
<amz3>i have a nice addition idea to fibers
<amz3>n-for-each-fiber-map
<amz3>wingo: ^ wdyt?
<amz3>at least it can be good exerise
<amz3>s/exerise/lesson
<wingo>how does it work? :) anyway yes, now is a great time for experiments :)
<spk121>amz3: in summary. Linux file and env API calls require reading/writing string-like binary junk of no specific encoding. Guile strings used with Linux file and env API must be able to encode, hold, and decode junk of no specific encoding to deal with Linux API. Guile strings can't, yet.
<amz3>spk121: thank you very much
<amz3>wingo: so there is N+2 fibers. N fibers are what exec `pproc', there is one fiber that is executing `sproc' and the last is feeding the N `pproc' fibers input from LST1 ... LSTN. There is two channels, one for the `sproc' fiber that `get-message' what to do with the result of `pproc'
<amz3>and there is another channel for the feeder fiber which `put-message' LST1 ... LSTN for `pproc' fibers
<amz3>IIUC channels in fibers work in a similar fashion to pipes between multiple processus, correct?
<wingo>channels are like pipes but not buffered.
<amz3>funny stuff: guile articles are the most popular articles on my blog (hyperdev.fr)
<slyfox>wingo: WDYT of http://debbugs.gnu.org/cgi/bugreport.cgi?bug=25803 ?