07:32 <FabM> Fully open-source toolchain for FPGA : http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/

07:38 <mithro> FabM: yeah - it's pretty awesome

07:38 <FabM> mithro: Ho yes !

07:40 <mithro> BTW - Incase not everyone has seen it, I wrote a tool to try and make vhdl + verilog formatting nicer in the similar vain to clang-format or go-format - https://github.com/mithro/hdl-pretty (It wraps emacs's vhdl/verilog modes)

07:41 <mithro> It's not great, but it's better than nothing, which seems to be where things are at the moment

07:48 <sb0> does someone have a new version of this hack? https://github.com/enjoy-digital/migen/commit/083ea643f2d54c17256f51b052068ffb3a0e2a93

07:49 <sb0> also, i think we really should ditch iverilog for most purposes, and do something like this: https://gist.github.com/sbourdeauducq/93bc62ee51c3b9cbfcc6

07:51 <key2> sb0: in what case do you use iverilog vs verilator ?

08:01 <sb0> key2, please search the source to find out.

08:28 <cr1901_modern> Who wants to write a Python verilog compiler :P?

08:31 <whitequark> use yosys

08:33 <sb0> I wonder what part of the yosys development time was spent implementing stupid verilog idiosyncrasies, and what part of those idiosyncrasies is implemented correctly

09:00 <whitequark> sb0: look what I have completely accidentally found http://www.aliexpress.com/item/Electronic-Expansion-Valve-for-air-conditioning-refrigeration-system/32240001947.html

09:00 <whitequark> look at Cv

09:00 <whitequark> like the one with Cv 0.12

09:01 <whitequark> this is basically the same as my uber-expensive sealed swagelok needle valve (used: $80), except it's $20 new, and it's actuated electronically

09:01 <whitequark> you can use it to add precise amounts of gases to the chamber

09:04 <whitequark> not stainless, so less chemically resistant. mainly you can't use ammonia with it

09:04 <whitequark> but still, very interesting

12:25 <travis-ci> fallen/artiq#219 (sync_struct_test - 8afd738 : Yann Sionneau): The build passed.

12:25 <travis-ci> Build details : http://travis-ci.org/fallen/artiq/builds/64902206

12:26 <mithro> fallen is really close to failed :P

12:26 <ysionneau> hum?

12:27 <ysionneau> ah!

12:27 <ysionneau> yes =)

15:37 <ysionneau> sb0: if unittest only runs one thread, then I guess we can use atexit() to just close the even loop.

15:37 <ysionneau> event*

15:43 <ysionneau> dunno if my install is wrong or something but I get his when trying to run artiq_gui: http://pastebin.com/zvY8XnKQ

15:50 <sb0> yes https://github.com/pyqtgraph/pyqtgraph/issues/172

15:51 <ysionneau> seems it's wrong since day 1 then

15:53 <ysionneau> thx

16:14 <sb0> also it's kinda annoying they take time to merge this trivial fix

16:52 <travis-ci> fallen/artiq#221 (gui - 8c3cdd8 : Yann Sionneau): The build passed.

16:52 <travis-ci> Build details : http://travis-ci.org/fallen/artiq/builds/64941625

17:23 <rjo> ysionneau: i think the asyncio unittest pattern of explicitly creating and destroying the loop on setUp/tearDown is the correct one.

18:36 <ysionneau> rjo: ok!

18:50 <ysionneau> in asyncio's unittests, they seem to have no rule about that, sometimes they create the loop in setUp, but then they close it at the end of the test (no tearDown), or sometimes they don't even close it

18:50 <ysionneau> or sometimes they create the loop at the beginning of the test

19:04 <rjo> they might be testing that very behavior...

19:04 <rjo> ysionneau: there is also https://github.com/Martiusweb/asynctest if you really want/need to dive into it.

19:06 <rjo> https://github.com/python/asyncio/wiki/ThirdParty#unit-testing

19:17 <rjo> ysionneau: i think you actually want to do new_event_loop()

23:41 <cr1901_modern> ysionneau: Sorry I wasn't around today. I just didn't have the energy/time to work on the mibuild file