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
mumptai has joined #m-labs
<rjo>
sb0: and numpy is such an integral part in all of our numerical work. i would not be afraid to use linspace/logspace/random.shuffle here.
aeris has quit [Ping timeout: 256 seconds]
aeris has joined #m-labs
sb0 has quit [Ping timeout: 244 seconds]
<rjo>
sb0, florent: uart.c#L77 why is getmask/setmask() used there? getie() is used in L73. isn't setmask(0) the same as setie(0)? or asking differently, would'nt you want to check for IE _and_ the UART bit in the mask in L73 and disable just the UART irq from L78 to L79?
<rjo>
sb0: rather than doing ppp, couldn't we just expose the serial port as a tcp port (on the host)?
<rjo>
ah. forget it. there is the udp channel.
kyak has quit []
kyak has joined #m-labs
kyak has quit []
kyak has joined #m-labs
sb0 has joined #m-labs
<sb0>
those scans need to run on the device I think, so no numpy
<sb0>
what about the prng seed? fixed or not?
<sb0>
rjo, udp and the tcp "connection established/terminated" info
<GitHub117>
[artiq] whitequark pushed 4 new commits to new-py2llvm: http://git.io/vmy5B
<GitHub117>
artiq/new-py2llvm f212ec0 whitequark: Add a trivial dead code elimination transform....
<GitHub45>
artiq/master 97ebdee Sebastien Bourdeauducq: gui: add pyqtgraph patch to prevent closing of detached nonclosable docks (move them to main window instead)
<sb0_>
rjo, what is the "#if 0" section doing in your uart code?
<sb0_>
it may produce a spurious tx interrupt, though it's not a problem I think
<sb0_>
but I wonder what problem it is supposed to solve
<sb0_>
well, no spurious tx irq
rjo_ has joined #m-labs
<rjo_>
sb0_: in the cases i can think of, we would want to scheduler.pause() anyway in each iteration of the scan loop. i have a hard time coming up with examples for where the scan needs to happen on the core device.
<rjo_>
sb0_: and even in that case we could rpc the next() call
<rjo_>
sb0_: anyways. what happens if i scheduler.pause() from kernel context? can it suspend that experiment?
<rjo_>
sb0_: i was unsure whether trying to transfer from ringbuffer to fifo is a good idea in uart_write() or whether that should be left entirely to the bottom half.
<rjo_>
i gravitate towards not doing it because it is more code and costs time. but it may save a few context switches...
<sb0_>
scheduler.pause() from kernel will break because the next experiment will disconnect the paused one from the core device
<sb0_>
as a matter of fact, you are supposed to disconnect from the core device before calling pause() to avoid a connection dropped error
<rjo_>
sb0_: what does disconnecting look like? is returning from a kernel enough?
<sb0_>
self.core.close()
<sb0_>
returning from kernels do not close the connection so that now() is kept
<sb0_>
*does not
<sb0_>
and the idle kernel is not run
<rjo_>
ack. then all cases i can think of will loop on the worker over [a kernel, core.close(), pause()]
<sb0_>
yes
<rjo_>
that is the natural place to call pause().
<sb0_>
i still need to implement core.close ...
<sb0_>
well, in fact, self.core.comm.close() should be enough
<sb0_>
since the now() management is done entirely by the runtime now
<rjo_>
whitequark: that 4-line test code takes 2.5ms to do Module.from_string(). should i be worried that for ~1000 lines it would be 0.6s (plus all the optimization passes, llvm itself, and the upload)?
<rjo_>
sb0_: ack. feel free to restrict the scan loops to be on-worker.
<rjo_>
.. or we need to make the pausing so that the kernel can return and when a pause request is pending (due to unscheduling or another higher pri experiment become due) and the worker can then service the request by pause()ing.
<sb0_>
add a pause_requested() call that just returns a status and has no side effect? (and thus is RPCable from kernels)
<rjo_>
sounds good.
<rjo_>
then i leave it to you whether to restrict the scan to be on-worker or not.
<rjo_>
and fixed seed is fine for the randomizer.
<sb0_>
with the current scan code, the only needed additional compiler feature is generators
<rjo_>
and a prng
<sb0_>
not necessarily
<sb0_>
scan sequences would be computed on the host and sent as rodata lists
<sb0_>
(for the randomized ones that is)
<rjo_>
ack.
<GitHub68>
[misoc] sbourdeauducq pushed 3 new commits to master: http://git.io/vmQUL
<GitHub68>
misoc/master 84514cf Sebastien Bourdeauducq: uart: remove option to refill HW from uart_write
<GitHub68>
misoc/master a501d7c Robert Jordens: uart: support async phys
<GitHub68>
misoc/master 097248b Robert Jordens: uart.c: rx overflow fix and tx simplification...
<sb0_>
the only limitation of the current scan code is the sequence is randomized only once during argument initialization (i.e. experiment build())
<sb0_>
iterating multiple times over the scanner results in the same sequence every time
<sb0_>
which may or may not be desirable
aeris has quit [Ping timeout: 260 seconds]
<rjo_>
that would require a bit of a workaround (remapping the variables) for n-dimensional scans where the inner dimensions depend on the outer.
<rjo_>
but it's fine.
aeris has joined #m-labs
rjo_ has quit [Quit: leaving]
<sb0_>
do you mean scanning on shapes that are not squares/cubes/hypercubes?
aeris has quit [Ping timeout: 250 seconds]
acathla has quit [Ping timeout: 264 seconds]
aeris has joined #m-labs
acathla has joined #m-labs
<sb0_>
what happened to the altera fpga with integrated fiber optics transceiver?