2017-05-13T00:53:41Z rumbler31 joined #ccl
2017-05-13T00:58:35Z rumbler31 quit (Ping timeout: 272 seconds)
2017-05-13T02:04:44Z rumbler31 joined #ccl
2017-05-13T02:14:19Z mrottenkolber quit (Ping timeout: 255 seconds)
2017-05-13T02:20:08Z _rumbler31 joined #ccl
2017-05-13T02:24:25Z _rumbler31 quit (Ping timeout: 246 seconds)
2017-05-13T02:56:05Z _rumbler31 joined #ccl
2017-05-13T02:58:05Z pierpa quit (Quit: Page closed)
2017-05-13T02:58:15Z pjb quit (Ping timeout: 260 seconds)
2017-05-13T03:00:31Z _rumbler31 quit (Ping timeout: 268 seconds)
2017-05-13T03:54:39Z pjb joined #ccl
2017-05-13T04:16:27Z sabetts quit (Ping timeout: 240 seconds)
2017-05-13T04:20:47Z pjb quit (Ping timeout: 240 seconds)
2017-05-13T04:35:49Z milanj quit (Quit: This computer has gone to sleep)
2017-05-13T04:42:03Z rumbler31 quit (Remote host closed the connection)
2017-05-13T08:22:37Z pjb joined #ccl
2017-05-13T08:43:38Z hhdave joined #ccl
2017-05-13T08:43:46Z hhdave quit (Client Quit)
2017-05-13T08:52:34Z jdz quit (Ping timeout: 264 seconds)
2017-05-13T08:57:28Z jdz joined #ccl
2017-05-13T09:04:52Z milanj joined #ccl
2017-05-13T09:08:31Z milanj_ joined #ccl
2017-05-13T09:11:05Z milanj quit (Ping timeout: 240 seconds)
2017-05-13T09:11:23Z jdz quit (Ping timeout: 255 seconds)
2017-05-13T10:00:08Z milanj_ quit (Quit: This computer has gone to sleep)
2017-05-13T11:53:58Z mrottenkolber joined #ccl
2017-05-13T12:27:16Z jdz joined #ccl
2017-05-13T12:38:44Z opusmodus joined #ccl
2017-05-13T12:38:52Z opusmodus quit (Client Quit)
2017-05-13T13:19:20Z rumbler31 joined #ccl
2017-05-13T13:45:33Z mrottenkolber quit (Ping timeout: 260 seconds)
2017-05-13T14:49:03Z edgar-rft quit (Quit: edgar-rft)
2017-05-13T15:10:01Z milanj_ joined #ccl
2017-05-13T16:58:34Z milanj_ quit (Quit: This computer has gone to sleep)
2017-05-13T18:35:27Z milanj_ joined #ccl
2017-05-13T18:53:50Z pierpa joined #ccl
2017-05-13T19:48:20Z rumbler31 quit (Remote host closed the connection)
2017-05-13T20:48:55Z rumbler31 joined #ccl
2017-05-13T20:50:19Z phoe joined #ccl
2017-05-13T20:50:27Z phoe: I have a problem with deploying CCL binaries.
2017-05-13T20:50:43Z rme: What's the problem?
2017-05-13T20:50:50Z phoe: I'm on Windows. When I ccl:save-application :application-type :console, everything always works.
2017-05-13T20:51:10Z phoe: When I :application-type :gui - the deployed binary only works whenever I run it from a msys2 terminal.
2017-05-13T20:51:19Z phoe: When I double-click it, it enters a busy loop and does nothing.
2017-05-13T20:51:30Z phoe: UNLESS I run it from CMD like "foo.exe > out.txt" - in which case it works.
2017-05-13T20:51:51Z phoe: In other words - it must have a stream to output stuff to.
2017-05-13T20:51:58Z phoe: That's what I am thinking.
2017-05-13T20:53:44Z rme: Unfortunately, this doesn't sound familiar.
2017-05-13T20:54:11Z phoe: It might be an issue in Shinmera's Qtools that manifests itself in CCL since that's what I am using.
2017-05-13T20:54:24Z phoe: I will try the most silly thing: (setf *standard-output* (make-broadcast-stream)) in build hooks.
2017-05-13T20:54:57Z rumbler31 quit (Ping timeout: 272 seconds)
2017-05-13T20:55:52Z phoe: Wrong moment - boot hooks.
2017-05-13T20:56:20Z phoe: Pfft. The silly thing does not work.
2017-05-13T20:56:24Z phoe: I'll think about it.
2017-05-13T20:57:40Z rme: The only weird Windows thing that I remember at the moment has to do with sometimes having to call ShowWindow twice in order to make the first window appear.
2017-05-13T20:59:21Z phoe: Yes. This sucks.
2017-05-13T20:59:23Z phoe: I suffer from this.
2017-05-13T20:59:47Z phoe: But I suffer from this because I launch a closed-source application that I do not control and therefore cannot call ShowWindow inside it again.
2017-05-13T21:05:52Z phoe: This is crazy.
2017-05-13T21:06:03Z phoe: Does CCL have some sort of STDOUT variable somewhere?
2017-05-13T21:07:06Z rme: There's an unexported ccl::*stdout*
2017-05-13T21:09:43Z phoe: Do all spawned threads use it by default?
2017-05-13T21:10:32Z phoe: Uh. I will see.
2017-05-13T21:19:18Z phoe: ....
2017-05-13T21:19:30Z phoe: I have a logger thread.
2017-05-13T21:20:49Z phoe: It has its *standard-output* rebound to the *standard-output* of the main thread.
2017-05-13T21:21:22Z phoe: And I commented out the part of my program where it actually writes anything to that stream.
2017-05-13T21:21:25Z phoe: Boom, works.
2017-05-13T21:21:53Z phoe: I will shrink it into a minimal test case and get back to you - it looks like something's weird where threads and streams meet.
2017-05-13T21:38:36Z rme: OK. Please make an issue at https://github.com/Clozure/ccl/issues if you think that would be appropriate.
2017-05-13T21:47:13Z phoe: rme: Sure thing.
2017-05-13T21:49:45Z rme: One thing that you might not expect is that streams are, by default, essentially thread-local.  See  https://ccl.clozure.com/docs/ccl.html#additional-keywords-for-open-and-make-socket
2017-05-13T21:49:57Z phoe: !!!!!!
2017-05-13T21:50:09Z rme: So if you want to write to a stream from multiple threads, you have to create it with :sharing :lock
2017-05-13T21:50:17Z phoe: I see.
2017-05-13T21:51:06Z rme: I don't know if this is relevant to your issue or not, but when someone says "streams and threads", that is what my internal search engine comes up with.
2017-05-13T21:52:25Z phoe: With which flags is the default *standard-output* created on Windows?
2017-05-13T21:52:56Z phoe: If it's :EXTERNAL then I guess Windows threading might cause stuff to crash and burn - like in my case.
2017-05-13T21:53:19Z rme: looks like ccl::*stdout* is created with :sharing :lock.
2017-05-13T21:56:10Z phoe: But this means that *standard-output* should not crash when written from multiple threads.
2017-05-13T21:56:17Z phoe: Unless it's uh, a windows-specific thing.
2017-05-13T21:56:29Z phoe: output handle and multiple threads.
2017-05-13T22:03:41Z rme: Microsoft's main campus is practically right next door to where I'm currently living, and half the people I meet seem to work for Mcrosoft, but that hasn't helped me know much about Windows.
2017-05-13T22:04:18Z rme: Not that I've tried very hard to learn, mind you...
2017-05-13T22:04:36Z phoe nodnods.
2017-05-13T22:04:42Z phoe: Woah.
2017-05-13T22:04:51Z phoe: I've deployed on 32-bit CCL instead of a 64-bit CCL.
2017-05-13T22:04:59Z phoe: Memory usage - 50%.
2017-05-13T22:05:36Z phoe: That's the stuff that I like.
2017-05-13T22:15:09Z edgar-rft joined #ccl
2017-05-13T22:51:25Z rumbler31 joined #ccl
2017-05-13T22:55:43Z rumbler31 quit (Ping timeout: 246 seconds)
2017-05-13T23:44:47Z phoe: How can I install ASDF 3.2.1 permanently in CCL?
2017-05-13T23:44:56Z phoe: https://pastebin.com/BE0NRcPY is the error message I get after deploying.
2017-05-13T23:45:17Z phoe: Mostly because I have (load "path/to/load-asdf.lisp") in my CCL init file.
2017-05-13T23:46:47Z rme: I don't know where you're getting that old ASDF.  ccl 1.11 bundles ASDF 3.1.5.
2017-05-13T23:47:16Z phoe: I don't know either. My copy in ~/.local/...... is fresh 3.2.1.
2017-05-13T23:47:30Z phoe: "Warning: You are using ASDF version 3.2.1 from #P"C:/msys64/home/phoe/.local/share/common-lisp/source/asdf/asdf.asd" and have an older version of ASDF (and older than 2.27 at that) registered at #P"C:/msys64/home/phoe/.local/share/common-lisp/source/asdf/asdf.asd"."
2017-05-13T23:47:34Z phoe: This does not make sense.
2017-05-13T23:47:38Z phoe: These paths are identical.
2017-05-13T23:49:27Z phoe: Okay - what I need to solve is,  ==> Encountered unhandled error: No such file or directory : #P"C:/msys64/home/phoe/.local/share/common-lisp/source/asdf/header.lisp"
2017-05-13T23:49:36Z phoe: How can I permanently install ASDF3.2.1 inside CCL?
2017-05-13T23:49:52Z phoe: So it does not need to look for any local files?
2017-05-13T23:50:42Z rme: Usually, I would expect that you would use (require 'asdf) to load the bundled ASDF.
2017-05-13T23:51:15Z phoe: Yes, but the bundled ASDF is 3.1.5.
2017-05-13T23:51:24Z phoe: I require functionality from 3.2.1 (which is LAUNCH-PROGRAM).
2017-05-13T23:53:48Z rme: If you want to replace the bundled ASDF, you could copy your updated ASDF into ccl:tools;asdf.lisp
2017-05-13T23:56:57Z phoe: I replaced ccl\tools\asdf.lisp with a newer version.
2017-05-13T23:57:09Z phoe: Now after I launch wx86cl.exe:
2017-05-13T23:57:10Z phoe: > Error: There is no package named "ASDF" .
2017-05-13T23:57:45Z phoe: when I go (asdf:asdf-version)
2017-05-13T23:58:00Z phoe: Am I expected to rebuild CCL after this?
2017-05-13T23:58:15Z rme: I have no idea why the error message is complaining about a version of ASDF older than 2.27.  That's not coming from CCL.  I seem to remember Faré saying that Quicklisp was including ASDF 2.26.
2017-05-13T23:58:48Z rme: If you start up with wx86cl --no-init, and then do (require 'asdf), does it work?