GHC 2017-04-21

12 comments.

, https://git.io/v9ULX in jarun/homebrew-nnn
LGTM.

, https://git.io/v9UL1 in jarun/nnn
`brew update` if install fails. For most users, a `brew update` is performed automatically when `brew install` is run.

, https://git.io/v9ULM in jarun/homebrew-nnn
`jarun/nnn` is the tap. `jarun/nnn/nnn` is the qualified formula name. So it is `jarun/nnn` that needs to be untapped. (`brew install jarun/nnn/nnn` performs an automatic `brew tap jarun/nnn`.)

, https://git.io/v9ULD in jarun/homebrew-nnn
Oh and `brew untap jarun/nnn`.

, https://git.io/v9ULy in jarun/homebrew-nnn
Yes.

, https://git.io/v9ULS in jarun/homebrew-nnn
Yes.

, https://git.io/v9UL9 in jarun/homebrew-nnn
Oh, and the instruction in jarun/nnn's readme should be updated to

```
brew install nnn
```

, https://git.io/v9ULH in jarun/homebrew-nnn
Migrate to homebrew/core
========================

`nnn` has been accepted into homebrew/core. This tap can be deprecated now. There are three ways forward:

1. Leave this tap alone. `brew install jarun/nnn/nnn` still works, but it will be stuck at whatever version that is in this tap.

2. Delete this tap. `brew install jarun/nnn/nnn` will no longer work, `brew update` or `brew upgrade` will throw an error.

3. Keep this tap, remove `nnn.rb` and add a `tap_migrations.json`:

   ```json
   {"nnn": "homebrew/core"}
   ```

   This way, `brew install jarun/nnn/nnn` still works and is automatically redirected to homebrew/core; people who previously installed `jarun/nnn/nnn` will be upgraded in the future without manual intervention.

I prefer 3.

, https://git.io/v9Jhb in Homebrew/homebrew-core
Gentle bump.

, https://git.io/v9JKq in jarun/googler
As you can see, most of the real time is neither user nor sys. It's just network IO waiting time we're not responsible for.

, https://git.io/v9JKm in Homebrew/homebrew-core
@ilovezfs I tried it and here's what happens when instrumenting a simple program:

```c
#include <stdlib.h>

int main() {
    void *buf = malloc(65536);
    return 0;
}
```

Valgrind:

```
...
==83732== HEAP SUMMARY:
==83732==     in use at exit: 83,911 bytes in 163 blocks
==83732==   total heap usage: 179 allocs, 16 frees, 90,055 bytes allocated
==83732==
==83732== LEAK SUMMARY:
==83732==    definitely lost: 65,536 bytes in 1 blocks
==83732==    indirectly lost: 0 bytes in 0 blocks
==83732==      possibly lost: 72 bytes in 3 blocks
==83732==    still reachable: 200 bytes in 6 blocks
==83732==         suppressed: 18,103 bytes in 153 blocks
==83732== Rerun with --leak-check=full to see details of leaked memory
...
```

So, it is at least in a working state.

, https://git.io/v9JRs in jarun/nnn
The default libreadline on macOS is libedit from NetBSD's editline. I hardly ever write low level readline code so I don't know how compatible it is with GNU readline, but you can always check the headers in https://static.zhimingwang.org/usr_include-macOS-10.12.4.tar.xz which I shared with you before. At least the current master works.