00:13:03 drl [~lat@110.139.229.172] has joined #sbcl 05:21:35 sdemarre [~serge@91.176.125.157] has joined #sbcl 06:04:10 slyrus [~chatzilla@adsl-99-62-137-105.dsl.pltn13.sbcglobal.net] has joined #sbcl 06:26:55 -!- pchrist_ [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 248 seconds] 07:22:42 -!- drl [~lat@110.139.229.172] has quit [Excess Flood] 07:23:28 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 07:32:48 drl [~lat@110.139.229.172] has joined #sbcl 07:49:14 akovalen` [~user@95.73.220.203] has joined #sbcl 07:51:11 -!- akovalenko [~user@95.72.45.26] has quit [Ping timeout: 248 seconds] 08:45:42 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 260 seconds] 10:07:06 The sbcl build-script seems to bang out on Solaris: 10:07:07 id: illegal option -- u 10:07:07 Usage: id [-ap] [user] 10:07:31 On this: 10:07:32 $ grep 'id -u' * 10:07:32 make-config.sh:echo '"'`hostname`-`id -un`-`date +%Y-%m-%d-%H-%M-%S`'"' > output/build-id.tmp 10:09:34 -!- drl [~lat@110.139.229.172] has quit [Ping timeout: 276 seconds] 10:15:54 drl [~lat@110.139.229.172] has joined #sbcl 10:16:18 I've changed it temporarily to `id | sed 's/[^(]*(//;s/).*$//'`, which is ugly, but works. 10:16:24 Build for now 10:16:27 builds* 11:36:51 -!- drl [~lat@110.139.229.172] has quit [Ping timeout: 245 seconds] 11:37:28 Kryztof [~user@81.174.155.115] has joined #sbcl 11:38:23 drl [~lat@110.139.229.172] has joined #sbcl 11:46:25 -!- drl [~lat@110.139.229.172] has quit [Ping timeout: 276 seconds] 11:53:31 drl [~lat@110.139.229.172] has joined #sbcl 13:14:17 misterncw [~misterncw@82.71.241.25] has joined #sbcl 13:34:36 -!- whoops [u549@gateway/web/irccloud.com/x-wojjrhbilkkkitqu] has quit [Excess Flood] 13:34:45 whoops [u549@gateway/web/irccloud.com/x-pjunukfrsgqzosmz] has joined #sbcl 13:52:57 Krystof [~user@81.174.155.115] has joined #sbcl 13:55:11 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 245 seconds] 15:30:09 antgreen [~user@12.232.236.2] has joined #sbcl 15:36:24 -!- akovalen` is now known as akovalenko 16:01:50 -!- misterncw [~misterncw@82.71.241.25] has quit [Remote host closed the connection] 16:19:33 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Remote host closed the connection] 17:51:25 homie [~levgue@xdsl-78-35-157-41.netcologne.de] has joined #sbcl 18:48:54 rpg [~rpg@mpls.sift.info] has joined #sbcl 19:10:20 Back to trying to build sbcl 1.0.51 on Solaris, sbcl itself seems to build fine (and work), however there are some contrib problems: 19:10:23 WARNING! Some of the contrib modules did not build successfully or pass 19:10:23 their self-tests. Failed contribs:" asdf-install sb-bsd-sockets sb-posix sb-simple-streams 19:10:43 It's difficult to get anywhere without these. 19:11:50 I suppose there are headers missing for some glue-code in C. Any hints what header files are necessary? 19:12:11 I'd like to create a usable OpenCSW package with current sbcl. 19:13:19 (running the build again with full logging for further info) 19:24:41 antoszka: I guess that sb-grovel fails to find your compiler 19:26:04 (if some tweaking was required to specify compiler for building runtime, similar thing should be done for compiler invocation by SB-GROVEL) 19:29:49 indeed, contrib building does unfortunately not automatically use the same C compiler and make binary that the build scripts have detected initially. 19:30:53 The contrib's idea of making both choices configurable through environment variables is actually nice, compared to the the runtime, which hardcodes CC in the makefile. 19:32:19 I think make.sh should determine both (using the existing find_gnumake.sh, plus a new find_cc.sh) and then make certain both runtime and contribs are using those values. 19:32:53 antoszka: are you building with sun's cc, or with gcc? 20:38:39 -!- scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has quit [Remote host closed the connection] 20:39:31 scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has joined #sbcl 20:39:36 -!- rpg [~rpg@mpls.sift.info] has quit [Quit: rpg] 21:15:19 tsuru` [~user@c-68-53-57-241.hsd1.tn.comcast.net] has joined #sbcl 21:17:20 *akovalenko* now does something sensible on Windows control stack overflow 21:19:59 custom guard page for control stack seems to be broken on Windows (and broken on Wine in a different way) 21:21:34 akovalenko: absolutely; I think we should just trust the windows guard page. Is that what you're doing? 21:21:35 I decided to prefer either REPL reset or thread termination over debugger invokation -- 4k stack is not enough 21:21:49 yes, I handle EXCEPTION_STACK_OVERFLOW 21:22:41 unfortunately, wine/x64 doesn't get it right, too -- but wine/i386 works, as well as real windows /x64/i386 21:23:27 The nice part about SBCL's mechanism is, of course, that you can debug things while still running on the altstack, and choose a restart yourself. We could make the windows guard page large enough to also support that on windows, in a way that wouldn't be any less safe than on other platforms. 21:23:28 _resetstkoflw is the tricky part (it should be done after unwinding) 21:23:47 SetThreadStackGuarantee is too new 21:23:54 (Vista+, I think) 21:24:48 aha. Well, I was primarily unhappy that I didn't see a good place to do _resetstkoflw. I was hoping that you'd have a cool trick for that. 21:24:55 I think of something like an additional fiber within the same Lisp thread identity.. 21:25:34 No cool tricks, I'm just doing it in toplevel loop 21:26:16 unwind-to-frame-and-call could help here, but it seems that working with debugger frames require more than 4k stack :( 21:28:36 do something cool on >= vista and fall back to something dumb on ancient windows? 21:29:26 yes, it makes sense. (unwind-and-call would be required anyway) 21:29:42 well, available starting with Server 2008 R2 or Windows 7 if I'm reading the right page 21:30:06 it's easier to check for function presence 21:30:29 instead of comparing versions and guessing 21:30:40 agreed. 21:30:51 Wine will happily say that it's Windows7, but it won't provide SetThreadStackGuarantee 21:32:30 BTW, sorry I haven't pursued merging your code further this month; too much other stuff to do. Hopefully I get get back on it early next month. 21:32:34 I'm afraid that as a consequence, it'll become harder for you to sync with upstream for a while, before it'll become easier again. 21:33:42 up to this moment, merging was much easier than I expected it to be 21:34:26 pipping [~pipping@exherbo/developer/pipping] has joined #sbcl 21:34:39 -!- tsuru` [~user@c-68-53-57-241.hsd1.tn.comcast.net] has quit [Remote host closed the connection] 21:34:43 I hope to be able work on POSIX safepoint builds soon 21:35:00 I'm thinking that my merge will be in this order: 21:35:12 1. commit my POSIX-only safepoint changes (I've told people that I'd merge them Real Soon Now for months now, so I really need to go ahead to do that before they bit rot). 21:35:31 2. since interrupt-thread needs I/O changes, I'd like to do I/O stuff next 21:35:45 3. before windows threading can then almost just fall into place 21:36:39 ISTR you've altered global safepoint page address to be in runtime image, am I right? 21:37:07 there is a reason to prefer a constant one -- like 21000000 21:37:08 yes, I've done that (and IIRC it worked fine on Windows, but I'm foggy on what I tested where now) 21:37:33 it works, but I'm gonna support runtime-as-dll, then it won't work 21:37:59 ..until we have relocatable cores, then it'll work again :) 21:38:07 I see. Well, runtime-as-dll would be cool. But: 21:38:36 I understand the problem with reserved spaces 21:39:26 After discussion with nyef, it always seemed to me that consensus was in favour of "just" relocating everything if we ever need to do that sort of thing (instead of having trampolines, and whatever). 21:39:37 runtime-as-dll is not (only) for delivering DLLs; with some additional work, it would allow runtime hotswapping 21:40:07 x64 has a problem: "everything" that fits in 32-bit can't be relocated higher 21:40:08 IIRC genesis has most the information on the required fixups anyway, it's just that this part of fixup information gets discarded. We need to keep it instead, and could relatively easily relocate everything then. 21:40:45 ... hmm, is there a strong reason to ordinarily have parts of the core file above 32bit addresses? 21:41:07 oh, the runtime DLL would be put there? :-( 21:42:19 if we want SBCL to be usable as a library, not only as a main application, low 4G can be busy 21:47:45 I'm still waiting for decision on my sword_t/uword_t stuff 21:48:15 it's a silly issue, but (as of C code) it affects merging most. 21:48:49 akovalenko: clearly nobody cared sufficiently to speak for or against anything... 21:49:56 the feedback I got here on the channel was roughly (I'm paraphrasing) "you were raising good points there, I agree" -- the fact that most of those points were questions notwithstanding :-) 21:51:04 lichtblau: I was even considering building core (objects) with an LP64 compiler to avoid making this changes.. 21:51:18 a-la linux-targetted gcc -mrtd 21:51:28 hah! :-) No, it's a good change. Let's do it! 21:51:34 -!- Krystof [~user@81.174.155.115] has quit [Ping timeout: 276 seconds] 21:59:11 -!- sdemarre [~serge@91.176.125.157] has quit [Ping timeout: 248 seconds] 22:03:48 then another thing that no one seems to care about is a STDCALL callback type spec syntax 22:04:25 ..or everyone just hesitates to say that my choice (function (:stdcall int) ...) sucks.. 22:56:55 -!- homie [~levgue@xdsl-78-35-157-41.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 23:10:05 -!- pipping [~pipping@exherbo/developer/pipping] has left #sbcl 23:10:18 akovalenko, lichtblau: I haven't actually manually set any compiler, however cc is not in PATH, but gcc is so I presume gcc was used. 23:11:46 I'll paste the logfiles in a minute. 23:13:05 http://antoszka.pl/_STDOUT_LOG 23:13:09 http://antoszka.pl/_STDERR_LOG 23:15:15 The only tweaking that was necessary was for fixing the build-name (id -something), so I don't suppose the problem is related to that. 23:18:29 (not counting export GNUMAKE=gmake, obviously) 23:26:29 okay, SIGBUS, that's quite an ugly failure mode 23:27:00 unfortunately I don't have sparc VM running yet; I'm testing solaris only on x86 currently 23:27:35 can you try loading contribs just using asdf, so that you get an (ideally deterministic!) stacktrace for that error? 23:28:52 I'd propose testing run-program separately, with something trivial like /bin/true 23:30:54 ./src/runtime/sbcl --core output/sbcl.core --eval '(run-program "true" nil :search t)' 23:31:07 * (sb-ext:run-program "/bin/true" ()) 23:31:07 CORRUPTION WARNING in SBCL pid 13479: 23:31:07 Signal 10 received 23:31:09 Hm 23:31:44 And further: debugger invoked on a SIMPLE-ERROR: bus error at #X11CE9878 23:32:08 (SB-IMPL::STRING-LIST-TO-C-STRVEC ("/bin/true")) 23:32:09 0] 23:32:09 WARNING: Starting a poll(2) without a timeout while interrupts are disabled. 23:38:56 *antoszka*  off to sleep for a while, will have to get back to that later. 23:39:17 ./src/runtime/sbcl --core output/sbcl.core --eval '(run-program 23:39:17 "true" nil :search t :env nil)' 23:39:26 ok, one moment. 23:40:39 # 23:40:54 heh, seems to be a problem in string-list-to-c-strvec 23:41:06 Giving a bus error? 23:41:11 ..maybe something strange in /bin/env? 23:42:10 Nothing unusual, as far as I can see. 23:45:06 interesting if sap-ref-32 supposed to be aligned access or not.. 23:45:37 does Solaris give SIGBUS on misaligned access? 23:46:00 I'm suspecting (setf (sap-ref-32 string-sap size) 0) in run-program.lisp to be a culprit here 23:46:23 akovalenko: sparc does. 23:47:24 I've not a faintest idea. The second time I run that form (from the repl) I got the same bus error. 23:47:47 http://wklej.org/hash/abdeb61ac19/ 23:50:26 try replacing (setf (sap-ref-32 string-sap size) 0) with (sb-kernel:system-area-ub8-fill 0 string-sap size 4) in run-program.lisp, then load run-program lisp, then try (run-program "true" nil :search t). if the latter won't fail, try rebuilding.. 23:50:27 23:50:39 ok 23:50:47 the place in string-list-to-c-strvec 23:53:30 * (run-program "true" nil :search t) 23:53:31 # 23:53:38 Seems to have helped. 23:54:03 Shall I try to rebuild the whole of sbcl now? 23:54:15 Re-run make.sh? 23:56:18 you may manage it with make-target-2 and make-target-contrib 23:56:49 or maybe slam.sh will do the job 23:57:15 IIRC, slam.sh + make-target-contrib 23:57:49 OK, trying that. 23:58:26 people with commit access, please take care of it (the change is harmless anyway) 23:59:43 Hm, got another sig 10.