tomn

> LaserCube

Hmm, that looks like a 2D galvo scanner. I was thinking more like a laser pointer and a mirror attached to a motor.

> what I'm looking at the moment is a way to verify the intuition about if that's even possible

You just have to build it! It's definitely possible, and the only question I have is the power of laser needed to be visible in your environment for a given circle size, and a simulation will not tell you that.

From my understanding, the 5mw limit doesn't necessarily apply when a laser is scanned and has appropriate interlocks. For example the valve lighthouse (VR base station) is classified as class 1, but contains class 3 laser sources.

I think the scanning laser path is more likely to be what you want. Projection-based solutions will probably end up being a lot larger (and more power hungry), as I think you'd need a reasonable amount of quality optics to make anything resembling a sharp line at 1m distance from anything described as a 'small' gadget.

Right, sometimes you want that. I suppose my point was that the definition of truthiness works well with the default, most obvious way of indexing a dictionary, which was the original complaint.

Perhaps I was a bit harsh -- that exposes an issue which does trip people up, where they use `if x:` when you mean `if x is not None:`.

Saying that, I think it's defensible in the same way. The fact that you can write `if x:` (where x is not a bool) tells you that the language has a concept of truthiness, and so maybe you should have a think about what that actually means.

The alternative here (which would make your example work) is that dictionary lookups return some falsy sentinel value when the key does not exist, just like in javascript. In javascript, this has made a lot of people very angry and been widely regarded as a bad move.

Those values tend to propagate out and make a mess, sneaking into your stored data or causing errors in unexpected places -- fixing this feels like one of the main advantages of using things like typescript, and it's just not an issue in python.

It's not a problem, because the alternative is way worse. It's just a different language design than the one you're used to.

You could argue about whether or not truthiness makes sense as a concept (personally I think not), but the way it's defined in python is quite coherent and useful in practice.

Nice. They also tidied up the GPIOs a lot, which is such a good quality of life improvement (though I did spend a while hunting through the datasheet looking for the bit where they tell you that GPIO7 can only be used as an output during a full moon, or whatever).

The bitcoin comparison seems reasonable from the outside, but IMO misses the motivations of the people behind these services.

With cryptocurrency projects, people have a massive financial incentive to build them, promote them, take people's money, then disappear. It costs money to make the product, so you make more if you just pretend the money has disappeared.

With mastodon instances, I don't see the parallel. The benefit to instance admins is that they get to participate in a community that follows exactly their rules, and be in control of their own identity (and those of the users of the instance). They only get that benefit as long as they keep running the instance.

As in instance user the risks I can see are:

- The instance shuts down without warning, so the account migration feature can't be used. This can happen for technical reasons, or because the instance admin wants to screw with people, but there's no real motivation for doing that. The risk is also perfectly manageable -- backups are a good idea, and most people keep an eye on who's following them and follow back if appropriate.

- Your data gets used in a way you don't like (admin sells it, or looks at your DMs, or gets hacked). Again, I don't see the issue for most users -- it's a social network, most of the interesting stuff is public. Are people really using the DMs on social networks for stuff they want to keep private? That just feels like the wrong tool for the job. IP logs might be interesting, but there's not much you can do with them these days, and if you think you're likely to be a target there are ways to mask that.

Most of these problems are really the same or worse for centralised social networks, especially as they generally want ID verification (via phone numbers), which makes the data more sensitive, and a much more attractive target than some random instance with 5 users.

Anyway, sorry for the long reply, I was mostly irked by the bitcoin comparison, and for hitting some common anti-mastodon talking points that never made much sense to me. I agree that regular people trying to use it will probably have issues caused by misunderstanding -- in my mind it's more like twitter re-worked for nerds who like IRC, rather than twitter 2.0 for everyone.

Yeah, this is great if you're making your own PCBs -- all you need is the ESP32 module, power supply and a USB connector.

There's no need for a usb-serial converter, JTAG connector (you can debug over USB), or a serial header with yet another random pinout that you have to figure out every time you want to program the thing...

