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
attie has joined #m-labs
<sb0> whitequark, maybe the tests can use some dedicated function for reporting instead of print()?
<GitHub> [artiq] sbourdeauducq commented on issue #704: Adding the conda-forge channel before installing ARTIQ fixes the problem, as it installs pyqtgraph 0.10 then. AFAICT there are no adverse effects. https://github.com/m-labs/artiq/issues/704#issuecomment-292838083
<GitHub> [artiq] sbourdeauducq opened issue #711: pre-link scripts conda warning https://github.com/m-labs/artiq/issues/711
<sb0> what is the "shield" circuit (and ensuing complexity of a differential amplifier after the TIA) for? https://framapic.org/u19Aejno75lV/P5wd8mlXSjx9.png
<sb0> this goes to the shield of the BNC used to measure ion current
<sb0> avoiding ground loops?
<sb0> shield circuit == R156 + C155
<sb0> yeah, I suppose it's for avoiding ground loops
<whitequark> sb0: then that would complicate running them with host python.
<whitequark> and I think a better behavior for startup kernels is to redirect print() to core log, not just prohibit it.
<whitequark> how do you suppose they should be debugged?
<sb0> also is there any disadvantage to a large C151 (TIA stabilization cap) instead of optimizing it? this amp is basically taking DC, the bandwidth doesn't really matter
<sb0> whitequark, sounds good
<whitequark> well, there's rtio_log. but it's for different things.
<sb0> is it what it is doing now? that should be documented, too
<sb0> well I suppose large cap = more leakage
rohitksingh_work has joined #m-labs
<whitequark> no, that's not what it's doing
<whitequark> but it should be fairly easy to do this redirect
<sb0> whitequark, ok, please do it, document it, and close the issue
sb0 has quit [Quit: Leaving]
<whitequark> sure
sb0 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 240 seconds]
rohitksingh_work has joined #m-labs
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
<GitHub> [artiq] cjbe opened issue #712: dma sequence recording slow https://github.com/m-labs/artiq/issues/712
<GitHub> [artiq] jordens opened issue #713: inferring return types with annotations https://github.com/m-labs/artiq/issues/713
rohitksingh_work has quit [Read error: Connection reset by peer]
<GitHub> [artiq] whitequark commented on issue #712: That's what I expect from the current implementation, yes. I recall we've discussed this with @sbourdeauducq and decided that doing a syscall for every `rtio_output` is acceptable.... https://github.com/m-labs/artiq/issues/712#issuecomment-292943714
<GitHub> [artiq] whitequark commented on issue #713: > ```... https://github.com/m-labs/artiq/issues/713#issuecomment-292944996
<GitHub> [artiq] jordens commented on issue #712: Why does it have to go through the comms CPU at all? Why can't the kernel CPU own the DMA engine? Why does there need to be any shared memory between comms and kernel?... https://github.com/m-labs/artiq/issues/712#issuecomment-292946755
Ultrasauce has joined #m-labs
<GitHub> [artiq] whitequark commented on issue #712: > Why can't the kernel CPU own the DMA engine?... https://github.com/m-labs/artiq/issues/712#issuecomment-292948660
rohitksingh has joined #m-labs
<GitHub> [artiq] whitequark commented on issue #712: > also intentionally makes implementing future features harder.... https://github.com/m-labs/artiq/issues/712#issuecomment-292965102
<GitHub> [artiq] sbourdeauducq commented on issue #712: > But what I could rather easily do is accumulate RTIO events in some sort of static buffer, and only send a slice from the buffer over to comms CPU once in a while.... https://github.com/m-labs/artiq/issues/712#issuecomment-292965510
<GitHub> [artiq] jordens commented on issue #712: It is slow irrespective of that it fundamentally could be.... https://github.com/m-labs/artiq/issues/712#issuecomment-292976398
<GitHub> [artiq] sbourdeauducq commented on issue #712: Why should writing a record to a memory buffer be slower than writing it to the RTIO(/DMA) core?... https://github.com/m-labs/artiq/issues/712#issuecomment-292980271
<GitHub> [artiq] sbourdeauducq commented on issue #712: Why should writing a record to a memory buffer be slower than writing it to the RTIO(/DMA) core?... https://github.com/m-labs/artiq/issues/712#issuecomment-292980271
<GitHub> [artiq] jordens opened issue #714: iterate over binary data https://github.com/m-labs/artiq/issues/714
<GitHub> [artiq] sbourdeauducq commented on issue #712: Why should writing a record to a memory buffer be slower than writing it to the RTIO(/DMA) core?... https://github.com/m-labs/artiq/issues/712#issuecomment-292980271
<whitequark> rjo: you've found so many compiler bugs, are you doing something particularly interesting?
<sb0> pdq
<whitequark> pdq?
<whitequark> I mean, I understand it's some sort of device
<sb0> whitequark, have you looked at https://github.com/m-labs/pdq ?
<sb0> there are also the references in the readme that explain what this does
<sb0> there has been some evolution, but the basic idea remains the same
<rjo> whitequark: no. i am just using it. am i the only one?
<whitequark> rjo: others seem to hit bugs rarely, and one at a time.
<whitequark> so I was wondering if you were doing something unusual.
<rjo> whitequark: i don't think i am doing something unusual.
<whitequark> okay.
<GitHub> [artiq] whitequark commented on issue #714: Why not both. https://github.com/m-labs/artiq/issues/714#issuecomment-292995574
<whitequark> sb0: "pretty darn quick" heh
<rjo> whitequark: maybe a difference is that i have an opinion how i want the compiler to behave. other users might just work around it...
<whitequark> that could be
<GitHub> [artiq] jordens commented on issue #714: ack. "better" just when prioritizing. the `.extend()` ability of `bytearray()` might make it more problematic again. what i'd like is a fixed size bytes/bytearray where i can set elements. https://github.com/m-labs/artiq/issues/714#issuecomment-293002947
<GitHub> [artiq] whitequark commented on issue #714: > the .extend() ability of bytearray() might make it more problematic again... https://github.com/m-labs/artiq/issues/714#issuecomment-293003817
<GitHub> [artiq] whitequark commented on issue #714: > the .extend() ability of bytearray() might make it more problematic again... https://github.com/m-labs/artiq/issues/714#issuecomment-293003817
<GitHub> [artiq] cjbe opened issue #715: Async RPC ConnectionResetError https://github.com/m-labs/artiq/issues/715
<GitHub> [artiq] whitequark commented on issue #715: What is in the core log? https://github.com/m-labs/artiq/issues/715#issuecomment-293026869
<GitHub> [artiq] cjbe commented on issue #715: ```... https://github.com/m-labs/artiq/issues/715#issuecomment-293027237
<GitHub> [artiq] whitequark commented on issue #715: Ah, I've been looking for a repro for that intermittent failure for quite some time. https://github.com/m-labs/artiq/issues/715#issuecomment-293028002
<GitHub> [artiq] npisenti commented on issue #704: I don't see any issues either. All seems to work as expected. https://github.com/m-labs/artiq/issues/704#issuecomment-293068232
rohitksingh has quit [Quit: Leaving.]