Validating lambda signatures in C++17

WinLamb, as the name itself implies, is heavily based on lambda functions. While searching a way to enforce the lambda signatures in the upcoming C++17 release, I received an incredible answer on StackOverflow:

#include <functional>
#include <type_traits>
	
template<typename F>
auto foo(F&& func) noexcept ->
	std::enable_if_t<
		std::is_same_v<
			decltype(std::function{std::forward<F>(func)}),
			std::function<void(int)>
		>, void
	>
{
	func(33);
}

Up to this point, I was completely unaware of the existence of trailing return types in function declarations.

The validation is extremely restrict, serving my purposes perfectly. And it seems that the upcoming C++20 concepts feature can simplify it quite a lot.

SFINAE and enable_if

Today, while researching for the upcoming C++17 version of WinLamb, I was rethinking the idea of restricting the allowed types on a template argument. That’s an SFINAE thing, scary to many people – including me sometimes, in my love-hate relationship with advanced C++ stuff.

The thing is that I ended up writing a working piece of code using std::enable_if to restrict a template argument, and I’m quite proud of it.

#include <type_traits>

struct One { int num; };
struct Two { int num; };
struct Tre { int num; };

template<
  typename T,
  typename = std::enable_if_t<
    std::is_same_v<T, One> ||
    std::is_same_v<T, Two>
  >
>
void foo(T& o) { ++o.num; }

int main() {
  One o;
  foo(o);
  return 0;
}

In the code above, One and Two classes will work with foo(), whereas Tre will not compile, despite being exactly like the others.

CSS folded poster effect

Yesterday I just stumbled across this incredible CSS work, which makes a picture look like a folder poster on Reddit. The CSS was somewhat overengineered, so I removed a bunch of stuff and fixed some parts, and the result is now pretty usable.

The border is set by the padding attribute, and may need to be adjusted according to the image size. The image size itself cannot be properly set, or the effect goes nuts – if you want to resize the image, resize the image file itself.

I hope to use it somewhere, because it’s really cool. Props to the dude who did it.

Embedding rc files into Go Win32 executables

When building Go executables in Windows, the Go toolchain recognizes *.syso files and automatically embeds then into the *.exe – this allows the embedding of resources scripts, which can contain icon and manifest, among other resources. Visual C++ resource compiler, however, only generate *.res files.

I’ve seen people using rsrc tool to add manifest files to executables. The problem is that this tool doesn’t really compile a resource file, nor it converts *.res into *.syso.

Turns out resource file compilation can be done with windres tool, from MinGW package. Since I already have the whole Visual C++ stuff, I didn’t want to install all the package, which is rather big, and I already have MinGW terminal from Git. Fortunately, windres works standalone, the only requisite is that gcc is in the same directory. And we can download both.

Portable MinGW tools can be downloaded from here:

• MinGW Compiler Collection has gcc;
• MinGW Binary Utilities has windres.

From both packages, extract gcc and windres and save them somewhere else. All the rest can be deleted.

Compile the *.rc file into *.res with Visual C++ Developer Power Shell for VS 2019:

rc /r my-resource.rc

Then, on MinGW prompt, convert *.res into *.syso:

windres -i my-resource.res -o my-resource.syso

Now place my-resource.syso in the same directory of your main.go, and that’s it. For some weird reason, when debugging in VSCode, the program icon may appear wrong, but it will show fine in release builds, which are the ones that really matter:

go build -ldflags "-s -w -H=windowsgui"

Ideally windres would be used to compile the *.rc directly into *.syso, but to do so it needs the Win32 headers from MinGW, which are not present – you’ll get an error. Probably there’s a way to point Visual C++ headers directory to windres, but by now I’m satisfied using windres tool just to convert the *.res.

Rust macro to clone many objects at once

When working at my forthcoming Rust Win32 library, I was frustrated with the unergonomic task of cloning all the objects before referencing them inside a closure. The basic problem goes like this:

let a = a.clone();
let b = b.clone();
stuff.do_something(|| {
  a.foo();
  b.bar();
});

It would be nice to have some kind of syntactic sugar. Then at some point I saw an example that led me to use destructuring, very familiar from my JavaScript experience:

let (a, b) = (a.clone(), b.clone());
stuff.do_something(|| {
  a.foo();
  b.bar();
});

After that, it came to my mind that I could write a macro for that. After about a half hour wrapping my head around the concept, I finally came up with a macro to clone many objects at once:

macro_rules! clone {
  ( $($obj: expr),+ ) => {{
    ( $( $obj.clone() ),+ )
  }};
}

Which finally allowed me to write the most sugary version of all:

let (a, b) = clone!(a, b);
stuff.do_something(|| {
  a.foo();
  b.bar();
});

Testable in the Rust Playground.

Better antialiasing on Windows Visual Studio Code

In Windows, Google Chrome browser suffers from font bad rendering, with fonts being too thin and washed on screen. I don’t really know the technical cause, but it seems related to antialiasing and how the fonts are drawn, maybe a DirectX Graphics misuse.

