I'd try this out on a breadboard, but I don't currently have the necessary parts so I'll just ask instead.
What happens on a 555 timer if you simultaneously drive the trigger low and the threshold high? Is this an error state that could vary from chip to chip?
πππ reshared this.
Woo! Got my clock module down to two chips total (plus resistors, capacitors, and such).
Really basic stuff, but I'm still learning #KiCad.
like this
reshared this
~HLT instead of +5V. No additional logic gates required.
Decided to look into Nostr since everyone here seems to hate it (so I can figure out why).
From their website, they tout that it's "censorship-resistant"* while also complaining that traditional social media is overrun by bots and spam.
How does one go about solving the bot/spam problem without resorting to censorship? This feels rather mutually exclusive to me.
* frequently a fascist dog whistle
R. L. Dane :debian: :openbsd: reshared this.
8bitdo makes bluetooth receivers that plug into an nes controller port, been thinking about getting one of those.
And there are plenty of no name 3rd party nes controllers on websites like aliexpress
Jonathan Lamothe likes this.
Here's the funny thing about propaganda:
It gets started by someone (or a group of someones) with an agenda, but when it's effective, it gets swallowed and spread by well-meaning individuals who simply don't know any better. When this happens, it becomes even more effective, making it a vicious cycle.
Not everyone who spreads it is doing so for nefarious reasons (though many are).
screen for many years. I somewhat recently switched to tmux. Both are solid options, though tmux seems more popular.
Adam Hunt likes this.
Jon's Friendica Node Notices reshared this.
To those who argue "my VPN can't track me because I pay them in bitcoin":
You know they have your IP address, right?
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.
πππ 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.
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.
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.
Building a small personal project in #Rust to teach myself the language. As I was looking over my code, I noticed a mistake I'd made that technically worked, but was kind of silly so I fixed it.
This got me to wondering if Rust had a linter (it does) because surely I'd made other similar rookie mistakes. I found the linter and ran it on my project. It came back with one result that I already knew about: a value in a struct that doesn't get read because I haven't written that code yet. That was it.
I was surprised. It's still a very small project, but perhaps I'm a more competent developer than I give myself credit for.
reshared this
Jonathan Lamothe likes this.
Does time::OffsetDateTime::now_local() always fail in a testing context or something? It keeps returning Err(IndeterminateOffset).
#rust
Edit: it's working fine when I use it in src/main.rs.
reshared this
UtcOffset not threadsafe in such an environment?
UtcOffset to be manually specified.
More musings on #Rust:
I wonder if it would be possible to write an #SNES #ROM in Rust. It seems like exactly the kind of resource-constrained system that would be a prime candidate for that sort of thing. Unfortunately, it seems that the SNES used a custom processor, so it's very possible that I won't be able to specify it as a compile target. A quick search reveals that many people have made SNES emulators in Rust, but at a glace, I see nothing about writing ROMS.
I believe the original NES used an off-the-shelf processor (6502 if memory serves?). Perhaps that's more likely to be supported, but that may be a little too resource constrained.
I shall have to dig deeper into this idea. I love the idea of building a custom ROM rather than just pirating something off the internet.
Has anyone done anything like this? Links to any relevant resources would be very much appreciated.
like this
reshared this
The SNES CPU is based on the WDC 65C816, which is indeed able to run 6502 code but it also has 16-bit mode instructions with much larger memory address space.
I think the only general purpose computer to use this CPU was the Apple IIGS, so maybe look around to see if there's any Rust port to Apple IIGS.
this folks have ported llvm to MOS6502: llvm-mos.org/wiki/Welcome
You can try to link rustc to that fork and add a new rustc target.
It will be a very long journey, but it is possible.
Newbie #Rust question time:
I wan to use the current_local_offset function from the time library, but I apparently need to import it into my project with the local-offset feature.
I assume I need to specify this in Cargo.toml but for the life of me, I can't figure out how. Can someone point me in the right direction?
reshared this
You need to specify the `features` list next to the version in Cargo.toml:
doc.rust-lang.org/cargo/refereβ¦
Alternatively, you can run
`cargo add -F FEATURE1,FEATURE2,β¦`
You can run `cargo add` even after you added a dependency.
Have you tried something like the following?
time = { version = "0.3.36", features = ["local-offset"] }
Jonathan Lamothe likes this.
Story time:
I've been holed up in the (home) office for most of the day (not uncommon). I happened to look out the window and noticed that our building was surrounded by cops.
Interesting.
Turns out they arrested one of the downstairs neighbours... for what, I don't know.
Here's the interesting bit though: apparently, the landlord offered them the key to the apartment, but they couldn't legally use it because there was no warrant. I guess that makes sense, but while they weren't allowed to to that, they apparently were allowed to enter the apartment by prying a window open or kicking the door in. In what world does that make any sense?
like this
reshared this
People who don't like #Rust: why specifically don't you like it?
I'm in the process of learning it now. There are definitely some things about the language that I can see some as finding irritating (i.e.: the borrowing system). Personally though, I'd rather have a dozen complie-time errors than a single runtime error. This is the reason I tend to gravitate towards Haskell, for instance.
It's certainly not the right language for everything, but if you want better safety in code that needs to be highly efficient, it seems a reasonable alternative to C/C++.
reshared this
the borrow checker is such a big part of the language it's not just slightly irritating, it's like having a non-consentual finger up the ass every time you open some Rust code in your editor
And the fact Rust is always staticallly linked and lacks any sort of reproducible builds don't help, even the compiler itself only compiles with an n-2 version of the compiler, if you skip updating the compiler for a while and want or have to keep using sources then have fun compiling every version since you last updated the compiler
Its type system is also like a borrow checker: non-consentual fist up the ass, want to add an u8 to an u32? Nope, can't, have to manually cast everything because that's why we do programming languages instead of writing Assembly, to do all the fucking busy work ourselves
Oh, and Cargo is its own can of rotten worms
LisPi likes this.
@Reiddragon > And the fact Rust is always staticallly linked and lacks any sort of reproducible builds don't help
That is excusable in languages where source-only distribution is normal and expected. (Indeed, compilation should be a transparent caching step and artifacts of such shouldn't be commonly shared.)
That is not the case for Rust.
> even the compiler itself only compiles with an n-2 version of the compiler
That's also a problem, Rust's bootstrap story sucks.
Ada's might suck as much, I'm not sure, I have found a few interpreters when I last looked...
> I'd rather have a dozen complie-time errors than a single runtime error. This is the reason I tend to gravitate towards Haskell, for instance.
There should be no meaningful difference between runtime and dev-time for the majority of devs. Dead languages aren't necessary. And punchcard retrocompatibility can be preserved without prioritizing a development process that is optimized for that workflow.
As for typing static vs dynamic, there's a thing called "gradual typing", and it is very possible to tie the type-checker into a REPL.
I've got a few things with Rust that make me dislike it a bit -- note that that doesn't mean that I think it's generally a bad language. (They're all good langs, Brent.) But here we go:
Another single implementation standard-less language. No solid standard library, everything done by downloading the internet. Very un-Turbo-Pascal-ish compile times and memory usage. Annotations. BCPL-ish syntax with too much line noise (and hey, I used to program Perl). Tied a lot to the worst things in IT (browser engines, crypto). Fanatical community. Overly complex async to save me from writing threads. Both functional purists and micro-optimizers. The word "Rustaceans" alone.
It's not a language that I'd like to use recreationally, but I wouldn't quit jobs if I have to do more work with it at work.
Jonathan Lamothe likes this.
Jonathan Lamothe
in reply to Jonathan Lamothe • •Qand~Qoutputs of the SR latch to be driven low.Matthew Skala
in reply to Jonathan Lamothe • • •Sensitive content
Matthew Skala
in reply to Matthew Skala • • •Sensitive content
Jonathan Lamothe
in reply to Matthew Skala • •