01:31:46 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 01:40:24 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 02:08:29 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 02:08:59 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 02:52:56 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 03:13:48 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 03:35:02 homie` [~user@xdsl-78-34-103-253.netcologne.de] has joined #sbcl 03:37:16 -!- homie [~user@xdsl-84-44-252-148.netcologne.de] has quit [Ping timeout: 240 seconds] 06:30:03 stassats [~stassats@wikipedia/stassats] has joined #sbcl 06:47:35 -!- homie` [~user@xdsl-78-34-103-253.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 06:58:08 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Remote host closed the connection] 06:58:48 homie [~user@xdsl-78-34-103-253.netcologne.de] has joined #sbcl 07:47:21 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 08:07:59 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 08:07:59 -!- ChanServ has set mode +o nikodemus 11:04:14 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 11:39:31 -!- hefner [~hefner@ppp-58-9-117-34.revip2.asianet.co.th] has quit [Ping timeout: 240 seconds] 11:46:03 hefner [~hefner@ppp-58-9-119-51.revip2.asianet.co.th] has joined #sbcl 11:50:06 attila_lendvai [~attila_le@adsl-89-134-26-225.monradsl.monornet.hu] has joined #sbcl 12:01:22 hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has joined #sbcl 12:09:40 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds] 13:41:17 stassats [~stassats@wikipedia/stassats] has joined #sbcl 13:43:14 -!- hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has quit [Quit: hargettp] 14:06:23 hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has joined #sbcl 14:42:40 nikodemus or anyone else with commit access, I have a diff to add the openbsd binaries for 1.0.44: http://www.elsasser.org/misc/sbcl-page-openbsd.diff 14:43:52 Note that all that os-version stuff is because binaries compiled for one openbsd release will most likely not work with others, due to libc version bumps 14:45:11 Also I removed :mips from the list of available openbsd platforms, since openbsd does not have any 32-bit mips platforms 15:17:35 rmarynch [~roman@88.135.194.233] has joined #sbcl 15:21:28 joshe: thanks! done 15:23:07 Wow, the openbsd x86 binary has already had two downloads in the last half day 15:24:09 -!- Krystof [~csr21@csrhodes.plus.com] has quit [Ping timeout: 265 seconds] 15:32:23 what? we have per-binary download tracking? where? 15:32:48 Just on the normal user-visible file page 15:32:53 https://sourceforge.net/projects/sbcl/files/ 15:47:16 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 15:48:08 oh! i never noticed we have counters there :) 15:48:25 nyef [~nyef@pool-70-20-44-124.man.east.myfairpoint.net] has joined #sbcl 15:48:33 G'morning all. 15:50:31 nikodemus: You busy? 15:57:00 not particularly 15:57:41 I was looking at bug 553493 recently (error reporting for unknown packages in fasls), and have a possible improvement. 15:58:16 ... If I can find the files. 15:58:16 good! :) 15:58:50 Should I just attach the files to the bug? 15:59:06 (Assuming, that is, that I can find all of them still...) 16:01:15 that sounds fine 16:01:48 i wonder why there are spikes in downloads for some versions 16:02:22 Perhaps some popular packaging system updated then 16:03:06 sexy NEWS items, planet lisp bloggage? 16:03:20 sbcl-10 release was also very popular, iirc 16:04:22 it's 1.0.29, 1.0.22, 1.0.12 16:04:44 If either if you are looking for something to commit then you could consider bugs 669485 and 668332 :) 16:04:56 The latter is even on an OS that people actually use! 16:05:10 ok, i see now, it's the versions for which windows bits were (are) available 16:05:18 s/bits/builds/ 16:06:10 i doubt i'll be doing any sbcl hacking today, unless i run into a bug 16:06:12 Odd, why would binary availability lead to more source downloads? 16:06:25 Oh, that reminds me, 1.1 next month? 16:06:33 joshe: it's not source downloads 16:06:36 homie` [~user@xdsl-78-34-104-144.netcologne.de] has joined #sbcl 16:06:36 or maybe even 2.0! 16:06:47 Eleventh anniversary? 16:06:53 stassats: oh, I see 16:06:58 Save 2.0 for 2019! 16:06:59 oh, nice point 16:07:11 1.1 it is then, i expect 16:07:14 I had been looking at downloads of the source file 16:07:19 2019, sheesh 16:07:36 -!- homie` [~user@xdsl-78-34-104-144.netcologne.de] has quit [Remote host closed the connection] 16:07:38 my big items are better backtraces and looking at the windows patch 16:07:54 ... I should properly comment on that thing. 16:07:59 please :) 16:08:17 Too large a patch, what's the justification for the posix compatibility layer, et cetera. 16:09:07 -!- homie [~user@xdsl-78-34-103-253.netcologne.de] has quit [Ping timeout: 240 seconds] 16:15:33 ... And if you're hacking on backtraces, would you mind taking a look at bug 310175? I'm considering demoting it to Medium or Low or marking it as Incomplete or Invalid or something. 16:18:21 homie [~user@xdsl-78-34-104-144.netcologne.de] has joined #sbcl 16:20:58 nyef: i'll assign it to myself as a reminder 16:21:41 but if you're satisfied that backtracing can no longer construct objects pointing at garbage, feel free to close it 16:23:31 argh. now i managed to upload a manual with an ugly version string 16:23:46 better than 1.0.37 we had up, but... 16:28:40 that's better 16:33:58 Backtracing shouldn't be able to create a pointer into stack space, which closes the hole on creating a pointer to corrupt stack memory, but GC heap verification doesn't have a problem with pointers into stack space anymore, so... I'm not entirely happy with backtrace, but I don't see how it can actively corrupt the image at this point. 16:37:07 nyef: by interpreting fake pointer on stack as a real one (fake root, you know). then someone does map-backtrace and grabs that "object" 16:38:08 when GC seens fake roots on stack, we just pin the page so there's no great loss 16:38:52 when debugger sees them and gives the apparent object to user... Not Good (tm) 16:39:47 admittedly, given the separation between code pages and data pages, and having a stricter make-lisp-obj the issue should be greatly reduced nowadays 16:54:35 nikodemus: make-lisp-obj is sufficiently strict on gencgc that I'm not worried about it. 16:55:47 (How not worried? It checks the object tag /and/ it walks the allocation region from the start. If they don't match up, it won't make the object.) 16:56:42 On cheneygc, the heap can't have invalid pointers on it in the first place. 16:56:54 Err... Stack. The stack can't have invalid pointers on it in the first place. 16:57:27 And the same applies for gencgc/ppc, no unboxed data on the control stack. 17:06:34 ... Say, would there be any real drawbacks to making the x86oid ports use the same pin mechanism as the PPC port does? 17:07:01 Leave the stack conservative, but have an explicit pinned-object list as well. 17:08:50 i've been wanting to do something like that for a while, actually 17:09:19 not for with-pinned-objects, but for pin-objec and unpin-object 17:10:14 Eek. 17:10:35 You'd have to destructively update the pin list to do that remotely properly... Or have two pin-lists... 17:11:12 unpinning can be expensive 17:12:02 but i'm not sure changing with-pinned-object makes sense: currently it is free if the compiler knows the object is live on stack 17:12:17 That's a fair point, I guess. 17:12:23 Free on x86oids, at least. 17:12:37 right 17:14:23 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: Leaving] 17:18:01 *attila_lendvai* is glad a separate #sbcl channel has been created 17:19:14 :) 17:23:10 Well, after all the lisp newbies and other-implementation-users invaded the previous SBCL developer channel... 17:23:19 -!- hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has quit [Quit: hargettp] 18:54:16 hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has joined #sbcl 20:27:14 -!- hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has quit [Quit: hargettp] 20:35:53 hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has joined #sbcl 20:49:31 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 240 seconds] 21:02:19 -!- hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has quit [Quit: hargettp] 21:14:31 -!- hefner [~hefner@ppp-58-9-119-51.revip2.asianet.co.th] has quit [Quit: hefner] 21:15:40 hefner [~hefner@ppp-58-9-119-51.revip2.asianet.co.th] has joined #sbcl 21:25:20 Krystof [~csr21@csrhodes.plus.com] has joined #sbcl 21:25:20 -!- ChanServ has set mode +o Krystof 21:51:00 -!- hefner [~hefner@ppp-58-9-119-51.revip2.asianet.co.th] has left #sbcl 21:51:10 hefner [~hefner@ppp-58-9-119-51.revip2.asianet.co.th] has joined #sbcl 23:04:02 -!- attila_lendvai [~attila_le@adsl-89-134-26-225.monradsl.monornet.hu] has quit [Ping timeout: 265 seconds] 23:17:18 attila_lendvai [~attila_le@adsl-89-135-201-226.monradsl.monornet.hu] has joined #sbcl 23:18:52 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 23:19:21 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 23:36:33 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.]