bentley` has quit [Ping timeout: 250 seconds]
bentley` has joined #m-labs
<
sb0>
whitequark, can you run the hardware unittests (using ARTIQ_ROOT) on your pipistrello?
<
sb0>
everything works here on pipistrello and kc705, but in rjo's test setup there are tons of bugs
<
sb0>
some apparently appeared since the toolchain switch to llvm
<
sb0>
that's with the runtime built by travis-ci. is it using the proper llvm toolchain?
<
whitequark>
yes, it should use the proper LLVM toolchain. I have uploaded all the changes
<
whitequark>
let's see
<
whitequark>
bizarre
<
whitequark>
rtio.o: In function `rtio_process_exceptional_status':
<
whitequark>
rtio.c:(.text+0x128): undefined reference to `rtio_o_collision_error_reset_write'
<
whitequark>
rtio.c:(.text+0x128): relocation truncated to fit: R_OR1K_INSN_REL_26 against undefined symbol `rtio_o_collision_error_reset_write'
<
whitequark>
oh, need to regenerate
<
whitequark>
sb0: ack, RTIO underflows
<
sb0>
do you have all this breakage as well?
<
whitequark>
these are the tests that fail, yes, but the conditions of failure are different
<
whitequark>
I have for test_rpc_timing:
<
whitequark>
AssertionError: 0.0 not greater than 1.0000000000000001e-07
<
whitequark>
and your log:
<
whitequark>
AssertionError: 0.01608190336000001 not less than 0.015
<
whitequark>
it seems like floating-point is broken
<
whitequark>
on my machine, self.core.get_rtio_counter_mu() just always returns 0
<
whitequark>
hm, that's not floating-point
<
sb0>
it's 64-bit int though
<
whitequark>
ok, if I return "100" from the function (hardcoded), it works
<
whitequark>
sb0: what is the condition for rtio_counter_read() to start increasing?
<
whitequark>
well, the value of
<
sb0>
it should count all the time
<
sb0>
whenever the rtio clock is valid in the bitstream
<
whitequark>
hm, I get hangs on brg_ddsinstall() again
<
whitequark>
I have also been getting completely random hangs when trying to upload the kernel with flterm, even before clang switch
<
whitequark>
it just would sit at 0%
<
sb0>
what is brg_ddsinstall?
<
whitequark>
dds_initall
<
whitequark>
misread
<
whitequark>
anyway, I can return both 1 and 0x100000000 from rtio_get_counter, so it is not an ABI or miscompilation issue
<
whitequark>
let me look at the code it generates for reading the register, to be safe.
<
whitequark>
I think you can see that it is completely correct
<
sb0>
is your bitstream in sync?
<
whitequark>
possibly no
<
whitequark>
actually, certainly no
<
whitequark>
I am guessing the generated register addresses aren't stable
<
sb0>
they are stable when registers are not added, removed or resized in the rtio core, but that has been done recently
<
rjo>
that llvmlite in conda (and supposedly libllvm that is statically links) is 3 weeks old.
<
whitequark>
yes, and you couldn't actually use that with master right now
<
whitequark>
(because of the package name change)
<
whitequark>
so it breaks travis, which I will fix, but if you have something locally that works, it must be recent
<
whitequark>
besides, I didn't make any changes to the parts which py2llvm uses
cr1901_modern1 has quit [Ping timeout: 255 seconds]
cr1901_modern has joined #m-labs
<
whitequark>
brg_ddsinitall doesn't hang now, apparently
<
whitequark>
annnnd... RPC tests pass
<
whitequark>
actually, all coredevice tests pass
<
whitequark>
Ran 116 tests in 20.078s
<
whitequark>
OK (skipped=31)
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 246 seconds]
cr1901_modern1 is now known as cr1901_modern
<
sb0>
whitequark, with new bitstream?
<
sb0>
or did you change something else?
<
whitequark>
only bitstream
kyak has joined #m-labs
<
GitHub98>
pythonparser/master db8947c whitequark: Add colored (Clang-style) diagnostics.
<
GitHub168>
artiq/new-py2llvm 1a969aa whitequark: compiler.transforms.inferencer: accept and ignore @kernel decorator.
cr1901_modern1 has joined #m-labs
acathla has quit [Ping timeout: 250 seconds]
cr1901_modern has quit [Ping timeout: 244 seconds]
acathla has joined #m-labs
mumptai has joined #m-labs
<
GitHub163>
artiq/new-py2llvm b5cf1e3 whitequark: runtime: avoid race condition when running kernel....
sb0 has left #m-labs [#m-labs]
sb0 has joined #m-labs
whitequark has quit [Ping timeout: 252 seconds]
whitequark has joined #m-labs
acathla has quit [Changing host]
acathla has joined #m-labs
<
GitHub197>
artiq/master 7ed8fe5 Sebastien Bourdeauducq: Git support
<
sb0>
whitequark, if you implement colors, you have to implement them in the GUI log display as well :-)
<
GitHub30>
artiq/new-py2llvm b6e2613 whitequark: runtime: avoid spurious error messages.
<
GitHub197>
misoc/master 1b34f48 whitequark: libdyld: all ELF relocations may refer to the current object.
<
whitequark>
gods. the RPC code is gross
<
whitequark>
well, the communication code
<
sb0>
yes, it is. C is gross.
<
whitequark>
the way you calculate lengths and offsets every time at the place of use
<
whitequark>
and it's the same in Python
<
whitequark>
it could be easily abstracted out. no wonder you're saying adding string support is hard
<
whitequark>
it
*is* hard with this mess
<
sb0>
it's not hard, it just takes time
<
whitequark>
it would have taken approximately fifty seconds if you had self._read_string
<
sb0>
I don't see lengths and offsets calculated in many places in Python
<
whitequark>
hum? it's all over in comm_generic
<
whitequark>
well, only lengths there, since you don't buffer reads and writes
<
sb0>
ah, the header stuff
<
sb0>
well, that's minor. i thought you were referring to the out-of-bounds checks sprinkled around in the runtime ...
<
whitequark>
that's too. and the solution for both is exactly the same
<
sb0>
what do you want to do?
<
whitequark>
add a little encoder/decoder state and API that knows how to encode/decode values
<
whitequark>
basically, factor out the checks and length calculations.
<
sb0>
also, this stuff should probably use pbufs (or equivalent) to remove memory copies of lists
<
sb0>
I'm not saying it should be done now, though
<
whitequark>
no, I don't want to do that now
travis-ci has joined #m-labs
<
travis-ci>
m-labs/artiq#379 (master - 7ed8fe5 : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
mumptai has quit [Remote host closed the connection]
<
GitHub48>
artiq/new-py2llvm 353f454 whitequark: Add basic support for embedded functions with new compiler.
jaeckel has quit [Ping timeout: 256 seconds]
jaeckel has joined #m-labs
jaeckel has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
cr1901_modern1 has quit [Ping timeout: 265 seconds]
fengling has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 244 seconds]
jaeckel has joined #m-labs
fengling has quit [Quit: WeeChat 1.2]
cr1901_modern has joined #m-labs
cr1901_modern1 has quit [Ping timeout: 265 seconds]
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 250 seconds]
ohama has quit [Remote host closed the connection]
<
GitHub198>
artiq/new-py2llvm 50448ef whitequark: Add support for referring to host values in embedded functions.
<
whitequark>
sb0: this now works
<
whitequark>
needs better error messages though
rjo_ has joined #m-labs
rjo has quit [Ping timeout: 244 seconds]
ohama has joined #m-labs
<
sb0>
whitequark, cool. @kernel should reference self.core and automatically call the compiler (as you have probably noticed)
<
sb0>
i guess it does tail recursion optimization?
<
whitequark>
there are no classes yet though
<
whitequark>
you can't optimize factorial with TCO
<
whitequark>
since it does not have a call in the tail position
<
whitequark>
(common mistake, actually)
<
sb0>
yeah, ok, not exactly tail recursion
<
whitequark>
I've just tried enabling TCO but then it loops forever
<
whitequark>
will look at it a bit later
<
sb0>
that's not a feature request, I doubt anyone will use tail recursion in artiq anytime soon
<
whitequark>
well, it's a miscompilation, which probably means a latent bug somewhere else
<
whitequark>
ok, so if you replace host_value definition with, sya
<
whitequark>
host_value = [1, 2.0]
<
GitHub145>
pythonparser/master 6749f63 whitequark: Add support for expansions to source.Range.
<
GitHub3>
artiq/new-py2llvm a7633f7 whitequark: Show origin of expansion in diagnostics for synthesized code.
<
whitequark>
imo that one's pretty good
<
GitHub93>
artiq/new-py2llvm acc97a7 whitequark: Fix compiler.module.
ylamarre has joined #m-labs
<
whitequark>
how about
<
whitequark>
self.read(4)
<
sb0>
3.5.0 even, no?
<
whitequark>
well, it's not 3.5.0 as released by llvm.org
<
whitequark>
you could call it 3.5.0-or1k or something
<
sb0>
or1k is already in the package name
<
sb0>
why "not armv6"?
<
whitequark>
no clue whatsoever
<
whitequark>
maybe someone tried to keep it from being built on rpi?
<
sb0>
whitequark, are you still using the gnu linker btw?
<
sb0>
to run kernels
<
whitequark>
what about that?
<
sb0>
mh. another thing to package, that will break on windows, etc. :(
<
whitequark>
getting LLD to work would be nontrivial
<
whitequark>
I'm 80% sure it would be necessary to migrate to 3.6 or even 3.7 before that
<
whitequark>
and then you need to implement the, well, linking. and also bindings
<
GitHub53>
artiq/master c6e5eaa Sebastien Bourdeauducq: doc/manual: fix confusing board config instructions
<
GitHub53>
artiq/master 54a568c Sebastien Bourdeauducq: conda/llvmdev-or1k: cleanup, bump version number
<
whitequark>
that was confusing? oh well
<
sb0>
what were "the first two steps"?
<
sb0>
and why do you have to look at something about installing from source after you installed from binaries?
<
whitequark>
speaking about @kernel, it is weird
<
whitequark>
it is permitted to annotate things like standalone functions and non-experiment functions with @kernel
<
whitequark>
however, the resulting function will only be directly callable if it has the "core" attribute
<
whitequark>
at least, there should be an error message
<
whitequark>
dear god why do you read out the log BYTE BY BYTE
<
whitequark>
was it not slow enough or what
<
GitHub49>
artiq/master be55487 Sebastien Bourdeauducq: comm_generic: cleanup
<
GitHub45>
artiq/new-py2llvm 9f3b10a whitequark: coredevice.comm_*: refactor.
<
GitHub107>
artiq/new-py2llvm 7480d2d whitequark: coredevice.comm_*: refactor.
<
whitequark>
↑ i like that more :]
travis-ci has joined #m-labs
<
travis-ci>
m-labs/artiq#380 (master - 54a568c : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
<
sb0>
the log may contain some null bytes if the ringbuffer is not filled
<
whitequark>
yes, I've fixed that already
<
sb0>
ah right, I was looking at the first diff
<
whitequark>
actually, that doesn't work
<
whitequark>
the log starts with a huge block of 0's
<
whitequark>
you need rindex, I think
<
whitequark>
because you start reading the log starting at the current cursor
<
whitequark>
i.e. after all data which is already in it
<
sb0>
it's a bit of a hack :) better skip the zeros on the runtime even
<
whitequark>
and there's another \0 right at the end
<
whitequark>
eh, the zeroes actually don't hurt
<
whitequark>
they aren't displayed.
<
GitHub0>
artiq/new-py2llvm d6ab567 whitequark: coredevice.comm_*: refactor.
<
whitequark>
ok, now to fix session.c...
mumptai has joined #m-labs
cr1901_modern has joined #m-labs
cr1901_modern1 has quit [Ping timeout: 244 seconds]
whitequark has quit [Ping timeout: 245 seconds]
whitequark has joined #m-labs
ylamarre has quit [Quit: ylamarre]
cr1901_modern has quit [Ping timeout: 255 seconds]
cr1901_modern1 has joined #m-labs
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined #m-labs
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 264 seconds]
cr1901_modern1 has quit [Ping timeout: 244 seconds]
cr1901 has joined #m-labs
acathla` has joined #m-labs
acathla has quit [*.net *.split]
mumptai has quit [Quit: Verlassend]
rjo_ is now known as rjo