| Age | Commit message (Collapse) | Author |
|---|
|
* maint:
stdlib: Fix jumping to beginning or end of line
Fix del_chars not considering wide chars and update buffer length before calling write_buf
Make cp_pos_to_col function aware of the ANSI escape codes
|
|
calling write_buf
After deleting the chars the function `del_chars` was considering the code points to move the cursor back and not the graphemes
|
|
* lukas/erts/non-smp-removal-cleanup/OTP-14518:
Make estone work with older releases
erts: Allow read in ttsl driver to return EAGAIN
syntax_tools: Fix makefile dep
erts: non-smp removal cleanup in erlexec
|
|
|
|
This fixes the issue with the function `move_cursor` described in #1536 and that causes the bug described in https://github.com/elixir-lang/elixir/issues/6504.
The function `cp_pos_to_col` maps the current position in the buffer to the correct column on the screen, but it didn't handle ANSI escape codes. Since the ANSI escape codes aren't visible, the `cp_pos_to_col` now skips them when executing the calculations using `ansi_escape_width`. This new function only considers color escape codes, but also handles invalid codes.
|
|
The ANSI support doesn't work properly with edlin, the issue can be noticed when you try to use the history of the shell and the prompt prefix has ANSI (https://github.com/elixir-lang/elixir/issues/6448). The problem is that when a `\e` character appears, it handles it like a new line, dropping the buffer before it.
The solution is to always add the `\e` to the buffer like a regular character and handle it when writing the buffer instead.
|
|
* dgud/stdlib/edit-unicode:
stdlib: Improve edlin handling of unicode chars
OTP-14542
|
|
Let edlin handle grapheme clusters instead of codepoints to
improve the handling multi-codepoints characters.
The ttsl driver (and protocol) still expects all lengths as
codepoints.
Previously it was expected that each codepoint used (at least) one
terminal column for each codepoint, and a hack was made for wide
characters (multicolumn) by patching in TAGGED characters to occupy
the extra space so that codepoint index was equal column index.
This didn't work at all for combining codepoints that do not occupy any
more space than the previous character.
Improved this handling by calculating column positions in move_cursor.
This is based on wcwidth() and is not perfect, wcwidth() is wrong for
some codepoints and wcwidth() can not know with Hangul graphemes for
example. But it works better than before without making a major change
in the protocol.
|
|
On Solaris, giving a too long sfv_len results in an
EINVAL error, but data is still transmitted and len is
correctly. So we translate this to a success with that
amount of data sent. This may hide some other errors
that causes EINVAL, but it is the best we can do for now.
|
|
|
|
Conflicts:
OTP_VERSION
erts/vsn.mk
lib/crypto/c_src/crypto.c
lib/crypto/src/crypto.erl
lib/ssh/src/ssh.erl
|
|
|
|
|
|
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
* bjorn/erts/huge-file-fix/OTP-13461:
Handle multi-giga byte writes to files
|
|
Test cases that write 4Gb to a file at once would fail on
OS X and FreeBSD.
By running a simple test program on OS X (El Capitan 10.11.4/Darwin
15.4.0), I found that writev() can handle more than 4Gb of data, while
write() only can handle less than 2Gb. (Note that efile_drv.c will use
write() if there is only one element in the io vector, and writev() if
there is more than one.)
It is tempting to attempt to piggy-back on the existing mechanism
for segmenting write operations in efile_drv.c, but because of the
complex code I find it too dangerous, both from a correctness and
performance perspective.
Instead do the change in unix_efile.c, which is considerably
simpler.
|
|
|
|
Bug introduced on master in a31eab5469b7740d.
|
|
|
|
|
|
* egil/fix-fdatasync-mac/OTP-13411:
erts: Use fcntl(fd, F_FULLFSYNC) instead of fdatasync on Mac OSX
|
|
The syscall fdatasync does not work as intended on Mac OSX.
Both the function fsync and fdatasync now uses fcntl(fd, F_FULLFSYNC) on Mac OSX.
|
|
|
|
* theom/freebsd-sendfile-patch-2/OTP-13271:
erts: Fix sendfile:ing of large files on FreeBSD
|
|
If the file was larger than the OS send buffer the call
would fail before this patch.
|
|
* lukas/erts/ttsl_eintr/OTP-12987:
erts: Make sure to deal with EINTR write failures
|
|
|
|
Lots of pthread platforms unnecessarily falled back on the pipe/select
solution. This since we tried to use the same monotonic clock source
for pthread_cond_timedwait() as used by OS monotonic time. This has
been fixed on most platforms by using another clock source.
Darwin can however not use pthread_cond_timedwait() with monotonic
clock source and has to use the pipe/select solution. On darwin we
now use select with _DARWIN_UNLIMITED_SELECT in order to be able to
handle a large amount of file descriptors.
|
|
|
|
|
|
Also removed old legacy fallback that is no longer used
|
|
* lukas/erts/non-blocking-shell:
Fix io:columns/0 timeout when invoked via user
kernel,ssh: Add synchronous user_drv protocol
erts: Make writing to non-tty fds non-blocking
erts: Make tty driver non-blocking
|
|
Added a put_chars_sync to the protocol that can be used to
talk to user_drv and made group use it. This is needed in order
to guarantee that bytes has been pushed to the tty port when
doing something like this:
io:format("halting\n"),erlang:halt(0).
Before this change the halting message could be lost in the message
queue of the user_drv process, this is no longer possible.
This commit also fixes ssh_cli as that plugs itself in as a user_drv
process.
OTP-12240
|
|
Instead of using blocking call to fwrite, the tty driver
now uses non-blocking calls to writev and queues any output
data that cannot be written into the driver queue. Without
this change an stdout write could block an entire scheduler
if for some reason the pseudo tty on the other side does not
consume the output of the Erlang shell.
OTP-12239
|
|
|
|
If the initial stat() fails then efile_openfile() will still proceed
to open() the file. If that succeeds and the caller passed a non-NULL
pSize, then it will copy bogus data from the statbuf into *pSize. This
has been observed to cause file:read_file/1 to return truncated file
data with no error indication.
The use case involved a large file system mounted via NFS, with some
directories containing large number of files, and NFS mount options
that allow the NFS client to return EIO if the NFS server does not
respond quickly enough. Depending on the caching state of the client
and server machines, a few stat() calls (fewer than 1 per 10 million)
would take long enough to trigger EIO errors, but subsequent open()
calls would succeed, and read_file/1 would return truncated data. This
sequence of events has been observed via "strace" on beam.smp.
Signed-off-by: Mikael Pettersson <[email protected]>
|
|
If writev return an error (eg ENOSPC) we do not want to abort here
but instead propagate upwards into erlang.
|
|
|
|
The sync option adds the POSIX O_SYNC flag to the open system call on
platforms that support the flag or its equivalent, e.g.,
FILE_FLAG_WRITE_THROUGH on Windows. For platforms that don't support it,
file:open/2 returns {error, enotsup} if the sync option is passed in.
The semantics of O_SYNC are platform-specific. For example, not all
platforms guarantee that all file metadata are written to the disk along
with the file data when the flag is in effect. This issue is noted in the
documentation this commit adds for the sync option.
Add a test for the sync option. Note however that the underlying OS
semantics for O_SYNC can't be tested automatically in any practical way, so
the test assumes the OS does the right thing with the flag when
present. For manual verification, dtruss on OS X and strace on Linux were
both run against beam processes to watch calls to open(), and file:open/2
was called in Erlang shells to open files for writing, both with and
without the sync option. Both the dtruss output and the strace output
showed that the O_SYNC flag was present in the open() calls when sync was
specified and was clear when sync was not specified.
|
|
files as delimiters.
While working on a tool that processes Erlang code and testing it against this repo,
I found out about those little sneaky 0xff. I thought it may be of help to other
people build such tools to remove non-conforming-to-standard characters.
|
|
|
|
|
|
* nox/wide-chars/OTP-11088:
Support wide characters in the shell through wcwidth()
Fix bogus DEBUGLOG() incantations in ttsl_drv
|
|
There is one remaining bug where ttsl_drv's state ends up inconsistent
with the terminal own state; when a wide character is entered on the
last column of the terminal.
Reported-by: Loïc Hoguin
|
|
|
|
|
|
Running some valgrind memory checking showed the error below:
==18040== Thread 6:
==18040== Source and destination overlap in memcpy(0xf3f3f04, 0xf3f3f08, 52)
==18040== at 0x4C2CFA0: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18040== by 0x5CF527: del_chars (ttsl_drv.c:845)
==18040== by 0x5CED5E: ttysl_from_erlang (ttsl_drv.c:658)
==18040== by 0x4982E3: erts_write_to_port (io.c:1235)
==18040== by 0x49A2BD: erts_port_command (io.c:2223)
==18040== by 0x48C054: do_send (bif.c:1962)
==18040== by 0x48CB6E: erl_send (bif.c:2162)
==18040== by 0x566599: process_main (beam_emu.c:1665)
==18040== by 0x4B1A95: sched_thread_func (erl_process.c:4834)
==18040== by 0x6075E2: thr_wrapper (ethread.c:106)
==18040== by 0x5560E99: start_thread (pthread_create.c:308)
This occurred on Linux using R15B01 while the shell was emitting a prompt,
but the same problem is still present in R16B.
Change the memcpy on line 845 of ttsl_drv.c to memmove as valgrind
suggests. After the change, verify with valgrind that the error no longer
occurs.
|
|
|
|
|
