00:40:49 tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 00:45:48 -!- tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Ping timeout: 264 seconds] 01:37:38 -!- slyrus [~chatzilla@173.228.44.92] has quit [Ping timeout: 245 seconds] 01:41:10 tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 01:45:48 -!- tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Ping timeout: 264 seconds] 01:53:51 -!- wbooze [~wbooze@xdsl-87-79-199-228.netcologne.de] has quit [Ping timeout: 265 seconds] 02:08:29 echo-area [~user@182.92.247.2] has joined #sbcl 02:41:31 tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 02:44:55 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 02:45:55 -!- tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Ping timeout: 260 seconds] 02:48:55 scymtym_ [~user@potash.TechFak.Uni-Bielefeld.DE] has joined #sbcl 02:49:36 -!- scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [Ping timeout: 245 seconds] 03:41:51 tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 03:46:24 -!- tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Ping timeout: 264 seconds] 04:42:13 tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 04:46:39 -!- tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Ping timeout: 260 seconds] 05:42:33 tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 05:47:00 -!- tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Ping timeout: 264 seconds] 06:43:07 tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 06:47:31 -!- tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Ping timeout: 260 seconds] 07:05:04 stassats [~stassats@wikipedia/stassats] has joined #sbcl 07:16:35 -!- specbot [~specbot@tiger.common-lisp.net] has quit [Remote host closed the connection] 07:16:35 -!- minion [~minion@tiger.common-lisp.net] has quit [Remote host closed the connection] 07:16:50 specbot [~specbot@tiger.common-lisp.net] has joined #sbcl 07:16:51 minion [~minion@tiger.common-lisp.net] has joined #sbcl 07:24:24 -!- ASau [~user@46.115.116.92] has quit [Quit: I be back.] 07:31:25 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 07:43:40 tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 07:43:51 -!- Bike [~Glossina@207-224-23-226.ptld.qwest.net] has quit [Quit: leaving] 07:46:13 prxq [~mommer@mnhm-590c2392.pool.mediaWays.net] has joined #sbcl 07:48:02 -!- tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Ping timeout: 252 seconds] 08:25:50 -!- psilord [~psilord@69.180.173.249] has quit [Quit: Leaving.] 08:44:01 tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 08:45:53 *easye* is working through a solaris amd64 compile. Could use some mentoring on internals in the src/code/unix.lisp interface. 08:48:14 what do you mean by "unix.lisp interface"? 08:48:48 -!- tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Ping timeout: 264 seconds] 08:55:38 stassats: UNIX-SELECT syscall is borked. 08:56:17 It crashes the GC when running tests on my platform (amd64-solaris-oi151a7) 08:56:40 So, I mean the "unix.lisp" compilation unit? 08:57:18 oh wow, wasn't it select that compiles into a ton of unrolled cases? 08:59:50 *easye* is in a maze of twisted macros, all alike in syntax... 09:03:20 I have plausible patches for contemporary 64bit GCC toolchain, as well as a speculative port of threads from the BSD configuration. 09:03:53 i suggest you to check that all the foreign type definitions are correct 09:04:01 But I want to at least compile a current sbcl before sharing. 09:04:59 stassats: Will do. 09:05:02 Thanks. 09:05:57 "crashes" == "exahausts" i.e. a bad leak condition exposed in the GC, esp. wrt. threads. 09:07:20 ah, i thought you were implying that a gc invariant was not met 09:07:37 Nope. 09:07:41 have you tried increasing dynamic-space-size? 09:07:51 Jim Wise was aware of this circa a year ago. 09:08:12 But he seems to be doing his own thing not involving solaris sbcl at the moment. 09:08:34 stassats: Yes. It will exhaust whatever memory I give it (out of 64 Gib) 09:09:05 tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 09:09:30 can you paste the table it prints after the exhaustion? 09:09:39 yep. Hold on. 09:17:47 -!- qlkzy [qlkzy@2a01:7e00::f03c:91ff:feae:4a4a] has quit [Ping timeout: 260 seconds] 09:17:58 qlkzy [qlkzy@2a01:7e00::f03c:91ff:feae:4a4a] has joined #sbcl 09:18:01 This is an output of truss as it fills memory http://paste.lisp.org/display/134042 09:19:00 And here's the map http://paste.lisp.org/display/134042#1 09:20:17 Yeah, I think looking at the basic assumptions about alignment are in order. 09:20:39 Maybe part of SBCL still thinks (= :sunos :sparc) 09:22:32 and on which test does it crash? 09:23:32 or is it just during compilation? 09:37:45 This is during make-stage-2.sh 09:38:37 err x-compiling. Using sbcl-1.0.55 as xc-host. 09:39:44 and how did you increase the dynamic-space-size? 09:41:43 make.sh --xc-host="sbcl --dynamic-space-size 8Gb"? 09:42:43 well, it really shouldn't be necessary to have an 8GB heap just to compile unix-select 09:42:53 Krystof: roger. 09:43:19 But yes, I have used --dynamix-space-size up to 64Gb 09:44:18 as --xc-host=? because there's a ./make.sh --dynamix-space-size, but it's for the target 09:44:24 dynamic 09:44:55 stassats: Not for the xc host. I'll double check. 09:45:06 tcr1 [~tcr@178.83.229.138] has joined #sbcl 09:46:19 the one you pasted is just 1GB 09:46:59 solaris may have a larger fd-setsize, which may need more than 1GB 09:48:23 looks like it's 65536 on 64-bit 09:49:23 and unix-select includes the whole body fd-setsize times, that sounds like too much 09:49:26 -!- tcr1 [~tcr@178.83.229.138] has quit [Ping timeout: 246 seconds] 09:49:50 Why can't I seem to just stub out UNIX-SELECT to get things to compile? 09:50:18 because there's unix-fast-select as well 09:50:28 which uses with-fd-setsize too 09:50:37 I don't understandI add #+sunos to the body, I start getting errors in other forms. 09:51:00 Does UNIX-SELECT define the with-fd-setsize form? 09:51:06 Anyways, I gotta go. 09:51:10 no 09:51:21 Thanks for the help stassats. I'll do some work on my own, and report back soon. 09:54:36 with-fd-setsize doesn't include its body n times 09:55:06 num-to-fdset and fdset-to-num, on the other hand 09:58:26 right, and not fd-setsize times, but fd-setsize/n-word-bits 10:00:26 trying to compile unix-select on linux with fd-setsize being 65536 10:01:41 that takes some time... 10:03:27 i'm not really willing to wait, but it's clear that it can be blamed 10:05:48 does it really need to unroll all the cases? 10:06:50 even if it's just for 1024 on linux 10:09:20 -!- tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has quit [Quit: Leaving.] 10:09:48 or was it just written in the good old days were that value was small? 10:16:10 -!- scymtym_ [~user@potash.TechFak.Uni-Bielefeld.DE] has quit [Ping timeout: 252 seconds] 10:23:36 -!- |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [Ping timeout: 256 seconds] 10:25:02 |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 10:33:45 tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 10:41:37 stassats: I suspect it is a relic from ye olde days 11:00:44 attila_lendvai [~attila_le@80-95-90-157.pool.digikabel.hu] has joined #sbcl 11:00:44 -!- attila_lendvai [~attila_le@80-95-90-157.pool.digikabel.hu] has quit [Changing host] 11:00:44 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:02:26 "Abandon all hope who enters here..." comment sums it up 11:03:48 *stassats* turned all those macros into functions, let's see what happens 11:08:43 maybe that is the only difference between unix-select and unix-fast-select? 11:10:12 but unix-fast-select doesn't appear to be doing any of those initializations, and i don't know what are they significance 11:11:10 looks like it relies on the call site to do that 11:12:40 on a different note, aren't our fasls meant to be directly executable? 11:13:09 they have shebangs 11:13:33 yes, but do they work? 11:14:14 for me, I get an illegal read macro character in line 2 11:14:27 which is a shame, because I was about to reply to a comp.lang.lisp article 11:15:50 same here 11:16:23 basically, sbcl --script foo.fasl doesn't work 11:17:55 1.0.42.10 works fine 11:19:45 easye: can you try compiling it with this patch http://paste.lisp.org/display/134044 11:20:58 -!- echo-area [~user@182.92.247.2] has quit [Ping timeout: 245 seconds] 11:21:03 a thorough review of what's actually happening with unix-select, unix-fast-select and serve-event would be required 11:23:02 or with the whole unix.lisp, for that matter 11:25:43 stassats: is it the fasl header that has changed, or something in --script handling? 11:26:29 the headers seem identical 11:28:51 I would tend to blame 4993cd552cc06b6889a2b1898448cb2687ed0b6c on first reading 11:30:10 specifically, I think the change to fasl-header-p might be a problem 11:34:53 what's sbclese for "bivalent stream, please"? 11:35:04 :element-type :default? 11:35:38 crud, that doesn't do what I want anyway 11:39:40 let's see if I can get myself a bit more karma this month 12:29:48 stassats: Back. Applying your suggested patch wrt macro cleansing. 12:53:23 stassats: With the DEFUN instead of macros for fd I get an exit in ldb due to thread-local stack segment. Much further! Thanks! 12:54:26 -!- cmm- [~cmm@bzq-79-181-186-247.red.bezeqint.net] has quit [Ping timeout: 246 seconds] 12:56:23 i thing with just adding some type declarations to those newly ordained functions it could be committed 12:56:35 cmm [~cmm@bzq-109-64-200-5.red.bezeqint.net] has joined #sbcl 12:56:59 I have a fix for the fasl header thing 12:58:41 but now you have to wait a month before recommending executable fasls 12:58:59 meh 12:59:12 no-one reads comp.lang.lisp anyway 13:09:16 good thing you're the release manage, or it could have been two months! 13:09:20 r 13:10:16 *easye* reads c.l.l. 13:10:30 But I had to search to get a reasonable NNTP client other than GNUS. 13:12:29 Invalid exit status: script.test.sh 13:12:31 curses 13:21:00 oh, duh. Damnation 13:21:07 stdin is not seekable 13:21:25 mega1 [~user@2E6B32C4.catv.pool.telekom.hu] has joined #sbcl 13:21:51 I feel that I might have to invent a new option (e.g. --fasl) for automatic fasl executability 13:22:45 punning --script is cute but maybe unsupportable in the end 13:23:15 but what if someone wants to run sbcl --script fasl directly? 13:23:43 is that actually a good idea? Why would they not run sbcl --fasl fasl? 13:23:45 is a fasl a script? 13:23:58 because they don't know better? 13:24:10 talk to me, because obviously no-one has used this functionality in about 9 months 13:24:13 and because it used to work 13:24:50 ok, admittedly, no-one who tracks any releases 13:50:04 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 13:53:36 cmm- [~cmm@bzq-109-67-211-103.red.bezeqint.net] has joined #sbcl 13:55:28 -!- cmm [~cmm@bzq-109-64-200-5.red.bezeqint.net] has quit [Ping timeout: 265 seconds] 14:01:44 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds] 14:02:20 QuickSilver__ [~ait@akasha.ayai.com] has joined #sbcl 14:02:27 -!- QuickSilver_ [~ait@cpe-72-177-30-155.austin.res.rr.com] has quit [Ping timeout: 260 seconds] 14:27:44 Some progress on amd64-solaris-oi151a7. 14:28:08 I certainly have the non-threaded variant working with x86-64. 14:28:41 But it's such a minority platform, I don't think anyone would be interested in the binaries. Mail me if that is not the case. 14:29:28 CFFI certainly works well. 14:30:15 What do SBCL developers do in the ten minutes it takes to rebuild? 14:30:58 *easye* paws at social media. 14:31:21 <|3b|> shop for a faster cpu? :p 14:32:07 *easye* needs some coins to buy more hardware. 14:32:36 |3b|: I can get more cpus of the same speed much easier. 14:33:12 *|3b|* has that problem too :( 14:35:29 an ssd should help more 14:36:01 *|3b|* didn't think sbcl builds hit drive that hard 14:41:56 it takes 4m4s for me to build 14:42:11 QuickSilver_ [~ait@cpe-72-177-30-155.austin.res.rr.com] has joined #sbcl 14:43:34 <|3b|> yeah, that's about what i'd expect from a recent cpu 14:44:35 -!- QuickSilver__ [~ait@akasha.ayai.com] has quit [Ping timeout: 255 seconds] 14:45:29 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 14:52:05 Got bordeaux-threads failing 7 of 9 tests. 14:52:57 I'm seeing buildtimes south of 10 min. 14:53:11 *easye* isn't building on SSD. 14:54:02 *|3b|* gets 5m20s on few-year-old (but moderately high-end) laptop without ssd 14:54:04 Are the PCI-X SSD cards these days? Maybe I should go shopping. 14:54:31 *easye* has four year old datacenter gear. 14:54:40 Get the noise out of the room. 14:54:44 (and free) 14:54:51 4m, ~3m if I skip the contribs. 14:55:08 easye: slam.sh? 14:55:28 true, for unix-select, slam should be fine. 15:01:27 psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 15:01:30 gko [~user@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 15:01:54 <|3b|> hmm, ':BUG-936304' test is nearly killing my system 15:06:54 mega1: I need to check such things out. 15:07:04 -!- lichtblau [~user@port-92-195-127-233.dynamic.qsc.de] has quit [Ping timeout: 260 seconds] 15:07:05 _8david [~user@port-92-195-127-233.dynamic.qsc.de] has joined #sbcl 15:07:16 But mostly it is just straight compilation time of SBCL. 15:08:01 easye: slam.sh skips most of the self-compilation. 15:08:39 I will definitely check it out. 15:08:55 *easye* is manually invoking various steps in make.sh 15:15:39 wbooze [~wbooze@xdsl-78-35-184-30.netcologne.de] has joined #sbcl 15:48:49 st 15:48:51 gah 15:49:12 I am baffled as to how --script in fasls has ever worked 15:50:31 edgar-rft [~GOD@HSI-KBW-091-089-000-047.hsi2.kabelbw.de] has joined #sbcl 15:51:20 -!- gko [~user@114-34-168-13.HINET-IP.hinet.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 16:05:22 antgreen [~user@dsl-207-112-126-76.tor.primus.ca] has joined #sbcl 16:50:16 -!- scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [Remote host closed the connection] 16:51:16 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 17:24:01 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 17:35:13 Krystof: is mask-sign-field supposed to be a noop for signed-words? 17:38:56 (m-s-f sb!vm:n-w-bit ...), that is 17:45:40 Bike [~Glossina@207-224-23-226.ptld.qwest.net] has joined #sbcl 17:51:50 -!- wbooze [~wbooze@xdsl-78-35-184-30.netcologne.de] has quit [Ping timeout: 260 seconds] 17:55:55 ... yes 17:56:02 (I now understand how --script in fasls worked) 17:57:21 I think we need a stream-seekable-p predicate. What's the prior art on that? I think ccl has something 17:57:25 maybe we already have something 17:57:43 either that, or *stdin* should not be stream-associated-with-file-p 17:57:58 Krystof: there seems to be an issue with fixnum, but I guess that's realted to the issue you've been hunting for the past couple months. 18:01:40 possibly 18:02:41 the issue I know comes in to play when at least one of the subresults of a (logand ... #xffffffff) form, which gets converted to signed modarith by cleverness, is not modarith converted 18:02:44 tell me about the fixnum thing 18:03:47 (sb-c::mask-signed-field 64 (- x 7033717698976965573)) 18:03:52 with x signed-word 18:04:14 So (lambda (x) (declare (type sb-vm::signed-word x)) (sb-c::mask-signed-field 64 (- x 7033717698976965573))) 18:04:23 (funcall * 10038) => 2189654337877820273 18:07:42 wbooze [~wbooze@xdsl-78-35-144-81.netcologne.de] has joined #sbcl 18:10:40 ASau [~user@46.115.74.99] has joined #sbcl 18:12:20 -!- scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [Read error: Connection reset by peer] 18:12:57 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 18:17:11 -!- scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [Remote host closed the connection] 18:17:41 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 18:23:20 -!- scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [Read error: Connection reset by peer] 18:24:18 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 18:26:57 -!- psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 18:29:36 -!- scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [Ping timeout: 245 seconds] 18:38:23 stassats [~stassats@wikipedia/stassats] has joined #sbcl 18:46:31 pkhuong: that definitely feels related 18:46:51 it might not be the same, though 18:48:55 one way to speed up sbcl build is to use an sbcl built with speed 3 safety 0 as a host 18:49:04 cuts time from 3:30 to 3:00 here 18:49:43 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 18:51:02 pkhuong: huh, that one might be a simple bug 18:51:02 stassats: any chance to have (parts of) the compilation run in parallel? 18:51:06 no 18:51:11 (basically) 18:51:13 contribs, maybe 18:51:15 -!- scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [Read error: Connection reset by peer] 18:51:36 but if you're rebuilding for developing purposes, you can just not build contribs at all 18:51:38 _that_ would help 18:52:25 i was once sorting issues with run-time, so i cut re-build time to just 9 seconds 18:52:54 so, if you often rebuild some part, you can tweak some part of the build-process 18:53:40 but, for ordinary people, the difference between 3 minutes and 4 minutes shouldn't be significant 18:54:00 wait, no, it's a weird bug 19:02:18 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 19:12:12 wait, how has this ever worked? 19:12:30 magic? 19:12:35 "it hasn't" 19:13:24 pkhuong: I have a totally lame development setup, partly caused by trying to work out how to make --script work 19:13:41 in srctran.lisp, mask-signed-field optimizer, change (best-modular-version width t) to (best-modular-version (1+ width) t) 19:13:56 see how many test failures that causes :-( 19:21:08 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 19:25:12 leuler [~user@p548FD1E3.dip.t-dialin.net] has joined #sbcl 19:26:52 slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 19:45:10 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 19:45:59 csr21@aleph-null:~/src/lisp/sbcl (master)$ SBCL_HOME=`pwd`/output /tmp/hello.fasl 19:45:59 Hello, World! 19:46:04 *bliss* 19:54:31 Krystof: fixes my bug, at least. 19:54:50 Krystof: can I change the width of the swankr repl? 19:55:07 *slyrus* ventures way OT 19:56:06 I don't even know what that means 19:56:36 pkhuong: I think it's right -- I think the logic in the integer-lengths is totally wrong (a (signed-byte 64) result will have an integer-length of at most 63) 19:56:51 yup. 19:57:59 Krystof: when I try to print data frames it splits the columns after roughly 80 cols. any way to force it to print more data frame cols (for a wider window). perhaps this isn't a swankr thing. 19:58:20 -!- QuickSilver_ [~ait@cpe-72-177-30-155.austin.res.rr.com] has quit [Quit: QuickSilver_] 20:03:23 sdemarre [~serge@91.176.162.129] has joined #sbcl 20:03:25 Krystof: no test failed. Which may tell more about the test suite than the patch. 20:07:33 we have nearly 50000 lines of test code 20:07:56 will you commit or shall I, once I'm done writing a fasl test? 20:08:02 I was about to ask. 20:08:04 Please commit. 20:08:27 I'm not sure how to adapt the test case to 32 bit platforms 20:15:20 will do 20:20:44 Stupid question: what sort of things cause the first and second genesis passes to not match? 20:22:51 Err. Actually it looks like src/runtime/sbcl is scrambled -- illegal instruction 20:57:12 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 264 seconds] 21:01:14 -!- mega1 [~user@2E6B32C4.catv.pool.telekom.hu] has quit [Ping timeout: 250 seconds] 21:18:43 QuickSilver_ [~ait@cpe-72-177-30-155.austin.res.rr.com] has joined #sbcl 21:20:51 Krystof: Is the 32-bit test supposed to fail without your patch? It succeeds here, both on x86-64 and on x86. 21:21:50 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds] 21:23:56 it fails for me on sbcl-1.0.55 21:24:00 I would have expected it to fail now too 21:24:23 (that is, it fails for me on sbcl-1.0.55/x86) 21:24:29 I have tested 1.1.2.2. 21:24:42 odd 21:24:45 yes. 21:24:47 -!- QuickSilver_ [~ait@cpe-72-177-30-155.austin.res.rr.com] has quit [Quit: QuickSilver_] 21:27:31 Oh sorry, my mistake. It fails here, too. A stupid error on my side. 21:27:35 woot 21:28:09 It's just that I dislike tests that never fail ;-) 21:28:32 I'm sure I can make more tests fail for you if you like 21:28:41 just let me at this code base, I'm sure I remember how it works 21:28:46 21:29:46 QuickSilver_ [~ait@173-147-34-9.pools.spcsdns.net] has joined #sbcl 21:30:14 *leuler* is looking forward to your next commit ... 21:32:41 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 21:33:49 -!- sdemarre [~serge@91.176.162.129] has quit [Ping timeout: 260 seconds] 21:34:10 -!- QuickSilver_ [~ait@173-147-34-9.pools.spcsdns.net] has quit [Ping timeout: 250 seconds] 21:41:19 QuickSilver_ [~ait@107.33.229.77] has joined #sbcl 21:42:11 -!- tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Quit: Leaving.] 21:46:33 -!- specbot [~specbot@tiger.common-lisp.net] has quit [Remote host closed the connection] 21:46:39 specbot [~specbot@tiger.common-lisp.net] has joined #sbcl 21:58:32 slyrus: you could try options(width=160) or something 22:01:16 -!- wbooze [~wbooze@xdsl-78-35-144-81.netcologne.de] has quit [Quit: none] 22:06:06 tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 22:07:44 attila_lendvai [~attila_le@apn-89-223-187-32.vodafone.hu] has joined #sbcl 22:07:44 -!- attila_lendvai [~attila_le@apn-89-223-187-32.vodafone.hu] has quit [Changing host] 22:07:44 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 22:16:27 attila_lendvai1 [~attila_le@apn-89-223-217-224.vodafone.hu] has joined #sbcl 22:16:27 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 22:27:49 attila_lendvai [~attila_le@apn-37-220-225-20.vodafone.hu] has joined #sbcl 22:27:49 -!- attila_lendvai [~attila_le@apn-37-220-225-20.vodafone.hu] has quit [Changing host] 22:27:49 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 22:29:43 -!- attila_lendvai1 [~attila_le@apn-89-223-217-224.vodafone.hu] has quit [Ping timeout: 244 seconds] 23:13:51 pkhuong: I think I got the REX prefix printing as #X48 nailed down. The disassembler, when fed assembler output directly (and only then), goes through some contortions not to get confused by the fillers in the assembler output. This made it not completely obvious what needed to be done. But in the end the fix is quite simple. 23:19:24 -!- leuler [~user@p548FD1E3.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 23:20:46 attila_lendvai1 [~attila_le@apn-130-43-238-47.vodafone.hu] has joined #sbcl 23:20:46 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 23:31:59 attila_lendvai [~attila_le@apn-89-223-196-229.vodafone.hu] has joined #sbcl 23:32:00 -!- attila_lendvai [~attila_le@apn-89-223-196-229.vodafone.hu] has quit [Changing host] 23:32:00 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 23:32:32 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 23:33:11 -!- attila_lendvai1 [~attila_le@apn-130-43-238-47.vodafone.hu] has quit [Ping timeout: 252 seconds] 23:41:38 -!- edgar-rft [~GOD@HSI-KBW-091-089-000-047.hsi2.kabelbw.de] has quit [Quit: immediate death] 23:41:41 -!- QuickSilver_ [~ait@107.33.229.77] has quit [Ping timeout: 248 seconds] 23:50:30 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Remote host closed the connection]