Search
Thursday, 14th of September 2017, 14:47:52 UTC
14:51:34
Shinmera
Why does make.sh invoke time anyway? Shouldn't that be a responsibility of the user if they want timing data?
14:53:04
stassats
anyway, i finally fixed it
14:57:37
stassats
ugh, the runtime doesn't build on sparc
14:57:47
stassats
error: 'os_context_t {aka struct sigcontext}' has no member named 'si_mask'; did you mean 'sigc_mask'?
15:00:51
stassats
nobody uses sparc anyway, so i'll forgo #ifdefs and just make it work on my machine (ha-ha)
15:04:34
stassats
/usr/bin/ld: sparc architecture of input file `sparc-assem.o' is incompatible with sparc:v9 output
15:09:03
foom
Time to just delete the sparc build?
15:18:16
stassats
and sparc-assem.S is not compatible with v9
15:21:52
stassats
no more v8plus support in the runtime (oh no)
15:22:32
foom
I mean, there's really no point in building sbcl for a 32-bit v8 sparc.
15:22:59
stassats
and there is for alpha?
15:30:28
stassats
i wonder if i just remove static functions from hppa and alpha altogether, will it work?
15:36:57
stassats
invalid magic number in core: 0x5342434c00000f14 should have been 0x5342434c.
15:37:02
stassats
did i build a 32-bit runtime?
15:53:46
Shinmera
foom: You'll probably have to fight nyef if you want to get rid of any architecture
16:08:43
stassats
getting a nice Segmentation fault
16:08:50
stassats
which means it's quite early
16:09:48
stassats
call_into_lisp () at sparc-assem.S:59 59 st reg_ZERO, [reg_NL0+%lo(foreign_function_call_active)]
16:12:03
stassats
the problem is from sethi %hi(foreign_function_call_active), reg_NL0
16:12:10
stassats
foreign_function_call_active is 0 for some reason
18:13:54
flip214
I've given my SBCL process ~6GB of RAM, but after an RSS of 2.4GB it drops into LDB, saying "No more immobile pages available"
18:14:27
stassats
those numbers you listed have no effect on immobile pages
18:15:09
flip214
SBCL 1.3.21.139-8408fe5a7
18:15:18
flip214
okay... so, what should I tune?
18:15:53
flip214
now I tried with 10GB of dynamic space -- but as you said, stopped again at the same size.
18:16:29
flip214
--control-stack-size wouldn't help too, I guess.
18:17:55
flip214
but what would allocate in there? closures?
18:18:11
flip214
I'm allocating quite some data, but what should I change?
18:19:20
flip214
ah, too many symbols? okay, that's an idea...
18:20:02
flip214
I'm currently using a package as a quick de-duplication storage, I can use a hash-table instead.
18:20:34
stassats
well, regardless of whether symbols are immobile, never use abuse packages like that
19:15:35
flip214
I get "There is no applicable method for the generic function XXX when called with arguments ( ... )"
19:15:43
flip214
but there IS such a method
19:16:27
flip214
well, if I try to inspect the functions symbol, I get
19:16:29
flip214
unhandled DEBUG-CONDITION:
19:16:48
flip214
#<SB-DI::BOGUS-DEBUG-FUN "foreign function: new_thread_trampoline"> has no debug variable information.
19:17:10
flip214
so I guess something is broken
19:17:50
flip214
I had that already a few hours ago... but it vanished after I removed all traces of a class (including its methods), and did a restart of my sbcl (to really clean up)
19:19:25
flip214
and (sb-mop:generic-function-methods #'...) tells me that there IS a method for that (single) argument's type
19:20:18
flip214
it did work with less data, ie. smaller inputs
19:20:38
flip214
how would I keep the source line information for the sbcl internal function when rebuilding?
19:21:31
flip214
I already do "make.sh --fancy", so :sb-xref-for-internals should be active
19:22:30
flip214
what would I need, then?
19:23:36
flip214
but I'd like to keep the information about source location of eg. SB-PCL::CALL-NO-APPLICABLE-METHOD
19:29:51
flip214
sb-pcl::flush-effective-method-cache doesn't help
19:35:00
flip214
freshly loaded it works...
19:35:55
flip214
but after some heavy load (11G of 14G RAM used) sbcl doesn't find the method any more
19:36:05
flip214
although the generic function still has it listed
19:42:31
flip214
hmmm, this time sbcl complains about /proc/sys/vm/max_map_count...
Friday, 15th of September 2017, 2:47:52 UTC