EINTR could happen in many situations.
The usual resolution for EINTR is to retry whatever system call that failed
because of EINTR.
Here, we should call fgetc again.
Best,
Xiao-Yong
> On Jul 29, 2018, at 4:10 PM, Chris Moller <mol...@mollerware.com> wrote:
>
> Hi, Jürgen,
>
> So far as I can tell, after all the testing I can throw at it, my editor
> interface function is ready for the world. Unfortunately, it needs a small
> patch to APL itself:
>
> Index: LineInput.cc
> ===================================================================
> --- LineInput.cc (revision 1054)
> +++ LineInput.cc (working copy)
> @@ -966,6 +966,12 @@
> const int b0 = fgetc(stdin);
> if (b0 == EOF)
> {
> + if (errno == EINTR) {
> + clearerr (stdin);
> + CIN.unsetf( std::ios_base::unitbuf );
> + CERR.unsetf( std::ios_base::unitbuf );
> + return UNI_ASCII_CR;
> + }
> if (got_WINCH)
> {
> got_WINCH = false;
>
> The usual state of APL is blocking on the fgetc, waiting for user keystrokes.
> But my new edif2 function fork()s to open editor windows and when those
> processes are killed they emit SIGCHLD signals which also unblock the fgetc,
> resulting in an invalid unicode being returned. The patch catches these
> signals, clears the error on stdin, and returns a harmless CR. Somehow,
> though, and I don't really understand it, the signals were causing CIN to
> block on echoing to the screen. Unsetting the unitbuf bit fixes this, though
> I don't have any idea why. (I'm unsetting it on CERR too, just in case, but
> I don't know if it's really necessary.)
>
> I've run apl -T and haven't hit any unexpected failures, so I'm pretty sure
> this patch won't break anything, at least under Fedora 28 Linux, kernel
> 4.16.13.
> --Chris
>
> On 20/07/18 15:33, Chris Moller wrote:
>> Hi, Jürgen,
>>
>> On 18/07/18 05:36, Juergen Sauermann wrote:
>>> Hi Chris,
>>>
>>> thank you for contributing this. I have added a link on our community page
>>> http://www.gnu.org/software/apl/Community.html.
>>>
>>> I believe the function would be even more useful it could create or modify
>>> an APL function in a running workspace rather than writing the function to
>>> a file.
>>
>> It already does that--even in the current version, once the editor closes
>> and the system() call that started it returns, the file is read and fixed
>> back into the workspace. (I guess I need to make that clearer in the
>> README.)
>>
>> But version 2.0 takes it even farther--I fork()/exec() to start the editor,
>> along with a fork()-ed inotify waitspin that listens for changes in the
>> working file. When the editor writes to the file, the change is caught and
>> the function is fixed into the workspace, but the editor stays open until
>> you explicitly kill it. The effects of this are that APL keeps running even
>> while the editor is open--you can real-time run the function after every
>> save and see if it's doing the right thing--and you can have any number of
>> editor sessions running simultaneously. (I don't know how useful that will
>> be, but it was easy to make happen...) All this works even now, but
>> somewhere in all these spawned processes I seem to be firing off a wild
>> signal and not catching it so it winds up interrupting the main APL readline
>> loop resulting in either a null input or a spurious ctrl-d. I'm working on
>> that now.
>>
>> --Chris
>>
>>>
>>> /// Jürgen
>>>
>>>
>>> On 07/15/2018 10:47 PM, Chris Moller wrote:
>>>> After battling for decades with the ancient nabla editor, I finally did
>>>> something I should have done years ago and write a simple native function
>>>> that let's you use emacs or vi from inside an APL session. It's not even
>>>> close to Elias Mårtenson's cool emacs APL mode--it's just a quick thing to
>>>> bring up a friendlier editor. It's alpha-level code--if it melts your
>>>> computer, it's not my fault--and there are a few things on the TODO list,
>>>> but I thought I'd put it out there and get some feedback if anyone's
>>>> interested.
>>>>
>>>> Here's the README:
>>>>
>>>> edif is a GNU APL native function that allows the use of external editors
>>>> from within an APL session.
>>>>
>>>> Usage:
>>>>
>>>> edif 'function_name'
>>>>
>>>> This will open an editor, typically vi or emacs, containing the present
>>>> definition of the specified function, or, if the function doesn't exist,
>>>> a boilerplate function header consisting of the function name. After
>>>> saving
>>>> the edited definition and exiting the editor, the function will appear in
>>>> the APL workspace. While the editor is open, APL is suspended.
>>>>
>>>> edif will look for the environment variable EDIF and will use the string
>>>> specified by that variable as the command line to invoke the chosen editor.
>>>> For example:
>>>>
>>>> export EDIF="emacs --geometry=40x20 -background '#ffffcc' -font
>>>> 'DejaVu Sans Mono-10'"
>>>>
>>>> will invoke emacs with a fairly small window, a light yellow background,
>>>> and
>>>> using the DejaVu Sans Mono-10 font. (That's also the default if no EDIF
>>>> variable is found.)
>>>>
>>>> edif has only been tested with emacs and vi.
>>>>
>>>>
>>>> Future work may also allow edif to edit APL variables and operators, but no
>>>> guarantees I'll ever get around to it.
>>>>
>>>> edif may be included in the workspace with:
>>>>
>>>> 'libedif.so' ⎕fx 'edif'
>>>>
>>>>
>>>>
>>>> Implimentation note:
>>>>
>>>> edif works by storing an editable version of the specified function in:
>>>>
>>>> /var/run/user/<uid>/<pid>/<name>.apl
>>>>
>>>> where <uid> is the user's userid, <pid> is the process id of the APL
>>>> session, and <name> is the function name. This allows multiple users
>>>> each to have multiple simultaneous APL sessions with workspaces with
>>>> identical names. No locking is done by edif and I've no idea if APL
>>>> itself has any protection against a writable workspace being open in
>>>> multiple simultaneous sessions, but it opens up the possibility that
>>>> you can hose the workspace. So while, as far as edif is concerned
>>>> you can have multiple simultaneous sessions aimed at the same lib0
>>>> workspace, you probably shouldn't do it.
>>>>
>>>> Also, I've no idea if Windows or any Linux distribution other than
>>>> Fedora has a /var directory, so using this directory may be non-portable.
>>>>
>>>> So far as I can tell, edif doesn't interfere with Elias Mårtenson's
>>>> emacs APL mode, but I haven't thoroughly tested that.
>>>>
>>>>
>>>> It's at https://github.com/ChrisMoller/edif
>>>> (BTW, "edif" is short for "editor interface.")
>>>
>>
>
