PS, the unitbuf thing was just the result of some bad advice I got when
asking around about the way C++ handles streams--the last time I used
C++ for anything significant was in about 1990 and I've forgotten just
about everything I knew about it from back then. Just about everything
I do thes
Hi, Jürgen,
Yes, it works fine with just goto agin.
--Chris
On 11/08/18 11:00, Juergen Sauermann wrote:
Hi Chris,
it would remove the *clearerr() *and *unsetf()* calls.
*clearerr()* has probably no effect at all because the next *fgetc()*
will do the same. And *CIN.unsetf(ios_base::unitbuf)*
Hi Chris,
it would remove the clearerr() and unsetf()
calls.
clearerr() has probably no effect at all because the next fgetc()
will do the same. And CIN.unsetf(ios_base::unitbuf) - if
at all needed -
should go to a different place.
I'm not sure how much the reversion would revert. If it was the patch I
sent you on 2 August:
Index: LineInput.cc
===
--- LineInput.cc (revision 1060)
+++ LineInput.cc (working copy)
@@ -968,9 +968,10 @@
{
Hi Chris,
does that mean that I can revert the patch that I have put in for
edif recently?
Best Regards,
/// Jürgen
On 08/07/2018 07:09 PM, Chris Moller
wrote:
Hans-Peter,
If you want to try it again
OS/2? Now /that/ was a lot of years ago... :-)
On 07/08/18 16:22, Hans-Peter Sorge wrote:
Hello Chris,
thank you (Really a lot:-). Works like a charm.
Feels like OS/2-times :_))
Greetings
Hans-Peter
Am 07.08.2018 um 19:09 schrieb Chris Moller:
Hans-Peter,
If you want to try it agai
Hello Chris,
thank you (Really a lot:-). Works like a charm.
Feels like OS/2-times :_))
Greetings
Hans-Peter
Am 07.08.2018 um 19:09 schrieb Chris Moller:
>
> Hans-Peter,
>
> If you want to try it again, I'm pretty sure I've fixed that bug in
> edif2--I just committed the update to https://g
Hans-Peter,
If you want to try it again, I'm pretty sure I've fixed that bug in
edif2--I just committed the update to https://github.com/ChrisMoller/edif
--Chris
On 02/08/18 07:12, Hans-Peter Sorge wrote:
Hello Chris,
thank you for this master piece. The line editing in GNU APL is a bit
Hi, Jürgen,
I finally got lucky using strace--using it affected the timing so much
that at first I couldn't reproduce the failure under strace, but finally
got it. What was happening was that once in a rare while, an IPC
message queue in edif2 popped a signal while a character was being
wri
Hi, Jürgen,
Just to keep you updated, what seems to be happening is that after a few rounds
opening and closing external editor processes, the
CIN << uni;
in LineEditContext::insert_char(Unicode uni) isn't getting the character to the
screen. I still haven't figured out why, but I'm still ha
I agree with you. I'm not all that pleased with it either, mostly
because I don't understand why it works--it was something suggested by
someone on StackOverflow.
Whatever is going on seems to be the result of the EINTR out of the
fgetc()--I'll try to look more closely at that. I'll also try
Hi Chris,
I am not entirely happy with your patch, in particular because I cannot
judge which other effects it may have
and which problem it actually solves.
What I can see is that:
You disable automatic flushing when you are waiting for an input
character and get a ^C interrupt or so,
What I d
I thought I'd fixed the echo blocking!
Actually, what seems to be happening is that APL is still running--you
can enter an APL expression, press enter, and the result will show up on
your screen--but keystroke echoing is somehow inhibited.
There was a patch for this Jürgenput in for me that s
Hello Chris,
thank you for this master piece. The line editing in GNU APL is a bit
cumbersome.
But the apl session gets blocked during editing (edif2).
Currently I have no clue, how to analyze it.
Thank you again.
Hans-Peter
Am 30.07.2018 um 20:52 schrieb Chris Moller:
>
> Thanks, Jürgen.
>
Thanks, Jürgen.
And for anyone interested, my editor interface native function is
available at https://github.com/ChrisMoller/edif.git
Basically, what it does is allow users to invoke external editors from
within APL sessions, i.e., while running APL, you can edit functions
using vi, emacs,
Hi Chris,
thanks, done in SVN 1060.
/// Jürgen
On 07/30/2018 03:59 PM, Chris Moller
wrote:
Here's an even simpler, more direct, patch:
Index: LineInput.cc
=
Here's an even simpler, more direct, patch:
Index: LineInput.cc
===
--- LineInput.cc (revision 1054)
+++ LineInput.cc (working copy)
@@ -966,6 +966,11 @@
const int b0 = fgetc(stdin);
if (b0 =
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
becau
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 wrote:
>
> Hi, Jürgen,
>
> So far as I can tell, after all the t
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
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
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 r
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
23 matches
Mail list logo
