ychenfo pushed to default_parameter at M-Labs/nac3
- 59bdb1be50 nac3core: change default parameter integer out of range err msg
ychenfo pushed to default_parameter at M-Labs/nac3
- 6397e42e74 default paramter support simple global modules
ychenfo deleted branch range_with_class from M-Labs/nac3
ychenfo pushed to polymorphism_fixes at M-Labs/nac3
- 01b51b62ee nac3core: composer better error msg in for uninit field
- aae9925014 nac3standalone: report when entry point run function cannot be found
- d336200bf4 nac3core: fix broken tests due to the fix of rigid typevar handling
- a50df6560e nac3core: fix handling on rigid typevar
- a9635f0979 nac3core: top level use codegen official get_subst_key
- Compare 6 commits »
ychenfo commented on pull request M-Labs/nac3#98
Constant Default Parameter SupportSorry, still one thing not very clear about this... To handle complex expressions(calling `eval` for now? Also, expressions like `Module.T` which refers to things defined in another module…
ychenfo pushed to symbol_resolver_typevar at M-Labs/nac3
- 1c5e68aca9 nac3artiq/nac3core: remove forwardref type annotation support for unstable python API
ychenfo pushed to default_parameter at M-Labs/nac3
- e75ec35687 nac3ore: default parameter of type int64 should be specified explicitly
- 6b059fa288 nac3core: default parameter fix typo and error handling
- c7b6b048fb nac3core: default constant parameter support
- 599aeb7bb3 nac3ore: default parameter of type int64 should be specified explicitly
- 439cef636f runkernel: improve print_int debug functions
- Compare 8 commits »
ychenfo commented on pull request M-Labs/nac3#98
Constant Default Parameter SupportOk I will add module globals support on top of the current constant support
ychenfo commented on pull request M-Labs/nac3#98
Constant Default Parameter SupportI think here we are handling default parameters in nac3core so we do not really know the `id(numpy.int64)`? In type inference module we also do things using strings matches…
ychenfo commented on pull request M-Labs/nac3#99
TypeVar and virtual support in Symbol Resolver> Can we just remove anything that has to do with ``ForwardRef`` for now, and deal with the forward type annotation situation later? https://git.m-labs.hk/M-Labs/nac3/issues/73 Ok, I will do that…
ychenfo commented on pull request M-Labs/nac3#95
AugAssignment & Default Parameter Support, and Polymorphism FIxes> Should we close this PR? Yes, this PR can be closed. > @ychenfo can you keep breaking down the remaining changes into separate PRs, and then delete the ``range_with_class`` branch? Sure,…
ychenfo commented on pull request M-Labs/nac3#99
TypeVar and virtual support in Symbol Resolver> Regarding `_eval_type`: > 1. It is a private API which may be changed across Python versions. Are there alternatives to this? Yes I also have some conern about this when writing the code. I…
ychenfo pushed to symbol_resolver_typevar at M-Labs/nac3
- dab06bdb58 nac3core: parse type annotation python forwardref handling
- 66a9eda3c1 nac3standalone: fix resolver typevar err msg
- e8a5843ca7 nac3standalone: basic resolver typevar handling
- eb1f353acd nac3artiq: remove unnecessary python print from helper
- 9406a645c7 nac3artiq: avoid using py.eval to get id of class virtual
- Compare 14 commits »
ychenfo commented on pull request M-Labs/nac3#98
Constant Default Parameter Support> LGTM, but we should probably add tests to nac3artiq/nac3standalone later. Yes, some demo python files related to this will be added later.
ychenfo commented on pull request M-Labs/nac3#98
Constant Default Parameter Supportthis is handled in the new commit below
ychenfo pushed to default_parameter at M-Labs/nac3
- 599aeb7bb3 nac3ore: default parameter of type int64 should be specified explicitly
ychenfo created pull request M-Labs/nac3#100
nac3artiq: support now-pinning on RISC-V with wide data bus (#97)ychenfo pushed to now_pinning_time_64 at M-Labs/nac3
- 1e47b364c5 nac3artiq: support now-pinning on RISC-V with wide data bus (#97)