00:25:24 -!- milanj [~milanj_@109-92-103-199.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 00:48:51 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 02:42:32 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Read error: Operation timed out] 02:42:50 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 02:45:51 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 03:32:58 attila_lendvai [~attila_le@87.247.51.76] has joined #sbcl 03:32:58 -!- attila_lendvai [~attila_le@87.247.51.76] has quit [Changing host] 03:32:58 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:47:19 -!- akovalenko [~akovalenk@95.72.172.69] has quit [Ping timeout: 244 seconds] 04:53:09 akovalenko [~akovalenk@95.73.52.185] has joined #sbcl 04:59:27 -!- akovalenko [~akovalenk@95.73.52.185] has quit [Remote host closed the connection] 05:32:40 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Read error: Operation timed out] 05:34:47 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 05:36:37 akovalenko [~akovalenk@95.73.52.185] has joined #sbcl 05:44:50 -!- homie [~levgue@xdsl-78-35-154-167.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:56:31 -!- antgreen [~user@bas3-toronto06-1177890206.dsl.bell.ca] has quit [Ping timeout: 248 seconds] 06:08:14 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 06:16:04 How can I force sbcl to unbox a word for an inner loop? Doing (let ((foo-work foo)) (declare (type ... foo)) ...) doesn't seem to work because presumably some optimization removes that let. 06:18:47 OK, (let ((foo-work 0)) (setf foo-work foo) ...) worked 06:20:44 -!- udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has quit [Ping timeout: 252 seconds] 06:22:56 -!- ottergwc [~brian.jon@wsip-24-234-75-217.lv.lv.cox.net] has quit [] 06:34:04 maybe you should (declare (type ... foo-work)) instead? 06:36:04 that's a typo 06:36:08 -!- blumbri [1000@204.152.219.7] has quit [Ping timeout: 252 seconds] 07:05:36 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 07:05:36 -!- ChanServ has set mode +o nikodemus 07:25:54 nikodemus: Is there any way to force the compiler to unbox a value for an inner loop other than (let ((foo-work 0)) (setf foo-work foo) ...)? A simple let seems to be optimized out. 07:26:21 (The setf solution is fine, so I'm j 07:26:26 ust interested :)) 07:28:19 *akovalenko* would like to know the use case; just interested. 07:29:29 The inner loop of a binsearch function searching an uint32 in an uint32 array on 32-bit sbcl - I want it to be as efficient as possible. The variable holds the key. 07:30:29 angavrilov: if you declare the type (eg as fixnum), you might even get a register ... 07:31:11 that's all fine, provided optimizations don't elide the typed variable, and redirect the loop to use the original boxed parameter directly 07:32:33 blumbri [1000@204.152.219.61] has joined #sbcl 07:38:45 angavrilov: not force per se, but usually eg. (let ((x y)) (declare (sb-ext:word x)) ...) works -- the declaration to something with an interesting primitive type being the key 07:39:34 angavrilov: if you couple that with using modular arithmetic, i would definitely expect it to be unboxed in the loop 07:40:28 angavrilov: if that doesn't seem to work, send an example to sbcl-devel or launchpad, and we'll mull over it 07:45:52 what does sb-vm:word do exactly? 08:00:01 sb-ext:word. it's either (unsigned-byte 32) or (unsigned-byte 64), depending on the build 08:00:07 just a deftype 08:01:04 mostly for convenience in conjunction defstruct/make-array + atomic-incf/atomic-decf 08:01:46 but obviously if you know it's uint32, (declare (type (unsigned-byte 32) x)) should work just as well 08:07:02 fantazo [~fantazo@178-191-164-109.adsl.highway.telekom.at] has joined #sbcl 08:07:18 -!- fantazo [~fantazo@178-191-164-109.adsl.highway.telekom.at] has left #sbcl 08:14:49 ottergwc [~brian.jon@wsip-24-234-75-217.lv.lv.cox.net] has joined #sbcl 08:14:51 Here's the code & disassembly, checked on a recent sbcl: http://paste.lisp.org/display/126027 08:15:07 Since that computer is 64-bit, the problem appears in the 64-bit int version. 08:18:15 It actually seems sufficient to do (setf key key) with the parameter var, without any additional lets. 08:27:47 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 08:30:56 -!- akovalenko [~akovalenk@95.73.52.185] has quit [Remote host closed the connection] 08:43:30 akovalenko [~akovalenk@95.73.52.185] has joined #sbcl 09:01:32 akovalenko` [~akovalenk@95.72.99.130] has joined #sbcl 09:02:59 -!- akovalenko [~akovalenk@95.73.52.185] has quit [Ping timeout: 258 seconds] 09:03:05 -!- akovalenko` is now known as akovalenko 10:30:46 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 10:30:46 attila_lendvai1 [~attila_le@87.247.51.76] has joined #sbcl 10:30:46 -!- attila_lendvai1 is now known as attila_lendvai 10:30:47 -!- attila_lendvai [~attila_le@87.247.51.76] has quit [Changing host] 10:30:47 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:31:05 attila_lendvai1 [~attila_le@87.247.51.76] has joined #sbcl 10:31:05 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 10:31:06 -!- attila_lendvai1 is now known as attila_lendvai 10:31:06 -!- attila_lendvai [~attila_le@87.247.51.76] has quit [Changing host] 10:31:06 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:31:57 attila_lendvai1 [~attila_le@87.247.51.76] has joined #sbcl 10:31:57 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 10:31:58 -!- attila_lendvai1 is now known as attila_lendvai 10:31:58 -!- attila_lendvai [~attila_le@87.247.51.76] has quit [Changing host] 10:31:58 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:32:54 attila_lendvai1 [~attila_le@87.247.51.76] has joined #sbcl 10:32:54 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 10:34:26 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 10:36:25 flip214 [~marek@86.59.100.100] has joined #sbcl 10:36:25 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 10:36:25 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 10:50:32 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 10:51:07 flip214 [~marek@86.59.100.100] has joined #sbcl 10:51:07 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 10:51:07 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 11:03:43 -!- drdo [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Ping timeout: 248 seconds] 11:12:46 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 11:14:15 flip214 [~marek@86.59.100.100] has joined #sbcl 11:14:15 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 11:14:15 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 11:54:13 good day everyone 12:07:04 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 12:14:37 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Quit: +++ killed by SIGSEGV +++] 12:14:54 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 12:53:23 -!- Kryztof [~user@81.174.155.115] has quit [Read error: Connection reset by peer] 13:09:29 nikodemus pasted "hey, it works :)" at http://paste.lisp.org/display/126033 13:10:30 https://github.com/nikodemus/SBCL/tree/wip-flexible-heap 13:19:50 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 13:35:48 nyef [~nyef@pool-70-109-136-86.cncdnh.east.myfairpoint.net] has joined #sbcl 13:35:58 G'morning all. 13:38:09 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:40:42 -!- attila_lendvai1 [~attila_le@87.247.51.76] has quit [Ping timeout: 276 seconds] 13:48:25 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 13:50:18 Hrm. If we partition the x86-64 register set, it looks like rax, rcx, rdx, rsi, rdi, r8, and r9 have to be non-descriptor registers. 13:53:39 good-universal-time. or bad. /me overlooked some unsigned longs in looks_like_valid_lisp_pointer_p... 13:54:22 nyef: what would you recommend instead of unsigned long for casting start_addr in looks_like_valid_lisp_pointer_p?.. 13:54:32 lispobj? u64? uintptr_t? 13:54:43 size_t? os_vm_size_t?.. 13:54:53 Oh, right, I was going to do something about that damage, wasn't I? 13:56:38 You thinking the FUNCALLABLE_INSTANCE_HEADER_WIDETAG test? 13:57:10 Hrm. 13:57:15 Same trick done several places. 13:57:23 for example. it starts from SIMPLE_FUN_HEADER_WIDETAG and goes on. 13:58:10 I'd go with (void *) or (char *) for the short-term fix, TBH. 13:58:26 Whichever will give you the correct semantic when adding an integer. 13:59:46 milanj [~milanj_@109-92-103-199.dynamic.isp.telekom.rs] has joined #sbcl 14:01:24 flexible-heap! 14:01:29 akovalenko: it should be caddr_t, right? 14:01:35 at least from a C point of view 14:01:41 Oh, hey, there's a pointer_sized_uint_t type. 14:02:42 there are too much of similar types in SBCL, that's why I'm asking what's generally right, according to developers' intent. 14:04:01 Okay, I remember roughly what I was going to do to this function now. 14:04:19 And it started by changing pointer from a (lispobj *) to a lispobj. 14:04:36 You're doing this for your local branch? 14:05:00 nyef: yep. I went on with char*. 14:05:21 Okay. There's probably going to be some upstream changes soon... 14:09:01 Umm... What did you do about the definition of lispobj in runtime.h? 14:12:25 Kryztof [~user@81.174.155.115] has joined #sbcl 14:12:25 -!- ChanServ has set mode +o Kryztof 14:14:34 nyef: I did s/unsigned long/pointer_sized_uint_t/ 14:14:59 Fair enough. And adjusted pointer_sized_uint_t appropriately as well? 14:15:53 "adjusted". I added my own uword_t, which is uintptr_t, and also a base for pointer_sized_uint_t. 14:17:57 ..I asked about this mess in sbcl-devel looong time ago. Now I have only one thing to ask: could you'all Western Hegemones please refrain from adding /more unsigned longs/ with new code? 14:19:01 Heh. I'm already mildly upset at nikodemus for some of the stunts he's pulled this cycle. 14:23:31 nyef pasted "what I'm testing now" at http://paste.lisp.org/display/126034 14:31:03 Thus far, it's working, and I think that it is rather a bit cleaner. 14:43:50 I guess no one else is seeing a failure in test compiler.pure.lisp on bug-309448 on x86_64? 14:45:01 tsuru`: Is that one of those timing ones? 14:45:26 *nyef* hasn't actually done an x86-64 build in several days. 14:46:17 nyef: "The assertion (>= (* 10 (1+ TIME-1/SIMPLE)) TIME-1/HAIRY) failed." 14:46:49 Yup, that's a timing-sensitive one. 14:46:49 my novice eyes say yes... :/ 14:47:48 ok so I should hold on sending a bug report with large backtrace, stderr and stdout logs ? 14:48:51 ... probably? 15:55:39 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 15:55:39 -!- ChanServ has set mode +o nikodemus 15:55:48 Hello nikodemus. 15:56:16 hi 16:01:48 is it safe to use long long in runtime.c ? 16:02:15 i at least would prefer if we didn't introduce any new long longs. 16:02:28 What do we need a long long for, anyway? 16:02:39 (i don't know if we have any) 16:02:44 64-bit integers on 32-bit systems? 16:02:57 nyef: memory size calculations 16:03:19 size_t? 16:03:25 os_vm_size_t 16:04:21 (or if os_vm_size_t is considered useless, we should cut it. otherwise i think we should use it instead of size_t in our own code) 16:04:22 IIRC win64 has 32bit longs, which would limit the return of parse_size_arg to 2G 16:04:46 fe[nl]ix: in sbcl runtime currently longs are 64 for win64 16:04:49 There's also something about a pointer-sized-integer in runtime.h. 16:04:52 at least in anton's tree 16:05:06 ok 16:05:07 but we don't want any more longs if we can help it 16:05:40 I spotted a few issues with commit 798b02eeb8691ec00138f03dac3858368a8b0b0b 16:06:00 the comparision should be case-insensitive 16:06:12 isn't it? 16:06:21 also, "GB" and "GIB" are not the same unit of measure 16:06:32 the case-insensitive one is strcasecmp 16:06:36 that's what the topupper is for 16:06:59 oops, I didn't see that :) 16:07:09 Okay, looks_like_valid_lisp_pointer_p() changes committed. 16:07:16 strcasecmp is fine as well, though. didn't know that one existed, and didn't find it easily 16:07:30 nikodemus: You know that you broke the unwind-to-frame-and-call tests on PPC, right? 16:07:40 um, no? 16:07:41 GB is 10^9 and GiB 2^30 16:07:53 Yup. Something about NIL not being an SB-DI:FRAME. 16:08:06 GB=GIB bogosity is by design. i'm pretty sure that anyone who says --dynamic-space-size 5Gb actually means 5GiB 16:09:00 -!- |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [Ping timeout: 260 seconds] 16:09:19 ISO can go to hell and stop trying to make bytes being counted in base 10 16:10:12 nyef: which tests? 16:10:18 all of them? 16:10:30 nikodemus: in your planned variant of extendable heap, will it use brk/sbrk, or anonymous mmap? 16:10:37 akovalenko: mmap 16:10:38 Don't remember offhand, but probably. 16:10:49 yay 16:10:51 Or, at least, any that involve the new "context" stuff. 16:11:05 That said, I'm not going to be able to check for certain until Monday or so. 16:11:09 darwin's sbrk is bloody useless 16:11:53 use of brk was a bad idea anyway, except that it was oh-so-convenient to get started 16:11:56 nyef: ok. remind me than and i'll send you a version of the test file with prints that will enable me to fix it 16:12:08 now let me tell you about Windows sbrk :) 16:12:16 hah 16:12:35 ..it's bloody absent. 16:13:06 darwin's is a poor emulation in user space 16:13:36 ... isn't that true of almost everything in darwin? 16:13:41 no, actually, wait. i think it _is_ in the kernel, but it could just as well be in user space 16:13:45 true 16:14:54 lichtblau: over lunch i added mmap extensibility to my tree (pushed to github) 16:15:26 i really don't know how to do the "slow and steady" thing, it seems 16:17:32 Sometimes, it's all about the burst rate. 16:31:09 nikodemus: for what it's worth, I would have preferred accurate rather than dwim on G/Gi 16:31:28 also I would tend not to have used B in the specification 16:32:23 (removes the possible bit/byte confusion) 16:36:27 but don't let me distract you 16:37:14 I'm probably going to get disconnected soon. 16:37:36 ... 856 hours and 36 minutes of battery remaining? Neat! 16:41:14 Kryztof: i won't be cross if someone patches it to distinguish them -- though dropping support for ?b and ?ib is better done before release 16:41:48 it was very much "since i'm adding this..." kind of decision 16:42:07 -!- nyef [~nyef@pool-70-109-136-86.cncdnh.east.myfairpoint.net] has quit [Ping timeout: 245 seconds] 16:44:24 but how do my proposed semantics re. heap exhausion sound? ie. "extend heap to let allocation succeed, then signal" 16:44:34 homie [~levgue@xdsl-78-35-149-75.netcologne.de] has joined #sbcl 16:45:29 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 244 seconds] 16:48:54 *lichtblau* is still trying to figure out how the new plan differs from his code 16:49:15 During GC it's obvious; the errors gets delay until after GC, and that's what I did. 16:50:10 In user code, did I give an error immediately? If so, I suppose delaying the error until after pa is more clever. 16:52:08 -!- Kryztof [~user@81.174.155.115] has quit [Read error: Connection reset by peer] 16:53:02 yes, unless you're running with interrupts disabled it waits till pa is over. 16:53:24 ... so if that's the change, we're in violent agreement. 16:53:32 Kryztof [~user@81.174.155.115] has joined #sbcl 16:53:32 -!- ChanServ has set mode +o Kryztof 16:53:40 when i have the energy i'll look into making it signal reliably after pa regardless of interrupts 16:54:31 lichtblau: also, my reading of your code was that you agressively minimized initial heap size -- whereas i start by mapping the whole requested dynamic space, and extend only when needed 16:55:09 the only other real difference is order of execution. ie. relocation last 16:57:39 yeah, I certainly recall thinking that my initial size was a tad aggressive; for testing purposes though, this extreme case seemed like the right thing to try 17:02:32 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 244 seconds] 17:04:06 ... I think your --dynamic-space-size commit originated in my tree back then; later I wasn't certain we _need_ many separate options for initial/soft/hard limits, and I simply reused it for the soft limit. But if we now have Java-style flexibility in customizing everything, that's clearly even better. 17:04:18 what does order of execution mean? 17:12:39 attila_lendvai [~attila_le@87.247.54.146] has joined #sbcl 17:12:39 -!- attila_lendvai [~attila_le@87.247.54.146] has quit [Changing host] 17:12:39 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:12:57 order of hacking 17:13:10 oh! :-) 17:13:39 lol 17:13:57 it took me a while to realize that relocation was making it look more complicated than it was, so after i decided to do that last things started to look a lot simpler 17:14:05 "x86 is an architecture where order of hacking is very close to sequential consistency" 17:20:09 speaking of longs, long longs, etc... should we worry about x86-64-bsd-os.c:38: warning: pointer targets in return differ in signedness (and related warnings) 17:20:44 possibly. darwin has a cropload of those 17:21:04 if nothing else, they make it hard to see if you've introduced new warnings 17:21:14 no reason to worry too much, maybe, but (as usually) this noise makes real warnings less noticeable 17:23:26 Kryztof [~user@81.174.155.115] has joined #sbcl 17:23:26 -!- ChanServ has set mode +o Kryztof 17:23:46 agreed 17:24:22 morning Kryztof 17:30:13 yo 17:30:33 it seems weird to me that register_t would be a signed integer, but what do I know... 17:31:03 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Remote host closed the connection] 17:32:05 especially if the OS's mcontext is going to define register values as unsigned ints, rather than using said register_t type 17:32:21 are registers not supposed to change that automatically ? 17:32:31 signed<->unsigned ? 17:33:11 homie: we're talking about the types in the C sources 17:34:23 now i have the urge to default dynamic-space-reserve to half of dynamic space, so that a gc can always complete even if we cannot extend the heap anymore... 17:48:16 antgreen [~user@bas3-toronto06-1177890206.dsl.bell.ca] has joined #sbcl 17:53:19 nikodemus pasted "tee-hee!" at http://paste.lisp.org/display/126042 17:54:02 (ignore the leading part, bad copy-paste) 17:56:05 -!- borkman [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 17:57:08 nice. What's the difference between CONTINUE and ABORT? 17:57:34 oh, if there's an actual computation in there would you get the real answer from CONTINUE? 17:57:45 yes 17:59:13 hm. What is or was bug 403? 18:00:01 also, if you do (make-array :initial-element t), the condition should be signalled before it is initialized, so abort prevents touching all those pages you just mapped 18:00:15 bug 403? 18:00:54 403: FORMAT/PPRINT-LOGICAL-BLOCK of CONDITIONs ignoring *PRINT-CIRCLE* 18:00:55 ? 18:01:08 403: FORMAT/PPRINT-LOGICAL-BLOCK of CONDITIONs ignoring *PRINT-CIRCLE* 18:01:13 ah, damn 18:01:34 git show 4af56c115ef7ec63e06be677f9dfbf8116882e4c:BUGS 18:01:35 hm 18:02:40 (easy way to find old bugs: git log -S BUGS, copy-paste the sha1, git show :BUGS) 18:02:55 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 248 seconds] 18:03:41 that is a shame, because that bug seems to still exist and also to block a simple change to make the default debugger message not do that stupid 18:03:43 # ... 18:03:49 RUNNING> 18:03:50 thing 18:04:04 yeah 18:04:20 it irks me every single time i see it, but never enough to hunt it down 18:19:14 udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 18:21:34 hm, actually, all it really needs is one conditional newline 18:40:19 -!- milanj [~milanj_@109-92-103-199.dynamic.isp.telekom.rs] has quit [Ping timeout: 258 seconds] 18:44:58 milanj [~milanj_@178-223-149-21.dynamic.isp.telekom.rs] has joined #sbcl 18:47:39 sdemarre [~serge@91.176.28.91] has joined #sbcl 18:48:49 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 18:48:55 nyef [~nyef@pool-70-109-144-138.cncdnh.east.myfairpoint.net] has joined #sbcl 18:58:57 nikodemus: regarding your paste ... are (dynamic-space-) things in CL-USER? might be better to have them in sb-impl or something like that 19:01:28 sb-ext, surely 19:01:43 it's actually quite difficult to define anything in cl-user in an sbcl build 19:03:21 tyson2 [~Ian@206.248.173.91] has joined #sbcl 19:04:46 are these (setf) able, too? 19:07:47 currently dynamic-space-limit is 19:08:05 -reserve is unlikely to be, but could in principle be 19:08:31 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 248 seconds] 19:08:31 -size is unlikely to be, but could in principle be 19:09:40 drdo [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 19:17:49 *nikodemus* adds --dynamic-space-hard-limit 19:18:32 hrmpf; that's a lot of similarly named variables :-) 19:22:57 -!- homie [~levgue@xdsl-78-35-149-75.netcologne.de] has quit [Read error: Connection reset by peer] 19:23:34 I'm not seeing the full picture yet, and probably not understanding some details, so excuse any misunderstandings on my part, please! :-) But here some random comments on stuff I'm seeing: 19:24:04 Why are the reserve pages contiguous? That seems a lot less flexible than reservation in the sense of a limit as I had implemented it. (How to you restore reservation without wasting space?) 19:24:21 homie [~levgue@xdsl-78-35-148-239.netcologne.de] has joined #sbcl 19:24:46 i don't currently restore reservation 19:24:49 -!- joshe [~joshe@opal.elsasser.org] has quit [Quit: os upgrade] 19:25:28 touché! 19:25:29 -!- homie [~levgue@xdsl-78-35-148-239.netcologne.de] has quit [Read error: Connection reset by peer] 19:25:29 i want them congtiguous because that means that an allocationt the size of reservation can always succeed 19:25:55 Growing shouldn't jump from "preferred address" to "anywhere", but rather incrementally probe forward. Otherwise, not only do you get a potentially HUGE page table otherwise, but also, if mmap runs backwards, you would need to fill what I called holes (not certain whether that is what you mean with holes). 19:26:28 good point 19:26:43 i haven't actually tested that code path at all yet 19:26:46 nikodemus: Let me ask again. Why are the reserve pages contiguous? 19:27:45 so that if you say "reserve me 100Mb", you know what until you get a storage condition telling you you're eating into your reserve space, any allocation upto 100Mb will succeed 19:29:19 fragmented reserve space seems a lot less useful and hard to reason about -- and the only reason to really want a reserve space beyond a couple of megabytes is if you eg. want to make sure you can take down your server gracefully 19:29:30 sure, but for that it is sufficient to restrict the _number_ of pages allocated, as opposed to their _position_. 19:29:46 how so? 19:30:15 oh, you mean always reserve N pages from the end? 19:30:23 very true 19:32:25 I think I meant the opposite; but I'll wait for a complete patch before discussing further; that probably makes more sense. :-) 19:32:34 fair enough :) 19:35:30 nikodemus annotated #126042 "one more, now hitting reserve due to hard limit" at http://paste.lisp.org/display/126042#1 19:35:51 it always bothers me that when I google for things like mach_exception_handler, my own posts show up on the front page. doesn't anyone else use this stuff?? 19:36:56 slyrus: they're careful to only post on places with robots.txt keeping google out, that way they preserve their competitive advantage while lying in wait of the day when mach becomes the dominant paradigm! 19:37:16 --> home, bbl 19:38:02 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 19:38:17 slyrus: Another take on "wisdom of the ancients", isn't it? 19:39:03 heh 19:41:07 -!- tyson2 [~Ian@206.248.173.91] has left #sbcl 19:41:33 For quite a while, and possibly still the case, the only technical documentation available on the SWIM drive controller used in old-school macs was a document I wrote about what I figured out from reverse engineering the code. 19:41:58 ... never did get it working, either. /-: 19:45:06 joshe [~joshe@opal.elsasser.org] has joined #sbcl 19:53:48 nikodemus [~Nikodemus@GGZYYYMMCCXV.gprs.sl-laajakaista.fi] has joined #sbcl 19:53:48 -!- ChanServ has set mode +o nikodemus 19:54:27 nikodemus: iiuc, lichtblau means that, before coresave, it doesn't matter where pages are allocated, only how many. 19:55:32 ah, right. i haven't yet really thought about saving much yet 19:55:50 saving will compactify automagically. 20:05:50 nyef: I'm afraid the darwin/x86-64 mach_exception_handler/mach_msg_server call works by accident 20:06:20 ... Wouldn't be the first thing in this mess that did. 20:06:45 How so this time, though? 20:08:34 pthread_create creates a thread which calls mach_exception_handler with mach_exception_handler_port_set as the arg 20:10:31 mach_exception_handler in turn casts this to mach_port_t in the call to mach_msg_server 20:11:46 this is all fine on 32-bit systems, but I think mach_port_t is a 32-bit type and we cast a 64-bit value to a 32-bit type on 64-bit systems 20:13:43 nikodemus: core saving (in the presence of holes) is the reason the incremental allocation branch builds on relocation: the heap gets recompacted while saving 20:14:55 lichteblau: i got that. that's why saving with holes and relocation are last on my list :) 20:18:21 (... why didn't I commit all this years ago? Oh right, lack of time, the same reason I'm not committing anything these days...) 20:19:47 how's the win stuff moving? 20:20:32 I hope to get the reasons I'm not working on it sorted out in december. 20:23:11 or maybe hlavaty will help out 20:37:47 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 20:42:42 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Quit: +++ killed by SIGSEGV +++] 21:00:15 udzinari` [~user@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 21:03:18 -!- udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds] 21:25:22 Guest49170 [~levgue@xdsl-78-35-148-239.netcologne.de] has joined #sbcl 21:28:24 -!- Guest49170 [~levgue@xdsl-78-35-148-239.netcologne.de] has quit [Client Quit] 21:30:50 homie` [~levgue@xdsl-78-35-148-239.netcologne.de] has joined #sbcl 21:31:26 -!- homie` [~levgue@xdsl-78-35-148-239.netcologne.de] has quit [Remote host closed the connection] 21:32:10 -!- nikodemus [~Nikodemus@GGZYYYMMCCXV.gprs.sl-laajakaista.fi] has quit [Ping timeout: 260 seconds] 21:33:40 homie` [~levgue@xdsl-78-35-148-239.netcologne.de] has joined #sbcl 21:36:50 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 21:36:50 -!- ChanServ has set mode +o nikodemus 21:41:57 -!- homie` is now known as homie 21:59:39 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 258 seconds] 22:06:11 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 22:06:51 ASau [~user@89-178-95-171.broadband.corbina.ru] has joined #sbcl 22:12:20 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 22:12:20 -!- ChanServ has set mode +o nikodemus 22:35:00 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Remote host closed the connection] 22:35:07 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 22:44:25 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 22:47:35 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 22:47:35 -!- ChanServ has set mode +o nikodemus 23:01:22 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 258 seconds] 23:07:14 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 23:07:14 -!- ChanServ has set mode +o nikodemus 23:28:34 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Quit: Leaving] 23:32:48 -!- udzinari` [~user@ip-89-102-12-6.net.upcbroadband.cz] has quit [Ping timeout: 258 seconds]