<_whitenotifier-9>
[nmigen] sbourdeauducq opened issue #58: fix Signal(max=1) - https://git.io/fjYx6
_whitelogger has joined #m-labs
<lkcl>
i have no idea if the "reset" value on a zero-width signal should make any sense. logically it should not: would raising an exception if the reset argument is non-zero be a good idea?
<lkcl>
it would help the cases where, programmatically, the desired width is passed in to a class as an __init__ parameter
<lkcl>
and the designer of the class set a non-zero default reset for the signal, yet the user of the class, not knowing that, specified zero-width
<whitequark>
lkcl: we don't currently warn on reset values wider than the signal
<whitequark>
there are some edge cases, e.g. -1 as a way to initialize a signal to all-ones
<whitequark>
since that's what ~0 translates to
<whitequark>
i'm not sure what kind of diagnostic and on what condition would be best here
<whitequark>
i agree that this requires consideration
futarisIRCcloud has joined #m-labs
<lkcl>
ack. didn't realise reset was truncated (even for width != 0)
sb0 has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> @astro: maybe the windows c.img creation process should be split into two steps
<mtrbot-ml>
[mattermost] <sb10q> 1. install windows and set up openssh
<mtrbot-ml>
[mattermost] <sb10q> 2. install conda
<mtrbot-ml>
[mattermost] <sb10q> with a copy of the c.img file between the two.
<mtrbot-ml>
[mattermost] <sb10q> 1. requires manual intervention, and 2. is prone to failure due to conda bugginess
<mtrbot-ml>
[mattermost] <sb10q> also, if we update the artiq dependencies, we could skip step 1
<mtrbot-ml>
[mattermost] <sb10q> @astro your RTC hack does not work
<mtrbot-ml>
[mattermost] <sb10q> I'll let you figure out that one
m4ssi has joined #m-labs
proteusguy has quit [Ping timeout: 255 seconds]
rohitksingh has quit [Ping timeout: 245 seconds]
proteusguy has joined #m-labs
rohitksingh has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has quit [Ping timeout: 246 seconds]
<mtrbot-ml>
[mattermost] <astro> thank you!
proteusguy has quit [Ping timeout: 255 seconds]
cr1901_modern has quit [Ping timeout: 250 seconds]
cr1901_modern has joined #m-labs
ohsix has quit [Ping timeout: 264 seconds]
sb0 has quit [Quit: Leaving]
<npulido>
rjo: PDQ is working fine now. The mistake was that we had the F2 IN connected to ground...
sb0 has joined #m-labs
<sb0>
ah, conda is now the "enterprise data science platform"
<sb0>
"enterprise" is the usual keyword for software that aucks
<sb0>
*sucks
<mtrbot-ml>
[mattermost] <astro> enterprise as in not polished for the end-user
<mtrbot-ml>
[mattermost] <astro> enterprise as in needs professional support
<sb0>
astro: what version do you have that causes problems? 2019.03?
<mtrbot-ml>
[mattermost] <astro> nixos 19.03
<mtrbot-ml>
[mattermost] <astro> anaconda 2019.03
<mtrbot-ml>
[mattermost] <astro> but I think the install-artiq.py problems are related to windows+ssh: I don't even have write permissions to what I scp'ed before. I'm halfway through figuring out how to enable/become administrator via powershell
<mtrbot-ml>
[mattermost] <astro> but first, hydra+qemu!
<sb0>
okay. i'm slowly installing anaconda 2019.03 in the windows vm. it's remarkably slow...
<mtrbot-ml>
[mattermost] <astro> it is. miniconda would be only a fraction of that...
<mtrbot-ml>
[mattermost] <astro> but I guess we should test with the full thing
X-Scale has quit [Ping timeout: 245 seconds]
X-Scale has joined #m-labs
<rjo>
npulido: good. we don't have any active involvement in pdq anymore or anybody funding support/maintenance/development/integration. if you want to contribute and if you submit pull requests with better/code/artiq integration/documentation/tests etc please fee free. i'd be glad to accept them.
<npulido>
rjo: alright; your code works very nicely :) but I'll keep it in mind. For now the strategy will be to program using USB and trigger (which works out of the box) with a ttl via artiq. Thanks and happy holidays!
<sb0>
astro: so far the install-artiq.py script is working just fine with the latest anaconda
<sb0>
it's still installing...
<mtrbot-ml>
[mattermost] <astro> it breaks with the 2nd .tar.bz2
<mtrbot-ml>
[mattermost] <astro> because the pre-link scripts (wherever they come from) encounters permission errors while trying to meddle with `artiq_client.exe` which was installed by the 1st artiq.tar.bz2
<sb0>
okay, well I've put 4 of them in there, so we'll see
<sb0>
the other .tar.bz2 are not touching artiq_client
<sb0>
they are board firmware packages
<mtrbot-ml>
[mattermost] <astro> I know that now :)
<sb0>
astro: I'm not sure if QEMU needs to be part of propagatedBuildInputs anymore, or even buildInputs
<sb0>
when you're doing ${qemu_kvm}/bin/qemu-system-x86_64 it becomes part of the closure afaik
<sb0>
(but that needs testing)
<mtrbot-ml>
[mattermost] <astro> that's good *if* nix recognizes that from the generated shell scripts?
<mtrbot-ml>
[mattermost] <astro> s/\?//
<sb0>
astro: I'm not too familiar with that aspect of the nix language, but it might
<sb0>
okay the windows tests are running in hydra now :)
<mtrbot-ml>
[mattermost] <astro> does that mean `install-artiq.py` worked for you?
<sb0>
no, I'm also getting some permission error with artiq_client.exe
<sb0>
sigh
<mtrbot-ml>
[mattermost] <astro> I'll continue looking into that later
<mtrbot-ml>
[mattermost] <astro> I have just pushed a split installer
<mtrbot-ml>
[mattermost] <astro> and am otherwise wiring up ports forwardings
<mtrbot-ml>
[mattermost] <astro> which may need elevated privs as well to manipulate the VM's `hosts` file
<sb0>
we can probably fix this conda problem by making the board firmware packages not depend on artiq packages
<sb0>
the conda dependency solver is useless anyway, it's just a broken buggy pile of trash
<sb0>
astro: we can just put the board IP instead of the hostname into the ARTIQ device database used for testing
<sb0>
astro: or let windows access the router DNS server
<sb0>
the first option is probably easier
<sb0>
kc705-1 is 192.168.1.50 (fixed) - let me just do that
<sb0>
astro: removing the dependency worked around the conda bug
<sb0>
for some reason that also made conda downgrade pyqt to version 4 and break the GUI, but that's fixable later with "conda install pyqt=5" and may not be reproducible
<mtrbot-ml>
[mattermost] <astro> that's great news
<mtrbot-ml>
[mattermost] <astro> I don't need to find out how to enable the secret windows administrator account after all
<sb0>
astro: seems the error codes aren't forwarded from windows to linux - when the tests fail, the script continues execution
<mtrbot-ml>
[mattermost] <astro> I forgot `set -e` in the `run-test.nix` script
<mtrbot-ml>
[mattermost] <sb10q> set -e will skip the shutdown command on a test failure
<mtrbot-ml>
[mattermost] <astro> hydra will kill it?
<mtrbot-ml>
[mattermost] <astro> I'll see… still doing test runs
<mtrbot-ml>
[mattermost] <sb10q> not sure. might be better to try to do a clean shutdown when possible
<mtrbot-ml>
[mattermost] <sb10q> afaik only the test command might fail in normal conditions, so only this one needs to have its return code checked and then perform the shutdown
<mtrbot-ml>
[mattermost] <astro> ok
<mtrbot-ml>
[mattermost] <sb10q> for the other commands set -e can be used
<mtrbot-ml>
[mattermost] <sb10q> also it seems your timed shutdown is killing the test now, i suggest removing it entirely
m4ssi has quit [Remote host closed the connection]
<mtrbot-ml>
[mattermost] <sb10q> also the connection to the core device doesn't seem to work
<mtrbot-ml>
[mattermost] <sb10q> well, maybe the timed shutdown actually helps with failures like that
<mtrbot-ml>
[mattermost] <astro> the timeout can be changed
ohsix has joined #m-labs
proteusguy has joined #m-labs
rohitksingh has joined #m-labs
<_whitenotifier-9>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjOqv
<_whitenotifier-9>
[m-labs/nmigen] whitequark dda8f34 - hdl.xfrm: handle classes that inherit from Record.