If an individual increases their TX power it would help them, but make others' experience worse. In a situation like an apartment block, if everyone increased their TX power then everyone would have a worse experience.

The point of this specific regulation is to prevent tragedy of the commons in a shared band -- if you want fewer restrictions go ahead and license your own spectrum; it wont be cheap.

If anything, it should be responding to new technology by encouraging their use to make use of shared bands more efficient, for example by reducing the power limit and restricting the use of inefficient modulation schemes.

edit: I know the article was about symbol rates, and I would agree that a symbol rate limit is silly, but you're responding to my comment which was just about the power limit.

but if there was no regulation we could increase the transmit power and have better signal!

Surround is a plugin which adds more text objects: https://github.com/tpope/vim-surround

cs"': change surrounding quotes, e.g. "foo" -> 'foo'

cs([: change surrounding brackets, e.g. (foo) -> [ foo ]

( cs]) would omit the spaces)

ci": change in quotes, e.g. "foo" -> "" (in insert mode between the quotes)

ca": change around quotes, e.g. x"foo"y -> xy (in insert mode between x and y

viWS<tag>: add tag around current word using visual mode, e.g. foo -> <tag>foo</tag>

dst: delete surrounding tag, e.g. <tag>foo</tag> -> foo

It's really good. I'm not familiar with argument.

For more details on this specific application these pages might be more relevant:

https://en.wikipedia.org/wiki/Optical_isolator

https://en.wikipedia.org/wiki/Faraday_rotator

Back in the days before async/await, twisted (an asynchronous I/O framework) used these to emulate async/await -- you could yield a differed value (like a promise/future), and it would pass it back when the value was available, saving some effort making your state explicit and writing many callbacks:

https://twisted.org/documents/21.2.0/api/twisted.internet.de...

I used this for a while with the 'alot' frontend[0] (before work moved to a different mail system and broke my set-up). It really does live up to the claims on the home page.

If you like TUIs (especially vim) but find things like mutt to be a bit too basic or inflexible, give this combination a try.

0: https://github.com/pazz/alot

True, some do, though some don't (and some have both). Even dedicated LED drivers using PWM can be better than simple PWM by using smarter modulation to get high resolution without reducing the frequency to something noticeable.

You're right -- look at any LED datasheet and you'll see the efficiency get lower at higher currents.

The real reason for PWM dimming is simplicity, expanse and size.

Turning an LED on and off is a lot simpler than a real constant-current LED driver: indicator LEDs can be driven directly from a digital output on a microcontroller, or switched with just a mosfet. Constant current is always going to be more components.

In AC-powered applications, making an LED not flicker at 100/120Hz requires capacitance for energy storage, which are bulky and unreliable.

That's a development board; if you look at the chip that's on that board (STM32F722ZE), there's no stock.

true. using hyperfine on my machine shows that grep is about 2x faster than egrep (and yeah, still nothing, 1.5 vs. 3ms)

the overhead isn't even an extra fork, as it uses exec

If you look at the disassembly, there's no difference in python 3 (I only tested 3.7+), so it's a matter of style.

There used to be a difference in python2 -- the list option would turn into n LOAD_CONSTs and a BUILD_LIST, whereas the tuple option would just emit one LOAD_CONST.

    import dis
    
    def with_tuple():
        for i in (1,2,3):
            print(i)
    
    def with_list():
        for i in [1,2,3]:
            print(i)
    
    print("with_tuple")
    dis.dis(with_tuple)
    print("with_list")
    dis.dis(with_list)

edit: looks like this changed in python 3.6: https://python.godbolt.org/z/rEfY9GT9W

some more reasons from a UK perspective:

- if you want to turn across the road, you have to merge onto the road which can be dangerous and awkward, so it's better to be on the road for longer before you want to turn than you might expect.

- cycle lanes are often too narrow (if just painted onto an existing road), so push you closer to the curb than is really safe. i often feel like the best position would be on the edge of the cycle lane, but then cars will not overtake properly

