Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better software architecture? #27

Closed
yczhang89 opened this issue Jan 21, 2017 · 7 comments
Closed

Better software architecture? #27

yczhang89 opened this issue Jan 21, 2017 · 7 comments
Labels
stale stale issues and PRs

Comments

@yczhang89
Copy link

yczhang89 commented Jan 21, 2017

Maybe taichi could be split into several modules:

  1. (Module A) C++ graphics rendering engine: Given a 3D scene in a standard data format (e.g. the one in taichi/blender/exporter/__init__.py), the engine calculates a rasterised image. This rendering engine could be used interchangeably with other rendering engines.

  2. (Module B) Python library to procedurally generate a 3D scene. The output is given in a standard data format, and can be fed into any graphics rendering engine.

  3. (Module B) C++ physics simulation: given some parameters, calculates a series of scenes. This part could be integrated into Module B: this can be seen as a specific way to generate 3D scenes.

  4. (Module C) A seperate Python library to handle realtime preview and program hot reloading, for any Python program that generates a series of images. We don't need to have lovecat integrated into Module C.

  5. (Module D) A set of demos that is built upon Module B, Module C and lovecat. Binary asset files could go into Module D.

@yuanming-hu
Copy link
Member

Hi Yucheng,

Thanks for your input and I feel sorry for the delayed reply. Not until recently do I get time to consider and do related engineering regarding general architecture.

The thing I worry about is that interchanging data as files onto disks may be much slower than doing so within RAM. I am not sure the ''standard'' data format for 3D scenes actually exists, and making exporter for each rendering engine can be troublesome.

Taichi can have its own format for 3D scenes. As the outer layer is wrapped with Python, it would be best to utilize some existing ways like pickle. I'm still considering if we also need a C++ wrapper. If so, we may not be able to use pickle, but another way to serialize/deserialize our data. I believe serialization would be necessary sooner or later, as when doing a simulation it is common that people want to stop halfway and restore the state afterward.

For the real-time previewer, currently I'm working on Pakua, a WebGL based visualization engine based on Three.js. Doing so removes the dependency on a game engine like Unity or Unreal and keeps installation of Taichi simple.

Regarding lovecat, I think it would be most useful for procedural generation, since much parameter tuning will be needed. Also, such generation can provide relatively fast feedback. (In contrast, rendering and simulation can be quite slow.)

@voronoipotato
Copy link

STL is a good format for geometry if you are going to make an export.

@yczhang89
Copy link
Author

Sorry for the delayed reply.

The thing I worry about is that interchanging data as files onto disks may be much slower than doing so within RAM.

Adopting a standard data format doesn't imply that the data has to be written to a disk. You could still use RAM for data exchange. You may want to consider a RESTful API over network.

I believe serialization would be necessary sooner or later, as when doing a simulation it is common that people want to stop halfway and restore the state afterward.

Just a side note, what you need is actually serializing a continuation.

Regarding lovecat, I think it would be most useful for procedural generation, since much parameter tuning will be needed. Also, such generation can provide relatively fast feedback. (In contrast, rendering and simulation can be quite slow.)

lovecat is an alternative to the traditional node-graph approach, both of which has advantages and disadvantages. lovecat may serve your use case (producing a small demo for your new algorithm) better.

As for the realtime feedback, lovecat should have the same performance characteristics with node-graph. Note that caching intermediate results is also possible with lovecat.

However, unfortunately I currently don't have time for a Python-based lovecat.

@yuanming-hu yuanming-hu reopened this Mar 1, 2018
@jawaff
Copy link

jawaff commented Jan 29, 2020

@yuanming-hu Hey, I saw that you mentioned Unity and Unreal. Do you know if there are any plugins that make this work with the Unreal Engine?

@yuanming-hu
Copy link
Member

Hi @jawaff, the answer is no, for now...

@jawaff
Copy link

jawaff commented Jan 30, 2020 via email

@github-actions
Copy link

Warning: The issue has been out-of-update for 50 days, marking stale.

@github-actions github-actions bot added the stale stale issues and PRs label May 22, 2020
feisuzhu added a commit that referenced this issue Jan 12, 2023
Related Issue: #7140 

### Brief Summary

On macOS, when test worker hard fails (abort, EXC_BAD_ACCESS, etc.),
backward_cpp's signal handler will re-raise the signal and catch it
afterwards, make it an infinite loop, at the moment the offending
process can't be terminated easily (except a SIGKILL), eat CPU cycles
and blocks test runner.

