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