dima55

7 ms·

91.
by dima55 2y ago
To do the stuff the blog post talks about you 'dpkg-buildpackage'. That's it. After years of maintaining packages, I think I decided that much of the complexity is unfortunately warranted. You want stuff to work in all sorts
92.
by dima55 2y ago
Well, to be fair, no package maintainers are touching any of the stuff described here. All the "ar" and "control.tar" stuff is handled for you by the tools. This isn't a "this is how you build packages" ar
93.
by dima55 2y ago
> I’d argue it’s a waste to use separate files here Fine. Write a `make.sh` that parses the arguments; that would be better. > How so? Well, read the comments here. Do you sense that Make is a beloved tool? Most of the complaints are
94.
by dima55 2y ago
I got an even better one for you: `./dev.sh`. The author is doing it wrong, and giving Make a bad name.
95.
by dima55 2y ago
The author is confused about what Make is for, and frankly this kind of thing is why Make gets a bad rap. Make is for traversing a graph to determine what should be built, and how to parallelize the steps. Here he doesn't have a graph
96.
by dima55 2y ago
File a bug report?
97.
by dima55 2y ago
They can't afford more mouse buttons?
98.
by dima55 2y ago
Or, you know, just use emacs.
99.
by dima55 2y ago
Totally. rr is nothing short of a revolution in debuggin.
100.
by dima55 2y ago
If you want to mention this, then you very clearly haven't actually tried it. The implementation in GDB is more convenient than rr (you can start/stop recording at will), but it is also orders of magnitude less efficient. It'
101.
by dima55 2y ago
This is the usual killer feature of something like rr. You debug, look at some variable: `p whatever`. You see that its value is wrong. You want to know where this wrong value came from, so you `watch -l whatever` and `rc`. Bam!
102.
by dima55 2y ago
I'd like to read more about it, but that link is... paywalled I think? It's not even clear.
103.
by dima55 2y ago
It graphically displays the relative sizes of things, and allows you to interactively zoom into any particular subdirectory to see the relative sizes of the things inside it
104.
by dima55 2y ago
Ideas for a better format: do what xdiskusage does.
105.
by dima55 2y ago
ROS is shit. In every possible way. It's a set of semi-related components, most of which can be done far better by doing it the normal way or writing it yourself. Nobody wants a "DDS" to simply send bits across and nobody wan
106.
by dima55 2y ago
To address your python woes: https://github.com/dkogan/gnuplotlib/ Gnuplot is excellent, and I use it every day.
107.
by dima55 2y ago
An important note about numpy broadcasting: numpy broadcasts from the back, so your life improves dramatically when you reference indices from the back as well: use axis references < 0. So if you want to reference a row: refer to axis=-1
108.
by dima55 2y ago
Avoiding rich models is a great thing to do if you don't model uncertainty: a beginner that didn't get enough useful calibration data will see poor uncertainties in the results. So I now use the splined models in pretty much all a
109.
by dima55 2y ago
That paper describes a rich splined model, very similar to the one used in mrcal. mrcal models projection (instead of unprojection like the paper does), which is better in a practical sense. Both work well to fit every lens. https:/&#
110.
by dima55 2y ago
Uncertainty propagation. Richer models that fit better. Lots of feedback and metrics and visualization to evaluate the quality of the solve. Flexibility of the tool. Documentation.
111.
by dima55 2y ago
Calibrating cameras is still important; it's only "mostly irrelevant in 2024" if you don't care about accuracy. Incidentally, tools like opencv and their ilk are also what you use if you don't care about accuracy. M
112.
by dima55 2y ago
Yes. Recursing your Makefiles produces poor results. You know who hasn't read the Make manual and makes recursive Makefiles? The cmake devs. If you truly need a lot of complexity, you can end up with unreadable Makefiles, as you say. M
113.
by dima55 2y ago
That is the one big use case cmake has, yes. But most (all, actually) cmake I see around me is used to just get a Makefile.
114.
by dima55 2y ago
There are plenty of options other than cmake. Ideally: 1. read the GNU Make manual 2. Write a tiny build system with Make or use any of the precanned ones. I use this: https://github.com/dkogan/mrbuild/ but there
115.
by dima55 2y ago
Do we really need to wrap more crap around cmake? It's already wrapping make in an unknowable way, and this layer doesn't help. The challenges when using these things aren't in writing the thing, it's fixing it when it d
116.
by dima55 2y ago
And on top of that, Debian's bug tracker is where development happens (as opposed to Ubuntu's, which is a black hole). And packages that cannot be built, get a bug report BEFORE the release on Debian, but are silently not included
117.
by dima55 3y ago
Rather than the "killer app", that's the only thing that cmake does better than other systems, and the only reason for anybody to use cmake.
118.
by dima55 3y ago
I think Make is exactly what you want, and I do recommend it to everybody, since the default alternative is usually something heinous like CMake which isn't really an improvement. You want the bit of logic to create a "build syste
119.
by dima55 3y ago
Are they though? The "complex .d-file generation" is "gcc -MMD" and a "-include *.d" at the end of the Makefile. You specify the dependencies, and it's on you to get those right, as it is in every other bu
120.
by dima55 3y ago
You want emacs and https://github.com/caldwell/commit-patch . Like 'git add -p' but much faster and more powerful.

More ›