Visual Studio Code is built upon Electron infrastructure, which in its turn uses Chrome engine to render stuff. So, VSCode suffers from the same problem: fonts being too thin and bad to read. Writing source code in such an environment is hard on the eyes. Until this day, I simply used Consolas font, which is naturally thicker. But I was never satisfied.

On Chrome, I fixed the problem by using Font Rendering Enhancer extension. It’s a rather simple extension that just adds the following style everywhere:

* {
  text-shadow: transparent 0px 0px 0px,
    rgba(0, 0, 0, 0.5) 0px 0px 0px !important;
}

The variation occurs in the 0.5 value: the higher the value, the darker the fonts will be rendered.

At some point, I also started facing the same problem on Firefox, and I asked about it on Reddit. Then I used addon to apply the style globally, and the problem was solved.

Now, back to Visual Studio Code, I started wondering whether it would be possible to add a global style to the whole window, since it’s just a browser window, after all. Turns out it’s possible by directly injecting CSS into Developer Tools, but it will go away when you close VSCode. Now, to make this change permanent – at least until the next update –, we can edit the main CSS file of VSCode and inject the CSS snipped globally. The file is:

(install dir)
 resources
  app
   out
    vs
     workbench
      workbench.desktop.main.css

There’s a side effect, however: when opening the VSCode again, you’ll receive the following warning:

Your Code installation appears to be corrupt. Please reinstall.

What means VSCode checks its own files when it’s launched, and that’s good, given the amount of garbage that an Electron program has. You can ignore this warning though, although there’s a very remote risk that something bad was actually injected into your VSCode installation without your consent, and you’ll be vulnerable. But it would be a very rare event, indeed. You’ll also see “[Unsupported]” in the titlebar.

Install PKCS#11 token on Ubuntu 18.04

Firefox offers an graphical interface to add the PKCS#11 library to the browser, so you can use PKCS#11 token to authenticate in websites. Chrome doesn’t offer a GUI, so it must be done purely using command line in Ubuntu Linux.

After a few failed attempts, I finally found a recipe on how to properly do it. Although it’s aimed at Ubuntu 16, it works perfectly for Ubuntu 18.04:

• MoebiusSolutions/cac-agent

An actual GUI on Chrome, just like Firefox has, would be great though.

Road Rash 3 guide

One of my favorite childhood games was Sega Genesis’ Road Rash 3. I ended up downloading Fusion emulator during corona virus pandemic, and of course I resurrected Road Rash 3, among others.

To my joy, I found a comprehensive guide for Road Rash 3, with amazing detail, which was finished in 2009, 11 years ago, by some good people. So far I’m having a lot of fun exploring it.

Choosing between useState and useReducer in React

Right now I’m designing a rather important architecture at work, and I’m using React for it. After writing a simple enough implementation with Redux, I came to the conclusion that, in fact, I don’t need Redux in this architecture, since I’m only storing auth information. Context API seems to be enough.

So, in order to have a mutable and reactive value in the application context, I must choose between useState and useReducer hooks.

While studying the matter, I found a rather good answer to this question:

• When it’s just an independent element of state you’re managing: useState;
• When one element of your state relies on the value of another element of your state in order to update: useReducer.

Although the examples given by the author are way too long, the idea is spot on. In my particular case, since the state is just a monolithic block of data, useState seems to fit my needs.

False memory leak reports of static objects

I was having a weird memory leak report in a C++ program, happening right after I close it, and triggered by a call to _CrtDumpMemoryLeaks, which exists in the very end of WinMain function in WinLamb. I was puzzled, because I’ve commented everything out, and I still had the memory leak.

Turns out _CrtDumpMemoryLeaks is called at the end of WinMain, before the static object destructors are called. And there you go: if any statically allocated object had made a heap allocation, the memory won’t be freed yet, thus the report.

I’m not the only one with this problem, but so far no solution had any effect. By now I’ll just avoid static allocation of objects which alloc memory on the heap, and carry on with life. Maybe I’m too used to the JavaScript blessings.

What types are heap-allocated in Rust

Today I stumbled on this question regarding which standard Rust types do alloc in the heap. I have this question popping in my head quite often, so here are the heap-allocated ones:

• Box, simple heap allocation;
• Rc, reference counter;
• Arc, thread-safe atomic reference counter;
• collections.

Reference to the answer can be found here.

Firefox: can’t see menu separators in Linux

In Linux, I was having a problem when using Firefox. After some version update, the menu separator lines simply disappear. After searching around after a solution to this very annoying problem, I found another userChrome.css customization:

/* Make separators in menus easier to see */
menuseparator {
  -moz-appearance: none !important; /* nothing changes without this */
  background: #d4d2d1 !important;
  height: 1px !important;
  padding: 0 !important;
  margin: 3px 5px !important;
}

Make sure it’s loading is enabled. After restarting Firefox, the menu separators were back in all their glory.