00:05
<
sb0 >
whitequark, host_only has broken the unittests
00:06
<
whitequark >
hm, thought I had fixed that
00:06
<
GitHub141 >
artiq/master e6185e1 whitequark: Commit missing parts of 127b117.
00:15
sb0 has quit [Quit: Leaving]
00:31
<
rjo >
whitequark: your memoize() is broken: it never updates the cache.
00:31
<
whitequark >
rjo: I wrote a memoize() ?
00:32
<
whitequark >
oh, in the debug info generator. fun.
00:33
<
rjo >
there is lru_cache somewhere in the stdlib
00:33
sb0__ has joined #m-labs
00:33
<
sb0__ >
whitequark: now there is this "hardware exception" bug ...
00:34
<
sb0__ >
the new compiler has a lot of issues.
00:34
<
whitequark >
sure. it's much more complex.
00:34
<
sb0__ >
happens all the time now
00:35
<
whitequark >
do you have a small repro?
00:35
<
sb0__ >
and that's seriously annoying, every demo i have attempted has crashed
00:35
<
whitequark >
sb0__: hang on
00:36
<
whitequark >
was that after my sret fix?
00:36
<
whitequark >
hm, very strange
00:36
<
sb0__ >
before that it only crashed with small values of nrep
00:36
<
whitequark >
can you give me any of the crashing demos?
00:38
<
sb0__ >
whitequark: in the issue. default_std.py
00:38
<
sb0__ >
in conjunction with the std_include above
00:43
<
sb0__ >
the crashing bit seems to be the assingment into self.counts
00:44
<
sb0__ >
out-of-bounds error?
00:45
<
whitequark >
arrays are not copied on assignment
00:45
<
sb0__ >
I'm talking about self.counts[self.rep_i] = cts
00:46
<
sb0__ >
commenting this out makes the hardware exception disappear
00:46
<
whitequark >
no, the EA is too low
00:46
<
whitequark >
exception 6 is unaligned access.
00:46
<
sb0__ >
i guess it didn't crash there before the sret fix, because count() never returned and this was not executed
00:46
<
sb0__ >
bugs, bugs, bugs, bugs ...
00:46
<
sb0__ >
when will this end?
00:50
<
whitequark >
mhm, we need a more representative testsuite for the core device. beyond the basic operations
00:51
<
whitequark >
e.g. the portability testsuite found a lot of bugs... we don't have anything like that for RTIO though
01:07
<
rjo >
sure there is.
01:08
<
whitequark >
if it didn't catch this bug, it's not representative enough
01:08
<
whitequark >
I'll take a look at expanding it...
01:09
<
rjo >
artiq/test/coredevice/rtio.py
01:09
<
whitequark >
yes, I know
01:10
<
sb0__ >
guess this test has not been run in a while, during which it broke.
01:10
<
whitequark >
mhm, yes, we should run those in the lab
01:10
<
whitequark >
actually, what's holding that off? it should be trivial to implement
01:10
<
sb0__ >
whitequark: any ideas about this hw exception? it's blocking right now and i haven't found a small repro
01:11
<
whitequark >
let me finish fixing the compile error in GUI and I will minimize it
01:11
<
whitequark >
almost done
01:16
<
sb0__ >
whitequark: attribute writeback of lists also looks broken ....
01:16
<
sb0__ >
oh yes it is
01:28
<
GitHub75 >
artiq/master 8522278 whitequark: transforms.llvm_ir_generator: fix memoize().
01:28
<
GitHub75 >
artiq/master 95470a5 whitequark: gui.log: work around a Qt layout bug.
01:28
<
GitHub75 >
artiq/master 67d2e7a whitequark: worker: display compile warnings and errors nicely (#227).
01:29
<
whitequark >
sb0__: while I work on that crash, can you check if I really worked around that Qt bug?
01:39
<
whitequark >
sb0__: worker.py:184 leads to exceptions being formatted in really awful ways
01:59
<
GitHub23 >
artiq/master d337121 whitequark: worker: make parent errors readable in log.
02:07
<
GitHub72 >
artiq/master 6bf48e6 whitequark: worker: make parent errors readable in log.
02:08
<
whitequark >
now I just get
02:08
<
whitequark >
ERROR:master:artiq.master.scheduler:got worker exception in run stage, deleting RID 3
02:11
<
whitequark >
so now it's my turn to complain about bugs. without running artiq_master as -vv, the DEBUG messages don't appear in the GUI at all
02:11
<
whitequark >
therefore defeating the purpose of that log level switch
02:11
<
whitequark >
why do you print an exception as debug anyway?..
02:17
<
whitequark >
wtf is expid?
02:17
<
sb0__ >
whitequark: the worker debug messages do appear in the gui, without master -vv.
02:18
<
whitequark >
no, they do not.
02:18
<
whitequark >
I had to do
02:18
<
whitequark >
- logger.debug("worker exception details", exc_info=True)
02:18
<
whitequark >
+ logger.info("worker exception details", exc_info=True)
02:18
<
whitequark >
and actually not even that worked
02:18
<
whitequark >
logger.warn is the lowest level which makes them appear in the GUI
02:19
<
sb0__ >
is the master calling that or the worker?
02:19
<
whitequark >
that's in master/scheduler.py
02:19
<
sb0__ >
ok. so yes, that is dependent on the master debug level.
02:20
<
GitHub68 >
artiq/master 13e65c2 whitequark: scheduler: make sure worker exceptions are not unexpectedly hidden.
02:20
<
sb0__ >
unless you are debugging the master, you shouldn't have to touch it though
02:21
<
whitequark >
well, it crashed and I spent a lot of time figuring out why
02:22
<
whitequark >
hm, I cannot even copy log entries...
02:22
<
whitequark >
ValueError: cannot create an OBJECT array from memory buffer
02:23
<
whitequark >
it tries to decode some worker pyon
02:28
<
whitequark >
sb0__: ok, I am unable to reproduce the bug on the lab kc705
02:28
<
whitequark >
the experiment just runs forever
02:39
<
whitequark >
oh, that's because it doesn't actually run
02:39
<
whitequark >
everything about artiq_master is so broken.
02:40
<
whitequark >
ah, no, not artiq_master's fault, my fault.
02:42
<
whitequark >
ok, I turned off simulation, but it still doesn't crash
02:44
<
whitequark >
nreps is set to 5...
02:45
<
whitequark >
sb0__: attribute writeback of lists works
02:46
<
whitequark >
if you tried to do this...
02:46
<
whitequark >
then it's a bug in the sense that you shouldn't be allowed to do this.
02:51
<
sb0__ >
yes, i did #2. what is the problem with that?
02:52
<
whitequark >
the allocated list only lives until the function returns
02:52
<
whitequark >
so of course you read back garbage
02:52
<
sb0__ >
oh, so that might be why the experiment crashes too
02:52
<
whitequark >
ah, yes, most certainly.
02:52
<
sb0__ >
since the list is allocated in rep_start
02:54
<
whitequark >
sb0__: try list[:] = [0 for ...]
02:55
<
whitequark >
yep, that works, but you need to write it as list[0:] because of some other bug
02:55
<
whitequark >
let me fix that one, it's easy
02:56
<
rjo >
sb0__: /joe beer any time?
03:09
<
GitHub21 >
artiq/master be560db whitequark: Commit missing parts of 13e65c2a.
03:09
<
GitHub21 >
artiq/master cc22837 whitequark: transforms.inferencer: infer a monomorphic type for slice ":"
03:12
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
03:12
<
GitHub81 >
buildbot-config/master 05ddef6 whitequark: Merge build requests.
03:13
bb-m-labs has joined #m-labs
03:25
rohitksingh has joined #m-labs
03:34
sb0__ has quit [Quit: Page closed]
04:07
evilspirit has joined #m-labs
04:58
sb0 has joined #m-labs
05:55
ylamarre has quit [Quit: ylamarre]
09:21
stekern has quit [Ping timeout: 265 seconds]
09:28
rohitksingh has quit [Quit: Leaving.]
12:57
evilspirit has quit [Ping timeout: 264 seconds]
13:33
imrehg has joined #m-labs
13:46
attie has quit [Ping timeout: 260 seconds]
13:47
attie has joined #m-labs
14:01
attie has quit [Ping timeout: 246 seconds]
14:03
attie has joined #m-labs
14:08
attie has quit [Ping timeout: 264 seconds]
14:09
attie has joined #m-labs
14:43
imrehg has quit [Quit: Leaving]
14:54
sb0 has quit [Quit: Leaving]
15:31
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
15:32
bb-m-labs has joined #m-labs
15:34
bb-m-labs has quit [Client Quit]
15:34
bb-m-labs has joined #m-labs
15:41
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
15:41
bb-m-labs has joined #m-labs
15:43
bb-m-labs has quit [Client Quit]
15:43
bb-m-labs has joined #m-labs
15:53
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
15:53
bb-m-labs has joined #m-labs
15:54
bb-m-labs has quit [Client Quit]
15:55
bb-m-labs has joined #m-labs
15:58
bb-m-labs has quit [Client Quit]
15:58
bb-m-labs has joined #m-labs
16:00
bb-m-labs has quit [Client Quit]
16:00
bb-m-labs has joined #m-labs
16:02
bb-m-labs has quit [Client Quit]
16:02
bb-m-labs has joined #m-labs
16:03
<
whitequark >
fucking hell
16:03
<
whitequark >
pysftp is a piece of crap that doesn't actually implement sftp semantics
16:03
<
whitequark >
or... any usable semantics at all
16:04
<
whitequark >
doesn't even have rm_r
16:06
<
whitequark >
and of course its directory traverse code is completely unsuitable for implementing rm_r
16:11
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
16:11
bb-m-labs has joined #m-labs
16:13
<
whitequark >
amazing
16:13
<
whitequark >
I can't believe it finally worked. only took me a dozen tries.
16:16
<
GitHub104 >
buildbot-config/master d1c43a4 whitequark: Upload ARTIQ manual via SFTP.
16:19
evilspirit has joined #m-labs
16:39
<
GitHub174 >
artiq/master 785b273 whitequark: Document core device cache (#219).
16:40
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
16:41
bb-m-labs has joined #m-labs
16:48
<
whitequark >
so, it didn't actually work. crap.
16:52
evilspirit has quit [Ping timeout: 264 seconds]
16:53
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
16:54
bb-m-labs has joined #m-labs
16:56
stekern has joined #m-labs
16:59
mumptai has joined #m-labs
17:00
<
whitequark >
ok, much better now
17:02
stekern has quit [Ping timeout: 272 seconds]
17:19
sb0 has joined #m-labs
17:19
sb0 has quit [Client Quit]
17:20
sb0 has joined #m-labs
17:53
<
sb0 >
whitequark, er, master no longer starts... looking into it
17:54
<
sb0 >
ah, it's my fault.
17:57
<
GitHub85 >
artiq/master a808d26 Sebastien Bourdeauducq: style
17:57
<
GitHub85 >
artiq/master f9323c3 Sebastien Bourdeauducq: master/worker_db/get_last_rid: ignore improperly named files
18:21
sb0 has quit [Quit: Leaving]
22:17
rohitksingh has joined #m-labs
22:21
<
cr1901_modern >
rjo: Adding onto what you said re: xc3sprog and OpenOCD proxies being different, I did a quick lookup. It appears that the xc3sprog proxies write to a block RAM using the SPI protocol. The block RAM attaches itself to the boundary scan implemenation on the FPGA, and is manipulated through the block RAM. So yea, it is indeed much more complicated :P
23:56
rohitksingh has quit [Quit: Leaving.]
23:57
<
rjo >
cr1901_modern: i explained all this to uwe bonnes and he said he would look into making xc3sprog use the trivial (openocd) bitstreams.