<openfpga-github>
[openfpga] rqou pushed 1 new commit to master: https://git.io/vpSd2
<awygle>
how does semver et al handle things like this? i mean, your thing won't build unless you have rustc 1.26, but that change neednt have broken your API at all
<rqou>
well, my version starts with 0.0.*, so i don't care at this point :P
<awygle>
yes but in the general case
<whitequark>
awygle: it doesn't
<awygle>
bleh
<awygle>
i was afraid you'd say that
<whitequark>
awygle: it's just like any other dependency
<whitequark>
you may bump your dependencies without breaking your API
<whitequark>
since, in principle, any dependencies you need are private
<rqou>
yeah, i've complained before that rust isn't really great at the "stable ABI" thing unless you restrict yourself to a C interface
<whitequark>
um
<whitequark>
rust doesn't claim to provide a stable ABI
<rqou>
i know
<rqou>
still sucks
<rqou>
but then again, C++ doesn't officially provide a stable ABI either
<whitequark>
if you have cross-crate inlining it is impossible to provide a stable ABI at all
<whitequark>
so that would necessarily pessimize your code, too
<rqou>
and people manage to tiptoe around it enough that windows programs only crash because of ABI mismatches occasionally
<awygle>
i don't understand how a stable ABI is really relevant to what i said about compiler versions
<rqou>
i guess it isn't directly
<awygle>
well, i guess it's not a compiler version so much as a language version. but w/e
<whitequark>
aarrgh
<whitequark>
such stupid bugs
<whitequark>
so much time
GenTooMan has quit [Quit: Leaving]
<whitequark>
awygle: so I've realized I kind of want uh
<whitequark>
SystemPython
<awygle>
lmao do tell
<whitequark>
writing FSMs in Migen by hand is extremely tedious
<whitequark>
and most programmers are just one big FSM
<rqou>
didn't we have this argument like a year and a half ago?
<rqou>
:P
<whitequark>
rqou: did we?
<rqou>
there was a MyHDL vs Migen discussion
<whitequark>
oh
<rqou>
and deep vs shallow DSL embeddings
<whitequark>
yeah, I don't think deep embedding is the right way *in general*
<awygle>
whitequark: if you have other shit to do, don't let me hold you up. i can always use something else for this test if this isn't work that would happen anyway.
<whitequark>
but there are definitely *some* cases where it's appropriate
<whitequark>
awygle: well I want to finish this already
<whitequark>
it almost works
<awygle>
yeah i get you lol
<awygle>
rqou: have you worked with myhdl?
<awygle>
is it good?
<rqou>
not particularly
<awygle>
it doesn't seem substantially different than migen
<rqou>
it seemed like a neat idea
<rqou>
but i also didn't use it extensively
<whitequark>
a weird consequence of using this FXMA chip is that any bus contention becomes an oscillator
<whitequark>
and a pretty high-frequency one
<whitequark>
we could... put a trace under the FXMA108, detect the harmonics, and if they're present, light a LED
<whitequark>
:P
<whitequark>
s/harmonics/crosstalk/
<rqou>
god, rust error types have so much boilerplate
<whitequark>
rqou: are you using the failure crate?
<rqou>
no?
<rqou>
should i?
<rqou>
i usually avoid pulling in random crates
<whitequark>
yes
<whitequark>
it's the official replacement for std::error
<rqou>
how are there so many random "official" replacements for things that have no real evidence of them being official?
<gruetzkopf>
hm
<gruetzkopf>
accidentally ran HDSL at 2304 kbit/s/pair over 8000m cable, instead of the planned 1152/pair
<gruetzkopf>
need to get the NMS up and look at the link parameters
<whitequark>
rqou: of course they have
<whitequark>
everything in rust-lang-nursery is official
<rqou>
huh
<rqou>
i interpreted it as "stuff the team wanted to take over"
<rqou>
but not "std-level of official"
<whitequark>
what does that even mean?
<rqou>
as in "somebody wrote this nice code, let's hijack it because of the power of F/OSS"
<whitequark>
that would be an asshole move
<whitequark>
rust-lang-nursery is "things that are going to be standard but aren't quite std-quality yet"
<whitequark>
(they won't necessarily ever be *in* the std crate, though many will)
<rqou>
but is it maintained by "the rust developers"?
<whitequark>
it's maintained by whoever maintains it
<rqou>
i thought they were packages written by random people that the rust developers convinced to hand over maintenance
<whitequark>
once nursery crates go to rust-lang org, the org is responsible for their quality
<whitequark>
while they're in nursery, they may not be "good enough" yet
<whitequark>
in practice that usually means that it's a massive improvement over whatever's already in std but it'll have some breakage before it goes to rust-lang
<rqou>
but the original authors can always say "no, i'm a control freak, i don't want that"?
<whitequark>
then the crate would have never been in nursery in the first place
<whitequark>
really, only crates written with explicit intent of becoming *the* standard ones get htere
<whitequark>
awygle: turns out the signal integrity of 30 MHz over shitty connectors is not so good
<whitequark>
my scope fails to decode SPI at least
<whitequark>
though granted its decoders aren't all that good either
<whitequark>
oh no I was using it wrong
<rqou>
wait a sec
<rqou>
whitequark: the failure crate is v0.1.1?
<rqou>
that seems... sketchy
<whitequark>
doesn't matter
<rqou>
because?
<whitequark>
because it's a bogus reason
<rqou>
it's not a bogus reason?
<rqou>
i don't want to unexpectedly end up needing left-pad or backdoorme
<rqou>
and "very low version numbers" is usually a heuristic for "not very good"
<whitequark>
which part of my explanation of what rust-lang-nursery is above you didn't read?
<whitequark>
left-pad is literally impossible on crates.io btw
<whitequark>
since you can't remove a published crate, period
<rqou>
um, yeah you can?
<whitequark>
nope
<rqou>
they force-yanked "nul"
<rqou>
who says they won't force-yank "dmca-bait" at some point in the future?
<whitequark>
yes, the crates.io maintainers can, just like the npm maintainers unyanked left-pad
<whitequark>
*you* cannot
<rqou>
so did they just reset the version numbering when the crate got added to nursery?
<whitequark>
no
<whitequark>
you can't really do that
<whitequark>
unless you rename the crate anyway
<rqou>
as in, is failure a rename+reset of existing ideas?
<whitequark>
no
<whitequark>
it's a replacement for error-chain that doesn't suck
<rqou>
so why should my "low versions are sketchy" heuristic not be applied here?
<whitequark>
because it's wrong in general
<whitequark>
versions are completely arbitrary
<rqou>
sure, but this is additionally not marked as a stable version
<whitequark>
if the author follows semver, you can *compare* versions. if the author doesn't, versions are just opaque identifiers
<whitequark>
it isn't stable, but neither is error-chain
<whitequark>
and std::error is just shit
<whitequark>
before failure, I would have told you to use error-chain. failure is much better
<rqou>
so why don't we have a thing to "magically" integrate serde, slog, and errors?
<whitequark>
because you didn't write it?
<rqou>
lol
<rqou>
ok
<awygle>
damn these 0.4mm pitch bastards
<whitequark>
oh wtf
<whitequark>
migen doesn't implement all python comparisons correctly
<awygle>
i built another smolfpga and i think im off by one row
<whitequark>
i have an off-by-one too lol
<whitequark>
ok, packetizer works
<whitequark>
time to test this thing for realz
<awygle>
wooo
<awygle>
this might be ok actually. it doesn't look like it's a full row off. there's just so little room for it to be anything _but_ a full row off...
<whitequark>
plug it in :P
<whitequark>
worst case, you get rework experience
<awygle>
yeah i'ma plug it in in a sec
<awygle>
the problem is i can't tell if 3v3 or 1v2 are shorted
<awygle>
so gud 2 hav output discharge
<whitequark>
output discharge?
<whitequark>
you're using an LDO that has that?
<awygle>
yup
<whitequark>
hm
<awygle>
when disabled, pulls down output to ground
<whitequark>
btw we might want to switch to an LDO with output discharge in rev C.
<whitequark>
or even rev B
<whitequark>
right now I have a hacky sleep() call when lowering the voltage
<whitequark>
to avoid triggering an alert
<awygle>
hm maybe
<awygle>
love the low-ass dropout on the ones we're using though...
<whitequark>
true
<whitequark>
maybe there's some with both
<awygle>
worth a look
<whitequark>
naturally it doesn't work
<whitequark>
in real weird way
<awygle>
natch
<whitequark>
I think I'm losing bytes somewhere
<awygle>
hm ok i'ma plug this in but i'm gonna power it through a switchable usb hub off a battery so i don't fry my laptop
<awygle>
i gotta get a good lab power supply...
<whitequark>
frying your laptop sounds real unlikely
<whitequark>
you might get it to turn off
<whitequark>
and that would explode the FPGA
<awygle>
well, true, but i have killed usb ports before
<whitequark>
i actually haven't
<whitequark>
and i've abused the hell out of them
<awygle>
i think i backdrove it with 12V or something
<awygle>
although come to think i did put 20V across one in this laptop already lol
<whitequark>
wow, the data I read from the FIFO is real fucked
<whitequark>
backdriving an USB port with 12V would do it
<whitequark>
but I'm not sure how are you gonna achieve that with aboard that doesn't have a single inductor
<awygle>
yeah, not likely in this case lol
<awygle>
in that case i was sourcing 5V from an ATX supply
<awygle>
and also sourcing 12V from it, elsewhere on the board
<whitequark>
hm
<azonenberg>
awygle: crosstalk test board came in today
<azonenberg>
gonna assemble in a few then test
<awygle>
azonenberg: sweet
<awygle>
I envy your nice big transformers :-P
<awygle>
This board does look offset :-( bummer
<azonenberg>
Also i now have an 8 in-lb SMA torque wrench
<azonenberg>
Think it's too much for those samtec SMAs i use?
<awygle>
woo
<awygle>
Nah
<awygle>
I've used one on them
<awygle>
Even the drop in ones take it fine
<azonenberg>
Probably going to do a quick blog post with the test results
<azonenberg>
no matter how it turns out
<azonenberg>
Just b/c i havent done one in forever
<awygle>
Sure
<awygle>
Gonna put a bet down on the result?
<azonenberg>
Measurable but non-fatal crosstalk
<azonenberg>
i.e. acceptable SNR but it shows up on the scope in a worst-case scenario as visible eye shrinkage
<awygle>
Yep. 30mV
<awygle>
That's my number
<awygle>
Based on nothing
<azonenberg>
Lol
<awygle>
If I'm wrong, who cares? But if I'm right, I'm a genius
<awygle>
Debating reflowing this board in the oven again and trying to poke the fpga into alignment...
<awygle>
I really need to get hot air
<whitequark>
argh
<whitequark>
I need an LA that's faster than what I already have
<whitequark>
looking at decoded 2 kbytes on the scope is painful
<awygle>
need la to debug la
<whitequark>
precisely
<whitequark>
hm
<whitequark>
wait
<awygle>
la la cthulu ftaghn
<whitequark>
if I send a 8-byte bulk write
<whitequark>
does USB waste the other 512 bytes?!
<whitequark>
what the fuck USB
<whitequark>
like I just checked and yes it does
<whitequark>
USB is a bus made out of fail.
<azonenberg>
whitequark: you see why i like ethernet?
<azonenberg>
if ethernet had the level of chip vendor and software stack support that USB did
<azonenberg>
it would be unstoppable
<azonenberg>
Nearly every argument i've ever seen against ethernet dominating the world of PC external buses is "but USB is more widely supported"
<whitequark>
azonenberg: PoE, PNP
<whitequark>
and complexity of TCP/IP as well
<azonenberg>
whitequark: i'm talking about 802.3 for the moment
<azonenberg>
Not upper level protocols
<whitequark>
bandwidth
<whitequark>
amount of data pairs
<azonenberg>
i.e. comparing USB bulk/isochronous/control transfers vs 802.3 frames
<sorear>
you need to solve the autoconfiguration problem at some point
<azonenberg>
Not any protocol or device class you may have on top
<azonenberg>
Just the layer 1/2
<whitequark>
I agree that 802.3 frames running at 500 Mbps over a single bidirectional pair would be strictly better than what USB has
<whitequark>
but this is only tangentially like Ethernet
<azonenberg>
whitequark: check out the *-baseT1 PHYs
<azonenberg>
formerly broadcom BroadR-Reach, now extended into IEEE standard
<azonenberg>
tl;dr one bidirectional pair, full duplex using similar noise cancellation to 1gbase-T
<azonenberg>
broadr-reach was 100M only but there are now base-T1 PHYs for 1G and i believe 2.5/5/10 either exist or are under dev
<azonenberg>
using ONE diffpair
<azonenberg>
if you were willing to do one pair each way, like usb3 does, you could trivially do 10Gbase-KX
<whitequark>
wiki says it needs a DSP
<whitequark>
I agree that SS makes things easier
<azonenberg>
You do realize that there is "a DSP" in 1000baseT already right?
<sorear>
USB is interesting because it used to have human-comprehensible autoconfiguration semantics, although OTG makes things a lot harder
<whitequark>
no, I actually don't
<whitequark>
what about USB 3?
<azonenberg>
usb3 is closer to a baseKX PHY
<azonenberg>
one diffpair each way with 64/66b encoded NRZ data
<azonenberg>
Much simpler line code, but less range
<azonenberg>
baseT wants more range over cheap cable and uses multilevel signaling starting at 100M
<azonenberg>
and starting at 1000M, bidirectional signaling with fancy DSP echo cancellation
<sorear>
your cable has an upstream end and a downstream end, you plug it between two devices and the downstream one will passively expose a certain set of functions to the upstream end, with no configuration required beyond what is implicit in the cable layout
<sorear>
you try that with a symmetrical cat5 cable
<azonenberg>
sorear: see this is one of the things i like about ethernet, it does not force a master-slave topology
<azonenberg>
usb has no way to do multimaster, or have slaves talk to each other, etc
<awygle>
DNS-SD + mDNS is the best option there, and it's not great
<azonenberg>
you can certainly do this by choice
<azonenberg>
Also, if we back up a bit
<whitequark>
azonenberg: this is irrelevant to 99.9% of use of USB
<whitequark>
which is "plug this flash drive and have it just work goddamnit"
<azonenberg>
My point is that the usb *link and physical layers* appear to be largely inferior to ethernet
<sorear>
I'm guessing you enjoyed being able to set PATA addresses by moving jumpers around on the drives too
<whitequark>
the fact that you can just plug a flash drive in and it always works is a severely underappreciated one
<azonenberg>
And that if a similar device class structure etc were built on top of ethernet, it would probably be better than what we have now
<whitequark>
sure
<azonenberg>
I'm not necessarily saying the TCP/IP protocol suite and the usb application layer protocols are plausible alternatives to each other
* whitequark
stabs USB descriptors several times
<whitequark>
I suppose I could try lowering bMaxPacketSize to debug this issue
<whitequark>
to something like 8
<whitequark>
[490398.034214] usb 3-1.1: config 1 interface 0 altsetting 0 bulk endpoint 0x2 has invalid maxpacket 8
<whitequark>
oh FUCK YOU
<whitequark>
huh
<whitequark>
"D7 D8 D9 DA DC DE E0 E2 E4 E6 E8 EA EC EE F0
<whitequark>
aha, it's the other FIFO
* azonenberg
off to garage to build boards
<awygle>
Come on you son of a bitch, work this time
<whitequark>
awygle: does that technically make you the bitch
<whitequark>
i'm just sayin
<whitequark>
o
<whitequark>
it works
<whitequark>
well, the FIFO
<whitequark>
but... it doesn't pass timing in a more complicated configuration now.
<whitequark>
what a pain.
<awygle>
whitequark: I'll own that lol
<whitequark>
man this FPGA is more like UltraMinus
<whitequark>
okay, I've added some registers and got like 10ns of period back
<awygle>
I put the fpga back on rotated 90 degrees.
<whitequark>
hahahahah
<awygle>
aaaaaaaargh
<whitequark>
relatable
<daveshah>
Congrats on the bitstream
<awygle>
daveshah: thanks!
<awygle>
IF ONLY I HAD A BOARD TO TEST IT ON
* awygle
swears, offends cats
<rqou>
ping azonenberg
<awygle>
hrm. Do I try this *again*? Or do I borrow hot air tomorrow?
<rqou>
mail it to me? :P
<daveshah>
Crap the only official lm4k board is expensive
<daveshah>
I can see why you're doing smolfpga
<awygle>
yup, that's why i built it in the first place
Bike has quit [Quit: Lost terminal]
<awygle>
and also why i didn't do one for Ultra or UltraLite (those are only 50$ each)
<whitequark>
what's good about lm4k again?
<sorear>
what's the bitstream news? vtr working for ice40 yet?
<daveshah>
sorear: this news is ice40lm support in icestorm and arachne
<daveshah>
By awygle
<awygle>
whitequark: it has the hard IP (which apparently sucks). it's an ice40 that's not supported (which offends me aesthetically). and it has the right number of pins for a project i may want to do in the future.
<whitequark>
hahaa
<whitequark>
how many pins?
<sorear>
ultra and ultralite when
<awygle>
39 i/o in a 3mm package
<whitequark>
hm, so like up5k but smoler?
<awygle>
sorear: i'm gonna write a blog post on the lm support, and offer to sponsor hardware for anyone who wants to do ultra and ultralite
<awygle>
if nobody takes it up i might do it at some point, but it won't be a super-high priority
<sorear>
how different are ice40 and ice65?
<awygle>
whitequark: smoler, faster(?), yeah
<sorear>
kinda doubt there's any legitimate use for ice65 support, but
<daveshah>
sorear: I think there are most likely a lot of similarities. But no one is realistically going to add an unobtanium fpga to icestorm
<awygle>
zero idea. has anyone taken a look at ice65? it's discontinued, right?
<awygle>
it's probably about as similar as XO2 is to ECP5 lol
<daveshah>
Discontinued for several years now, and never widely sold AFAIK
<whitequark>
ok, I think it should work now.
* awygle
is trying to resist the urge to reflow this board at least twice more
<awygle>
oh fuck it's 11pm. i need to go to sleep.
<azonenberg_work>
side #1 assembled
<azonenberg_work>
got a great pic of the inside of the magnetics too
<azonenberg_work>
this was major... three county sar teams plus the navy all out looking for him
<azonenberg_work>
i drew the short straw yesterday, 2/3 of the guys from my unit got a blackhawk flight deep into the woods
<azonenberg_work>
i was the reserve team back at base to be deployed to anyone needing assistance with an evac, the stretcher, etc
<sorear>
i'm curious what a "clean zia dump" is
<azonenberg_work>
me and two others sat around all day by the radios
<azonenberg_work>
sorear: the zia is the coolrunner-2 routing matrix
<azonenberg_work>
its a sparse crossbar
<azonenberg_work>
afaik there are only two ways to figure out which connections are possible
<azonenberg_work>
#1: decap the chip and image the M3-M4 vias (legal but labor intensive)
<azonenberg_work>
#2: read a bunch of ISE data files (EULA violation but super easy)
<azonenberg_work>
rqou has his code working with data obtained via method 2 but cant release it until we re-learn the same info via method 1
<whitequark>
should have just outsourced that to a non-US-resident :P
<daveshah>
azonenberg_work: set up a limited company somewhere like the UK to break the EULA with no assets?
<azonenberg_work>
daveshah: pretty sure they can still DMCA a github repo, etc
<azonenberg_work>
even if we have no personal liability the code is tainted
<daveshah>
azonenberg_work: but information is not really copyrightable
<whitequark>
do you really want to determine that in court
<daveshah>
So if you process the routing matrix in a human intensive way, then it might not even count as a deriviate work
<whitequark>
because that's what you'll have to do if xilinx doesn't like it
<daveshah>
Anyway I've been through similar thoughts with the ecp5, and gone with proper fuzzing even though I know data files are available
<daveshah>
And the Lattice EULA is more liberal than the Xilinx one
<azonenberg_work>
meanwhile
<azonenberg_work>
under 17 USC 906
<azonenberg_work>
it is explicitly legal to re a chip
<azonenberg_work>
And xilinx has no contractual prohibitions against doing so
<azonenberg_work>
It's absolutely crystal clear
<azonenberg_work>
Just a lot of work
<daveshah>
On the subject of weird legal clauses
<daveshah>
The Diamond EULA has a clause that any output files can only be used to program Lattice devices from authorised distributors
<awygle>
That's an anti-bitstream-conversion sort of clause
<daveshah>
Which raises an interesting question - if you make a bitstream public, and someone programs a device from an unauthorised source, have you broken the eula
<daveshah>
awygle: yeah, I don't think it was really aimed at that though
<awygle>
So Microsemi can't auto port you to a ProASIC or whatever
<awygle>
That's my understanding of the history at least
<sorear>
there was an actual court case about that sort of thing
<azonenberg_work>
daveshah: so, this is funny
<azonenberg_work>
i have a coolrunner-2 emulator
<azonenberg_work>
cycle accurate verilog that runs xc2c32a bitstreams
<azonenberg_work>
According to the xilinx eula you can only use ise-generated bitstreams to program "a Xilinx device"
<azonenberg_work>
So if i run that emulator on an artix-7 and burn a coolrunner-2 bitstream to it
<awygle>
azonenberg_work: can't you fuzz the zia?
<daveshah>
Yep, that's presumably fine
<azonenberg_work>
i'm complying with the letter, if not the spirit, of the rule
<azonenberg_work>
But if it was on an altera part its not
<azonenberg_work>
awygle: Possibly, but i'm a bit more conservative
<azonenberg_work>
and interpret the clause saying thou shalt not reverse engineer "the data files generated by the Software"
<azonenberg_work>
to prohibit bitstream RE in the general case
<azonenberg_work>
I only allowed data that was found by fuzzing the *silicon*
<daveshah>
No clause like that in Diamond luckily (but iirc something closer to that in icecube)
<azonenberg_work>
Or by die photo analysis
<azonenberg_work>
i.e. poking bits and seeing how the chip responds is ok
<azonenberg_work>
synthesizing random hdl to see what happens is not
<awygle>
I suppose that's fair. I'm sure one of us is going to end up in court over all this eventually. You'll be faster than your slowest friend :-P
<azonenberg_work>
I also chose coolrunner as a risk reduction strategy
<azonenberg_work>
i gambled that if i DID go a bridge too far
<azonenberg_work>
xilinx would be unlikely to expend the effort suing me
<azonenberg_work>
Because it was essentially a dead product line from 10+ years ago
<awygle>
arright, I arranged to borrow kevin's hot air tomorrow, I'll try and fix the board then
<azonenberg_work>
thus the legal fees would exceed the potential lost profits
<sorear>
that's what the authorized distributor clauses are about
<sorear>
> Based on that provision, Altera asserted state law claims for inducing Altera's customers to intentionally breach their license agreements with Altera and also for intentionally interfering with those contractual relations.
<daveshah>
Oh yeah, I remember that one now
<daveshah>
So if you buy chips/dev kits of aliexpress, then you are also technically speaking breaking the EULA...
<daveshah>
But I doubt they'd care given that's not what the clause is really about
<daveshah>
Maybe if a big customer was circumventing proper channels they could use it
<azonenberg_work>
i think they put that second bit in as a freebie
<azonenberg_work>
its meant as a no-porting clause
<azonenberg_work>
but they can go after gray market if they care
<azonenberg_work>
In case anyone is wondering
<azonenberg_work>
Soldering an 8-port RJ45 by hand is a pain
<azonenberg>
woo its assembled
<azonenberg>
weird not having a power connector
<azonenberg>
or having any active components at all :p
<whitequark>
awygle: OH GOD
<whitequark>
I FIGURED OUT WHY THE BOARD IS CALLED GLASGOW
<whitequark>
that's where the FTDI headquarters are
<whitequark>
it's good to have amnesia
<zkms>
ohhhhh
<rqou>
wait, so it's actually named after the place?
<rqou>
not the mecha?
<whitequark>
rqou: not the mecha, of course
<rqou>
"of course"?
<whitequark>
I haven't even watched Code Geass
<whitequark>
(and I don't like mecha anime in general)
<rqou>
anyways, i really need to get working on Guren :P
<daveshah>
Just wondering, are people going to murder me for using British English in the Project Trellis source :P
<daveshah>
Is it even worse than using Boost
<daveshah>
I can't face writing normalize
<rqou>
meh
<rqou>
oh btw earlier i was ranting to my housemate about how much effort it was to make a rust library that played well in the ecosystem (e.g. has logging, has serde, etc.)...
<rqou>
and my housemate pointed out "yeah, because the standards are so much higher"
<rqou>
"can you imagine having even a fraction of these features in a c library?"
<rqou>
"oh you wanted logging? have a fprintf(stderr). serialization? too bad"
<Ultrasauce>
code geass isnt really a mecha anime
<Ultrasauce>
it's firmly in the "mc jerks off about how smart he is" genre
<whitequark>
yeah but it would be really odd for me to name anything after a mecha
<whitequark>
is what i was saying
<rqou>
whitequark: is there a de-facto rust command line argument handling library?
<rqou>
"the thing that handles flags in argv"
<whitequark>
no de-facto ones
<rqou>
so do it ad-hoc? or do you have one you like?
<whitequark>
there's getopt
<whitequark>
getopt is very basic
<whitequark>
there's also clap
<whitequark>
clap is nicer but more complex
<whitequark>
I'd say use getopt and if it's not enough use clap
<whitequark>
I don't know what your needs are
<rqou>
i want a "fancy, proper, production-grade cli tool"
<rqou>
which interestingly gp4par is just ad-hoc?
<whitequark>
then it's clap
<rqou>
wow, everything in rust really is "much more complicated but works much better"
<whitequark>
loool
<whitequark>
AAAAARGH
<whitequark>
it wasn't the resistor
<rqou>
again, what my housemate said to me: "can you imagine having even a fraction of these features in a c library?"
<whitequark>
I was connecting the reset output to ground
<whitequark>
of course it was being pulled to ground
<rqou>
oh lol
<whitequark>
fuck's sake
<rqou>
whitequark: i don't need it yet, but what's the i18n story for clap?
<rqou>
i18n seems in general not too mature in rust?
<whitequark>
indeed
bitd has joined ##openfpga
<rqou>
hmm, i get the impression that there are too many people like me that really like "advanced" features (type system tricks, async, generators, futures, etc.) and not enough people slogging through "actual software engineering" stuff
<awygle>
I like clap (and hate insomnia)
<awygle>
Docopt is also mentioned
<gruetzkopf>
my g.shdsl modems seem to like the 8km line a bit less
<gruetzkopf>
had to step down with the link rate :(
<rqou>
why are you playing with dsl crap?
<rqou>
why no docsis/pon?
<gruetzkopf>
because someone in the 80s installed a 7*4*1.4mm (and a 56*1*0.9 and a 40*1*1.8) cable between this building and another
<gruetzkopf>
maybe g.shdsl only likes the part where i'm going back and forth over the same cable
<gruetzkopf>
*dislikes
azonenberg_work has quit [Ping timeout: 240 seconds]