M-Labs/nac3
M-Labs
/
nac3
8
0
Fork 10
Code Issues 99 Pull Requests 21 Releases Wiki Activity

define parallel/sequential in nac3artiq Rust side #74

New Issue
Open
opened 2021-11-05 18:09:47 +08:00 by sb10q · 13 comments
sb10q commented 2021-11-05 18:09:47 +08:00
Owner
Copy Link

Make it clear that they are special. Same as now_mu, at_mu, delay_mu

Make it clear that they are special. Same as now_mu, at_mu, delay_mu
pca006132 was assigned by sb10q 2021-11-05 18:09:48 +08:00
hartytp commented 2021-11-06 17:04:19 +08:00
Collaborator
Copy Link

What's your view on supporting things like import artiq as aq, with aq.parallel aq.delay_mu. This is the style we're moving towards here. In the current compiler, aq.delay gives an obscure error message about missing time managers.

What's your view on supporting things like `import artiq as aq`, `with aq.parallel` `aq.delay_mu`. This is the style we're moving towards here. In the current compiler, `aq.delay` gives an obscure error message about missing time managers.
sb10q commented 2021-11-06 17:12:37 +08:00
Author
Owner
Copy Link

Doesn't seem to be worth the extra complexity in the compiler. aq.delay (or anything other than plain delay) would not be supported at all.

Doesn't seem to be worth the extra complexity in the compiler. ``aq.delay`` (or anything other than plain ``delay``) would not be supported at all.
pca006132 commented 2021-11-06 19:05:48 +08:00
Contributor
Copy Link

What's your view on supporting things like import artiq as aq, with aq.parallel aq.delay_mu. This is the style we're moving towards here. In the current compiler, aq.delay gives an obscure error message about missing time managers.

Actually this is #40.

> What's your view on supporting things like `import artiq as aq`, `with aq.parallel` `aq.delay_mu`. This is the style we're moving towards here. In the current compiler, `aq.delay` gives an obscure error message about missing time managers. Actually this is #40.
pca006132 commented 2021-11-06 23:17:45 +08:00
Contributor
Copy Link

What's your view on supporting things like import artiq as aq, with aq.parallel aq.delay_mu. This is the style we're moving towards here. In the current compiler, aq.delay gives an obscure error message about missing time managers.

FYI: I plan to support this together with #54 (as I have to do some refactoring, which can also support module type with little effort)

> What's your view on supporting things like `import artiq as aq`, `with aq.parallel` `aq.delay_mu`. This is the style we're moving towards here. In the current compiler, `aq.delay` gives an obscure error message about missing time managers. FYI: I plan to support this together with #54 (as I have to do some refactoring, which can also support module type with little effort)
hartytp commented 2021-11-06 23:20:58 +08:00
Collaborator
Copy Link

Cool! It's not a huge deal, but would make some things cleaner. The situation with the old compiler is a bit annoying because the error message is so bad.

Cool! It's not a huge deal, but would make some things cleaner. The situation with the old compiler is a bit annoying because the error message is so bad.
sb10q commented 2021-11-06 23:23:04 +08:00
Author
Owner
Copy Link

So you'd define e.g. delay_mu and parallel in a Python module? How will the compiler know that it's the special ones?

So you'd define e.g. ``delay_mu`` and ``parallel`` in a Python module? How will the compiler know that it's the special ones?
pca006132 commented 2021-11-06 23:24:23 +08:00
Contributor
Copy Link

So you'd define e.g. delay_mu and parallel in a Python module? How will the compiler know that it's the special ones?

Just get the Python object ID and compare them. In general we should use SymbolResolver to check for it.

> So you'd define e.g. ``delay_mu`` and ``parallel`` in a Python module? How will the compiler know that it's the special ones? Just get the Python object ID and compare them. In general we should use `SymbolResolver` to check for it.
sb10q commented 2021-11-06 23:24:50 +08:00
Author
Owner
Copy Link

How do you know the object IDs of the special ones?

How do you know the object IDs of the special ones?
sb10q commented 2021-11-06 23:25:58 +08:00
Author
Owner
Copy Link

Call things like NAC3.register_parallel(parallel) from Python?

Call things like ``NAC3.register_parallel(parallel)`` from Python?
pca006132 commented 2021-11-06 23:26:03 +08:00
Contributor
Copy Link

How do you know the object IDs of the special ones?

016cbf2b90/nac3artiq/src/lib.rs (L250-L286)

> How do you know the object IDs of the special ones? https://git.m-labs.hk/M-Labs/nac3/src/commit/016cbf2b9028c554c67da01238156ce2e7c682ff/nac3artiq/src/lib.rs#L250-L286
sb10q commented 2021-11-06 23:28:25 +08:00
Author
Owner
Copy Link

But those would always be present in the global namespace, and are not confined to a module.

But those would always be present in the global namespace, and are not confined to a module.
pca006132 commented 2021-11-06 23:31:22 +08:00
Contributor
Copy Link

But those would always be present in the global namespace, and are not confined to a module.

You can import it, or call register_xxx(xxx) in python, ignore the ID and check for the existance of a special field in the object, etc. This is just an implementation detail, I don't think it is hard to do.

I would say the simplest way might be to just register the entire module and get whatever we want without implementing a register function for every special construct we have.

> But those would always be present in the global namespace, and are not confined to a module. You can import it, or call `register_xxx(xxx)` in python, ignore the ID and check for the existance of a special field in the object, etc. This is just an implementation detail, I don't think it is hard to do. I would say the simplest way might be to just register the entire module and get whatever we want without implementing a register function for every special construct we have.
sb10q commented 2021-11-06 23:35:03 +08:00
Author
Owner
Copy Link

If we do implement this, register_special(name, id) and ID comparison sounds fine to me. We can probably also have decorators that make it consistent with the way @extern works currently.

If we do implement this, ``register_special(name, id)`` and ID comparison sounds fine to me. We can probably also have decorators that make it consistent with the way ``@extern`` works currently.
pca006132 was unassigned by sb10q 2021-12-21 18:47:55 +08:00
ychenfo was assigned by sb10q 2021-12-21 18:47:59 +08:00
ychenfo was unassigned by sb10q 2024-11-16 19:10:27 +08:00
occheung was assigned by sb10q 2024-11-16 19:10:33 +08:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
misc/impl-tracert
ndstrides-neo-next
ndstrides-14-end
ndstrides-13-tests
ndstrides-12-builtins
ndstrides-11-matmul
ndstrides-10-ops
ndstrides-9-subassign
ndstrides-8-transpose
ndstrides-7-broadcasting
ndstrides-6-reshape
ndstrides-5-miscfuncs
ndstrides-4-nparray
ndstrides-3-indexing
ndstrides-2-basic
ndstrides-1-model
ndstrides
refactor_composer
misc/update-pyo3
misc/mold
ndstrides-1-model-lifetime
ndstrides-enhance-irrt
ndstrides-intro
issue-313
refactor-primstore
numpy-anyall
enhance/cargo-test-standalone-demos
issue-136
rpc-obj-as-param
iterators
escape-analysis
refactor_anto
Labels
Clear labels   
future-extension

   
high-priority

   
low-priority

   
UROP0622
No Label
future-extension
high-priority
low-priority
UROP0622
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
occheung
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/nac3#74
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?