Commit graph

113 commits

Author SHA1 Message Date
LemonBoy
b5a50a26eb Fix many thinkos
Somehow I forgot to save after copy-pasting some code and changing it.
2021-03-12 15:08:48 +01:00
LemonBoy
3010bfb08a Fix Progress printing on Windows systems
The cursor must be restored after the line is printed, not before.
Take into account the visible viewport to correctly compute the terminal
size.
2021-03-12 10:15:38 +01:00
LemonBoy
4fc2e92876 std: Better handling of line-wrapping in Progress
In order to update the printed progress string the code tried to move
the cursor N cells to the left, where N is the number of written bytes,
and then clear the remaining part of the line.
This strategy has two main issues:
 - Is only valid if the number of characters is equal to the number of
   written bytes,
 - Is only valid if the line doesn't get too long.

The second point is the main motivation for this change, when the line
becomes too long the terminal wraps it to a new physical line. This
means that moving the cursor to the left won't be enough anymore as once
the left border is reached it cannot move anymore.

The wrapped line is still stored by the terminal as a single line,
despite now taking more than a single one when displayed. If you try to
resize the terminal you'll notice how the contents are reflowed and are
essentially illegible.

Querying the cursor position on non-Windows systems (plot twist,
Microsoft suggests using VT escape sequences on newer systems) is
extremely cumbersome so let's do something different.

Before printing anything let's save the cursor position and clear the
screen below the cursor, this way we ensure there's absolutely no trace
of stale data on screen, and after the message is printed we simply
restore it.
2021-03-07 15:23:20 +01:00
jacob gw
1bd434fd18 std.Progress: improve support for "dumb" terminals 2021-02-21 12:12:17 +02:00
Andrew Kelley
2b321c25ce std.Progress: call refreshWithHeldLock as appropriate 2021-01-24 12:22:17 -07:00
Timon Kruiper
4f7d76f19c fix windows bug in Progress.zig
This bug caused the compiler to deadlock when multiple c objects
were build in parallel.

Thanks @kprotty for finding this bug!
2021-01-24 12:20:51 -07:00
Andrew Kelley
a9667b5a85 organize std lib concurrency primitives and add RwLock
* move concurrency primitives that always operate on kernel threads to
   the std.Thread namespace
 * remove std.SpinLock. Nobody should use this in a non-freestanding
   environment; the other primitives are always preferable. In
   freestanding, it will be necessary to put custom spin logic in there,
   so there are no use cases for a std lib version.
 * move some std lib files to the top level fields convention
 * add std.Thread.spinLoopHint
 * add std.Thread.Condition
 * add std.Thread.Semaphore
 * new implementation of std.Thread.Mutex for Windows and non-pthreads Linux
 * add std.Thread.RwLock

Implementations provided by @kprotty
2021-01-14 20:41:37 -07:00
Jay Petacat
a9b505fa77 Reduce use of deprecated IO types
Related: #4917
2021-01-07 23:48:58 -08:00
Frank Denis
6c2e0c2046 Year++ 2020-12-31 15:45:24 -08:00
Andrew Kelley
f4d82f0ad6 std.Progress: work around time going backwards 2020-12-23 13:36:21 -08:00
Andrew Kelley
fbcffe9d5d std.Progress: fix atomic ordering semantics
thx king protty
2020-12-20 15:08:59 -07:00
Andrew Kelley
aa6ef10cc6 std.Progress: make the API thread-safe
We generally get away with atomic primitives, however a lock is required
around the refresh function since it traverses the Node graph, and we
need to be sure no references to Nodes remain after end() is called.
2020-12-20 15:08:59 -07:00
Andrew Kelley
b2f8631a3c ThreadPool: delete dead code
If this errdefer did get run it would constitute a race condition. So I
deleted the dead code for clarity.
2020-12-20 15:08:59 -07:00
Renamed from lib/std/progress.zig (Browse further)