Pablo Galindo Salgado

> @pradyunsg totally agree. Did you mean to say "pablogsal"? I cannot see @pradyunsg commenting on this PR :confused:

> Maybe `CC=clang -target arm64-apple-macos11` may help? I tried that but some build systems have special options. For example, we also link against `libbacktrace` and that wants you to set...

Check out [this PR](https://github.com/bloomberg/memray/pull/202) for reference.

A bit precarious, but we can use something akin to this to fix it: ```diff diff --git a/src/memray/_memray.pyx b/src/memray/_memray.pyx index b739153..f87c5a5 100644 --- a/src/memray/_memray.pyx +++ b/src/memray/_memray.pyx @@ -214,11 +214,18 @@...

Then there is no way to detect this problem in those cases. This means that we need to either won't fix it skip the test in the absence of symbols.

This is another possibility: ```diff diff --git a/src/memray/_memray/tracking_api.cpp b/src/memray/_memray/tracking_api.cpp index 72a1059..6777798 100644 --- a/src/memray/_memray/tracking_api.cpp +++ b/src/memray/_memray/tracking_api.cpp @@ -469,6 +469,13 @@ PythonStackTracker::recordAllStacks() s_tracker_generation++; } +PyObject* +PyEvalFrame_Memray(PyThreadState* ts, _PyInterpreterFrame* f, int val)...

> It does mean sacrificing some optimizations, though Yeah, I honestly prefer to sacrifice correctness here unless we leverage the eval function in its entirety. If we are going to...

The reason why we are abandoning the idea of the custom eval function: https://github.com/bloomberg/memray/pull/213#issuecomment-1259815614

> Is this something that needs to be worked on (if so, I'd like to!), or is it just a case of a pull request waiting to be merged? Someone...

Thanks for checking with me! 👍 One thing that would help me evaluate the risk better is if you could walk me through what improvements or bugfixes are important to...