00:06 <stekern> sb0: I think so, but I can check it tomorrow morning (got to sleep now)

02:48 <rjo> ysionneau: yes. i have hidapi (zyp's dll) working on a win32 machine. i went from cffi to ctypes because i hate writing C inside python strings and the compilation cache with its temporary files.

02:49 <rjo> ysionneau: i gave hidapi on wow64 a try a few days ago for another project but forgot that i had 64 bit python on there.

02:51 <rjo> sb0: yes. i found the same videos. funny stuff. never seen before. complete welds like pipesor even sheets from edge to edge looks impossible.

02:53 <rjo> sb0: regarding your DIY ion trap: the easy path would be to first build a paul trap for dust or spores (no laser needed, just an audio amp and a resonator). and then go for a buffer gas cooled ion trap. they are much simpler to manage and do not require uhv.

02:55 <rjo> ysionneau: compiling hidapi.dll with whatever compiler toolchain comes with the respective windows python distribution (for cffi, weave, cython etc) sounds doable.

02:59 <rjo> ysionneau: re uart. i believe the current serial code in comm_serial comes from my re-implementation of what flterm does. there are funny things (very funny...) you have to do for special/non-standard baud rates that i did not bother implementing.

03:29 <kristianpaul> hmm is there an archived wiki.milkymist.org somewhere?..

03:34 <kristianpaul> and rtems wiki is down.. :sadpanda:

06:17 <GitHub73> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/-TYflA

06:17 <GitHub73> artiq/master b736c30 Sebastien Bourdeauducq: coredevice/core: core_com -> comm

06:33 <sb0> kristianpaul, http://m-labs.hk/milkymist-wiki/wiki.html

06:56 <GitHub111> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/rWA1Zw

06:56 <GitHub111> artiq/master e01050b Sebastien Bourdeauducq: transforms/inline: fix default values of positional args

09:24 <ysionneau> morning

09:25 <ysionneau> 03:49 < rjo> ysionneau: i gave hidapi on wow64 a try a few days ago for another project but forgot that i had 64 bit python on < cffi documentation states that if you are on win64 it assumes you have 64 bits python installed so I guess it's fine (that's what I did)

09:25 <ysionneau> and did it work on your 64 bit win ?

09:26 <ysionneau> 03:55 < rjo> ysionneau: compiling hidapi.dll with whatever compiler toolchain comes with the respective windows python < so far I compiled my hidapi.dll with Visual Studio, and it was fairly easy

17:05 <rjo> morning!

17:06 <rjo> ysionneau: what i tried could not have worked. i didn't have a chance to try with a 64 bit dll.

17:06 <ysionneau> rjo: hi, so you don't use cffi anymore, you use ctype now ?

17:06 <rjo> ysionneau: yes. but for deployment visual studio is a pita.

17:06 <ysionneau> so if you modified your lda.py could you send me the new one?

17:07 <rjo> ysionneau: yes. meeting now.

17:08 <ysionneau> ok

17:08 <ysionneau> is the ctype version working fine on linux+windows?

17:08 <ysionneau> cause so far I don't see any hope of having cffi working reliably on win 32 & 64

17:08 <ysionneau> it seems to be a real mess

17:08 <rjo> http://paste.debian.net/132670/

17:09 <ysionneau> or maybe without verify() and just ABI compatibility using the "dlopen()" stuff

17:09 <ysionneau> so with no on-the-fly compilation

17:09 <rjo> i didn't try linux. but my other project works fine with pretty much the same code and hidapi on linux.

17:09 <rjo> use ctypes. no compilation. ;)

17:09 <ysionneau> it seems a bit more verbose but it has the advantage of not having the big C code strings and if it works ... :)

17:10 <ysionneau> thanks for the paste!

17:10 <ysionneau> I tried to compile cffi with mingw32, it didn't work...

17:10 <ysionneau> by doing stuff like python setup.py --compiler=mingw32

17:11 <ysionneau> it chokes on some visual studio specific inline-assembly syntax

