IRC.

1 files changed, 32 insertions, 0 deletions

diff --git a/open_issues/translator_stdout_stderr.mdwn b/open_issues/translator_stdout_stderr.mdwn
index 11793582..14ea1c6d 100644
--- a/open_issues/translator_stdout_stderr.mdwn
+++ b/open_issues/translator_stdout_stderr.mdwn
@@ -11,11 +11,43 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_hurd]]
 
+There have been several discussions and proposals already, about adding a
+suitable logging mechanism to translators, for example.
+
+
 Decide / implement / fix that (all?) running (passive?) translators' output
 should show up on the (Mach / Hurd) console / syslog.
 
+
 [[!taglink open_issue_documentation]]: [[!message-id
 "87oepj1wql.fsf@becket.becket.net"]]
 
+
 [[!taglink open_issue_documentation]]: Neal once had written an email on this
 topic.
+
+
+IRC, freenode, #hurd, 2011-11-06
+
+    <youpi> about CLI_DEBUG, you can use #define CLI_DEBUG(fmt, ...) {
+      fprintf(stderr, fmt, ## __VA_ARGS__); fflush(stderr); }
+    <tschwinge> Isn't stderr in auto-flush mode by default?
+    <tschwinge> man setbuf: The standard error stream stderr is always
+      unbuffered by default.
+    <youpi> tschwinge: "by default" is the important thing here
+    <youpi> in the case of translators iirc stderr is buffered
+    <tschwinge> youpi: Oh!
+    <tschwinge> That sounds wrong.
+
+
+IRC, freenode, #hurd, 2011-11-23
+
+    <braunr> we'd need a special logging task for hurd servers
+    <pinotree> if syslog would work, that could be used optionally
+    <braunr> no, it relies on services provided by the hurd
+    <braunr> i'm thinking of something using merely the mach interface
+    <braunr> e.g. using mach_msg to send log messages to a special port used to
+      reference the logging service
+    <braunr> which would then store the messages in a circular buffer in ram
+    <braunr> maybe sending to syslog if the service is available
+    <braunr> the hurd system buffer if you want