Richard Jonas

Can it be something like this? ```vim function! ale_linters#go#golangci_lint#GetMatches(lines) abort let l:pattern = '\v^([a-zA-Z]?:?[^:]+):(\d+):?(\d+)?:?:?:?\s\*?(.+)\s+(.+)$' return ale#util#GetMatches(a:lines, l:pattern) endfunction function! ale_linters#go#golangci_lint#Handler(buffer, lines) abort let l:dir = expand('#' . a:buffer . ':p:h')...

I did a `erlang:garbage_collect/0` but the binaries didn't go away. I don't know the process structure of chatterbox, but I think there are two processes pass the binaries, and after...

Ok, calling the `garbage_collect(Pid)` decreased the number of refc binaries from 1932 to 84. So probably we will call GC for only those processes when the refc binaries count is...

It is also interesting that `process_info(memory)` and heap size in normal process_info gives me different results. And like I said, the reductions were huge. So I decided to reconnect in...

I am using my own fork until the change in prometheus.erl is not merged.

Seeing the code the generic rule should be something like: ``` {generic, field_name, [{pre_encode, fun/2}, {post_decode/1}, recursive]} ``` Encoding: pre_encode function is called, and its result will be encoded recursively...

Virtual is implemented, the generic recursive is the only one is waiting to be implemented.

Referring to a non-existing beam in -json_include results in a compilation error. Now parse transform should check the correctness of the rules.

After new upgrade of Mac OS (15.3.2) Python 3.8.x cannot be build because it fails with a 'too long filename' error during build it generates a very long temp file...