like this
So, I was bemoaning the fact that finding chips in a DIP format is getting harder and harder because everything's moving to SMT. I don't hate SMT chips, but they make it rather difficult to play with them on a breadboard before using them in a project.
It just occurred to me that if I'm going to the trouble of designing a PCB in the first place, nothing stops me from sticking a single chip on a PCB with a bunch of pin headers to turn it into a quick and dirty "DIP chip" for experimenting with on a breadboard. I can even do this with a bunch of different chips on a single PCB that breaks out into multiple different units.
I'm sure I'm not the first person to have thought of this, but it was definitely an "aha" moment for me.
like this
Justin To #НетВойне reshared this.
I love it when the photo of a component and the schematic drawing on the data sheet disagree with each other.
(e.g.: digikey.ca/en/products/detail/…)
Guess I'll have to wait 'till I have the physical component in my possession to find out for sure.
Ep. 311 Ant Hill Kids PATREON Episode Part 2
In this Patreon deep-dive from the vault, I look into the Ant Hill Kids, truly one of the worst cults I have ever researched or heard about to this day. This isSpreaker
𝚛𝚊𝚝 reshared this.
Maintenance and Release Schedule
☁️ Nextcloud server, a safe home for all your data - nextcloud/serverGitHub
@Björn Schießle I think I figured out my problem. I'm running an older version of PHP that is no longer supported by later versions.
Edit: It irks me that it didn't warn me about this before now though.
Something that's been bothering me about lifetimes.
When I got to this section in the book, I couldn't (and still can't) understand why it's necessary to specify lifetimes for the references a struct
holds. I mean, if I have:
struct Foo<'a> {
bar: &'a String,
}
Shouldn't it just be assumed that the data referenced by Foo::bar
should have to live at least as long as the Foo
object itself? Why does this have to be explicitly stated? Is there some scenario where you would want this to not be the case?
Edit: formatting fix
Adam Hunt likes this.
Lifetime elision only applies on function signatures. It might be because no one has done the work? Though I think it's nice to be explicit that the struct holds a reference to something.
Explicit lifetimes would be necessary for a struct with multiple references (or I guess a rule that says they're either all the same or all unique). These are not the same:
struct Foo<'a> {
bar: &'a String,
baz: &'a String,
}
struct Foo<'a, 'b> {
bar: &'a String,
baz: &'b String,
}
More info on the elision rules is at the Rustonomicon.
Lifetime Elision - The Rustonomicon
The Dark Arts of Advanced and Unsafe Rust Programmingdoc.rust-lang.org
Jonathan Lamothe likes this.
&self
and return a reference.
like this
So you'd put up with the sound of crickets to spite them all. Good luck with that.
I need to know what is going on. I don't have cable tv (a real corporate problem) and my "social media" include my local weather info (via Youtube) as does a lot of my news sources etc.
And ALL my interests are in things that no longer have magazines or newspapers exclusive to them, instead them have Podcasts, Youtube Channels, etc. Same with most of the folks I communicate with in my life (since I lost so many friends and relatives to the Pandemic).
It's not the 1990s anymore.
@Joseph Teller That's not really likely to happen though, is it? At least not in the near future. Besides, if everyone jumped ship, there would be no content there to miss out on to begin with.
My original point though was that singling out TikTok as the only problem is rather silly.
Ep. 311 Ant Hill Kids PATREON Episode Part 1
In this Patreon deep-dive from the vault, I look into the Ant Hill Kids, truly one of the worst cults I have ever researched or heard about to this day. This isSpreaker
Reading up on NES ROM programming.
For some reason, memory addresses 0x0000-0x07ff are mirrored three times (for a total of four identical regions of memory). In a system with such a small amount of addressable memory, why would anyone do that??
like this
@Jonathan Lamothe Depending on the specific system, complex asynchronous code via timer interrupts (or raster interrupts, or I/O interrupts) is possible, but only one "thread" should use the stack.
For example, by default the Commodore 64 has a timer interrupt to trigger code to handle keyboard scanning, blinking the cursor, and other stuff. It's a non-trivial amount of code, but it does not mess with the stack.
Ep. 310 Physically In, Mentally Out - Episode 116 Remastered
In this episode I chat with author Geoffrey Wallis about his book "A Voice From Inside - Notes on Religious Trauma In a Captive Organization".Spreaker
God damned #ADHD brain.
I either get super hyper-focused on one project, to the detriment of other things (like eating and sleeping) or I'm so scattered between twenty things that I don't get anything meaningful accomplished on any of them.
A thing that's been stuck in my brain for a while:
A couple weeks ago, @Cory Doctorow wrote this blog post about how AI shouldn't be used to write code (edit: among other things). I agree with his rationale, but I can't help but be reminded of a (perhaps apocryphal) story I once heard about a similar argument being made against compilers in the early days of computing. The same kinds of arguments could've been made back then.
R. L. Dane :debian: :openbsd:
in reply to Jonathan Lamothe • • •Jonathan Lamothe
in reply to R. L. Dane :debian: :openbsd: • •