17:11 <ysionneau> I guess I'm just losing my time by digging in the cffi direction

17:11 <ysionneau> it's too bad because it works really well on Linux

18:03 <rjo> ysionneau: the ctypes version is even shorter than the cffi one. you have to write the signatures in both.

18:03 <rjo> ysionneau: but anaconda comes with a clean and working cffi

18:08 <rjo> i guess i never really saw an edvantage of cffi over ctypes.

18:09 <rjo> ysionneau: oh. there is a hid_init missing in that __main__.

18:24 <ysionneau> hid_init is not mandatory I think

18:37 <rjo_> ysionneau: ok. good to know.

20:40 <GitHub157> [artiq] sbourdeauducq pushed 3 new commits to master: http://git.io/OwxESg

20:40 <GitHub157> artiq/master 1780759 Sebastien Bourdeauducq: dds: phase control (mostly untested)

20:40 <GitHub157> artiq/master 96720d2 Sebastien Bourdeauducq: examples: remove compiler_test

20:40 <GitHub157> artiq/master dfd779c Sebastien Bourdeauducq: core: add underflow recovery function

20:49 <GitHub69> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/uJqwLw

20:49 <GitHub69> artiq/master 914bdd9 Sebastien Bourdeauducq: runtime: use booleans in syscalls

20:53 <sb0> davidc__, have you tried again to fix the migen simulation comb loop bug?

20:54 <davidc__> sb0: my fix works perfectly

20:54 <davidc__> sb0: you just think its ugly :)

20:54 <davidc__> so I still use that fix

20:54 <sb0> it makes the generated verilog unreadable, which makes metaprogramming errors difficult to investigate

20:55 <davidc__> sb0: I might go back and take a stab at a cleaner one at some point

20:55 <davidc__> but my todo queue is so long these days that I'm not sure when that will be

20:56 <sb0> transforming the comb statements into something similar to SSA form sounds like a much better fix

20:56 <sb0> also, that transform might prove useful when developing direct FHDL-to-netlist synthesis

20:59 <davidc__> sb0: oh, for sure. Its interesting + has lots of applications

21:00 <davidc__> sb0: but I have literally zero time these days; and writing a full SSA transform backend for migen sounds like a bit more than an evening or two's work

21:01 <sb0> not backend - transform

21:01 <rjo> sb0: back in .hk? i had a look at nr21. the vw ice cream looks good ;)

21:01 <sb0> you can leave the backend itself as it is. just don't feed problematic comb statements to it ;)

21:02 <davidc__> heh. I mean, one could just fix iverilog

21:02 <davidc__> but that code makes vim look like a paragon of clean coding values

21:03 <sb0> is that a iverilog problem, or a verilog problem?

21:03 <davidc__> pretty sure its iverilog

21:03 <sb0> seems like that can happen with that event model... but not sure

21:03 <sb0> rjo, Monday. still in SF for a few days.

21:03 <rjo> sb0: did staring at llvm ir make you like ssa so much?

21:05 <sb0> re. nr21, here are the presentation they did for the mixxeo design http://m-labs.hk/design/20131210_LEK_Presentation_modified.pdf http://m-labs.hk/design/20131212_LEK_Additional_assembly_information.pdf

21:08 <sb0> I should still try to manufacture that... incompetent, annoying and/or uninterested machine shops and part obsolescence not helping

21:12 <davidc__> sb0: I seem to recall it was in one of those "undefined" areas of the spec

21:18 <davidc__> sb0: but that people concluded that the only sane way to implement it was to coalesce events from the same comb block

21:54 <sb0> EDA design at its best again

22:22 <GitHub89> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/lRrXDw

22:22 <GitHub89> artiq/master 64866a0 Sebastien Bourdeauducq: pc_rpc: add init magic string

22:50 <rjo> sb0: nice. looks like they really gave it some thought.

23:30 <GitHub147> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/gSNNfw

23:30 <GitHub147> migen/master b87ad1a Florent Kermarrec: xilinx_vivado: use REM for comment on Windows