<_whitenotifier-9>
[nmigen] rroohhh commented on issue #57: DomainRenamer does not work with together with ClockSignal - https://git.io/fjOGG
<_whitenotifier-9>
[nmigen] rroohhh commented on issue #57: DomainRenamer does not work with together with ClockSignal - https://git.io/fjOGB
<_whitenotifier-9>
[nmigen] whitequark commented on issue #57: DomainRenamer does not work with together with ClockSignal - https://git.io/fjOG6
<_whitenotifier-9>
[nmigen] rroohhh commented on issue #57: DomainRenamer does not work with together with ClockSignal - https://git.io/fjOGy
<mtrbot-ml>
[mattermost] <sb10q> @npulido try reposting your message
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
bb-m-labs has joined #m-labs
sb0 has joined #m-labs
<mtrbot-ml>
[mattermost] <npulido> @sb10q I reposted on Wednesday and got failure notification for the first post. Maybe the second one will get through.
<mtrbot-ml>
[mattermost] <npulido> @sb10q anyway my post was the question about the PDQ, which I ended asking here, and is now resolved
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has joined #m-labs
m4ssi has joined #m-labs
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 250 seconds]
<sb0>
but nix provides many tools for disciplining this piece of crap, such as sandbox conda-builds with network access cut off
<sb0>
basically the new infra is using conda-build as a dumb tool to produces package files in the correct format, and all the hard work is done by hydra/nix
<cr1901_modern>
mmm, I like dpkg, but maybe I'll try nix for those builds where I legitimately don't want the rest of my system being polluted as an alternative to a container
<sb0>
dpkg is essentially like conda, but minus the bugs and the slowness
<sb0>
nix has a totally different approach
<cr1901_modern>
I know, and I don't particularly agree w/ the nix approach
<cr1901_modern>
but it may be a useful alternative to "sourcing handmade scripts" for certain things
<sb0>
I was skeptical for a while, but it does work and solve a lot of problems
<cr1901_modern>
"sourcing handmade scripts to set up an environment"
<cr1901_modern>
Clarify: I don't _aesthetically_ agree w/ the nix approach
<cr1901_modern>
I'm sure it's fine at what it does
<sb0>
aesthetically?
<cr1901_modern>
Over the years we've figured out "dependencies and libraries coexisting in a unified file system is difficult". Nix I feel punts on that by giving up and saying "that's too hard, so now every application has its own false view of the filesystem"
<cr1901_modern>
and well, aesthetically I don't like that :P. It's not a good reason to dislike nix
<cr1901_modern>
(or containers, really)
<cr1901_modern>
But nix is def less evil than containers :)
<sb0>
no, the applications all see the same filesystem, unless you use buildFHSEnv
<sb0>
instead, there is some patching of the ELF binary files that goes on so they use the correct libraries
<cr1901_modern>
rpath?
<sb0>
that's not perfect either but it's not like containers or chroot
<cr1901_modern>
I was under the impression that for many nix applications you have to source a particular shell script which sets up the environment for you
<sb0>
yes, sometimes there are wrappers for that, in particularly for python
<cr1901_modern>
and this can be automated from a WM/DE by using XDG .desktop files
<sb0>
oh, no, you don't need those
<sb0>
the nix toolchain will put the wrapper in your PATH and it's mostly transparent
<cr1901_modern>
I mostly remote in to my Ubuntu box. I run xpra on it to get a X session if I need it. And I (still) use Atom as my text editor. >>
<sb0>
atom is quite bloatdd
<cr1901_modern>
Yes I know :P.
<sb0>
not sure if there are free alternatives. i use sublime-text...
<cr1901_modern>
VSCode supposedly is the new FOSS hotness
<cr1901_modern>
xray is prob the Atom replacement
<sb0>
it's also electron, so how can it be not bloated?
<cr1901_modern>
sb0: Well here's a funny thing
<sb0>
also I wonder who would think CSS is a good framework for user interfaces...
<cr1901_modern>
electron is actually better at smooth scrolling over an Xpra connection than Scintilla is
<sb0>
<table> works better
<cr1901_modern>
Scintilla is unusable over an xpra connection
<cr1901_modern>
(which was part of the previous editor I used on *nix- Geany)
<cr1901_modern>
So that was one reason I switched, since most of my *nix work is remote
<cr1901_modern>
Idk why electron is better at this- I would expect it to be unusable as well. But I'm willing to live w/ the bloat since the machine is mostly headless otherwise
<sb0>
how usable is xpra? is it a lot better than the horrible X protocol?
<cr1901_modern>
Works fine IME- far less bandwidth/CPU intensive than the X protocol, even when using H.264 codec to send data
<sb0>
even with 100Mbps FTTH at both ends and <<10ms ping, X is still unusable
<cr1901_modern>
MATLAB alone, when I still used it, brought an ssh -Y connection to its knees
<cr1901_modern>
xpra handled it just fine
<cr1901_modern>
Prob the best feature is session resuming- xpra is essentially "tmux for X"
<cr1901_modern>
you can disconnect from a session and reopen it later. And sometimes renegotiating the connection actually helps w/ bandwidth
<cr1901_modern>
One quirk: I think it's that primary/secondary clipboard handling is a bit weird- and my .xpra-start file doesn't honor my defaults of changing the clipboard; I have to do that manually when the initial xterm opens up.
<cr1901_modern>
sb0: Quickstart "xpra start --start-child=xterm --exit-with-children=yes :100" will start an xpra server on your remote machine. And there's a GUI for the client- I've never used the command line client.
<cr1901_modern>
Anyways... I got off-track: One of the powerful things about Atom is its build plugin- press F9 and you have a one keypress build system if a Makefile, etc is preset in Atom's concept of the Project Root directory. >>
<cr1901_modern>
If you have to set up environments before running build tools in nix using a shell script, I don't think the F9 to build workflow will work w/ nix
<cr1901_modern>
i.e. before running Atom w/ nix binaries I have to source the environment I want. For. Every. Project. ._.
<cr1901_modern>
I kinda like being able to swap out projects w/o killing the running instance of my editor :P
<sb0>
rjo: your newfocus controller doesn't work with artiq-5
<sb0>
AttributeError: module 'artiq.tools' has no attribute 'verbosity_args'
<lkcl>
cr1901_modern: i usually set up chroot jails using debootstrap, schroot, and mount-bind on the home directory (or better just the relevant source/build subdirectory) for that.
<lkcl>
ooo i like the sound of xpra. been looking for something like it for absolutely ages, since i met roger binns two decades ago and his team were working on tarantella
<lkcl>
freenx never really took off and was too complicated
<bb-m-labs>
build #2996 of artiq is complete: Failure [failed anaconda_upload python_unittest_1] Build details are at https://buildbot.m-labs.hk/builders/artiq/builds/2996 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<elmarco>
hi, I am trying to use smoltcp, and it pushes my limits of rust lifetime understanding ;)
<elmarco>
I would like to store a SocketSet in a struct
<elmarco>
whitequark: could you give me a hint? thanks
<lkcl>
whitequark: ping, Record is missing __iter__ which would otherwise mean that nmigen.tools.flatten() would be successful. flatten(rec) presently throws an exception in Record.__getitem__ as that's the python default fallback method for iteration (if __iter__ doesn't exist)
<whitequark>
lkcl: hm, that's not a correct implementation
<whitequark>
a Record is a Value so iteration over it should work the same as iteration over a Value
<whitequark>
which means iterating over bits, not fields
rohitksingh has quit [Ping timeout: 245 seconds]
_whitelogger has joined #m-labs
rohitksingh has joined #m-labs
mauz555 has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 245 seconds]
Gurty has quit [Ping timeout: 258 seconds]
mauz555 has joined #m-labs
rohitksingh has joined #m-labs
<lkcl>
whitequark: unfortunately, it doesn't work that way. Record.__getitem__ is getting items by name in the fields
<lkcl>
so r[5] which would be expected to return bit 5 of the record-as-bits
<lkcl>
instead tries to look for an item in the fields dictionary named "5"
<lkcl>
if Record.__getitem__ was *removed*, such that Value.__item__ was used instead, it *might* actually work as described
<whitequark>
lkcl: yeah, I agree that it is currently broken
<whitequark>
I need to think about the best way to fix this
<whitequark>
it might be possible to support both, but that also seems wrong... hm
<lkcl>
the expectation of Record indexing by items instead of bits is probably why i am going "hmm, adding __setattr__ is the next logical step"
<whitequark>
the only reason Record has a __getattr__ is so you can have fields which are not legal Python names
<whitequark>
I did not think that one through
<lkcl>
flattening to bits (which seems logical) has the risk of accidentally doing eq (or other operations) that lose name information. two disparate Records for example
<lkcl>
the irony of adding __getattr__ is that, actually, we need what Record-with-__getattr__ *can* become
<lkcl>
rather than what it's envisaged [a bit-based system]
<whitequark>
sorry, __getitem__
<whitequark>
not __getattr__, __getattr__ is fine
<lkcl>
ah yeh
<lkcl>
hmmmm, tough one to think through :)
<whitequark>
it might be possible to support strings in __getitem__ and also fall back if a range or int is passed