| 1 |
>>>>> On Tue, 3 Sep 2013, Duncan wrote: |
| 2 |
|
| 3 |
[Please check your e-mail agent. The "References:" header in your |
| 4 |
posting was broken.] |
| 5 |
|
| 6 |
> Zac mentioned in a different subthread that portage's logger is |
| 7 |
> single-threaded ATM, and could become a bottleneck if it had to do |
| 8 |
> too much output processing. |
| 9 |
|
| 10 |
> How feasible might it be to make something like this a (possibly |
| 11 |
> optional but presumably enabled by default) portage dep, and set |
| 12 |
> portage's default logging to use it when writing the log file (as |
| 13 |
> opposed to the screen output)? Presumably that would pipe to another |
| 14 |
> app to do the actual logfile filtering and writing, so the threading |
| 15 |
> issue would disappear. |
| 16 |
|
| 17 |
> Actually, presuming there's already a python implementation to |
| 18 |
> parallel that perl one, it's possible the only thing that would need |
| 19 |
> changed would be portage's default logging command. Pythonistas? |
| 20 |
|
| 21 |
Isn't it just a matter of regexp matching? For example, |
| 22 |
Emacs' ansi-color.el discards any string that matches |
| 23 |
<ESC>\[\([ABCDsuK]\|2J\|=[0-9]+[hI]\|[0-9;]*[Hfm]\) |
| 24 |
and it seems to work in the common cases. |
| 25 |
|
| 26 |
Ulrich |
Archives