<rjo>
we could tune the relevant sources that it considers and do the bitstream generation under coveralls. but you can remove the badge. afaict keeping the call does not hurt.
<rjo>
sb0: ^
cr1901 has quit [Ping timeout: 265 seconds]
cr1901 has joined #m-labs
<whitequark>
and session.c also has different algorithms than comm_generic.py... meh
<whitequark>
(looking at synchronization code)
cr1901 has quit [Ping timeout: 265 seconds]
cr1901 has joined #m-labs
fengling has joined #m-labs
<sb0>
whitequark, from a user perspective, cleaning up/optimizing this code is *much* lower priority than getting travis-ci and packages to work again after the llvmlite rename, or getting UDP to work in the GUI on windows
<whitequark>
well, I need some of it to add strings, and either way, I'm almost done
mumptai has joined #m-labs
<GitHub175>
[misoc] whitequark pushed 1 new commit to master: http://git.io/v3eNA
<sb0>
so, if you don't detect the host disconnecting, how do you know when to run the idle kernel?
<sb0>
oh
<whitequark>
:p
<sb0>
well, sure, that will work
<whitequark>
(typical annoying way) which is?
<sb0>
but the point was checking that all those changes you made to session.c don't introduce regressions wrt the idle experiment NORMAL startup, not after getting it to run by hacking the runtime
<sb0>
this happened with ethernet before, the problem was it didn't had enough memory
<sb0>
instead of printing an error or warning message, it behaves in the most obscure and painful to debug way
<sb0>
and please do not debug ppp now, the compiler is very late already
<sb0>
and ppp is purely optional.
<whitequark>
wasn't planning to
<sb0>
you can test the idle experiment with buggy ppp, though
<whitequark>
speaking of the idle experiment, I don't see why it would not work. I mean, it works when session_end is called, and I haven't changed *that*
<sb0>
bugs are smart.
<GitHub115>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/v3vOW
<sb0>
I'm also concerned about the removal of the mem/data ack distinction, which I didn't do for fun but because lwip zero-copy requires it
<whitequark>
sb0: I grepped it before removing and one of the pointers wasn't used
<whitequark>
which is to say, maybe I was wrong, but not any more wrong
<sb0>
both pointers are used
<sb0>
buffer_out_index_data and buffer_out_index_mem
<sb0>
maybe you grepped an old and buggy version?
<whitequark>
ok, I see now, I was wrong in removing that
<GitHub150>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/v3vGi
<GitHub150>
artiq/new-py2llvm f5ea202 whitequark: session.c: bring back session_ack_{consumed,sent}....
<sb0>
what happens if you try to RPC a list that does not fit in the buffer?
<sb0>
details, details... so much time
<whitequark>
session restart
<whitequark>
and "Failed to send RPC request" in the log
fengling has quit [Ping timeout: 245 seconds]
<sb0>
send_rpc_value doesn't test the return value of out_packet_chunk
<whitequark>
hm, yes
<sb0>
(also, this code should be refactored at some point to use pbufs, which will solve the problem of long lists in addition to improving performance)
<whitequark>
what are pbufs and how would they help?
<GitHub177>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/v3vnP
<GitHub177>
artiq/new-py2llvm 1d61e44 whitequark: session.c: ensure session reset on out buffer overrun during RPC.
<sb0>
they're called mbufs in the bsd kernel and (i think) socket buffers in linux
<whitequark>
I am not familiar with either
<sb0>
they're basically a linked list of (pointer, size) that represent the concatenation of all the buffers pointed to
<whitequark>
ah, scatter/gather I/O
<sb0>
yes
<sb0>
though that's used internally as well, not only for IO
<whitequark>
I'm not sure if that will be such a big win
<sb0>
for small RPCs, no, if you are RPCing a 50M list then it can be passed directly in-place to the network driver
<whitequark>
well, assuming it has no pointers inside
<whitequark>
an RPC can only return an int32?
<sb0>
for now yes, but removing that limitation would be welcome.
<sb0>
one issue is how to annotate the type, as you don't know what it is until the execution is done
<sb0>
there is the "-> " syntax...
<whitequark>
yes
<whitequark>
(there's no other reasonable way)
<whitequark>
a somewhat trickier issue is returns of lists.
<whitequark>
they need to be allocated, and an allocation must happen inside the caller.
<whitequark>
however, the caller doesn't yet know how much it needs to allocate.
<sb0>
how would you even type-annotate them?
<whitequark>
oh, yeah, I was going to ask: which calls exactly become RPCs?
<sb0>
any call that doesn't have @kernel or @portable
<whitequark>
ok, so here's the issue
<whitequark>
let's say the experiment has attributes "a" and "b", containing instances of class "C", which has a method "m", which is host-only
<sb0>
attribute consistency? yes, that's the user's problem.
<whitequark>
whuh?
<whitequark>
no, I mean, how do you figure out on which instance to call the RPC?
<sb0>
a RPCd function is not allowed to modify attributes that are cached in the core device
<sb0>
ah
<whitequark>
I can only think of putting an unique "id" field in every proxied object, on the device, and the method would pull it out and send along with the RPC
<sb0>
well, yeah, you need to add something like that ...
<whitequark>
so there would be an rpc_map and also self_map.
<whitequark>
or more like obj_map.
<sb0>
fine.
<whitequark>
an especially annoying part of that is handling cycles
<whitequark>
but it's doable
<sb0>
hmm, why do you have to handle cycles?
<whitequark>
well, what do I do if "a" has an attribute containing "b", and "b" with "a"?
<sb0>
how is that a problem for generating object IDs?
<whitequark>
no, but since the objects also have other attributes, which may be even modified by the kernels, the identity needs to be maintianed
<sb0>
?
<whitequark>
say, how an object from the host is represented on the device?
<sb0>
I see the cycle problem with representing host objects on the device
<sb0>
but this doesn't have to do with object IDs or RPCs, does it?
<whitequark>
no
<whitequark>
I'm really glad I bothered with adding the ARTIQ IR
<whitequark>
it makes this kind of thing--some ad-hoc code generation, like for print statements, or RPCs--really easy
<whitequark>
and you still have the nice things, like type information, or variable or attribute names, unlike when poking LLVM IR
<whitequark>
also, IR is not tree-structured, so I can just put QuoteT(obj) into IR and expand it into a sequence of instructions initializing it in the IR generator
<whitequark>
ah, crap
<whitequark>
what to do with strings contained in an exception
<whitequark>
they have to live forever.
<whitequark>
ok, so they will have to be interned.
<whitequark>
no good way around that :(
<GitHub37>
[misoc] whitequark pushed 1 new commit to master: http://git.io/v3vVT
<whitequark>
sb0: hrm, actually the RPC handler in session.c is structured extremely weird and not convenient for the compiler at all
<whitequark>
why not just dissect va_args as you go, instead of always going through at least one level of indirection?
<whitequark>
well, I guess that would result in code duplication for things like lists, so maybe it makes sense
_florent_ has joined #m-labs
ylamarre has joined #m-labs
<GitHub141>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/v3JYK
<GitHub141>
artiq/new-py2llvm ee3f35c whitequark: Improve error message on passing an argument twice.
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 250 seconds]
<GitHub155>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/v3J8s
<GitHub155>
artiq/new-py2llvm 13ad9b5 whitequark: Allow to dump ARTIQ/LLVM IR for stitched code.
<GitHub141>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/v3J8M
<GitHub141>
artiq/new-py2llvm 22457bc whitequark: Ensure uwtable is added to all generated functions.
<cr1901_modern1>
whitequark: After seeing your twitter post about GEP, I decided to look up what GEP is. It makes sense, except for uglygep. Is uglygep the LLVM equivalent of aliasing with a char * in C?
cr1901_modern1 is now known as cr1901_modern
cr1901 has quit [Ping timeout: 260 seconds]
cr1901 has joined #m-labs
_florent_ has quit [Read error: Connection reset by peer]
cr1901_modern has quit [Quit: Leaving.]
cr19011 has joined #m-labs
cr1901 has quit [Disconnected by services]
cr19011 is now known as cr1901
<rjo>
sb0: nice.
cr1901 has quit [Read error: Connection reset by peer]
<rjo>
sb0: that design looks gopod to me. people might demand buttons to rescan the repo and commit from the gui. don't know how far educating on consoles and good text editors will get us here.
ylamarre has quit [Ping timeout: 255 seconds]
<GitHub45>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/v3Ugj