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
<whitequark>
rjo: if we merge rust i expect the runtime to grow above 1MB due to some implementation details, for now
<whitequark>
actually, no, nevermind, it doesn't apply to bare metal
<whitequark>
then, the answer is no. (we won't use ocaml or haskell anyway because their GC will break our realtime requirements)
<rjo>
sb0___: why do m1 and mixxeo flash_boot_address = 0x001a0000
<rjo>
even if their bitstreams are less than 0x170000
<rjo>
whitequark: so is 512kB fine for the foreseeable future?
<whitequark>
rjo: I think so, yes
<whitequark>
(rust statically links libstd on desktops, and libstd is large, but we don't have libstd on bare-metal anyway and also we almost certainly want to build with LTO, so it was irrelevant)
<mithro>
rjo_: That is likely the problem
<rjo>
mithro: well. the fpga itself does _not_ leave it in that quad mode. but maybe whatever digilent/xilinx puts onto the fpga does.
<mithro>
rjo: it works!
<mithro>
rjo: so, I guess on the todo list is Quad SPI flash mode support :P
<mithro>
rjo: well at least enough to get it back to non Quad SPI flash
<rjo_>
mithro: even adding the possibility to get out of qspi is orders of magnitude more complicated than the entire current code and flipping a jumper (once. you won't need it again until you flash that weird bitstream that leaves in qspi). not even thinking about the complexity of adding qspi support.
<rjo_>
and adding qspi support would gain exactly nothing. speed would be the same.
<cr1901_modern>
rjo_: Up to 10 ticks on screen at once, correct?
<cr1901_modern>
AActually nevermind... I'll just look at the logs and make a checklist
evilspirit has quit [Ping timeout: 276 seconds]
sb0__ has joined #m-labs
<sb0__>
rjo: artiq_start smells like NIH. I don't see any problem with prepending to PYTHONPATH.
<sb0__>
and there is no problem with subprocesses getting the environment variables either AFAICT
<sb0__>
and use sys.executable, not "python".
<sb0__>
rjo: there are also practical problems with artiq_start, e.g. debugging on windows needs python -u at times
sb0__ has quit [Quit: Page closed]
<cr1901_modern>
rjo: How essential is it that zoom in and zoom out must be perfect inverses of each other? I'm considering getting rid of my use of the Fraction class b/c while I can get exact inverses with a Fraction class, the numerator/denominators start exploding and require increasingly large integers to store the zoom factor
<cr1901_modern>
With floating point, small errors with zoom in and zoom out from the ideal fraction start creeping in b/c (a * b) /a != b (ever?) in floating point, but it's small
evilspirit has joined #m-labs
acathla has quit [*.net *.split]
kyak has quit [*.net *.split]
tmbinc___ has quit [*.net *.split]
felix_ has quit [*.net *.split]
stekern has quit [*.net *.split]
mazzoo_ has quit [*.net *.split]
mwalle has quit [*.net *.split]
cr1901_modern has quit [*.net *.split]
folkert has quit [*.net *.split]
whitequark has quit [*.net *.split]
robtaylor has quit [*.net *.split]
larsc has quit [*.net *.split]
mumptai has quit [*.net *.split]
rjo_ has quit [*.net *.split]
siruf has quit [*.net *.split]
kmehall has quit [*.net *.split]
awallin_ has quit [*.net *.split]
ChanServ has quit [*.net *.split]
attie has quit [*.net *.split]
ysionneau has quit [*.net *.split]
rohitksingh has quit [*.net *.split]
MiW has quit [*.net *.split]
Gurty has quit [*.net *.split]
bentley` has quit [*.net *.split]
bb-m-labs has quit [*.net *.split]
balrog has quit [*.net *.split]
early` has quit [*.net *.split]
mithro has quit [*.net *.split]
rjo has quit [*.net *.split]
cr1901_modern has joined #m-labs
sb0 has joined #m-labs
rohitksingh has joined #m-labs
MiW has joined #m-labs
Gurty has joined #m-labs
<sb0>
cr1901_modern, you could also use only integers (i.e. fix the denominator to a large value e.g. 1e15 as discussed before)
<sb0>
and limit the max zoom level
sb0 has quit [Quit: Leaving]
early` has joined #m-labs
<whitequark>
sb0: speaking of that chamber, he investigated it and turns out it is FUBAR
Gurty has quit [Ping timeout: 272 seconds]
Zou has joined #m-labs
ylamarre has joined #m-labs
Zou is now known as Gurty
Gurty has quit [Changing host]
Gurty has joined #m-labs
jaeckel has quit [Ping timeout: 240 seconds]
jaeckel has joined #m-labs
evilspirit has quit [Ping timeout: 240 seconds]
sb0___ has joined #m-labs
<rjo_>
sb0___: just PYTHONPATH would still break from setup.py and other probably other testing frameworks.
<sb0___>
we do not support setup.py, setuptools are crap
<sb0___>
"setup.py test" won't work and is not supposed to
<sb0___>
why shouldn't other testing frameworks honor PYTHONPATH>
<sb0___>
?
<rjo_>
cr1901_modern: zooming does not need to be perfectly undoable. as long as the sliders don't get moved as a sideeffect. also zooming out very far and then in again should leave the sliders visible if they were visible before.
<sb0___>
or give the user another way to specify where the modules to be tested are
<sb0___>
also, if the testing framework XYZ doesn't handle imports in subprocesses, it's their problem
<sb0___>
and setup.py appears to be one such testing framework, among the gazillion bugs and issues that setuptools has
<rjo_>
sb0___: they honor it because you have set it. but they might also add stuff so sys.path before running tests (and maybe even sphinx does so). you would loose those mods once you start a subprocess.
<sb0___>
then it's a bug in the testing framework
<rjo_>
sb0___: no. that is naive. if you spawn processes, you are responsible of them.
<sb0___>
rjo_: if you really want to fix that, the only sensible option is to update PYTHONPATH with sys.path before creating subprocesses
<sb0___>
the other option is to add cruft to every subprocess so that it reads sys.path from the command line or something like that
<sb0___>
this "only" add cruft to the subprocess creation. but I wouldn't bother and instead claim "python -m unittest *.py" is the only supported options to run tests, with the user responsible to make sure the correct package is imported
rohitksingh has quit [Quit: Leaving.]
<cr1901_modern>
rjo: Ack, thanks
<rjo>
sb0___: there is also unittest discover as i mentioned. you will miss most unittests if you do *.py.
<GitHub70>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vgeOJ
<GitHub70>
artiq/master cf465da Sebastien Bourdeauducq: tools/file_import: make sure sys.path is always restored
<rjo>
yes. that is an inherent problem with herding subprocesses instead of threads or on-big-event-loop.
<rjo>
sb0: with *.py you miss all the tests in coredevice
<rjo>
and all the tests in compiler
sb0___ has joined #m-labs
<sb0___>
whitequark, rjo: can we assume that 1) when the tests are run, 'import artiq' does the right thing 2) this also hold for subprocesses created using sys.executable?
<sb0___>
otherwise this will cause a proliferation of hacks I'm afraid
<sb0___>
rjo: hmm, what do you use to automatically go into the subdirectories? nosetests?
<rjo>
sb0___: nose can do this. iirc unittest discover as well. and setup.py test also does it (maybe through unittest discover)
<sb0___>
setup.py fools around with sys.path and breaks the assumptions above, what about the others?
<rjo>
don't know
<rjo>
i hesitate to guarantee 1) and 2). but yes, you can probably guarantee both by playing with PYTHONPATH, either before running the unittests or when spawning processes.
<sb0___>
unittest discover looks fine
<rjo>
but heck. we have gone so far down the herding-subprocesses route that it seems inevitable.
<sb0___>
and doesn't add yet another dependency
<rjo>
but it will be very nasty to verify that 1) and 2) are true. especially for the case where you have one artiq in PYTHONPATH, another in ./artiq, and yet another artiq in sys.path
<rjo>
which is what happened on the buildbot
<sb0___>
unittest adds an empty string to sys.path for some reason
<rjo>
maybe that's the same as "."
<sb0___>
but it seems rather harmless
<sb0___>
that's a general annoyance with python. try running something when you have e.g. something called sys.py in the current directory...
<sb0___>
it's even a security hazard I'd say
<whitequark>
it is
<whitequark>
Ruby removed "." from default load path because of security
<rjo>
i don't see that problem it only sees that "sys.py" if the module you are running is in that same directory.
<rjo>
relative imports does not cause the type of problem you get if you have "." in yout (shell) $PATH.
<rjo>
PYTHONPATH=. does!
<rjo>
this is why i don't like adding . to PYTHONPATH. absolute paths are ok if you really need to.
<rjo>
anyway. got to shut down this machine... see you.
<mithro>
sb0___: your talk go okay?
<sb0___>
rjo_: the default directory is automatically prepended to sys.path
<sb0___>
s/default/current
<sb0___>
mithro: yeah!
<sb0___>
how is the hdmi2usb deployment?
<mithro>
sb0___: stressful due to many interesting challenges that are unrelated to the HDMI2USB device
<sb0___>
whitequark: we can maybe remove harness.py and not.py, with the assumptions above?
<mithro>
sb0___: We should have the streams up later today
<sb0___>
mithro: just general conference setup challenges?
<mithro>
sb0___: Some of the projectors (which are inside buildings) decided to take a bath