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
<sb0> whitequark, can you announce it on the ML?
<sb0> is there a reason to keep the new-py2llvm branch?
<sb0> also, the py2llvm_old folder can probably be deleted
ylamarre has quit [Remote host closed the connection]
Guest24673 has joined #m-labs
Guest24673 has quit [Client Quit]
Mon_ has joined #m-labs
Mon_ is now known as Guest53312
Guest53312 has quit [Quit: This computer has gone to sleep]
Mon_ has joined #m-labs
Mon_ is now known as Guest48971
Guest48971 has quit [Client Quit]
sb0_ has joined #m-labs
<sb0_> whitequark, you will love this: http://paste.debian.net/335481/
<sb0_> whitequark, btw, as i told you, your diagnostic colors create a mess in the GUI log
<sb0_> the master log files are probably affected as well
<GitHub193> [artiq] sbourdeauducq pushed 4 new commits to master: http://git.io/vBY1R
<GitHub193> artiq/master 8999d57 Sebastien Bourdeauducq: examples/mandelbrot: fix variable initialization
<GitHub193> artiq/master 91a8acf Sebastien Bourdeauducq: protocols/pc_rpc: properly convert FullArgSpec to dict
<GitHub193> artiq/master 2503dcd Sebastien Bourdeauducq: devices/thorlabs_tcube: remove unnecessary attribute
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#593 (master - e5b58b5 : Sebastien Bourdeauducq): The build is still failing.
travis-ci has left #m-labs [#m-labs]
<GitHub8> [artiq] whitequark deleted new-py2llvm at 66b1388: http://git.io/vBYMV
<whitequark> sb0_: there was a reason i kept some of the py2llvm_old folder...
<whitequark> specifically i kept the bits which weren't ported yet. but well, it doesn't matter, it's in git
<whitequark> how did you arrive at the error in that paste?
<sb0_> ah, sorry.
<whitequark> also you didn't even remove all of it
<GitHub81> [artiq] whitequark pushed 1 new commit to master: http://git.io/vBYDw
<GitHub81> artiq/master f5187eb whitequark: Remove leftover artiq/transforms/.
<whitequark> some merge artifact
<sb0_> feel free to revert if you prefer to work that way. i personally tend to keep the files separate for this sort of thing and only keep the source that is actually in use in the main repos...
<whitequark> it doesn't really matter
<sb0_> whitequark, re. the error: just import inspect, and inspect.getfullargpec(print)
<sb0_> they made print() a regular function in py3k, but not totally :-)
<whitequark> oh, unrelated to the compiler
<whitequark> all python builtins react like that.
<sb0_> yes, that's a pure python problem
<whitequark> try it with `list` or something
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#594 (master - f5187eb : whitequark): The build is still failing.
travis-ci has left #m-labs [#m-labs]
<sb0_> ysionneau, have you read the pyserial documentation?
<sb0_> specifically this:
<sb0_> Read size bytes from the serial port. If a timeout is set it may return less characters as requested. With no timeout it will block until the requested number of bytes is read.
sb0__ has joined #m-labs
sb0_ has quit [Read error: Connection reset by peer]
<sb0__> whitequark, i still don't see the problem with RPCs
<sb0__> first - can you detect if a call is RPC before type inference?
<whitequark> no
<whitequark> self.x.y.z(). z() may be a @kernel or an RPC
<whitequark> ok, I have an idea, we'll just handle this like function polymorphism, not dynamic typing
<sb0__> ysionneau, you are using Enum for MGMSG, but not for Direction? why?
<GitHub103> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vBOvT
<GitHub103> artiq/master 76eadc0 Sebastien Bourdeauducq: devices/thorlabs_tcube: remove unnecessary {read,write}_exactly functions
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#595 (master - 76eadc0 : Sebastien Bourdeauducq): The build is still failing.
travis-ci has left #m-labs [#m-labs]
<sb0__> ysionneau, didn't you know that "a() or b()" doesn't call b() if a() evaluates to True?
Mon_ has joined #m-labs
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 42.0/20151029151421]]
Mon_ is now known as Guest65187
<GitHub132> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vBOTQ
<GitHub132> artiq/master bda1114 Sebastien Bourdeauducq: devices/thorlabs_tcube: fix more style issues
Guest65187 has quit [Client Quit]
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#596 (master - bda1114 : Sebastien Bourdeauducq): The build is still failing.
travis-ci has left #m-labs [#m-labs]
<whitequark> sb0__: artiq.compiler.types imports pythonparser.diagnostic so that it can do an assert: assert cause is None or isinstance(cause, diagnostic.Diagnostic)
FabM has joined #m-labs
<whitequark> do I: 1) put the import into the function containing the assert
<whitequark> 2) do some hack with class name instead of isinstance
<GitHub28> [artiq] whitequark pushed 1 new commit to master: http://git.io/vBOYa
<GitHub28> artiq/master e1cd2cc whitequark: compiler: pull in dependencies in more finely grained way (fixes #181).
<sb0__> #1
<sb0__> there are other parts of artiq where similar situation arises (e.g. for git support) and they are solved with lazy imports
<sb0__> plus the hack is fuzzy
<GitHub145> [artiq] whitequark pushed 2 new commits to master: http://git.io/vBOZu
<GitHub145> artiq/master 14993e8 whitequark: compiler.embedding: show suggestions for mistyped host object attributes.
<GitHub145> artiq/master d14ad67 whitequark: compiler.embedding: avoid showing wildly incorrect suggestions.
<GitHub185> [artiq] whitequark pushed 1 new commit to master: http://git.io/vBOnt
<GitHub185> artiq/master d732b6c whitequark: doc: nested lists are now supported.
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#598 (master - d14ad67 : whitequark): The build has errored.
travis-ci has left #m-labs [#m-labs]
<whitequark> sb0__: dockarea.Dock.__init__(self, name, label="Log", size=(1000, 300))
<whitequark> TypeError: __init__() got an unexpected keyword argument 'label'
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#599 (master - d732b6c : whitequark): The build is still failing.
travis-ci has left #m-labs [#m-labs]
sb0__ has quit [Read error: Connection reset by peer]
sb0_ has joined #m-labs
<sb0_> whitequark, use the m-labs pyqtgraph fork
<sb0_> or kick the maintainer's ass
<whitequark> oh
sb0_ has quit [Quit: Leaving]
aeris has quit [Quit: Leaving]
aeris has joined #m-labs
<cr1901_modern> Why not both?
Mon_ has joined #m-labs
Mon_ is now known as Guest37351
<GitHub15> [artiq] whitequark pushed 1 new commit to master: http://git.io/vB3fW
<GitHub15> artiq/master d560b57 whitequark: doc: update mention of int64.
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#600 (master - d560b57 : whitequark): The build is still failing.
travis-ci has left #m-labs [#m-labs]
<whitequark> grrr
Guest37351 has quit [Quit: This computer has gone to sleep]
Mon_1 has joined #m-labs
<sb0> whitequark, look what i found
<sb0> CF35 nude Bayard Alpert gauge
<sb0> 750 HKD
<whitequark> why do you like hot cathode gauges so much?
<sb0> what's wrong with them?
Mon_1 has quit [Quit: This computer has gone to sleep]
<whitequark> easy to break
Mon_1 has joined #m-labs
<sb0> bah
<sb0> in case of catastrophic vacuum loss, many things will break. and by far, that's usually not the most expensive or hard part to replace
<whitequark> ugh, fucking conda
<whitequark> on my machine it now just hangs.
<whitequark> after "removing old work directory"
<whitequark> oh, it's cloning something. okay
<whitequark> fucking useless garbage
<whitequark> sb0: btw, miniconda 3 now ships with python 3.5
<sb0> yes
<whitequark> did you update the instructions already?
<sb0> no, I haven't
<sb0> i imagine the build scripts could use an update too
<sb0> aren't they downloading 3.4 initially and then upgrading to 3.5?
<whitequark> no
<whitequark> I mean, yes, build scripts do
<sb0> so if I understand this well: GIT_DESCRIBE_TAG is now broken by default because conda uses --depth?
<whitequark> no
<whitequark> it does not use --depth, which is why I am unable to do anything with conda on this mobile connection
<whitequark> because it just sits in git for half a hour every time
<sb0> do you want to come to hk island tomorrow? you could use my connection and pick up some of your stuff
<sb0> internet in the office will still take a good week I'm afraid...
<whitequark> hrm, the conda build succeeds on my VPS
<whitequark> let's try this
<GitHub25> [artiq] whitequark pushed 1 new commit to master: http://git.io/vB3u3
<GitHub25> artiq/master 5d89acb whitequark: conda: switch back to default miniconda python, which is now 3.5.
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#601 (master - 5d89acb : whitequark): The build is still failing.
travis-ci has left #m-labs [#m-labs]
<whitequark> BUILD START: should display 0+git
ylamarre has joined #m-labs
<whitequark> Package: should display proper name
<whitequark> get_src is never false...
<whitequark> I dunno. I give up. I'm not motivated to dig that cesspool again. someone who is more motivated than me is going to fix it
<whitequark> or at least give me a way to reproduce it, because downloading the Travis images will take literally forever
<cr1901_modern> I can't do it right now, but I'll take a look at it later.
<sb0> whitequark, do you want to set up a build-bot in the lab? then it could also load an fpga board and do hardware-in-the-loop tests
<whitequark> sb0: why does artiq_gui spam WARNING:artiq.gui.moninj:could not find core device address
<whitequark> ?
<sb0> because you are using comm_serial and it doesn't find the ip address of the board
<sb0> ppp will fix this
<whitequark> no, why does it do that every second? that's dumb
<sb0> it does it everytime it needs to send a udp packet to ask the board to send its status
<sb0> and that involves a ip address lookup through the latest device db
<whitequark> well, it's annoying.
<sb0> use -q
<whitequark> sb0: how can I get repository name from worker?
<whitequark> or rather, path to repositor
<sb0> obj["wd"] when obj["action"] == "build"
<sb0> which is None when the experiment run is bypassing the repository, in which case obj["expid"]["file"] is relative to the filesystem
<whitequark> ok
<whitequark> do you know that your log widget is extremely ugly and works poorly?
<sb0> what's wrong with it?
<whitequark> it doesn't respect my desktop color scheme and the rows are 2x larger than they should be
<whitequark> also, lines longer than the width of the widget are handled poorly
<whitequark> also, for some bizarre reason you can resize rows
<sb0> that's a Qt but
<sb0> *bug
<sb0> respecting desktop color scheme, how would you support that?
<sb0> the color scheme doesn't provide colors for log severities
<sb0> assuming that the color scheme uses black text on white background works in most cases, and when it doesn't, you get a widget that doesn't integrate with your colors but is still functional
<whitequark> yeah but there are only two possible color schemes that are high-contrast. it's reasonable to choose one of them depending on the background color
<sb0> large rows, I'm not sure why Qt does that
<sb0> the most annoying thing of all is the column resize bug, especially because it's most probably in the qt c++ code
<sb0> note that after a while, qt notices that the column size is wrong and resizes it properly...
<whitequark> which column resize bug? I don't have it
<whitequark> ah I see, the wrapping one
<sb0> "lines longer than the width of the widget are handled poorly" << sounds like it
<whitequark> no, actually, the behavior that you consider a "bug" is the behavior that I normally want
<whitequark> I don't want to scroll around, I would like it to wrap, it's much easier to read
<whitequark> python backtraces are basically useless with this scrolling, because my DPI settings cause all interesting info to go offscreen
<sb0> it is a bug, qt is supposed to resize the column so that it fits the contents
<sb0> and it does it, but only after wrapping for a while
<whitequark> yes, it needs a reflow to actually resize it, which does seem to be a bug
<whitequark> but it doesn't matter, because that's awful behavior anyway, just fix the column width and let it wrap
<sb0> anyway. feel free to change to wrapping, hopefully no bug will manifest itself then
<sb0> same with detecting inverted color schemes, though I'm pretty sure you're the only one who'll use this
<GitHub159> [artiq] whitequark pushed 1 new commit to master: http://git.io/vB3b2
<GitHub159> artiq/master c6ccc87 whitequark: worker: gracefully handle compile errors (fixes #179).
<whitequark> ok
<sb0> how do you resize logger rows? I haven't seen that problem
<whitequark> do you see the very small tab on the left? like column header but horizontal
<whitequark> or rather vertical
<whitequark> you can grab it and resize individual rows
<sb0> I see. do you want me to fix this or you do it?
rohitksingh has joined #m-labs
<felix_> sb0: i tracked down the serial interface problem and i'm quite sure that a software patch can fix the problem
<felix_> i'll comment on github
<whitequark> sb0: I think it's better if you fix this and I'll concentrate on that RPC issue
<felix_> the software solution is imho more flexible and generic than a hardware solution
<felix_> performance shouldn't matter that much here, as the uart is a quite slow interface
<felix_> that solution will have a longer latency (in worst case 8 byte transmit times), but when the threshold is set up correctly, that's not a problem
<sb0> whitequark, done. i'll leave the colors to you.
<GitHub108> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vBss2
<GitHub108> artiq/master 3c0efb3 Sebastien Bourdeauducq: gui/log: fix layout problems
<sb0> whitequark, anything else that is extremely ugly or works poorly?
<sb0> felix_, ack
<felix_> ok, so i'll implement the software solution?
<whitequark> sb0: the resizing can be very slow sometimes
<whitequark> and there is some strange behavior where docked widgets have the tabs on the right, but after removing and putting them back the tab is on the top again
<whitequark> otherwise I haven't noticed anything bad
<felix_> other option would be adding a csr for the tx path which bypasses the tx buffer, but i don't think that this is necessary
<whitequark> the specific case when resizing is slow is when you resize the log widget
<sb0> felix_, yes.
<felix_> ok
Mon_1 has quit [Quit: This computer has gone to sleep]
Mon_ has joined #m-labs
Mon_ is now known as Guest34218
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
Guest34218 has quit [Quit: This computer has gone to sleep]
Mon_ has joined #m-labs
Mon_ is now known as Guest79905
Guest79905 has quit [Client Quit]
mumptai has joined #m-labs
ylamarre has quit [Ping timeout: 276 seconds]
ylamarre has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
ylamarre has quit [Quit: ylamarre]
aeris has quit [Read error: Connection reset by peer]
ylamarre has joined #m-labs
aeris has joined #m-labs