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
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> yeah
<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
<sb0> *gateware
<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] whitequark pushed 1 new commit to master: http://git.io/vOFQS
<GitHub98> pythonparser/master db8947c whitequark: Add colored (Clang-style) diagnostics.
<GitHub168> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vOF7B
<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] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vObeC
<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] sbourdeauducq pushed 1 new commit to master: http://git.io/vObVu
<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 :-)
<whitequark> hrm
<GitHub30> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vObrG
<GitHub30> artiq/new-py2llvm b6e2613 whitequark: runtime: avoid spurious error messages.
<GitHub197> [misoc] whitequark pushed 1 new commit to master: http://git.io/vObrH
<GitHub197> misoc/master 1b34f48 whitequark: libdyld: all ELF relocations may refer to the current object.
<whitequark> gods. the RPC code is gross
<sb0> what part?
<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] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vOb9R
<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] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vONWB
<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)
<whitequark> sure
<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] whitequark pushed 1 new commit to master: http://git.io/vONg7
<GitHub145> pythonparser/master 6749f63 whitequark: Add support for expansions to source.Range.
<GitHub3> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vON2U
<GitHub3> artiq/new-py2llvm a7633f7 whitequark: Show origin of expansion in diagnostics for synthesized code.
<whitequark> imo that one's pretty good
<GitHub93> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vONiI
<GitHub93> artiq/new-py2llvm acc97a7 whitequark: Fix compiler.module.
ylamarre has joined #m-labs
<whitequark> how about
<whitequark> self.read(4)
<whitequark> yes
<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?
<whitequark> yes
<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] sbourdeauducq pushed 2 new commits to master: http://git.io/vOAtA
<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> hrm
<whitequark> point
<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] sbourdeauducq pushed 1 new commit to master: http://git.io/vOAn1
<GitHub49> artiq/master be55487 Sebastien Bourdeauducq: comm_generic: cleanup
<GitHub45> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vOAnb
<GitHub45> artiq/new-py2llvm 9f3b10a whitequark: coredevice.comm_*: refactor.
<GitHub107> [artiq] whitequark force-pushed new-py2llvm from 9f3b10a to 7480d2d: http://git.io/vmI6O
<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> right...
<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] whitequark force-pushed new-py2llvm from 7480d2d to d6ab567: http://git.io/vmI6O
<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