```
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00000001a04f0e28 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #2: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #3: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #4: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #5: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #6: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #7: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #8: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #9: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #10: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #11: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #12: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #13: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #14: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #15: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #16: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #17: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #18: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #19: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #20: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #21: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #22: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #23: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #24: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #25: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #26: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #27: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #28: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #29: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #30: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #31: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #32: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #33: 0x00000001a046b454 libsystem_c.dylib`abort + 124
    frame #34: 0x0000000100194fc0 python`os_abort + 12
    frame #35: 0x00000001000758a8 python`cfunction_vectorcall_NOARGS + 324
    frame #36: 0x00000001001140f0 python`call_function + 460
    frame #37: 0x000000010011086c python`_PyEval_EvalFrameDefault + 27176
    frame #38: 0x00000001000287e4 python`function_code_fastcall + 128
    frame #39: 0x0000000100028008 python`PyVectorcall_Call + 120
    frame #40: 0x0000000100110b20 python`_PyEval_EvalFrameDefault + 27868
    frame #41: 0x000000010010982c python`_PyEval_EvalCodeWithName + 3008
    frame #42: 0x0000000100028948 python`_PyFunction_Vectorcall + 208
    frame #43: 0x0000000100028008 python`PyVectorcall_Call + 120
```
lin-hitonami pushed a commit that referenced this issue Jan 12, 2023
Related Issue: #7140 

### Brief Summary

On macOS, when test worker hard fails (abort, EXC_BAD_ACCESS, etc.),
backward_cpp's signal handler will re-raise the signal and catch it
afterwards, make it an infinite loop, at the moment the offending
process can't be terminated easily (except a SIGKILL), eat CPU cycles
and blocks test runner.

```
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00000001a04f0e28 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #2: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #3: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #4: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #5: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #6: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #7: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #8: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #9: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #10: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #11: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #12: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #13: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #14: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #15: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #16: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #17: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #18: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #19: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #20: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #21: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #22: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #23: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #24: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #25: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #26: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #27: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #28: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #29: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #30: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #31: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #32: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #33: 0x00000001a046b454 libsystem_c.dylib`abort + 124
    frame #34: 0x0000000100194fc0 python`os_abort + 12
    frame #35: 0x00000001000758a8 python`cfunction_vectorcall_NOARGS + 324
    frame #36: 0x00000001001140f0 python`call_function + 460
    frame #37: 0x000000010011086c python`_PyEval_EvalFrameDefault + 27176
    frame #38: 0x00000001000287e4 python`function_code_fastcall + 128
    frame #39: 0x0000000100028008 python`PyVectorcall_Call + 120
    frame #40: 0x0000000100110b20 python`_PyEval_EvalFrameDefault + 27868
    frame #41: 0x000000010010982c python`_PyEval_EvalCodeWithName + 3008
    frame #42: 0x0000000100028948 python`_PyFunction_Vectorcall + 208
    frame #43: 0x0000000100028008 python`PyVectorcall_Call + 120
```
lin-hitonami pushed a commit that referenced this issue Jan 12, 2023
Related Issue: #7140 

### Brief Summary

On macOS, when test worker hard fails (abort, EXC_BAD_ACCESS, etc.),
backward_cpp's signal handler will re-raise the signal and catch it
afterwards, make it an infinite loop, at the moment the offending
process can't be terminated easily (except a SIGKILL), eat CPU cycles
and blocks test runner.

```
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00000001a04f0e28 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #2: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #3: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #4: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #5: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #6: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #7: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #8: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #9: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #10: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #11: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #12: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #13: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #14: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #15: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #16: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #17: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #18: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #19: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #20: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #21: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #22: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #23: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #24: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #25: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #26: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #27: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #28: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #29: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #30: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #31: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #32: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #33: 0x00000001a046b454 libsystem_c.dylib`abort + 124
    frame #34: 0x0000000100194fc0 python`os_abort + 12
    frame #35: 0x00000001000758a8 python`cfunction_vectorcall_NOARGS + 324
    frame #36: 0x00000001001140f0 python`call_function + 460
    frame #37: 0x000000010011086c python`_PyEval_EvalFrameDefault + 27176
    frame #38: 0x00000001000287e4 python`function_code_fastcall + 128
    frame #39: 0x0000000100028008 python`PyVectorcall_Call + 120
    frame #40: 0x0000000100110b20 python`_PyEval_EvalFrameDefault + 27868
    frame #41: 0x000000010010982c python`_PyEval_EvalCodeWithName + 3008
    frame #42: 0x0000000100028948 python`_PyFunction_Vectorcall + 208
    frame #43: 0x0000000100028008 python`PyVectorcall_Call + 120
