Re: [Bug-apl] Yet another editor thingy.

[Xiao-Yong Jin]

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 <address@hidden> 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.")
>>> 
>> 
>