- ungraded cycle lanes tend to fill up with the dirt and detritus that's flung off the road by vehicles if they're not cleaned regularly enough (this is especially a problem if there are bollards or other street furniture that is supposed to separate the bike lane from the road, as it makes them harder to clean)

- cars are more likely to cut you off when turning across a cycle lane, than if they are forced to overtake properly

most cyclists I've talked to here think the kind of cycle lanes we have are worse than useless

It's not the batteries that have changed, it's the circuitry. In older devices, batteries were required to power SRAM, which uses very little power (just leakage currents).

This has largely been replaced by flash memory, so if you see a battery in a modern device there's a good chance it's powering a real-time clock, which use a fair bit more power in comparison.

I'm sure there's a big difference between different implementations of this -- low power design is an art that's quite easy to get wrong.

My colleague wrote this solution for C++ and cmake:

https://github.com/ebu/libear/commit/40a4000296190c3f91eba79...

This is a cmake function which generates C++ files using no external tools. It's probably not very fast, but if you don't need to handle big files and are already using cmake this is easy to integrate, adds no dependencies and works on all platforms.

I think Erlang has them for a more specific reason: in general it eschews all forms of data definition (records are just a fancy syntax for tuples with an atom at the start), which makes hot code reloading and transparent network communication simpler.

Both cases would require some synchronization of data structures (across time or over the network), and with user-defined types this can get complicated, and atoms make the lack of user-defined types much more pleasant (and more performant than strings).

this isn't going to be any better than just loading from the two buffers into registers then storing the other way around, like:

  a = load(ap)
  b = load(bp)
  store(ap, b)
  store(bp, a)
  ap += step; bp += step;

any instructions to "do the swap" are a waste because generally load-store are separate instructions in SIMD instruction sets (and even if that wasn't the case, that's how they would get executed anyway)

if you want to avoid polluting the cache there are SSE instructions for loading without caching, which might be worthwhile

edit: this might be useful in a SIMD context where you need to swap two registers, where the cost of using another register is higher than the cost of the 3 arithmetic instructions. i could totally imagine that happening, but it's nothing to do with caches or memory

Annoyingly this always re-writes commits (i.e. never fast-forwards), which means that if you have branches based on the branch you're merging they will need to be rebased, and git will complain about deleting the branch because it looks like it's unmerged.

Thanks! I'm not sure what integrated components you could use for this, as anything useful would probably use more current than the LED can provide.

Here's a video of a circuit I made which flashes an LED, using only power collected by the LED:

https://youtube.com/watch?v=BM7VDOoFIWI

The LED is the component on the left; there's a very dim flash (pretty much just the black die turning red) at around 11s, then every few seconds.

I can't remember exactly how it works... I think there's two capacitors charged up to the voltage of the LED in parallel through high-value resistors, and a circuit that shorts the +ve of one to the +ve of the other to put them in parallel.

It only just works at a very specific light level. IIRC some of the transistors are used as very low leakage diodes rather than transistors, as the regular diodes I had we're too leaky.

This project generates recipes in this format from a custom language:

https://github.com/mossblaser/recipe_grid

I use it regularly and it works well!

The response to this comment is a bit sad.

Yes, "we just needs a sufficiently advanced compiler" is a meme, but 1) not everyone knows that and 2) that's not what this comment is asking for:

> but here one domain specific language can have a huge impact

There's a big difference between a sufficiently advanced compiler for general C code, and a compiler for a domain-specific array processing language, for example.

Have a look at halide: https://halide-lang.org , where you specify the computation to perform and a schedule (loop order, blocking, vectorisation) separately. There's even an automatic scheduler that can find a good schedule given some example array sizes and parameters.

The fftw paper is worth a read, too -- this shows that for a restricted domain it's possible to automatically find code that works as well as or better than hand-tuned algorithms. Generalising this is of course very hard.

For deep learning I think a lot of this is already done, see XLA for example.

The TV licensing website says that you can get a refund if you're not going to need it; is that not true?

https://www.tvlicensing.co.uk/check-if-you-need-one/refunds-...