rohitksingh_wor1 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
<d_n|a>
What would you suggest for debugging what is presumably memory corruption on the kernel CPU?
<d_n|a>
I'm getting ERROR(runtime::session): session aborted: invalid kernel CPU pointer: 0xe6969328 – pretty sure it's a function pointer codegen issue, but any suggestions beyond staring at the generated LLVM IR?
<whitequark>
d_n|a: basically none. there are no tools available to instrument the kernel CPU
<d_n|a>
That's what I gathered, yeah – just wanted to make sure I'm not missing anything
<d_n|a>
whitequark: Thanks for the confirmation, though, intense staring shall commence. Are there any areas surrounding codgen for calling an array of function pointers you would be suspicious of?
<whitequark>
not off the top of my head
<whitequark>
hm, any chance those are actually method pointers?
<whitequark>
or maybe those are closure pointers with an expired environment?
<d_n|a>
They are method pointers
<whitequark>
can you show me the code?
<d_n|a>
I'm working on a test case. Might not be related to function pointers after all, but memory corruption from something else
<d_n|a>
whitequark: Oh, by the way, do you have any suggestions regarding the recursive setup() call use case from the eval_kernel discussion (#1089)? I might take a stab at implementing string eval, but if there is a cleaner way, I'd much prefer that
<d_n|a>
Basically, is there a way to get a closure/delegate/... of the form `typeof(f) = { RetType function(void*, ArgTypes) fn; void* ctx; }` which is invoked as `f(args) -> fn(ctx, args)`, so that I could have a list of member functions with compatible signatures but different self types?
<whitequark>
d_n|a: I think string eval is a horrible idea and the right way to solve genericism is what I suggested in the issue.
<whitequark>
however, the macros idea is reasonably okay
<whitequark>
if macros are implemented, they should be done on AST level, not string level
<whitequark>
there's already AST nodes for quasiquotation, though they work in a slightly different way than what macros need
<d_n|a>
From my perspective, there is no difference at all between them in terms of hygiene – you'd always need to provide the source code for a complete function, and there are no weird corner cases
<whitequark>
sure there are, you can splice an expression in place of an identifier if you use strings
<d_n|a>
Well, yeah, but the generated code is easily inspectable as a standalone fragment, and there is no weird scoping to take care of – if you put an expression in place of a type, it just won't compile
<d_n|a>
But that's a discussion to have over a (virtual) beverage on a long evening some other day
<d_n|a>
Right now, I'm really just interested in solving the recursive tree setup issue without my language designer hat on
<d_n|a>
I'd be glad for any pointers in that regard, as the amount of copypasta piling up in my codebase is slowly reaching the point where I'm considering just implementing string eval to be done with it.
<d_n|a>
whitequark: ^
<whitequark>
I'll try to do something about it
<d_n|a>
That would be great, thanks – design ideas might also be helpful if you don't get around to it yourself
<d_n|a>
I'm just not sure whether I understood the intent behind the current closure design
<d_n|a>
Hmm, seems like that function pointer issue might actually be related to the fact that some of the function pointers called involved an RPC call and numpy arrays. I'll open an issue if I ever find a nice test case
<whitequark>
what do you mean "intent behind the current closure design"?
<whitequark>
the closures are the way they are to avoid heap allocations