01:24:08 -!- hypercube32 [~hypercube@231.125.189.72.cfl.res.rr.com] has left #sbcl 03:33:02 -!- sbalousek [~sbalouse@ip174-67-214-212.oc.oc.cox.net] has quit [Read error: Connection reset by peer] 03:33:52 sbalousek [~sbalouse@ip174-67-214-212.oc.oc.cox.net] has joined #sbcl 03:52:07 -!- sbalousek [~sbalouse@ip174-67-214-212.oc.oc.cox.net] has quit [Read error: Connection reset by peer] 03:52:50 sbalousek [~sbalouse@ip174-67-214-212.oc.oc.cox.net] has joined #sbcl 06:14:24 flip214 [~marek@2001:858:107:1:7a2b:cbff:fed0:c11c] has joined #sbcl 06:14:24 -!- flip214 [~marek@2001:858:107:1:7a2b:cbff:fed0:c11c] has quit [Changing host] 06:14:24 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 07:30:38 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 07:30:38 -!- ChanServ has set mode +o nikodemus 08:27:45 -!- ASau [~user@176.14.33.178] has quit [Quit: off] 09:07:03 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:13:30 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 12:54:49 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 13:46:32 aerique [310225@xs8.xs4all.nl] has joined #sbcl 13:48:09 Hm, I'm setting *input* to *standard-input* at the start of a program and when I try to read from it later I get a "Bad address" error with SBCL 1.0.50. I've solved it for now by replacing *input* with *standard-input* throughout the program. 13:48:18 Bug's probably in my code anyway. 13:52:55 aerique: what's the exact error you get and the backtrace? 13:54:40 i'll put in on paste.lisp.org in 10 or 15 minutes and be back here then 14:10:01 paste.lisp.org doesn't announce in the channel 14:10:07 nikodemus: here it is: http://paste.lisp.org/display/123804 14:11:57 aerique: is saving a core or executable involved by any chance? 14:12:08 nikodemus: yes 14:12:16 oh 14:12:23 yeah 14:12:23 *aerique* lightbulb 14:12:34 sorry :-| 14:13:03 well, ideally saving a core would mark open fd-streams as invalid or something... 14:13:52 don't worry, you're not the first or last to be bitten by this 14:14:01 i just recognized the symptom 14:14:13 I'm kinda miffed I didn't recognize it. 14:14:41 Not an entirely new issue for me, although it was with dynamic libs in the past. 14:15:34 -!- DGASAU [~user@91.218.144.129] has quit [Remote host closed the connection] 14:15:52 I only ran across it with 1.0.50 though, the 1.0.45 binary hadn't been chugging along fine for a couple of weeks. 14:16:01 oh well, back to work. thanks :) 14:16:11 DGASAU [~user@91.218.144.129] has joined #sbcl 14:17:44 homie [~levgue@xdsl-78-35-154-57.netcologne.de] has joined #sbcl 14:28:54 -!- DGASAU [~user@91.218.144.129] has quit [Remote host closed the connection] 14:29:42 DGASAU [~user@91.218.144.129] has joined #sbcl 14:39:04 -!- DGASAU [~user@91.218.144.129] has quit [Remote host closed the connection] 14:40:08 DGASAU [~user@91.218.144.129] has joined #sbcl 15:02:15 homie` [~levgue@xdsl-84-44-210-160.netcologne.de] has joined #sbcl 15:04:17 -!- homie [~levgue@xdsl-78-35-154-57.netcologne.de] has quit [Ping timeout: 246 seconds] 15:21:12 -!- aerique [310225@xs8.xs4all.nl] has quit [Quit: ...] 15:26:08 before I commit a fast path for div-by-mul, can you think of a simpler expression than ? 15:47:33 -!- homie` [~levgue@xdsl-84-44-210-160.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 15:49:42 homie [~levgue@xdsl-84-44-210-160.netcologne.de] has joined #sbcl 16:07:26 I reviewed a long time ago a paper about exactly this 16:07:32 I wonder if I still have the review copy 16:09:31 It's not complicated (iirc, I quickly doodled this up on a train), but I don't know of a reference (and gcc doesn't seem to do it). 16:11:32 I forget the details, but don't you have the choice of exponent in 2^x? 16:12:40 yes. Linear search (: 16:14:03 http://comjnl.oxfordjournals.org/content/51/4/470.short 16:14:35 gah, no of course I'm not going to be able to access the paper I reviewed, that would be ridiculous 16:14:53 ah, good, citeseer 16:15:35 oh yes, I remember my review now: "your notation is terrible" 16:18:48 This requires coffee. 16:19:14 yes, sadly they argued that changing their notation to make it make sense was too much work :-( 16:20:20 hi lichtblau 16:20:48 good afternoon 16:21:41 lichtblau: have you ever considered using RCU on sbcl ? 16:21:50 fe[nl]ix: for? 16:22:15 not necessarily in internals 16:22:19 we sort of do, if I understand what RCU stands for, in things like CLOS caches 16:22:31 fe[nl]ix: RCU doesn't really make sense in a GCed language. 16:22:37 I was reading https://lwn.net/Articles/262464/ 16:23:02 something like it would be useful in keeping in-process caches 16:23:07 like DNS, etc... 16:23:10 The first paragraph is misleading. 16:23:42 much of what Linux does is unnecessary, having a GC 16:24:00 but memory barriers, perhaps, not 16:24:01 What it achieves is safe reclamation, which, coupled with mostly-functional style and single-word pointer updates, gives concurrent readers and writers. 16:24:20 We already have safe reclamation. 16:24:39 so I only need an atomic setf, then ? 16:24:44 yup. 16:25:21 (which it is, for pointers) 16:26:25 If you want to circumvent the GC for, e.g. an object cache, then maybe... 16:27:23 *lichtblau* is just glad that there's no such caching code left in his app anymore 16:28:05 lichtblau: I found myself wanting (again) an sbcl with a growable heap, so that I could start with a nice smallish (~2GB) soft limit and then expand as necessary 16:28:15 I have (again) lost track of what's happening with all your various trees 16:28:34 someday I will have more brainspace 16:29:13 The "growable heap" feature is waiting for someone to find an actual use case. If you can provide that, it'll appear a lot more attractive. 16:30:48 The only use case I could come up with was "run nicely on Linux with overcommit fully disabled", which is cool but not essential. 16:31:59 *|3b|* 's use case is "don't swap out the rest of my system without warning me" :p 16:32:36 <|3b|> (but don't run out of heap and die on the occasions when i actually /do/ want to use a few GB of live data) 16:36:57 lichtblau: it would have been useful to me quite a few times already 16:37:30 debugging memory leaks is made easier if the heap doesn't keep running out... 16:38:33 and servers which _have_ memory leaks can arrange for a graceful shutdown when the situation gets too bad 16:38:58 I'll up it on the to do list somewhere after sb-safepoint, window threading, and dynspace relocation, but before gencgc rewriting and llvm support :-) 16:39:26 running a LONG development session in emacs and having crapload of data in the core, and dying with a heap-exhaustion during GC is quite irritating as well :) 16:39:29 Now I only need to find time for SBCL at all. 16:39:35 heh 16:40:54 mine is the same as |3b|'s 16:41:46 I want to be able to say "don't use more than 2GB, unless you ask me nicely first, so that I can evaluate whether I think you'll use another 0.5GB, and the rest of my system will carry on working, or another 6GB where I will have to wait for longer than the Universe has existed to move my mouse cursor" 16:42:21 Krystof: OK. So you don't actually need lazy mapping. The soft limit alone would be enough. That's the easy (and portable) half of my (overall pretty easy but slightly unportable) patch. 16:42:23 I've just convinced the R people that this is a good idea, so it's a bit embarrassing that sbcl doesn't... (though mind you sbcl's memory allocation is a LOT more predictable than R's) 16:42:42 true, I can live with address space reservation 16:43:41 yeah, soft limit is a nice halfway house 16:44:35 http://permalink.gmane.org/gmane.comp.lang.r.devel/28565 # for what it's worth 16:45:05 -!- DGASAU [~user@91.218.144.129] has quit [Ping timeout: 260 seconds] 16:50:06 DGASAU [~user@91.218.144.129] has joined #sbcl 16:55:39 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 17:45:36 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 258 seconds] 18:14:23 Krystof: so, would you be ok with a huge dynamic-space-size and a soft limit? 19:00:07 I think so. I don't use the address-space ulimit, and none of the others work 19:21:30 Could add a check on the high water mark for the heap. 19:30:04 nikodemus_phone [~androirc@87-95-54-236.bb.dnainternet.fi] has joined #sbcl 19:42:54 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Ping timeout: 258 seconds] 20:10:10 ASau [~user@176.14.33.178] has joined #sbcl 20:20:09 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 20:23:10 http://repo.or.cz/w/sbcl/lichteblau.git/shortlog/refs/heads/incremental-allocation-using-mmap has the soft limit change (but in a way that depends on the earlier commits, obviously) 20:49:04 beginning GENESIS, creating headers in "src/runtime/genesis" 20:49:04 *** - FUNCALL: undefined function SB!VM:STATIC-SYMBOL-OFFSET 20:49:06 Hm. 20:49:39 I haven't seen build broken for a long time... 20:54:45 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 20:54:45 -!- ChanServ has set mode +o nikodemus 21:15:03 Alright, we've lost ability to bootstrap with CLISP at least. 21:20:32 ASau: there's a bunch of flag to make sure clisp tries to be ansi, and dies early instead of silently failing. 21:20:56 pkhuong: I know all that pretty well. 21:21:09 I have automatic setup for that for a long time. 21:21:20 It's just today the build is broken. 21:21:32 I'm working on isolating it. 21:21:40 k. 21:22:04 I run nightly clisp-hosted builds, I don't believe it's behaved any differently then nightly sbcl-hosted builds for a while 21:22:19 ecl-based bootstrap is broken too. 21:22:29 it's never quite worked 21:22:36 Hm. 21:22:40 I thought it worked. 21:22:42 Alright. 21:22:47 I had an ecl-hosted build working at one point, with lots of patches on both sides 21:23:10 some of them have been committed, but ecl's compiler has evolved to fail in new and interesting ways 21:24:48 according to my logs, building sbcl 1.0.50.20-9b16f09 with clisp 2.49 works on openbsd amd64 5.0-current 21:25:27 well, using "clisp -norc" 21:30:27 pkhuong: awesome 21:30:32 (fast-path stuff) 21:30:46 yeah. Still trying to convince myself it's right. 21:40:23 ok, good stuff: it's the same expression as the paper Krystof reviewed. 21:40:49 bad stuff: the paper's proof is awful to follow. 21:46:45 huh. We don't optimize chains of constant multiplications :\ 21:52:48 wow, that sucks 21:53:01 (or addition, or another such operation) 21:53:07 *any other even 21:54:17 aha, right, we only do it as a source transform 21:56:21 and now I'm not sure if it its better in IR1 or IR2. 21:56:28 oh well. later. 21:59:11 sounds like IR1 to me ... but maybe IR2 would allow it to fire more often 22:00:17 type checking issues at IR1 22:00:58 ? 22:02:10 naw, there'd be a cast node 22:15:58 -!- redline6561 is now known as redline6561_sigt 22:16:04 -!- redline6561_sigt is now known as redline6561_syn 22:44:21 night 22:47:39 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Read error: Operation timed out] 22:48:31 -!- nikodemus_phone [~androirc@87-95-54-236.bb.dnainternet.fi] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]