<awygle>
hm, i wonder if there's an algorithm for "pretty good sequence of colors"
<rqou>
lol i want one too
<awygle>
where "pretty good" means "adding a new one adds a minimum of confusion between it and the existing ones"
<rqou>
kicad and the other-unnamed-but-also-shitty-ecad-software both have godawful default colors
<rqou>
(i assume this is want you want it for? :P )
<awygle>
you have accurately sussed out my motivation (well, accurately enough)
* awygle
awards rqou a gold star
<awygle>
oh i actually know someone who might have an answer to this. to twitter!
<rqou>
some fancy "design" person?
<awygle>
dataviz
<rqou>
dataviz is its own subfield now?
<awygle>
i don't actually know any designer-designers, which is unfortunate, both because that stuff is very interesting and because a friend like that would be very useful
<awygle>
and also, friends are just good things to have
<rqou>
hmm, i'm not sure everybody agrees with that :P
<awygle>
dataviz is at least as distinct from designer as, like, compiler engineer and kernel hacker
<awygle>
even if they both write C++
<awygle>
(or javascript in the former case)
<awygle>
also, i may not know what a designer is. they may not write code at all and just do photoshop.
<rqou>
yeah, i just feel a lot of these boundaries are pretty artificial and unnecessary
<awygle>
that's fair. i feel like they are useful as long as they're not limiting. once it devolves into "you can't sit with us" then it's a problem.
<awygle>
i can say "i'm an embedded guy, not a compiler guy" and it conveys useful if incomplete information to you about my skill set
<awygle>
also, everyone check out @sxywu on twitter, she does really cool work
<rqou>
er, i've seen her posts via the algorithm(TM) before, but i couldn't really figure out "what she does"
uovo has joined ##openfpga
oeuf has quit [Ping timeout: 248 seconds]
wpwrak has quit [Read error: Connection reset by peer]
<azonenberg>
I'm working on the line card design now though
<azonenberg>
this is 2x4 RJ45s
<rqou>
ok
<azonenberg>
i plan to make a dummy board with a mechanical mockup of the footprint and verify before doing this
<azonenberg>
ditto for the sfp
<azonenberg>
in particular stewart/bel fuse do not provide step models
<rqou>
i wanted to spin a very very quick test of bridging SFP and TB3/USB-C
<azonenberg>
i'm a lot less spooked by using a new, complex footprint on an expensive board
<azonenberg>
if i have a step to sanirty check against
<rqou>
azonenberg: want to let me piggyback my test on your mechanical fit test? :P
<azonenberg>
as long as its not a rush sure
<azonenberg>
i wont be doing it for a while
<rqou>
definitely not
<rqou>
also, wtf why is everybody on birdsite suddenly running into the "high-bandwidth over wires is hard" problem at the same time?
<rqou>
i've been shilling "fancy" ethernet for days :P
<gruetzkopf>
PCIe over SFP works far better than it is supposed to be
<rqou>
what do you mean "supposed to be"
<gruetzkopf>
-be
<rqou>
i thought everybody did either that or SAS cable
<gruetzkopf>
pcie cable
<gruetzkopf>
has a few more pins than a SAS cable
<rqou>
afaik nobody has ever run PCIe over its official external cabling
<gruetzkopf>
PCIe-over-SFP-el-cheapo involves turning off host-side SSC and having a local refclock oscillator at the device end
<rqou>
use QSFP? :P
<gruetzkopf>
i haven't even tested 8GT/s mode on a SFP+
<rqou>
should work
<rqou>
i had an 8G one that works at 10G
<gruetzkopf>
5GT/s mode works over FC SFPs i have which are supposed to be good to 4600
<gruetzkopf>
2.5GT/s mode works on 2300 ones
<gruetzkopf>
you're losing quite a lot of range, then, but *shrug*
xdeller_ has quit [Quit: Leaving]
<rqou>
gruetzkopf, azonenberg: anybody got BER estimates for HDMI/DP? :P
<azonenberg>
lol nope
<azonenberg>
I'm just working on this pcb until i get a bit sleepy
<azonenberg>
Was out on a SAR call all day today and yesterday
<azonenberg>
and i have a mass casualty drill tomorrow at 0815
<azonenberg>
So i wont be sleeping much :p
<azonenberg>
(and then i have work to do on the house, then stuff for $dayjob to make up the hours i missed when i was out in the woods)
<rqou>
sounds fun
<rqou>
azonenberg: have they done mass shooting drills yet? :P
<azonenberg>
rqou: This particular one is focusing on an earthquake since that's the main situation where the fire dept would be overwhelmed and need additional responders
<azonenberg>
We're also not trained go into a hot/warm zone, we're not tactical medics
<azonenberg>
That being said, local LE does do them periodically
<azonenberg>
I was out of town on a sar mission but they had volunteers playing casualties for a few of them
<azonenberg>
i recall one was called "Operation Hostile Bookworm" and took place in, predictably, the library
<rqou>
oh wtf
<rqou>
azonenberg: high-bandwidth HDMI cables can be ridiculously cheap
<azonenberg>
rqou: pcie over hdmi cable? :p
<rqou>
i wonder what the BER you would get is
<rqou>
supposedly i read that normal BERs for digital video are atrocious
<rqou>
and ethernet would never allow anything like that
<rqou>
maybe that's why the cables are so cheap
<whitequark>
awygle: i disagree about rust and apache btw
<whitequark>
all you would achieve is less adoption of rust if it was GPL'd
<whitequark>
and as a consequence, we would still have been stuck with shitty C code where it matters
<whitequark>
you're not really negotiating from a position of power when you choose a software license, those days are long gone; there are way too many people who will gladly take your ideas and reimplement them under 0BDS
<azonenberg>
incidentally this is why i bsd'd antikernel
<whitequark>
*0BSD
<whitequark>
like me!
<azonenberg>
And why jtaghal exists, to provide a permissively licensed openocd etc alternative :p
<whitequark>
what you want to do is basically go into policy
<whitequark>
but that requires, like, actual work, not just slapping a LICENSE.txt
<rqou>
huh, so HDMI cables that really are specced for 4x10G are back to the same price point as every other type of cable specced for 4x10G
<rqou>
it's almost like there's a conserved quantity here :P
<rqou>
seriously, why is everybody on birdsite currently learning about "wires r hard"?
<azonenberg>
Because wires aren't really wires :p
<rqou>
it just seems like a coincidence that everybody (including whitequark :P ) is hitting this same problem this week
<rqou>
azonenberg: does 40gbase-t exist in reality?
<azonenberg>
Don't know, don't really want to know
<azonenberg>
10Gbase-T is already unobtainium and super picky about cabling
<rqou>
what's the total analog bandwidth of an SFP+ designed for 10gbits/s rates?
<azonenberg>
i mean you might be able to calculate from the SFF eye opening spec
<rqou>
some maxim appnote claims 16 GHz
<azonenberg>
But they have digital buffers etc in the path
<daveshah>
despite what you would expect, neither use a PLL
<daveshah>
because it is broken on the upduino of course...
<awygle>
lol
<awygle>
wish they'd do UPduino style dirt cheap boards for the other families
noobineer has quit [Ping timeout: 248 seconds]
<whitequark>
hahaha
<daveshah>
I'm pretty impressed he got a MIPI DSI display working without needing a PLL
<rqou>
wtf
mumptai_ has quit [Quit: Verlassend]
ym has quit [Quit: Leaving]
<rqou>
ugh
<rqou>
one of my machines just hit the btrfs "ran out of metadata" issue
<whitequark>
lol btrfs
<whitequark>
why do you run btrfs
<rqou>
what should i be running?
<rqou>
i want CoW snapshots
<balrog>
ENOSPC?
<rqou>
yeah, that
<rqou>
ugh, moving to a new computer while using nightly rust just doesn't f*cking work
<balrog>
did you use btrfs for a while before 3.18?
<rqou>
ok, apparently i just need to copy Cargo.lock
<rqou>
balrog: not sure, i don't remember exactly how old this FS is
<balrog>
ah
<rqou>
debugging all the random issues in nightly rust is a trashfire still
pie__ has quit [Quit: Leaving]
<whitequark>
rqou: zfs or lvm
<whitequark>
and you should check cargo.lock into VCS
<rqou>
i thought you weren't supposed to check in Cargo.lock?
<rqou>
also, zfs on linux is nice and drama-ful
GenTooMan has joined ##openfpga
<rqou>
lvm was just not great IME
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
rohitksingh has joined ##openfpga
<whitequark>
you shouldn't check in Cargo.lock for libraries (which should be tested on CI against latest versions of dependencies *at least*) but should for applications
<whitequark>
precisely to avoid the issue you have hit
<qu1j0t3>
rqou: dramaful? it's been around for a while, surely it's reasonably stable...
<whitequark>
I don't like how much RAM it eats but otherwise it seems okay
<awygle>
There's license drama and recently there was a big issue that got a bunch of press
<qu1j0t3>
oh, license drama. well yeah that's normal for zfs lists........
<rqou>
whitequark: am i technically supposed to eventually make my application work with all the latest versions of libraries? so Cargo.lock just defers the problem
<whitequark>
rqou: um, no.
<whitequark>
Cargo.lock is like -Werror.
<rqou>
meaning?
<whitequark>
you're supposed to update your dependencies regularly, but users of your application should never be exposed to dependencies you haven't tested
<rqou>
ah ok
<rqou>
well, the current error is deep inside the guts of proc_macro2, so i don't think I'll be updating my dependencies anytime soon
<rqou>
anyways, nightly gets a ridiculous amount of churn considering that there's already been a "stable" release
<rqou>
especially since I'm not using any particularly fancy features
bitd has quit [Quit: Leaving]
<whitequark>
uhm
<whitequark>
that's why it's nightly?..
<whitequark>
it sure would have been better to have a shitty design locked in forever /s
<rqou>
worked for unix /s
<rqou>
i guess I've just been disappointed at the new features of the past few releases
<whitequark>
no love for NLL?
<rqou>
what's NLL?
<whitequark>
nonlexical lifetimes
<rqou>
the only major visible new feature in 1.25 is setting struct alignment
<whitequark>
oh, you mean stable
<rqou>
yeah
<rqou>
and the only new feature in 1.24 stable is messing up panic and reverting it
<rqou>
*major new feature
<whitequark>
um, incremental compilation? hello?
<rqou>
that doesn't change what you can write in your code
<whitequark>
that's a major new feature
<rqou>
i was thinking of major features that affect the code i can write
<rqou>
such as nll, which apparently hasn't shipped yet
<whitequark>
that's a really narrow view of useful changes
<rqou>
or letting derive work on arrays with more than 32 elements
<whitequark>
I find that the quality of tooling is far more interesting than fancy language features, of which there are enough already to make for unexpected bad interaction between them
<whitequark>
const generics still don't have a fully specified design because that's... hard
<whitequark>
for example, given struct X<const N>, and a const generic parameter M, should X<M+1> unify with X<1+M>?
<whitequark>
if yes, how far should you go trying to prove equivalence of expressions?
<whitequark>
do you do constant folding? reassociation?
<rqou>
they fixed it for Clone?
<rqou>
anyways, i personally am only really interested in fancy new features and ergonomics improvements
<rqou>
but it seems that nobody is prioritizing these things
<whitequark>
what
<whitequark>
the focus of rust 2018 roadmap is literally "productivity"
<rqou>
ok, well, what i see as an "outsider" is:
<whitequark>
you've, like, read it, right? before starting to whine as usual
<awygle>
personally i'm pretty happy running whatever version i need to of a compiler, because it's not a user-facing tool (unless you're writing a library and then your users are developers)
<awygle>
if i have to pin to rust 1.26.1~ebf6d, oh well
<awygle>
but i don't maintain any widely used software
<whitequark>
kmehall: oh thanks
<kmehall>
...which is apparently publicly editable and somehow not full of spam
<rqou>
O_o i didn't know this existed
<rqou>
since i find rust's issue tracker completely unreadable
<rqou>
ok, so how do i read this spreadsheet? e.g. simd says "done" on april 16
<rqou>
so does that mean that after 6-12 weeks i'll see it?
<awygle>
yes
<awygle>
at least that's my understanding
<rqou>
so NLL says "SOS" under "Plan"
<rqou>
so it's f*cked?
<awygle>
someday i'll learn what "impl trait" means and why it's good
<awygle>
i wish i had more opportunity to write rust
<rqou>
so generators is even more f*cked?
<rqou>
it says "SOS" "not planned"
<rqou>
and "not started" as of 19 march with no further updates
<kmehall>
SIMD stabilization just merged, so it will be in 1.27 = May 10
<rqou>
that soon?
<whitequark>
generators are actually already implemented
<rqou>
wat
<rqou>
so the spreadsheet is wrong?
<whitequark>
and async/await uses them
<whitequark>
I think that line in the spreadsheet is for *standalone* generators
<whitequark>
i.e. not when used as a part of async/await
<rqou>
kmehall: i thought the may 10 release should be 1.26?
<whitequark>
which desugar into generators internally
<rqou>
what's a "standalone" generator?
<kmehall>
rqou: you're right, it's released as beta on may 10, stable on june 21
<whitequark>
a generator explicitly used in code
<rqou>
hmm, since i have no idea what the current design looks like i don't really know what you mean
<whitequark>
|| { yield 1; yield 2; }
<rqou>
right, so i would expect that to create a generator object?
<whitequark>
yes
<rqou>
is that a "standalone" generator?
<whitequark>
yes
<rqou>
so what is a not-standalone generator?
<rqou>
await || { yield 1; }
<rqou>
something like that?
<whitequark>
a generator used internally by async/await
<rqou>
ah, ok
<whitequark>
#[async] fn foo() { await bar(); }
<whitequark>
you should read the spreadsheet keeping in mind that design and implementation happen concurrently on these large features
<rqou>
async-await at least says "on track"
<rqou>
expected in 1.29
<whitequark>
you can't really design them fully in abstract because they touch enough of the languages that unexpected issues arise
<rqou>
which is 4 versions out
<rqou>
or ~20 weeks or 5 months
<whitequark>
yup
<rqou>
huh, actually almost everything says ~1.27-1.29
<rqou>
so i'm going to have a great summer and not a christmas timebomb
<rqou>
:)
user10032 has quit [Quit: Leaving]
<whitequark>
do you see why it's a 2018 roadmap now
<rqou>
yeah, now i see what they're going for
<whitequark>
well, schedules will slip
<rqou>
i figured the rust people have enough experience to not deliver christmas timebombs :P
<whitequark>
it's a software project, schedules always slip
<rqou>
"gotta ship everything before i go on vacation and show up in january"
<whitequark>
nah, that never really happened
<whitequark>
even 1.0, which was quite rushed, wasn't too bad
<whitequark>
unwinding *might* have been a wrong choice
<whitequark>
but lang design decisions are hard and I won't pretend that I know what would happen to Rust without unwinding
<whitequark>
awygle: regarding asm
<whitequark>
the LLVM inline assembly is basically defined by implementation
<rqou>
i just don't see why this is a problem
<whitequark>
what is a problem?
<rqou>
much better than go replacing your supposedly-constant-time code with an "optimized" version
<whitequark>
um
<rqou>
just make asm! be defined as "shoves code into the backend"
<whitequark>
what
<whitequark>
you're being obtuse again
<rqou>
why?
<rqou>
it's always worked this way
<rqou>
or is that also not up to rust's standards?
<whitequark>
"stable" means "is guaranteed to work on newer rust versions modulo bugfixes"
<whitequark>
if LLVM migrates from LLVM to Cretonne, then your proposed solution will break
<whitequark>
or even forget that
<whitequark>
LLVM makes no guarantees about inline assembly syntax
<rqou>
sure, but people have somehow managed to survive that
<whitequark>
people wrote code in C too
<awygle>
hm, i didn't know that. does clang make guarantees?
<whitequark>
nope
<awygle>
wow
<awygle>
that's somewhat horrifying
<whitequark>
nor does gcc
<whitequark>
and gcc has a *fuckton* of bugs around inline assembly
<whitequark>
and gcc's inline assembly is incompatible with clang's
<awygle>
that i knew
<whitequark>
gcc is *way* too permissive about accepting blatantly insane constructs
<whitequark>
if it works on clang, it usually works on gcc too, but not the other way around
<awygle>
inline asm is almost never what i want, i just want to hand-code a function or something
<awygle>
so i usually end up dropping to a separate .s file
<whitequark>
I think module-level assembly might be stabilized before inline assembly
<whitequark>
a major point of contention is gcc's insane register constraint specifiers
<awygle>
i'd be happy about that
<whitequark>
another major point of contention is that if you shove the wrong variable into the wrong register constraint, LLVM asserts
<whitequark>
and there is literally no way to learn why other than reading LLVM sources
<rqou>
is rust trying to explicitly avoid "foo_x86_masm.asm" "foo_x86_gas.S" "foo_x86_nasm.asm" "foo_arm_gas.S" "foo_arm_rvds.S" "foo_ppc_darwin.S" "foo_ppc_gas.S"
<rqou>
?
<rqou>
?:
<rqou>
i suppose avoiding that would be pretty great
<whitequark>
have I mentioned that the code that handles gcc's insane register constraints is horrible?
<whitequark>
many constraints carry additional hidden invariants
<whitequark>
e.g.: es, o, Q, Z, Zy: A memory address operand, currently treated the same as m.
<whitequark>
this doesn't tell you which of these won't work on gcc
<whitequark>
"M: An immediate integer 0x7fffffff." why the fuck is this a constraint
<whitequark>
"A: Special case: allocates EAX first, then EDX, for a single operand (in 32-bit mode, a 64-bit integer operand will get split into two registers). It is not recommended to use this constraint, as in 64-bit mode, the 64-bit operand will get allocated only to RAX – if two 32-bit operands are needed, you’re better off splitting it yourself, before passing it to the asm statement.
<whitequark>
why does this even *exist*
<rqou>
wait, is this gcc?
<whitequark>
this is llvm's documentation for gcc-compatible constraints
<whitequark>
"a: A 32, 64, or 128-bit integer address register (excludes R0, which in an address context evaluates as zero)."
<whitequark>
it's impossible to say since there's no spec
<whitequark>
if you count gcc's implementation as the spec, these would technically be llvm bugs
<whitequark>
but my conscience is incompatible with that
<rqou>
you seem to hate gcc way more than reasonable
<sorear>
whitequark: the answer to all of those are “some instruction needed it”. The constraints are how gcc does isel IIUC and are being abused for asm
<whitequark>
because gcc is a piece of shit whose only redeeming quality is that long ago it was better than a bunch of even shittier proprietary compilers
<whitequark>
sorear: oh my god.
<whitequark>
this is even worse than I thought.
<rqou>
i just use whatever i can get working or is documented to be working, and (at least for some window in time) vendors had a vested interest in making gcc work
<whitequark>
rqou: yes. you love crappy, fragile hacks that have zero thought put into their maintainability
<sorear>
Relatedly: without checking docs, what type is a “TFmode”
<rqou>
well, people claim they work, and in many cases it worked for me
<whitequark>
"works for me" is literally the lowest bar any software can pass
<whitequark>
gcc is "works for me, the compiler"
<whitequark>
don't even get me started on glibc
<balrog>
gcc has improved a bunch since 4.x
<balrog>
dunno about glibc
<gruetzkopf>
guess who's currently running 802.11n@2.4GHz right in the middle of thousands of DC-Switching relays
<whitequark>
yes. because clang forced it to improve
<balrog>
having more than one good compiler available is a good thing
<whitequark>
many of these gcc improvements are just outright copied from llvm/clang
<awygle>
and many devs are still salty about it
<balrog>
clang also is forcing MSVC to improve
<whitequark>
and that's a good thing
<awygle>
have you seen this thing with ASTs and emacs?
<balrog>
(since e.g. Chrome is now compiled with clang-cl)
<whitequark>
balrog: some people speculate that MS may replace their compiler with clang
<awygle>
that would be pretty in keeping with New Microsoft
<rqou>
works for me and whoever wrote the document/tutorial
<whitequark>
I think it's not very close because you have loads of weird shit like C++/CX
<gruetzkopf>
(i'm guessing somewhere between 7600 and 8900 relays)
<rqou>
ugh, f*cking wifi here
<whitequark>
Clang will likely never support C++/CLI
<rqou>
awygle: AirBears is garbage, news at 11? :P
<whitequark>
however, I think it is likely that MS will ship clang with MSVC, optionally
<rqou>
wait whitequark you also knew about C++/CX?
<rqou>
i just found out about that a few days ago
<whitequark>
um
<balrog>
> produces entirely unmanaged code
<balrog>
lol
<whitequark>
C++/CX has been considered in clang since like 2012
<gruetzkopf>
(60s grade control logic best control logic)
<rqou>
how come you don't call C++/CX and C++/CLI godawful hacks?
<whitequark>
I am not familiar with C++/CX at all
<whitequark>
it doesn't seem any more inherently broken than, I dunno, Objective-C++
<whitequark>
and yes I have used Objective-C++
<rqou>
years ago my housemate tried to use Objective-C++11
<rqou>
mixing a C++ lambda, a boost lambda, and an objc lambda-like thing
<rqou>
it caused llvm to assert :P
<rqou>
also, wtf
<rqou>
why would you have used Obj-C++?
<whitequark>
solvespace
<rqou>
why does that require Obj-C++?
<whitequark>
solvespace is written in C++?
<rqou>
what's the Obj- part for?
<whitequark>
a Cocoa UI
<rqou>
ugh
<rqou>
and this is why i have completely given up on native gui toolkits
<awygle>
this is why i've completely given up on mac
<whitequark>
lol
<rqou>
browsers are the best cross-platform gui toolkit
<awygle>
does qt use native widgets now btw?
<awygle>
i saw someone implying that was the case the other day
<rqou>
i don't get this obsession with "native widgets"
<whitequark>
browsers are the Unix of UIs
<whitequark>
they sort of work, but everything is fractally broken
<awygle>
browsers are the unix of everything
<rqou>
as long as widgets connect correctly to IMEs and a11y it doesn't matter if they're "native"
<whitequark>
sure it does
<whitequark>
all the usual platform keybindings should work
<rqou>
i specifically _don't_ want that
<rqou>
i want the _same_ keybindings to work on every platform
<whitequark>
I don't
<awygle>
i would like it if both of those things were true but since that's impossible i'll take platform
<rqou>
have fun swapping between Ctrl and ⌘ all the time then
stefanct has quit [Ping timeout: 256 seconds]
<whitequark>
people who switch platforms are a minority
<rqou>
i especially hate programs that have one set of keybindings for *nix/windows and a totally different set for macos
<awygle>
blame apple
<awygle>
(see above)
<rqou>
and then they use apple's stupid little icons and it takes me forever to figure out what actual key they mean
<gruetzkopf>
blender is (was when i last used it) using SGI irix keybinds on all platforms
<rqou>
sure
<rqou>
whatever
<whitequark>
fuck blender
<whitequark>
everything about blender's UI is awful
<gruetzkopf>
(which is totally fine if you're running it on irix)
<whitequark>
I'd rather stick my hand into an actual blender
<rqou>
it's afaict fully scriptable with python
<whitequark>
yes, and also you can remove your tonsils through your asshole
<rqou>
wtf why so hostile?
<rqou>
blender always appeared to work just fine?
<whitequark>
because you're responding to "blender's GUI is awful" with "don't use blender's GUI, use something completely different"
<sorear>
because you’re not making much sense?
<whitequark>
^
<whitequark>
all your arguments boil down to "it works for me therefore it's objectively good, and here it doesn't work for me therefore it's objectively bad"
* awygle
closes irc, goes to make dinner
* whitequark
is really irritated
<whitequark>
this is exactly how we got into this hole with modern software
<rqou>
i never said anything about "objectively good"
<rqou>
more like "accomplished my goal, good enough"
<whitequark>
"accomplished rqou's goal" is not necessary and sufficient for software to be "good enough"
<rqou>
well, i don't have infinite time to go and make everything better. so if it accomplishes my goal of e.g. "finished problem sets" I'm satisfied
<pie_>
<whitequark> yes, and also you can remove your tonsils through your asshole
* pie_
wont even bother reading the rest of scroll, today has peaked
* pie_
goes back to playing with coq
<whitequark>
pie_: it's an idiom okay
<whitequark>
it has a counterpart idiom for especially odious hacks, "removing your tonsils through someone else's asshole"
<pie_>
now you have me thinking about removing tonsils through assholes and induction on assholes
<whitequark>
rqou: thank you for nicely demonstrating why academic code is so universally terrible
stefanct has joined ##openfpga
stefanct has quit [Changing host]
stefanct has joined ##openfpga
<gruetzkopf>
at this point in this project i'd rather rip out all the processors in this project exept for one and replace them with programmable logic
<pie_>
dont cross the streams kids.
TAL has joined ##openfpga
<gruetzkopf>
sadly that's not possible
<awygle>
... I threw out my back.
<awygle>
Since when am I this old
<rqou>
gruetzkopf are you working on a telephone exchange? :P
<gruetzkopf>
no
<rqou>
or is this a signal controller?
<gruetzkopf>
the relay system is one
<rqou>
wait, modern train signals still use relays?
<rqou>
not the internet of targets?
<qu1j0t3>
:)
<rqou>
"the 'S' in 'IoT' stands for security"
<gruetzkopf>
"modern"
<gruetzkopf>
this class of interlocking systems was designed in the early 60s
<rqou>
oh, is this decommissioned?
<gruetzkopf>
hundrets of them are still in operation, with some of germanys biggest stations having such systems
<whitequark>
early 60s is recent in railway time
<gruetzkopf>
the oldest relay-based interlocking system i know of that's still in operation in germany is from 1953, the oldest overall (lever-frame) from 1897
<gruetzkopf>
there's even two newer relay-only systems in germany
<gruetzkopf>
late 80s
<gruetzkopf>
(like types, not installations)
<gruetzkopf>
find me one semiconductor-based system that'll still be in full manufacturer service in 75 years ;)
<TAL>
better don't tell em that those "modern signals" are standardized since 1935 :P
<qu1j0t3>
:)
<balrog>
whitequark: just like how 8 bit PIC is a pile of odious hacks? :D
* whitequark
vomits
<balrog>
What if I told you that it looks like they’re planning to release more chips in those series....
<whitequark>
no
[X-Scale] has joined ##openfpga
<whitequark>
the worst timeline
<balrog>
I don’t get why people like it so much. Are the peripherals that good?
<whitequark>
no they suck
<whitequark>
you can't even do PORTA|=1
<whitequark>
since the input and output registers are multiplexed
X-Scale has quit [Ping timeout: 248 seconds]
[X-Scale] is now known as X-Scale
<cr1901_modern>
whitequark: I think TRISA = 0x00 will ensure PORTA |= 1 works. Also I think "LATA |= 1" will work if PORTA is in input mode.
<whitequark>
cr1901_modern: huh, I can't believe I missed LATA
<cr1901_modern>
I haven't actually used it yet. When I do PORTA |= 1, I treat anything set as input ("TRISAbits set to 1") as having undefined output latch values. >>
<cr1901_modern>
Since "TRISAbits = 0" will feed the value of the pin back to PORTA during a read of PORTA, this works for any pins set as output.
<cr1901_modern>
But this is probably a bad idea and I should actually use LATA as intended :P
<q3k>
ahhh, I haven't seen the letters 'TRISA' since I did PIC development in middle school
<q3k>
holy flashback batman
<qu1j0t3>
looks like the acronym for dodgy legislation