Ultimately, that's exactly what happens, but "goto again;" didn't work
Though I just thought of something I'll try in the morning...
On 29/07/18 21:19, Xiao-Yong Jin wrote:
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.")