rohitksingh_work has quit [Ping timeout: 268 seconds]
digshadow has joined ##openfpga
mwk has quit [Ping timeout: 260 seconds]
mwk has joined ##openfpga
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- In tests, 0x09 out of 0x0A l33t h4x0rz prefer it :)]
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 256 seconds]
s1dev has joined ##openfpga
s1dev has quit [Client Quit]
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has quit [Ping timeout: 240 seconds]
pie_ has quit [Ping timeout: 244 seconds]
pie_ has joined ##openfpga
Miyu has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
finsternis has quit [Quit: leaving]
finsternis has joined ##openfpga
pie_ has joined ##openfpga
rohitksingh has joined ##openfpga
<shapr>
HI
daveshah_ has joined ##openfpga
_florent__ has joined ##openfpga
eddyb_ has joined ##openfpga
sorear_ has joined ##openfpga
rqou_ has joined ##openfpga
DrLuke__ has joined ##openfpga
_florent_ has quit [Ping timeout: 240 seconds]
eddyb has quit [Ping timeout: 240 seconds]
daveshah has quit [Ping timeout: 240 seconds]
sorear has quit [Ping timeout: 240 seconds]
rqou has quit [Ping timeout: 240 seconds]
DrLuke has quit [Ping timeout: 240 seconds]
_florent__ is now known as _florent_
rqou_ is now known as rqou
daveshah_ is now known as daveshah
eddyb_ has quit [Changing host]
eddyb_ has joined ##openfpga
eddyb_ has joined ##openfpga
eddyb_ is now known as eddyb
rohitksingh has quit [Quit: Leaving.]
azonenberg_work has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
ironsteel has quit [Quit: Ex-Chat]
sorear_ is now known as sorear
Adluc has quit [Excess Flood]
Adluc has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
<rqou>
azonenberg_work: how's ZoidbergHouse? :P
* rqou
is last-minute packing for bsideslv because i am good at adulting
<azonenberg_work>
rqou: was out with sar all weekend but we have 3 pieces of sheetrock hung
<rqou>
YOU'RE STILL DOING SAR?!?!
<azonenberg_work>
going on a hanging rampage after work tonight trying to finish one room
<azonenberg_work>
Duh
<rqou>
your priorities are amazing
<rqou>
(in a good way)
<rqou>
so can you move out of your hotel room the instant you sheetrock the bedroom, or do you still need additional inspections?
ZipCPU_ has joined ##openfpga
<azonenberg_work>
We need the final electrical inspection of the whole house, which implies sheetrock on all of the ceilings and lower halves of walls where there are outlets
<azonenberg_work>
Technically we could pass final electrical without light-free areas of ceilings or upper walls being sheetrocked but realistically i dont want to put the outlets up until we tape and mud
<azonenberg_work>
and the walls hold up the ceiling edges
<azonenberg_work>
So we basically have to sheetrock everything
<azonenberg_work>
Then the city has a final inspection of the whole house looking for things like handrails on stairs, smoke detectors being installed, etc
<rqou>
wat
<rqou>
are handrails actually required in residential buildings?
ZipCPU has quit [Ping timeout: 248 seconds]
<rqou>
so fancy renderings of floating staircases aren't actually allowed?
<azonenberg_work>
Yes, the IRC even has requirements for min/max size to ensure it's grippable
<azonenberg_work>
The handrails on the path front of the house by the driveway actually do not meet those requirements, they're too fat to comfortably fit a hand around, but since it's an existing install we're not required to replace it
ZipCPU_ is now known as ZipCPU
<azonenberg_work>
The code is only applied to stuff you changed
Miyu has quit [Ping timeout: 264 seconds]
<mithro>
Morning everyone!
<daveshah>
evening mithro
noobineer has joined ##openfpga
<mithro>
daveshah: How was nextpnr dealing with routing off carry chains without route-through luts?
<daveshah>
mithro: they are always inserted in the packer
<daveshah>
route through luts still wouldn't work, as you would need to also reserve space above the carry chain
<daveshah>
so it's easier just to dispose of them in the packer
<mithro>
daveshah: The routing off carry chains was special cased?
<daveshah>
Yes, just as arachne-pnr did (it has to be a special case for the above reason)
<mithro>
daveshah: I'm wondering if it should have been done at tech mapping stage? I guess the fact its "route through" kind of implies it goes in the pnr?
<daveshah>
mithro: no, it has to be done in pnr
<mithro>
daveshah: Why?
<daveshah>
there are cases such as a carry chain being too long for the device, incompatible ff types, etc that the synthesis tool can't really deal with
<rqou>
<rant> why is texlive always a massive piece of shit every time i need to upgrade my system?
<rqou>
its upgrades are always ginormous and slooooow
<mithro>
daveshah: Well, there is always the question of how much device info you want at each stage? IE there is no reason the synthesis couldn't know about these facts
<daveshah>
mithro: True, but it is conventional for it not too
<daveshah>
e.g. if you were floorplanning
<daveshah>
you would have less than the full device height available
<daveshah>
so you'd have to split the carry chain early
<daveshah>
and you don't want full floorplanning support in Yosys just for some tiny edge case
<daveshah>
whereas all that info is in the PnR tool already
<rqou>
seriously every time i need to upgrade texlive in particular i always seem to hit a lame mirror that's broken
<rqou>
remind me again why academia keeps using tex?
<mithro>
daveshah: I've always pondered why do we techmap to the smaller parts rather than the to the tile level?
<daveshah>
Techmapping to tile level would be crazy
<daveshah>
You would almost certainly end up combining stuff too far apart and then causing routing congestion
<mithro>
daveshah: Why? With DSP and RAM tiles you are normally techmapping to the whole tile?
<daveshah>
Yes, because they can't be split anyway
<daveshah>
(DSP not with ECP5 anyway)
<daveshah>
with logic it's much harder to work out what to pack together
<awygle>
i will agree that packing has always felt like a hack
<daveshah>
You mean packing as in combining LUTFFs, or packing entire tiles?
<awygle>
i think you'd get better QoR to move it further towards the end of the process though. if you could place _within_ a tile successfully, i mean
<daveshah>
Yes that's exactly what nextpnr and arachne do
<awygle>
either/both
<awygle>
if you could individually place flip flops you'd get better results than placing a full LC
<awygle>
is my guess
noobineer has quit [Ping timeout: 256 seconds]
<awygle>
but it makes the placer tremendously more complex of course, so we don't
<mithro>
daveshah: Like it feels like if you mapped adders to a custom packed tile structure rather then using low level logic and then packing at a later stage could be interesting
<daveshah>
On the ice40 there's little difference because they are hard to separate
<daveshah>
On the ecp5 and 7series there would be an argument to placing individual cells at some point
<daveshah>
mithro: not even sure what you mean?
<daveshah>
The floorplan issue I mentioned, as much as other things, mean this kind of stuff is much better done in PnR
<mithro>
daveshah: Say you had an 8bit A+B adder -- it seems like there should be maybe 1 way to pack that adder efficiently into a ice40 tile
<mithro>
So if you had an 8bit A+B adder, you should just map it to that form?
<mithro>
I also wondered if the synthesis tool should pass down multiple different possible representations to the pnr tool - IE this could be implemented using a DSP block or this logic...
<awygle>
i'm more on board for that
<awygle>
although idk how it could be done efficiently
<awygle>
you'd basically have to run two independent placements
<awygle>
(which maybe isn't a big deal given that we're essentially single-threaded currently)
<rqou>
fuck shouldn't have upgraded gimp
<rqou>
new gimp is broken
<awygle>
i find the idea of "linux distributions" kind of weird
<awygle>
apropos of very little
<rqou>
i'm starting to hate distros
<rqou>
unfortunately i don't have time to manually curate packages myself, so i steal their free labor
<rqou>
right now i have hilarity going on because cmake can't be upgraded because kicad is held?! anybody know wtf is going on?
<rqou>
also huh, apt is much smarter than apt-get
<awygle>
it's upsetting that "curate packages" is a thing we need to do
<rqou>
i mean, there's the "everyone is an ISV" world that i would use for anything i write, but that's not the most efficient use of resources such as memory or storage
<awygle>
... i can always tell when i slept badly because i _say things like that_
<rqou>
although with the current containerization trend we seem to be doing this anyways
<Ultrasauce>
btw i use arch
<rqou>
i've been considering moving to weebdist for a while
<awygle>
mercy main btw
<rqou>
but i didn't want to ever sit down and do it and figure out how much debian dependence i have in my system
<rqou>
e.g. most of my systems have a screwy networking config
<rqou>
apparently using the debian mechanism
<rqou>
but other than that i'm pretty tired of angry-germans-dist
mumptai has joined ##openfpga
<awygle>
tfw your development vm has libreoffice installed
<rqou>
yeah, everything pulls that in for some reason
<rqou>
angry-german-dist dependencies are a massive tangle
<awygle>
i suspect it was just installed by default in ubuntu 14.04 or whatever this is
<awygle>
it's fun to watch packages scroll by when upgrading after a long time. "hello libpurple my old friend...."
<awygle>
lol xul. is xul dead? xul feels dead
<balrog>
xul is dead
<balrog>
who's using it?
<awygle>
idk for sure but i bet it got pulled in by thunderbird (which also sort of deserves a lol)
<awygle>
ha! thread on an archive of netscape.public.mozilla.xpfe, "is xul dead", dated 13 years ago
<awygle>
maybe xul was never properly alive at all...
<jn__>
is it coincidence that XUL sounds like Cthulhu? ;)
<rqou>
awygle: xul was finally killed for real a few years ago
<rqou>
`firefox -app` is the immediate replacement
<rqou>
and the other day at $WORK i still saw something using it
<rqou>
xul has been used in quite a few proprietary closed-source line-of-business things over the years
<rqou>
since it was the first (and ahead of its time) "make web apps native" project
<awygle>
cyrozap: wow there's a _lot_ of baggage in that essay before we even reach the first header
<cyrozap>
rqou: In my experience, software devs are terrible at packaging, and either release packages that do sneaky/terrible things (collecting user system information, installing into /usr/local, overwriting other files on the system, etc.), or release docker containers (because they've never heard of "dependency management"
<cyrozap>
)
<rqou>
i personally would do the latter but without the docker :P
<rqou>
/opt/foobar/bin/statically-linked-tool
<awygle>
is /usr/local/ not where stuff's supposed to go?
<awygle>
i can't keep track, we've changed it like a dozen times
<rqou>
/opt usually works
<awygle>
why does /opt exist even
<awygle>
is it short for "optional"?
<shapr>
decades ago that was where optional things were installed
<shapr>
I first saw it on Sun OS
<awygle>
but i thought that was what the /bin and /usr/bin split was about
<awygle>
(i don't really care that much about the answers to these questions, btw)
<shapr>
oh, nm then
<shapr>
was gonna hit you with some history
<shapr>
from what I remember using Unix in the 80s, /usr was originally what /home is now
<awygle>
hm i approve of the idea of /opt/<package>/<literally everything from the software>
<awygle>
but i feel like i rarely if ever see that
<rqou>
ISE does that :P :P :P
<awygle>
oh don't forget about /sbin lol
<cyrozap>
rqou, awygle: The best thing to do as a developer is to make your package able to be built easily and repeatably--that way, users won't _need_ your binary package because they can just build it themselves. This means writing build scripts, generating an exhaustive list of your dependencies, and possibly using a CI system.
<etrig>
awygle: ever see gobolinux?
<rqou>
but it _also_ fucks up the rest of the system somehow
<awygle>
etrig: used and contributed to it :)
<cyrozap>
awygle: /opt is for ISV-style software, /usr/local is for stuff you build yourself on your own machine that isn't managed by a package manager.
<awygle>
so we have /sbin, /bin, /usr/bin, /usr/local/bin, and /opt/bin before we even get to package-specific stuff
<rqou>
cyrozap: sure, i'd definitely want those things too, but once i have them i no longer really need the distro
<rqou>
and i can stop dealing with angry germans
<etrig>
awygle: cool! I thought it had some really neat ideas
<cyrozap>
awygle: No /opt/bin
<awygle>
cyrozap: i have some issues with the idea that "users" build anything
<cyrozap>
awygle: It's /opt/vendor/<whatever>
<awygle>
cyrozap: "The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use"
<etrig>
why would you build stuff yourself that isn't managed by a package manager? :)
<awygle>
per shapr's link
<rqou>
etrig: because angry germans spend forever bikeshedding and never updating the packages i care about?
<rqou>
see for example: kicad
<etrig>
I don't know what that means
<awygle>
why can't i just do "make rpm", anyway?
<rqou>
angry germans = Debian maintainers
<awygle>
we can have both of these things, or at least it seems like we should be able to
<cyrozap>
etrig: Development, small things that you just want in a */bin somewhere but aren't large enought to bother generating a package.
<rqou>
cyrozap: "Your distro has made all of these [packaging tools] available and well documented."
<rqou>
HA
<etrig>
I'd probably avoid it too if I had to write a spec file or whatever the debian equivalent is
<rqou>
funny
<rqou>
IME both debian and rpm-based distros are disasters in different ways
<cyrozap>
awygle: I'm a user, and I build non-packaged software all the time. I even package software that either isn't officially packaged or the official package sucks.
<cyrozap>
Praise be to AUR.
<awygle>
cyrozap: okay, let me rephrase. i have issues with the idea that "user"s _should have to_ build anything
<awygle>
etrig: yaeh agreed, gobo had some great ideas, although a lot of them were sort of unfortunate in their necessity. "great workaround for a thing that should never have existed" kind of thing
<rqou>
cyrozap: anyways, "maintainers serve a social purpose" is one reason why i _dislike_ Debian
<cyrozap>
awygle: And I have issues with the idea that "only the software dev is capable of building their software because their build process isn't documented anywhere". I have no problems with binary software distribution--I just see "Just use the Docker container!" a lot when building the software myself fails.
<awygle>
i agree with all of those things
<rqou>
due to the impression they always give off of "angry Germans who yell at you if you aren't 'in the loop' enough"
<cyrozap>
rqou: Yall need to to install Arch :P
<rqou>
I've been considering it
<awygle>
i just don't necessarily see how "linux distros are a good idea" falls out from them *shrug*
<rqou>
I'd probably be less unhappy with weebs than angry Germans :P
<rqou>
although i suppose these aren't mutually exclusive categories :P :P
<etrig>
pkgbuild at least seems intuitive enough that there's no excuse to not create a package for everything
<rqou>
IME debian was completely impossible to understand other than "use checkinstall"
<awygle>
cyrozap: mostly unrelated - how do i read the entire text of these grey half-quotes on the right hand side of this essay you linked me?
m_w has joined ##openfpga
<rqou>
rpm was _even more_ impossible to understand until i discovered fpm -- effing package manager
<cyrozap>
awygle: Distros are a convenience thing--other people can make sure that all your programs and libraries are up to date so you don't get pwned, and so that all the distributed software can be installed and will work and won't conflict with each other. IMO rolling-release distros are the best way of handling this, but distros like Debian and Centos are nice when you have LOB apps that you need to
<cyrozap>
maintain on those systems and you don't want those apps breaking after an update.
<rqou>
i noticed you didn't include Ubuntu in that list :P
<rqou>
(IME Ubuntu breaks everything every major update)
<azonenberg_work>
cyrozap: what annoys me about debian is that they dont push critical bugfix releases
<azonenberg_work>
only security patches
<azonenberg_work>
they dont backport*
<azonenberg_work>
which means that you can lead to situations in which a critical package will segfault under common circumstances and be rendered totally unusable
<azonenberg_work>
and they wontfix until next stable release
<shapr>
I just used that yesterday to get GHC 8 on a work CentOS VM
<shapr>
props to jens petersen
<cyrozap>
Also, while we're all talking about packaging, reproducible builds are pretty interesting: https://reproducible-builds.org/
<awygle>
reproducible builds are one of those things that confused me for a long time because i just assumed we'd always had them
<awygle>
i view them as a necessary prerequisite for any serious attempt to improve the general packaging ecosystem
<shapr>
cyrozap: I argue necessary
<awygle>
shapr: you missed :)
<shapr>
missed the smiley?
<awygle>
no, i'm the one who said necessary, not cyrozap
<shapr>
yeah, I also assumed that all builds were reproducible
<shapr>
right, you got there first
<awygle>
ahh okay, i thought you meant "i argue with the idea that they're necessary"
<cyrozap>
Reproducible builds especially interesting from the perspective of package signing and distribution, since with a reproducible build _anyone_ can build packages and host a mirror using those built packages because they'd be bit-for-bit identical to the officially-signed packages: https://www.gnu.org/software/guix/blog/2017/reproducible-builds-a-status-update/
<shapr>
oh no
<shapr>
no I agree with you
<awygle>
woo violent agreement
<shapr>
yes!
<shapr>
except gcc and many compilers build in a timestamp by default
<shapr>
I was talking to one of my google friends about this recently
<shapr>
google wants timestamps in binaries so they can figure out which code led to bugs
<shapr>
but suddenly bazel isn't nearly as useful
<shapr>
so, much longer build times for a 'production' build, or near instant bazel builds for something that works but can't go into production
<awygle>
why do you need timestamps to figure out which code led to bugs
<shapr>
don't know
<awygle>
if it's a reproducible build the hash should suffice
<shapr>
I'll ask him next time he's in town
<shapr>
awygle: just realized PnR seeds mean you can get reproducible FPGA bitstreams
<awygle>
wow cool busybox grep, just spit out binary files on match
<awygle>
shapr: should be able to, yeah
<shapr>
I was talking to a startup in NYC, but they didn't vendor their Go code, so I turned them down.
<shapr>
I'm not willing to debug code if I don't know which code is in production.
<daveshah>
nextpnr should be reproducible, file a bug if it isn't
<daveshah>
It actually prints checksums at different points for analysis of this
<qu1j0t3>
shapr: what?
<qu1j0t3>
shapr: do you mean they didn't have reproducible build/deploy, or?
<cyrozap>
daveshah: You mean building nextpnr is reproducible? Or that the P&R'd netlist is reproducible?
<shapr>
qu1j0t3: Go packages get HEAD from github.com, so every build could give you a different binary
<daveshah>
The PnRnd netlist and bitstream should be reproducible with the same seed
<qu1j0t3>
shapr: Ah! thanks
<shapr>
You can specify a git hash, that's all the versioning Go has at the moment
<daveshah>
We've had a few bugs where we've relied on unordered map ordering, so it's been reproducible only on the same machine
<daveshah>
But hopefully those are all gone now
<shapr>
heh "unordered map ordering" :-)
<cyrozap>
daveshah: Ah, cool!
<shapr>
daveshah: yeah, cool stuff :-)
<daveshah>
PnR tools are basically impossible to debug if not reproducible
<daveshah>
So it's pretty much a necessity
<rqou>
^ agree
<rqou>
xc2par was specifically made reproducible because of this
<shapr>
on the other end of the scale, some neural network libraries perform better because updates to weights are not thread safe
<cyrozap>
daveshah: Of course now you need to make sure nextpnr itself can be reproducibly built (or at least has really detailed version information), so that people can actually build the exact version of nextpnr that generated their bitstreams.
<cyrozap>
It's reproducibility all the way down :)
<daveshah>
Yes the main requirement there is that both a specific icestorm/Trellis and nextpnr version are needed for reproducibility
<awygle>
it is ultimately inconsequential but it really bothers me that it's impossible to coordinate getting movers to help you move from one apartment building to another in a race-condition-free manner
<rqou>
lolol
<rqou>
if you're in California, you can pretty easily go to home despot and hire some mexicans
<awygle>
lmao the TODO.md for libui contains the bullet point "remove whining from source code"
<awygle>
libraries that only support web and mobile should come up with a new way to refer to themselves so as not to pollute the "native" and "cross-platform" namespaces
s1dev has joined ##openfpga
azonenberg_work has quit [Read error: Connection reset by peer]
azonenberg_work has joined ##openfpga
azonenberg_work has quit [Ping timeout: 260 seconds]
<openfpga-bot>
[jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fNMml
<openfpga-bot>
jtaghal/master c89392f Andrew Zonenberg: Continued work on Doxygen coverage for jtaghal
mumptai has quit [Remote host closed the connection]
azonenberg_work has joined ##openfpga
<rqou>
random observation: mobile payments seem to actually work pretty consistently nowadays here in the US
<rqou>
maybe eventually we'll stop being in the stone age
<rqou>
(of course, they're rarely accepted, but they seem to work correctly where they are)
<pie_>
inb4 cash banned
<awygle>
quick space industry drama detour
<awygle>
planet released their LST radio today
* jn__
is one of those weird angry germans that like cash
<awygle>
we've now gone back in time to SmallSat 2016
<rqou>
eli5 for someone who cannot into space?
<awygle>
planet (nee planetlabs) made a big splash at smallsat 2016 by scheduling a talk to open source their low speed radio
<awygle>
and an equally big splash by ... not showing up for said talk
<awygle>
i think some people may have quit over it? not sure
<awygle>
but basically the suits sad "no, we can't open source this" at the 11th hour
gnufan1 has joined ##openfpga
<rqou>
was that your former employer?
<awygle>
no
<awygle>
that was planetary resources
<awygle>
yes all the names sound the same
<rqou>
lol
<rqou>
so why can't i "just" run wsjt as the low speed radio protocol?
<sorear>
asteroid energy is the fun one
gnufan1 has quit [Ping timeout: 240 seconds]
<awygle>
that was us, basically. asteroid mining.
<awygle>
rqou: i have no idea what wsjt is but you probably can
<rqou>
it's one of the ham radio protocols
<rqou>
although tbh you probably don't want to use any ham software directly since they all seem to be clusterfucks from a software engineering perspective
<rqou>
seriously, have no ham software devs ever heard of "source control" or "the open-source movement"?
gnufan1 has joined ##openfpga
<mIKEjONES>
rqou: oy, there's a good number of SDR tools out there that still come version controlled via tar cfz
gnufan1 has left ##openfpga [##openfpga]
azonenberg_work has quit [Read error: Connection reset by peer]
azonenberg_work has joined ##openfpga
Bike has joined ##openfpga
Miyu has joined ##openfpga
m_w_ has joined ##openfpga
m_w_ has quit [Remote host closed the connection]
<s1dev>
rqou, I mean, many physics codes are version controlled with cp -r simulation_{,_bak} :P