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
<GitHub58> artiq/master e4791ad Sebastien Bourdeauducq: examples/sim/al_spectroscopy: replace FreeValue
<sb0> whitequark, are all user exceptions turned into artiq.language.core.ARTIQException?
<whitequark> no, if there's a descendant of ARTIQException with the proper name, that one is raised
<sb0> so all user-defined exceptions must derive from ARTIQException?
<sb0> whitequark, can you fix the unittests...?
<whitequark> to be ergonomic, yes, I think so
<whitequark> I will take a look at unittests
<whitequark> what is broken now?
<sb0> many things, half the compiler tests are failing
<sb0> (when the core device is actually involved)
<whitequark> can you give me a log? I've misplaced the ssh magic that sets up the tunnel somewhere
<whitequark> and pipistrello needs to be reflashed...
<sb0> whitequark, what is the necessity for ARTIQException? can't the compiler figure that out by itself?
<whitequark> the compiler doesn't care
<whitequark> it will accept anything inheriting from BaseException
<sb0> but the incorrect exception is raised by a kernel then
<whitequark> the runtime, however, needs to grab the exception class somehow
<whitequark> in order to raise it
<sb0> class MyException(Exception): pass; @kernel def run(): raise MyException
<whitequark> ... hrm, wait, I can just parse the path to the exception
<sb0> why can't that raise MyException?
<whitequark> well, right now it doesn't work because the runtime doesn't know anything about scoping
<sb0> again that worked with my compiler
<whitequark> there are several annoying issues here
<whitequark> I can't identify an exception only by its id in the object map, because C runtime can also raise them
<whitequark> and it doesn't know nor care about object map
<whitequark> I can't identify it only by its name either, because there's no easy way to grab an exception given only its name
<whitequark> except the inheritance trick that I've used
<whitequark> I should be able to fix most core unit tests today...
_whitelogger has quit [Ping timeout: 240 seconds]
_whitelogger has joined #m-labs
whitequark has quit [Ping timeout: 240 seconds]
whitequark has joined #m-labs
_whitelogger has joined #m-labs
whitequark has joined #m-labs
EvilSpirit has joined #m-labs
whitequark has quit [Ping timeout: 264 seconds]
_whitelogger has joined #m-labs
whitequark has joined #m-labs
_whitelogger_ has joined #m-labs
Mon_ has joined #m-labs
_whitelogger has joined #m-labs
whitequark has joined #m-labs
_whitelogger has joined #m-labs
Mon_ has quit [Quit: Leaving]
rohitksingh1 has joined #m-labs
rohitksingh has quit [Ping timeout: 265 seconds]
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
EvilSpirit has joined #m-labs
rohitksingh1 has quit [Ping timeout: 246 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined #m-labs
EvilSpirit has quit [Ping timeout: 255 seconds]
<larsc> if I want a lightweight co-processor for some low-latency event handling is there something you'd recommend?
mumptai has quit [Quit: Verlassend]