00:00:30 -!- jangle [~jimmy1984@50.241.129.73] has quit [Quit: jangle] 00:15:03 ipmonger_ [~IPmonger@pool-72-94-39-57.phlapa.fios.verizon.net] has joined #ccl 00:17:11 -!- ipmonger [~IPmonger@pool-72-94-39-57.phlapa.fios.verizon.net] has quit [Ping timeout: 260 seconds] 00:17:11 -!- ipmonger_ is now known as ipmonger 00:23:18 -!- DataLinkD2 [~DataLinkD@1.144.130.123] has quit [Quit: Disconnecting -- bye] 00:47:52 -!- ipmonger [~IPmonger@pool-72-94-39-57.phlapa.fios.verizon.net] has quit [Quit: ipmonger] 01:00:41 ipmonger [~IPmonger@pool-72-94-39-57.phlapa.fios.verizon.net] has joined #ccl 01:12:47 DataLinkDroid [~DataLinkD@1.144.63.0] has joined #ccl 01:22:13 -!- DataLinkDroid [~DataLinkD@1.144.63.0] has quit [Ping timeout: 256 seconds] 01:22:55 DataLinkDroid [~DataLinkD@1.144.63.0] has joined #ccl 01:38:58 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #ccl 01:46:04 -!- gleag [~gleag@71.175.broadband2.iol.cz] has quit [Quit: Odcházím] 02:25:58 Fare [fare@nat/google/x-uczibzapxkqqanzs] has joined #ccl 03:07:20 -!- Fare [fare@nat/google/x-uczibzapxkqqanzs] has quit [Quit: Leaving] 03:39:45 -!- ipmonger [~IPmonger@pool-72-94-39-57.phlapa.fios.verizon.net] has quit [Quit: ipmonger] 03:41:06 -!- DataLinkDroid [~DataLinkD@1.144.63.0] has quit [Quit: Disconnecting -- bye] 04:44:47 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 05:43:26 -!- svs_ [~svs@104-252-AGAVEBB-NM.abq.nm.agavebb.net] has quit [Read error: Connection reset by peer] 05:43:56 svs_ [~svs@104-252-AGAVEBB-NM.abq.nm.agavebb.net] has joined #ccl 05:54:30 -!- svs_ [~svs@104-252-AGAVEBB-NM.abq.nm.agavebb.net] has quit [Ping timeout: 264 seconds] 06:17:59 Hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has joined #ccl 07:16:38 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 240 seconds] 08:25:33 -!- ivan`` [~ivan@unaffiliated/ivan/x-000001] has quit [Ping timeout: 245 seconds] 08:32:07 ivan`` [~ivan@unaffiliated/ivan/x-000001] has joined #ccl 08:40:40 ogamita [~t@77.104.4.54] has joined #ccl 11:28:00 ipmonger [~IPmonger@pool-72-94-39-57.phlapa.fios.verizon.net] has joined #ccl 11:34:47 segv- [~mb@95-91-242-104-dynip.superkabel.de] has joined #ccl 11:38:11 -!- Hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has quit [Remote host closed the connection] 12:07:02 gleag [~gleag@71.175.broadband2.iol.cz] has joined #ccl 12:22:27 ogamita` [~t@77.104.4.54] has joined #ccl 12:23:45 -!- ogamita [~t@77.104.4.54] has quit [Ping timeout: 240 seconds] 12:45:58 -!- ogamita` is now known as ogamita 13:29:45 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 13:32:58 -!- ipmonger [~IPmonger@pool-72-94-39-57.phlapa.fios.verizon.net] has quit [Quit: ipmonger] 13:35:16 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Ping timeout: 264 seconds] 13:37:14 billstclair [~billstcla@unaffiliated/billstclair] has joined #ccl 13:38:27 ipmonger [~IPmonger@pool-72-94-39-57.phlapa.fios.verizon.net] has joined #ccl 14:29:18 jangle_ [~jimmy1984@50.241.129.73] has joined #ccl 14:46:21 Hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has joined #ccl 15:21:16 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 15:58:55 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 16:01:02 -!- ogamita [~t@77.104.4.54] has quit [Ping timeout: 240 seconds] 16:07:27 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #ccl 16:23:04 gendl [~gendl@c-98-250-10-50.hsd1.mi.comcast.net] has joined #ccl 16:30:26 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 16:37:30 So how often does http://svn.clozure.com/publicsvn/openmcl/trunk/windows/ccl get rebuilt? 16:38:14 I mean, so that e.g. the wx86cl.exe which comes form that version is matching the sources in that version? 16:39:31 I'm trying to test http://trac.clozure.com/ccl/changeset/15892 and wondering how much I have to build myself, or how much I can just pull from the svn repository? 16:40:16 I just tested with the wx86cl.exe which came from that trunk repository, and apparently the fix is not in there yet, 16:40:46 or the fix isn't effective for my test case... 17:01:26 gendl: It is recommended to rebuild everything. Instructions in section 2.2.4 here: http://ccl.clozure.com/manual/chapter2.2.html#obtaining-via-svn 17:04:49 That changeset is from 16hrs ago but the image in svn is 7 months old (and the executable 5 weeks). 17:08:10 thanks. Installing cygwin mingw-64 now 17:08:19 then i will try full build on windows 17:08:43 How can i see how old the image and executable in svn are? 17:09:36 http://trac.clozure.com/ccl/browser/trunk/windows/ccl 17:10:34 thanks. So when I do a svn checkout on that directory, I get a lot more than just these 4 files 17:10:39 how does that work? 17:10:56 i mean, i get the whole source tree (but without the named "source/" subdirectory) 17:11:14 So, the recommended process to get up-to-date with the image is to download the whole SVN repo and rebuild the SVN souces once with the SVN binary and the SVN image? 17:11:30 There are a bunch of svn externals that cause the client to fetch appropriate source directories. 17:11:33 yes 17:12:42 -!- Hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has quit [Ping timeout: 264 seconds] 17:13:26 (I think I finally ought to start using the trunk. I'm diving in!) 17:39:11 alms_ [~alms_@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has joined #ccl 17:39:40 gendl: If you end up having a lot of trouble trying to get a working build environment, let me know and I'll see about checking in updated Windows lisp kernel binaries. 17:42:03 -!- patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has quit [Read error: Connection reset by peer] 17:43:03 patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has joined #ccl 17:45:30 -!- patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has quit [Read error: Connection reset by peer] 17:46:44 patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has joined #ccl 17:52:04 -!- patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has quit [Quit: patrickwonders] 17:54:30 patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has joined #ccl 18:00:32 -!- patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has quit [Quit: patrickwonders] 18:03:14 patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has joined #ccl 18:03:49 -!- segv- [~mb@95-91-242-104-dynip.superkabel.de] has quit [Remote host closed the connection] 18:04:20 segv- [~mb@95-91-242-104-dynip.superkabel.de] has joined #ccl 18:05:54 pmcl-kernel.o: In function `lazarus': 18:05:55 > /cygdrive/c/users/dcooper8/genworks/cl-dev/ccl-win/lisp-kernel/win32/../pmcl-kernel.c:1644: undefined reference to `start_lisp' 18:06:02 etc. etc. 18:06:25 while it's trying to do ;Building lisp kernel ... 18:09:35 o wait 18:09:47 i had previous errors because of "m4: command not found" 18:09:55 after I installed cygwin's m4, 18:10:01 i neglected to clear the old .o files. 18:10:14 I was about to ask if you had installed m4. 18:10:25 so now I just cleared the old *.o files 18:10:34 and redid the (rebuild-ccl :full t) 18:10:41 and now it seems to have completed everything successfully 18:11:52 last message is: "Wrote heap image #P"C:/users/dcooper8/genworks/cl-dev/ccl-win/wx86cl.image" 18:11:57 that looks like a good message. 18:12:15 It sounds like it worked. 18:12:22 i'll try the 64-bit one now. 18:12:32 Then I'll test the change set. 18:17:15 So how does it manage to overwrite the wx86cl.exe when that executable is already running? Doesn't Windows lock files to prevent that kind of thing? 18:24:08 I always build the lisp kernel binaries separately, and do (rebuild-ccl :clean t). I'm kind of surprised that :full t worked on Windows. 18:24:48 when I run it now it announces "Welcome to Clozure Common Lisp Version 1.10-dev  " 18:24:55 gendl: http://trac.clozure.com/ccl/wiki/WindowsNotes 18:25:19 It says "Additionally, because of Windows file-sharing issues it's not possible to overwrite an executable file (.exe) while it's running, so on Windows, trying to use the :FULL T option to REBUILD-CCL will fail." 18:25:53 If it works now, perhaps the page ought to be updated at some time (after release?) 18:26:23 somehow it worked from inside the cygwin shell, both 32-bit and 64-bit. the .exe files are clearly overwritten with new timestamp. 18:28:35 I'm surprised at the idea of CCL being Cygwin-compatible in the first place. 18:34:38 hmm i'm still getting the "Not a FASL file" error when trying to load the concatenated fasl 18:35:01 i'll try building the kernel binaries separately (looking for instructions for that) 18:35:14 cd lisp-kernel/win32 && make clean && make 18:38:06 when doing the kernel build separately, it did indeed give "permission denied" on removing the old .exe 18:39:01 while i had the .exe still running (had to quit it). 18:42:15 gendl: Hah! Windows are for quitters! :) 18:45:18 Ok. Having done the kernel build separately, then (rebuild-ccl :clean t), the ccl:fasl-concatenate seems to work properly! 18:46:10 so apparently, doing the kernel build with :full t on Windows only _seems_ to work, but actually fails silently somehow (maybe there was some error message I didn't notice, but it appeared to complete) 18:49:33 I just updated the Wiki page to mention that :full t on windows will fail "even though it may appear to have worked." 18:50:44 I don't suppose it would be useful for me to try to commit the newly built .exe and .image files? 18:50:52 gendl: When I did a :full t rebuild on CCL 1.9 Win32, the kernel build seemed to have stuck in a loop. It wasn't obvious at all what was happening. I didn't investigate further. 18:52:01 gendl: I suspect the semi-stable binaries are kept as reliable baselines? 18:52:53 "Since it's likely that relatively few users will have the GNU toolchain for Windows installed, we're probably a little better about keeping the kernel up-to-date (e.g., we try to check in an updated wx86cl(64).exe soon after a significant change is made to its sources)." 18:55:21 I suppose the question is what qualifies as "significant"  I assume the trunk sources should always be considered "semi-stable" (i.e. buildable and basically runnable), so it should be reasonable to make the kernel up-to-date w.r.t. the trunk, at any time. 18:56:02 i've noticed emails on a very infrequent basis from Clozure Assoc folks saying "I just broke the trunk" and they don't seem to like to let it stay that way. 18:56:13 The kernel kept around could easily be a release one. 18:56:48 After all, one would think that the story of CMUCL is a cautionary tale that doesn't need repeating! 18:57:22 s/kernel/image/ ! 18:58:17 Of course, whenever it happens that the new kernel can't launch an old image anymore, that would require a new semi-stable image. 18:59:28 But I suspect that this is preaching to the choir, the CCL maintainers seem to know what they're doing very well. 20:11:27 jangle__ [~jimmy1984@50.241.129.73] has joined #ccl 20:13:18 -!- jangle_ [~jimmy1984@50.241.129.73] has quit [Ping timeout: 264 seconds] 20:38:24 -!- alms_ [~alms_@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has quit [Quit: alms_] 21:02:31 -!- jangle__ [~jimmy1984@50.241.129.73] has quit [Ping timeout: 245 seconds] 23:25:37 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 23:29:22 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Client Quit] 23:46:43 -!- rme [~rme@50.43.147.243] has quit [Quit: rme] 23:53:18 rme [~rme@50.43.147.243] has joined #ccl