00:07:33 sellout- [~Adium@c-98-245-92-119.hsd1.co.comcast.net] has joined #ccl 00:56:36 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #ccl 00:57:07 ok, released 2.32 00:57:58 the deferred-warning feature is both fixed for CCL and disabled by default. 00:58:16 OK. Will commit shortly. 00:58:34 the fix loses some information as opposed to deferred warnings in the same image, but that's still progress as compared to not checking. 00:58:55 i.e. we lose method specializer information in function context 00:59:14 and values being used in the function call 00:59:24 thanks a lot 00:59:40 passes all tests on ccl 01:46:40 gendl [~gendl@c-98-250-10-50.hsd1.mi.comcast.net] has joined #ccl 01:48:34 Hi, is asdf built into the default ccl64 image for Mac, in /opt/local/bin/ccl64? 01:49:06 I admit I don't recall exactly how I installed it to end up there 01:49:21 but it seems that (asdf:asdf-version) works out-of-the-box and returns 2.26 01:49:47 although the source /opt/local/share/ccl/1.8/tools/asdf.lisp is version 2.20 01:50:04 and M-. in Slime for asdf:load-system gives me ~/quicklisp/asdf.lisp 01:54:54 Anyway basic question is what is the recommended way to manually upgrade ASDF in CCL? 01:55:22 I'd like to try the just-released 2.32. I suppose I can just load it the old fashioned way 01:57:11 no, it shouldn't be builtin there 01:57:30 but if you did compile ccl yourself and has a .ccl-init that loaded asdf... you might have lost 01:58:18 yes, if your .ccl-init loads quicklisp, and you didn't disable it with --no-init when you compiled ccl, it will have been compiled 01:58:42 and/or it won't have been compiled, but your .ccl-init loads it 02:00:46 Sure enuff, there it is plain as day "ccl-init.lisp" in my home directory. 02:00:51 I sure don't remember putting that there. 02:02:01 and its contents are: (load "home:quicklisp;setup.lisp") 02:02:27 i wouldn't have put that there because I normally don't even use the quicklisp from my home directory... 02:04:14 now.. if I do a plain (require :asdf) without any reference to quicklisp, I get 2.20 which matches the asdf.lisp shipped with CCL 1.8. 02:04:59 if i restore the ccl-init.lisp and let it do its (load "home:quicklisp;setup.lisp") then I get 2.26 which matches the ~/quicklisp/asdf.lisp 02:05:21 so that tells me that quicklisp does prefer its own version rather than the (require :asdf) version -- 02:05:49 i think that's because this version of quicklisp insists on at least asdf 2.26, so its own version will trump the version from require. 02:07:26 anyway I'll just manually force an upgrade and carry on. I'm trying to do the (call-image-dump-hook) stuff, 02:07:33 saving an image in Allegro, not CCL for now, 02:08:04 but I am using CCL to drive remote Allegro instances on various virtual machines, using our Distributed Gendl module, 02:08:21 which lets you have child Gendl objects which live on a remote host/port 02:08:33 using http (portableallegroserve for now) as the transport, 02:08:54 and all the message dependency-tracking works transparently across the local and remote objects. 02:09:33 Making this work between ANSI-mode (e.g. CCL) and Allegro modern-mode Lisps was fun (that happened in the last couple days). 02:11:45 End result will be that we build all variants of our system on all available Lisps on all OS platforms (using virtual machines), all driven from a single master CL session running on a host machine. Current setup is CCL running on host Mac system, driving Allegro on guest Linux and Windows systems. 02:23:00 gendl, quicklisp first uses (require) but if the provided asdf is too old, it uses its own 02:23:46 nice 02:49:48 RazLaptop [~raz@71.206.94.60] has joined #ccl 03:18:33 -!- DataLinkDroid [~DataLinkD@1.148.54.162] has quit [Ping timeout: 256 seconds] 03:45:36 bfulgham_ [~brent@cpe-76-173-170-144.socal.res.rr.com] has joined #ccl 05:07:10 cfy [~ilisp@unaffiliated/chenfengyuan] has joined #ccl 05:16:11 -!- bfulgham_ [~brent@cpe-76-173-170-144.socal.res.rr.com] has quit [Quit: bfulgham_] 05:48:20 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 272 seconds] 08:08:56 -!- cfy [~ilisp@unaffiliated/chenfengyuan] has quit [Ping timeout: 255 seconds] 08:18:45 cfy [~ilisp@unaffiliated/chenfengyuan] has joined #ccl 08:20:44 -!- mathrick [~mathrick@85.218.134.11] has quit [Ping timeout: 255 seconds] 08:53:05 -!- Krystof [~user@81.174.155.115] has quit [Read error: Connection reset by peer] 09:57:17 Krystof [~user@81.174.155.115] has joined #ccl 10:27:53 Guest2606 [~ilisp@115.195.172.148] has joined #ccl 10:28:27 -!- cfy [~ilisp@unaffiliated/chenfengyuan] has quit [Disconnected by services] 10:28:34 -!- Guest2606 is now known as cfy 10:28:38 -!- cfy [~ilisp@115.195.172.148] has quit [Changing host] 10:28:39 cfy [~ilisp@unaffiliated/chenfengyuan] has joined #ccl 10:56:05 mathrick [~mathrick@195.184.110.34] has joined #ccl 11:24:43 -!- RazLaptop [~raz@71.206.94.60] has quit [Ping timeout: 245 seconds] 11:51:23 -!- mathrick [~mathrick@195.184.110.34] has quit [Ping timeout: 245 seconds] 12:19:11 mathrick [~mathrick@stud-136.sdu.dk] has joined #ccl 13:30:44 Fare [~fare@173.9.65.97] has joined #ccl 13:39:04 segv- [~mb@dslb-094-222-246-092.pools.arcor-ip.net] has joined #ccl 13:46:40 -!- mathrick [~mathrick@stud-136.sdu.dk] has quit [Ping timeout: 245 seconds] 14:49:00 mathrick [~mathrick@85.218.134.11] has joined #ccl 15:01:15 -!- sellout- [~Adium@c-98-245-92-119.hsd1.co.comcast.net] has quit [Quit: Leaving.] 15:09:23 -!- cfy [~ilisp@unaffiliated/chenfengyuan] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 15:25:00 sellout- [~Adium@70.96.9.235] has joined #ccl 15:34:35 sayara_ [~sayara3@82.117.199.26] has joined #ccl 15:40:36 -!- sellout- [~Adium@70.96.9.235] has quit [Read error: Connection reset by peer] 15:43:14 sellout- [~Adium@70.96.9.235] has joined #ccl 15:55:07 alms_ [~alms_@209.6.130.32] has joined #ccl 15:55:44 -!- segv- [~mb@dslb-094-222-246-092.pools.arcor-ip.net] has quit [Remote host closed the connection] 16:10:49 -!- sayara_ [~sayara3@82.117.199.26] has quit [Quit: Leaving] 16:18:01 jsj [~smuxi@unaffiliated/jsj] has joined #ccl 17:40:44 dioxirane [~ab_init@unaffiliated/dioxirane] has joined #ccl 17:41:34 -!- dioxirane [~ab_init@unaffiliated/dioxirane] has quit [Client Quit] 17:45:24 dioxirane [~wdtcp@unaffiliated/dioxirane] has joined #ccl 18:27:58 segv- [~mb@dslb-094-222-246-092.pools.arcor-ip.net] has joined #ccl 19:04:36 sellout-1 [~Adium@70.96.9.235] has joined #ccl 19:04:43 -!- sellout- [~Adium@70.96.9.235] has quit [Ping timeout: 245 seconds] 19:06:51 -!- sellout-1 is now known as sellout 19:21:30 -!- sellout [~Adium@70.96.9.235] has quit [Quit: Leaving.] 20:10:59 -!- billstclair is now known as wws 20:16:00 sellout- [~Adium@c-98-245-92-119.hsd1.co.comcast.net] has joined #ccl 21:03:23 -!- dioxirane [~wdtcp@unaffiliated/dioxirane] has quit [Quit: leaving] 21:14:30 -!- jsj [~smuxi@unaffiliated/jsj] has quit [Remote host closed the connection] 22:22:38 can one freely toggle between (ccl::egc t) and (ccl::egc nil), doing some work in between, and expect things to work? does doing that sound horrifying/reasonable? 22:23:10 That should be OK. 22:23:39 cool... i will try it then :D 22:41:07 Interesting performance bug in CCL: prediction data for indirect branch/calls is cached wrt the lower bits of the last byte in the jump/call instruction. If they still encode information in the return address by (mis)aligning the call instruction, that effectively reduces the size of the BTB. 22:42:50 That sucks, but I don't know what else to do: CALL pushes an address on the (lisp) stack, and we can't have some arbitrarily-tagged thing there, so we have to align the return addresses so that they're tagged specially. 22:43:47 "stack maps"? 22:53:08 That implies gc safe points. CCL can gc at any instruction boundary; it's essentially always at a gc safe point. 22:54:10 stack maps could be indexed by instruction. 22:55:13 can still GC at any point -- but the GC has to be more clever in decoding data on stack 23:44:02 -!- segv- [~mb@dslb-094-222-246-092.pools.arcor-ip.net] has quit [Remote host closed the connection] 23:44:32 Just have to kick SBCL butt in other ways, but please thank pkhuong for his concern 23:54:40 does ccl run on the raspberry pi? 23:54:46 yes 23:54:53 Yes. 23:55:06 ni 23:55:07 ce