sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
cr1901 has quit [Ping timeout: 272 seconds]
cr1901 has joined #m-labs
fengling has joined #m-labs
<sb0> whitequark, where is it?
<sb0> and how is that example working? I don't see any rpc type annotation there
<whitequark> sb0: where is what?
<whitequark> as for type annotation, yes, I hardcoded the return type to whatever that function returns in embedding.py
<sb0> whitequark, what you are asking me an opinion about. or do you just want a first opinion on what should be done?
<whitequark> sb0: the form of the type annotation, which is not currently done at all
<whitequark> well, there are mainly two possibilities
<sb0> whitequark, can you postpone this until the critical parts (see issue) are done?
<whitequark> ok, I have read your comment. sure
fengling has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
FabM has joined #m-labs
<ysionneau> Morning!
cr1901 has quit [Ping timeout: 250 seconds]
FabM has quit [Remote host closed the connection]
fengling has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
<GitHub24> [artiq] sbourdeauducq pushed 3 new commits to master: http://git.io/v3mfQ
<GitHub24> artiq/master 9772676 Sebastien Bourdeauducq: doc: cleanup shell prompts
<GitHub24> artiq/master d9d7466 Sebastien Bourdeauducq: doc: scheduling
<GitHub24> artiq/master af230f6 Sebastien Bourdeauducq: Merge branch 'master' of github.com:m-labs/artiq
<sb0> hi ysionneau
FabM has joined #m-labs
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#388 (master - af230f6 : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
attie has quit [Remote host closed the connection]
nengel has joined #m-labs
nengel is now known as attie
fengling has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
siruf has quit [Ping timeout: 260 seconds]
<sb0> why does python asyncion condition variables require locks?
<sb0> isn't the implicit locking from asyncio enough?
siruf has joined #m-labs
<sb0> e.g. as long as you don't yield in the middle of modifying a data structure related to the condition variable...
<sb0> i tried rebuilding the llvmlite package (which needs renaming, and new source), but ...
<ysionneau> arg sorry
<ysionneau> let me push it right away
<GitHub28> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/v3mxX
<GitHub28> artiq/new-py2llvm 22570af whitequark: LLVMIRGenerator: allocate less.
<GitHub129> [pythonparser] whitequark pushed 1 new commit to master: http://git.io/v3mxj
<GitHub129> pythonparser/master aee2f09 whitequark: source.Range: make hashable.
<GitHub151> [artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/v3mjn
<GitHub151> artiq/new-py2llvm 4f02f6e whitequark: compiler.types: make all hashable.
<GitHub151> artiq/new-py2llvm 8f510a4 whitequark: compiler.ir.Function: add loc field.
<GitHub46> [artiq] fallen pushed 1 new commit to master: http://git.io/v3YeG
<GitHub46> artiq/master 393576f Yann Sionneau: conda: add missing build.sh for llvmdev-or1k pkg
<whitequark> ysionneau: why -DCMAKE_BUILD_TYPE=Debug ?
<ysionneau> a mistake, I changed it but didn't commit --amend, fixing that
<whitequark> I would do -DCMAKE_BUILD_TYPE=Release or RelWithDebInfo
<whitequark> and enable assertions
<ysionneau> yes, I will put Rel + enable assertions, like in manual
<GitHub63> [artiq] fallen pushed 1 new commit to master: http://git.io/v3YJz
<GitHub63> artiq/master c57ce6d Yann Sionneau: conda: llvmdev should be built in Release mode with assertions enabled
<sb0> ysionneau, can you rebuild/reupload the llvmlite package?
<ysionneau> yes, it will take some time though
<ysionneau> I guess I should build linux-64 in priority?
<sb0> yeah, and then the other ones
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#389 (master - 393576f : Yann Sionneau): The build has errored.
travis-ci has left #m-labs [#m-labs]
<ysionneau> ok
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#390 (master - c57ce6d : Yann Sionneau): The build has errored.
travis-ci has left #m-labs [#m-labs]
<ysionneau> llvmlite-artiq has been uploaded for linux-64
<whitequark> \o/
<whitequark> which revision?
<ysionneau> c75ca3fb
<whitequark> ah, excellent.
<ysionneau> let's build for linux-32, should build way faster since I do that on a host and not a guest
<GitHub131> [artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/v3YyS
<GitHub131> artiq/new-py2llvm c63ec70 whitequark: LLVMIRGenerator: emit debug information.
<GitHub131> artiq/new-py2llvm 75532d1 whitequark: Display full core device backtraces.
<whitequark> ^ nonessential, yes, but I started that yesterday anyway and wanted to finish.
<ysionneau> really cool
<ysionneau> that is ... meaningful
<whitequark> oh? what do you mean?
<ysionneau> the error message plus location of the error
<whitequark> didn't it show that even with the old compiler?
<ysionneau> might be, I didn't play much with the compiler yet
<whitequark> have you seen other diagnostics yet? :]
<ysionneau> what does "y" refer to?
<whitequark> rpc is defined like: def rpc(x, y=[1, "x"])
<ysionneau> aaah ok
<ysionneau> this errors because array containing different types are not supported, right?
<whitequark> yeah
<ysionneau> really cool
<whitequark> I should also show where rpc is defined
<whitequark> ohh, I already do
<ysionneau> what does <synthesized> mean?
<whitequark> imagine if rpc was defined like this:
<whitequark> obj = [1, "x" + "y"]
<whitequark> def rpc(x, y=obj)
<whitequark> I don't have access to the code fragment from which obj was created. a single fragment doesn't even necessarily exist
<whitequark> so I take the value of obj and do something like repr() on it
<whitequark> except it's not just repr because I can highlight location of every single value in it, nested or not
<whitequark> in other words, I synthesize source out of this object
<ysionneau> ok you can retrieve some text code that would give the same object if you eval'ed() it?
<whitequark> no, I can't *retriveve* it
<whitequark> since I have no way to link obj to its initialier
<whitequark> and it could be even obj = []; obj.append(1); or something
<whitequark> what's worse, obj can have cycles in it
<ysionneau> arg
<whitequark> so I synthesize some kind of representation, solely for displaying a message
<whitequark> it's not always eval()able and I never try to eval it
<ysionneau> in the case you pointed earlier (with obj = [1, "x" + "y"]) what would this message be?
<ysionneau> y=[1, "xy"] ?
<whitequark> try it yourself? :] https://paste.debian.net/290932/
<GitHub27> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/v3Ov4
<GitHub27> artiq/new-py2llvm 261515d whitequark: compiler.targets.OR1KTarget: fix typo.
cr1901 has joined #m-labs
<GitHub59> [artiq] sbourdeauducq pushed 3 new commits to master: http://git.io/v3OOH
<GitHub59> artiq/master 52de631 Sebastien Bourdeauducq: test/scheduler: add repo_msg
<GitHub59> artiq/master b700f59 Sebastien Bourdeauducq: protocols/pc_rpc: add missing import
<GitHub59> artiq/master 47e3d03 Sebastien Bourdeauducq: Merge branch 'master' of github.com:m-labs/artiq
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#391 (master - 47e3d03 : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
<whitequark> hm, syscall
<whitequark> why even bother with a builtin? it's easier to allow calling arbitrary C functions
<whitequark> oh, github GCs git repositories more often now, it seems
<whitequark> fixed
<GitHub134> [misoc] whitequark pushed 1 new commit to master: http://git.io/v3OGT
<GitHub134> misoc/master abf9a58 whitequark: unwinder: update.
<sb0> shouldn't we put that under m-labs/libunwind, too?
<sb0> and what do you mean by "a builtin"?
<whitequark> well, right now, there's a special function "syscall" that magically knows the arguments
<whitequark> I want to make it so that you would add something like this to prelude: "ttl_set_o": types.TCFunction("ttl_set_o", [("num", types.TInt32()), ("state", types.TBool())])
<whitequark> the only difference from TFunction is that it doesn't need the environment argument
<whitequark> yes it is. its type depends on the value it is passed.
<sb0> would ttl_set_o be accessible when running the code in a python interpreter (ie without the compiler)?
<sb0> we may want a good software simulator at some point
<whitequark> put it in artiq.language.core, no ?
<whitequark> just like int64 and the rest
<sb0> TTLs are not "core language"
<sb0> neither are DDSes, or whatever device will need syscalls in the future
<whitequark> correction: import it, like int64 and the rest.
<whitequark> one global dispatch table less! isn't that great.
<whitequark> if you really want a single entry point, I could make it something like syscall.ttl_set_o instead, not a big deal
<sb0> so, basically, you could define python "functions" that get turned into unresolved symbols when compiled?
<whitequark> yes
<sb0> ok, sounds good
<sb0> then all the ttl stuff can go into artiq.coredevice.ttl, even better
<whitequark> yes
<whitequark> oh, you actually want it to always require the import, even when compiling
<sb0> I guess it should be possible to define something smart to do when the python interpreter attempts to call such a "function"
<sb0> (when/if we implement sw simulations later)
<whitequark> @syscall("ttl_set_o")
<whitequark> def ttl_set_o(num: types.TInt32(), value: types.TBool()):
<whitequark> raise NotImplementedError
<whitequark> looks ok?
<whitequark> actually, that's also a good solution for RPC return types. just use the types the compiler already uses.
<sb0> why do you need to specify "ttl_set_o" twice?
<whitequark> oh, point
<sb0> also, the "raise NotImplementedError". is that what gets executed when the function is called from the interpreter?
<whitequark> yes
<sb0> ok. i guess we could call into some global simulator there later.
<sb0> ysionneau, what's the latest status of pxi6733 tests?
<whitequark> sb0: how do you want artiq.language.types to look? e.g.:
<whitequark> types.None
<whitequark> types.TNone
<whitequark> types.bool
<whitequark> types.TBool
<whitequark> None and bool have the advantage of matching Python. TNone and TBool can be imported *
<sb0> why not use the Python types in annotations? doesn't work with lists?
<sb0> or other complex structures
<whitequark> range
<sb0> range?
<whitequark> with list you can sort of emulate it with one-element lists
<whitequark> well, APython ranges are polymorphic
<whitequark> range(int(width=32)), range(int(width=64)), range(float)
<sb0> range(float)? python doesn't support that
<ysionneau> sb0: last email I got from Kathie was on the 10th of June, the "multiple channels" still remains untested then
<whitequark> of course it does
<whitequark> wait
<ysionneau> I can ping her again to see if she's available
<whitequark> it doesn't
<whitequark> fuck.
<whitequark> anyway, you are otherwise correct, if it works with complex structures, it is at best by accident
imrehg has joined #m-labs
<ysionneau> sb0: I emailed her again
<sb0> whitequark, here's one example where we need .rodata lists https://github.com/m-labs/artiq/blob/master/artiq/language/scan.py#L49
<sb0> I'd use the T, then
<whitequark> sb0: that could be solved by providing a frozenlist
<whitequark> although that particular instance, in my opinion, should be solved by not sending lists around
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#391 (master - 47e3d03 : Sebastien Bourdeauducq): The build failed.
travis-ci has left #m-labs [#m-labs]
<sb0> ysionneau, can you package pygit2?
<ysionneau> sb0: yes
<GitHub98> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/v3OaN
<GitHub98> artiq/master 06badd1 Sebastien Bourdeauducq: scheduler: refactor, fix pipeline hazards
<GitHub136> [artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/v3OrW
<GitHub136> artiq/new-py2llvm f53a5ff whitequark: Remove syscall builtin.
<GitHub136> artiq/new-py2llvm b28a874 whitequark: Inferencer: range() does not accept a float argument.
cr1901_modern has joined #m-labs
ylamarre has joined #m-labs
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#392 (master - 06badd1 : Sebastien Bourdeauducq): The build is still failing.
travis-ci has left #m-labs [#m-labs]
aeris has quit [Read error: Connection reset by peer]
aeris has joined #m-labs
<GitHub26> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/v3OAb
<GitHub26> artiq/new-py2llvm 435559f whitequark: Allow type annotations on remotely called functions.
<whitequark> can now use it like this:
<whitequark> def foo(x) -> TList(TInt32): return [1,2,3]
ylamarre has quit [Quit: ylamarre]
imrehg has quit [Quit: Leaving]
<whitequark> sb0: look what happened :O https://i.imgur.com/7lp6TbF.png
<whitequark> are you *sure* you don't want backtraces to show C frames? I already have that information. the only thing I need to do is show it
<sb0> nice
<sb0> what additional info would the C frames bring?
<whitequark> um, show how it arrived at that point?
<whitequark> mind you, hardware faults also get raised as exceptions
<whitequark> so if something dereferences a null (or otherwise invalid) pointer, you automatically have the fault address and complete backtrace
<sb0> ah, are some frames missing from that backtrace? ie your python source is not just doing the syscall?
<whitequark> well, I filter out any frames that do not belong to Python source
<whitequark> (and the last frame is a bit special because it gets embedded directly into the exception)
<sb0> I'm not sure if the C frames bring any info to the end user or if they are just confusing
<whitequark> hrm
<sb0> show them in verbose/debug mode?
<whitequark> can be done.
<whitequark> where do I put the now_*, watchdog_* and rtio_* syscalls?
<whitequark> sb0: ^
<sb0> coredevice.core?
<sb0> where are they invoked anyway?
<whitequark> now_init: nowhere except lower_time
<whitequark> and now_save
<sb0> I mean, in your new compiler
<whitequark> nowhere right now
<whitequark> I'm not even sure what exactly they do
<sb0> now init/save are for maintainng continuity of time when multiple kernels are invoked
<sb0> ("smooth handover")
<whitequark> what does that lower into?
<sb0> another thing you should check your session.c changes didn't break, btw
<sb0> what do you mean "lower into"?
<sb0> the value of 'now' should be retrieved from now_init upon entering kernel mode, and passed to now_save just before leaving it
<whitequark> oh
<whitequark> it's not called anywhere in runtime or old compiler except in lower_time transform
<sb0> sure
<whitequark> oh, i see.
<whitequark> ok, watchdog?
<GitHub110> [artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/v33Nc
<GitHub110> artiq/new-py2llvm 67967b9 whitequark: ARTIQException: tell linecache where to look for runtime sources....
<GitHub110> artiq/new-py2llvm b6bc868 whitequark: Implement syscalls for the new compiler.
ylamarre has joined #m-labs
<GitHub140> [artiq] whitequark force-pushed new-py2llvm from 67967b9 to 62e6f8a: http://git.io/vmI6O
<GitHub140> artiq/new-py2llvm c72267e whitequark: Implement syscalls for the new compiler.
<GitHub140> artiq/new-py2llvm 4647651 whitequark: ARTIQException: tell linecache where to look for runtime sources....
<GitHub140> artiq/new-py2llvm 62e6f8a whitequark: compiler.embedding.Stitcher: refactor.
<whitequark> oh, now is not a variable
mumptai has joined #m-labs
<GitHub84> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/v3slE
<GitHub84> artiq/new-py2llvm 200330a whitequark: Remove parts of py2llvm that are implemented in the new compiler.
<whitequark> ok yes i see how that is supposed to work
<whitequark> 1/ how about making now a global variable in ksupport?
<whitequark> no context switches, one less thing in every function, etc
<whitequark> wait, "output function". did you inline EVERY call and unroll EVERY loop, or what?
<whitequark> ysionneau: can you please rebuild llvmlite?
<whitequark> I fucked up a rebase
<ysionneau> whitequark: ok, np
<ysionneau> whitequark: do I need to rebuild llvmdev also ?
<whitequark> no
ylamarre has quit [Quit: ylamarre]
<ysionneau> ok I've rebuilt it for linux-64, you can do conda update llvmlite-artiq
<GitHub124> [artiq] fallen pushed 1 new commit to master: http://git.io/v3s5X
<GitHub124> artiq/master 80e8928 Yann Sionneau: conda: llvmlite-artiq has been rebuilt with an updated version
<ysionneau> linux-32 also ok
<ysionneau> if llvmlite-artiq is going to get lots of commits, maybe we should put a tag on it, it would allow for conda packages to automatically generate the version number / build number (by using git describe --tags)
<ysionneau> because for now I need to increment manually the build number and do a commit in artiq repo
<whitequark> no, hopefully not
<whitequark> I *really* hope that has been the last
<ysionneau> ok
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#393 (master - 80e8928 : Yann Sionneau): The build has errored.
travis-ci has left #m-labs [#m-labs]
<ysionneau> why the hell does cmake put the .lib in lib/ but the .dll in bin/ (on Windows)
<whitequark> because .lib is only for development, and .dll is for distribution along with the binary
<whitequark> and, well, the default dll search path includes the directory of the executable
<ysionneau> humm ok but then pygit2 seems to not find the libgit2.dll
<ysionneau> I think it wants it to be in lib/
<ysionneau> or maybe I can just play with LIBGIT2 env variable to tell pygit2 where to find libgit2.dll ... but it feels weird to have the .dll in bin/
<whitequark> that's odd. even for .dll, on windows you link with lib/
<whitequark> unlike on unix where you link with .so directly
<ysionneau> ok maybe I misunderstood pygit2 error message then
<whitequark> basically, a .lib for a static library has the code, and .lib for a .dll has loads and loads of void f() { (void(*)())GetProcAddress(NULL, "f")(); }
<whitequark> since Windows doesn't have a dynamic linker
<ysionneau> oh, ok
* ysionneau didn't know that
<whitequark> (that's not exactly what happens, but it's close enough)
<ysionneau> hum I get an ImportError when building pygit2, raised by cffi "DLL load failed"
<ysionneau> I think it's just my LIBGIT2 variable being wrong.
<ysionneau> let's fix that
<whitequark> oh. that's easy. pygit2 doesn't actually link with the .lib
<whitequark> so you probably have to point LIBGIT2 to bin/.
<ysionneau> yep, I'm trying that
<ysionneau> alright now I get LINK: fatal error LNK1181 cannot open input file "git2.lib" -_-
<whitequark> lol what
<ysionneau> let's try some mix of LIBGIT2 and LIBGIT2_LIB
<ysionneau> I get http://pastebin.com/9utBUGvK (nice url with BUG)
<ysionneau> and the git2.lib is actually in envs\_build\lib
<whitequark> pygit2's build process is batshit insane
<ysionneau> the path seems OK in the /LIBPATH
<ysionneau> but I'm no VS expert
<ysionneau> ah, maybe because it does not think git2.lib is a lib, maybe it thinks it's a normal object
<ysionneau> therefore it does not search for it in the LIBPATH stuff
<ysionneau> this is insane
<whitequark> no, that's unlikely
<whitequark> passing x.lib is how you usually link libraries with MSVC
<ysionneau> ok
<ysionneau> so it should search for it in the /LIBPATH shouldn't it?
<whitequark> I think so
<whitequark> you can strace it
<ysionneau> AH
<ysionneau> "libs" "lib"
<ysionneau> .
<ysionneau> ok, in fact it does build, but then the "verification" fails
cr1901_modern has quit [Quit: Leaving.]
<whitequark> sb0: decided against symbolizing C frames because that requires getting ksupport built with debug info
<whitequark> which bloats it immensely past 70K that it already is
<whitequark> and you've correctly mentioned that the python parts should not require any runtime binaries to be built
<whitequark> so it's not feasible to fetch it from the host.
<GitHub87> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/v3ZC8
<GitHub87> artiq/new-py2llvm 786fde8 whitequark: Unbreak tests.
<ysionneau> cffi seems unable to load some generated file for some reason: http://pastebin.com/LGiYp3sw
<ysionneau> but if I run ProcessMonitor while building, I see a "LoadImage" operation with the correct path and a result "SUCCESS" ... weird
<ysionneau> hummmm , maybe we should just use that .... http://www.lfd.uci.edu/~gohlke/pythonlibs/#pygit2
<ysionneau> windows is really a pain in the ass.
<ysionneau> mostly because lots of projects do not support it really well (less tested, less CI)
<ysionneau> pygit2 for instance has no CI on Windows and it's "less tested" (said a @ on their irc channel)
<ysionneau> so, calling it a day, this windows stuff is so annoying
<ysionneau> see you tomorrow
<cr1901> I've found that a lot of open source projects are not interested in supporting non-Unices (or even worse, non-Linuces).
<sb0> whitequark, keep the now init/save syscalls as they are.
<sb0> they are not just meddling with 'now'