HN user
I don't have WSL available, but I would love some numbers for tasks like cloning a large repository with git and running cmake. These things tend to be slow on Windows due to fork, see for instance this comparison for Windows vs. Linux in a VM:
https://gist.github.com/jibsen/7ebeddde3bc2bfd421b96ae53a824...
Regarding #3, it's worth noting that even though the elements of the two-dimensional array form a contiguous block of integers, you cannot treat them as such [1].
I suppose due to DST, the same clock time on the next calendar date might not exist or be ambiguous.
This was a very convenient way to share files because links were direct. Some people even used the public folder to host small static sites.
Interestingly their help site lists the change as March 15, 2016 instead of 2017, but perhaps they got all the dates wrong there [1]. At least I got the same email.
I also seem to have an annual attempt at switching to Vim [1]. I can do enough basic commands to survive, but I am so far from the productivity in Sublime/Atom that I always end up going back to them.
[1] https://www.donationcoder.com/forum/index.php?topic=37747
It's worth noting that ssize_t is a POSIX type, and is only guaranteed to have the range [-1, SSIZE_MAX] (basically a size type with one error value) [1]. If you need negative sizes, then ptrdiff_t is perhaps better.
[1] http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/...
Using mingw-w64 (GCC 6.1.0):
g++ -Os -static -s on `int main() { }' 17.408 bytes
g++ -Os -static -s on `int main() { throw 42; }' 139.776 bytesTry compiling with a recent 64-bit GCC and adding `-mtune=native -flto` to the mix.
It compiles fine with mingw-w64 on Windows. MSVC is a bit more involved due to the GCC extensions used. When LZFSE first came out I made a fork with the changes to compile with MSVC [1], but there wasn't any interest in it.
Most importantly, whatever the language or codebase you are working in/on mandates.
I write a lot of C, and given the choice, I tend to prefer tabs for indentation and spaces for alignment. I use a tab-width of 8, so the code will look fine for anyone using a lower tab-width.
Converting from tabs to spaces is a simple search-and-replace, whereas the other way is more work (there was an article here recently about algorithms to guess indentation width).
Back in 1997-1998 I wrote a compressor for DOS 16-bit executables called aPACK (and a library, aPLib, with the compression code). I still occasionally get an email from someone trying to get them to work, so they must still be in use :-).
I don't know if it is due to various fork implementations being slow on Windows, but programs that spawn a lot of subprocesses like build tools can be really slow [1].
I would love to see some numbers for those from Bash on Windows.
[1] https://gist.github.com/jibsen/7ebeddde3bc2bfd421b96ae53a824...
The Mac version has gotten a lot of good response, so I tried installing the Windows version. It feels a bit like a beta sadly.
- Backups to local folder do not work
- Scheduled backups don't always run until you open the GUI
- Open log viewer before any backups have been performed crashes the app
- File-Exit does nothing
- Wizard adds whole C:\ to first destination
- Doesn't seem to backup (all) locked files
To a large degree the language didn't change (some of the undefined behaviours we are discussing were in C89), rather the compiler vendors started to enforce parts of it.
I would love to see how it compares to a Linux VM for tasks that involve a lot of shelling out to run other tools.
The native Windows versions of git and CMake can be awfully slow [1].
[1] https://gist.github.com/jibsen/7ebeddde3bc2bfd421b96ae53a824...
I wonder why they did not add `--ff-only` as an option, like GitLab has.
It seems that the target option might be the one I was looking for.
The installed version defaults to x86_64-pc-windows-msvc, where the msvc at the end suggests it is looking for MSVC headers.
If you specify x86_64-w64-mingw32 as target, it uses the mingw-w64 headers.
What really confused me was that from the llvm front page, if you click Win Installer, you get a version that seems to expect MSVC headers, while if you click LLVM 3.8.0 you get the page you are linking, where the installers appear to expect MinGW headers.
Or perhaps there is some option in both of them to select the other?
You might like Clang with Microsoft CodeGen[1], a work in progress by Microsoft to add a Clang toolset to Visual Studio 2015 that uses the MSVC backend.
[1] https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-wit...
Pointers to character types get some special treatment. They can be used to address the individual bytes of other objects (C11 6.3.2.3p7), and the strict aliasing rule allows character types to be used to access those bytes (6.5p7) (one interesting note is that uint8_t is not strictly required to be a character type [1]).
The problem with assuming things like a pointer working like an integer, is that compiler vendors may choose to start taking advantage of any undefined behavior and point to the standard if you complain.
Even computing pointers that point outside an array can be undefined behavior, like f - 1 + 1.
It is easy for people who understand the relatively strong correlation between C and the assembly language it generates to assume such things work. Also, compiler vendors did let us get away with them for many years.
Interestingly, Monokai was developed back when Mac OS was not using sRGB by default, so using the RGB values today looks different than it did back then [1].
People have gotten used to the higher contrast, and the theme works great this way too.
Last time I saw GitKraken mentioned, I must admit I chose not to try it due to the license (which reads more like a NDA).
You might like this script that wraps cmake in a configure-like interface [1].
Also, CMAKE_INSTALL_PREFIX vs. --prefix is just different magical incantations. The obvious is sometimes what you are most used to.
I've played around with replacing the C library with something more lightweight for small programs (WCRT), but one issue is that you end up with executables that get flagged by some AV software for being "unusual".
I think unless you have a specific need for a small executable, it is usually not worth it.
I don't think tools like pngquant should be so easily dismissed. With the pixel density of todays monitors, the lossy changes they introduce can be very hard to see (which may be surprising for those of us who remember the pixelated horrors of Floyd-Steinberg from a couple of decades ago).
For some image types, lossy png has the huge advantage over jpg at the same file size that they have no jpg artifacts.
671.012 original
584.677 zopflipng -m
580.180 zopflipng -m --lossy_transparent
576.637 pngwolf --max-stagnate-time=0 --max-time=300 --normalize-alpha --strip-optional
190.598 pngquant --speed 1
179.638 pngquant + pngwolfI tried using ligatured when Pragmata added them, but the issues made me return to the normal version.
If you use your editor for multiple languages and documentation as well, you may find things like lines in comment blocks made of '%', '#', or '-' to break from the ligatures. Also if your doc markup(-down) uses underlines of '-' or '=' for headings, they are affected.
On Windows, I found some editors where the ligatures were enabled, some where they weren't, and not many where you had any option to toggle either way.
I had a similar experience. I had tried to find a decent set of tools for working with my images, and I was not along [1].
At some point I caved in and downloaded the LR trial, and it was clear that they had put a lot of effort into making it easy to do your workflow. And having the import/culling, undestructive basic editing, and library functionality in one tool won me over.
[1] https://www.donationcoder.com/forum/index.php?topic=7513.0
I also stuck my nose down this rabbits hole about a year ago, while writing a blog post about TextMate color themes [1] (TL;DR: Some older TextMate color themes were made on the Mac when it was using Generic RGB and a gamma value of 1.8, and converting those themes directly to other editors can result in slightly off colors, because they likely assume RGB values to be sRGB with a gamma close to 2.2).
It is fascinating to learn about, but it feels a bit like you could always go deeper. I stopped when I got to the different methods for gamut mapping.
On Windows, I've used the combination MSE + MBAM + EMET in the past. I think they complement each other well.