<GitHub>
[artiq] sbourdeauducq commented on issue #432: According to @dhslichter , a feature like this is still wanted, but the desired dead time between experiments is ~10ms (not microseconds), so we can afford a round-trip with the PC and simplify the scheduler design (and the current scheduler could be kept as-is).... https://github.com/m-labs/artiq/issues/432#issuecomment-287513347
<GitHub>
[artiq] sbourdeauducq commented on issue #432: According to @dhslichter , a feature like this is still wanted, but the desired dead time between experiments is ~10ms (not microseconds), so we can afford a round-trip with the PC and simplify the scheduler design (and the current scheduler could be kept as-is).... https://github.com/m-labs/artiq/issues/432#issuecomment-287513347
<whitequark>
we could hook the python interpreter to invalidate our kernel cache (either a true cache or this "device-assisted scheduling" thing) when any of the attributes we've compiled in are changed
<GitHub>
[artiq] sbourdeauducq commented on issue #432: No, we would need to restrict that. Maybe even enforce it so that the user cannot modify a Python object that has been included in a kernel compilation until the kernel is run, but I'm not sure if that can be done without horrible/unreliable hacks and/or slowness. https://github.com/m-labs/artiq/issues/432#issuecomment-287513514
<GitHub>
[artiq] sbourdeauducq commented on issue #432: Yes, we can override setattr, but this won't catch all modifications, e.g. ``object.__setattr__(target, key, value)``. But it could be good enough. https://github.com/m-labs/artiq/issues/432#issuecomment-287513661
<GitHub>
[artiq] whitequark commented on issue #432: > Yes, we can override setattr, but this won't catch all modifications, e.g. object.__setattr__(target, key, value). But it could be good enough.... https://github.com/m-labs/artiq/issues/432#issuecomment-287513738
<GitHub>
[artiq] sbourdeauducq commented on issue #432: We don't know the scheduler's decision nor the host control flow of the next experiment, so the start of the next kernel should be when it is actually called, not when the previous session ends. And there could be multiple kernels preloaded, from different experiments or from the same. So this becomes essentially a kernel caching mechanism. Something like:... https://github.com/m-labs/artiq/issues/432#
<GitHub>
[artiq] sbourdeauducq commented on issue #432: We don't know the scheduler's decision nor the host control flow of the next experiment, so the start of the next kernel should be when it is actually called, not when the previous session ends. And there could be multiple kernels preloaded, from different experiments or from the same. So this becomes essentially a kernel caching mechanism. Something like:... https://github.com/m-labs/artiq/issues/432#
<GitHub>
[artiq] sbourdeauducq commented on issue #432: We don't know the scheduler's decision nor the host control flow of the next experiment, so the start of the next kernel should be when it is actually called, not when the previous session ends. And there could be multiple kernels preloaded, from different experiments or from the same. So this becomes essentially a kernel caching mechanism. Something like:... https://github.com/m-labs/artiq/issues/432#
<sb0>
whitequark, not sure if that helps. there would be obscure invalidations (and corresponding poor performance) that users will have a hard time debugging
<whitequark>
sb0: why make them obscure?
<sb0>
locking the objects + explicit cache loading/unloading is more transparent
<whitequark>
just print them out. or have a flag.
<whitequark>
but yes. I am not opposed to explicit locking at all.
<whitequark>
it just seems like the kind of ceremony people might dislike.
<GitHub>
[artiq] sbourdeauducq commented on issue #535: @dhslichter mentioned basic math functions (sin, cos, log, exp). Should those be gateware-accelerated, or are slower software implementations (using gateware FP for floating addition, multiplication, etc.) OK? https://github.com/m-labs/artiq/issues/535#issuecomment-287514582
<GitHub>
[artiq] sbourdeauducq commented on issue #679: We can rename the "Linear" scan to a "Range" scan, add a "randomize" checkbox, and remove the "Random" scan. The user experience is the same IMO and it is easier to program. https://github.com/m-labs/artiq/issues/679#issuecomment-287521517
<GitHub>
[artiq] jordens commented on issue #535: I would really prefer not to stray to far of the beaten path here, i.e. for hard FP and vectorization (which is an extremely complicated thing to reinvent) we should concentrate on the corresponding openrisc instruction sets and implement them, instead of inventing new instruction sets. Also accelerated trigonometry is of similar complexity as vectorization.... https://github.com/m-labs/artiq/issues/535#issu
<rjo>
whitequark: in fractions of the overall smoltcp development effort: how much would adding ipv6 support be?
<whitequark>
rjo: 1/4, maybe
<whitequark>
maybe even less. it's already prepared for ipv6 to a degree.
<whitequark>
i.e. all the matches over the kind of address and such are there. just needs packet parsers and neighbor discovery
<rjo>
whitequark: if smoltcp took two months, then that's <2 weeks?
<rjo>
whitequark: could you spice up that github issue about ipv6 (on artiq) with why ipv6 is good, so that people want to fund it?
<whitequark>
rjo: I was going off 6 weeks
<whitequark>
four weeks of initial dev plus two more of debugging
<whitequark>
going by the git log that seems realistic.
siruf has quit [Remote host closed the connection]
hawk_king has quit [Quit: Page closed]
hawk_king_ has joined #m-labs
hawk_king_ has quit [Quit: Page closed]
siruf has joined #m-labs
mumptai has joined #m-labs
brandonz has joined #m-labs
kilae has joined #m-labs
kilae has quit [Quit: ChatZilla 0.9.93 [Firefox 52.0/20170302120751]]
allen0s has joined #m-labs
<allen0s>
kc705 flashed and available on the network, flterm output correct. when I run led.py sample program, no leds turn on or off. using nist_qc2. do I need to adjust a mapping somewhere?
<allen0s>
however, i can toggle leds in test mode at power up