sytranvn

How to use clangd C/C++ LSP in any project

tl;dr: If you want to just know the method, skip to How to section

Clangd is a state-of-the-art C/C++ LSP that can be used in every popular text editors like Neovim, Emacs or VS Code. Even CLion uses clangd under the hood. Unfortunately, clangd requires compile_commands.json to work, and the only way to painlessly generate it is to use CMake.

But what if I tell you you can quickly hack your way around that, and generate compile_commands.json for any project, no matter how compilcated? I have used that way at work for years, originaly because I used CLion which supported only CMake projects - but now I use that method succesfully with clangd and Neovim.

Method summary

Basically what we need to achieve is to create a CMake file that will generate a compile_commands.json file with information about:

sytranvn

Environment variables in Jekyll templates

This is one way to pass some data (API tokens, etc.) to your Jekyll templates without putting it in your _config.yml file (which is likely to be committed in your GitHub repository).

Copy the environment_variables.rb plugin to your _plugins folder, and add any environment variable you wish to have available on the site.config object.

In a Liquid template, that information will be available through the site object. For example, _layouts/default.html could contain:

sytranvn

collapsible markdown?

CLICK ME

yes, even hidden code blocks!

print("hello world!")

sytranvn

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocksConfig version="1">
	<editor>
		<colour_sets>
			<ACTIVE_COLOUR_SET>
				<str>
					<![CDATA[modnokai night shift v2]]>
				</str>
			</ACTIVE_COLOUR_SET>
			<ACTIVE_LANG>

sytranvn

Install opencv3 for python 3.5.0 with pyenv on ubuntu 14.04

• update cmake and install deps as this said.

• run cmake

  cmake -D CMAKE_BUILD_TYPE=RELEASE \
  -D CMAKE_INSTALL_PREFIX=~/.pyenv/versions/3.5.0/usr/local/ \
  -D INSTALL_C_EXAMPLES=OFF \
  -D BUILD_NEW_PYTHON_SUPPORT=ON \
  

sytranvn

#!/usr/bin/env node

function execute(command) {
  const exec = require('child_process').exec

  exec(command, (err, stdout, stderr) => {
    process.stdout.write(stdout)
  })
}

sytranvn

This is a comment on http://eli.thegreenplace.net/2014/04/02/dynamically-generating-python-test-cases/

sytranvn

Revert the full commit

Sometimes you may want to undo a whole commit with all changes. Instead of going through all the changes manually, you can simply tell git to revert a commit, which does not even have to be the last one. Reverting a commit means to create a new commit that undoes all changes that were made in the bad commit. Just like above, the bad commit remains there, but it no longer affects the the current master and any future commits on top of it.

git revert {commit_id}'

About History Rewriting

Delete the last commit

Deleting the last commit is the easiest case. Let's say we have a remote origin with branch master that currently points to commit dd61ab32. We want to remove the top commit. Translated to git terminology, we want to force the master branch of the origin remote repository to the parent of dd61ab32:

sytranvn

console.log(examineNaN(NaN));
// > { isNaN: true, sign: 0, signaling: false, payload: 0 }

const nan = createNaN(false, false, 5000);
console.log(isNaN(nan));
// > true
console.log(examineNaN(nan));
// > { isNaN: true, sign: 0, signaling: false, payload: 5000 }

const nan2 = createNaN(false, false, [1, 2, 3, 4, 5, 6]);

sytranvn

Why You Can't Un-Root a Compromised Machine

Let's say somebody temporarily got root access to your system, whether because you "temporarily" gave them sudo rights, they guessed your password, or any other way. Even if you can disable their original method of accessing root, there's an infinite number of dirty tricks they can use to easily get it back in the future.

While the obvious tricks are easy to spot, like adding an entry to /root/.ssh/authorized_keys, or creating a new user, potentially via running malware, or via a cron job. I recently came across a rather subtle one that doesn't require changing any code, but instead exploits a standard feature of Linux user permissions system called setuid to subtly allow them to execute a root shell from any user account from the system (including www-data, which you might not even know if compromised).

If the "setuid bit" (or flag, or permission mode) is set for executable, the operating system will run not as the cur