02:04 <GitHub-m-labs> [misoc] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/misoc/commit/7f63aff531a62aa5979a115e06c2ffc39d405588

02:04 <GitHub-m-labs> misoc/master 7f63aff Sebastien Bourdeauducq: cpu_interface: define consts with group lengths in Rust

02:09 <bb-m-labs> build #434 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/434

02:27 <GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/560889372f3dc0e5ad8bca42dea78bed6e94f376

02:27 <GitHub-m-labs> artiq/master 5608893 Sebastien Bourdeauducq: firmware: grabber support

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

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

03:17 <whitequark> cjbe: fixed, sorry about that

03:17 <GitHub-m-labs> [artiq] whitequark pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/2e09307d8d4b0b60294f5c72c202d3021f86d3fa

03:17 <GitHub-m-labs> artiq/master 2e09307 whitequark: firmware: use writeln instead of write in UART logger.

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

04:04 <bb-m-labs> build #2399 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2399 blamelist: whitequark <whitequark@whitequark.org>

07:31 <bb-m-labs> build #1584 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1584

09:00 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1016: At some point the asyncio is calling:... https://github.com/m-labs/artiq/issues/1016#issuecomment-392704472

09:05 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1016: i.e. asyncio is asking for a stream UDP (proto=17) address, which is obviously not possible. Without the patch, the error is masked, as ``_ipaddr_info`` disregards the type/proto combination. https://github.com/m-labs/artiq/issues/1016#issuecomment-392706068

09:15 <sb0> wtf: https://hastebin.com/axarivuteg.rb

09:22 <tpw_rules> hey whitequark

09:32 <sb0> https://bugs.python.org/issue21327

09:52 <GitHub-m-labs> [artiq] sbourdeauducq closed issue #1016: _ipaddr_info monkey_patch breaks UDP https://github.com/m-labs/artiq/issues/1016

10:08 <GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to release-3: https://github.com/m-labs/artiq/commit/1afcf8b459c180400b0200bced6b90adfde80b4d

10:08 <GitHub-m-labs> artiq/release-3 1afcf8b Sebastien Bourdeauducq: monkey_patches: work around Python issue 33678. Closes #1016

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

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

11:09 <tpw_rules> so i'm trying to convert a real basic design to verilog and i must be missing something. https://pastebin.com/gcM7uGZd is this usage not supported yet? i just kinda extrapolated from reading the source

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

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

11:26 <sb0> tpw_rules, set(m.led) isn't doing what you think it does

11:26 <sb0> tpw_rules, {m.led}

11:27 <tpw_rules> guh you're right. that always catches me with bytes()

11:27 <tpw_rules> s/that/a similar thing/

13:59 <GitHub69> [smoltcp] dlrobertson opened issue #222: [RFC]: Break out the core modules into cargo workspaces https://github.com/m-labs/smoltcp/issues/222

14:01 <GitHub138> [smoltcp] whitequark commented on issue #222: I personally don't think this is worth it. The compilation time of smoltcp is less than a second last time I checked, there is no global data involved, and all functionality that can bloat unrelated codepaths is gated with feature flags.... https://github.com/m-labs/smoltcp/issues/222#issuecomment-392787569

14:19 <GitHub146> [smoltcp] dlrobertson commented on issue #222: `iface` is compiled regardless. Yes you can disable all the socket types, but IIRC `Interface` etc is still compiled in.... https://github.com/m-labs/smoltcp/issues/222#issuecomment-392793688

14:21 <GitHub16> [smoltcp] dlrobertson commented on issue #222: Primarily your comment [here](https://github.com/m-labs/smoltcp/issues/54#issuecomment-339172433) made me think this could be a possibility now.... https://github.com/m-labs/smoltcp/issues/222#issuecomment-392794567

14:23 <sb0> whitequark, any progress on fixing the compiler?

14:37 <GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/8fd57e6ccb6e5070d3dc988a9d5550b295621d72

14:37 <GitHub-m-labs> artiq/master 8fd57e6 Sebastien Bourdeauducq: kasli_tester: add Sampler and Zotino support

14:53 <tpw_rules> https://github.com/tpwrules/pigen is this useful to anybody

14:54 <GitHub171> [smoltcp] batonius commented on issue #219: Looks good to me, I would only suggest adding a trivial caching mechanism, for example, to remember the last IP and the path found and to check each query against it first before doing a full search, but that could be done later as a separate PR. https://github.com/m-labs/smoltcp/pull/219#issuecomment-392806552

14:54 <GitHub118> [smoltcp] batonius commented on issue #219: Looks good to me, I would only suggest adding a trivial caching mechanism, for example, to store the last IP and the path found and to check each query against it first before doing a full search, but that could be done later as a separate PR. https://github.com/m-labs/smoltcp/pull/219#issuecomment-392806552

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

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

15:55 <whitequark> sb0: yes

15:55 <whitequark> I'm comparing the new implementation to the old one now

16:02 <tpw_rules> whitequark: https://github.com/tpwrules/pigen this was today's little project. i'm not sure if it fits your vision

16:19 <whitequark> that's just myhdl

16:19 <whitequark> I really don't like the magic `is` and `next_state =` though

16:20 <tpw_rules> oh it is?

16:22 <tpw_rules> i more just wanted a way to use python if statements

16:22 <tpw_rules> and i think .eq is really really clunky. but that's me

16:25 <tpw_rules> maybe we can discuss design reasoning cause i don't understand why it works like it does

16:30 <whitequark> elaborate?

16:31 <whitequark> the main bad thing about .eq is how it changes meaning based on whether it's in comb or sync and so you have the NextValue hack in FSMs

