10:47:07pjbjackdaniel: those kinds of hooks are very useful. They should be documented and implemented. ccl as a complete collection of them. http://paste.lisp.org/display/353883
10:47:50pjbjackdaniel: of course, the right thing to do would be to design and document them in an CDR.
10:48:28consolersI noticed some cut-paste typos in the manual page you pointed me to last time, in the example, but they were minor.
10:49:08pjbThere's also the question of the context in which they run, (threads, streams, etc). If not properly specified, it can make users' life miserable.
10:49:46jackdanielsave-application and launch hooks doesn't make much sense in ECL, because it does "ordinary" compilation, no image saving whatsoever
10:50:17pjbstill *lisp-startup-functions* may be useful.
10:53:38consolersthere is some weird interaction with the terminal that after a glitch it eventually sends all terminal (st) i/o to my /dev/xconsole -- st is started by the window manager and the wm redirects its output to xconsole
10:54:47consolersno time to dig into it now though
10:59:48jackdanieltry (finish-output *standard-output*) if its klodged on CL side
10:59:55jackdanielotherwise you may try to turn of buffering in your terminals
11:06:22jackdanielI remember I had such buffering roundtrips with ecl-android - I had buffering on CL side, on pipe (which I connected through with Java) and on Java side
11:27:26consolers(oh no, i'm sure its not the ecl side, except how the terminal gets into the weird state. after it gets into the weird state and everything all i/o gets sent to stdout, from other screens under gnu screen to)
11:28:04consolersby stdout i mean the what the stdout of the terminals parent process, the windowmanager