Search
Thursday, 14th of September 2017, 18:47:05 UTC
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, 6:47:05 UTC