jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
_whitelogger has joined #glasgow
pie_ has quit [Ping timeout: 258 seconds]
_whitelogger has joined #glasgow
<eddyb>
08:14 <BA1719@ whitequark> third, you can upgrade yosys and nextpnr
<eddyb>
Cargo & rustc have an interesting relationship, heh
pie_ has joined #glasgow
pie_ has quit [Remote host closed the connection]
pie_ has joined #glasgow
<eddyb>
Cargo includes rustc -vV (verbose version) in its fingerprint, and also rustc embeds that into its serialized data, in case you run it directly, or Cargo fails to clear some artifacts on a version change
pie_ has quit [Remote host closed the connection]
pie_ has joined #glasgow
pie_ has quit [Remote host closed the connection]
pie_ has joined #glasgow
pie_ has quit [Remote host closed the connection]
<eddyb>
rustc's own incremental tracking is rly cool but harder to setup, so I wouldn't suggest bothering unless you really need it and have time to spend on it
<chocol4te>
I thought I was on the wrong channel for a sec there, I didnt realise glasgow used Rust somewhere?
<eddyb>
nope
<eddyb>
I was replying to something from yesterday, about caching
<eddyb>
the only compiler cache I know is Cargo+rustc
<chocol4te>
ohh sorry 🤦
<eddyb>
also it does this funny thing where rustc has a flag to output .d files (Makefile dependency rules, which a C compiler would use for e.g. #include header dependencies) which Cargo parses, assuming it's a specific subset of Makefile syntax
<eddyb>
I should bug the devs about that, surely we have a better way of doing this
<eddyb>
oh another determinism-related trick: Cargo hashes the identity information it has, for a crate, and passes that to rustc, which uses it to tell apart different versions of the same library (since it has no other way to tell) and make symbol names unique
<ar>
at least you're not trying to compile them with LDC
<eddyb>
we have at least one Debian person who bugs us whenever we break deterministic builds by accident
<ar>
at least these days Debian cares about deterministic builds
<ar>
back in the old days devs could literally smash together a .deb by hand and upload it
<eddyb>
assuming nextpnr has some algorithms that require randomness, I wonder if all of that can be manually seeded and how good or an idea that is
<eddyb>
ar: lol @ dlang. there's also the dtrace scripting language :P
<eddyb>
whitequark: hmmz I've seen a hash in some of your screenshots: is that a whole-gateware hash, and the discussion yesterday was about caching only parts of it?
<whitequark>
eddyb: it's a hash of the verilog file
zoobab has quit [Ping timeout: 264 seconds]
zoobab has joined #glasgow
Stary- is now known as Stary
mehar has quit [Ping timeout: 246 seconds]
mehar has joined #glasgow
oeuf is now known as egg|laptop|egg
oeuf has joined #glasgow
oeuf has quit [Remote host closed the connection]
egg|laptop|egg has quit [Quit: moo.]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Client Quit]
egg|laptop|egg has joined #glasgow
egg|laptop|egg is now known as oeuf
jevinskie has joined #glasgow
carl0s has joined #glasgow
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjCjU
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark 3c33e5c - README: explain the installation process.
<electronic_eel>
whitequark: are you strictly opposed to mentioning Bus Pirate et. al in the Readme?
<electronic_eel>
I think the new intro is good, but quite long
<electronic_eel>
the bus pirate thing was short and communicated a lot
<electronic_eel>
how about "Glasgow = Bus Pirate + Bus Blaster + Logic Sniffer on steroids and all software in Python"
<whitequark>
it's not really providing the same feature set
<whitequark>
i mean, we don't even *have* a logic analyzer ye
<whitequark>
*yet
q3k has quit [Ping timeout: 252 seconds]
q3k has joined #glasgow
<electronic_eel>
yes, but we will get one
<whitequark>
then we can talk about this again
<electronic_eel>
hmm, ok, you sound opposed :)
<whitequark>
it's not a truthful statement
<whitequark>
at this point, anyway
<electronic_eel>
but it gets the idea of the device across
<whitequark>
so?
<whitequark>
the current text also does, and it's not a lie
<electronic_eel>
but you currently have to read a whole block before you get the idea
<whitequark>
why do i want to cater to people who can't skim a few paragraphs of text?
<whitequark>
i'm uninterested in maximizing sales
<whitequark>
that just means more support workload
<electronic_eel>
also means more potential contributors...
<whitequark>
exactly
<whitequark>
i don't want more contributors, per se, because the process of introducing new contributors is highly asymmetric
<whitequark>
it costs far more to me to review a drive-by PR than it costs for someone to write it
<whitequark>
so, it doesn't scale. i'm far more interested in working with a few people who can be left to their own devices than by spending day and night mentoring people
<whitequark>
ha. do you have any idea how many weeks of review backlog i *already* have?
<electronic_eel>
hmm, can't you let a few of those people you trust do some of the review backlog?
<electronic_eel>
like in the linux kernel
<whitequark>
i already do, it has been worse in the past
<whitequark>
please do not use the linux kernel as an example of a good process.
<whitequark>
it's like the poster child for brokenness
<esden>
electronic_eel: I do not think it is a good idea to describe glasgow in the means of other tools/products. Unless you are familiar with those tools you will not know what glasgow actually is and at the end it can be misleading in itself.
<esden>
I really did not like the "short" but confusing and only usful when you know the other tools intro.
<electronic_eel>
but won't most people who are interested in Glasgow know the BP?
<whitequark>
yes. thanks esden. that is a good way to describe the reason why i changed the description.
<esden>
electronic_eel: definitely not, I talked to plenty of people during the last two conferences that had no clue what BP is. I had to describe it differently, and they were very interested and will find it useful as a tool.
<whitequark>
the only reason "short" description exists in the first place is i was talking about it on twitter
<esden>
I do agree that a nice "punchline" description is usuful. I like the "digital interface explorer" :D
<electronic_eel>
ok, when you both think it is not a good idea, then leave it as it is
<esden>
whitequark: Yes one tweet description is useful, but it will never fully describe how much more the device can actually do.
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjWeR
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark 86d1df4 - access.direct.demultiplexer: add a workaround for Windows brokenness.
<electronic_eel>
I think the biggest drawback of the bp & co was the toolchain
<esden>
electronic_eel: if you can come up with a short tweet long description that is not based on prior knowledge of the available tools in the space. Feel free to share it. I am not opposed to short and accurate descriptions conveying the idea of what the tool is.