Ian Henriksen

Okay, what if we go through the global names that are used in the function's bytecode, check if they're currently defined in `__globals__`, then modify the bytecode of the task...

Worth noting: probably the most important question here is "what semantics do we actually want to support?" That'll determine the hoops we have to jump through to make things "work"....

Yah, I think options 2 or 3 are both fine. I was originally thinking we'd want something like 2, but 3 seems perfectly fine. We should probably have an override...

Yah, that's an excellent point. Looking at the code for the first one, I can totally see what's wrong, but that doesn't mean it wouldn't lead to obscure bugs in...

We should probably ask the CUDA developers to fix things on their end, but I doubt we'll see any sort of quick response there (if any at all). Given that...

Maybe related? https://github.com/ut-parla/Parla.py/issues/12

Probably also related: https://github.com/ut-parla/Parla.py/issues/12

Trace for this one: ``` 0x7ff912225188: (handler+0x28) 0x7ff91252a830: (killpg+0x40) 0x7ff903cc7ece: (parse_iso_8601_datetime+0x44e) 0x100000001: -- error: unable to obtain symbol name for this frame ``` This points to https://github.com/numpy/numpy/blob/623bc1fae1d47df24e7f1e29321d0c0ba2771ce0/numpy/core/src/multiarray/datetime_strings.c#L221 as the issue....

See https://stackoverflow.com/questions/51592455/debugging-strategies-for-libraries-open-with-dlmopen.

The best we've been able to do as of this writing is attempt to print out the stack with libunwind. See https://github.com/ut-parla/Parla.py/blob/d82e6d573a5cd5b1e492a99a0106cd90e632961e/parla/vec_backtrace.h#L13. When exactly it works is inconsistent, and symbols...