2015-12-22T00:09:40Z stassats quit (Ping timeout: 272 seconds) 2015-12-22T00:23:41Z scymtym_ quit (Remote host closed the connection) 2015-12-22T01:35:05Z myrkraverk quit (Ping timeout: 255 seconds) 2015-12-22T01:48:27Z psy_ joined #sbcl 2015-12-22T01:49:10Z psy_ quit (Max SendQ exceeded) 2015-12-22T01:49:28Z psy_ joined #sbcl 2015-12-22T02:49:16Z myrkraverk joined #sbcl 2015-12-22T04:08:45Z karswell quit (Ping timeout: 260 seconds) 2015-12-22T04:18:17Z psy_ quit (Remote host closed the connection) 2015-12-22T05:00:24Z sjl joined #sbcl 2015-12-22T05:19:20Z sjl quit (Ping timeout: 250 seconds) 2015-12-22T05:37:24Z myrkraverk: Ok, I forgot what the restarts for broken shift-jis encodings are. Can someone please remind me what I should be looking at? 2015-12-22T05:37:42Z myrkraverk: (some lines are even in utf-8) 2015-12-22T05:37:50Z myrkraverk: And sometimes some symbols are just broken. 2015-12-22T05:37:57Z myrkraverk: Yay for old data. 2015-12-22T05:47:12Z myrkraverk: http://sourceforge.net/p/sbcl/mailman/message/23509194/ 2015-12-22T05:47:58Z myrkraverk: I've been reading that. For me, it's *not* the right thing to do, to just replace invalid characters with a single symbol or string. 2015-12-22T06:03:07Z myrkraverk: So I want to look into hooking into SBCL's system, before I decide to bite the bullet and write my own conversion routines. 2015-12-22T07:11:10Z kanru joined #sbcl 2015-12-22T07:37:35Z myrkraverk quit (Ping timeout: 260 seconds) 2015-12-22T07:52:27Z krzysz00 joined #sbcl 2015-12-22T07:57:11Z Xof: what is the right thing to do? 2015-12-22T08:10:20Z gingerale joined #sbcl 2015-12-22T08:16:25Z loke: There is also cl-iconv 2015-12-22T08:16:34Z loke: it has restarrts for all of that. I implemented them myself. 2015-12-22T08:18:30Z myrkraverk joined #sbcl 2015-12-22T09:10:33Z ASau quit (Ping timeout: 265 seconds) 2015-12-22T09:27:40Z lnostdal quit (Ping timeout: 256 seconds) 2015-12-22T09:40:37Z lnostdal joined #sbcl 2015-12-22T09:53:52Z yvm: Are all these recursive functions in target-sap.lisp are plugs or something? 2015-12-22T09:57:59Z yvm: I want to use sb-sys:sap-int to convert sb-posix:mmap return value, but compiler deletes "unreachable code", when I try to. 2015-12-22T09:59:02Z scymtym: yvm: the functions are for out-of-line calls. the "recursive calls" in their bodies are not actually treated as calls but are translated into an appropriate expansion by the compiler. 2015-12-22T10:01:45Z yvm: Ok, thanks. 2015-12-22T10:02:14Z scymtym: yvm: maybe the compiler detects an earlier error in your code and concludes that the SAP-INT call can never be reached 2015-12-22T10:02:55Z scymtym: or something expands to code that has unused forms in it 2015-12-22T10:21:01Z attila_lendvai joined #sbcl 2015-12-22T10:21:01Z attila_lendvai quit (Changing host) 2015-12-22T10:21:01Z attila_lendvai joined #sbcl 2015-12-22T10:30:10Z krzysz00 quit (Quit: leaving) 2015-12-22T10:36:31Z sigjuice_ quit (K-Lined) 2015-12-22T10:36:46Z sigjuice joined #sbcl 2015-12-22T10:45:50Z stassats joined #sbcl 2015-12-22T10:59:11Z fikusz quit (Quit: Leaving) 2015-12-22T11:31:41Z Xof: I have a cunning plan, but I don't know if I've thought it through properly 2015-12-22T11:32:06Z Xof: no, I know I haven't thought it through properly, but maybe someone here can tell me instantly that this is doomed to failure 2015-12-22T11:32:59Z Xof: for threads on arm: what if we put static space at 0x10000000 -- then NIL can be encoded as an immediate for data processing instructions 2015-12-22T11:34:56Z Xof: for loading/storing the other static symbols, we'd have to use a multi-instruction sequence 2015-12-22T11:39:42Z Xof: then null-tn -> thread-tn, and bob's our uncle 2015-12-22T11:42:04Z flip214: Xof: with static-space at 0x60000000 there'd be 8 - 2 (high bits) - 2 (alignment bits for 32bits) ie. 4 bits == 16 addresses left for "constants" like NIL and T.... 0x60000004, 0x60000008, ... 2015-12-22T11:42:08Z flip214: good idea, BTW! 2015-12-22T11:43:37Z flip214: sorry, 3 upper bits, so only 8 constants. still good enough, I guess 2015-12-22T11:44:26Z Xof: sadly we need actual space for nil: we need to be able to dereference its value, plist, etc etc 2015-12-22T11:44:29Z Xof: it's a symbol 2015-12-22T11:44:41Z Xof: so we only get one symbol 2015-12-22T11:44:48Z flip214: how much space does it need? Ain't a 32bit pointer enough? 2015-12-22T11:45:16Z Xof: once you have NIL, you need to be able to do (symbol-value nil) 2015-12-22T11:45:48Z Xof: symbol-value is roughly "dereference [symbol+symbol_value_offset]" 2015-12-22T11:46:01Z Xof: in other words, it's not the pointer, it's what it's pointing to 2015-12-22T11:46:06Z flip214: well, if a symbol needs, say, 256 bytes, we could put these constants at 0x100, 0x200, 0x300, 0x400 ... lots of space down there ;) 2015-12-22T11:46:38Z Xof: sadly there's another problem: it needs a lowtag 2015-12-22T11:46:41Z myrkraverk quit (Ping timeout: 276 seconds) 2015-12-22T11:46:55Z Xof: so NIL is not 0x10000000, it's 0x1000000b 2015-12-22T11:47:21Z flip214: hmmmm... thanks for the info. so much I don't know. 2015-12-22T11:47:32Z Xof: also sadly, at least my arm kernel doesn't let me mmap space above 0x7f000000 (so I can't use 0x8000000b which would give a bit more room to play) 2015-12-22T11:47:59Z flip214: yeah, right, you'd need to use the 3GB:1GB split for that. 2015-12-22T11:49:42Z flip214: well, 0x[1-7]000000b would be possible - 7 constants, but mapping 7*4KiB... 2015-12-22T11:50:18Z flip214: how big is a symbol, now? if it's 0x20 bytes, we could map 0x4000002b and 0x1000000b to the same page ;) 2015-12-22T11:52:43Z Xof: we need a large continuous area for dynamic space 2015-12-22T11:59:08Z flip214: so, put NIL at 0x0b .... ouch. 2015-12-22T12:02:45Z flip214: hmmm, I can see "struct symbol ... size: 24 bytes". so, if we'd halve the dynamic space, 0x4000002b and 0x4000000b would be usable. 2015-12-22T12:03:10Z flip214: on a RPI with 1GB RAM it might not make sense to have more than 1GB of dynamic space, anyway!? 2015-12-22T12:12:57Z yuankode joined #sbcl 2015-12-22T12:19:09Z gingerale quit (Remote host closed the connection) 2015-12-22T12:29:34Z stassats: Xof: i already proposed that NIL trick some time ago, but stuff like T is not encodable 2015-12-22T12:29:57Z stassats: if both could be immediately encoded, than it would be not so bad 2015-12-22T12:30:31Z stassats: otherwise, NIL can be stuffed into reg_THREAD 2015-12-22T12:31:13Z flip214: stassats: I can offer two symbol addresses, if 1GB dynamic space is sufficient 2015-12-22T12:33:26Z stassats: "2014-05-01T13:54:09Z stassats: though, if static space were higher up, NIL => #x80000003 , T => (+ #x80000003 28) => #x8000001F" 2015-12-22T12:34:10Z Xof: so loading t would take two instructions rather than one 2015-12-22T12:34:12Z Xof: is that so bad? 2015-12-22T12:34:30Z flip214: 0x8... isn't usable in linux 2015-12-22T12:34:38Z flip214: at least not with default boot options 2015-12-22T12:34:46Z Xof: stassats: also, expecting me to remember what you proposed 19 months ago is optimistic :-) 2015-12-22T12:36:05Z stassats: not sure why i used 3 as a lowtag 2015-12-22T12:36:26Z stassats: "if NIL were #x8000003 instead of #x800000B, then it could be encoded with rotations" 2015-12-22T12:36:41Z stassats: how can nil have a lowtag of 3, no idea 2015-12-22T12:37:53Z stassats: i don't remember what i thought 19 months ago as well 2015-12-22T12:41:57Z stassats: Xof: i think there's a lot of comparisons with T and NIL, and if T has to be loaded into a register, there may be not enough registers 2015-12-22T12:42:51Z Xof: lots of comparisons with nil, yes; t? really? 2015-12-22T12:44:43Z flip214: and mapping the zero page isn't a good idea, right? 2015-12-22T12:45:13Z Xof: are we even allowed to do that these days? 2015-12-22T12:45:42Z stassats: 2014-05-01T13:56:23Z stassats: i once tried to make static space start from 0, on x86 2015-12-22T12:45:42Z stassats: 2014-05-01T13:56:58Z stassats: doable, but needs some changes, and null-pointer as a protected address doesn't work anymore 2015-12-22T12:46:14Z stassats: 2014-05-01T13:58:13Z stassats: and it needs ulimit changes 2015-12-22T12:46:14Z stassats: 2014-05-01T13:58:27Z foom: not ulimit, sysctl. 2015-12-22T12:46:14Z stassats: 2014-05-01T13:58:49Z stassats: right 2015-12-22T12:46:30Z stassats: less typing, can just quote me from the past 2015-12-22T12:46:46Z flip214: stassats: +1 ;) 2015-12-22T12:47:50Z flip214: stassats: well, how about leaving 0x0 alone, and use 0x00001040 and above? a symbol every 0x20 gives lots of space... 2015-12-22T12:48:27Z flip214: $ sysctl vm.mmap_min_addr 2015-12-22T12:48:27Z flip214: vm.mmap_min_addr = 65536 2015-12-22T12:48:31Z flip214: grr, same issue 2015-12-22T12:48:53Z flip214: well, 0x000010400 should work. 2015-12-22T12:49:01Z flip214: and 0x000010800 .... 2015-12-22T12:49:49Z flip214: with 0x10c00 we could store 3 symbols in one 4kB page. 2015-12-22T12:50:49Z flip214: and 0x000011[48c]00 via another page would work the same... 2015-12-22T12:50:49Z Xof: lowtag 2015-12-22T12:50:51Z stassats: oh, now i remember why #x3 2015-12-22T12:51:05Z flip214: Xof: arg, right. sorry. 2015-12-22T12:51:19Z flip214: let's just use 0 as lowtag. ; 2015-12-22T12:51:22Z flip214: ;{ 2015-12-22T12:51:52Z stassats: #xB is lowtag only on 64-bit, on 32-bit it's #x3 2015-12-22T12:52:25Z stassats: nil ends in B because it starts at #x08000000, if it started below it could become #x3 2015-12-22T12:52:53Z stassats: due the whole list-as-a-symbol kerfuffle 2015-12-22T12:54:11Z Xof: right 2015-12-22T12:55:06Z stassats: but that would waste a whole page 2015-12-22T12:55:25Z stassats: maybe some other stuff could be below NIL then? 2015-12-22T12:55:30Z stassats: more encoding space 2015-12-22T12:55:30Z Xof: so if we mapped two pages from #x0ffff000, nil could be #x10000003 and t #x10000023 ? 2015-12-22T12:55:51Z Xof: details might be wrong 2015-12-22T12:56:10Z pkhuong: I hope they're read-only maps 2015-12-22T12:56:59Z myrkraverk joined #sbcl 2015-12-22T12:57:07Z pkhuong: oh wait nvm. two real pages, not mapping the same page twice 2015-12-22T12:57:27Z Xof: well we could map the same page twice 2015-12-22T12:57:41Z Xof: but, wait 2015-12-22T12:58:07Z stassats: 10000003 is encodable, not #x10000023 2015-12-22T12:58:37Z Xof: sorry, yes 2015-12-22T12:58:47Z Xof: for some reason I thought 1 was 8 2015-12-22T13:00:06Z Xof: #x60000003 and #x6000001f? 2015-12-22T13:00:40Z Xof: though I'm not sure there are many tests against an explicit t 2015-12-22T13:00:54Z stassats: there is a lot of T returned, that's for sure 2015-12-22T13:01:04Z stassats: not many tests, right 2015-12-22T13:01:58Z Xof: so two instructions rather than one for returning T... I'm not sure that's so bad 2015-12-22T13:03:21Z stassats: i'm now more worried about multiple value returns and NIL 2015-12-22T13:03:53Z stassats: though it could be loaded into a non-descriptor reg 2015-12-22T13:04:51Z pkhuong: inline constants then? 2015-12-22T13:05:20Z pkhuong: reading a IP-relative value might be a cheaper way to materialise the value than a sequence of integer ops 2015-12-22T13:06:10Z stassats: might as well just load from reg_THREAD 2015-12-22T13:06:31Z stassats: PC offsets are limited as well 2015-12-22T13:06:54Z psy_ joined #sbcl 2015-12-22T13:07:38Z Xof: PC offsets are only 4k or so 2015-12-22T13:07:45Z myrkraverk quit (Ping timeout: 260 seconds) 2015-12-22T13:07:49Z Xof: guaranteed compilation failure of sb-unix:unix-select 2015-12-22T13:08:19Z stassats: what about cl:expt? 2015-12-22T13:09:19Z pkhuong: oh right. therefore CCL's trampoline system + related bugs 2015-12-22T13:09:44Z pkhuong: "RISC" "Compiler optimised" 2015-12-22T13:10:33Z milanj joined #sbcl 2015-12-22T13:10:49Z stassats: it was much easier on arm64, with a temporary unwired register, and some instruction macros and macros, i didn't have as much cannot-encode-immediate problems as on ARM 2015-12-22T13:11:00Z milanj quit (Client Quit) 2015-12-22T13:11:07Z stassats: and stack loading is still ugly on arm32 2015-12-22T13:11:27Z milanj joined #sbcl 2015-12-22T13:11:52Z stassats: (adjusting the stack pointer) 2015-12-22T13:12:08Z stassats: no, that would be bad, the frame pointer 2015-12-22T13:14:02Z stassats: maybe i should have modified the vop machinery to allow temporaries for moves 2015-12-22T13:14:20Z stassats: but the problem with temporarires is that you can't allocate them conditionally 2015-12-22T13:16:52Z stassats: anyhow, soon everyone will have arm64 and arm32 will go the way of the alp^Wdodo 2015-12-22T13:18:09Z Xof: I expect to have arm32 for the next 10 years or so 2015-12-22T13:19:28Z stassats: sbcl is already not so great on it, and if we nick another register from it, even worse 2015-12-22T13:19:47Z stassats: so, arm32 for sbcl is not really a good match for anything serious 2015-12-22T13:19:56Z stassats: anything not serious can do without threads, i guess 2015-12-22T13:20:30Z Xof: well we'll have the same number of registers, just thread-tn instead of null-tn 2015-12-22T13:20:46Z Xof: as for "serious": how will we get the next generation of sbcl hackers if there's no room for non-serious? 2015-12-22T13:21:22Z stassats: but the next generation will all have multi core arm64s 2015-12-22T13:22:49Z Xof: I'd like to be able to run on cheap hardware. Not necessarily run super-duper-well, but run 2015-12-22T13:24:15Z stassats: i'm sure there'll be a 64-bit rpi sometime in the next couple of years 2015-12-22T13:24:19Z flip214: I'd like to have a threaded SBCL on my RPi, please... with extra fries, hold the ketchup. 2015-12-22T13:24:33Z stassats: there's nothing inherently much more expensive about 64 bits 2015-12-22T13:26:03Z stassats: http://pine64.com/product is actually cheaper 2015-12-22T13:26:29Z Xof: besides, at some point someone is going to work out how to make small elf binaries out of sbcl, and then I will take over the world 2015-12-22T13:26:49Z stassats: and sbcl.so 2015-12-22T13:27:11Z stassats: and then sell $400 android apps 2015-12-22T13:28:12Z stassats: turns out, SBC means Single Board Computer 2015-12-22T13:28:21Z stassats: Single Board Computer Lisp 2015-12-22T13:29:17Z stassats: that pine thing with 2GB RAM sounds like a perfect SBCL target 2015-12-22T13:30:10Z Xof: it has the downside of not actually existing :-) 2015-12-22T13:30:38Z Xof: it does look a bit like my wandboard, other than the 64-bitness 2015-12-22T13:30:50Z stassats: their kickstarer seems to be doing rather well 2015-12-22T13:31:31Z eudoxia joined #sbcl 2015-12-22T13:32:33Z Xof: at which point they emigrate to Brazil 2015-12-22T13:32:38Z Xof: or Russia 2015-12-22T13:34:47Z stassats: i think people will pay $603,158 just to avoid emigrating to Russia 2015-12-22T13:36:26Z attila_lendvai quit (Ping timeout: 240 seconds) 2015-12-22T13:42:35Z Xof: am I right in thinking that the uses of store-symbol-value in compiler/arm are for things that would be thread-specific in any case? 2015-12-22T13:43:25Z stassats: that would become store-tl-symbol-value 2015-12-22T13:45:38Z stassats: if you have wired tls (which is only available on arm64) then you can forgo computing the address 2015-12-22T13:50:56Z stassats: only available on x86-64 2015-12-22T13:51:31Z stassats: and not in a generic way, that's why i didn't implement it yet, since i would need to genericise it 2015-12-22T13:52:46Z myrkraverk joined #sbcl 2015-12-22T14:04:24Z milanj quit (Quit: This computer has gone to sleep) 2015-12-22T14:07:08Z psy_ quit (Ping timeout: 250 seconds) 2015-12-22T14:21:51Z Xof: is that the gcc-tls I saw? 2015-12-22T14:22:35Z stassats: there are some ifdefs everywhere, but it's only used on x86 2015-12-22T14:22:51Z milanj joined #sbcl 2015-12-22T14:54:34Z Xof: gosh, I'm not used to having two simultaneous active sbcl development lines 2015-12-22T14:56:05Z stassats quit (Ping timeout: 255 seconds) 2015-12-22T15:00:31Z stassats joined #sbcl 2015-12-22T15:10:40Z attila_lendvai joined #sbcl 2015-12-22T15:10:41Z attila_lendvai quit (Changing host) 2015-12-22T15:10:41Z attila_lendvai joined #sbcl 2015-12-22T15:13:35Z dougk_ quit (Ping timeout: 240 seconds) 2015-12-22T15:22:43Z stassats quit (Ping timeout: 260 seconds) 2015-12-22T15:26:37Z dougk_ joined #sbcl 2015-12-22T15:28:52Z stassats joined #sbcl 2015-12-22T15:29:12Z Xof: what are the rules about what lip-tn can hold? 2015-12-22T15:34:13Z sjl joined #sbcl 2015-12-22T15:43:54Z nyef: LIP can hold "interior pointers" and values that are less than the starting address of heap space. 2015-12-22T15:44:00Z nyef: (dynamic space, typically.) 2015-12-22T15:44:37Z nyef: Also possibly values that are MORE than the highest valid dynamic space address, not sure about that last. 2015-12-22T15:45:12Z nyef: The actual logic for messing about with LIP is in scavenge_interrupt_context(). 2015-12-22T15:46:25Z sjl quit (Ping timeout: 260 seconds) 2015-12-22T15:47:22Z eudoxia_ joined #sbcl 2015-12-22T15:47:52Z eudoxia quit (Read error: Connection reset by peer) 2015-12-22T15:49:53Z eudoxia_ quit (Client Quit) 2015-12-22T15:50:53Z Xof: * pointer register to point to the runtime, read-only space, or 2015-12-22T15:50:53Z Xof: * static space without problems. */ 2015-12-22T15:51:01Z Xof: gah 2015-12-22T15:51:07Z Xof: but I think that tells me what I want to know 2015-12-22T15:51:40Z guicho joined #sbcl 2015-12-22T15:51:42Z Xof: which is that assuming read-only / static space are below the lisp heap, I can use lip-tn to store nil-value :-) 2015-12-22T16:01:07Z nyef: Yes, read-only and static space are invariably below dynamic space. 2015-12-22T16:01:26Z nyef: Something about a requirement that NIL be the lowest-addressed object in the system, or something like that? 2015-12-22T16:01:44Z nyef: ... Possibly not that. 2015-12-22T16:10:03Z prxq joined #sbcl 2015-12-22T16:17:36Z nzambe quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) 2015-12-22T16:20:35Z stassats: no matter all the options, somebody needs to implement at least one of them 2015-12-22T16:42:14Z stassats quit (Ping timeout: 245 seconds) 2015-12-22T16:43:23Z stassats joined #sbcl 2015-12-22T16:47:35Z stassats quit (Ping timeout: 240 seconds) 2015-12-22T16:49:27Z stassats joined #sbcl 2015-12-22T16:54:04Z stassats quit (Ping timeout: 265 seconds) 2015-12-22T16:54:26Z stassats joined #sbcl 2015-12-22T17:01:48Z milanj quit (Quit: Leaving) 2015-12-22T17:03:14Z lnostdal quit (Ping timeout: 276 seconds) 2015-12-22T17:07:18Z nyef: For ARM threads, I was thinking to just stick a NIL in the thread structure. 2015-12-22T17:09:58Z guicho quit (Quit: さようなら) 2015-12-22T17:13:13Z flip214: these "Andrew Wolven" mails on sbcl-devel, is that some kind of experiment in AI or markov-chain letter building or something like this? 2015-12-22T17:13:31Z flip214: not sure about the sender passing the Turing test, TBH. 2015-12-22T17:13:44Z stassats: some people are just that crazy 2015-12-22T17:18:07Z lnostdal joined #sbcl 2015-12-22T17:34:01Z Xof: hm, I'm not seeing them. Maybe my spam filtering is working! 2015-12-22T17:34:16Z Xof: I think nikodemus has the keys to sbcl-devel 2015-12-22T18:07:12Z flip214: Xof: http://sourceforge.net/p/sbcl/mailman/message/34714258/ and previous 2015-12-22T18:42:02Z DGASAU quit (Read error: Connection reset by peer) 2015-12-22T18:42:46Z DGASAU joined #sbcl 2015-12-22T19:23:19Z psy_ joined #sbcl 2015-12-22T20:55:52Z rpg joined #sbcl 2015-12-22T21:06:55Z karswell joined #sbcl 2015-12-22T21:54:48Z Xof: ok, I have an arm/sbcl whose only use of null-tn is in load-symbol-value/store-symbol-value 2015-12-22T21:58:02Z Xof: I don't have any hacking time for about 36 hours 2015-12-22T21:58:22Z Xof: does anyone want to finish it off? 2015-12-22T22:05:57Z ASau joined #sbcl 2015-12-22T22:43:46Z prxq quit (Ping timeout: 240 seconds) 2015-12-22T23:30:27Z rpg quit (Ping timeout: 255 seconds) 2015-12-22T23:35:31Z karswell quit (Ping timeout: 260 seconds) 2015-12-22T23:43:15Z yuankode quit (Ping timeout: 240 seconds) 2015-12-22T23:54:51Z lnostdal_ joined #sbcl 2015-12-22T23:58:51Z lnostdal quit (Ping timeout: 260 seconds) 2015-12-22T23:58:54Z ASau quit (Read error: Connection reset by peer)