sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<sb0>
whitequark, so any function that takes more than one type for any given argument has to be a builtin?
<whitequark>
no no, as long as *args and **kwargs are not used, types may vary arbitrarily
<whitequark>
in RPCs that is
<sb0>
so why is there any problem with the RTIO log function? it's not a RPC
<whitequark>
it accepts a varying amount of arguments
<whitequark>
these have to be builtins.
<sb0>
oh, no, make it just one
<whitequark>
huh? why?
<sb0>
rtio_log(key, value)
<sb0>
that's all
<whitequark>
well the idea was that there would be no record separation / newline
<sb0>
key is a string, value is formatted
<sb0>
the purpose of this is to show values in VCDs
<whitequark>
ah ok. anyway it still has to be a builtin because it's a function that examines the types of its arguments
<sb0>
on a waveform plot
<sb0>
the value is short and fits on a single line
<whitequark>
and normal ARTIQ functions (non RPCs) can't do that, they just accept one alway
<whitequark>
ss
<sb0>
why does the compiler need to know if the target RPC function uses *args/**kwargs?
<whitequark>
because the typechecker does not have a concept of a variadic function
<sb0>
shouldn't unpacking arguments be the problem of cpython?
<whitequark>
the typechecker currently does not treat RPCs any differently than regular functions
<sb0>
yes but foo(x, y) works, but foo(*args): x, y = args doesn't
<whitequark>
and regular functions do not have *args or **args because it makes no sense
<sb0>
even though this difference happens entirely outside of the compiler
<whitequark>
you can't actually *do* anything with these args inside ARTIQ Python
<whitequark>
well, anything that you couldn't already do by listing the arguments one by one
<sb0>
foo is on the host in my example
<whitequark>
>the typechecker currently does not treat RPCs any differently than regular functions
<whitequark>
there is nothing that would prevent *args from being handled in principle, it's just a nontrivial amount of work
<whitequark>
quite possibly it would make sense to treat RPCs specially instead
<whitequark>
which is I think less work, but still needs to be done.
<sb0>
so right now when you have a RPC, you use getargspec to look at how many arguments it takes on the host?
<sb0>
I don't understand what problem this information solves ...
<whitequark>
yes
<whitequark>
it doesn't
<whitequark>
I basically implemented that by inertia
<whitequark>
sb0: so, what about the rtio_log function? OK to make it a builtin?
<sb0>
yes
<sb0>
there is no problem with having the builtin be rtio_log(timestamp, channel, value) and then a wrapper in artiq-python that does user_rtio_log(channel, value): rtio_log(now_mu(), channel, value), right?
<sb0>
mh. there are still tons of coredevice unittests failing ... :(
<whitequark>
no, there will of course be a problem, because the `value` argument in the wrapper would only have one type
<sb0>
so how will you pass now_mu() ?
<whitequark>
no problem with rtio_log having builtin knowledge of now
<whitequark>
since now is just a global...
<GitHub46>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vEKVI
<GitHub46>
artiq/master bea1182 Sebastien Bourdeauducq: sim/devices/core: adapt to _ARTIQEmbeddedInfo
<GitHub58>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vEKVc