01:03:47 -!- chp [~user@c-68-45-180-238.hsd1.nj.comcast.net] has quit [Ping timeout: 240 seconds] 01:08:53 -!- borkman [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Remote host closed the connection] 01:09:14 borkman [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 01:16:07 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 240 seconds] 01:29:13 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 02:09:11 -!- samebchase [~samuel@76.73.121.203] has quit [Ping timeout: 245 seconds] 02:09:56 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 268 seconds] 02:16:40 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 02:18:17 samebchase [~samuel@76.73.121.203] has joined #sbcl 02:21:08 -!- Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has quit [Quit: Cryotank2011] 03:03:15 Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has joined #sbcl 04:18:57 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 04:30:38 saschakb_ [~saschakb@p4FEA0E9F.dip0.t-ipconnect.de] has joined #sbcl 04:34:13 -!- saschakb [~saschakb@p4FEA06B9.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds] 05:21:24 Phoodus [~foo@68.107.217.139] has joined #sbcl 05:41:13 attila_lendvai [~attila_le@87.247.9.144] has joined #sbcl 05:41:13 -!- attila_lendvai [~attila_le@87.247.9.144] has quit [Changing host] 05:41:13 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:21:42 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 07:11:01 pon1980 [~pon@195.67.88.105] has joined #sbcl 07:13:16 -!- Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has quit [Quit: Cryotank2011] 07:35:23 -!- antifuchs [~foobar@care.boinkor.net] has quit [Ping timeout: 252 seconds] 08:17:13 nikodemus [~nikodemus@87-93-56-152.bb.dnainternet.fi] has joined #sbcl 08:17:13 -!- ChanServ has set mode +o nikodemus 08:29:47 -!- pon1980 [~pon@195.67.88.105] has quit [Ping timeout: 240 seconds] 08:49:19 pon1980 [~pon@195-67-88-105.customer.telia.com] has joined #sbcl 09:09:28 So, if a thread is ptracing another process, sigchld handlers are guaranteed to be called on that same thread? 09:29:25 don't know, sorry 09:30:24 but if the os calls it there, sbcl won't move it anywhere else? 09:30:58 also, can it lose signals, if multiple instances of the same one come in short succession? 09:34:41 nikodemus_ [~nikodemus@dsl-hkibrasgw4-fe5bdf00-15.dhcp.inet.fi] has joined #sbcl 09:34:41 -!- nikodemus [~nikodemus@87-93-56-152.bb.dnainternet.fi] has quit [Disconnected by services] 09:34:41 -!- ChanServ has set mode +o nikodemus_ 09:35:08 nikodemus [~nikodemus@87-93-56-152.bb.dnainternet.fi] has joined #sbcl 09:35:08 -!- ChanServ has set mode +o nikodemus 09:52:39 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Remote host closed the connection] 09:52:57 attila_lendvai [~attila_le@87.247.9.144] has joined #sbcl 09:52:57 -!- attila_lendvai [~attila_le@87.247.9.144] has quit [Changing host] 09:52:57 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:05:46 evenson [~evenson@213.33.70.157] has joined #sbcl 10:06:03 Did :SB-LUTEX go away with sbcl-1.0.54? 10:06:22 *evenson* is trying to upgrade the macports file. 10:13:34 Seems so: http://sbcl.git.sourceforge.net/git/gitweb.cgi?p=sbcl/sbcl.git;a=commit;h=d6f9676ae94419cb5544c45821a8d31adbc1fbe8 10:13:45 And I take it that OS X is not a futex capable platform. 10:16:47 yes 10:17:15 just specify :sb-thread (you were never supposed to manually specify :sb-lutex, really) 10:17:28 nikodemus: Thanks for the confirmation. 10:18:12 evenson: you may also want to add :sb-core-compression (check the exact spelling, though -- i always misremember it) 10:18:35 Is that gonna save a lot of load time? 10:18:37 are compressed cores loaded faster? 10:19:06 no, slower. it's not used by default, but it's not available at all unless enabled at build time 10:19:33 but they /are/ smaller, so people worrying about the size of their delivered executables should like it 10:20:07 (it adds a dependency to zlib, which is why it is not in the default feature set) 10:20:25 does it uncompress it directly into memory or to a temporary file? 10:20:39 directly into memory 10:21:30 i guess it depends on the medium speed and on the CPU speed, so it may actually be faster in some configuration 10:22:05 stassats`: faster than just mmap'ing the file? i would be very surprised if so 10:22:45 how much of the mmaped file are accessed at the start up? 10:23:03 not very much, i think 10:24:19 then perhaps it'll amortize the cost better in the long run 11:02:13 mensch [~mensch@c-71-232-44-219.hsd1.ma.comcast.net] has joined #sbcl 11:05:51 nikodemus: tell me when you're done committing for today 11:06:12 (i have a small commit, but i don't want to cause unnecessary interference) 11:06:14 the madness is over 11:06:56 i may do one or two more, but they need to be tested on linux first 11:07:30 and regarding that commit, would be doing (progn ,unused-variable (%puthash ,key-temp ,hashtable-temp ,new-value-temp)) the right way to go about preventing warnings about unusage of the variable? 11:07:55 (declare (ignore ,key-temp)) 11:08:03 where? 11:08:11 ,unused-variable, even 11:08:25 in the place where ,unused-variable is bound 11:08:41 well, it's in define-setf-expander expansion 11:08:45 if it's hard to tell if it is used or not at that point, declare it IGNORABLE instead 11:08:55 ahm 11:09:06 lisppaste? 11:09:38 src/code/early-setf.lisp:487 11:11:00 ,default-temp? 11:11:21 yes, it's the ,unused-variable in my example 11:12:00 putting it into progn like this certainly works, but i thought maybe i'm missing something 11:12:13 and btw, it's https://bugs.launchpad.net/sbcl/+bug/492071 11:13:58 i think it's actually SETF that should do (DECLARE (IGNORABLE ,@DUMMIES)) 11:14:34 but i would want such warning for my own setf expansions 11:14:41 warnings 11:14:57 true 11:15:10 maybe the PROGN is TRT 11:15:21 wtf? where did these test failures come from? 11:15:42 at least i don't see any downsides with PROGN 11:16:34 me neither, really 11:23:15 udzinari [90a0621f@gateway/web/freenode/ip.144.160.98.31] has joined #sbcl 11:25:28 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 11:26:33 ok, committed, for GET, GETF, and GETHASH, are there any other accessors which have default parameter? 11:27:11 can't think of any 11:30:33 stassats`: tests! 11:31:03 i thought it wasn't significant enough for tests 11:31:16 (handler-bind ((style-warning #'error)) (compile nil `(lambda () ...))) is enough 11:31:27 otherwise there /will/ be a regression 11:31:32 ok 11:32:03 Could SBCL benefit from some sort of more general constant declaration (declaration on the general sense, not the DECLARE sense) for functions? i.e., (defun-constant foo (x) ..), guaranteeing (SYMBOL-FUNCTION foo) will never be changed? 11:32:28 *nikodemus* is a firm believer in the value "poke at it with a stick" tests. over time just such trivial tests have caught the strangest regressions 11:33:35 Quadrescence: a (declaim (sealed (function foo))) would be neat 11:34:10 or possibly just (declaim (sealed foo)) 11:34:29 patch welcome 11:35:08 I guess it'd allow more optimization potential. But I don't know specifically what it would help. 11:35:16 stassats`: you seem to have broken the build :) 11:35:35 Quadrescence: it would allow the compiler to trust derived types safely, for one 11:35:42 inconceivable! 11:36:58 http://paste.lisp.org/display/126295 11:37:14 there's sb-ext:*derive-function-types* for that 11:37:19 nikodemus, I guess if the concept is extended to methods, With Sufficient Compiler Smartness, methods could be inlined. 11:38:26 stassats`: *derive-function-types* is a /big/ hammer -- and unsafe if you accidentally redefine something with an incompatible type 11:38:31 nikodemus: of course, i forgot to test for the case when default isn't provided 11:38:37 heh 11:38:55 errands, bbl 11:39:46 -!- nikodemus [~nikodemus@87-93-56-152.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 11:46:41 -!- Kryztof [~user@81.174.155.115] has quit [Read error: No route to host] 11:47:50 fixed and added tests 11:49:17 and it even builds 12:07:45 Xof [~crhodes@dunstaple.doc.gold.ac.uk] has joined #sbcl 12:07:45 -!- ChanServ has set mode +o Xof 12:07:50 -!- mensch [~mensch@c-71-232-44-219.hsd1.ma.comcast.net] has quit [Quit: leaving] 12:14:14 gosh. Mailbombed by sbcl-foo. Much better than being mailbombed on the first of the month by Mailman 12:37:35 I wonder if there should be a commit-hook that rejects commits with a timestamp < the previous HEAD (i.e. require rebasing with --ignore-date) 12:38:30 or whether caring about the commit date is just a sign of being stuck in the old centralized vc mindset :-) 12:39:02 jsnell: there's another field for the date you want, though. 12:39:29 (also the date I want, fwiw) 12:39:42 only if the committer is different from author? 12:42:24 hm, so you can get the CommitDate always with git log --pretty=fuller. but that "pretty" is a lie 12:43:31 -!- antoszka [~antoszka@89-77-132-69.dynamic.chello.pl] has quit [Changing host] 12:43:31 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 12:44:01 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 13:21:34 nikodemus [~Nikodemus@GGMMMCMVI.gprs.sl-laajakaista.fi] has joined #sbcl 13:21:34 -!- ChanServ has set mode +o nikodemus 13:30:51 homie [~levgue@xdsl-78-35-156-33.netcologne.de] has joined #sbcl 13:35:05 -!- nikodemus [~Nikodemus@GGMMMCMVI.gprs.sl-laajakaista.fi] has quit [Ping timeout: 252 seconds] 13:36:04 nikodemus [~Nikodemus@GGMMMCMVI.gprs.sl-laajakaista.fi] has joined #sbcl 13:36:04 -!- ChanServ has set mode +o nikodemus 13:43:06 attila_lendvai [~attila_le@87.247.12.196] has joined #sbcl 13:43:06 -!- attila_lendvai [~attila_le@87.247.12.196] has quit [Changing host] 13:43:06 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:46:46 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 14:00:25 -!- nikodemus [~Nikodemus@GGMMMCMVI.gprs.sl-laajakaista.fi] has quit [Ping timeout: 245 seconds] 14:08:29 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 14:08:36 G'morning all. 14:09:16 hi nyef 14:12:15 ... 31 commits already since release? 14:13:04 nyef: nikodemus_ subjected many things to flow control during the freeze :) 14:13:50 Heh. He's not the only one to have stuff in queue. 14:14:07 I'm just checking now to see how much trouble I'm going to have with one of my working trees. 14:15:08 And the answer is... none. 14:15:38 ... now if I could just remember to not try and stash from the copy of the tree in chroot... 14:19:24 ... "./make.sh: 71: time: not found". 14:19:36 Bloody debian. 14:19:57 apt-get install time 14:20:09 Install what? 14:20:33 bloody modern shells making you think that time is there when it's not :) 14:20:39 Ahh. 14:20:59 echo 'echo 7 o\' clock' > /usr/bin/time 14:21:14 echo 'echo \"7 o\' clock\"' > /usr/bin/time 14:21:21 great solution 14:22:46 *nyef* wonders how far a build --with-mips would get on an x86-64/linux host... 14:35:22 nikodemus [~nikodemus@87-93-56-152.bb.dnainternet.fi] has joined #sbcl 14:35:22 -!- ChanServ has set mode +o nikodemus 14:36:46 Hello nikodemus. 14:51:14 hi 14:53:16 are there other platforms besides darwin we care about, where POSIX realtime semaphores are absent or non-functional? 14:54:06 ... windows? 14:54:22 Beyond that, I have no idea. 14:54:30 we have the equivalent (if it's really needed) 14:54:45 Hrm. Lovely. zlib.h: No such file or directory. 14:54:47 what's the reason to use POSIX semaphores in sbcl? 14:55:22 nyef: disable sb-core-compression (or apt-get install zlib1g-dev) 14:55:41 Yeah, yeah. Seems odd that --fancy brings in a dependency that I don't have by default, though. 14:56:52 akovalenko: pthread_cond_broadcast is not signal-handler safe 14:57:27 drl [~lat@110.139.229.172] has joined #sbcl 14:57:28 well, almost nothing interesting is signal-handler safe 15:00:25 and how do we broadcast with sem_post ? 15:02:43 we keep a waitcount so we know how many times to post 15:03:08 (it is actually exactly 1 almost always) 15:03:23 I bet a blocking read on a FIFO is signal-handler safe. 15:03:32 either thread is waiting for its own state to change while GC runs, or GC is waiting for a thread to stop 15:10:57 *akovalenko* is wondering what more will happen to keep safepoints away 15:11:47 who's queue are they in? paul's or david's? 15:11:53 probably david's 15:12:24 nikodemus: Add src/runtime/TAGS to .gitignore, plz. 15:12:38 will do 15:13:06 *lichtblau* will (aim to) merge safepoints in January! 15:13:55 nikodemus: Oh, and the fail-early thing for bogus target feature combinations is in. 15:14:14 i saw that. very nice 15:14:44 lichtblau: i'm trying to get rest of the long-cleanup done over the next two weeks 15:14:55 anything else i can do to clear your way? 15:25:03 nyef: re. NEWS, i put "NEWS merge=union" into .gitattributes, which makes it not conflict, but though often things still need to be edited as union picking things from both versions will tend to duplicate entries when things are shuffled around during rebasing 15:25:43 could not figure out how to specify just zero-context yet 15:46:59 -!- akovalenko [~akovalenk@95.72.41.55] has quit [Quit: rcirc on GNU Emacs 24.0.91.1] 15:48:03 akovalenko [~akovalenk@95.72.41.55] has joined #sbcl 15:49:44 -!- samebchase [~samuel@76.73.121.203] has quit [Ping timeout: 252 seconds] 15:49:50 samebchase [~samuel@76.73.121.203] has joined #sbcl 16:06:33 lichtblau: have you decided _strongly_ in favor of putting global safepoint page into the data segment? 16:06:50 -!- pon1980 [~pon@195-67-88-105.customer.telia.com] has left #sbcl 16:07:47 as :sb-dynamic-core is already ported outside #+win32, the inconvenience of it becomes even more important... 16:11:45 akovalenko: I haven't decided strongly; in fact I haven't decided at all. 16:12:25 However, last time I discussed stuff similar to sb-dynamic-core with nyef, I think his suggestion was to not go through an extra indirection and "just" relocate the code segments to achieve the same goal. :-) 16:12:35 shaaaaring 16:12:49 it's "unjust"! 16:13:20 it's doubleplusunjust 16:13:40 nyef: share to weigh in? 16:13:51 argh, s/share/care/ :-) 16:14:00 What were we discussing, again? 16:14:23 nyef: relocation vs. prepopulated linkage-table for core<->runtime linkage 16:14:39 -!- MikeSeth_ is now known as MikeSeth 16:14:42 -!- MikeSeth [~me@174-143-244-95.static.cloud-ips.com] has quit [Changing host] 16:14:42 MikeSeth [~me@unaffiliated/mikeseth] has joined #sbcl 16:15:18 Linkage-table is probably easier. 16:15:28 I would argue that (1) relocation is bad for shared mappings [huge core and multiple processes], and (2) we're going to have linkage-table indirection anyway, for the sake of shared libraries. 16:15:36 The other angle is a LispM-like "support vector" of pointers into the runtime. 16:15:43 nyef: clearly easier; and akovalenko has already done that. 16:16:24 what's the interaction with safepoints? that bit i didn't follow 16:16:30 Somewhere around, I have a patch for moving undefined_tramp and friends into static space instead of leaving them in the runtime. 16:16:33 I'm wondering whether there is consensus on it. Sufficient consensus that discussion of other features should assume that we'll be using that approach everywhere. 16:16:54 nyef: But surely we'd like a relocatable static space, too! 16:17:04 nikodemus: currently, safepoint insertion is like TEST AL,[#x21000000] 16:17:24 ah, and the safepoint page is in data segment? 16:17:45 nikodemus: if you make it TEST AL,[some-addr-in-sbcl.exe-datasegment], it will work for traditional core<->runtime linking, but not for my hack 16:17:46 The critical point with the trampolines, I think, is interaction with fdefinitions. 16:17:56 -!- MikeSeth [~me@unaffiliated/mikeseth] has left #sbcl 16:18:27 akovalenko: what revisions should I be looking at to see your implementation? 16:22:12 nikodemus: is the main part of getting it from win32-only to win32+unix 16:22:21 thank you 16:24:05 nikodemus: as of what's done during xc and genesis, it's a deeper (and longer) history, and grepping +sb-dynamic-core within a snapshot is probably an easier way to get the big picture 16:24:44 that looks like exactly the bit i left out when i ported linkage tables from cmucl to sbcl :) 16:24:45 nikodemus: most of the time, the xc stuff is about un-special-casing dynamic linkage for #+xc-host 16:26:05 imo using linkage table for that is fine, i don't remember exactly why i left it out 16:26:50 how about if we avoid yet another global param like this: the sp page would sit right before dynamic space, meaning that we'd have to relocate the TEST instruction if and only if we relocate dynamic space. 16:27:03 nikodemus: there are not-too-simple things with data linkage 16:27:11 sounds good to me 16:27:42 nikodemus: that is, when you have a variable that's not just an extern-alien, but a piece of data accessed by assembly routines, for example. 16:28:19 yeah, i have vague recollections of all the fun varieties of foreign fixups we have 16:28:34 for this case, you have to do something special for indirect linkage, it doesn't just work (as it does for extern-aliens when appropriate VOP is used) 16:29:41 but there are not too many instances of that (unthreaded alloc has most of it) 16:32:53 this is why I went with an offset from thread-base-tn, fwiw. 16:34:36 pkhuong, i am probably going to email you sometime today, just giving a heads up 16:35:14 I wish it were an offset from thread-base-tn on unithreaded builds as well, but it seems to [partially] defeat the point of having unithreaded builds. 16:35:58 Quadrescence: I'm still on a caffeine detox. 16:36:17 -!- evenson [~evenson@213.33.70.157] has quit [Remote host closed the connection] 16:36:42 Quadrescence: It might take a while for me to reply. 16:36:43 (btw, my tree doesn't yet support x86-64 + no-threads + sb-dynamic-core. anyone wanting to test sb-dynamic-core, be careful) 16:37:57 pkhuong, well I've been up since 3 AM so we are even. 16:38:33 (evenp Qworkescence pkhuong) ==> too many arguments 16:39:21 (zerop (- (abs Qworkescence) (abs pkhuong))) ==> T 16:39:27 *nikodemus* goes looking for a drink to celebrate 16:40:01 threads on darwin look solid with this commit, /finally/ 16:40:40 better be ppc/darwin 16:41:44 Qworkescence: Don't go there. I found an async interrupt hole in the non-x86 calling convention implementations. 16:41:47 -!- nikodemus_ [~nikodemus@dsl-hkibrasgw4-fe5bdf00-15.dhcp.inet.fi] has quit [Ping timeout: 240 seconds] 16:41:56 nikodemus: nice. 16:42:05 nyef, :C 16:42:41 Planning on patching it this week, once I finish dumping the rest of my commit queue. 16:45:16 *akovalenko* now has to do something about this new sem_preposterous thing. 16:48:40 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Operation timed out] 16:49:37 ... Did source-location handling change recently? 16:49:46 heh. OBJ_FMTX is "lx" on !mswin, "Ix" on mswin. You'd better have a good font.. 16:49:56 Or something else? 16:53:36 'cause I just failed to build on PPC due to a constant not being allowed in MOVE-ARG... 16:55:04 -!- nikodemus [~nikodemus@87-93-56-152.bb.dnainternet.fi] has quit [Disconnected by services] 16:55:05 nikodemus_ [~nikodemus@dsl-hkibrasgw4-fe5bdf00-15.dhcp.inet.fi] has joined #sbcl 16:55:05 -!- ChanServ has set mode +o nikodemus_ 16:55:25 -!- samebchase [~samuel@76.73.121.203] has quit [Ping timeout: 245 seconds] 16:55:28 nikodemus [~nikodemus@87-93-56-152.bb.dnainternet.fi] has joined #sbcl 16:55:28 -!- ChanServ has set mode +o nikodemus 16:55:35 samebchase [~samuel@76.73.121.203] has joined #sbcl 16:59:45 nyef: that could possibly be my boxed-constants change 17:01:10 *akovalenko* rejoices of his earlier rehacktoring of safepointy gc-*-the-world away from set_thread_state/wait_for_thread_state_change 17:01:47 nikodemus: Yeah, just trying to build that commit now. 17:04:15 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:09:35 nikodemus: why not put darwinian os_sem_* into darwin-os.c, with common prototypes in thread.h, and default os_sem_* into os-common.c? Inlining doesn't gain you too much when a syscall is going to happen anyway. 17:10:43 Now building the parent commit... 17:10:59 true 17:11:39 uh. ppc linux is spectacularly unhappy with HEAD 17:12:27 What do you think I'm trying to build? 17:12:30 nikodemus: I'm going to put another #ifdef for windows there, so I want a convincing argument to use when I'm criticized for it 6 months later :) 17:13:34 well, maybe "I just followed nikodemus' example" is convincing enough :-/ 17:16:55 akovalenko: i'll refactor it and remove the inlines 17:31:58 -!- samebchase [~samuel@76.73.121.203] has left #sbcl 17:35:38 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 17:48:25 nikodemus: Looks like that constant-arg commit is at fault. 17:52:53 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 17:54:02 what i don't understand is why this PPC now tries to include half the word into ppc-assem.S 17:57:05 world, eve 17:58:40 Half the world, what? 17:59:36 a crapload of system header files which it then claims not to understand. (load of unknown opcode __external__, etc) 17:59:50 *nikodemus* starts a bisection of his own 18:00:14 nikodemus: semaphore stuff? 18:00:49 pkhuong: that was my first though, but this tree has that already behind #ifndef LANGUAGE_ASSEMBLY 18:00:54 thought, even 18:01:19 *nikodemus* bets on a misspelled #define 18:04:34 So, thoughts on the MOVE-ARG thing? Or are you trying to test a fix already? 18:05:05 i'm looking at it, yeah 18:07:27 Okay. I'm kindof blocked until this is sorted. 18:08:12 http://paste.lisp.org/display/126309 # this reminds me of something from a while ago 18:08:40 It's vaguely familiar, maybe. 18:10:53 ... something x86oid-specific, maybe? 18:16:14 Why aren't positive-fixnums packable into descriptor-regs? 18:19:38 Alternately, why does this work on x86oids? 18:19:44 and why is it Const and not Immed? 18:21:18 homie` [~levgue@xdsl-78-35-133-239.netcologne.de] has joined #sbcl 18:21:44 it should be any-reg... 18:21:45 aha. PPC has ZERO and NULL as well 18:22:59 ah, yes. 18:23:44 x86[-64] has direct support for immediates in move-arg; other platforms, or, at least, ppc, don't. 18:23:52 -!- homie [~levgue@xdsl-78-35-156-33.netcologne.de] has quit [Ping timeout: 240 seconds] 18:24:31 we're supposed to load constants and then pass the TN (that refers to a real location) to move-arg. 18:25:36 and it works by accident on x86oids. 18:39:49 nikodemus: does lvar-tn work still correctly now that we can have two tns per constant? 18:40:06 pkhuong: i *think* so 18:41:26 re. move-arg. i don't think my patch should have changed the behaviour there. my understading is of the problem is that NULL and ZERO are really boxed locations, but the code in make-constant-tn doesn't know that 18:47:50 oh well. I have real work to do :'( Why did I tell my jury i'd be done in 12 months? 18:57:27 aarhh. no wonder my fixes aren't working. i'm pulling the wrong branch... 19:00:54 Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has joined #sbcl 19:01:40 pkhuong: btw, that sbcl-old repository that you cloned a while ago is, well, old - although the only changes since then were that I rebased the sse branch onto a later sbcl version 19:10:01 angavrilov: rebasing is a small issue, really ;) 19:12:54 ... "all your rebase are belong..." 19:14:20 ok, looks like i have a fix 19:14:40 Oh? 19:15:35 -!- homie` [~levgue@xdsl-78-35-133-239.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:18:48 yeah, unthreaded ppc build just finished. now let's check the threaded one... 19:49:13 ok, PPC should be happy once more 19:50:10 akovalenko: and the sempahore code is now placed more hygienicly into os-common.c / darwin-os.c 19:50:45 nikodemus yay on the thread improvements 19:50:47 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 240 seconds] 19:50:50 Yay. 19:54:14 nikodemus: And congratulations on the more stable threading on OSX. 19:55:12 It seriously no longer catches fire when I run my tests with threaded containers instead of process containers 19:55:38 nikodemus: \o/ 19:55:41 sbryant: good to hear 19:56:04 I have a few friends that I don't have to tell to use CCL now. Joy. :) 19:56:18 i'm quite tempted to enable threads by default on darwin, but i'll let the eager experimentalists bang on them for a while first 19:58:36 milanj [~milanj_@178-223-191-12.dynamic.isp.telekom.rs] has joined #sbcl 19:59:36 *redline6561_* puts aside some money for the next sbcl fundraiser 20:00:51 I'm tempted to enable threads by default on PPC/Linux, but that's mainly because I keep forgetting to hack them into my c-t-f... 20:00:56 Kryztof [~user@81.174.155.115] has joined #sbcl 20:00:56 -!- ChanServ has set mode +o Kryztof 20:01:53 nikodemu_ [~Nikodemus@GGMMMCMVI.gprs.sl-laajakaista.fi] has joined #sbcl 20:03:04 -!- nikodemus [~nikodemus@87-93-56-152.bb.dnainternet.fi] has quit [Ping timeout: 240 seconds] 20:23:14 saschakb__ [~saschakb@p4FEA02D1.dip0.t-ipconnect.de] has joined #sbcl 20:27:05 -!- saschakb_ [~saschakb@p4FEA0E9F.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds] 20:46:27 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Ping timeout: 240 seconds] 20:53:47 -!- nikodemu_ [~Nikodemus@GGMMMCMVI.gprs.sl-laajakaista.fi] has quit [Remote host closed the connection] 20:59:56 nikodemus [~Nikodemus@GGMMMCMVI.gprs.sl-laajakaista.fi] has joined #sbcl 20:59:56 -!- ChanServ has set mode +o nikodemus 21:07:49 antgreen [~user@bas3-toronto06-1177698504.dsl.bell.ca] has joined #sbcl 21:08:21 sdemarre [~serge@91.176.39.17] has joined #sbcl 21:12:32 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 21:19:44 -!- nikodemus [~Nikodemus@GGMMMCMVI.gprs.sl-laajakaista.fi] has quit [Disconnected by services] 21:19:46 nikodemus` [~nikodemus@188-67-206-250.bb.dnainternet.fi] has joined #sbcl 21:19:46 -!- ChanServ has set mode +o nikodemus` 21:20:15 nikodemus [~Nikodemus@GGMMMCMVI.gprs.sl-laajakaista.fi] has joined #sbcl 21:20:15 -!- ChanServ has set mode +o nikodemus 21:22:05 prxq [~mommer@mnhm-4d013d2f.pool.mediaWays.net] has joined #sbcl 21:26:09 -!- nikodemus [~Nikodemus@GGMMMCMVI.gprs.sl-laajakaista.fi] has quit [Remote host closed the connection] 21:46:07 -!- sdemarre [~serge@91.176.39.17] has quit [Read error: Operation timed out] 21:47:56 "Failure: compiler.pure.lisp / BOXED-FP-CONSTANT-FOR-FULL-CALL" 21:50:28 on PPC? 21:55:45 *nikodemus`* logs back to the host that was running tests 21:56:34 yeah, i see it here too 21:56:50 at least that's not a regression in the strict sense of the word... 21:56:57 i'll deal with it 21:59:04 Thanks. 22:02:38 that's funny. on PPC we get 1.0d0 twice in the constant vector 22:04:07 oh.... 22:14:41 -!- prxq [~mommer@mnhm-4d013d2f.pool.mediaWays.net] has quit [Quit: Leaving] 22:17:17 we put a fixnum 0 in the constant vector on x86oids? thats... silly 22:20:20 -!- DGASAU [~user@91.218.144.129] has quit [Remote host closed the connection] 22:20:37 DGASAU` [~user@91.218.144.129] has joined #sbcl 22:31:41 Feature compatability check failed, ("One of :GENCGC or :CHENEYGC must be enabled") 22:31:48 when running make.sh in clean git tree 22:31:57 on mipsel 22:32:13 1.0.53.106.master.1-9719409 built and produced a working binary 22:32:16 Nice! What's in local-target-features.lisp-expr, or whatever it's called? 22:32:24 with the usual suspects of contribs failing 22:32:39 ((lambda (features) (set-difference features (list))) 22:32:45 (union (list) (list :mips :unix :elf :linux :largefile :linkage-table :stack-allocatable-closures :stack-allocatable-vectors :stack-allocatable-lists :stack-allocatable-fixed-objects :alien-callbacks :little-endian :os-provides-dlopen :os-provides-dladdr :os-provides-putwc :os-provides-suseconds-t :os-provides-getprotoby-r :os-provides-poll))) 22:33:06 Umm... where's the garbage collector? 22:33:45 For that matter, dear god, someone uses MIPS? Whatever you do, don't stack-allocate vectors! 22:33:58 Or structures with unboxed slots. 22:34:10 oh, 0 must be the trace table thingabob 22:36:15 seems the old sbcl didn't have a gc as well, right 22:37:22 Okay, now I'm confused. 22:38:09 at least the last working git snapshot 22:38:37 Yeah, yeah. Seems that not having :gencgc is "good enough". 22:39:09 For now, build with --with-cheneygc 22:39:36 jep doing that right now 22:39:53 And please be aware that stack-allocatable-vectors are horribly, horribly dangerous on MIPS, and about to get worse. 22:40:49 nyef: just curious, what's the story there? 22:40:58 What, stack-allocatable-vectors? 22:41:32 There's no defense against specialized vectors, AFAIK, and unboxed data on the control stack is BAD. 22:41:47 -!- akovalenko [~akovalenk@95.72.41.55] has quit [Ping timeout: 240 seconds] 22:42:02 For that matter, a stray header in a "dead" stack slot can be BAD as well. 22:42:32 oh, right 22:42:39 (As in, scavenge ends up past the end of the stack, and there's this little GC assertion thing...) 22:43:26 The fix for the unboxed structure slots thing and the fix for the stray headers thing are both in my pending queue. 22:43:47 Actually doing the right thing with specialized vectors, however, I haven't sorted out yet. 22:44:32 right 22:45:24 ... is undefined-function frames showing up in the backtrace on x86oids as ("undefined function") instead of ("bogus stack frame") a bug fix or an enhancement? 22:45:34 I know it's a bug fix everywhere else. 22:46:49 i'd call it an enhancement 22:47:29 Okay, so separate entries in NEWS? 22:47:56 akovalenko [~akovalenk@95.73.48.236] has joined #sbcl 22:47:58 i'm fine either way 22:48:00 so, we can safely stack allocate specialized vectors only when c-stack-is-control-stack? 22:48:39 Correct. The Right Thing is to allocate them on the number stack instead. 22:48:50 But the only platform this affects is MIPS. 22:49:27 I refuse to allow it to affect PPC until it's going to work right. 22:49:32 only element-type t is safe? or is element-type fixnum ok as well? (are our fixnum vectors boxed nowadays) 22:49:44 Fixnum is probably okay. 22:50:02 It's just that we can't store unboxed data on the control stack. At all. 22:50:16 i'll add the appropriate check to defoptimizer for allocate-vector 22:50:42 Aww... 22:51:03 I was hoping for a somewhat static situation while I try to figure out how to fix it properly. 22:53:18 it's a couple of lines of code under #-c-stack-is-contol-stack 22:56:32 Okay, so I can take it out or use it as a basis, whichever is most convenient? 22:57:20 exactly -- and in the meanwhile our 2.5 mips users can't blow their stacks quite so easily :) 22:57:48 Heh. 22:59:17 Okay, that's one branch committed. 22:59:29 in print.c:34 gencgc-alloc-region.h should probably also only be included on gencgc ;-) otherwise it dies on cheneygc with redefinition of alloc_region 22:59:54 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 268 seconds] 23:02:08 That's new since the release, isn't it? 23:03:47 yes. part of my semaphore damage 23:07:01 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 23:07:30 Okay, I'll deal with the :cheneygc thing tomorrow, I think. 23:08:03 Either by taking out the sanity-check, or adding it to make-config.sh. 23:09:09 i think explicit gc feature is good, though historically i think cheney has been mostly indicated by lack of alternatives 23:09:33 Mmm. The thing is, PPC supports both. 23:09:55 And I think I'd like for that trend to continue. 23:10:06 (Say, x86-64 supporting both as well?) 23:27:45 i'm ok with that trend :) 23:30:07 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 23:35:40 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 23:53:22 -!- milanj [~milanj_@178-223-191-12.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 23:55:02 -!- saschakb__ [~saschakb@p4FEA02D1.dip0.t-ipconnect.de] has quit [Quit: Verlassend] 23:55:49 saschakb [~saschakb@p4FEA02D1.dip0.t-ipconnect.de] has joined #sbcl