<whitequark>
sb0: there is a problem with exceptions
<whitequark>
sure, I can map exceptions back to something else than ARTIQException, but then you will lose the core device traceback
<whitequark>
ah no wait, I can use the same hack as now, though it's gross
<whitequark>
sb0: ping
<sb0>
whitequark, yes?
<whitequark>
I think I told you before that to make an exception recognizable after going through the core device you have to add a builtin
<whitequark>
which is incorrect, of course, it just has to derive from ARTIQException
<whitequark>
is that still a problem?
<sb0>
I'd say no for now, as there are more pressing issues
<whitequark>
I kinda started working on it already, so would you figure out if this is the semantics you want or not?
<whitequark>
there are some advantages to it, for example, I have to store the core device backtrace and params somewhere
<whitequark>
and if I just map it to bare Python exceptions I have to stash them into strings
<whitequark>
even if I leave the original around this messes with anything that wants to examine them
<sb0>
so you are proposing that all exceptions that go through the core device need to derive from ARTIQException?
<whitequark>
in short, yes
<sb0>
what if e.g. a RPC raises TypeError?
<whitequark>
it will be reraised as an ARTIQException
<whitequark>
and you will get one line of backtrace before it went through the core device, as opposed to zero
<whitequark>
it's not possible to fake backtraces in python. I tried basically every imaginable option
<sb0>
I don't like ARTIQException. can't you catch the exception in the RPC handler, store its class in a map of exceptions that the core device may potentially raise, and raise the correct one?
<sb0>
didn't we talk about fake backtraces sometime ago?
<sb0>
some templating engine did that iirc
<sb0>
...of course, all this is orders of magnitude less important than e.g. the context managers not working
<whitequark>
yes, it used the C bindings to Python to manipulate exceptions
<whitequark>
poking the innards of the runtime basically
<sb0>
ok, why can't we recycle that?
<whitequark>
because it's going to break when a new Python version comes out someday?
<sb0>
btw you can load the runtime with flterm too
<whitequark>
oh?
<whitequark>
also on kc705?
<sb0>
yes, it's the same BIOS
<sb0>
and there's TFTP netboot even
<sb0>
isn't this linking mechanism incompatible with the MPU proposal?
<whitequark>
hm, it would be enough to guard writes, really
<whitequark>
since the only thing we really care about are stack overflows, also maybe random unsoundness
<whitequark>
hang on
<whitequark>
why would it be incompatible? ksupport has a copy of all basic routines
<sb0>
but e.g. strcmp is linked with the main binary, ksupport.c is compiled with it, and therefore &strcmp will point to the function in the main binary
<sb0>
no?
<sb0>
remember there was this problem that the main binary would not know where the functions were in ksupport, and you didn't like my elftools-based script, so you replaced that with a single symbol space
<whitequark>
I don't remember why exactly I made it so but there was a reason
<whitequark>
yeah, you could also guard reads, to catch bugs earlier
<whitequark>
... wtf
<whitequark>
it doesn't crash anymore
<whitequark>
I didn't do anything that would have made it not crash
<whitequark>
.... oh
<whitequark>
it was a completely unrelated bug in the unwinder debug logging code which no one has noticed until now by sheer chance
<sb0>
how fast is the linker? or is there still a way to load multiple kernels in advance and switch fast between them, e.g. by having a single copy of ksupport?
<whitequark>
the linker should take no more than a millisecond to run
<sb0>
actually if we do that, the MPU should probably be smarter as well
<whitequark>
loading multiple kernels in advance should be easy
_whitelogger has joined #m-labs
_whitelogger_ has joined #m-labs
<whitequark>
sb0: got kicked out... linode having connectivity issues again
<sb0>
ok, nothing happened while you were gone
<whitequark>
so, multiple kernels, you literally just load multiple kernels
<whitequark>
since they're now PIC
<whitequark>
but that's semantically unsound
<whitequark>
because kernels carry the state of host objects with them.
bentley` has joined #m-labs
rohitksingh has joined #m-labs
_whitelogger_ has quit [Read error: Connection reset by peer]
_whitelogger has joined #m-labs
<whitequark>
perhaps, but you have to multiplex stuff on commcpu and also give them separate stack spaces
fengling has joined #m-labs
_whitelogger has joined #m-labs
_whitelogger has quit [Excess Flood]
_whitelogger has joined #m-labs
_whitelogger has quit [Excess Flood]
_whitelogger has joined #m-labs
_whitelogger has quit [Excess Flood]
fengling has quit [Read error: Connection reset by peer]
_whitelogger_ has joined #m-labs
<GitHub78>
[artiq] whitequark pushed 1 new commit to master: http://git.io/vuesC