00:33:08 loke [~loke_@42.61.218.195] has joined #sbcl 01:20:52 -!- loke [~loke_@42.61.218.195] has quit [Remote host closed the connection] 01:27:41 jarod_ch_ [~jarod_che@115.193.163.122] has joined #sbcl 01:30:00 slyrus [~chatzilla@107.200.11.156] has joined #sbcl 02:06:20 -!- echo-area [~user@123.120.224.104] has quit [Remote host closed the connection] 02:22:15 -!- jarod_ch_ [~jarod_che@115.193.163.122] has quit [Read error: Connection reset by peer] 02:24:58 jarod_ch_ [~jarod_che@183.128.140.218] has joined #sbcl 02:25:39 -!- yacks [~py@180.151.36.168] has quit [Quit: Leaving] 02:36:55 jarod_c__ [~jarod_che@183.128.140.218] has joined #sbcl 02:37:10 -!- christoph_debian [~christoph@ppp-188-174-82-173.dynamic.mnet-online.de] has quit [Read error: Operation timed out] 02:38:41 Blkt_ [~pi@82.84.149.56] has joined #sbcl 02:43:45 -!- jarod_ch_ [~jarod_che@183.128.140.218] has quit [*.net *.split] 02:43:45 -!- ivan`` [~ivan@unaffiliated/ivan/x-000001] has quit [*.net *.split] 02:43:45 -!- redline6561 [~redline65@li69-162.members.linode.com] has quit [*.net *.split] 02:43:46 -!- Blkt [~pi@82.84.149.56] has quit [*.net *.split] 02:43:47 -!- daem0n [popoki@unaffiliated/mryaargh] has quit [*.net *.split] 02:43:47 -!- Tribal [tribal@rcfreak0.com] has quit [*.net *.split] 02:43:48 -!- antifuchs [~foobar@boots.boinkor.net] has quit [*.net *.split] 02:44:13 Tribal [tribal@rcfreak0.com] has joined #sbcl 02:44:27 redline6561 [~redline65@li69-162.members.linode.com] has joined #sbcl 02:46:37 ivan`` [~ivan@unaffiliated/ivan/x-000001] has joined #sbcl 02:48:53 -!- jarod_c__ [~jarod_che@183.128.140.218] has quit [Quit: Textual IRC Client: http://www.textualapp.com/] 02:53:55 christoph_debian [~christoph@ppp-93-104-180-147.dynamic.mnet-online.de] has joined #sbcl 03:08:20 robgssp` [~user@cpe-24-93-28-218.rochester.res.rr.com] has joined #sbcl 03:09:24 -!- robgssp [~user@cpe-24-93-28-218.rochester.res.rr.com] has quit [Ping timeout: 240 seconds] 03:09:27 daem0n [popoki@unaffiliated/mryaargh] has joined #sbcl 03:09:27 antifuchs [~foobar@boots.boinkor.net] has joined #sbcl 03:11:54 kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 03:56:44 loke [~loke_@42.61.218.195] has joined #sbcl 03:59:51 yacks [~py@180.151.36.168] has joined #sbcl 04:04:32 robgssp`` [~user@cpe-24-93-28-218.rochester.res.rr.com] has joined #sbcl 04:05:58 -!- robgssp` [~user@cpe-24-93-28-218.rochester.res.rr.com] has quit [Ping timeout: 245 seconds] 04:08:15 -!- robgssp`` is now known as robgssp 04:14:54 -!- kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has quit [Ping timeout: 240 seconds] 04:16:55 kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 04:19:45 -!- Bike [~Glossina@174-25-41-134.ptld.qwest.net] has quit [Ping timeout: 245 seconds] 04:21:20 Bike [~Glossina@174-25-41-134.ptld.qwest.net] has joined #sbcl 04:39:43 -!- Bike [~Glossina@174-25-41-134.ptld.qwest.net] has quit [Ping timeout: 245 seconds] 04:46:14 Bike [~Glossina@174-25-41-134.ptld.qwest.net] has joined #sbcl 04:53:31 -!- homie_ [~homie@xdsl-78-35-171-65.netcologne.de] has quit [Remote host closed the connection] 04:54:39 pnpuff [~wff@unaffiliated/pnpuff] has joined #sbcl 04:56:08 -!- pnpuff [~wff@unaffiliated/pnpuff] has quit [Client Quit] 05:08:52 sdemarre [~serge@91.180.127.203] has joined #sbcl 05:17:38 prxq [~mommer@mnhm-4d011555.pool.mediaWays.net] has joined #sbcl 05:39:45 -!- sdemarre [~serge@91.180.127.203] has quit [Ping timeout: 245 seconds] 06:14:47 drmeister [~drmeister@184.71.117.234] has joined #sbcl 06:28:12 mtsd [~mtsd@213.132.112.86] has joined #sbcl 06:33:20 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Quit: Leaving.] 06:52:53 -!- loke [~loke_@42.61.218.195] has quit [Ping timeout: 248 seconds] 06:59:23 -!- kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has quit [Read error: Connection reset by peer] 07:04:50 -!- drmeister [~drmeister@184.71.117.234] has quit [Remote host closed the connection] 07:13:57 -!- mtsd [~mtsd@213.132.112.86] has left #sbcl 07:16:53 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 240 seconds] 07:17:57 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 07:21:16 yacks [~py@180.151.36.168] has joined #sbcl 07:48:59 kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 08:33:12 specbot [~specbot@common-lisp.net] has joined #sbcl 08:46:54 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 240 seconds] 08:49:36 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 08:59:33 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 09:59:22 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Remote host closed the connection] 10:09:02 -!- Guest19019 [user@nat/google/x-ipcdtyyzkmrlutts] has quit [Ping timeout: 240 seconds] 11:22:09 -!- robgssp [~user@cpe-24-93-28-218.rochester.res.rr.com] has quit [Ping timeout: 246 seconds] 11:58:15 yacks [~py@180.151.36.168] has joined #sbcl 12:59:57 -!- Blkt_ is now known as Blkt 13:04:51 benkard [~benkard@dhcp-138-246-84-127.dynamic.eduroam.mwn.de] has joined #sbcl 13:11:03 segv- [~mb@95-91-241-71-dynip.superkabel.de] has joined #sbcl 13:25:58 -!- segv- [~mb@95-91-241-71-dynip.superkabel.de] has quit [Ping timeout: 245 seconds] 13:27:19 homie [~homie@xdsl-78-35-135-13.netcologne.de] has joined #sbcl 13:29:45 -!- homie [~homie@xdsl-78-35-135-13.netcologne.de] has quit [Client Quit] 13:30:10 homie [~homie@xdsl-78-35-135-13.netcologne.de] has joined #sbcl 13:34:35 wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has joined #sbcl 13:35:32 segv- [~mb@95-91-241-71-dynip.superkabel.de] has joined #sbcl 13:40:44 psilord [~pkeller@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 14:06:16 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Remote host closed the connection] 14:07:50 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 14:13:49 davazp [~user@92.56.26.10] has joined #sbcl 14:27:43 Yay, cl-bench runs on my interpreter. More or less. 14:35:27 good stuff. 14:36:11 fe[nl]ix: yea? 14:36:59 can you try using :iso-8859-1 as encoding instead of :utf-8 ? 14:37:22 hi, is the git from sourceforge no longer updated? I see commits until june 6, and tags only till 1.1.8 14:37:46 prxq: sf changed the url 14:38:18 there should be something around git.code.sf.net/p/sbcl 14:38:20 fe[nl]ix: I tried :ascii, isn't that a synonym? 14:38:49 the code you've shown uses :utf-8 14:38:58 prxq: git://git.code.sf.net/p/sbcl/sbcl 14:39:27 it has &optional arg, which I used to try to find some encoding that speeds it up, but none made much difference, with utf-8 obviously being the slowest 14:39:47 it seems iolib prob was that 90% of CPU was in cffi:foreign-string-to-lisp actually 14:41:03 anyway no diff http://i.imgur.com/6aVf6vh.png 14:41:18 fe[nl]ix: thanks. Interestingly, the old url still works, but has an outdated repo. Weird 14:42:14 prxq: yes... migrations are awesome. 14:50:53 maxm-: it's not that slow here 14:52:09 fe[nl]ix: not slow at all; it took less than zero cycles ;) 14:54:10 milanj [~milanj@82.117.199.26] has joined #sbcl 14:55:50 -!- benkard [~benkard@dhcp-138-246-84-127.dynamic.eduroam.mwn.de] has quit [Ping timeout: 240 seconds] 14:56:14 fe[nl]ix: what is ratio of performance comparing to piping same output to wc -l ? 14:57:34 well, wc -l doesn't do any character decoding 14:58:01 well SBCL native solution at least gets 10x slowdown vs wc -l 14:58:29 I use wc -l as baseline for what C/C++ code ingests the stream.. 14:58:45 benkard [~benkard@dhcp-138-246-84-127.dynamic.eduroam.mwn.de] has joined #sbcl 14:59:20 I have not finished the read-sequence thing, got sidetracked by other stuff, I'll drop a line to see if I can make it closer to C++ like read speed by reading in 64k read-sequence octet blocks 15:02:01 creating a string for each line isn't going to be faster than C 15:07:57 is there an assembly instruction for searching a byte in a memory range ? 15:08:01 for x86 ? 15:10:05 stassats`: yea it kind of sucks CL does not have read-line-into-array thing like C 15:10:15 forcing everyone to write custom bufferer 15:10:18 -!- wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has quit [Quit: none] 15:10:20 it has read-sequence 15:10:25 -!- homie [~homie@xdsl-78-35-135-13.netcologne.de] has quit [Quit: Verlassend] 15:11:07 yes, but read-sequence needs wrapping, because you reading variable-length records with some separator char (end of line), needing an extra layer 15:11:57 wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has joined #sbcl 15:12:02 fe[nl]ix: rep scasb, but that's probably slow. 15:12:09 I think SSE 4.x has something 15:12:15 fe[nl]ix: there's SCAS 15:13:45 wc probably uses strchr which I'd expect to be implemented in terms of the fastest assembly instruction available 15:13:59 -!- wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has quit [Client Quit] 15:19:03 wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has joined #sbcl 15:29:33 -!- Blkt [~pi@82.84.149.56] has quit [Quit: leaving] 15:31:17 -!- davazp [~user@92.56.26.10] has quit [Ping timeout: 248 seconds] 15:41:18 drmeister [~drmeister@184.71.117.234] has joined #sbcl 15:46:41 Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has joined #sbcl 15:48:02 pnpuff [~wff@unaffiliated/pnpuff] has joined #sbcl 15:49:01 -!- pnpuff [~wff@unaffiliated/pnpuff] has left #sbcl 15:59:27 -!- drmeister [~drmeister@184.71.117.234] has quit [Remote host closed the connection] 16:07:15 nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has joined #sbcl 16:08:06 drmeister [~drmeister@184.71.117.234] has joined #sbcl 16:09:46 -!- wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has quit [Remote host closed the connection] 16:12:05 wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has joined #sbcl 16:23:21 btw, read-sequence is no good too 16:23:36 without any line counting, it looks like it calls ansi-read-byte repeatedly 16:23:47 unless I'm doing something horribly wrong 16:24:42 is calling ansi-read-byte bad? 16:25:24 hmm I expected it would optimize by passing entire array to read() syscall 16:26:34 http://paste.lisp.org/display/138009#2 16:26:39 is anything obviously wrong with this test? 16:26:50 its not even attempting to count lines, just read a pipe really fast 16:27:59 This is typical backtrace when I C-c it while it runs http://i.imgur.com/DXietQM.png 16:28:22 tih [~tih@athene.hamartun.priv.no] has joined #sbcl 16:28:43 Hah. You're lucky it doesn't stop reading if the process on the other side of the pipe is slow at presenting data. /-: 16:28:44 top profile so far same as with read line, 90% cpu usage SBCL, 10% rar, while with wc -l test its 90% rar 16:29:01 rar is sitting waiting in pipe_w 16:29:11 with its cpu time increasing at 0.1 rate to wall clock 16:29:19 obvious who is at fault here no? 16:29:25 maxm-: can you upload that rar file somewhere ? 16:29:47 its not the rar file, I guarantee same results with "cat /dev/zero" 16:29:53 even though I have not tried it 16:30:30 well, I'd like to try it nevertheless 16:31:22 just a sec let me see 16:31:29 if there anything obviously private in it 16:31:46 like my broker password :-) 16:34:00 ok uploading 16:37:11 -!- drmeister [~drmeister@184.71.117.234] has quit [Remote host closed the connection] 16:38:35 -!- nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has quit [Remote host closed the connection] 16:39:19 nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has joined #sbcl 16:53:05 brown [user@nat/google/x-oomopdkaaogdyyjd] has joined #sbcl 16:53:40 -!- brown is now known as Guest16051 16:54:49 maxm-: the problem seems to be that (RUN-PROGRAM ... :output :stream) creates a bivalent stream which is treated like a stream with element-type CHARACTER by ANSI-STREAM-READ-SEQUENCE; if i change COMPATIBLE-VECTOR-AND-STREAM-ELEMENT-TYPES-P as in the annotation of your paste, RAR-SLURPER-READ-SEQUENCE gets ~ 100 times faster (with input from cat /dev/zero) on my system 16:55:45 hmm, any way I can do what I need without creating a fifo? 16:55:58 in fact you know what, making fifo is probably best solution anyway 16:56:42 I forgot how large these suckers are, that file expands to 6 gig of data 16:58:09 well, in fact scymtym thats SBCL patch right? 16:58:20 how likely that this makes it into official SBCL? 16:58:38 coz I can certainly live for a while patching SBCL myself, as long as it does not break something else 17:00:08 maxm-: yes, it changes an internal function but can be applied to a running image 17:00:35 note that ANSI-STREAM-READ-SEQUENCE has be redefined as well since COMPATIBLE-VECTOR-AND-STREAM-ELEMENT-TYPES-P is declared inline 17:01:05 for probability of inclusion you have to ask a developer 17:04:24 I need to test it with CCL and if it ends up really fast, SBCL devs would have to do it out of wounded pride :-) 17:05:23 drmeister [~drmeister@184.71.117.234] has joined #sbcl 17:05:38 maxm-: :) 17:19:56 yup after the patch read time only 10% slower then wc -l test 17:21:07 testing adding of "sum (count 10 buf :end n)" right now to simulate wc -l, changed "top" profile to 60% sbcl, 40% rar, I expect around twice slower then C, as it seems COUNT is not highly optimized in sbcl 17:24:17 unrolling count manually into (dotimes), from top, think will get almost C+ like performance, rar is now fully loaded 17:25:52 annotated paste with my results, wc -l 69 seconds, SBCL 79 seconds 17:26:13 maxm-: you could also try repeated calls to POSITION which seems to have more transforms than COUNT 17:27:09 position only finds 1st occurrence, and I'm lazy :-) 17:27:13 i'll run it if you give me code 17:28:30 maxm-: on my computer the sbcl code is surprisingly slow 17:28:46 334s vs 5.5s with iolib 17:29:15 fe[nl]ix: did you notice iolib code is limited to 50000 lines? 17:29:21 coz it never finished after a few hours 17:29:32 hahaha 17:31:42 -!- wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has quit [Remote host closed the connection] 17:31:57 actually I'm going to rerun sbcl's read-line code now, to see if this patch makes a diff 17:32:57 nah won't even do it, as quick looks sees ansi-read-line* does not use read-sequence 17:34:48 wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has joined #sbcl 17:42:58 -!- drmeister [~drmeister@184.71.117.234] has quit [Remote host closed the connection] 17:58:36 -!- maxm- is now known as maxm 18:05:24 Sagane [~Sagane@177.100-226-89.dsl.completel.net] has joined #sbcl 18:33:59 -!- wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has quit [Remote host closed the connection] 18:35:21 ASau`` [~user@p5797EFA3.dip0.t-ipconnect.de] has joined #sbcl 18:36:17 wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has joined #sbcl 18:38:43 OK, my interpreter's performance is... uh... nothing to brag about quite yet, I guess. https://gist.github.com/benkard/5977983 18:38:55 -!- ASau` [~user@p4FF96FAC.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds] 18:40:22 seems like things that involve numbers suffer the most 18:40:27 ah, cool. are ECL and ABCL working as interpreters there? 18:40:37 ECL, yes. I'm not sure what ABCL does. 18:40:58 did you compile the code? 18:41:11 if not, then ABCL should be interpreting 18:42:45 On ABCL? Not explicitly, but cl-bench uses COMPILE-FILE on ABCL, as far as I can tell. 18:43:02 compile-file sounds like compiling 18:43:35 Probably... :) 18:43:50 did you happen to try clisp as well? 18:44:15 Yes, but it crashed. :) 18:44:42 ah, figures :-) 18:46:18 so I'm trying to think of which of the tests are the most relevant ones for basic interpreter performance 18:47:11 e.g. the bignum ones are clearly irrelevant 18:47:25 I'm guessing *TAK and FIB/FACTORIAL may be useful. 18:48:07 yeah, the basic gabriel stuff in general 18:49:13 more importantly, is it faster than the current interpreter? 18:50:13 pretty much impossible not to be... just doing minimal compilation must make an order or magnitude or two of difference 18:50:57 Well, TRTAK is quite fast! (OK, probably a bug in the implementation of TAGBODY or something...) 18:50:58 what if minimal compilation is not desirable? 18:51:42 i.e. you really don't want to recompile after redefining macros 18:51:46 sorry, there is no perfect solution. 18:51:53 I don't think a fast non-minimally compiling interpreter is interesting 18:52:06 well, it'd be interesting. just not plausible 18:53:21 Right. "interesting" (: 18:53:40 benkard: specials aren't supported at all yet, right? 18:54:23 so, how fast is fast enough? will it involve byte-code compilation? 18:57:18 jsnell_: Not in any meaningful way. Undeclared variables are assumed to be special, but that's it. 19:00:09 -!- Sagane [~Sagane@177.100-226-89.dsl.completel.net] has quit [Ping timeout: 264 seconds] 19:01:12 stassats`: it's hard to say how fast is fast enough (there are various use cases for an interpreter, and the abysmal speed of the existing one makes some of them impossible). that's one reason to benchmark against some reference interpreters now -- to see whether this design could be competitive with whatever others are using 19:01:42 pnpuff [~sexehexes@unaffiliated/pnpuff] has joined #sbcl 19:01:46 -!- ASau`` is now known as ASau 19:01:59 A Feeley-style design doesn't seem to lend itself well to byte-code compilation. A stack machine as in CLISP would work better for that. 19:05:20 there are things for which a serializable bytecode would be nice, but there is also something to be said for the simplicity of compiling to closures. so I guess right now where we're at is figuring out: 19:05:39 a) is this a competitive approach 19:06:22 -!- wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has quit [Remote host closed the connection] 19:06:34 b) are there non-speed related goals that this design is particularly good for, or ones that it's ill suited for 19:06:39 i don't think that the presented implementations aim at being efficient interpreters, ECL has two different compilers, ABCL compiles to JVM 19:07:09 stassats`: what would you compare with? 19:07:23 clisp would've been nice, too bad it crashed. maybe disable whatever test was crashing it? 19:07:57 clisp too is compiled. 19:08:58 pkhuong: i would've made sure that the tests are indeed interpreted 19:09:24 then, once it's faster than those, maybe with some other languages 19:09:41 There are implementations of other Lisp dialects that aim at being efficient interpreters, like picolisp and nanolisp. 19:09:58 s/nanolisp/femtolisp/ 19:10:49 stassats`: so, what would you compare with? 19:12:00 pkhuong: well, compiled to bytecode that's then interpreted. it seems like a reasonable enough benchmark 19:12:51 pkhuong: i actually wouldn't, since i don't care about interpretation 19:13:18 stassats`: i see. 19:13:19 but comparing with clisp would be beneficial 19:16:23 the cmucl ir1 intepreter or ir2 bytecompiler could be interesting as well 19:16:29 the goal is just a bit unclear to me, is it strictly interpreting or byte-coded or something else 19:16:35 nyef_ [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has joined #sbcl 19:16:54 i.e., when strict interpretation is as fast as possible, where do you go from there 19:17:28 stassats`: what's strict interpretation? 19:18:00 pkhuong: let's call it one pass evaluation 19:18:30 oh you mean naive sexp walking? the goal is to not do that. 19:19:27 so the internal representation of the minimally compiled code isn't set in stone yet. this version compiles to closures, but bytecodes or threaded code or whatever could be alternatives as well 19:20:35 is increased debuggability a goal 19:20:36 ? 19:20:38 but the goal is to have something that bypasses most of the very expensive compilation machinery and still provides somewhat usable performance 19:20:44 I'd like it to be 19:21:55 since another reason nobody would use the existing interpreter is the impossibility of debugging. a faster intepreter with e.g. a stepper that works the way people expect would be sweet 19:22:43 and other things that a cheap compilation step potentially provides is the potential for JIT-style runtime specialization 19:23:54 benkard: sorry, I feel we've been ripping your stuff apart here. it's really good to see some benchmarks, even if you were disappointed with the initial results 19:24:53 benkard: it's looking nice from here. I'll be keeping an eye on your repo. 19:25:00 Well, it's important to evaluate these things. 19:25:05 what do you think would be the next steps? what I might want to see is maybe addition of clisp to the implementation set (by disabling the problematic test), and some exploration of the performance characteristics on some individual benchmark 19:25:15 for example TAK 19:26:19 I mean, hopefully there's some low hanging fruit there that should be picked before making any conclusions :-) 19:26:22 So thanks all. :) Hmm, yes, good question about what to do next. First, I'll try getting the CLISP benchmarks to run. 19:27:25 I've also just tried benchmarking the existing interpreter, but it errored out on me as well. It only got as far as SUM-PERMUTATIONS (with a result of 73.46). 19:28:06 i wouldn't really care for performance if it had better debuggability, i could "recompile" a frame in the debugger with the interpreter and step through it 19:28:26 something like linux perf or papi might be useful to detect branch prediction issues. 19:30:39 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 19:30:39 I was figuring maybe something lower hanging than that :-) 19:30:58 -!- nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has quit [*.net *.split] 19:30:59 -!- loke_ [~loke@203.127.16.194] has quit [*.net *.split] 19:30:59 -!- pchrist_ [~spirit@li302-95.members.linode.com] has quit [*.net *.split] 19:31:00 -!- Krystof [~user@81.174.155.115] has quit [*.net *.split] 19:31:33 jsnell_: it's probably better nowadays, but I used to have really strange issues with branches in interpreters. 19:32:52 oh, absolutely. but I figure a mere sb-sprof run could show something interesting 19:33:02 loke_ [~loke@203.127.16.194] has joined #sbcl 19:33:04 I rather like the simplicity of the Feeley-style approach, even if closures aren't really the perfect data structure for introspection 19:33:16 but that can be solved 19:33:58 the clear improvement I see is to represent lexical bindings with something that has O(1) or log(n) indexing, and split it into a static (variable names) and dynamic (values) part. 19:34:24 The mapping from variable name to index can then be performed once, at minimal-compilation time. 19:34:38 sdemarre [~serge@91.180.127.203] has joined #sbcl 19:35:11 Ah, yes, I planned to do that. 19:35:19 you can just use de bruijn indices, right? 19:36:06 Bike: kind of. the goals are different, and CL has more than single-argument lambdas. 19:36:56 well, yeah. in my own pokey attempt i had let bindings grouped in a vector and that worked ok. 19:41:21 Krystof [~user@81.174.155.115] has joined #sbcl 19:41:22 -!- sendak.freenode.net has set mode +o Krystof 19:41:33 OK, I need to go, the building is about to be closed for today. 19:42:30 cheers 19:43:24 Bye 19:43:27 -!- benkard [~benkard@dhcp-138-246-84-127.dynamic.eduroam.mwn.de] has quit [Quit: Textual IRC Client: www.textualapp.com] 19:45:24 segv_ [~mb@95-91-241-71-dynip.superkabel.de] has joined #sbcl 19:46:37 wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has joined #sbcl 19:46:37 jdz_ [~jdz@85.254.212.34] has joined #sbcl 19:48:29 flip214_ [~marek@86.59.100.100] has joined #sbcl 19:49:53 -!- pnpuff [~sexehexes@unaffiliated/pnpuff] has quit [] 19:50:53 -!- slyrus [~chatzilla@107.200.11.156] has quit [Ping timeout: 240 seconds] 19:51:18 -!- stassats` [~stassats@wikipedia/stassats] has quit [Read error: Operation timed out] 19:51:44 Sagane [~Sagane@177.100-226-89.dsl.completel.net] has joined #sbcl 19:52:39 -!- segv- [~mb@95-91-241-71-dynip.superkabel.de] has quit [Ping timeout: 246 seconds] 19:52:40 -!- jdz [~jdz@85.254.212.34] has quit [Ping timeout: 246 seconds] 19:52:41 -!- flip214 [~marek@unaffiliated/flip214] has quit [Ping timeout: 246 seconds] 20:08:43 robgssp [~user@cpe-24-93-28-218.rochester.res.rr.com] has joined #sbcl 20:09:42 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 20:13:29 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: sleeping zzz...] 20:19:47 jsnell_ pkhuong any comment on above discussion about read-sequence on fd-streams returned from run-process? 20:20:25 specifically about patching compatible-vector-and-stream-element-types-p as scymtym proposed 20:21:23 either that, or extending run-process to allow specifying element-type 20:24:30 I didn't actually see the code. the description did not make it sound correct (my understanding is that for bivalent streams we pretty much have to disable all internal buffering) 20:25:10 to make sure that switching between binary and character data at any arbitrary point works 20:25:31 maxm: I've never looked at the IO system. 20:25:32 but allowing use of non-:default element-types for run-program seems rather sensible 20:25:46 yeah, it has been a few years for me... 20:29:25 the only problem I can see with adding an :element-type parameter is that the existing run-program interface is kind of wrong in how it deals with stream properties, and this would be propagating the wrongness. but that's not much of a reason 20:29:35 to not do it 20:39:33 on a debian machine around here I have to load-shared-object libgfortran.so, while on the ubuntu boxes I usually use that is not necessary. Any idea what the reason might be? 20:39:50 to do what? 20:40:34 eh of course. Well, to load matlisp :-) 20:41:49 it seems on the ubuntu machines it is already loaded, but not on the others. 20:44:09 thanks for the answer, even though I parse it "well the usual" :-) 20:44:39 prxq: different compiler for lapack, most likely. 20:44:45 unfortunately I have no energy here to submit a patch and test case and all that 20:46:44 pkhuong: matlisp comes with its own lapack, and I compile it with gfortran. Same on the ubuntu machines. 20:53:34 but when I load the resulting .so, I get an undefined symbol under debian, but not on ubuntu. 20:53:46 at least on these weird debian machines 20:54:17 (a thing with too many prcessors and a terabyte of ram) 20:54:37 i would expect it to be loaded automatically 20:55:11 is there :OS-PROVIDES-DLOPEN in *features*? 20:55:24 no idea if that matters 20:55:34 yes it is there 20:55:43 prxq: long shot, but is there some local fancy LD_LIBRARY_PATH? 20:56:08 and otherwise, the sbcl is exactly the same? 20:56:25 pkhuong: hm, indeed 20:56:26 there might be a mismatch between the environment you're expected to work with and the one sbcl is actually executed under. 20:56:48 stassats`: I think so 20:57:05 I compiled sbcl on this machine from source 20:57:09 sbcl 1.1.9 20:57:41 with os-provides-dlopen, load-shared-object is not implemented, so that question was redundant 20:58:27 without 20:58:32 ok 20:58:53 I think I'll set LD_L_P to "" and see what happens 20:59:06 does ldd resolve all the libraries? 20:59:35 stassats`: how would I know? 20:59:49 ldd `your library` 21:00:07 ok i'll try 21:02:02 it says "statically linked". o.O 21:02:56 maybe that's why it doesn't include the symbols you need from libgfortran 21:03:18 indeed. That must be it. 21:03:24 and which symbol is undefined? 21:04:00 but this implies that for some reason the same .asd manages to compile a properly dynamic lib in ubuntu, bot not on this box 21:04:36 is matlisp from the same source? 21:04:48 yes 21:05:04 our own custom version 21:05:33 the symbol is _gfortran_transfer_character_write 21:05:50 *prxq* goes digging 21:06:12 I suspect asdf subtleties 21:06:26 i always blame everything on ASDF 21:08:28 it tends to be a reasonably safe bet :-) 21:09:22 Bike_ [~Glossina@71-214-92-22.ptld.qwest.net] has joined #sbcl 21:09:57 -!- Bike [~Glossina@174-25-41-134.ptld.qwest.net] has quit [Ping timeout: 248 seconds] 21:11:01 ok, fixed that. thanks for the help! 21:11:10 fixed how? 21:11:46 -!- sdemarre [~serge@91.180.127.203] has quit [Ping timeout: 240 seconds] 21:12:18 well, I added "-lgfortran" to the arguments passed to the linker. Let me check if it compiled it shared 21:13:21 it did, which is weird. So -shared with no -lsomething seems to do a static link. 21:13:47 i presume that on ubuntu, -lgfortran is somwhow a default. 21:13:50 maybe if there's nothing to link against 21:14:33 right 21:14:55 -!- Bike_ is now known as Bike 21:20:29 pjb [~t@90.24.196.163] has joined #sbcl 21:25:25 -!- milanj [~milanj@82.117.199.26] has quit [Ping timeout: 248 seconds] 21:26:53 -!- Bike [~Glossina@71-214-92-22.ptld.qwest.net] has quit [Ping timeout: 245 seconds] 21:29:04 Bike [~Glossina@71-222-38-246.ptld.qwest.net] has joined #sbcl 21:31:40 -!- psilord [~pkeller@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 22:03:40 -!- prxq [~mommer@mnhm-4d011555.pool.mediaWays.net] has quit [Remote host closed the connection] 22:07:09 milanj [~milanj@37.19.108.7] has joined #sbcl 22:08:15 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 246 seconds] 22:09:34 wbooze_ [~wbooze@xdsl-78-35-185-241.netcologne.de] has joined #sbcl 22:12:06 -!- wbooze [~wbooze@xdsl-78-35-135-13.netcologne.de] has quit [Ping timeout: 246 seconds] 22:13:32 -!- nyef_ [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 22:16:57 -!- Bike [~Glossina@71-222-38-246.ptld.qwest.net] has quit [Ping timeout: 264 seconds] 22:17:58 Bike [~Glossina@71-222-38-246.ptld.qwest.net] has joined #sbcl 22:30:56 yacks [~py@180.151.36.168] has joined #sbcl 22:41:12 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 256 seconds] 23:08:11 -!- milanj [~milanj@37.19.108.7] has quit [Quit: Leaving] 23:34:54 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Remote host closed the connection] 23:39:13 davazp [~user@112.Red-88-15-121.dynamicIP.rima-tde.net] has joined #sbcl 23:45:18 drmeister [~drmeister@S010610ddb1c81950.vf.shawcable.net] has joined #sbcl 23:47:45 -!- drmeister [~drmeister@S010610ddb1c81950.vf.shawcable.net] has quit [Read error: Connection reset by peer] 23:48:18 drmeister [~drmeister@S010610ddb1c81950.vf.shawcable.net] has joined #sbcl 23:59:14 -!- Sagane [~Sagane@177.100-226-89.dsl.completel.net] has quit [Read error: Connection reset by peer]