16:31 <tpw_rules> like i don't understand the division between comb and sync if sync logic also has a lot of comb in it

16:31 <whitequark> it's the other way around

16:32 <tpw_rules> i mean in the code

16:32 <whitequark> comb is for combinatorial assignment to signals, sync is for synchronous assignment -with a specific clock domain-

16:32 <whitequark> (but it uses sys as the default domain)

16:33 <sb0> .eq() can be replaced with context managers and "signal.next = ..."

16:34 <sb0> while keeping the same principles, no touching the Python AST

16:34 <tpw_rules> i guess i don't really understand the difference between a python variable and a Signal. like x = y + 1 vs x.eq(y+1)

16:36 <whitequark> a python variable is just a variable in the interpreter, a Signal corresponds to a wire or reg in the generated HDL

16:36 <tpw_rules> if x and y are Signals, is x & y a Signal too? or is it just some expression type

16:36 <whitequark> it is a signal

16:36 <whitequark> this sugar is described in the manual here: https://m-labs.hk/migen/manual/fhdl.html#operators

16:37 <tpw_rules> so it's not a signal it's an operator

16:37 <whitequark> right, s/signal/migen value/

16:37 <whitequark> signals are migen values, operators are too

16:37 <whitequark> x & y translates to x & y in HDL

16:38 <tpw_rules> what if you say z = x & y; v.eq(z & w). does that come out v = (x & y) & w?

16:39 <whitequark> assign v = (x & y) & w;

16:39 <whitequark> try it

16:39 <whitequark> https://m-labs.hk/migen/manual/fhdl.html#conversion-for-synthesis

16:40 <tpw_rules> i guess the distinction between Signals and python vars is the difference between migen and myhdl?

16:40 <whitequark> that's a strange way to put it

16:40 <whitequark> if you write something like

16:41 <whitequark> z = x & y; v.eq(z & w); t.eq(z & q);

16:41 <whitequark> you get two assign statements like

16:41 <whitequark> assign v = (x & y) & w; assign t = (x & y) & q;

16:41 <tpw_rules> well yes.

16:41 <whitequark> if you make z a signal then you'll have assign z and then z will be used instead of duplicating x & y everywhere.

16:42 <whitequark> it doens't make a semantic difference

16:44 <GitHub78> [smoltcp] whitequark commented on issue #222: > iface is compiled regardless. Yes you can disable all the socket types, but IIRC Interface etc is still compiled in.... https://github.com/m-labs/smoltcp/issues/222#issuecomment-392846443

16:48 <tpw_rules> you prefer the NextValue hack to using `is`?

16:49 <GitHub-m-labs> [artiq] jordens commented on issue #1016: thanks! https://github.com/m-labs/artiq/issues/1016#issuecomment-392848795

16:49 <GitHub43> [smoltcp] whitequark commented on pull request #219 ced197f: I think `^` is the default operator. https://github.com/m-labs/smoltcp/pull/219#discussion_r191495133

16:49 <GitHub80> [smoltcp] whitequark commented on pull request #219 ced197f: This should just be `update`. https://github.com/m-labs/smoltcp/pull/219#discussion_r191495961

16:49 <GitHub75> [smoltcp] whitequark commented on pull request #219 ced197f: This adds a default IPv4 *route* (i.e. a single route is added), not *gateway* (which would imply that other routes might use the same gateway if none is specified). Also docstring and IPv6 needs to be changed. https://github.com/m-labs/smoltcp/pull/219#discussion_r191496271

16:49 <GitHub57> [smoltcp] whitequark commented on pull request #219 ced197f: Nit: `[None; 1]` here and `[None; 2]` in the other example as a demonstration that you don't have to list every item explicitly. https://github.com/m-labs/smoltcp/pull/219#discussion_r191495400

16:49 <GitHub103> [smoltcp] whitequark commented on pull request #219 ced197f: I think this can be an `assert!` or even `debug_assert!` since this is not a user-accessible API. https://github.com/m-labs/smoltcp/pull/219#discussion_r191496540

16:50 <tpw_rules> why not split FSMs into comb and sync too

16:50 <tpw_rules> so you're like fsm.comb["READY"] += something

17:01 <tpw_rules> i think i'm going to try that context manager idea for the main code though

17:01 <tpw_rules> for migen itself*

20:49 <tpw_rules> https://github.com/tpwrules/migen/tree/context-manager

20:50 <tpw_rules> context manager support. it needs a look over and some documentation but hopefully it fits with migen

20:50 <tpw_rules> i'm gonna tweak my pigen thing to work with this also in case that's interesting

20:59 <jbqubit> Running latest master (4.0.dev+1085.g8fd57e6c) on Sayma. Getting repeated lockups of coms uP. Is anybody else seeing this?

21:09 <jbqubit> https://hastebin.com/udolekayeh.rb

21:26 <jbqubit> Also see on serial terminal... WARN(runtime::session): wrong magic from *:0

22:44 <jbqubit> When running the same program as startup/idle kernel it runs without error.

22:52 <jbqubit> But the idle kernel completes instantly with no LED flashing. Is the idle kernel timebase is broken? 1 sec delays are <<< 1 sec

23:10 <jbqubit> The startup kernel also completes instantly. The startup kernel I've loaded ought to run for 40 seconds.

23:28 <jbqubit> Unrelated issue... $ artiq_coreconfig Traceback (most recent call last): File "/home/britton/.local/bin/artiq_coreconfig", line 11, in <module> load_entry_point('artiq', 'console_scripts', 'artiq_coreconfig')() File "/home/britton/miniconda3/envs/artiq-dev/lib/python3.5/site-packages/pkg_resources/__init__.py", line 561, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/home/britton/

23:33 <jbqubit> scratch [19:28]