03:25 <sb0> whitequark, regarding https://github.com/m-labs/artiq/issues/402 - I guess the problem is attribute writeback is turning the int64 into int32?

03:26 <sb0> and is the compiler caching/keeping things across kernels now to speed up? or is that unintended?

03:27 <whitequark> yes, the problem with writeback is as you described.

03:27 <whitequark> there is no caching between kernels of any sort

03:28 <whitequark> why do you think there is?

03:30 <sb0> it seems the second compilation is checking the new type of the attribute (int32) matches the type found during the first compilation (int64)

03:31 <sb0> but I might be misinterpreting that

03:31 <whitequark> no, it does not

03:31 <whitequark> i_previous_timestamp is accessed as int64

03:31 <whitequark> and it's initially assigned as int64 too

03:31 <whitequark> when it's reassigned as a regular int (which defaults to int64), it is first inferred from the access

03:32 <whitequark> remember, inference does not have (a fixed/stable) direction

03:35 <sb0> there's still something weird about the error message

03:36 <sb0> whitequark, this is more like the expected behavior: http://paste.debian.net/433101/

03:39 <sb0> whitequark, http://paste.debian.net/433112/

03:40 <whitequark> mhm

03:40 <whitequark> sb0: the error message is weird because there are two TTL outputs

03:41 <whitequark> the first has the correct type, so all accesses to it typecheck

03:41 <whitequark> after all the TTL-related functions were embedded and typechecked, the other TTL channel is pulled in

03:41 <whitequark> and it doesn't match the first one, which causes the error

03:41 <whitequark> by the time the error is discovered, all original context is long lost

03:42 <whitequark> I believe I warned you about this when we first were discussing embedding (eight months ago, okay), not that there is a good solution

03:43 <sb0> ok. what about the next paste?

03:43 <whitequark> that's a bug

03:43 <whitequark> I never really considered deserialization of int64s

03:43 <whitequark> well, it's easy to fix, fortunately

03:43 <sb0> or two. why is it not refusing the compile the second time, even though the attribute is int not int64?

03:44 <sb0> is that because the python int is too large to fit in 32-bit and it automatically chooses int64?

03:44 <whitequark> that's probably it, yes

03:45 <whitequark> actually, hm, that looks odd

03:45 <whitequark> I don't think it's a bug, but I want to look closer at that

03:59 <mithro> rjo: You pointed to a misoc jtag serial port somewhere? Do we have a way to debug the lm32/or1k CPU via jtag?

06:22 <GitHub32> [artiq] sbourdeauducq pushed 2 new commits to release-1: https://git.io/vwLcs

06:22 <GitHub32> artiq/release-1 0a25941 Sebastien Bourdeauducq: environment: make NumberValue return integers when appropriate. Closes #397

06:22 <GitHub32> artiq/release-1 08f903b Sebastien Bourdeauducq: environment,worker: remove enable_processors

06:22 <GitHub180> [artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/vwLcG

06:22 <GitHub180> artiq/master dc44aad Sebastien Bourdeauducq: environment: make NumberValue return integers when appropriate. Closes #397

06:22 <GitHub180> artiq/master 12a8c76 Sebastien Bourdeauducq: environment,worker: remove enable_processors

06:33 <bb-m-labs> build #349 of artiq-kc705-nist_clock is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-kc705-nist_clock/builds/349

06:36 <bb-m-labs> build #610 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/610 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>

07:00 <cr1901_modern1> mithro: I believe JTAG support is Spartan6 only. Although I guess that's not a problem for you. lm32_config.v has the JTAG parameters.

07:15 <mithro> cr1901_modern1: what about on the or1k? I know their FuseSoC version has support...

07:25 <cr1901_modern1> mithro: I am sadly unsure :(

08:50 <GitHub77> [artiq] sbourdeauducq pushed 1 new commit to release-1: https://git.io/vwL4A

08:50 <GitHub77> artiq/release-1 3984684 Sebastien Bourdeauducq: Revert "environment,worker: remove enable_processors"...

09:30 <rjo> mithro: jtaguart in my misoc repo. no jtag for the cpus that i know of. there are fragments for the older or1000 in openocd though.

10:21 <mithro> rjo: you mean the jtaguart branch?

10:22 <mithro> rjo: Does openocd git support it "out of the box"?

10:28 <mithro> oh - I see, that is what the .cfg file is for

10:29 <rjo> yes

10:31 <rjo> it is a somewhat uncommon implementation as it is synchronous and blocks the device. was more a proof of concept at that time and a quick hack to free up the other uart.

11:16 <mithro> rjo: Well, I get something which kind of looks like output but is corrupted in a lot of ways (looks like FIFO under/overflow)

11:20 <mithro> rjo: http://paste.ubuntu.com/15870029/

11:31 <GitHub41> [artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vwL2K

11:31 <GitHub41> artiq/master caf7745 Sebastien Bourdeauducq: environment: refactor

11:43 <bb-m-labs> build #350 of artiq-kc705-nist_clock is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-kc705-nist_clock/builds/350

11:49 <bb-m-labs> build #125 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/125

11:50 <bb-m-labs> build #611 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/611

12:07 <bb-m-labs> build #351 of artiq-kc705-nist_clock is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-kc705-nist_clock/builds/351

12:11 <rjo> mithro: dunno. haven't played with it since then.

12:12 <bb-m-labs> build #126 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/126

12:12 <mithro> rjo: I'm currently actually trying to get the adv_dbg_if for mor1k up and running which seems to include a jtag serial port in it too, so will see how that goes before coming back to that

12:13 <bb-m-labs> build #612 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/612

13:37 <GitHub142> [artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vwLKE

13:37 <GitHub142> artiq/master 0cf6df1 Sebastien Bourdeauducq: master/experiments: log more details about experiment name conflicts

13:37 <GitHub117> [artiq] sbourdeauducq pushed 1 new commit to release-1: https://git.io/vwLKu

13:37 <GitHub117> artiq/release-1 ed17972 Sebastien Bourdeauducq: master/experiments: log more details about experiment name conflicts

13:48 <bb-m-labs> build #352 of artiq-kc705-nist_clock is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-kc705-nist_clock/builds/352

13:53 <bb-m-labs> build #127 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/127

13:54 <bb-m-labs> build #613 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/613

14:41 <mithro> well, I have a very hacky version of this kind of working....

16:44 <mithro> I have GDB connected to the or1k running in MiSoC!

17:11 <rjo> mithro: good. that's useful.