00:04:58 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 00:14:30 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 00:25:17 -!- nyef [~nyef@c-76-119-183-159.hsd1.ma.comcast.net] has quit [Ping timeout: 246 seconds] 00:57:18 -!- slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 252 seconds] 01:38:09 tcr1 [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 02:18:38 -!- tcr1 [~tcr@84-72-21-32.dclient.hispeed.ch] has quit [Quit: Leaving.] 03:15:05 edgar-rft [~GOD@HSI-KBW-091-089-000-047.hsi2.kabelbw.de] has joined #sbcl 03:36:38 -!- Blkt [~user@62.10.10.99] has quit [Remote host closed the connection] 03:51:32 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 04:57:54 slyrus [~chatzilla@adsl-99-24-162-13.dsl.pltn13.sbcglobal.net] has joined #sbcl 05:15:26 -!- slyrus [~chatzilla@adsl-99-24-162-13.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 252 seconds] 05:35:24 slyrus [~chatzilla@adsl-99-24-162-13.dsl.pltn13.sbcglobal.net] has joined #sbcl 06:23:22 hroptatyr [~asathor@sxemacs/devel/hroptatyr] has joined #sbcl 06:24:14 -!- slyrus [~chatzilla@adsl-99-24-162-13.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 240 seconds] 06:26:12 slyrus [~chatzilla@adsl-99-24-162-13.dsl.pltn13.sbcglobal.net] has joined #sbcl 07:02:57 sdemarre [~serge@91.176.151.217] has joined #sbcl 07:25:59 -!- sdemarre [~serge@91.176.151.217] has quit [Ping timeout: 246 seconds] 07:31:24 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Quit: Leaving.] 08:18:11 prxq [~mommer@mnhm-5f75d13a.pool.mediaWays.net] has joined #sbcl 08:33:15 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 08:33:40 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 08:36:09 attila_lendvai [~attila_le@92.47.191.183] has joined #sbcl 08:36:09 -!- attila_lendvai [~attila_le@92.47.191.183] has quit [Changing host] 08:36:09 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 08:36:24 wbooze [~wbooze@xdsl-78-35-181-141.netcologne.de] has joined #sbcl 08:46:26 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 09:11:09 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 09:30:14 -!- jdz [~jdz@85.254.212.34] has quit [Quit: Byebye.] 09:44:26 tcr1 [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 09:49:56 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:32:09 -!- tcr1 [~tcr@84-72-21-32.dclient.hispeed.ch] has quit [Quit: Leaving.] 10:32:11 jdz [~jdz@85.254.212.34] has joined #sbcl 10:59:43 tcr1 [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 11:45:33 -!- wbooze [~wbooze@xdsl-78-35-181-141.netcologne.de] has quit [Read error: Operation timed out] 12:11:44 so, who can propose two nice names for foreign types which would be defined as (unsigned #.sb!vm:n-word-bits) and (signed #.sb!vm:n-word-bits)? 12:12:37 don't we already have word/signed-word? 12:12:49 word is in sb-ext. We might as well export signed-word ;) 12:14:43 ah, but can/should we have a type and an alien type of the same name? I wrote type, but meant alien type. 12:19:45 pretty sure it's doable, but no time :) 12:22:34 hmm. I suppose we're going to use `uword_t' and `sword_t' (well, sometimes we write `lispobj') in the runtime, so we might as well use UWORD-T and SWORD-T in Lisp. 12:22:53 Not that I'm generally a huge fan of these _t names. 12:47:03 I realize I'm channelling Anton to a degree here -- but some advice on this whole issue would be really quite welcome to me. I don't think anyone has really been able to answer this question since Anton first asked it on sbcl-devel years ago... :-( 12:47:15 ... because if you guys don't stop me from choosing some `clever' naming scheme, I'm really tempted to with something, let's say, witty. 12:47:55 uhoh 12:47:57 we can't have that 12:47:58 Think `#define llong long'. If only for the benefit that the search&replace `long -> llong' wouldn't be as awkwardly different as the current proposal `long -> sword_t' is, where it's hard to stop that these are actually the same. 12:48:36 llong? no. 12:49:25 loong? :-) 12:49:33 longish? big? 12:49:49 slispobj? 12:50:43 The "#define instead of typedef" approach would have the distinct advantage that `unsigned XXX' could become `unsigned YYY' instead of having to pull the signedness into the name. 12:51:17 And for something that every developer so far has called `long' I really wouldn't mind a name that looks a little like `long'. 12:52:48 Let's be honest here -- on all platforms that #sbcl is likely to care about for the foreseeable future, the new type just means `long' anyway. 12:53:14 except on alpha? 12:53:18 oh, wait, future 12:53:47 wbooze [~wbooze@xdsl-78-35-156-202.netcologne.de] has joined #sbcl 13:00:34 So, if it's futile to ask practical questions, let me ask a theoretical one. What exactly does lispobj mean? I see its typedef, but that doesn't tell me the conceptual meaning. 13:01:41 Does it mean "could be something with a lowtag" or "...but maybe also a widetag" or "... or just some other word in memory for that matter"? 13:07:35 oh, lovely. And guess what our alien type UNSIGNED is going to mean? Hint: it won't mean C's `unsigned'. 13:08:51 lichtblau: you should try submitting the C runtime to Coverity Scan 13:09:18 it helped me find a few subtle bugs in libfixposix 13:11:31 surely that would ruin their "open source code has fewer defects than commercial one" press release? 13:14:26 let's be optimistic 13:19:18 it would be fun to see what it made of our C runtime 13:19:36 lichtblau: actually the practical question is less ineffable 13:19:49 I think lispobj means "things that people over 20 years have thought might be lispobjs" 13:20:08 "things that might end up in a register" 13:21:47 yeah, OK, I get that 13:22:05 sorry 13:22:54 although maybe we ought to say "things that might end up in a register, except on MIPS nabi, and except on Alpha" :-) 13:26:32 But if that's the case, and noting that this definition need to be prefixed with "unsigned [...]", shouldn't there be an obvious equivalent of `lispobj' that is of the same size, yet signed? 13:27:19 gko [~user@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 13:33:28 when would one need it? 13:37:06 hmm, I currently don't have a better answer than "in the 188 LOC that currently say `long'". 13:38:54 lichtblau: I think lispobjs are meant to have lowtags. 13:55:53 -!- reb [user@nat/google/x-qwelvjiffwcxaeaq] has quit [Ping timeout: 246 seconds] 14:52:40 -!- wbooze [~wbooze@xdsl-78-35-156-202.netcologne.de] has quit [Quit: Client Quit] 14:55:45 *lichtblau* can't make out the pattern for when Anton used intptr_t vs. sword_t 14:56:09 (one is a typedef for the other, so I think it's one of these fancy notional differences only) 14:58:24 they're not the same everywhere 14:59:52 not with a narrow-pointer-on-64bit ABI 15:00:27 like x32, and maybe one of the MIPS ABIs 15:04:33 hmm, using what exact definition of those terms? 15:04:35 intptr_t is a standard, but sword_t is (in this case) an SBCL invention. 15:04:59 So intptr_t is a signed integer of the same size as a pointer. sword_t is a signed integer of the same size as a lispobj. 15:05:42 Those definitions do not differ on any of our current platforms (not even MIPS nabi); neither do they differ on Windows x64. 15:06:12 (alpha doesn't count, it uses #!+ before those anyway) 15:18:05 fe[nl]ix: OK, I see. So regarding your x32 example: 15:18:11 sword_t would be a pointerish thing in one of our memory spaces and intptr_t would be a pointerish thing in native memory? Assuming the hard case where lispobj is 64 bit and void* is 32 bit? 15:18:43 That sounds like a bigger nightmare than even what Anton has had to deal with. 15:21:19 -!- hlavaty [~user@91-65-217-229-dynip.superkabel.de] has quit [Remote host closed the connection] 15:23:47 psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 15:24:18 lichtblau: the other way around: int, void*, and intptr_t would be 32bit while the machine word is 64bit 15:27:24 uhm, OK -- I'll have to read the actual ABI document then :-). That does sound a lot like nabi then. 15:28:45 So... on the plus side that's largely not a problem we aren't already having, and on the negative side not an explanation of Anton's distinction either. 15:28:57 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 15:29:00 thinking of porting to x32 ? 15:29:31 no :-) 15:35:08 fe[nl]ix: restricting the heap to 8GB like some JVMs seems like a preferable choice if we're going in that general direction 15:43:10 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 16:06:00 wbooze [~wbooze@xdsl-78-35-156-202.netcologne.de] has joined #sbcl 16:06:06 nyef [~nyef@c-76-119-183-159.hsd1.ma.comcast.net] has joined #sbcl 16:13:14 G'morning all. 16:13:27 helloooo 16:21:32 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Remote host closed the connection] 16:31:06 Lovely. arrange_return_to_lisp_function() assumes that all non-x86oid targets have reg_LIP. /-: 16:33:59 nyef: I meant to ask -- do you expect your ARM work to function (in as much as it does) on a 800MHz ARM Cortex-A8? 16:36:29 ... Which was the Cortex-A8? 16:40:34 Is SBCL ARM work bnooting back up again? 16:40:52 Looks like I'm targeting a Cortex-A9. 16:41:22 Quadrescence: Somewhat. 16:42:13 nyef: it's what's in the Kindle Touch, which I think is the only ARM thing I have easy access to in the near future 16:42:15 My current log has had almost daily entries since October 1st. 16:42:18 oh well 16:42:40 nyef, rtoym, carl shapiro, and I have begun to draft a document on porting ARM to CMUCL (:(). Perhaps it would be more fruitful to coordinate efforts? 16:42:52 I rather expect that the two cores are similar enough that it could work on both fairly easily. 16:43:03 Quadrescence: How far have you gotten? 16:43:45 I ask, because I'm at the point of trying to scare up a fifth unboxed register so that I can make ALIEN-FUNCALL work. 16:44:48 nyef, preliminary register assignments, *FEATURES*, memory spaces, a bit on instruction representation, a bit on allocation 16:45:18 Ah, so you're badly behind. (-: 16:45:48 yes, well, what can you do with CMUCL fogies? 16:46:26 I've got basic call/return, hairy arg parsing, some of the m-v stuff, all of NLX, a good chunk of array manipulation and fixnum arithmetic... 16:46:40 wow, great! 16:46:51 Oh, and pseudo-atomic and memory allocation. 16:47:51 And I'll confirm the given estimate of 2-4 wizard-months to create a new backend. But those are full-time wizard-months, and I'm not a full-time wizard. 16:48:51 Have you swiped the assembler definitions from my old arm-port tree yet? 16:49:48 and you're doing it from scratch, aren't you, rather than copy-and-paste from the nearest equivalent? 16:50:09 No. Unfortunately I think they feel the need to do everything from scratch, even going as far as to essentially ignore all Prior Art (TM). 16:52:47 I'm copying from the nearest equivalent whenever I can. Thus far, that's typically been PPC for most things, SPARC and X86 for function-call/return, MIPS for array access... 16:52:48 Which I don't want, but it also seems the CMUCL guys have more consistent motivation than SBCL folks here. :) 16:54:11 Oh, and predicated code is AWESOME. 16:54:55 ARM DEFAULT-UNKNOWN-VALUES doesn't use *ELSEWHERE* at all. (-: 16:56:12 Hrm. Actually, I wonder if we can rewrite the x86oid DEFAULT-UNKNOWN-VALUES in the same way, given that they have MOVcc? 17:02:11 cmov is register-dest only. Workable. 17:14:16 nyef: oh yeah, we avoid cmov a lot in the x86oid backends. I don't think it makes sense anymore ;) 17:17:54 It makes more sense on the 32-bit backends than the 64-bit ones. 17:18:09 Krystof: well, if I do the FP bits, I expect A8 will suck at FP. 17:18:49 If I do the FP bits, I expect EVERYTHING will suck at FP. (-: 17:19:18 nyef: even then... unless the branch is very easily predicted. 17:20:20 CMOV stopped sucking around the pentium M, and it's usually a win in code density anyway. 17:20:52 Sure, but what about the poor unfortunates who are still running on a 486? 17:21:30 do these things have enough RAM for us? 17:21:43 conditionalize on a feature that's enabled by default? 17:22:58 I think even I will these days admit that 486s are below spec for running sbcl 17:23:23 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Ping timeout: 272 seconds] 17:23:55 "If it can't build SBCL in less than an hour, why are you bothering?" 17:24:16 oh, no, that's not fair 17:24:36 True. It's obnoxious trying to source a MIPS box that fast. 17:25:26 we need the people with the ancient hardware and the large amount of time to become the sbcl leaders of tomorrow 17:26:18 kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #sbcl 17:27:19 Or we need to remove the HPPA and Alpha backends from the source tree? 17:27:47 Though the bizarre heap model from the Alpha should probably be preserved for posterity somehow. 17:28:00 nyef: btw (don't know if it helps), but I can give you ssh access to my 50min-build-time mips 17:28:44 have we hit a point when qemu on a modern amd64 is quicker/more convenient? 17:29:17 My current plan is to make sure that the build fix that I have in my current tree still works, commit it upstream, and then ignore MIPS until I can source a faster machine. 17:29:30 I have enough to do for the next while with ARM and with actual paying work. 17:30:35 nyef: you were thinking about tekmote, right? FWIW, they _do_ ultimately deliver (takes about a month), but are a little, erm, weird. 17:31:11 Probably one of the MIPS android tablets, actually. 17:31:20 Faster hardware. 17:38:23 -!- gko [~user@114-34-168-13.HINET-IP.hinet.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 17:39:01 brown [user@nat/google/x-ggisghvbpalfyekt] has joined #sbcl 17:39:33 -!- brown is now known as Guest4987 17:46:53 -!- Guest4987 [user@nat/google/x-ggisghvbpalfyekt] has quit [Ping timeout: 246 seconds] 17:49:52 Actually, my current plan might also involve resurrecting me a PPC box, since there are some loose ends on that platform that could do with tying off. 17:53:31 attila_lendvai [~attila_le@92.46.5.117] has joined #sbcl 17:53:31 -!- attila_lendvai [~attila_le@92.46.5.117] has quit [Changing host] 17:53:31 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:12:18 sdemarre [~serge@91.176.151.217] has joined #sbcl 18:15:06 Guest4987 [user@nat/google/x-foeizhmevzcdixvm] has joined #sbcl 18:36:45 -!- slyrus [~chatzilla@adsl-99-24-162-13.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 276 seconds] 18:37:24 -!- tcr1 [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Quit: Leaving.] 18:37:58 nyef: Where's the current log? Only one I can find was last updated May 2010... 18:59:30 redline6561: in nyef's ~ I believe. 19:00:01 Ah, not on the web. Got it. Thanks. 19:13:44 Yeah, somewhere under ~/src/lisp/sbcl/arm-port-2/. 19:29:01 is there a sbcl branch somewhere that should work on an ARM (eg. raspberry pi)? 19:29:10 Define "work". 19:29:33 Mine says "CATS. CATS ARE NICE." when you try to run it, for example. 19:41:18 That said, if I can get ALIEN-FUNCALL going at some point this weekend, it might get more interesting. 19:41:59 nyef: is that some publicly available branch? 19:42:05 Not yet, no. 19:42:26 Why, you interested in working on an unfinished SBCL backend? 19:44:25 well, working is too optimistic ... but I might help testing. 19:45:09 It's not at that point yet, I'm afraid. 19:45:29 although, on another thought - that would require that I get a raspberry delivered .... the timeframes keep moving. 19:46:04 well, in the meantime I could try ECL. gcc is installed per default in Raspbian, so that might work. 19:46:26 Not even trying to run !COLD-INIT yet, even. I'm still at the point of putting together small test cases that try to do something like call a function, or call a function with an &OPTIONAL argument, or use a CATCH form, that kind of thing. 19:47:12 flip214: ask on #lisp. h4ns got something working a couple weeks ago 19:47:17 oh, ok. thanks a lot, anyway. 19:47:44 pkhuong: thanks for the tip, but I think I'll wait until I have some hardware for testing. 19:48:20 pkhuong: when's the next blog post due? looking forward to some more of that. 19:48:57 That said, if I get ALIEN-FUNCALL working then I'm pretty much at the point of trying to add files to the core to see what breaks and what doesn't. 19:50:37 flip214: hard to tell. I have real publications to worry about. 20:02:34 pnpuff [~aeiou@unaffiliated/pnpuff] has joined #sbcl 20:12:44 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 20:21:59 slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 20:31:00 milanj [~milanj_@93-87-194-171.dynamic.isp.telekom.rs] has joined #sbcl 20:32:06 Hrm. Second genesis. Looks like it DOES take all afternoon to build SBCL on my current MIPS system. 20:36:25 nyef: no way to cross-compile? 20:36:55 would be nifty to have multiple backends available in sbcl, and just changing a special to specify which arch to build for ... 20:37:25 pkhuong: understandable. thanks a lot for your insightful articles anyway! 20:39:15 Cross-compiling would involve multiple file-transfer steps. 20:39:33 And I'm curious as to quite how slow my target machine actually is. 20:40:24 nyef: I'd have hoped to just build a new core file in RAM or on disk ... this could be transferred easily (or perhaps implicitly, if using NFS) 20:40:55 Cross compiling SBCL should actually be fairly straightforward these days, even more than it traditionally was, though I don't know if the support code has bit-rotted again over the past however long. 20:42:17 Assuming that you have a shared filesystem (and if you don't you'll need to ship the entire build tree back and forth between host and target), you run make-config.sh on the target, make-host-1.sh on the host, make-target-1.sh on the target, make-host-2.sh on the host, make-target-2.sh on the target, make-target-contrib.sh on the target, and you're "done". 20:42:50 If you want to specify a particular host lisp (the --xc-host build option), you specify a host machine path for it when you run make-config.sh on the target. 20:43:07 And it took a bit of work to make it that straightforward. (-: 20:43:45 ah yes, that's what the comments in make.sh say. 20:44:06 For a while, it wasn't so easy to do. 20:44:19 I can guess. 20:44:33 In fact, for a while, the documentation had gotten out of sync with the build scripts. 20:44:56 So doing a cross-build involved a bit of trial, error, and investigation. 20:45:31 -!- pnpuff [~aeiou@unaffiliated/pnpuff] has left #sbcl 20:46:58 Anyway, I need ONE build for MIPS, I check in the commit, and then I plan to ignore the MIPS stuff for at least a couple of months. 20:52:51 hmmm, the *target*.sh are only ¼ of the whole time for me. 20:53:39 ... And your point is? 20:54:21 that splitting the work and use a faster machine might save a lot of time 20:54:31 It occurs to me that I'm not going to get a baseline for how slow this device is because the SB-CONCURRENCY contrib is going to fail that one damned test. Again. 21:33:52 So, I'm guesstimating about four hours to a build on this thing. And I'm guesstimating because I don't have exact figures, because SB-CONCURRENCY doesn't pass its test suite on non-threaded targets. 21:36:22 lichtblau: Okay, I'm probably done with MIPS until at least 2013. 21:47:49 thanks! (so, the rdev thing still remains to be pushed then?) 21:52:51 Yeah. I don't know which of four (!) struct stat definitions are valid, so anything I come up with would be a hack. 21:57:33 where are those four definitions ? 21:57:45 I forget. Same damned file, though. 21:57:55 One of the system headers. 21:58:42 ... now we just need drewc to show up, right...? 22:06:01 I don't get the reference 22:06:59 "The gang's all here"? 22:07:53 Ah well, nevermind. 22:08:27 then we need a fourth member 22:08:46 as a respectable gang 22:10:57 Ah, good point. 22:11:13 Maybe we can talk Andrew into it? 22:12:41 good idea 22:16:35 -!- sdemarre [~serge@91.176.151.217] has quit [Ping timeout: 240 seconds] 22:27:41 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Ping timeout: 265 seconds] 22:36:13 -!- psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 22:54:39 -!- milanj [~milanj_@93-87-194-171.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 22:55:48 -!- wbooze [~wbooze@xdsl-78-35-156-202.netcologne.de] has quit [Remote host closed the connection] 22:57:09 wbooze [~wbooze@xdsl-78-35-156-202.netcologne.de] has joined #sbcl 23:34:29 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 23:35:04 -!- nyef [~nyef@c-76-119-183-159.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 23:45:27 -!- slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 245 seconds] 23:59:22 slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl