03:22 <GitHub63> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/0nq8HA

03:22 <GitHub63> artiq/master b749c8e Yann Sionneau: doc/manual/installing: small cleanups and more details

03:49 <rjo> sb0: you tasked ysionneau to write docs?

03:53 <rjo> ysionneau: welcome to artiq by the way!

03:57 <sb0> yes

03:57 <sb0> :)

03:58 <sb0> btw regarding distribution dependence, don't we want the master to integrate with some startup system (systemd, init, etc.)?

03:58 <rjo> ysionneau/sb0: a few months ago i attempted the llvm/llvmpy installation on cygwin/mingw/windows and got pretty far (llvm compiled and installed). there were no particularly obvious roadblocks but it seemed to be difficult to find a tuple of versions that works well.

03:59 <sb0> a llvmpy/llvm tuple of versions?

04:00 <rjo> sb0: maybe. but that is not so difficult. also, given that there is always quite some manual work in the lab to do experiments, starting the master manually is not much added work.

04:00 <rjo> more the tuple of gcc/mingw and cygwin

04:01 <sb0> I've been thinking about replacing llvmpy with a minimal version of it. we don't use that much. it's barely more than the very nice 'kaleidoscope' tutorial, for which there are C++ and Python versions. it can't be that hard to just redo a small binding with those features...

04:01 <sb0> though we might end up needing more, e.g. to implement a backtrace system to pinpoint the source of exceptions in compiled python code

04:02 <rjo> sb0: that sounds like porting just barely enough of llvmpy to llvm 3.5 might be just as much work as writing it anew.

04:03 <sb0> those APIs we actually need have been consistent across several versions of LLVM afaict

04:03 <sb0> if we only bind those, this can also alleviate potential future version incompatibilities

04:04 <rjo> sb0: maybe. my experience with wrapping c++ apis for python have been about two orders of magnitude more painful than wrapping c apis.

04:05 <rjo> sb0: do you know how or whether llvm plans to take care of llvmpy?

04:05 <rjo> sb0: didn't they still have their own version that came with 3.5?

04:06 <sb0> there is a different Python binding that comes with llvm, which looks in a pretty bad state

04:07 <rjo> yes. that one. do they say whether they will merge continuum.io/llvmpy back in?

04:08 <sb0> I haven't heard anything about that...

04:12 <sb0> and yes, C++ is evil. but there's a C binding too, which if done correctly could leave most C++ problems to LLVM developers...

04:12 <sb0> http://llvm.org/docs/doxygen/html/group__LLVMCCoreInstructionBuilder.html

04:13 <sb0> sounds quite straightforward to map that to artiq py2llvm

04:19 <sb0> of course, then the C/C++ interface can become the new chaos area unless the llvm devs keep it clean...

04:37 <sb0> https://github.com/wickedchicken/llvm-c-example/blob/master/fac.c

04:40 <sb0> compiles and works here without any problem

04:51 <sb0> also seems unaffected by the "slow JIT" bug we have with llvmpy for some reason

04:59 <rjo> sb0: sounds reasonable. cython or ctypes or cffi are all pretty reasonable.

05:00 <sb0> artiq doesn't use that much more than such functions so far

05:00 <rjo> sb0: unless keeping up with llvm or the need for other features makes it a PITA.

05:00 <sb0> at some point we'll need something to map or1k instruction address -> python statement

05:00 <sb0> so that exceptions can be traced

05:01 <sb0> that might require some more llvm features

05:02 <sb0> or we can just have the upper leve

05:02 <sb0> l compiler pass the python statement locations in the calls to the runtime exception_raise(), but that's more limited and messy

05:03 <sb0> especially as the runtime functions for e.g. rtio also call exception_raise(), so you'd need to pass that to rtio_* as well

05:04 <rjo> sb0: might be fine to have exception tracing not that fine grained. maybe function-level would be enough.

05:06 <rjo> sb0: but the required functionality may turn out to be the same...

05:06 <rjo> gtg. see you.

07:40 <GitHub195> [misoc] sbourdeauducq pushed 3 new commits to master: http://git.io/jGfQJQ

07:40 <GitHub195> misoc/master 5e5f436 Florent Kermarrec: uart: split it and use dataflow...

07:40 <GitHub195> misoc/master 20528c6 Sebastien Bourdeauducq: mor1kx: sync

07:40 <GitHub195> misoc/master e53fb88 Sebastien Bourdeauducq: uart: minor cleanup and fix

08:20 <ysionneau> hello!

08:20 <ysionneau> < rjo> ysionneau: welcome to artiq by the way! < thanks :)

12:14 <GitHub179> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/bcmRlQ

12:14 <GitHub179> artiq/master 1c24a59 Sebastien Bourdeauducq: rtio: error recovery

16:23 <sb0> also, things that we do need (such as the returns_twice function attribute) are _not_ in llvmpy

16:23 <sb0> MEH

16:26 <sb0> exceptions sometimes crash right now because of that

16:38 <GitHub10> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/taYG0g

16:38 <GitHub10> artiq/master c659acb Sebastien Bourdeauducq: transforms/lower_time: fix time_to_cycles/cycles_to_time

16:44 <GitHub144> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/QMTV-w

16:44 <GitHub144> artiq/master e3ef077 Yann Sionneau: Fix module installation...

16:54 <GitHub126> [lm32] mwalle pushed 1 new commit to master: http://git.io/GuIm3A

16:54 <GitHub126> lm32/master 84b3e3c Michael Walle: convert the latex documention to rst...

21:07 <rjo> sb0: adding another ATTR_ does not seem too hard.