context manager plugin API in nac3core #23

New Issue

sb10q · 2021-09-24T12:44:05+08:00

sb10q commented

2021-09-24 12:44:05 +08:00

So nac3embedded can implement with parallel/with sequential.

So nac3embedded can implement ``with parallel``/``with sequential``.

pca006132 was assigned by sb10q

2021-09-24 12:44:05 +08:00

sb10q added the

high-priority

label 2021-09-24 12:47:25 +08:00

pca006132 commented

2021-10-03 23:11:36 +08:00

What should we pass to __exit__()? PEP343 requires the signature of the exit function to be __exit__(self, type, value, traceback), i.e. exception type, exception value, traceback. We probably won't have these...?

What should we pass to `__exit__()`? PEP343 requires the signature of the exit function to be `__exit__(self, type, value, traceback)`, i.e. exception type, exception value, traceback. We probably won't have these...?

sb10q commented

2021-10-03 23:43:52 +08:00

I don't think this is relevant for the special context managers at hand - they would be AST transforms, implemented in Rust, and not behave like regular Python context managers.

Supporting user-defined context managers in kernels is another issue and a very low-priority one.

I don't think this is relevant for the special context managers at hand - they would be AST transforms, implemented in Rust, and not behave like regular Python context managers. Supporting user-defined context managers in kernels is another issue and a very low-priority one.

pca006132 commented

2021-10-04 00:53:31 +08:00

I don't think this is relevant for the special context managers at hand - they would be AST transforms, implemented in Rust, and not behave like regular Python context managers.
Alternatively perhaps we can just traverse the AST in nac3artiq and transform it there?

Supporting user-defined context managers in kernels is another issue and a very low-priority one.

OK, so the context manager API you mentioned is for AST transform but not for the actual python one right? Why not implement it at the application level? The transform would be mostly application code instead of the core compiler code anyway.

> I don't think this is relevant for the special context managers at hand - they would be AST transforms, implemented in Rust, and not behave like regular Python context managers. > Alternatively perhaps we can just traverse the AST in ``nac3artiq`` and transform it there? > > Supporting user-defined context managers in kernels is another issue and a very low-priority one. OK, so the context manager API you mentioned is for AST transform but not for the actual python one right? Why not implement it at the application level? The transform would be mostly application code instead of the core compiler code anyway.

sb10q commented

2021-10-06 16:52:42 +08:00

Could codegen become a trait? Then the application would have a lot of flexibility to intercept those special context manager AST nodes and emit corresponding LLVM IR.

Doing a pure AST transform is a pain for the reasons explained in https://github.com/m-labs/artiq/issues/1555#issuecomment-922652441

Could codegen become a trait? Then the application would have a lot of flexibility to intercept those special context manager AST nodes and emit corresponding LLVM IR. Doing a pure AST transform is a pain for the reasons explained in https://github.com/m-labs/artiq/issues/1555#issuecomment-922652441

pca006132 referenced this issue from a commit

2021-10-16 22:18:29 +08:00

nac3core/codegen: refactor according to #23

sb10q referenced this issue

2021-10-21 10:44:55 +08:00

implement with parallel/with sequential #62

sb10q commented

2021-11-05 18:12:57 +08:00

done

sb10q closed this issue

2021-11-05 18:12:58 +08:00

Sign in to join this conversation.