Hello, On 11/25/2014 11:58 AM, Robert Jördens wrote: > * JSON/PYON: As mentioned on IRC, you could still have used JSON > with a bit of type annotation. The other arguments against JSON > appear to only count if you want to build a fully bijective python > data (de)serializer wich may not be needed. The reason why valid JSON > would be very valuable is its interoperability with other pieces of > software
In addition to a lack of support for custom classes, there are lots of corner cases with JSON which are potential stumbling blocks when writing or using controllers: dictionary keys are turned into strings, tuples into lists, etc. That would make RPC far from transparent. To clean up all those special cases, and support custom classes, the required amount of annotation/encapsulation is substantial and makes the wire protocol ugly and the transform code about as complex as writing a new parser (how to handle a Numpy array which is an element of a tuple which is a value of a dictionary keyed by integer tuples?). On the other hand, PYON is quite straightforward and writing a parser in those languages that have flex/bison-like tools should not be a big deal - it's more or less the same level of complexity as the "calculator" example that comes with many beginner tutorials for such tools. I can provide a grammar definition file if that helps. > * Object attribute writeback: I see why that is idiomatic and fits > native Python behaviour. But it sounds expensive if done > indiscriminately. Assume you want to generate or process data on the > coredevice and want to keep that data not in local variables but > organize them in some namespace, e.g. as attributes. Would it be > easy to mark attributes for exclusion from writeback? The inline transform turns all kernels into one big function and does the writeback only once at the end (not everytime an attribute is written - they reside as local variables in the meantime), so the overhead should be small. Otherwise, yes, it would be quite straightforward to add writeback exclusion support. What is more concerning are the consequences of turning everything into one big function - doing so enables the interleave transform to work properly across functions and permits certain optimizations, but it restricts the use of "return" (as it cannot branch to the calling function anymore) and may increase code size. > * Keyword argument support: I presume that arguments lists and dicts > (*args and **kwargs) are not supported. That is OK by me. Probably > very few usecases for it. Indeed, dynamic arguments (and lists and dictionaries) are not supported, except in the easy case of calling a kernel from the interpreter. Sébastien _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
