They're a kind of analogue dynamic memory. I'd hesitate to call them RAM because the Access is not Random, but they are a kind of shift register and early computers used those for RAM.
Imagine a pair of MOSFETs connected to a pair of capacitors, and a bunch of those joined together in a chain. All the gates of each one of the pair of MOSFETS are connected together, giving you a "left" and "right" clock input.
When you put a signal in if you pulse the "left" and "right" inputs, it'll store the signal voltage in one capacitor, then pass it off to the next capacitor in turn, like old-timey firefighter handing buckets of water down a line of people.
They used to use this for delaying audio signals before digital memory and analogue to digital conversion was cheap enough to use.
bucket brigades were also used to read large scale sensors like a CCD camera. they are more efficient in their use of die space because you need fewer data paths; they don't need to be digital either, each bucket can be analog for "grey" scale
It's pretty easy these days to spin up a local Postgres container. Might as well use it for prototyping too, and save yourself the hassle of switching later.
It might seem minor, but the little things add up. Make your dev environment mirror prod from the start will save you a bunch of headaches. Then, when you're ready to deploy, there is nothing to change.
Even better, stage to a production-like environment early, and then deploy day can be as simple as a DNS record change.
Have you given thought to why you prototype with SQLite?
I have switched to using postgres even for prototyping once I prepared some shell scripts for various setup. With hibernate (java) or knex (Javascript/NodeJS) and with unit tests (Test Driven Development approach) for code, I feel I have reduced the friction of using postgres from the beginning.
Because when I get tired of reconstructing the contents of the database between my various dev machines (at home, at work, on a remote server, on my laptop) I can just scp the sqlite db across.
Because it's "low effort" to just fire it into sqlite and if I have to do ridiculous things to the schema as I footer around working out exactly what I want the database to do.
I don't want to use nodejs if I can possibly avoid it and you literally could not pay me to even look at Java, there isn't enough money in the world.
I mentioned Hibernate and knex as examples of DB schema version control tools.
Incidentally, you can rsync postgres dumps as well. That's what I do when testing and when sharing test data with team mates. At times, I decide to pgload the database dump into a different target system.
My reason for sharing: I accepted that I was being lethargic about using postgres, so I just automated certain things as I went along.
`pglite` is a WASM version of postgres. I use it in one of my side projects for providing a postgres DB running in the user's browser.
For most purposes, it works perfectly fine, but with two main caveats:
1. It is single user, single connection (i.e. no MVCC)
2. It doesn't support all postgres extensions (particularly postGIS), though it does support pgvector
Is that due to some kind of issue with the architecture, or just a matter of software support?
In the latter case, I'd expect patches for AMD or Intel to become a priority pretty quickly. After all, they need their products to run on systems that customers can buy.
Pretty much the whole of the Middle East, and consequently most of Glasgow following the various diasporas.
There used to be a place on Allison Street that did a kind of mutton liver and spinach stew with fenugreek and green chillis that I am currently right at this moment prepared to drive a 12-hour round trip to buy.
> The author says that non-power-of-two is not possible, but I'm pretty sure it is if you use a conditional instead of integer modulus.
I don't see why it wouldn't be, it's just computationally expensive to take the modulo value of the pointer rather than just masking off the appropriate number of bits.
Yes, that's what I'm saying. You can't just use a quick and easy mask, you have to use a modulo operator which is computationally expensive enough that it's probably killing the time savings you made elsewhere.
There's probably no good reason to make your buffer sizes NOT a power of two, though. If memory's that tight, maybe look elsewhere first.
What I mean is: This ringbuffer implementation (and its simplicity) relies on the index range being a multiple of the buffer size (which is only true for powers of two, when the index is e.g. a 32bit unsigned integer).
If you swap bitmasking for modulo operations then that does work at first glance, but breaks down when the index wraps around. This forces you to abandon the simple "increment" operation for something more complex, too.
The requirement for a power-of-two size is more intrinsic to the approach than just the bitmasking operation itself.
I feel like it's a cultural thing with the designers. Ceragon were the exact same when I used to do microwave links. Happy to provide demo kit, happy to provide sales support, happy to actually come up and go through their product range.
But if you want any deep and complex technical info out of them, like oh maybe how to configure it to fit UK/EU regulatory domain RF rules? Haha no chance.
We ended up hiring a guy fluent in Hebrew just to talk to their support guys.
Super nice kit, but I guess no-one was prepared to pay for an interface layer between the developers and the outside world.
Bucket-brigade delay lines?
reply