<_whitenotifier-3>
[smoltcp] sbourdeauducq commented on commit bcc7e58caea01685dabc2333eab88022846271aa - https://git.io/JvISm
mauz555 has quit []
proteus-guy has quit [Ping timeout: 265 seconds]
<cr1901_modern>
But "Explain your smolness" isn't even a question!
airwoodix3 has joined #m-labs
airwoodix has quit [Ping timeout: 258 seconds]
airwoodix3 is now known as airwoodix
_whitelogger has joined #m-labs
X-Scale` has joined #m-labs
X-Scale has quit [Ping timeout: 272 seconds]
X-Scale` is now known as X-Scale
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel_ has joined #m-labs
X-Scale` has joined #m-labs
X-Scale has quit [Ping timeout: 258 seconds]
X-Scale` is now known as X-Scale
electronic_eel has joined #m-labs
electronic_eel_ has quit [Ping timeout: 265 seconds]
<_whitenotifier-3>
[nmigen-boards] HarryHo90sHK synchronize pull request #38: Option to factor out "clk" from "spi_flash" on Lattice ECP5 - https://git.io/JeFY3
attie has joined #m-labs
attie has quit [Ping timeout: 265 seconds]
rohitksingh has joined #m-labs
attie has joined #m-labs
proteusguy has quit [Remote host closed the connection]
attie has quit [Ping timeout: 258 seconds]
attie has joined #m-labs
<_whitenotifier-3>
[smoltcp] MabezDev commented on issue #323: TcpSocket timeout not respected in SynSent - https://git.io/JvINP
<_whitenotifier-3>
[smoltcp] MabezDev commented on pull request #310: dhcpv4: use offered ip in requested ip option - https://git.io/JvINM
<_whitenotifier-3>
[smoltcp] whitequark commented on pull request #310: dhcpv4: use offered ip in requested ip option - https://git.io/JvIN9
<_whitenotifier-3>
[smoltcp] MabezDev commented on pull request #310: dhcpv4: use offered ip in requested ip option - https://git.io/JvIAI
attie has quit [Ping timeout: 268 seconds]
attie has joined #m-labs
<mtrbot-ml>
[mattermost] <pkulik> @sb10q Is there a one liner to print all packages and their versions in nix? For example if I want to recreate that build environment later
<mtrbot-ml>
[mattermost] <sb10q> @pkulik how did you install those packages?
<mtrbot-ml>
[mattermost] <pkulik> let me rephrase - all packages that are used in current shell
<mtrbot-ml>
[mattermost] <sb10q> nix or nixos?
<mtrbot-ml>
[mattermost] <pkulik> I ran nix-shell -I artiqSrc=/media/pawel/DATA/pk/Repozytoria/artiq /home/pawel/artiq-dev/nix-scripts/artiq-fast/shell-dev.nix
<mtrbot-ml>
[mattermost] <sb10q> ok, then your environment is fully determined by your nixpkgs channel and that shell-dev.nix file
<mtrbot-ml>
[mattermost] <sb10q> and artiqStc
<mtrbot-ml>
[mattermost] <sb10q> and artiqSrc
<mtrbot-ml>
[mattermost] <sb10q> you can do nix-shell --pure to exclude system commands
<mtrbot-ml>
[mattermost] <pkulik> Ok, however artiq nixpkgs channel doesn't include information about version of packages currently used
<mtrbot-ml>
[mattermost] <pkulik> If I update channels then I get new packages, right?
electronic_eel has quit [Ping timeout: 258 seconds]
electronic_eel has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> yep
<mtrbot-ml>
[mattermost] <sb10q> the artiq channel tracks the nixpkgs channel release 19.09
<mtrbot-ml>
[mattermost] <sb10q> you can get precise information about all the sources for each build on the hydra interface
<mtrbot-ml>
[mattermost] <pkulik> so writing down that information won't let me recreate the exact same environment if you push new artiq package?
<mtrbot-ml>
[mattermost] <sb10q> yep
<mtrbot-ml>
[mattermost] <sb10q> well
<mtrbot-ml>
[mattermost] <sb10q> no
<mtrbot-ml>
[mattermost] <sb10q> it will let you recreate the exact same information
<mtrbot-ml>
[mattermost] <sb10q> *environment
<mtrbot-ml>
[mattermost] <sb10q> the hydra "inputs" tab contains all the information you need to recreate
<mtrbot-ml>
[mattermost] <pkulik> can I get this information locally? in my local script?
<mtrbot-ml>
[mattermost] <sb10q> for your command "nix-shell -I artiqSrc=/media/pawel/DATA/pk/Repozytoria/artiq /home/pawel/artiq-dev/nix-scripts/artiq-fast/shell-dev.nix" you are not using the hydra channel
Stormwind_mobile has quit [Read error: Connection reset by peer]
Stormwind_mobile has joined #m-labs
<mtrbot-ml>
[mattermost] <pkulik> basically I was thinking of something equivalent to listing all packages and their versions in conda
<mtrbot-ml>
[mattermost] <pkulik> to be able later to install all the same versions and recreate the same build environment
<mtrbot-ml>
[mattermost] <sb10q> so your equivalent inputs would be: 1. your nixpkgs commit id 2. artiqSrc contents (if unmodified git, that's the commit ID also) 3. nix-scripts contents (same remark)
<mtrbot-ml>
[mattermost] <sb10q> with the same inputs you'll get the same nix-shell environment
<mtrbot-ml>
[mattermost] <sb10q> and you can get your nixpkgs commit id with `nix-instantiate --eval -E '(import <nixpkgs> {}).lib.version'`
rohitksingh has quit [Ping timeout: 260 seconds]
<mtrbot-ml>
[mattermost] <pkulik> does it also give me the same misoc, migen, jesd etc packages? aren't those are in artiq-* packages?
attie has quit [Ping timeout: 258 seconds]
<mtrbot-ml>
[mattermost] <sb10q> it will give you the packages prescribed by shell-dev.nix, which includes misoc, migen, jesd etc.
<mtrbot-ml>
[mattermost] <sb10q> and yes, you'll get reproducible versions for those if the 3 inputs I mentioned stay the same
attie has joined #m-labs
<mtrbot-ml>
[mattermost] <pkulik> ok, so nixpkgs of this commit id includes information about artiq-* package version/commit/id which includes information about misoc/migen etc?
<mtrbot-ml>
[mattermost] <sb10q> your inputs are nixpkgs, artiqSrc and shell-dev.nix (and files from nix-scripts referenced by shell-dev.nix)
<mtrbot-ml>
[mattermost] <sb10q> those files from nix-scripts referenced by shell-dev.nix contain information about the migen, misoc etc. versions
<mtrbot-ml>
[mattermost] <pkulik> oh, I see, in pkgs/python-deps.nix
<mtrbot-ml>
[mattermost] <sb10q> yep
<mtrbot-ml>
[mattermost] <pkulik> ok, great
<mtrbot-ml>
[mattermost] <pkulik> thanks!
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel has joined #m-labs
<mtrbot-ml>
[mattermost] <pkulik> @sb10q Does sayma amc still need rtm built first?
Stary has quit [Ping timeout: 260 seconds]
<mtrbot-ml>
[mattermost] <sb10q> no you can build them in any order
<mtrbot-ml>
[mattermost] <sb10q> the RTM is a mostly regular DRTIO node now
attie has quit [Ping timeout: 260 seconds]
<rjo>
sb10q: it's annoying to do that remotely. and I see you have done some testing already. let's do the rest together with the sincos upgrade/integration and/or the specified performance testing
Gurty has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> why is it annoying to do remotely?
attie has joined #m-labs
attie has quit [Ping timeout: 268 seconds]
<rjo>
the latency, the cumbersome redpitaya interface, not knowing what's connected where, long delays getting things changed
<mtrbot-ml>
[mattermost] <sb10q> latency?
<mtrbot-ml>
[mattermost] <sb10q> also for the sawg test I think we can simply connect kasli -> sayma -> channel 0/1 on a redpitaya
<mtrbot-ml>
[mattermost] <sb10q> and I can check that this is working with simple waveforms
<mtrbot-ml>
[mattermost] <sb10q> the redpitaya interface indeed kinda sucks. the artiq-zynq project gives me a good idea about why nobody developed alternative firmware for it ...
<mtrbot-ml>
[mattermost] <sb10q> the current redpitaya firmware is using like 10% of the hardware capability, because doing anything with zynq other than running reference designs is a pain in the ass, and also the ADC/DAC etc. is proprietary and poorly documented
<mtrbot-ml>
[mattermost] <sb10q> you are aware of artiq_flash -H, right? and also you can put a public ipv6 address on the sayma and it'll get routed to your machine; while rather insecure, it will work in practice
attie has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> there's also a network-controlled power cycler in case it acts up, but sayma v2 is a lot saner than v1 and I haven't seen any crazy problems with it yet
mumptai has joined #m-labs
proteus-guy has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 265 seconds]