freenode/#clasp - IRC Chatlog
Search
16:06:39
Bike
it seems like it does from the description, but then it needs the possible user call-next-method, which they can define with make-method-lambda
16:06:42
beach
I have read the Common Lisp HyperSpec page for CALL-METHOD and MAKE-METHOD several times, and never was able to figure them out.
16:07:26
Bike
hardly anyone uses custom method combinations, so it's not very worrying, but still vexing
16:13:19
beach
I think if I read that page again after having ingested my morning coffee, I might be able to understand it this time. But not after a long day of work.
16:23:33
Bike
ok, so clhs says specifically "The form used with make-method is evaluated in the null lexical environment augmented with a local macro definition for call-method and with bindings named by symbols not accessible from the COMMON-LISP-USER package.", so no call-next-method
16:23:57
Bike
but then (call-method (make-method form) ...), which is explicitly allowed, is just form
16:35:16
Bike
oh hey, and the paper mentions that thing i was worried about yesterday with compile time ensure-generic-function
16:37:08
Bike
defmethod needs a generic function at compile time in order to call make-method-lambda, so if you put a defgeneric in a file followed by a defmethod, the gf will actually be created at compile time by defmethod, and then reinitialized later at load.
16:44:35
Bike
hm, but done this way naive call-next-method uses apply. i'd like more optimizations before doing that
16:46:11
Bike
or... actually i guess all that's needed is a local compiler macro for the common case. or a global one that refers to variables magically
16:47:25
drmeister
Turning on the llvm-ir rewriting optimization in aclasp does slow it down - by about 3min.
16:48:45
drmeister
Just for yucks I profiled a loop in the interpreter - it spends more time doing GO than anything else. That's because GO uses stack unwinding - even local ones.
16:51:16
Bike
i think we could probably have make-method-lambda work like this instead of like in the MOP. i suspect it wouldn't work anyway since we use valists. there's something for later
16:58:03
drmeister
Hmmm, the profiling 'do-flame' command depends on the FlameGraph.git repo being installed in a hard-wired place - I need to change that still
17:13:47
Bike
drmeister: just to confirm, all this stuff in kernel.lsp about discriminating functions written in C is only used during startup?
17:41:14
drmeister
Other things that you may need are also stored in the Atom_O object. Only some of it is copied into the AtomTable_O structure.
18:05:51
Bike
i should make a script that finds functions that aren't exported or called because god do we have a lot of them
21:13:22
Bike
hey. shiho ran into some kind of problem on boot. and i have a question, where are C++ files in the build system? I want to try removing some
21:15:56
Bike
i'm removing the standard-optimized-reader/writer-method things as a prelude to removing the ECL dispatch system
21:16:08
drmeister
It really should just build - when I stopped by the CL code was building. The C++ is done at that point.
21:18:16
drmeister
Crap - it's not like I haven't removed a hundred C++ files. I'm kind of drawing a blank. Ask me tomorrow - I'll probably remember when I stop trying.
21:21:52
shiho
then I got Condition of type: SIMPLE-ERROR Constructing call to intrinsic cc_dispatch_slot_reader - mismatch of arg#0 value[((PREPARE-OP COMPILE-OP))], expected type #<POINTER-TYPE {}*> - received type COMMON-LISP::CONS Available restarts: (use :r1 to invoke restart 1)
21:23:29
drmeister
Bike: So you are removing ECL dispatch? There are a few functions in genericFunction.cc that are needed by fastgf.
21:24:59
Bike
the one in particular that i'm worried about is that there's a "CompiledDispatchFunction_sp" which is treated differently from a general function
21:26:09
Bike
I was hoping I could have set-funcallable-instance-function just work the same for all functions, but i suppose it's okay if it just differentiates that
21:26:25
Bike
hopefully i can just pass invalidated-dispatch-function as a function instead of a symbol, though
21:27:13
drmeister
Here's why - the first entry point takes the arguments from the calling convention and creates a Vaslist and rewinds it - it passes that to the second entry point.
21:29:12
Bike
I think I can remove ECL independently, and just leavea test for the compiled dispatch function type
21:37:10
drmeister
I already have the instance (and the value for the slot-writer) from the dispatch function - I don't need to read them out of the va_list again.
3:28:48
beach
I have started some serious thinking about determining control flow of an arbitrary function with nested functions.
3:31:12
beach
Bike: But, you are right. It is sufficiently complicated that you should leave this to me.
3:32:32
beach
Initial goal: Handle enough cases that the result of simple LETs and things like CAR and CDR can be inlined.
3:34:22
beach
In terms of research, I should figure out examples (that I am convinced exist) where determining precise control flow requires knowing the precise control flow. Hence the difficulty here.