Julien LOLLIVIER
Julien LOLLIVIER
Can't reproduce here (Linux). Specific to MacOS X? To your usage? Here too, more details would help, please.
Anyone knows if this information is also available for MacOS X?
Perhaps @BestPig have a clue about that? He's the mind behind MacOS X's port ;)
With our current memory management, we have to set an upper limit and keep memory usage as low as possible, as every tool should ;) What would be your ideal...
That's the point: the value is the same for everybody, even for an embedded system with 8MB of RAM .
My original reply started with "with our current memory management […]" because it's currently a basic allocation on the stack, so having a dynamic `MAX_PIDS` requires a bit of work....
It would require `-i` to accept a pattern instead of an individual file name. Open for contributions.
Sorry for my (very) late answer. @jingxuanlim I can only test on a CentOS Linux release 7.9.2009 (close to Scientific Linux 7.6) and `ncurses-devel` does the trick. So `ncursesw`'s not...
I added this PR on my todo list… and never got time to unstack it. Sorry for that! The issue with the current patch is that removing the `static` nature...
PR #163 still need some work (if relevant) so I've pushed MAX_PIDS / MAX_RESULTS to 128. It seems a very reasonable value, even for low-memory systems. Tag v0.17 has been...