libera/#sbcl - IRC Chatlog
Search
11:54:03
Shinmera
Fwiw aside from the exception thing I have not encountered any problems on windows that can actually be blamed on sbcl.
11:58:18
Shinmera
by default when creating a gui application stdout/stderr are not used, as windows gui applications don't share that with the console that might have launched them
11:58:43
Shinmera
however, you can call AttachConsole to re-attach to the parent console, and then get the stdout/stderr handles with GetStdHandle.
12:18:51
Shinmera
replacing sb-sys:*stdout* with (sb-sys:make-fd-stream handle :output T) seems to at least not crash, but the output shown on the console is gibberish.
12:27:11
Shinmera
Hrm, cmd seems to use the 487 code page. Now to figure out what that means in sbcl
12:29:31
Shinmera
I mean, SBCL seems to run and output stuff fine normally, so I just wonder what I have to pass as the encoding
12:30:15
_death
but right, I think at some point I determined that I don't need it (maybe sbcl added it in the last few years?)
12:32:24
Shinmera
since at least afaik the ascii codes should be the same, and thus should show up fine.
12:33:32
_death
from your image it looks like some 16-bit encoding is used, though if it's ascii I'd expect the glyphs to be understandable
12:43:45
_death
but then your run-of-the-mill characters that are in ascii should've appeared intelligibly
12:46:16
Shinmera
In case SBCL wants to do this stuff automagically: https://github.com/Shinmera/deploy/blob/master/deploy.lisp#L77-L84
12:47:07
Shinmera
Probably even easier by just having to call AttachConsole before it creates the standard streams.
13:25:42
luis
Krystof: 99.9% of the pain has come and continues to come from our Common Graphics reimplementation. LUL's duty generation process got a nice 2x speed improvement. Still a few kinks here and there: exceptions, some socket issues (waiting on a closed socket takes up 100% CPU or something like that), will probably want to add a convenient way to
13:26:55
luis
Would be nice to handle stack overflows more gracefully, though that's mostly an issue during development, not so much production.
13:32:28
luis
The most serious production issue so far was due to a graphical REPL that shouldn't show up in production, but it did because of a stray BREAK, and then it ended up processing GUI events within the dynamic scope of the debugger, which binds several *print- variables, which then caused data corruption (because using with-standard-io-syntax is not