01:41 <sb0> rjo, so just "from artiq import *" instead of "from artiq.language.std import *" ?

01:42 <sb0> rjo, re. capitalization - it's also NumPy but "import numpy", and SciPy/"import scipy"

01:54 <sb0> http://www.wsj.com/video/aerial-drone-captures-scale-of-hong-kong-protests/76AA792E-7AB9-4D2B-88BB-E9B5F9D707EC.html < this is a few blocks from my place. it goes on for kilometers...

02:35 <rjo> sb0: yeah. i would just flatten the namespace like that and elevate all exports to the top.

02:36 <rjo> sb0: true. but their repositories are lower case.

02:40 <rjo> sb0: they don't seem to be skilled demonstrators. more like regular party people. no posters, no slogans... (or at few)

02:40 <rjo> ;)

02:45 <sb0> the demonstrations are actually the most organized and clean I've ever seen. there are people to supply food/water/masks, pick up trash, provide first aid, etc.

02:46 <sb0> it's even better organized than many music festivals I'd say :)

06:37 <rjo> sb0: i was pondering how to best write a migen transform that automatically and recursively extracts submodules (that have been annotated by their ios), converts them into Instances and exports them as verilog files. but i got stuck because i need a transformer that runs on modules and not on fragments. any pointers or hints?

06:38 <rjo> such a transform would be nice for quickly and roughly checking the individual modules contributions to resource usage during synthesis.

06:53 <sb0> hmm, yes

06:54 <sb0> it could unclutter the namespaces a little, too

06:55 <sb0> first, I guess the Module class has to pass hierarchy information into the Fragment somehow, which it discards atm

06:56 <sb0> another problem is that when splitting into modules, the verilog ports are not transparent

06:58 <sb0> and how would you handle one module that has "comb += x.eq(1)", and then one or several other modules that have code such as "comb += If(y, x.eq(0))"?

06:59 <sb0> Migen permits that, with semantics that depend on the order of those statements (which in the case of submodules, would be determined by the order the submodules are added)

07:00 <sb0> the verilog converter would do something like "always @(*) begin x <= 1; if(y) x <= 0; end"

07:01 <sb0> and those two statements are not easy to put into different modules

07:01 <sb0> especially with the various idiosyncrasies that Verilog has regarding module connections

07:02 <sb0> I guess those cases should be detected, and the respective modules merged

08:46 <GitHub52> [ARTIQ] sbourdeauducq pushed 4 new commits to master: http://git.io/h5jZBg

08:46 <GitHub52> ARTIQ/master 5099643 Sebastien Bourdeauducq: devices/rtio_core: rename RTIOCounter to RTIOIn and document

08:46 <GitHub52> ARTIQ/master 05d8dde Sebastien Bourdeauducq: language/core: pass docstrings through kernel decorator

08:46 <GitHub52> ARTIQ/master c95f5bd Sebastien Bourdeauducq: transforms/inline: strip docstrings

09:41 <GitHub189> [artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/nPK-eg

09:41 <GitHub189> artiq/master cb036a3 Sebastien Bourdeauducq: devices/dds_core: document

09:41 <GitHub189> artiq/master 5ac42e4 Sebastien Bourdeauducq: rename artiq.language.std -> artiq

10:13 <GitHub52> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/MgwbCw

10:13 <GitHub52> artiq/master 73d0a84 Sebastien Bourdeauducq: doc: various cleanups

11:34 <GitHub103> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/gXZ3IQ

11:34 <GitHub103> artiq/master 76fed11 Sebastien Bourdeauducq: rtio: raise RTIOSequenceError exceptions when events are not submitted in-order

14:58 <rjo> sb0: yes. i didn't think of multiple assignments. but in this case at least the signal would be an output from the module and synthesis should fail nicely.

14:59 <rjo> sb0: but it does look more complicated than i expected. i'll stash the idea for now.

15:45 <sb0> rjo, have you used https://libgit2.github.com and know what happens when you are accessing a repository while another process modifies it (e.g. while doing a "git push" to it)?

15:56 <ysionneau> not sure about full compatibility of libgit2 and the official git

16:03 <sb0> according to #libgit2 there should be no problem ...

16:04 <ysionneau> ok, let's hope so

16:04 <ysionneau> what do you wanna do with libgit2 ?

16:06 <sb0> manage experiment code/parameters histories in artiq

16:09 <ysionneau> you want to avoid users to use git CLI directly?

16:12 <sb0> no, but the system will probably need to e.g. retrieve code at a particular revision before running it, or just know what the latest revision ID is to associate it with the results/logs

16:27 <ysionneau> ok

17:54 <rjo> sb0: i always believed git did locking.

17:55 <rjo> sb0: what about GitPython?

17:56 <rjo> sb0: but i have never really used libgit2. certainly not explored its limits.

18:43 <rjo> sb0: oh. pygit2 looks nicer than GitPython.