00:27:29 -!- nikodemus_ [~nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 258 seconds] 00:32:48 -!- ASau [~user@95-24-202-195.broadband.corbina.ru] has quit [Remote host closed the connection] 00:33:53 ASau [~user@95-24-202-195.broadband.corbina.ru] has joined #sbcl 00:58:50 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 03:41:40 stassats [~stassats@wikipedia/stassats] has joined #sbcl 04:03:23 slyrus [~chatzilla@adsl-99-62-138-101.dsl.pltn13.sbcglobal.net] has joined #sbcl 04:04:57 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 04:06:33 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 06:17:34 superjudge [~superjudg@195.22.80.141] has joined #sbcl 06:20:46 flip214 [~marek@2001:858:107:1:7a2b:cbff:fed0:c11c] has joined #sbcl 06:20:46 -!- flip214 [~marek@2001:858:107:1:7a2b:cbff:fed0:c11c] has quit [Changing host] 06:20:46 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 07:31:25 tcr1 [~tcr@217-162-207-164.dynamic.hispeed.ch] has joined #sbcl 08:09:59 nikodemus_ [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 08:16:21 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:48:01 -!- slyrus [~chatzilla@adsl-99-62-138-101.dsl.pltn13.sbcglobal.net] has quit [Read error: Connection reset by peer] 09:53:26 slyrus [~chatzilla@adsl-99-62-138-101.dsl.pltn13.sbcglobal.net] has joined #sbcl 10:19:51 http://paste.lisp.org/display/122361 # comments? 10:24:23 lichtblau [~user@91-65-223-81-dynip.superkabel.de] has joined #sbcl 10:25:49 JuanDaugherty [~Ren@cpe-72-228-177-92.buffalo.res.rr.com] has joined #sbcl 10:28:20 does it handle lack of space in the output buffer correctly? 10:29:03 it allocates the output buffer only after it knows how much it needs 10:29:21 I mean, if CL can't represent the output buffer. 10:30:10 oh, you mean output buffer longer than array-total-size-limit? 10:30:17 at least as large as ;) 10:30:31 no, you get an error from string-to-octets 10:30:49 so, "correctly" fsvo "correctly" 10:30:54 are you sure? 10:31:00 i _think_ so 10:31:03 including null termination? 10:31:34 One of the failure modes for too long arg strings to run-program seems to die in a strange place 10:31:41 hm 10:31:45 (i.e. optimized for speed ;) 10:32:56 what code points encode into 4 bytes in utf8? 10:33:33 the highest ones. 10:34:15 3FFFFFF < codepoint <= 7FFFFFFF 10:34:37 erh, no. bad 10:35:15 > 16 bits. 10:38:37 i can't allocate a string long enough that encoding it should cause any more problems 10:39:35 (length (string-to-octets (make-array (truncate array-total-size-limit 4) :element-type 'character :initial-element (code-char 112387)) :external-format :utf-8 :null-terminate t)) ; dies on me, and unless i mistake that should be the minimum to case trouble 10:40:24 If you just take a bit more than half that, how does gc behave? 10:44:57 i'd need a 32 bit SBCL to test -- a character string 1/4 of array-total-size-limit still takes 1073741823 GIGS on 64bits 10:45:07 because array-total-size-limit is effing huge 10:46:06 so that amounts to 4GB RAM, right? 10:46:21 i used a 32-bit sbcl on amd64 linux for that 10:47:39 flip214: no, 1073741823GB RAM 10:47:56 oh, sorry, misread that ;-) 10:47:57 you're not going to use maxed out arrays on 64 bits, ever 10:48:09 never say never - oh, you didn't ;-) 11:23:56 aha, i know what i missed -- some callers are going to need the number of bytes allocated 11:31:36 I love how "interrupt" doesn't mean "interrupt" in this codebase, and INTERRUPT_PENDING is utterly unrelated to the meaning of INTERRUPT_PENDING in a normal build. 11:32:22 right, you need a 32b SBCL and probably base-string inputs 11:36:16 yah 11:36:39 but if that's an issue, it's an issue with string-to-octets, it seems to me 11:38:11 our external formats make me sad 11:38:18 they're so bloody slow 11:39:11 "sbcl, fast as long as you don't care about IO speed or are willing to roll your own encodings and just shuffle ub8 arrays around" 11:39:25 or use babel, of course 11:47:10 is babel faster? 11:47:11 sb-strings: utf-8 throughout. 11:48:19 I've lost track of why ours are slow 11:48:43 well, I've lost track of about everything 12:02:52 lichtblau: iirc, it is 12:04:00 the architecture leaves something to be desired, and for things like utf-8 we don't do any of the smart things for eg. figuring out how long the result should be 12:04:41 let alone factor those so that we could vopify them on x86-64 where SSE can make it much faster 12:05:06 ok, i think i'm done for 1.0.48.* now. feel free to freeze 12:13:12 -!- nikodemus_ [~nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 258 seconds] 12:18:11 nikodemus_phone [~androirc@87-95-196-47.bb.dnainternet.fi] has joined #sbcl 12:23:46 hargettp [~hargettp@pool-71-184-185-93.bstnma.east.verizon.net] has joined #sbcl 12:26:29 Krystof: almost forgot, the @sbext and @sbconcurrency macros don't look quite right, if you have a look at the sb-concurrency docs and the setf gc-logfile in the pdf. Do you have any idea what's up with that? 12:34:56 looks like the linux kernel has moved to the "the release version number is getting a bit large, let's bump the major/minor for no particular reason"-system that is occasionally suggested for sbcl 12:36:08 2.8 coming out? 12:36:13 no, 3.0 12:36:28 Oh! 12:36:42 perhaps sbcl should fix the I/O - strings - performance problem just discussed, and then move to 1.1, 1.2 or even 2.0 12:36:53 I'd *love* to have fast I/O 12:37:54 -!- hargettp [~hargettp@pool-71-184-185-93.bstnma.east.verizon.net] has quit [Quit: Leaving...] 12:39:03 flip, no disagreement there. Just a question of someone having the time to do it 12:39:56 so just put down the phone and start! you'll be finished in half an hour anyway, AFAIKY 12:44:13 time for actual paying work now 12:54:23 I don't understand what you mean by "not quite right" 12:54:56 do you mean they go into the margin? 12:56:16 they way they look now is by (highly-constrained-by-texinfo) design: the longest package name will have its "sb-" in the left margin. This is to get the index usable, by which I mean all the symbol-names starting in the same place 12:56:31 it might be possible to redefine macros between body text and index, but then again it might not 13:00:35 apparently 3.0 follows a recent trend in strict consolidation releases in OSes 13:01:23 nikodemus [~androirc@178-55-4-94.bb.dnainternet.fi] has joined #sbcl 13:01:23 -!- ChanServ has set mode +o nikodemus 13:04:10 -!- nikodemus_phone [~androirc@87-95-196-47.bb.dnainternet.fi] has quit [Ping timeout: 260 seconds] 13:11:22 -!- nikodemus [~androirc@178-55-4-94.bb.dnainternet.fi] has quit [Disconnected by services] 13:11:23 nikodemus_ [~nikodemus@cs181058025.pp.htv.fi] has joined #sbcl 13:13:35 *|3b|* has vague memories of "adding a restart for every character" showing up in profiles last time i looked at decoding performance... don't remember how big of an effect it was though 13:17:14 Krystof: hm. could we use the "name [package]" style in texinfo as well, and adjust it so that setf names look like (setf foo) [sb-foo] instead of (setf foo [sb-foo])? 13:20:05 "in texinfo"? 13:20:40 if you mean in pdf, the answer is probably "yes" but possibly not "easily" 13:21:53 yes, that was what i meant. fair enough 13:42:07 homie [~levent.gu@xdsl-78-35-151-34.netcologne.de] has joined #sbcl 14:03:36 -!- superjudge [~superjudg@195.22.80.141] has quit [Quit: superjudge] 14:42:25 hargettp [~hargettp@pool-71-184-185-93.bstnma.east.verizon.net] has joined #sbcl 14:47:42 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 15:11:56 antgreen [~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com] has joined #sbcl 15:18:19 -!- JuanDaugherty [~Ren@cpe-72-228-177-92.buffalo.res.rr.com] has quit [Ping timeout: 240 seconds] 15:27:26 JuanDaugherty [~Ren@cpe-72-228-177-92.buffalo.res.rr.com] has joined #sbcl 15:32:41 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 15:33:25 attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has joined #sbcl 15:33:25 -!- attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has quit [Changing host] 15:33:25 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:31:59 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 260 seconds] 16:59:15 -!- cmm [~cmm@bzq-109-67-199-173.red.bezeqint.net] has quit [Ping timeout: 260 seconds] 16:59:46 cmm [~cmm@109.67.199.173] has joined #sbcl 17:14:41 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has left #sbcl 17:31:22 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 248 seconds] 17:38:12 -!- scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has quit [Remote host closed the connection] 17:51:06 tcr2 [~tcr@217-162-207-164.dynamic.hispeed.ch] has joined #sbcl 17:51:06 -!- tcr1 [~tcr@217-162-207-164.dynamic.hispeed.ch] has quit [Read error: Connection reset by peer] 18:18:55 scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has joined #sbcl 18:30:37 fyi re 1.0.49: post-build tests failed @ least twice on Mac OS X 64-bit with threading enabled--the "profile threads" test just used up all CPU cycles for many 10s of seconds before I had to kill it....2 other test runs did not have that issue 18:30:40 I think it's new behavior 18:31:07 i doubt it 18:31:12 lol 18:31:36 thread tests on os x have always been extremely flaky for me 18:31:37 I am accustomed to seeing the threading tests fail...just not that way :) 18:32:56 the only related change is the deadlock detection -- it may create timing differences, and it does make aquisition of contested threads more costly, so that can have a bearing 18:33:42 contested locks, even 18:33:48 well fwiw, the deadlock detection tests seemed to pass :) 18:34:25 oh, there's another 18:34:43 the with-locked-hash-table / with-locked-system-table change 18:36:02 ...but no tests seem to use with-locked-hash-table, and internals all uses the with-locked-system-table, which is same as with-l-h-t used to be 18:36:10 so that should not matter 18:36:29 k 18:40:11 does the profiler use w-l-h-t? 18:48:02 -!- nikodemus_ [~nikodemus@cs181058025.pp.htv.fi] has quit [Ping timeout: 258 seconds] 18:48:42 -!- hargettp [~hargettp@pool-71-184-185-93.bstnma.east.verizon.net] has quit [Quit: Leaving...] 19:10:55 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 19:10:55 -!- ChanServ has set mode +o nikodemus 19:21:30 -!- tcr2 [~tcr@217-162-207-164.dynamic.hispeed.ch] has quit [Quit: Leaving.] 19:30:29 -!- cmm [~cmm@109.67.199.173] has quit [Ping timeout: 260 seconds] 19:31:11 hargettp [~hargettp@pool-71-184-185-93.bstnma.east.verizon.net] has joined #sbcl 19:31:19 cmm [~cmm@109.67.199.173] has joined #sbcl 19:38:32 tcr1 [~tcr@217-162-207-164.dynamic.hispeed.ch] has joined #sbcl 19:55:17 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Remote host closed the connection] 19:56:58 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 19:57:05 -!- tcr1 [~tcr@217-162-207-164.dynamic.hispeed.ch] has quit [Quit: Leaving.] 19:59:54 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: Leaving] 20:00:56 -!- homie [~levent.gu@xdsl-78-35-151-34.netcologne.de] has quit [Read error: Operation timed out] 20:01:27 homie` [~levent.gu@xdsl-78-35-135-216.netcologne.de] has joined #sbcl 20:26:29 christop` [~user@oteiza.siccegge.de] has joined #sbcl 20:28:00 -!- hargettp [~hargettp@pool-71-184-185-93.bstnma.east.verizon.net] has quit [Quit: Leaving...] 20:28:53 slyrus_ [~chatzilla@adsl-99-62-138-101.dsl.pltn13.sbcglobal.net] has joined #sbcl 20:29:44 -!- jiacobucci [~jiacobucc@gw-asdl.ae.gatech.edu] has quit [Ping timeout: 260 seconds] 20:29:44 -!- scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has quit [Ping timeout: 260 seconds] 20:29:44 -!- slyrus [~chatzilla@adsl-99-62-138-101.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 260 seconds] 20:29:44 -!- christoph_debian [~user@oteiza.siccegge.de] has quit [Ping timeout: 260 seconds] 20:29:45 -!- jsnell [~jsnell@ash.snellman.net] has quit [Ping timeout: 260 seconds] 20:29:52 -!- slyrus_ is now known as slyrus 20:30:01 jiacobucci [~jiacobucc@gw-asdl.ae.gatech.edu] has joined #sbcl 20:30:46 scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has joined #sbcl 20:34:47 -!- homie` [~levent.gu@xdsl-78-35-135-216.netcologne.de] has quit [Read error: Connection reset by peer] 20:34:57 jsnell [~jsnell@ash.snellman.net] has joined #sbcl 20:52:46 tcr1 [~tcr@80-218-247-218.dclient.hispeed.ch] has joined #sbcl 21:18:27 hargettp [~hargettp@pool-71-184-185-93.bstnma.east.verizon.net] has joined #sbcl 21:29:00 -!- hargettp [~hargettp@pool-71-184-185-93.bstnma.east.verizon.net] has quit [Quit: Leaving...] 22:23:22 -!- christop` is now known as christoph_debian 22:30:43 attila_lendvai [~attila_le@adsl-89-132-5-226.monradsl.monornet.hu] has joined #sbcl 22:30:43 -!- attila_lendvai [~attila_le@adsl-89-132-5-226.monradsl.monornet.hu] has quit [Changing host] 22:30:43 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 23:43:12 -!- tcr1 [~tcr@80-218-247-218.dclient.hispeed.ch] has quit [Quit: Leaving.] 23:51:53 hargettp [~hargettp@pool-71-184-185-93.bstnma.east.verizon.net] has joined #sbcl