```
lin-hitonami pushed a commit that referenced this issue Jan 12, 2023
Related Issue: #7140 

### Brief Summary

On macOS, when test worker hard fails (abort, EXC_BAD_ACCESS, etc.),
backward_cpp's signal handler will re-raise the signal and catch it
afterwards, make it an infinite loop, at the moment the offending
process can't be terminated easily (except a SIGKILL), eat CPU cycles
and blocks test runner.

```
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00000001a04f0e28 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #2: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #3: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #4: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #5: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #6: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #7: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #8: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #9: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #10: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #11: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #12: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #13: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #14: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #15: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #16: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #17: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #18: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #19: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #20: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #21: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #22: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #23: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #24: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #25: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #26: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #27: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame #28: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #29: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #30: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame #31: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame #32: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame #33: 0x00000001a046b454 libsystem_c.dylib`abort + 124
    frame #34: 0x0000000100194fc0 python`os_abort + 12
    frame #35: 0x00000001000758a8 python`cfunction_vectorcall_NOARGS + 324
    frame #36: 0x00000001001140f0 python`call_function + 460
    frame #37: 0x000000010011086c python`_PyEval_EvalFrameDefault + 27176
    frame #38: 0x00000001000287e4 python`function_code_fastcall + 128
    frame #39: 0x0000000100028008 python`PyVectorcall_Call + 120
    frame #40: 0x0000000100110b20 python`_PyEval_EvalFrameDefault + 27868
    frame #41: 0x000000010010982c python`_PyEval_EvalCodeWithName + 3008
    frame #42: 0x0000000100028948 python`_PyFunction_Vectorcall + 208
    frame #43: 0x0000000100028008 python`PyVectorcall_Call + 120
```
quadpixels pushed a commit to quadpixels/taichi that referenced this issue May 13, 2023
Related Issue: taichi-dev#7140 

### Brief Summary

On macOS, when test worker hard fails (abort, EXC_BAD_ACCESS, etc.),
backward_cpp's signal handler will re-raise the signal and catch it
afterwards, make it an infinite loop, at the moment the offending
process can't be terminated easily (except a SIGKILL), eat CPU cycles
and blocks test runner.

```
(lldb) bt
* thread taichi-dev#1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00000001a04f0e28 libsystem_kernel.dylib`__pthread_kill + 8
    frame taichi-dev#1: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame taichi-dev#2: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame taichi-dev#3: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame taichi-dev#4: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame taichi-dev#5: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame taichi-dev#6: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame taichi-dev#7: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame taichi-dev#8: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame taichi-dev#9: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame taichi-dev#10: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame taichi-dev#11: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame taichi-dev#12: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame taichi-dev#13: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame taichi-dev#14: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame taichi-dev#15: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame taichi-dev#16: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame taichi-dev#17: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame taichi-dev#18: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame taichi-dev#19: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame taichi-dev#20: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame taichi-dev#21: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame taichi-dev#22: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame taichi-dev#23: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame taichi-dev#24: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame taichi-dev#25: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame taichi-dev#26: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame taichi-dev#27: 0x00000001283a0848 taichi_python.cpython-38-darwin.so`backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 28
    frame taichi-dev#28: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame taichi-dev#29: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame taichi-dev#30: 0x00000001a0402e10 libsystem_c.dylib`raise + 32
    frame taichi-dev#31: 0x00000001a056ec44 libsystem_platform.dylib`_sigtramp + 56
    frame taichi-dev#32: 0x00000001a052343c libsystem_pthread.dylib`pthread_kill + 292
    frame taichi-dev#33: 0x00000001a046b454 libsystem_c.dylib`abort + 124
    frame taichi-dev#34: 0x0000000100194fc0 python`os_abort + 12
    frame taichi-dev#35: 0x00000001000758a8 python`cfunction_vectorcall_NOARGS + 324
    frame taichi-dev#36: 0x00000001001140f0 python`call_function + 460
    frame taichi-dev#37: 0x000000010011086c python`_PyEval_EvalFrameDefault + 27176
    frame taichi-dev#38: 0x00000001000287e4 python`function_code_fastcall + 128
    frame taichi-dev#39: 0x0000000100028008 python`PyVectorcall_Call + 120
    frame taichi-dev#40: 0x0000000100110b20 python`_PyEval_EvalFrameDefault + 27868
    frame taichi-dev#41: 0x000000010010982c python`_PyEval_EvalCodeWithName + 3008
    frame taichi-dev#42: 0x0000000100028948 python`_PyFunction_Vectorcall + 208
    frame taichi-dev#43: 0x0000000100028008 python`PyVectorcall_Call + 120
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale stale issues and PRs
Projects
None yet
Development

No branches or pull requests

4 participants