368 karma · joined November 12, 2009
https://www.tomn.co.uk/
https://github.com/tomjnixon
https://erlang.org/doc/man/erl_eval.html
https://github.com/erlang/otp/blob/master/lib/stdlib/src/erl...
It's not lisp levels of concise, but the language was not designed for that.
If you want to make that comparison, meson is more restrictive than cmake, but tends to have more functionality built-in to make up for it.
bazel is more all-encompasing than either, as it's more about reproducible and distributed builds than a "better makefile" type system.
Try adding a bunch of matrix operations (particularly chained ones resulting in massive expression templates), fixed size matrices of various sizes, and compile with optimisation and SIMD enabled, and you'll see different results. I really like eigen and use it a lot, but it can definitely result in long compile times.
The larger DC-DC converters are not as cost sensitive as a raspberry pi product; they tend to be used in low volume industrial/scientific/medical devices and might cost £70 each. When you consider that they are also mostly inductor by area, and factor in the additional complexity of manufacturing a multiple-pcb assembly, it's also not worth it.
IIRC there are also some larger PCBs in that video; for those it's possible that they already had enough layers for routing signals that it was easy to integrate the transformer core directly.
Another factor I haven't seen mentioned is the manufacturing complexity. It looks like the transformer could be placed by a normal pick and place machine, while assembling a transformer around a PCB would be more of a specialised or manual process. I suspect that might be the real reason, as the transformer PCB doesn't look like it has that many layers.
It doesn't give you low latency, but if you don't care about that this is a nice way of using JACK applications without interrupting other applications that might be using PulseAudio; for development it's pretty handy.
We can have a discussion about whether this particular rule really does benefit everyone, but clearly the ones that do should be respected, otherwise what's the point?
This doesn't sound right; a behaviour is just a set of functions to be implemented in a 'callback module'; you seem to be talking about processes and modules. I agree with your points though.
I've spent some time reverse-engineering the echo microphone board, and while there is an interlock that prevents recording while the red mute button is lit (just the light under the button, not the ring), I didn't see anything that would prevent recording while the ring light was off.
The main controller has an isolated primary/secondary side, so it's fine for it to bridge. According to the datasheet it's got >4kV of isolation.
The big yellow thing is a transformer, but it's switched at high frequency; this is quite common in this kind of thing. Note that the secondary wires coming out of the top are properly insulated, so this should be quite well isolated.
The class-Y capacitor is designed for exactly this purpose.
It's exactly the same problem that every other distro has when users compile or install unvetted community packages.
The only way to make unvetted community repositories safe is to have users look at the sources before building or installing. Arch encourages users to do that -- AUR helpers and binary repositories are discouraged, and the source package format is simple enough that an average user could probably spot something like this.
Vertical filtering can be implemented in analogue circuitry using line delays (this was done for standards conversion as an alternative to pointing a camera at a screen), but it's a lot harder than taking a photo of a folded-up print-out.
You might enjoy this, Ben Krasnow talking about the challenges of making photochromic glass:
The problem with the response is that it has clearly been treated as a request ("diversion request heads up through Old Bahama Channel understood and authorized") that could have been denied.
It's obviously not an admission of guilt, but a red flag that's worth investigating.
boss: "Yes, authorized."
NTSB: "What do you mean authorized? It's not your decision. Did the captain ask you if he could go the safe way on the way out?"
def foo(bar)\
:
if (bar > 5)\
:
return bar + 1;
#
else\
:
return bar - 1;
#
#When I first saw this, I re-did the 3D reconstruction as a bundle-adjustment problem, which resulted in this model:
http://misc.tomn.co.uk/lightning/out.gif
To do this, I found point correspondences between the two images, and set up a model of the two cameras looking at these points. The camera parameters and point positions were then optimised to minimise the reprojection error (the distance between the real positions of the points in the images and the 3D position projected through the camera models).
This was implemented using ceres, which is worth a look if you're interested in this kind of thing.
It took quite a bit of fiddling to make this work, mostly estimating the camera parameters manually by hunting around google maps for landmarks. There's not very much data to work with, so the optimisation tends to get lost quite easily without doing this.
The results are kind of similar, but it's impossible to say which is closer to the real thing. The reprojection error ended up pretty small (mostly a few pixels), but there were some errors that I was unable to reconcile --- likely due to the difficulty of manually estimating point correspondences for a 3D line in space, possible errors in my constraints, lens distortion etc.
Specifically, a python configure script using the ninja_syntax.py module. This seems like it's a bit more complicated, but has a lot of nice attributes.
File names with spaces should just work (unlike make). The amount of hidden complexity is very low (unlike make or SCons); all the complexity lives in your configure script. It's driven by a real, non-arcane language (unlike make). Targets are automatically rebuilt when their rules/dependencies change (unlike make).
It's more difficult to install than make, but only marginally.
57 is interesting too; the black square in the centre is actually a hole leading into a box lined with black felt, to provide a black reference.
The generation and use of test cards and patterns is a surprisingly complicated subject; even in the digital age.
If you decide to try to make this faster, check out ceres[0] a non-linear least squares optimisation framework that does automatic differentiation using a clever C++ template hack.
I've used it a few times to solve these kind of problems and found it to be very good!
For example, how do I get to the preferences for this app? Via a hamburger menu on the left, or an ellipsis menu on the right?
Almost all the apps on my phone that have the concept of making a new item (SMS/instant message/email/calendar event) have the button for doing so in exactly the same place on the screen; this is great as it means only have to learn that action once, and it works for all the apps I use. That is optimised user interface design.
Of course designers still need to put in effort to make their apps usable, but making having the common subset of actions work the same across apps is great for users.
It's unfortunate that platforms seem to change their interface guidelines all the time (no just the look and feel), as it seems to be having the opposite of the intended effect. The cost benefits of having a single style for an app across platforms is also a significant factor; I'd rather have an app available on my platform than not.
Historically, climbing safety equipment was very basic compared to what is used today -- a rope tied around your waist held by your mate at the bottom of the pitch might stop you tumbling down the mountain, but you don't really want to find out.
In the UK, climbing culture is pretty conservative compared to other places (there's very little sport climbing here), so the (extremely sensible) attitude that your safety gear is for accidents not for helping you climb harder routes is quite prevalent.
They mean the act of putting your weight on your equipment. If you're climbing up by pulling on the rock, and resting on ledges, that's fine, but taking a rest by sitting back in your harness, or pulling on the rope to gain height is not.
Climbing is an one of the more logical sports, but like all sports, arbitrary rules have to be set if you want to accurately compare achievements between two people. It's just a way to make sure everyone knows what you mean when you say you've 'done' a route.
That said, I recommend ignoring this aspect of climbing -- fulfilling personal goals is a lot more rewarding for everyone than trying to compare yourself to others.
This of course means that compile times are a bit longer, as a given template may be instantiated by the compiler many times, but in terms of run-time and final object size it should be optimal.
I think this behaviour also makes more sense when you think about inlining -- a lot of template code is actually doing something quite simple under the hood, so by having the compiler instantiate your template each time, you potentially allow it to inline the code qithout relying on a LTO, which may not have been feasible when this whole mess was designed.