00:01:01 ..to avoid mixing internal instances of (satisfies well-known-probably-foldable-predicate) with good old CL:SATISFIES. 00:01:19 Kryztof: I'm pretty sure it'll enable further constant folding, but we'll never get to the constant folded code anyway in safe code: some type check will fail on the way 00:02:46 I'll take anything along these lines as long as it's documented 00:06:03 saschakb [~saschakb@p4FEA0522.dip0.t-ipconnect.de] has joined #sbcl 00:26:55 (lambda () (eql :foo 42)) is constant folded into (constantly nil) 00:27:02 which isn't actually right currently. 00:31:07 though SBCL won't complain on (setq my-former-keywords::foo 42), it's still undefined behaviour. Not broken, though it could be better. 00:33:13 http://paste.lisp.org/display/126199 <- there. Not sure which if any should go in during the freeze. 00:38:31 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Read error: Connection reset by peer] 00:56:39 -!- saschakb [~saschakb@p4FEA0522.dip0.t-ipconnect.de] has quit [Quit: Verlassend] 01:05:22 -!- leuler [~user@p549055D5.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 01:42:29 Fare [Adium@nat/google/x-krcuiyhcwiatxdkk] has joined #sbcl 01:43:02 src/code/target-thread.lisp: (setf (semaphore-notifiction-%status notification) t)) 01:43:06 looks like a typo 01:43:22 interestingly, doesn't cause a failure in tests 01:44:05 (is this worth opening a bug and/or firing an email?) 01:46:28 I'm looking into creating a linkkit for sbcl as per bug 794713. I think I know how to do it with GNU ld, but am skeptical about doing it on BSD/MacOS, and have no knowledge of Windows. 01:51:40 chp [~user@c-68-45-180-238.hsd1.nj.comcast.net] has joined #sbcl 02:00:05 Fare: nobody uses try-semaphore ;) 02:01:26 obviously not 02:03:14 is there a way to have fine-grained control on where stuff is mmapped using the bsd/macos linker? I see order_file can put stuff in front, but where "front" is seems to depend on the length of various header tables, so it's a lose. 02:04:09 I think we can reserve zero-filled pages, if that's what you mean? 02:06:01 *Fare* sees -segaddr in the man page for ld and hopes 02:07:46 problem is, it seems it means putting an __attribute__ ((section("fixedaddress,code"))) after each function we want to be at a fixed address (similarly for data). 02:08:51 what are you trying to do? 02:08:57 no, I want stuff at a fixed address, so the lisp code can find it independently of what gets linked into the C runtime. 02:09:01 force the text and data segments to load at a specific address? 02:09:36 joshe: see https://bugs.launchpad.net/bugs/794713 02:09:54 ew, adding more fixed addressedness doesn't seem like the way to go to me 02:09:57 force some specific functions and data into such segments. 02:10:07 joshe: what's the way to go, to you? 02:10:22 and what's so wrong with fixed address? 02:12:13 Fare: ah, that *would* be nice. 02:12:33 Fare: and we can't frob the .o after the fact instead? 02:12:59 pkhuong: right now I'm instrumenting find-foreign-symbol-in-table to determine what addresses we *actually* need/want. 02:13:46 I'm too tired to try to understand that right now, sorry 02:14:09 pkhuong: you can frob the executable, but if any number is wired into fasls and/or the image, that won't work when you regenerate a new executable from the linkkit 02:14:12 and I'm getting flackbacks to when I had to understand emacs's horrible unexec hack 02:14:29 Fare: I mean, during the build. 02:14:58 the key thing here is: linkkit, so regenerating a new executable with additional C code inside. 02:15:12 yes. But the additional C code would come from another object file. 02:15:35 but how do you know where that object file will be loaded, until you did the final creation of the executable? 02:15:39 So my question is: if we have to do it with a section attribute, can we instead do that by post-processing object files? 02:16:04 or .S file, while we're at it. We could have our very own evil mangler :\ 02:16:27 I'm not sure what you mean. Also, I see a horror looming regarding re-linking FFI functions :-( 02:17:20 one of your solutions would involve adding a section attribute to the functions we need. 02:17:51 can we instead post-process the results of C compilation? 02:18:00 another way out is that the linkkit would NOT preserve image compatibility, instead requiring you to regenerate an image from scratch with the fasls. 02:18:14 assuming sbcl genesis is amenable to such a solution 02:18:51 If we don't preserve image compatibility, we could just abuse slam.sh and link in random things while building the runtime. 02:18:58 postprocess, as in, extracting data, or as in, forcing all their code to be in our segment instead of the default segment? 02:19:29 abusing slam.sh would be my fallback strategy 02:19:38 though, maybe it should be the first strategy? 02:20:18 s/extracting data/extracting address/ 02:22:28 using GNU ld, I believe I can do the forcing of segment  though only if I can predict (or postdict?) all the segments that the code will use. 02:27:55 ok, -segaddr looks like it works on macosx, but I realize indeed that unless I force all code reachable from foreign into fixed addresses with a monotonic list of object files (i.e. append-only), images won't be compatible. 02:28:12 so really, slam.sh looks like the more realistic solution 02:28:40 but that means that a linkkit must essentially have the sbcl source at hand, which kind of sucks. 02:30:19 another "solution" would be for the image to include enough linking information to re-link it when C symbols move. Or worse, when the whole image moves. 02:34:25 (win32forth did the latter to cope with unpredictability of where win32 loaded the image) 02:34:53 (is win32 more predictable now, or else how does sbcl/win32 survive?) 02:45:59 -!- homie [~levgue@xdsl-78-35-130-8.netcologne.de] has quit [Read error: Connection reset by peer] 02:47:08 homie [~levgue@xdsl-78-35-173-168.netcologne.de] has joined #sbcl 02:50:50 pkhuong: thanks a lot for the conversation. 02:54:34 I think I'll focus on a slam.sh variant for now 03:32:14 -!- cmm [~cmm@109.64.210.140] has quit [Ping timeout: 260 seconds] 03:44:00 pers [~user@96-25-162-104.gar.clearwire-wmx.net] has joined #sbcl 03:54:28 cmm [~cmm@bzq-109-64-210-140.red.bezeqint.net] has joined #sbcl 04:11:53 saschakb [~saschakb@p4FEA0E1B.dip0.t-ipconnect.de] has joined #sbcl 04:43:27 attila_lendvai [~attila_le@87.247.7.43] has joined #sbcl 04:43:27 -!- attila_lendvai [~attila_le@87.247.7.43] has quit [Changing host] 04:43:27 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:51:28 -!- saschakb [~saschakb@p4FEA0E1B.dip0.t-ipconnect.de] has quit [Ping timeout: 244 seconds] 04:55:05 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 05:05:23 saschakb [~saschakb@p4FEA099A.dip0.t-ipconnect.de] has joined #sbcl 05:07:52 Fare: I have implemented "another "solution"" in the win32 fork, btw. No fixed addresses, every reference against the runtime C symbols resolved at startup. 05:09:07 ..and recently I made it work on Linux and FreeBSD as well (the same mswinmt branch, but :sb-dynamic-core feature should be enabled manually) 05:48:13 compiling on darwin, I get errors while compiling target-thread: Undefined functions: SB!EXT:GET-CAS-EXPANSION MAKE-LISP-OBJ 05:48:39 during cold boot. 05:49:01 I suspect this is related to recent changes by Nikodemus 05:50:12 akovalenko: congrats. But doesn't every ffi function have to do that, too? 05:51:16 akovalenko: still, your solution would greatly simplify the making of a linkkit 05:51:57 I suppose the next thing would be for FFI defining forms to be cached and re-evaluated when relinking. 05:53:16 Well, that makes me even more eager to see your branch merged 05:53:22 is there any way I can help with that? 05:54:56 Fare: well, it will happen, but there's probably no way to make it happen much faster.. 05:55:29 :-( 05:56:49 every other FFI function has to do it, indeed -- that's why I decided to unify sbcl.exe references with the rest.. 06:05:44 unify them? 06:06:47 so there's a list of closures #'(lambda () (setf *foo* (get-foreign-address "foo"))) to be called at initialization, or some such? 06:07:35 or maybe an alist (place . closure) where place is either a symbol or a pair (getter . setter) ? 06:07:37 Fare: the result is roughly similar, but the implementation is different (that's why it was easy to replicate that in C) 06:08:16 linkage table is a table containing (1) jmp entries for functions, (2) variable addresses for variables 06:08:21 I'm even more interested in your branch. 06:08:24 and the compiler knows about it 06:08:42 but what if I want to extend the set of functions or variables registered? 06:08:50 e.g. I want to link in libfixposix 06:08:59 linkage table is a piece of virtual memory which is damn large 06:09:20 (normally there's not much /physical/ memory behind it) 06:09:48 does load address vary on win32? 06:10:16 reminds me of old libc4 pre-ELF linking. 06:11:00 For executables, normally it doesn't (at least unless you clash with ntdll or kernel32 or something... but the default executable base address avoids this, of course) 06:11:22 ok 06:11:34 -!- chp [~user@c-68-45-180-238.hsd1.nj.comcast.net] has quit [Remote host closed the connection] 06:11:43 so where do you get the list of functions and variables to include in the table? 06:11:58 ..though I can now handle this situation, too, the original reason for linkage table prepopulation was to be able to recompile runtime without rebuilding core. 06:12:34 for initial sbcl.core, the compiler saves a list of names (with a var/fun flag) to a static symbol, and the C runtime gets it from there 06:12:54 ok 06:12:55 all the rest is a matter of dlopen/GetProcAddress 06:13:29 and when a new function/variable is added to the FFI, the table is extended dynamically and indirection goes through there? 06:13:46 does the core get loaded at fixed address? 06:13:56 yes to both questions 06:14:07 what if I want to save the address of a symbol plus offset? 06:14:25 the FFI mechanism remembers that, and the table only stores the symbol? 06:15:25 the table stores the symbol (well, actually the string name) 06:16:05 do you have to remember the object (DLL, etc.) as well as symbol name, or is it all global? 06:16:10 if a symbol+offset is necessary (as for structure accesses), just don't cache it -- do it each time and you're safe 06:16:11 (minor detail) 06:16:20 ok 06:16:30 looks great 06:16:34 congrats 06:16:35 SBCL emulates "flat namespace" by polling each and every loaded library with GetProcAddress 06:16:52 I gotta go  but really looking forward to seeing it merged. 06:17:04 polling each and every  can be expensive 06:17:30 linkage-table per se is the mainline thing, as well as its extension. I just (1) made it fully work for windows, fixing some stuff, and (2) made it work for "static" early names in exactly the same way.. 06:17:47 I remember dreadful performance from dlopen & co with linear search in huge DLLs. I hope they have improved since. 06:18:08 gtg 06:18:11 thanks a lot once again 06:18:14 -!- Fare [Adium@nat/google/x-krcuiyhcwiatxdkk] has left #sbcl 06:18:16 polling each and every -- well, first it's unlikely to be more expensive for 100 libraries than 1 syscall, and second, it normally happens when you load a fasl, not once per call 06:40:12 attila_lendvai1 [~attila_le@87.247.7.43] has joined #sbcl 06:40:12 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 06:40:12 -!- attila_lendvai1 is now known as attila_lendvai 06:40:12 -!- attila_lendvai [~attila_le@87.247.7.43] has quit [Changing host] 06:40:12 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:40:16 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 06:41:08 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:42:50 -!- pers [~user@96-25-162-104.gar.clearwire-wmx.net] has quit [Ping timeout: 260 seconds] 06:58:04 -!- snafuchs is now known as antifuchs 07:02:57 sdemarre [~serge@91.176.87.217] has joined #sbcl 07:20:15 -!- sdemarre [~serge@91.176.87.217] has quit [Ping timeout: 248 seconds] 07:54:52 nikodemus [~nikodemus@188-67-8-52.bb.dnainternet.fi] has joined #sbcl 07:54:52 -!- ChanServ has set mode +o nikodemus 08:08:39 plutoid [~pluto@218.206.101.179] has joined #sbcl 08:09:29 compile restas from quicklisp in sbcl failed ? any suggestion ? thx! I'm new. 08:10:21 error message, backtrace, platform, version.. 08:12:26 ...directions to reproduce 08:12:27 plutoid: and ensure (get-macro-character #\@) in REPL returns NIL; NIL 08:12:58 (if it doesn't, evaluate (set-syntax-from-char #\@ #\A) before loading restas) 08:14:00 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 244 seconds] 08:21:28 akovalenko (get-macro-character #\@) in REPL returns NIL; NIL and it still the problem. 08:21:51 well, BACKTRACE AND ERROR MESSAGE AND SBCL VERSION. What's so hard about it? 08:22:47 where to paste? 08:23:08 http://paste.lisp.org/new ? 08:24:42 http://codepad.org/AcB4PSaj 08:25:38 08:25:44 same as http://paste.lisp.org/display/126201 08:27:57 hmm. Couldn't reproduce here on Debian's SBCL 1.0.53 (there is SB-DI:DEBUG-SOURCE-NAMESTRING, and it's fbound).. 08:28:50 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 08:30:54 akovalenko so..? any other solution? 08:31:28 we have to learn what happened, before there can be a solution. 08:32:16 plutoid: type (lisp-implementation-version) in the debugger, just to check 08:32:21 plutoid: are you sure that you're running SBCL-1.0.53? maybe you have another sbcl earlier in your path? 08:32:56 and (ql-dist:version (car (ql-dist:all-dists))) 08:33:54 (lisp-implementation-version) => "1.0.18.debian" 08:34:24 (ql-dist:version (car (ql-dist:all-dists))) => "2011-11-05" 08:34:25 well, now you know what happened :) 08:34:25 there you go then 08:34:26 that's ancient 08:35:38 either make sure /usr/local/bin is before /usr/bin in PATH, or "sudo apt-get remove --purge sbcl" 08:36:05 (and install fresh binaries from www.sbcl.org if needed) 08:37:06 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 08:37:43 en...I'll try ! THX all! 08:41:53 good morning everyone 08:53:46 nikodemus: actually, when someone claims to have 2:1.0.53.0-1 as his SBCL version, it's debian unstable, which usually has pretty recent SBCL. How it's possible for 1.0.18.debian to coexist is an interesting question (there is no infrastructure for multiple version coexistance of SBCL in debian...) 08:57:58 one is maybe in /usr/local ? 08:58:30 impossible because of 1.0.18.debian ;;; <= note the suffix 08:58:54 oh you mean it's via the package manager....yes that should not be possible..... 08:59:26 so I can see no natural way to get into such a mess without (save-lisp-and-die "/usr/local/bin/sbcl" :executable t) or something.. 09:01:44 or he got old sources, and installed it..... 09:01:49 apt source or so... 09:04:00 that's not easy. (specifically, to get 2:1.0.53... from dpkg -s /and/ to get "1.0.18.debian" from l-i-v, it's not enough to rebuild the package). I wouldn't really care if it's something "unnatural" that requires user's hard work to get into.. 09:05:55 but if it's something caused by common-lisp-controller (which is possible, as it once included a save-lisp-and-die-based thing for managing lisp images), it would be good to know for future troubleshooting. 09:18:14 akovalenko: my guess is that plutoid asked apt-get search or show or something for the available version, instead of the installed one 09:18:50 akovalenko: which in turn may have been pinned, and hence prevented from being updated 09:19:27 nikodemus my vps server old version ,my desktop is new one... 09:20:04 akovalenko: what would be good would be a debian recipe for using the debs for sbcl with minimum pain. ie. "this is how you set up to use SBCL from unstable without messing up the rest of your system" 09:20:24 including directions for disinfecting it from common-lisp-controller 09:56:46 -!- plutoid [~pluto@218.206.101.179] has quit [Quit: Leaving] 10:03:09 -!- scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has quit [Read error: Connection reset by peer] 10:04:07 nikodemus: seems that if you're on unstable, and if you have your own .sbclrc, no infection happens. However, thanks to new ASDF configuration system, stuff from /usr/share/common-lisp still enters the picture (from /etc/common-lisp/source-registry.conf.d/) 10:39:42 -!- cmm [~cmm@bzq-109-64-210-140.red.bezeqint.net] has quit [Ping timeout: 244 seconds] 10:41:34 cmm [~cmm@bzq-79-183-68-139.red.bezeqint.net] has joined #sbcl 11:00:31 -!- nikodemus_ [~nikodemus@cs181056239.pp.htv.fi] has quit [Ping timeout: 248 seconds] 12:04:04 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 12:04:05 attila_lendvai1 [~attila_le@87.247.9.52] has joined #sbcl 12:56:40 Posterdati [~tapioca@host133-226-dynamic.10-87-r.retail.telecomitalia.it] has joined #sbcl 13:46:39 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 13:46:48 G'morning all. 13:51:37 -!- homie [~levgue@xdsl-78-35-173-168.netcologne.de] has quit [Read error: Connection reset by peer] 13:52:47 homie [~levgue@xdsl-78-35-173-168.netcologne.de] has joined #sbcl 13:56:24 -!- homie [~levgue@xdsl-78-35-173-168.netcologne.de] has quit [Read error: Connection reset by peer] 13:57:34 homie [~levgue@xdsl-78-35-173-168.netcologne.de] has joined #sbcl 14:01:37 -!- saschakb [~saschakb@p4FEA099A.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 14:11:33 Lovely. A block (which appears to be setting up a debug catch) dumping out directly into an LRA header. 14:12:34 drdo [~user@2001:690:2100:1b:1e65:9dff:fe64:8b4b] has joined #sbcl 14:13:20 Hum. And seems to be a regression? 14:19:21 the eric's ppc failure? 14:19:30 Yeah. 14:19:54 leuler [~user@p54903537.dip.t-dialin.net] has joined #sbcl 14:20:17 How on earth do you get an LRA header in the middle of nowhere, though? 14:20:37 Oh. I know. That's the catch entry. 14:20:45 ... isn't it? 14:22:47 nyef: can you isolate it as being dependent on the "insert-debug-catch-tag" policy -- whatever the exact name was? 14:25:21 Just throw (sb-c::insert-debug-catch 0) into the optimize declaration after (debug 2)? 14:25:47 Yeah, that clears it up 14:26:22 And, again, it's doing a fall-through into an NLX-ENTRY. 14:27:44 in ir2opt.lisp, what if you adjust (flet ((jump-falls-through-p to always return nil? 14:28:16 or better yet, comment out (delete-fall-through-jumps component) from ir2-optimize 14:29:32 http://paste.lisp.org/display/126213 for the trace output. 14:29:43 Let me look at ir2-optimize a sec. 14:31:07 Hacking ir2-optimize didn't help. 14:32:02 -!- homie [~levgue@xdsl-78-35-173-168.netcologne.de] has quit [Read error: Connection reset by peer] 14:32:40 (defun sb-c::drop-thru-p (x y) nil)? 14:33:22 homie [~levgue@xdsl-78-35-173-168.netcologne.de] has joined #sbcl 14:35:01 Nope. 14:35:17 And might I say that using an abbreviation for "through" really doesn't help the good spellers of the world. 14:41:01 *akovalenko* thought that "thru" is equally good, though more rare (some people have trouble with "though" and "through" when learning English, and sometimes I recommend to use "thru" for the latter; well, it helps memorizing the distinction, anyway..) 14:41:26 don't forget "thorough" 14:41:53 I always have trouble remembering which town names end in "boro" and which ones end in "borough". 14:42:23 apocryphal tale: some americans asking how to go to "loo-guh-buh-roo-guh" 14:42:35 (Loughborough, "luff-buh-ruh") 14:44:15 ... Yeah, I'd probably screw the first part of that up, too. The "ough"->"uff" isn't something I run into very often. 14:44:59 that's a bit tough 14:45:25 "draft" beer is another example. 14:45:40 *leuler* coughs 14:47:43 one of my PhD students, doing home brewing, presumably made draft beers 14:49:06 :-) 14:49:44 nyef: my bad. I don't even remember why I wrote it that way. 14:50:15 *earmoughs* 14:50:15 pkhuong: The real question, though, is why it's trying to fall through into an NLX-ENTRY. 14:50:33 normally falling through to somewhere is because of a type system inconsistency which has caused something to merrily delete a whole bunch of blocks 14:50:41 I say "normally" -- that's what I most often experienced 14:50:59 nyef: well, didn't you just try without any fall-thru-elimination without success?.. 14:51:35 akovalenko: Which just means that it's not introduced during /that/ optimization pass. 14:51:54 It doesn't change that the code still falls through. 14:52:30 nyef: you can disable ir2opt completely just in case. There's some DCE in there. 15:09:39 -!- homie [~levgue@xdsl-78-35-173-168.netcologne.de] has quit [Read error: Connection reset by peer] 15:09:42 The issue happens during ir1, it seems. The faulty block has c47 as its only successor, like all the blocks that don't return (error or tail call). 15:10:43 homie [~levgue@xdsl-78-35-176-111.netcologne.de] has joined #sbcl 15:17:09 wait, a platform issue during ir1? 15:17:26 or does it go wrong -- without symptoms -- elsewhere too? 15:20:31 Well, it probably wouldn't occur on x86oids, because they have unwind-to-frame-and-call. 15:20:41 And we have no reports from any other non-ppc system. 15:21:46 oh, right. unwind-to-frame-and-call matters for ir1 too 15:23:53 ok, i can reproduce it on x86-65 15:23:56 64, even :) 15:24:25 remove unwind-to-frame-and-call from *features*, and recompile the ir1 and ir2 functions that conditionalize on it 15:26:10 and then (setf sb-c::*check-consistency* t) catches the type becoming NIL 15:26:46 \o/ 15:27:17 Wonderful. So I can now go back to trying to figure out what's going wrong with my backtrace? 15:30:22 yes :) 15:33:38 ... How on earth am I getting an LRA of # ? 15:39:24 here's the core problem: (values-type-p *wild-type*) 15:39:27 => NIL 15:40:40 or rather it's usage in the truncate deftransform 16:07:55 -!- homie [~levgue@xdsl-78-35-176-111.netcologne.de] has quit [Read error: Connection reset by peer] 16:09:02 nikodemus: single-value-type-p ? 16:09:31 homie [~levgue@xdsl-78-35-176-111.netcologne.de] has joined #sbcl 16:11:14 tcr1 [~tcr@95-88-46-7-dynip.superkabel.de] has joined #sbcl 16:11:49 pkhuong: we don't have that, and type-single-value-p isn't right either 16:12:23 i'll do the principled thing and add a new function 16:14:35 ... and then in a couple of years you'll discover that you wrote the same new function, six years ago? 16:14:45 hah 16:14:59 maybe values-type-p should be T for *wild-type* 16:15:22 most of the values-foo functions at least seem to support it 16:19:49 *wild-type*, source of countless bugs. 16:21:14 while this is building... 16:21:43 i looked at our "can't run with locale C if pathname constains non-ascii chars" problem 16:23:18 the culprit is *default-external-format* (set from the locale), not the locale directly.. 16:23:26 well, yes 16:23:48 TODO make it use native unicode command-line on win32 16:24:15 how do people feel about "try a couple of different external formats, falling back to latin1 if they fail" as a approach to our internal machinery that needs to deal with pathnames before any user code is run? 16:24:25 -!- homie [~levgue@xdsl-78-35-176-111.netcologne.de] has quit [Read error: Connection reset by peer] 16:24:45 (on the posix-side -- i defer to anton's choises on the windows side) 16:25:12 btw, was it a problem with finding embedding core in the executable..? 16:25:27 ..no, it was *posix-argv*. 16:26:49 the real thing is to add *posix-argv-octets* for unix, and migrate to it internally 16:27:03 well, the first problem was surviving posix-getwcd without dying :) 16:28:15 cwd("/") with a warning about it? 16:28:56 Every solution looks broken, though. 16:29:05 nah. try locale encoding, try utf-8, fall back to latin-1 16:29:22 milanj [~milanj_@178-223-158-248.dynamic.isp.telekom.rs] has joined #sbcl 16:29:44 no, actually 16:29:58 getcwd cannot be a wide encoding 16:30:19 because it must be null terminated, and wide chars mess that up 16:30:26 feh 16:30:27 utf-8 is not wide 16:30:41 no, but the locale encoding might be, and could accidentally succeed 16:31:11 nikodemus: it's totally unrealistic nitpicking 16:31:37 well, that didn't work 16:31:40 any Unix worth its name won't be able to read its own /etc/fstab in non-ascii-superset encoding.. 16:31:45 The value # is not of type SB!KERNEL:ARGS-TYPE. 16:32:38 right. so check locale for width, if 8-bit or variable-length try it, then utf-8, then latin1 16:32:48 us the result as *default-pathname-external-format* 16:32:52 use, even 16:34:28 Btw, nowadays desktop environments rely on UTF-8 filenames, disregarding locale. (well, it doesn't matter too much when most locales are UTF-8 themselves, but..) 16:35:15 (G_BROKEN_FILENAMES & G_FILENAME_ENCODING are good keywords for looking it up w.r.t. gtk + gnome) 16:36:15 might follow their lead. 16:36:47 it can be even more well-founded, that is, something like LSB spec, for example... 16:38:22 what about rest of the world? macs have utf-8 filenames. i've no idea about *bsd 16:38:25 ... what... the... hell?!? There's a window of opportunity in every &MORE function entry on PPC for an asynchronous event to come along and corrupt the function arguments? 16:39:07 Safepoints should be everywhere! 16:39:39 No, but utter stupidity shouldn't be in our backends. 16:41:12 Guess there's not much to do beyond pushing it to my stack. 16:41:23 *akovalenko* loves the HEAD's commit message. Can you fix bug in semaphore notification objects when it's not notification (where is the bug, then?) 16:42:09 akovalenko: read more carefully :) 16:42:11 *akovalenko* got it. 16:42:35 Hrm. Actually, might not be broken. I'll have to take a closer look at what's really going on. 16:43:07 We're still in freeze, aren't we? 16:43:52 yes 16:44:14 it seems that outside of linux world, nobody ever thinks "maybe the OS is broken". Is it mostly "we have to live with it anyway", or "serious system vendors wouldn't make such a bug"? 16:44:25 Busy freeze period. 16:44:53 downright placid in terms of commits, really 16:44:58 akovalenko: More likely to be the former. 16:48:21 huh. it seems i've accumulated 16 commits to my pending tree during this week 16:53:09 I think the former as well 16:54:23 After all, no serious system vendor would cause SIGINT to occasionally not be delivered... 16:55:08 pkhuong: i'm not sure i understand your comment re. broken weight 16:58:36 nikodemus: check-integer could use a backtracking search as well. 16:59:28 oh, right 16:59:59 i'm a bit miffed that i couldn't cook a forward constraint solution, actually 17:15:10 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 17:15:37 *nyef* sighs. 17:16:02 Well, I figured out a small optimization for PPC undefined_tramp, but I'm still not understanding the failure mode for backtrace. :-/ 17:16:55 -!- nikodemus [~nikodemus@188-67-8-52.bb.dnainternet.fi] has quit [Ping timeout: 260 seconds] 17:24:25 prxq [~mommer@mnhm-590c01b5.pool.mediaWays.net] has joined #sbcl 17:25:58 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 17:38:59 nikodemus [~nikodemus@87-95-54-33.bb.dnainternet.fi] has joined #sbcl 17:38:59 -!- ChanServ has set mode +o nikodemus 17:41:45 https://github.com/nikodemus/SBCL/commit/3d4420ecb71085a03506172fa2b1b10604210abf 18:34:33 nikodemus: Nice! 18:35:45 i'll leave it for someone else to figure out saving named configurations 18:49:42 Fare [Adium@nat/google/x-ejbdetgywzwenrmz] has joined #sbcl 18:50:48 can anyone think of a portable way to tell is is being executed as a toplevel form or not? 18:51:47 at what time? 18:51:56 you mean, inspecting a source you don't control with a compiler you control 18:52:06 or running on a compiler you don't control in a source you control? 18:52:29 (eval-when (:compile-toplevel :load-toplevel) (print 'yes)) ? 18:52:34 no 18:52:43 a toplevel form under EVAL 18:52:45 tcr1: *never* omit the :execute clause 18:52:55 tcr1: I can't imagine any good reason to 18:53:02 He asked for it? 18:53:12 Fare: plenty of good ones 18:53:23 Yeah that too 18:53:33 tcr1: what if you're loading the source instead of compiling it? You still need the :execute 18:53:45 trying to figure out if our (let () ...) => (locally ...) transformation inside the simple evaluator is actually legal 18:54:45 semantically the subforms of LOCALLY are toplevel forms, whereas subforms of LET are not 18:54:51 nikodemus: Give it a side-effect, then check the side-effect at compile-time? 18:55:05 but since it's under EVAL, i can't think of an easy way to tell 18:55:32 nikodemus: Might it be used during processing? (e.g. to evaluate :compile-toplevel)? 18:55:34 There are a number of cases where toplevelish things need to be recognized by the compiler but non-toplevelish things don't... 18:55:37 nyef: but EVAL only processes :EXECUTE, which is also processed as non-toplevel 18:55:46 If not now, maybe one will be tempted at some point 18:56:41 defuns, etc, may emit declarations in a toplevel form, but not if in a non-toplevel form, innit? 18:57:21 Fare: yes, but mostly that all actually happens via EVAL-WHEN 18:57:25 though it's certain to happen as in a (let () ) I'm not sure these declarations can do wrong unless it's a defmacro 18:57:36 so under EVAL the distinction is mostly lost 18:57:38 nikodemus: What if you make it transform it to ((lambda () )) ? 18:57:58 (let () (defmacro )) ==> only at runtime, whereas (locally () (defmacro )) ==> at compile-time, too ? 18:58:21 tcr1: sure, but i can just as well punt to %simple-eval in the first place 18:58:22 ...but not in eval. 18:58:42 what about (let () (defmacro foo ) (foo)) ? 18:58:58 vs (locally () (defmacro foo ) (foo)) ? 19:00:54 that works 19:00:59 excellent, thanks 19:01:05 what works? 19:01:43 I'm actually rather surprised that (let ((x 1)) (defmacro foo () x) (foo)) doesn't work in eval. 19:01:53 for my test case 19:02:10 foom: welcome to CL. :-( 19:02:13 foom: in evaluator-mode :interpret it will 19:02:23 nikodemus: that's a bug 19:02:34 isn't it? 19:08:17 homie [~levgue@xdsl-78-35-176-111.netcologne.de] has joined #sbcl 19:08:22 why? 19:13:01 I'm now reading the CLHS again, looking for how macroexpansion is specified... 19:14:03 but at least, it doesn't fit my mental model of how macroexpansion works: first you expand each toplevel form, then you evaluate it. And here, that means a form has been promoted to toplevelness where it shouldn't have been. 19:15:48 but that only matters if toplevelness is observable somehow 19:16:14 (isn't that last example just a non-conforming program?) 19:16:41 oh noes, or :interpret mode doesn't seem to do late binding of macros after all 19:16:52 shows how much i use it 19:17:31 I would expect it to evaluate to 1 in :interpret mode, but it doesn't make the snippet any more conforming :-) 19:18:29 it can be conforming and have different behaviour under compilation and interpretation 19:19:01 on the other hand I can't convince myself that eval is not in fact allowed to be implemented as (funcall (compile nil `'(lambda () ,...))) 19:19:11 https://github.com/nikodemus/SBCL/commit/c3b689068ec76f5cead58a2da55e8880c4bf0972 19:20:01 "Definitions of any referenced macros must be present in the compilation environment" 19:20:48 yeah, that's the one I was thinking of. but then that leaves open the question of whether that (foo) is actually a reference to a macro :-) 19:20:52 yeah 19:21:31 mind you I know that on that page it says "all conforming programs" but under 3.1 it says "The behavior of a conforming program processed by eval and by compile-file might differ; see Section 3.2.2.3 (Semantic Constraints)." 19:21:52 -!- attila_lendvai1 [~attila_le@87.247.9.52] has quit [Ping timeout: 248 seconds] 19:22:18 oh, hey, the (normative) glossary entry for "evaluation" lets us do whatever we like. Yay 19:24:36 oh, we /do/ do late binding for macros under :interpret. i wasn't actually running under that mode after all... 19:40:24 antgreen [user@nat/redhat/x-piiiswsdojzicelj] has joined #sbcl 19:44:03 -!- whoops [u549@gateway/web/irccloud.com/x-zloewqgcabnaxdxr] has quit [Excess Flood] 19:48:18 sdemarre [~serge@91.176.87.217] has joined #sbcl 19:51:08 -!- drdo [~user@2001:690:2100:1b:1e65:9dff:fe64:8b4b] has quit [Remote host closed the connection] 19:52:26 -!- nikodemus [~nikodemus@87-95-54-33.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 19:53:26 whoops [u549@gateway/web/irccloud.com/x-qzuwvhuowclonzli] has joined #sbcl 19:55:22 Okay, that hole I thought I saw with &MORE arg processing on PPC? It looks like it really is there. 20:01:41 ... It's also there on MIPS and Alpha. Yes, the window is only a few instructions wide, but... ugh. 20:11:54 pers [~user@96-25-162-104.gar.clearwire-wmx.net] has joined #sbcl 20:13:18 Heh. The /only/ platforms which don't have the hole appear to be the x86oids... which have a comment explaining the hole and how not to get bit by it. 20:17:31 Blkt [~user@82.84.182.166] has joined #sbcl 20:29:28 -!- Fare [Adium@nat/google/x-ejbdetgywzwenrmz] has quit [Quit: Leaving.] 20:39:02 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 252 seconds] 20:44:10 Fare [Adium@nat/google/x-txkddomnxuimhmuh] has joined #sbcl 22:06:06 -!- sdemarre [~serge@91.176.87.217] has quit [Ping timeout: 244 seconds] 22:15:17 -!- antgreen [user@nat/redhat/x-piiiswsdojzicelj] has quit [Read error: Connection reset by peer] 22:23:12 -!- akovalenko [~akovalenk@95.73.53.213] has quit [Ping timeout: 248 seconds] 22:29:21 akovalenko [~akovalenk@95.72.175.162] has joined #sbcl 22:49:04 -!- Blkt [~user@82.84.182.166] has quit [Remote host closed the connection] 22:54:50 -!- prxq [~mommer@mnhm-590c01b5.pool.mediaWays.net] has quit [Quit: Leaving] 22:56:36 scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has joined #sbcl 22:56:48 saschakb [~saschakb@p4FEA1072.dip0.t-ipconnect.de] has joined #sbcl 23:22:56 -!- saschakb [~saschakb@p4FEA1072.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds] 23:34:45 so, generate-version doesn't work out very well. :( 23:35:32 Chokes if there's no tags, and there aren't any when you clone from github? 23:35:54 no. a) it should use "git merge-base HEAD origin/master" not the crap it has to determine version_root. what's there is totally broken if you're on a branch that branched from earlier than the tip of origin/master. 23:36:13 b) selecting a name to use for your branch doesn't work when you're using an autobuilder like hudson, which checks out a specific commit hash. 23:36:48 (always says "HEAD") 23:37:36 Yay for failure modes, huh? 23:38:10 (a) is trivial to fix. But I don't know what to do about (b). 23:38:23 *lichtblau* suspects this discussion could be more successfully held at a time when one of nikodemus' many nicks is present 23:38:44 yea, I need to go home now anyways. 23:47:23 saschakb [~saschakb@p4FEA1072.dip0.t-ipconnect.de] has joined #sbcl 23:48:23 -!- akovalenko [~akovalenk@95.72.175.162] has quit [Read error: Connection reset by peer] 23:55:52 -!- Fare [Adium@nat/google/x-txkddomnxuimhmuh] has quit [Quit: Leaving.] 23:57:23 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.]