artiq
artiq copied to clipboard
Data type confusion for ARTIQ Python
Do parts of the ARTIQ codebase override or clear default Python types? For the most part I have been able to get around these issues, but now it has become a hassle. For instance, I am unable to use default Python arrays, dictionaries, and even some casting methods such as str
. For example, when casting an integer into a string: fatal: name 'str' is not bound to anything
Issues like this occur when even creating dictionaries: fatal: name 'dict' is not bound to anything; did you mean 'int'?
Finally, it seems that even Python arrays don't usually work in my environment: when setting a variable my_array = []
, I am told that this object does not have functions such as append
, pop
, or push
. I was just wondering if these types are overridden by one of the classes or packages in artiq.experiment
. When testing in the Python interpreter, these methods still work even after importing artiq.experiment
, so does is this a side effect of using the @kernel
decoration?
You can think of the ARTIQ Python compiler to override all built-in types.
The ARTIQ Python language is a subset of Python proper for several good reasons.
First, the experiments must run in realtime. This all but excludes most data structures relying on heap allocation and reallocation, like dicts and extensible arrays, since ARTIQ Python has no heap. (Implementing a decent real-time garbage collector is an extremely complicated affair and the payoff for experiments isn't that big.)
Second, the experiments must not have runtime dispatch. This means that, for example, all elements of array must be the same type, and all instances of a class must contain an object of the same type in a given field.
That said, some things are missing simply because they haven't been implemented. Many operations (e.g. string concatenation) would be easy to implement. Others (e.g. string indexing) are unlikely to ever be added.
For your specific issues, I recommend:
- Instead of dicts, you can use distinct classes.
- Instead of performing string operations in the kernel, you can collect the data in the kernel, perhaps in tuples, and format them in the host Python code afterwards.
- Instead of pushing into an array, pre-allocate the array for the maximum number of elements you expect with a list comprehension, i.e.
x = [0 for _ in range(1024)]
, and then keep a variable noting the last filled element of an array. Afterwards,x[0:n]
will give you a list with that number of elements.
Some of the tricks you have mentioned work great. I notice that tuples have no accessors on them (for instance, my_tuple[0]
will throw an exception type is not iterable
). Is this due to the fact that experiments must not have a runtime dispatch, and tuples are capable of holding values of different types?
Also, I believe that warnings to the developers during compilation (i.e. Note that append on the array type (line ###) is not supported within kernels!
) would be extremely helpful.
Is this due to the fact that experiments must not have a runtime dispatch, and tuples are capable of holding values of different types?
Absolutely correct. You can deconstruct tuples with a, b, c = tup
.
Also, I believe that warnings to the developers during compilation (i.e. Note that append on the array type (line ###) is not supported within kernels!) would be extremely helpful.
I don't understand what do you mean by this. Trying to use the append method in kernels already results in errors. Do you also want a warning in the host Python code?
The error's context (being a @kernel
and ARTIQPython being different from regular Python) is not always obvious for beginners.
@whitequark sorry, this is true that the errors are quite clear of the problem. As @jordens said, as a beginner such as myself where ARTIQ is my first endeavor in using FPGA systems, it was not immediately clear that the host Python code is compiled into a different type of Python code. From the documentation it is clear that there is a conversion happening, but I had no idea that the compiled code would have a subset of the original Python features (I originally assumed that the conversion was more on the 'optimization' side of things) . I think what would be helpful to developers is a few quick examples of unsupported operations in this section of the manual (regarding things such as lists, and possibly even presenting the idea of pre allocated arrays using list comprehensions; this part was confusing considering the supported section includes 'lists of any supported types'). It might even be useful to put a quick note at the beginning of the Getting started with the code language section, something simple such as "Please note the limitiations of some Python operations imposed by ARTIQ's compiler.
I agree. This would be helpful. The examples that Aaron brings up and accompanying narrative on this Issue would be a good starting point. :) -Joe
Joe Britton Sensors and Electron Devices Army Research Lab 2800 Powder Mill Rd Adelphi, MD 20783 301-394-3130 [email protected]
On Wed, Jan 18, 2017 at 6:46 PM, Aaron Vontell [email protected] wrote:
@whitequark https://github.com/whitequark sorry, this is true that the errors are quite clear of the problem. As @jordens https://github.com/jordens said, as a beginner such as myself where ARTIQ is my first endeavor in using FPGA systems, it was not immediately clear that the host Python code is compiled into a different type of Python code. From the documentation it is clear that there is a conversion happening, but I had no idea that the compiled code would have a subset of the original Python features (I originally assumed that the conversion was more on the 'optimization' side of things) . I think what would be helpful to developers is a few quick examples of unsupported operations in this section of the manual https://m-labs.hk/artiq/manual-release-2/compiler.html#pitfalls (regarding things such as lists, and possibly even presenting the idea of pre allocated arrays using list comprehensions; this part was confusing considering the supported section includes 'lists of any supported types'). It might even be useful to put a quick note at the beginning of the Getting started with the code language https://m-labs.hk/artiq/manual-release-2/getting_started_core.html#getting-started-with-the-core-language section, something simple such as "Please note the limitiations of some Python operations imposed by ARTIQ's compiler https://m-labs.hk/artiq/manual-release-2/compiler.html.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/m-labs/artiq/issues/656#issuecomment-273638605, or mute the thread https://github.com/notifications/unsubscribe-auth/ATl51pHp0Od8AIeQ-b7wi9wIW13TMeD7ks5rTqRpgaJpZM4Lk5j8 .