Re: Still some issues/warnings..

[Chris Moller]

Brings back unfond memories of decades ago of the significance of 
invisible leading tabs in Makefiles...


On 10/20/22 08:06, Dr. Jürgen Sauermann wrote:

Hi again,

I may have found the problem. I am so much used to nicely looking 
indentation that
my brain keeps refusing to remember the counter-intuitive fact that, 
in bash, blanks
before and after = make a (in this case) huge difference. To make 
things worse, this
happens in a conditional  and therefore only occurs on some systems 
and not on

others.

Fixed in *SVN 1609*.

Best Regards,
Jürgen




OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Unexpectedly offline

[Chris Moller]

A lousy way to start a year.  Gute Besserung,Jürgen.

--cm

On 1/22/23 08:07, Dr. Jürgen Sauermann wrote:

Gentlemen,

I am sorry for not responding earlier to any emails to bug-apl@gnu.org.

I was unexpectedly taken offline after new year and I am
now online again, although only for a short period.  Just
having returned from ICU and hospital, I will join a rehabilitation
program in some clinic soon. The clinic has internet access, but I
will not be able to install my development environment there.

My current time plan is to continue support of GNU APL hopefully
around March 1, 2023 and I will then work on the backlog of error
reports. So please keep reporting errors even though I may not
respond immediately.

The current state of development (in SVN) is that I have added
wrappers between APL ⎕GTK and libgtk that should make the
majority of all libgtk functions accessible from in APL. The missing
piece is the reverse direction, i.e. events from GTK to APL.

Happy new year,
Jürgen











OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: libapl stdout

[Chris Moller]

For what it's worth, in an ongoing project in use:

   #include 

   #include 
   #include 

   #include 

   #include "aplexec.h"

   LIBAPL_error
   AplExec::aplExec (apl_op_e apl_op, QString &cmd,
  QString &outString, QString &errString)
   {
 LIBAPL_error execerr = LAE_NO_ERROR;

 switch(apl_op) {
 case APL_OP_EXEC:
   {
 std::stringstream outbuffer;
 std::streambuf *coutbuf = std::cout.rdbuf();
 std::cout.rdbuf(outbuffer.rdbuf());
 std::stringstream errbuffer;
 std::streambuf *cerrbuf = std::cerr.rdbuf();
 std::cerr.rdbuf(errbuffer.rdbuf());
 execerr = apl_exec (cmd.toStdString ().c_str ());
 std::cout.rdbuf(coutbuf);
 std::cerr.rdbuf(cerrbuf);
 outString = QString (outbuffer.str ().c_str ());
 errString = QString (errbuffer.str ().c_str ());
   }
   break;
 case APL_OP_COMMAND:
   {
 std::stringstream errbuffer;
 std::streambuf *cerrbuf = std::cerr.rdbuf();
 std::cerr.rdbuf(errbuffer.rdbuf());
 const char *res = apl_command (cmd.toStdString ().c_str ());
 if (res) {
   outString = QString (res);
   free ((void *)res);
 }
 std::cerr.rdbuf(cerrbuf);
 errString = QString (errbuffer.str ().c_str ());
   }
   break;
 }

 return execerr;
   }

I.e., I'm capturing stdout and stderr in strings.



On 1/27/23 10:18, Dr. Jürgen Sauermann wrote:

Hi enztec,

not sure if this helps, but if I remember correctly (I may not) then 
the main GNU APL output
goes to *stderr* (fd 2) and not to *stdout* (fd 1). The reason is 
somewhat historic because *stdout* is
buffered by default while *stderr* is not (which caused some issues 
with *stdout* when used

interactively that did not occur with *stderr*).

Best Regads,
Jürgen


On 1/15/23 12:19 AM, enz...@gmx.com wrote:

Hi

I'm still trying to resolve the failure of fpc using libapl to get 
it's stdout


trying to get libapl stdout to be gotten in my libapl/fpc program i 
read the
https://gist.github.com/houmei/cfd9e570b8de4d8fd55ada228d5ff004#file-readme-2-configure 



thinking fpc might be using a different stdout then the libapl does 
from this line
'but because the executable that is linked with libapl.so) has its 
own I/O channels.'


and re-compiled libapl with --with-android
and then compiling my program i get get :

/usr/local/lib/apl/libapl.so: undefined reference to `CIN'
/usr/local/lib/apl/libapl.so: undefined reference to `UERR'
/usr/local/lib/apl/libapl.so: undefined reference to `COUT'
/usr/local/lib/apl/libapl.so: undefined reference to `CERR'

is this suppose to happen ?

i get same error when compiling my libaplo.c program

how to set these in the c program?









OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: libapl stdout

[Chris Moller]

Qt isn't necessary--that's just the environment I'm working in.  From my 
example, get rid of the #include line.


Here's aplexec.h:

   #ifndef APLEXEC_H
   #define APLEXEC_H

   #include 
   #include 

   #define APL_VARIABLE "([⍙∆a-z][⍙∆_a-z0-9]*)"

   typedef enum {
 APL_OP_EXEC,
 APL_OP_COMMAND
   } apl_op_e;

   class AplExec
   {
   public:
 static LIBAPL_error
 aplExec (apl_op_e apl_op, QString &cmd,
  QString &outString, QString &errString);
   };
   #endif // APLEEXEC_H



Again, you don't need the Qt stuff.  Mostly, what you need is the

   #include 

line.  And you probably don't need the #define APL_VARIABLE 
"([⍙∆a-z][⍙∆_a-z0-9]*)" line


For this to work at all, you need to build Jürgen's APL twice, once as 
usual to install apl itself, and a second time with


   ./configure --with-libapl
   make install

(with any other options you need on the configure)

What this does is put apl-related stuff in /usr/local/include and 
/usr/local/lib.  (I think I manually copied Error.def from the apl 
source tree into /usr/local/include--I don't think it gets copied with 
the make install.)


On 1/27/23 16:28, enz...@gmx.com wrote:

Chris

i don't have qt installed nor do i have your
#include "aplexec.h"

On Fri, 27 Jan 2023 11:23:08 -0500
Chris Moller  wrote:


For what it's worth, in an ongoing project in use:

 #include 

 #include 
 #include 

 #include 

 #include "aplexec.h"

 LIBAPL_error
 AplExec::aplExec (apl_op_e apl_op, QString &cmd,
    QString &outString, QString &errString)
 {
   LIBAPL_error execerr = LAE_NO_ERROR;

   switch(apl_op) {
   case APL_OP_EXEC:
     {
   std::stringstream outbuffer;
   std::streambuf *coutbuf = std::cout.rdbuf();
   std::cout.rdbuf(outbuffer.rdbuf());
   std::stringstream errbuffer;
   std::streambuf *cerrbuf = std::cerr.rdbuf();
   std::cerr.rdbuf(errbuffer.rdbuf());
   execerr = apl_exec (cmd.toStdString ().c_str ());
   std::cout.rdbuf(coutbuf);
   std::cerr.rdbuf(cerrbuf);
   outString = QString (outbuffer.str ().c_str ());
   errString = QString (errbuffer.str ().c_str ());
     }
     break;
   case APL_OP_COMMAND:
     {
   std::stringstream errbuffer;
   std::streambuf *cerrbuf = std::cerr.rdbuf();
   std::cerr.rdbuf(errbuffer.rdbuf());
   const char *res = apl_command (cmd.toStdString ().c_str ());
   if (res) {
     outString = QString (res);
     free ((void *)res);
   }
   std::cerr.rdbuf(cerrbuf);
   errString = QString (errbuffer.str ().c_str ());
     }
     break;
   }

   return execerr;
 }

I.e., I'm capturing stdout and stderr in strings.






OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: libapl stdout

[Chris Moller]

QString is mmore or less equivalent to the C++ std::string class.

On 1/27/23 18:00, enz...@gmx.com wrote:

what do i replace all the qstring with

/apl/libapl/c > grepi qstring

./aplexec.h:18:aplExec (apl_op_e apl_op, QString &cmd,
./aplexec.h:19:QString &outString, QString &errString);
./libaplc.c:12:AplExec::aplExec (apl_op_e apl_op, QString &cmd,
./libaplc.c:13:QString &outString, QString &errString)
./libaplc.c:29:outString = QString (outbuffer.str ().c_str ());
./libaplc.c:30:errString = QString (errbuffer.str ().c_str ());
./libaplc.c:40:outString = QString (res);
./libaplc.c:44:errString = QString (errbuffer.str ().c_str ());


On Fri, 27 Jan 2023 17:18:01 -0500
Chris Moller  wrote:


Qt isn't necessary--that's just the environment I'm working in.  From my
example, get rid of the #include line.

Here's aplexec.h:

 #ifndef APLEXEC_H
 #define APLEXEC_H

 #include 
 #include 

 #define APL_VARIABLE "([⍙∆a-z][⍙∆_a-z0-9]*)"

 typedef enum {
   APL_OP_EXEC,
   APL_OP_COMMAND
 } apl_op_e;

 class AplExec
 {
 public:
   static LIBAPL_error
   aplExec (apl_op_e apl_op, QString &cmd,
    QString &outString, QString &errString);
 };
 #endif // APLEEXEC_H



Again, you don't need the Qt stuff.  Mostly, what you need is the

 #include 

line.  And you probably don't need the #define APL_VARIABLE
"([⍙∆a-z][⍙∆_a-z0-9]*)" line

For this to work at all, you need to build Jürgen's APL twice, once as
usual to install apl itself, and a second time with

 ./configure --with-libapl
 make install

(with any other options you need on the configure)

What this does is put apl-related stuff in /usr/local/include and
/usr/local/lib.  (I think I manually copied Error.def from the apl
source tree into /usr/local/include--I don't think it gets copied with
the make install.)

On 1/27/23 16:28,enz...@gmx.com  wrote:

Chris

i don't have qt installed nor do i have your
#include "aplexec.h"

On Fri, 27 Jan 2023 11:23:08 -0500
Chris Moller   wrote:


For what it's worth, in an ongoing project in use:

  #include 

  #include 
  #include 

  #include 

  #include "aplexec.h"

  LIBAPL_error
  AplExec::aplExec (apl_op_e apl_op, QString &cmd,
     QString &outString, QString &errString)
  {
    LIBAPL_error execerr = LAE_NO_ERROR;

    switch(apl_op) {
    case APL_OP_EXEC:
      {
    std::stringstream outbuffer;
    std::streambuf *coutbuf = std::cout.rdbuf();
    std::cout.rdbuf(outbuffer.rdbuf());
    std::stringstream errbuffer;
    std::streambuf *cerrbuf = std::cerr.rdbuf();
    std::cerr.rdbuf(errbuffer.rdbuf());
    execerr = apl_exec (cmd.toStdString ().c_str ());
    std::cout.rdbuf(coutbuf);
    std::cerr.rdbuf(cerrbuf);
    outString = QString (outbuffer.str ().c_str ());
    errString = QString (errbuffer.str ().c_str ());
      }
      break;
    case APL_OP_COMMAND:
      {
    std::stringstream errbuffer;
    std::streambuf *cerrbuf = std::cerr.rdbuf();
    std::cerr.rdbuf(errbuffer.rdbuf());
    const char *res = apl_command (cmd.toStdString ().c_str ());
    if (res) {
      outString = QString (res);
      free ((void *)res);
    }
    std::cerr.rdbuf(cerrbuf);
    errString = QString (errbuffer.str ().c_str ());
      }
      break;
    }

    return execerr;
  }

I.e., I'm capturing stdout and stderr in strings.




OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: libapl stdout

[Chris Moller]

All of the code below is in the C++ language and std::string is a very 
basic bit of C++.  If you're not familiar with C++, the string class, 
stringstream, stringbuf, and so on, the first thing you need to do is 
get some experience in C++.


There is no direct replacement for QString, but std::string is close.  See:

   https://cplusplus.com/reference/string/string/


On 1/27/23 19:47, enz...@gmx.com wrote:

sorry that means nothing to me as to what to replace the qstring below with


On Fri, 27 Jan 2023 19:38:51 -0500
Chris Moller  wrote:


QString is mmore or less equivalent to the C++ std::string class.

On 1/27/23 18:00,enz...@gmx.com  wrote:

what do i replace all the qstring with

/apl/libapl/c > grepi qstring

./aplexec.h:18:aplExec (apl_op_e apl_op, QString &cmd,
./aplexec.h:19:QString &outString, QString &errString);
./libaplc.c:12:AplExec::aplExec (apl_op_e apl_op, QString &cmd,
./libaplc.c:13:QString &outString, QString &errString)
./libaplc.c:29:outString = QString (outbuffer.str ().c_str ());
./libaplc.c:30:errString = QString (errbuffer.str ().c_str ());
./libaplc.c:40:outString = QString (res);
./libaplc.c:44:errString = QString (errbuffer.str ().c_str ());


On Fri, 27 Jan 2023 17:18:01 -0500
Chris Moller   wrote:


Qt isn't necessary--that's just the environment I'm working in.  From my
example, get rid of the #include line.

Here's aplexec.h:

  #ifndef APLEXEC_H
  #define APLEXEC_H

  #include 
  #include 

  #define APL_VARIABLE "([⍙∆a-z][⍙∆_a-z0-9]*)"

  typedef enum {
    APL_OP_EXEC,
    APL_OP_COMMAND
  } apl_op_e;

  class AplExec
  {
  public:
    static LIBAPL_error
    aplExec (apl_op_e apl_op, QString &cmd,
     QString &outString, QString &errString);
  };
  #endif // APLEEXEC_H



Again, you don't need the Qt stuff.  Mostly, what you need is the

  #include 

line.  And you probably don't need the #define APL_VARIABLE
"([⍙∆a-z][⍙∆_a-z0-9]*)" line

For this to work at all, you need to build Jürgen's APL twice, once as
usual to install apl itself, and a second time with

  ./configure --with-libapl
  make install

(with any other options you need on the configure)

What this does is put apl-related stuff in /usr/local/include and
/usr/local/lib.  (I think I manually copied Error.def from the apl
source tree into /usr/local/include--I don't think it gets copied with
the make install.)

On 1/27/23 16:28,enz...@gmx.com   wrote:

Chris

i don't have qt installed nor do i have your
#include "aplexec.h"

On Fri, 27 Jan 2023 11:23:08 -0500
Chris Mollerwrote:


For what it's worth, in an ongoing project in use:

   #include 

   #include 
   #include 

   #include 

   #include "aplexec.h"

   LIBAPL_error
   AplExec::aplExec (apl_op_e apl_op, QString &cmd,
  QString &outString, QString &errString)
   {
 LIBAPL_error execerr = LAE_NO_ERROR;

 switch(apl_op) {
 case APL_OP_EXEC:
   {
 std::stringstream outbuffer;
 std::streambuf *coutbuf = std::cout.rdbuf();
 std::cout.rdbuf(outbuffer.rdbuf());
 std::stringstream errbuffer;
 std::streambuf *cerrbuf = std::cerr.rdbuf();
 std::cerr.rdbuf(errbuffer.rdbuf());
 execerr = apl_exec (cmd.toStdString ().c_str ());
 std::cout.rdbuf(coutbuf);
 std::cerr.rdbuf(cerrbuf);
 outString = QString (outbuffer.str ().c_str ());
 errString = QString (errbuffer.str ().c_str ());
   }
   break;
 case APL_OP_COMMAND:
   {
 std::stringstream errbuffer;
 std::streambuf *cerrbuf = std::cerr.rdbuf();
 std::cerr.rdbuf(errbuffer.rdbuf());
 const char *res = apl_command (cmd.toStdString ().c_str ());
 if (res) {
   outString = QString (res);
   free ((void *)res);
 }
 std::cerr.rdbuf(cerrbuf);
 errString = QString (errbuffer.str ().c_str ());
   }
   break;
 }

 return execerr;
   }

I.e., I'm capturing stdout and stderr in strings.




OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

libapl.cc bug

[Chris Moller]

Hi, Jürgen,

Xtian Robert just sent me a libedif bug, but building libapl.so so I 
could fix that bug I found a few libapl bugs of the form:


   libapl.cc: In function ‘void disable_safe_mode()’:
   libapl.cc:985:4: error: ‘uprefs’ was not declared in this scope
 985 |    uprefs.safe_mode = false;
 |    ^~

The attached diff fixes these bugs, or at least identifies them.

Thanks,
Chris


Index: libapl.cc
===
--- libapl.cc	(revision 1706)
+++ libapl.cc	(working copy)
@@ -739,15 +739,15 @@
 void
 init_libapl(const char * progname, int log_startup)
 {
-   uprefs.safe_mode   = true;
-   uprefs.user_do_svars   = false;
-   uprefs.system_do_svars = false;
-   uprefs.requested_id= 2000;
+   UserPreferences::uprefs.safe_mode   = true;
+   UserPreferences::uprefs.user_do_svars   = false;
+   UserPreferences::uprefs.system_do_svars = false;
+   UserPreferences::uprefs.requested_id= 2000;
 
init_1(progname, log_startup);
 
-   uprefs.read_config_file(true,  log_startup);   // in /etc/gnu-apl.d/
-   uprefs.read_config_file(false, log_startup);   // in $HOME/.config/gnu_apl/
+   UserPreferences::uprefs.read_config_file(true,  log_startup);   // in /etc/gnu-apl.d/
+   UserPreferences::uprefs.read_config_file(false, log_startup);   // in $HOME/.config/gnu_apl/
 
init_2(log_startup);
 }
@@ -982,7 +982,7 @@
 void
 disable_safe_mode()
 {
-   uprefs.safe_mode = false;
+   UserPreferences::uprefs.safe_mode = false;
 }
 //
 const int libapl_version = 0;   // not standard interpreter


OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: SVN 1704 completely broke libedif

[Chris Moller]

Hi, Xtian,

Just pushed a fix for edif if you want to give it a try.  Works for me 
on SVN 1706 and yesterday's SVN 1708.


--cm

On 6/5/23 03:33, Christian Robert wrote:

SVN 1704 completely broke libedif

Juergen made UCS_string (const char *)  a private member of the class
so a lot of compile errors in edif.cc ...

Not sure if this can be fixed. I reverted to SVN 1702 meanwhile. The 
is no way I'll revert to the "DEL Editor" !



Xtian.





OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: SVN 1704 completely broke libedif

[Chris Moller]

Glad it works.

It's probably a better idea to run ./configure before building. That way 
the Makefiles will exactly match your environment.  The downside of 
having a choice of Linux distros is that they're all a little different.


--cm

On 6/6/23 15:34, Christian Robert wrote:

Hi Chris,

 work as well as it used to !

 many thanks for fixing this. I had to edit the generated ./libtool
 and change

from:

# Which release of libtool.m4 was used?
macro_version=2.4.7
macro_revision=2.4.7

to:

# Which release of libtool.m4 was used?
macro_version=2.4.6
macro_revision=2.4.6

and the "make" worked fine thereafter


Xtian.

On 2023-06-06 11:31, Chris Moller wrote:

Hi, Xtian,

Just pushed a fix for edif if you want to give it a try.  Works for 
me on SVN 1706 and yesterday's SVN 1708.


--cm

On 6/5/23 03:33, Christian Robert wrote:

SVN 1704 completely broke libedif

Juergen made UCS_string (const char *)  a private member of the class
so a lot of compile errors in edif.cc ...

Not sure if this can be fixed. I reverted to SVN 1702 meanwhile. The 
is no way I'll revert to the "DEL Editor" !



Xtian.







OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: SVN 1704 completely broke libedif

[Chris Moller]

Yeah, I saw your comment in one of the .hh files. What I did was wrap 
all the edif ASCII strings in UTF8_string() calls.  That works, but if 
it's circumventing what you're trying to do, let me know and I'll think 
of something else.


Even after a lot of years, I'm still not sure of the differences between 
UTF, UCS, Unicode, etc, etc.


--cm

On 6/6/23 15:56, Dr. Jürgen Sauermann wrote:

Hi,

sorry for that. The reason for making it private is to entirely 
prevent its usage.
The former implementation of of it only worked for ASCII strings. 
There was
a note about that in the header file, but I have seen quite a few 
incorrect
usages of it (read: with UTF8-encoded strings) which then caused 
other, difficult

to find, errors later on.

Best Regards,
Jürgen


On 6/6/23 17:31, Chris Moller wrote:

Hi, Xtian,

Just pushed a fix for edif if you want to give it a try. Works for me 
on SVN 1706 and yesterday's SVN 1708.


--cm

On 6/5/23 03:33, Christian Robert wrote:

SVN 1704 completely broke libedif

Juergen made UCS_string (const char *)  a private member of the class
so a lot of compile errors in edif.cc ...

Not sure if this can be fixed. I reverted to SVN 1702 meanwhile. The 
is no way I'll revert to the "DEL Editor" !



Xtian.









OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: SVN 1704 completely broke libedif

[Chris Moller]

Thanks for the explanation--very much appreciated.

I more or less stumbled onto 1. and am using that in every relevant 
circumstance, but I'll revise to 4.  (I can't generally use 5. because 
some of the strings use what I assume are non-ASCII characters like "←".)


Thanks again,
Chris


On 6/7/23 10:24, Dr. Jürgen Sauermann wrote:

Hi Chris,

wrapping arbitrary (= UTF8-encoded) strings into UTF8_string first is
the proper way to go. Consider the differences between:
*
**1.  UCS_string yyy(UTF8_string(xxx));   // almost proper, but 
ambiguous (most vexing parse error)**

**2.  UCS_string yyy(xxx);    // now private: so never use it
3a. UTF8_string utf(xxx);  // really proper
3b. UCS_string yyy(utf);
4. ***UCS_string yyy((UTF8_string(xxx)));   // also proper (this is 1. 
without the *most vexing parse error)

5.  UCS_ASCII_string yyy(xxx)
***
If *xxx* is entirely *ASCII* then all of the above are equivalent.

Otherwise the difference is that 1. properly decodes UTF8-encoded
strings while the old 2. (which is now  disabled by private:) did not
(and the compiler has no way to detect an incorrect usage of 2.

Even worse, C++ would sometimes do 2. automatically (and incorrectly)
and without notice. Probably some of the recent Tokenization Errors
reported on bug-apl were caused by this.

Although 1. was throwing an assertion when used incorrectly, some
people wrapped a *try {} catch {}* around it which caused the error
to slip through unnoticed (at least up to the tokenizer).

A somewhat  unfortunate decision in the C++11 ff. standards was to
resolve *yyy* in  1. (which is ambiguous at a closer look) into a 
declaration

of function*yyy() *and not (as gcc still does) into two constructor calls
*UTF8_string(xxx)* followed by *UCS_string()* with the first. This problem
can apparently be avoided by using 4. instead of 1. (note the extra pair
of () which is NOT redundant).

Finally, 5. is a safe replacement for 2. (and the comment in the *.hh* 
file

is still valid (so *xxx* MUST be ASCII), which should hopefully avoid the
automatic use of 2. by the compiler. It is also easier to use with *grep*
in order to spot the (still possible) incorrect usage of 5.

Hope this helps,
Jürgen


On 6/6/23 22:13, Chris Moller wrote:
Yeah, I saw your comment in one of the .hh files.  What I did was 
wrap all the edif ASCII strings in UTF8_string() calls.  That works, 
but if it's circumventing what you're trying to do, let me know and 
I'll think of something else.


Even after a lot of years, I'm still not sure of the differences 
between UTF, UCS, Unicode, etc, etc.


--cm

On 6/6/23 15:56, Dr. Jürgen Sauermann wrote:

Hi,

sorry for that. The reason for making it private is to entirely 
prevent its usage.
The former implementation of of it only worked for ASCII strings. 
There was
a note about that in the header file, but I have seen quite a few 
incorrect
usages of it (read: with UTF8-encoded strings) which then caused 
other, difficult

to find, errors later on.

Best Regards,
Jürgen


On 6/6/23 17:31, Chris Moller wrote:

Hi, Xtian,

Just pushed a fix for edif if you want to give it a try. Works for 
me on SVN 1706 and yesterday's SVN 1708.


--cm

On 6/5/23 03:33, Christian Robert wrote:

SVN 1704 completely broke libedif

Juergen made UCS_string (const char *)  a private member of the class
so a lot of compile errors in edif.cc ...

Not sure if this can be fixed. I reverted to SVN 1702 meanwhile. 
The is no way I'll revert to the "DEL Editor" !



Xtian.













OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: apl won't start

[Chris Moller]

Is the battery dead? :-)



On 8/10/23 09:55, Bill Daly wrote:

Log of session attached

w




OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: output formatting

[Chris Moller]

Try adding the option "--PW 1000" (or any large number less than 
1).  That will set the print width to huge.


The tr utility with the -s option can compress repeated spaces into a 
single space.


sed '$d' will kill the last line.

So something like

   apl --PW 500 --eval "2 70⍴⍳140" | tr -s ' ' | sed '$d'


should work.

On 9/9/23 19:07, Stephen Lewis via Bugs and suggestions for GNU APL wrote:

I am a novice and I am using APL to calculate the
points for a surface. The output will go to another
program. The goal is to write a matrix, with the correct number of rows
and columns, to a file. Elements should be separated by 
and rows should be separated by . I have found that
the output is formatted in an unexpected way.

Test case to write a matrix with 2 rows of 50 columns.
Is there any way to write a matrix with correct shape
to a file when rows exceed 80 characters? I have tried
the following:

Method 1
script_1.apl:
-
2 50⍴⍳100
-
apl < script_1.apl
apl < script_1.apl > out_1.txt
Writes welcome banner, elements in 4 row matrix with spurious
extra  characters and four messages about end-of-input
and a goodbye message and also writes to stderr.
Method 2
apl -f script_1.apl
apl -f script_1.apl > out_2.txt
Writes welcome banner, elements in 4 row matrix with spurious
extra  characters  and a goodbye message and remains in
'apl' unless stdout is redirected to a file or )OFF added to script.
Method 3
script_2.apl:
-
#! /usr/bin/apl --script --OFF
2 50⍴⍳100
-
./script_2.apl
./script_2.apl > out_3.txt
Must add )OFF to script or use --OFF.
Writes elements in 4 row matrix with spurious
extra  characters and a blank line.
I would like two rows of 50 elements but
output file looks like this:
-
  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
   27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49  50
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76
   77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

-




OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

General chatter.

[Chris Moller]

First, due to my old ISP having apparently gone out of business while 
keeping my mollerware.com domain locked, my old mol...@mollerware.com 
address is at least temporarily dead.  I'm mol...@nc.rr.com for the moment.


Second, is there a Windows version of APL that runs without using 
Cygwin?  My son has need of it--he's stuck in a benighted environment 
that refuses to acknowledge the existence of Linux.


Thanks,
Chris


OpenPGP_0xC76DF093675A50A8.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: General chatter.

[Chris Moller]

Hi, Jürgen,

Thanks for the reply, though it looks like a no-go for my son--he's a 
medical physicist perfectly at home with tiny little (possible 
imaginary) particles but who hasn't even mastered "Hello, World," let 
alone complex builds.  And I've never in my life used Windows.


Not ideal, but I guess I'll have to take Mike Hall's suggestion and 
recommend Dyalog APL, or some other commercial version, to my son. 
(Which is too bad--he deals a lot with the differing effects on tissues 
of different X-ray wavelengths and I expect ⎕FFT would have been very 
useful.)


Thanks again,
Chris

On 3/30/24 09:57, Dr. Jürgen Sauermann wrote:

Hi Chris,

some experience of mine that might help.

1. Some time ago I tried really hard to compile GNU APL with the 
(standard?) Microsoft C++
compiler so that GNU APL runs natively under Windows. I don't remember 
which compiler
(there seems to be a few of them), but I got thousands of errors and 
warnings, most of them
rather stupid and some of them really hard to fix while maintaining 
compatibility of the code

with the gcc compiler.

2. Regarding cygwin, it very much looks like you need it only to build 
GNU APL (since it has the
necessary development tools (autoconf, m4, ...) to do so. Once you 
habe produced the GNU APL
binary under cygwin you can link it with one or two of the libraries 
that come with cygwin. The
result of that seems to run properly in the Windows cmd.exe (don't 
recall which Windows version

I tried.

3. Be warned: The standard C++ development environment in Windows is 
quite a mess and
far more complicated than the standard GNU APL build system. Without 
autoconf/automake
you will need to do many changes in Makefiles and header files so that 
they compile. And several
GNU APL goodies (⎕FFT, ⎕PNG, ⎕XML) may not be available under Windows 
because the

corresponding libraries are missing.

4. I believe that NARS (*https://www.nars2000.org*) is a free 
interpreter that runs under Windows
and is, like GNU APL, free (both are licensed under the GPLv3) . Most 
commercial APL vendors offer
Windows based APL imterpreters which are free of charge for private 
use but not free because they

come with limitations as to their use.

Best Regards,
Jürgen


On 3/29/24 18:47, Chris Moller wrote:
First, due to my old ISP having apparently gone out of business while 
keeping my mollerware.com domain locked, my old mol...@mollerware.com 
address is at least temporarily dead.  I'm mol...@nc.rr.com for the 
moment.


Second, is there a Windows version of APL that runs without using 
Cygwin?  My son has need of it--he's stuck in a benighted environment 
that refuses to acknowledge the existence of Linux.


Thanks,
Chris






OpenPGP_0xC76DF093675A50A8.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: General chatter.

[Chris Moller]

Thanks for the Dyalog suggestion.  I pulled down the Linux version this 
morning and it seems to play--as long as you don't need Jürgen's 
enhancements.


Chris

On 3/29/24 16:23, M.Hall wrote:

Perhaps Dyalog?
https://www.dyalog.com/dyalog/microsoft-windows.htm
https://www.dyalog.com/dyalog/current-platforms.htm


On Fri, Mar 29, 2024 at 12:47 PM Chris Moller  wrote:

First, due to my old ISP having apparently gone out of business
while keeping my mollerware.com <http://mollerware.com> domain
locked, my old mol...@mollerware.com address is at least
temporarily dead.  I'm mol...@nc.rr.com for the moment.

Second, is there a Windows version of APL that runs without using
Cygwin?  My son has need of it--he's stuck in a benighted
environment that refuses to acknowledge the existence of Linux.

Thanks,
Chris



--
Mike Hall






OpenPGP_0xC76DF093675A50A8.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[Bug-apl] Command-line bug, apl-1.3

[Chris Moller]

apl.texi and the files derived from it refer to a command line option 
"[no]COLOR," but in main.cc the options are "Color" and "noColor."


   apl --noColor


works

   apl --noCOLOR


yields "unknown option '--noCOLOR'"

[Bug-apl] A GTK wrapper for GNU APL

[Chris Moller]

I've written a GTK+-based wrapper for APL and Jürgen suggested I tell 
people about it...


Basically, what it does is provide a textual interface to APL that makes 
it unnecessary to install keymaps and fonts in xterm, konsole, or 
whatever CLI you usually use--the keymap and font are built into the 
utility.


If you're interested, all the links are in the last entry in the 
Community page at http://www.gnu.org/software/apl/Community.html


For more information, there are INSTALL and README files in the 
package.  Any bugs or feature requests, let me know.


Chris Moller

Re: [Bug-apl] A GTK wrapper for GNU APL

[Chris Moller]

The --with-apl-source-dir= thing is left over from an old version and I 
forget to take it out of the INSTALL file.  Now it asks apl itself where 
the source is.  If it's important, I can stick the option back in, but, 
mostly, it should do things automagically.


You can set the font size with the -s option:

   aplwrap -s 22

for example, will set the size to 22 points.  Default is 12 points, 
which is kinda big, but with anything much smaller some characters like 
del-tilde are pretty muddy.   I'll see if I can find a mono-font.


And, finally, the scroll thing is a "feature" ofGtkTextView I haven't 
yet been able to outwit, but I'll keep hacking.


cm

On 08/12/14 18:47, David Lamkins wrote:

Nice start! Thanks for doing this. :)

--with-apl-source-dir= is not recognized by configure, but

APL_SOURCES= ./configure

seems to work.


A few obvious things for the wish list:

1. a monospaced font
2. ability to adjust font size
3. automatically scroll to end of buffer on output

Again, thank you. This is a very pleasant surprise. :)

--
"The secret to creativity is knowing how to hide your sources."
   Albert Einstein


http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/

Re: [Bug-apl] A GTK wrapper for GNU APL

[Chris Moller]

Monospace added; use option -m


On 08/12/14 18:47, David Lamkins wrote:

Nice start! Thanks for doing this. :)

--with-apl-source-dir= is not recognized by configure, but

APL_SOURCES= ./configure

seems to work.


A few obvious things for the wish list:

1. a monospaced font
2. ability to adjust font size
3. automatically scroll to end of buffer on output

Again, thank you. This is a very pleasant surprise. :)

--
"The secret to creativity is knowing how to hide your sources."
   Albert Einstein


http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/

Re: [Bug-apl] A GTK wrapper for GNU APL

[Chris Moller]

The keymap came from Sharp APL, which I'd been using for years, but it's 
easy enough to modernise it.  I'll tinker that in the morning.


The -m switch switched to the SimPL font which was alleged to be 
monospace, but isn't quite.  I replaced it just now with GNU FreeMono, 
which is better, but still doesn't do ]keyb exactly right.  I'll see 
what I can do about it.  For what I do, proportional pacing looks 
better, but it's easy enough to make mono the default.


cm


On 08/13/14 00:11, Blake McBride wrote:

Dear Chris,

Wow.  Very nice!  A few things I noticed:

1.  The -m did not put it in mono font for me (using current GIT).

2.  Mono font really should be the default otherwise nothing displays 
correctly.  Try ]keyb.  Try 5 5⍴⍳25


3.  You are using an old keyboard mapping.  It doesn't match the 
output of ]keyb.  It also doesn't match my actual keyboard (which was 
designed to match the GNU APL standard.)


Thanks.

Blake





On Tue, Aug 12, 2014 at 1:43 PM, Chris Moller <mailto:mol...@mollerware.com>> wrote:


I've written a GTK+-based wrapper for APL and Jürgen suggested I
tell people about it...

Basically, what it does is provide a textual interface to APL that
makes it unnecessary to install keymaps and fonts in xterm,
konsole, or whatever CLI you usually use--the keymap and font are
built into the utility.

If you're interested, all the links are in the last entry in the
Community page at http://www.gnu.org/software/apl/Community.html

For more information, there are INSTALL and README files in the
    package.  Any bugs or feature requests, let me know.

Chris Moller

Re: [Bug-apl] A GTK wrapper for GNU APL

[Chris Moller]

Yeah, just found that.  I'll put up a new version in the morning.


On 08/13/14 01:29, Elias Mårtenson wrote:
I recommend using GNU FreeMono as the font. That's what I'm using in 
Emacs for APL buffers and it looks great. Much better than the 
disasters of fonts used by Dyalog.



On 13 August 2014 13:27, David Lamkins <mailto:da...@lamkins.net>> wrote:


On Tue, Aug 12, 2014 at 5:59 PM, Chris Moller
mailto:mol...@mollerware.com>> wrote:

The --with-apl-source-dir= thing is left over from an old
version and I forget to take it out of the INSTALL file.  Now
it asks apl itself where the source is.  If it's important, I
can stick the option back in, but, mostly, it should do things
automagically.


Cool. I didn't think to try that.

You can set the font size with the -s option:

aplwrap -s 22

for example, will set the size to 22 points. Default is 12
points, which is kinda big, but with anything much smaller
some characters like del-tilde are pretty muddy.   I'll see if
I can find a mono-font.


Sadly, font size doesn't seem to be scaled to screen resolution
(at least not on Fedora). On my work laptop with an HD screen, 17
points is a reasonable font size.

-- 
"The secret to creativity is knowing how to hide your sources."

   Albert Einstein


http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/

Re: [Bug-apl] A GTK wrapper for GNU APL

[Chris Moller]

I've just pushed a new version to github.

 * Switched to the FreeMono font rather than the SimPL font. ]keyb
   still doesn't look right, but I think it's the box characters
   screwing up and not the normal characters. Mono is now the default;
   use the -v option if you  want variable width.
 * Revised the keymap to match ]keyb.  There are a few symbols,
   circle-diaresis, star-diaresis, and quad-colon that GNU APL doesn't
   seem to support, and since I'm basing my keymap on the GNU APL
   Avec.def file, nothing happens when you press those keys.  Let me
   know if that's a problem and I'll try to do something about it. 
   Also, in the real world, diamond is on the alt-backquote key but

   KDE-world intercepts that key and there's no way to change that, so
   I've mapped diamond to the otherwise unused alt-d. ]keyb also shows
   a bizarre symbol, a tilde-zero or something like that, on alt-].  I 
   can't find anything similar in the Unicode tables, so I'm ignoring

   it,  Let me know if that's a problem.

Have fun,
cm


On 08/13/14 00:11, Blake McBride wrote:

Dear Chris,

Wow.  Very nice!  A few things I noticed:

1.  The -m did not put it in mono font for me (using current GIT).

2.  Mono font really should be the default otherwise nothing displays 
correctly.  Try ]keyb.  Try 5 5⍴⍳25


3.  You are using an old keyboard mapping.  It doesn't match the 
output of ]keyb.  It also doesn't match my actual keyboard (which was 
designed to match the GNU APL standard.)


Thanks.

Blake

Re: [Bug-apl] A GTK wrapper for GNU APL

[Chris Moller]

 * Added the command-line stuff.
 * Fixed the assign arrow and branch arrow transposition.

Both pushed to github.

I'll look at the quad-PW stuff

On 08/13/14 16:36, David Lamkins wrote:

Here's a feature request:

- Provide a means to pass command-line arguments to APL.

At the very least, I'd like to be able to do something like:

$ aplwrap -s 16 -- --my-option 1234

where everything from -- onward would be tacked onto the end of 
aplwrap's apl_argv[].


That way, everything after the -- would be available via quad-ARG for 
consumption by the APL program.

Re: [Bug-apl] A GTK wrapper for GNU APL

[Chris Moller]

I'm not sure I get it...

   aplwrap -- --LX "9-8"

opens a window containing the result and

  ?ARG

yields

 apl --noColor --rawCIN -w 500 --silent --LX 8-9


   aplwrap -- -f plotsincos

runs the script.  Is there something I'm missing?



On 08/13/14 18:16, David Lamkins wrote:
Sorry... I didn't explain the command-line stuff completely and forgot 
a part.


Here's a patch (attached).


On Wed, Aug 13, 2014 at 2:22 PM, Chris Moller <mailto:mol...@mollerware.com>> wrote:


  * Added the command-line stuff.
  * Fixed the assign arrow and branch arrow transposition.

Both pushed to github.

I'll look at the quad-PW stuff


On 08/13/14 16:36, David Lamkins wrote:

Here's a feature request:

- Provide a means to pass command-line arguments to APL.

At the very least, I'd like to be able to do something like:

$ aplwrap -s 16 -- --my-option 1234

where everything from -- onward would be tacked onto the end of
aplwrap's apl_argv[].

That way, everything after the -- would be available via quad-ARG
for consumption by the APL program.





--
"The secret to creativity is knowing how to hide your sources."
   Albert Einstein


http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/

Re: [Bug-apl] A GTK wrapper for GNU APL

[Chris Moller]

t 
alignment on that line.  Remember this is the same workspace.



Thanks.

Blake


On Wed, Aug 13, 2014 at 12:33 PM, Chris Moller <mailto:mol...@mollerware.com>> wrote:


I've just pushed a new version to github.

  * Switched to the FreeMono font rather than the SimPL font. 
]keyb still doesn't look right, but I think it's the box

characters screwing up and not the normal characters. Mono is
now the default; use the -v option if you  want variable width.
  * Revised the keymap to match ]keyb.  There are a few symbols,
circle-diaresis, star-diaresis, and quad-colon that GNU APL
doesn't seem to support, and since I'm basing my keymap on the
GNU APL Avec.def file, nothing happens when you press those
keys.  Let me know if that's a problem and I'll try to do
something about it.  Also, in the real world, diamond is on
the alt-backquote key but KDE-world intercepts that key and
there's no way to change that, so I've mapped diamond to the
otherwise unused alt-d. ]keyb also shows a bizarre symbol, a
tilde-zero or something like that, on alt-].  I  can't find
anything similar in the Unicode tables, so I'm ignoring it, 
Let me know if that's a problem.


Have fun,
cm


On 08/13/14 00:11, Blake McBride wrote:

Dear Chris,

Wow.  Very nice!  A few things I noticed:

1.  The -m did not put it in mono font for me (using current GIT).

2.  Mono font really should be the default otherwise nothing
displays correctly.  Try ]keyb.  Try 5 5⍴⍳25

3.  You are using an old keyboard mapping.  It doesn't match the
output of ]keyb.  It also doesn't match my actual keyboard (which
was designed to match the GNU APL standard.)

Thanks.

Blake

Re: [Bug-apl] GNU APL GTK wrapper

[Chris Moller]

I'll take a look at that.  Is your protocol documented somewhere? Or is 
it implicit in gnu-apl-mode/native?


cm


On 08/13/14 23:28, Elias Mårtenson wrote:

Hello Chris,

I've been following the discussions about the GTK wrapper, and while 
I'm not using it myself (since I work on the Emacs integration) I 
realise that there are plenty of (potential) overlaps between our 
projects.


In particular, I want to let you know about the Emacs mode backchannel 
protocol that the mode uses for directly communicating with the GNU 
APL interpreter. When started, if gives you a simple text-based 
protocol through which you can do things such as defining functions or 
creating listeners that send you a message whenever a variable is 
changed (this is used by the realtime variable watcher).


It would be neat if you were to consider implementing some of the 
feature I added to the Emacs mode, and if you do it would be useful if 
you used the same protocol as I am using.


Please let me know if you have any questions.

Regards,
Elias

Re: [Bug-apl] A GTK wrapper for GNU APL

[Chris Moller]

A few more patches pushed, including mapping the keyboard interrupt to 
the ctrl-break key.


cm


On 08/13/14 19:24, Blake McBride wrote:

IMO either Copy or Break should be moved to a menu option.


On Wed, Aug 13, 2014 at 6:21 PM, David Lamkins > wrote:


Control-C is bound to GTK's copy. That's going to interfere with
the key's role as the APL attention signal.

Re: [Bug-apl] GNU APL GTK wrapper

[Chris Moller]

Very cool.  I'll definitely try it out once aplwrap is reasonably stable.

cm

On 08/14/14 20:30, Elias Mårtenson wrote:


It's very much undocumented. It's also very ad-hoc since I just added
functions as they were needed.

You can see the implementation in the GNU APL source under
src/emacs_mode I think. Every command is in its own file with a name
ending with *Command.cc.

I'm on the phone right now so I can't give you a comprehensive list,
but there are commands that do:

Show the implementation of a function
Define a new function
List all functions, variables
Trace updates to a variable
List all system commands
List all quad-variables
Show the si-stack
Clear the si-stack
Get the tag for a function (the tag contains the source file and line
where it was defined)

If you need other commands, it's trivial to add.

Regards,
Elias

On 15 Aug 2014 04:24, "Chris Moller" mailto:mol...@mollerware.com>> wrote:

I'll take a look at that.  Is your protocol documented somewhere?
Or is it implicit in gnu-apl-mode/native?

cm


On 08/13/14 23:28, Elias Mårtenson wrote:

Hello Chris,

I've been following the discussions about the GTK wrapper, and
while I'm not using it myself (since I work on the Emacs
integration) I realise that there are plenty of (potential)
overlaps between our projects.

In particular, I want to let you know about the Emacs mode
backchannel protocol that the mode uses for directly
communicating with the GNU APL interpreter. When started, if
gives you a simple text-based protocol through which you can do
things such as defining functions or creating listeners that send
you a message whenever a variable is changed (this is used by the
realtime variable watcher).

It would be neat if you were to consider implementing some of the
feature I added to the Emacs mode, and if you do it would be
useful if you used the same protocol as I am using.

Please let me know if you have any questions.

Regards,
Elias

[Bug-apl] Possible bugs in ]keyb output

[Chris Moller]

For a few days, David Lamkins and I have been kicking around a problem 
in the ]keyb output.  Turns out the least tractable of these seems to be 
the result of two different utf8 sequences used for the epsilon-underbar 
character:


]keybuses utf8 e2 8b b8, unicode 22f8, "ELEMENT OF WITH UNDERBAR"

]keyb 1 uses utf8 e2 8d b7, unicode 2377, "APL FUNCTIONAL SYMBOL EPSILON 
UNDERBAR"


The first of these, U+22f8, doesn't exist in either the FreeMono or 
SimPL fonts; I'm guessing that GTK's text engine, pango, is just 
grabbing the closest glyph it can find from some other font, which turns 
out to be of a different width.  U+22f8 isn't in Avec.def.


U+2377 exists in both fonts and corresponds to EPSILON_UNDERBAR in Avec.def.

I'm more or less guessing that the data for ]keyb comes from either 
keyboard.dyalog.txt or keyboard1.dyalog.txt, both of which contain the 
broken U+22f8 character while ]keyb 1 comes from either keyboard.txt or 
keyboard1.txt, both of which contain the working U+2377.  No idea, of 
course, if these differences are deliberate.


Anyway, the latest push of aplwrap is stable with respect everything 
except dealing with these differences in ]keyb output.


Chris Moller

Re: [Bug-apl] A GTK wrapper for GNU APL

[Chris Moller]

I'm not sure what you're trying to do.  Would this do it?

 if (((key_event->state == 0 || key_event->state == GDK_MOD2_MASK) &&
   key_event->keyval == GDK_KEY_Return) ||
  (key_event->state == GDK_MOD2_MASK
   && key_event->keyval == GDK_KEY_KP_Enter)) {

   // send line to APL

   }

(GDK_MOD2_MASK is numlock)

What this does is:

 * If the state is zero or Numlock is on, and Return is pressed, send
   the line to APL.
 * If numlock is off, treat KP_Enter like a normal character and insert
   a newline into the buffer.
 * if numlock is on, treat KP_Enter like Return and send the line to APL.

cm

On 08/13/14 17:03, Frederick H. Pitts wrote:

Hello Chris,

Please consider 1) filtering out whether the 'NumLock' is active or not
when you test the key event state is 0 and keyval is GDK_KEY_Return and
2) adding support for a keyval of GDK_KEY_KP_Enter in the same test.
Then using the numeric keypad with aplwrap would be a lot more pleasant.
As it is right now, aplwrap doesn't send text to GnuAPL on return key
presses when the 'NumLock' is active.

Thanks,

Fred
Retired Chemical Engineer

On Wed, 2014-08-13 at 13:33 -0400, Chris Moller wrote:

I've just pushed a new version to github.

   * Switched to the FreeMono font rather than the SimPL font.
 ]keyb still doesn't look right, but I think it's the box
 characters screwing up and not the normal characters. Mono is
 now the default; use the -v option if you  want variable
 width.
   * Revised the keymap to match ]keyb.  There are a few symbols,
 circle-diaresis, star-diaresis, and quad-colon that GNU APL
 doesn't seem to support, and since I'm basing my keymap on the
 GNU APL Avec.def file, nothing happens when you press those
 keys.  Let me know if that's a problem and I'll try to do
 something about it.  Also, in the real world, diamond is on
 the alt-backquote key but KDE-world intercepts that key and
 there's no way to change that, so I've mapped diamond to the
 otherwise unused alt-d. ]keyb also shows a bizarre symbol, a
 tilde-zero or something like that, on alt-].  I  can't find
 anything similar in the Unicode tables, so I'm ignoring it,
 Let me know if that's a problem.

Have fun,
cm



On 08/13/14 00:11, Blake McBride wrote:


Dear Chris,


Wow.  Very nice!  A few things I noticed:


1.  The -m did not put it in mono font for me (using current GIT).


2.  Mono font really should be the default otherwise nothing
displays correctly.  Try ]keyb.  Try 5 5⍴⍳25


3.  You are using an old keyboard mapping.  It doesn't match the
output of ]keyb.  It also doesn't match my actual keyboard (which
was designed to match the GNU APL standard.)


Thanks.


Blake

Re: [Bug-apl] A GTK wrapper for GNU APL

[Chris Moller]

Applied, committed, and pushed to github.

Chris
Retired Computer Engineer


On 08/16/14 17:51, Frederick H. Pitts wrote:

Chris,

I'm using

   if (
   /* Filter out NumLock status from event state */
   ( key_event->state & ~ GDK_MOD2_MASK ) == 0 &&
   (
 key_event->keyval == GDK_KEY_Return ||
   /* Honor numeric keypad enter key */
   key_event->keyval == GDK_KEY_KP_Enter
   )
   ) { /* send line to APL */ }

I think we are on the same page.  Only difference I see between your and
my solutions is that mine will honor the numeric keypad enter key
irrespective of the NumLock state whereas your requires NumLock to be
active for the numeric keypad enter key to be honored.  Personally, I
prefer the former arrangement.

Regards,

Fred
Retired Chemical Engineer

Re: [Bug-apl] Requesting a couple of minor keyboard tweaks.

[Chris Moller]

On 08/16/14 22:09, David B. Lamkins wrote:

There are two small tweaks that I'd like to see w.r.t. key mapping and
binding:

1. GNOME binds alt-` to rotate through an applications windows, making
this keystroke unavailable for ◊ in aplwrap. Through trial and error I
discovered that I can use ctrl-alt-` instead.

While documenting this would be OK, it's still inconsistent with the
behavior of the rest of the alt-key mappings. Is it possible to disable
the GNOME intercept on a per-app basis? Failing that, perhaps ◊ could be
duplicated on some other keytop to give folks who don't read
documentation a chance to use that key.


Don't know about GNOME, but there's no way in KDE to disable or remap
that binding.  That's why I put diamond on alt-shift-D, D-for-diamond.



2. With laptops, netbooks and other compact devices, keys like Break,
PrintScreen, SysRequest, ScrollLock, Pause and Break are disappearing.
(None of the keyboards that I use have a Break key.) Would it be
possible to add a second binding for the APL attention key? It's going
to be a challenge to find something that isn't either already bound or
not readily available in international keyboard layouts. Perhaps ctrl-.
(ctrl-period)?


Do your keyboards have a "Windows" key?  That key shows up in GDK as
GDK_KEY_Super_L, making it possible for ctrl-Windows to be used as an
interrupt.  (I just tried it.)

Re: [Bug-apl] Requesting a couple of minor keyboard tweaks.

[Chris Moller]

The built-in keymap image in aplwrap Help>>Keymap shows diamond on
alt-shift-D.

Between older keyboards that have Break but not Windows, and newer that
have Windows but not Break, I don't think interrupting on ctrl-Period is
necessary, so I left that out.

Other than that, it's been pushed.


On 08/17/14 00:30, David B. Lamkins wrote:

On Sat, 2014-08-16 at 22:45 -0400, Chris Moller wrote:

On 08/16/14 22:09, David B. Lamkins wrote:


There are two small tweaks that I'd like to see w.r.t. key mapping and
binding:

1. GNOME binds alt-` to rotate through an applications windows, making
this keystroke unavailable for ◊ in aplwrap. Through trial and error I
discovered that I can use ctrl-alt-` instead.

While documenting this would be OK, it's still inconsistent with the
behavior of the rest of the alt-key mappings. Is it possible to disable
the GNOME intercept on a per-app basis? Failing that, perhaps ◊ could be
duplicated on some other keytop to give folks who don't read
documentation a chance to use that key.

Don't know about GNOME, but there's no way in KDE to disable or remap
that binding.  That's why I put diamond on alt-shift-D, D-for-diamond.

Ah. That's what I get for using ]KEYB as a reference.


2. With laptops, netbooks and other compact devices, keys like Break,
PrintScreen, SysRequest, ScrollLock, Pause and Break are disappearing.
(None of the keyboards that I use have a Break key.) Would it be
possible to add a second binding for the APL attention key? It's going
to be a challenge to find something that isn't either already bound or
not readily available in international keyboard layouts. Perhaps ctrl-.
(ctrl-period)?

Do your keyboards have a "Windows" key?  That key shows up in GDK as
GDK_KEY_Super_L, making it possible for ctrl-Windows to be used as an
interrupt.  (I just tried it.)


Yes, all my keyboards do have a Windows key.

Patch attached for enabling APL attention via ctrl-break,
ctrl-left_super (a.k.a. Windows) and ctrl-period.

Re: [Bug-apl] aplwrap: what's with the s?

[Chris Moller]

I'm not seeing it: 'S' and 's' both look normal to me.

As part of installing aplwrap, I put a copy of Freemono.ttf in 
$INSTALLDIR/share/fonts and run fc-cache.  If you don't already have 
Freemono.ttf, this makes it available, but if you already have a copy, 
whatever you already had may take precedence.  The Freemono I install is 
from GNU: freefont-ttf-20120503.zip, which I think is the latest.


cm


On 08/18/14 11:19, Blake McBride wrote:
Yea, I've verified, capitol S has a problem too.  I don't see it in 
the terminal.


Thanks.

Blake



On Mon, Aug 18, 2014 at 10:11 AM, David B. Lamkins > wrote:


I see it. The upper loop of the s is offset to the right, making it
appear to lean. Same thing with S.

I see the same thing when I use the same font in Emacs.


On Mon, 2014-08-18 at 09:56 -0500, Blake McBride wrote:
> I don't know if it is my imagination but the s in aplwrap seems
> italic.
>
>
> For example, when I display the following in aplwrap:
>
>
> abcdefghijklmnopqrstuvwxyz
>
>
> The s appear italic.  Not sure if the capitol has the problem or
not,
> but the lower case s appears wrong to me.  Is this just a funky
font,
> or is there a problem?
>
>
> Thanks.
>
>
> Blake
>
>

Re: [Bug-apl] Possible bugs in ]keyb output

[Chris Moller]

Thanks, and I'll check out the alternative char stuff.

cm


On 08/18/14 12:19, Juergen Sauermann wrote:

Hi,

regarding ? vs. ? they are both in ?AV. If I remember correctly I was
asked earlier to change from one to the
other and did so. Both are listed in Aved.def (called EPSILON_UBAR and
EPSILON_UNDERBAR). One of them
(probably EPSILON_UNDERBAR) may disappear if the space is needed for
new functions (I hope not, though).

GNU APL accepts both and they refer to the same function. So you can
put the one you prefer into your keyboard
mapping. Defined function keep the one used. Debug output of APL token
uses EPSILON_UBAR.

I have changed how ]KEYB works as of SVN 437. You can now specify a
keyboard layout text file in the preferences file(s).
If you do that then that file is printed instead of the default
keyboard layout. The old method of providing a method number
has been removed. The default layout shown by ]KEYB is also installed
in .../etc/gnu-apl.d/keyboard1.txt and can be used
as a starting point for your own file.

Chris, you may want to have a look at function
*Avec::map_alternative_char()**. *It has a list of additional Unicode
chars that
are used by other APL interpreters and also understood by GNU APL (and
mapped to chars in ?AV).

/// Jürgen


On 08/16/2014 09:26 PM, Chris Moller wrote:

For a few days, David Lamkins and I have been kicking around a
problem in the ]keyb output.  Turns out the least tractable of these
seems to be the result of two different utf8 sequences used for the
epsilon-underbar character:

]keybuses utf8 e2 8b b8, unicode 22f8, "ELEMENT OF WITH UNDERBAR"

]keyb 1 uses utf8 e2 8d b7, unicode 2377, "APL FUNCTIONAL SYMBOL
EPSILON UNDERBAR"

The first of these, U+22f8, doesn't exist in either the FreeMono or
SimPL fonts; I'm guessing that GTK's text engine, pango, is just
grabbing the closest glyph it can find from some other font, which
turns out to be of a different width.  U+22f8 isn't in Avec.def.

U+2377 exists in both fonts and corresponds to EPSILON_UNDERBAR in
Avec.def.

I'm more or less guessing that the data for ]keyb comes from either
keyboard.dyalog.txt or keyboard1.dyalog.txt, both of which contain
the broken U+22f8 character while ]keyb 1 comes from either
keyboard.txt or keyboard1.txt, both of which contain the working
U+2377.  No idea, of course, if these differences are deliberate.

Anyway, the latest push of aplwrap is stable with respect everything
except dealing with these differences in ]keyb output.

Chris Moller

Re: [Bug-apl] Patch: cout buffer control

[Chris Moller]

This may be a result of buffer sizes.  I don't know enough about C++ to
know how to do it, but maybe if you reduce the buffer size, it will
reduce the latency.


On 08/22/14 11:08, David Lamkins wrote:

I agree: cout << endl should flush the buffer. It does when stdout is
a tty. For some reason, the buffering becomes much more aggressive
when the stdout is a pipe.


On Fri, Aug 22, 2014 at 6:14 AM, Juergen Sauermann
mailto:juergen.sauerm...@t-online.de>>
wrote:

Hi David,

thanks, included in SVN 443.

This is interesting because I normally use something like *out <<
endl *which should have flushed the buffer.
On the other hand *⍞***is somewhat special because it prints a
prompt but no *endl* so that the user enters her input
on the same line.

I have added a few *cout << flush* for*⎕/⍞ *so maybe the patch
isn't needed anymore (I guess unbuffered output
is slightly slower than buffered output).

/// Jürgen


On 08/22/2014 05:11 AM, David Lamkins wrote:

Oops. Here's the same patch, but inquiring about the correct file
descriptor.

(It'll work either way in some cases...)


On Thu, Aug 21, 2014 at 8:06 PM, David Lamkins mailto:da...@lamkins.net>> wrote:

I've been puzzled by the interaction between GNU APL and
aplwrap, in which ⎕ and ⍞ output doesn't appear until APL
prompts for input. This behavior is bad for the case where
the program tries to emit periodic progress messages during
long computations.

It turns out that the C++ std lib is responsible for this
behavior. While cerr is unbuffered, cout holds onto buffered
content for as long as possible. (Apparently it only does
this when stdout is not a terminal, as running the same test
in a shell window does not exhibit the aggressive buffering
behavior.)

I learned that cout's buffering behavior can be be changed
using the call:

std::cout.setf(std::ios::unitbuf);

This can be called sometime before running the main APL loop,
and will cause cout's buffer to be flushed at each <<, the
same as cerr.

The attached patch (GNU APL SVN 441) runs the 'unitbuf' code
only in the case that stdin is not a tty.



--
"The secret to creativity is knowing how to hide your sources."
   Albert Einstein


http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/




--
"The secret to creativity is knowing how to hide your sources."
   Albert Einstein


http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/





--
"The secret to creativity is knowing how to hide your sources."
   Albert Einstein


http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/

Re: [Bug-apl] GNU APL GTK wrapper

[Chris Moller]

Hi, Elias,

I have indeed started adding a few APL-interaction features to aplwrap,
one of the first of which uses your "variables" command, which leads me
to a request: a variation in VariablesCommand.cc of "cls = ALL"  that
tags the entries in the returned list with their name classes.  That
makes it possible for me to get all the non-system functions and
variables in one transaction and still differentiate between functions
and variables.  I've attached a proposed patch.

Thanks,
Chris

On 08/13/14 23:28, Elias Mårtenson wrote:

Hello Chris,

I've been following the discussions about the GTK wrapper, and while
I'm not using it myself (since I work on the Emacs integration) I
realise that there are plenty of (potential) overlaps between our
projects.

In particular, I want to let you know about the Emacs mode backchannel
protocol that the mode uses for directly communicating with the GNU
APL interpreter. When started, if gives you a simple text-based
protocol through which you can do things such as defining functions or
creating listeners that send you a message whenever a variable is
changed (this is used by the realtime variable watcher).

It would be neat if you were to consider implementing some of the
feature I added to the Emacs mode, and if you do it would be useful if
you used the same protocol as I am using.

Please let me know if you have any questions.

Regards,
Elias


Index: VariablesCommand.cc
===
--- VariablesCommand.cc	(revision 449)
+++ VariablesCommand.cc	(working copy)
@@ -33,6 +33,7 @@
 void VariablesCommand::run_command( NetworkConnection &conn, const std::vector &args )
 {
 stringstream out;
+bool tagged = false;
 
 TypeSpec cls = ALL;
 if( args.size() >= 2 ) {
@@ -43,6 +44,10 @@
 else if( typespec == "function" ) {
 cls = FUNCTION;
 }
+else if( typespec == "tagged" ) {
+cls = ALL;
+tagged = true;
+}
 else {
 CERR << "Illegal variable type: " << typespec << endl;
 throw DisconnectedError( "Illegal variable type" );
@@ -59,7 +64,8 @@
 if( (cls == ALL && (symbol_nc == NC_VARIABLE || symbol_nc == NC_FUNCTION || symbol_nc == NC_OPERATOR))
 || (cls == VARIABLE && symbol_nc == NC_VARIABLE)
 || (cls == FUNCTION && (symbol_nc == NC_FUNCTION || symbol_nc == NC_OPERATOR)) ) {
-out << symbol->get_name() << "\n";
+if (tagged) out << symbol_nc << symbol->get_name() << "\n";
+elseout << symbol->get_name() << "\n";
 }
 }
 }

Re: [Bug-apl] GNU APL GTK wrapper

[Chris Moller]

Thanks.  I had it the other way around with no space because that was
dead simple to parse with strtoul() returning the nc and endptr left
pointing at the name, but your way is still easy enough to parse.

Chris

On 08/28/14 11:49, Elias Mårtenson wrote:

Thank you. I've added it, but with a small change. The format is now
NAME (space) NC

Regards,
Elias


On 28 August 2014 22:57, Chris Moller mailto:mol...@mollerware.com>> wrote:

Hi, Elias,

I have indeed started adding a few APL-interaction features to
aplwrap, one of the first of which uses your "variables" command,
which leads me to a request: a variation in VariablesCommand.cc of
"cls = ALL"  that tags the entries in the returned list with their
name classes. That makes it possible for me to get all the
non-system functions and variables in one transaction and still
differentiate between functions and variables.  I've attached a
proposed patch.

Thanks,
Chris


On 08/13/14 23:28, Elias Mårtenson wrote:

Hello Chris,

I've been following the discussions about the GTK wrapper, and
while I'm not using it myself (since I work on the Emacs
integration) I realise that there are plenty of (potential)
overlaps between our projects.

In particular, I want to let you know about the Emacs mode
backchannel protocol that the mode uses for directly
communicating with the GNU APL interpreter. When started, if
gives you a simple text-based protocol through which you can do
things such as defining functions or creating listeners that send
you a message whenever a variable is changed (this is used by the
realtime variable watcher).

It would be neat if you were to consider implementing some of the
feature I added to the Emacs mode, and if you do it would be
useful if you used the same protocol as I am using.

Please let me know if you have any questions.

Regards,
Elias

[Bug-apl] aplwrap 2.0

[Chris Moller]

I just pushed aplwrap 2.0, which incorporates a lot of work by David 
Lamkins and adds an editor.


Summary of changes since v 1.0:

 *

   Correct display of APL output.

 *

 --LX command-line argument to pass expression or command to APL.

 *

 --rows-var command-line argument lets APL know about window height.

 *

 Acceptance of additional command-line arguments following '--'.

 *

 Transcript is locked against editing; inputs and prompts are colored.

 *

 Tab-completion (see COMPLETION.md).

 *

 Copy selected text down to input area (see KEY_BINDINGS.md).

 *

 Command history (see KEY_BINDINGS.md).

 *

 Set TERM=dumb in APL's environment.

 *

 Set APLWRAP= in APL's environment.

 * Early-version full-window editor added:
 o File>>New does what you expect.
 o File>>Open lists and lets you select a user-defined function to
   edit.
 o Any number of functions can be opened simultaneously for
   editing, leaving APL running concurrently in the main screen.
 o The same function can be open with multiple views in multiple
   windows (like Emacs split-window).
 o Functions can be saved back into the APL workspace or exported
   as files.
 o Future enhancements will probably include the ability to import
   files as functions and edit the values of variables, possibly
   including editing array values in a spreadsheet format.

All of this works as of SVN 459.

Re: [Bug-apl] aplwrap 2.0

[Chris Moller]

Yes, I'm using your socket interface, but I'm not using all the
commands.  Right now, I'm just using "variables" to extract the list of
functions (and, eventually, both fcns and vars), "fn" to extract the
functions (and, eventually, "getvar") and "def."

Chris

On 09/07/14 10:59, Elias Mårtenson wrote:

Cool! Are you using the Emacs mode protocol?

If so, are you using all the commands? I just want to know in case I
would like to make changes. :-)

Regards,
Elias

On 7 September 2014 22:46, Chris Moller mailto:mol...@mollerware.com>> wrote:

I just pushed aplwrap 2.0, which incorporates a lot of work by
David Lamkins and adds an editor.

Summary of changes since v 1.0:

 *

Correct display of APL output.

 *

  --LX command-line argument to pass expression or command to APL.

 *

  --rows-var command-line argument lets APL know about window height.

 *

  Acceptance of additional command-line arguments following '--'.

 *

  Transcript is locked against editing; inputs and prompts are colored.

 *

  Tab-completion (see COMPLETION.md).

 *

  Copy selected text down to input area (see KEY_BINDINGS.md).

 *

  Command history (see KEY_BINDINGS.md).

 *

  Set TERM=dumb in APL's environment.

 *

  Set APLWRAP= in APL's environment.

  * Early-version full-window editor added:
  o File>>New does what you expect.
  o File>>Open lists and lets you select a user-defined
function to edit.
  o Any number of functions can be opened simultaneously for
editing, leaving APL running concurrently in the main screen.
  o The same function can be open with multiple views in
multiple windows (like Emacs split-window).
  o Functions can be saved back into the APL workspace or
exported as files.
  o Future enhancements will probably include the ability to
import files as functions and edit the values of
variables, possibly including editing array values in a
spreadsheet format.

All of this works as of SVN 459.

[Bug-apl] While I'm at it...

[Chris Moller]

...a bit more spam.  If anyone's interested, I've got another 
APL-related work-in-progress: aplplot.  It provides a way of plotting 
APL vectors and arrays.  At the moment it handles:


 * multiple-curve linear and log XY plots,
 * polar plots,
 * complex-vector plots in 3-space
 * various kinds of labelling
 * the ability to either display the plots or save them in a variety of
   image formats

(You can see examples at https://github.com/ChrisMoller/aplplot/wiki)

It's a "work-in-progress" because there are endless ways to render data 
visually and I'm trying to cover a handful of common specific cases 
before taking a stab at more general, and thus more difficult to use, 
general cases.


Future enhancements will likely include (spline-based?) curve smoothing, 
a means of inserting plots into the aplwrap transcript, and whatever 
else looks like fun.


Anyway, it's at https://github.com/ChrisMoller/aplplot if anyone wants 
to tinker with it.

Re: [Bug-apl] aplwrap: bell & ANSI controls

[Chris Moller]

There was some discussion about setting the TERM environment variable,
which David Lamkins did for aplwrap, setting it to "dumb"--i.e., aplwrap
doesn't understand terminal controls.  Nothing says it can't be made to
do so, but I've no idea at the moment the scope of work involved.

FWIW, though, I just pushed a patch that at least filters output from
APL so it replaces unprintable characters (⎕av[⎕io+⍳32]) with
spaces--⎕av used to be pretty ugly.  It also catches the ASCII BEL
character (⎕AV[⎕IO+7]) and tries to emit a beep through the right GDK
function, but that doesn't work in my hardware.  YMMV.

cm

On 09/08/14 10:12, Blake McBride wrote:

This was fixed before but doesn't work anymore.  I use it a lot, and
having it work just like GNU APL without APLWRAP is very useful to me.

Thanks.

Blake



On Mon, Aug 18, 2014 at 10:23 AM, Blake McBride mailto:blake1...@gmail.com>> wrote:

Greetings,

Some of my error handling code uses the bell (⎕AV[⎕IO+7]), and my
editor uses some ANSI positioning sequences. I think all I use is
clear and go to top of screen as follows:

∇
[0]   E∆Clear
[1]   ⍞←(⎕UCS 27),'[2J'
[2]   ⍞←(⎕UCS 27),'[1;1H'
∇

Anyway to get that working?

Thanks.

Blake

Re: [Bug-apl] Error building latest aplwrap

[Chris Moller]

Cool of your compiler to catch that.  Fixed and the fix pushed.

cm


On 09/10/14 21:21, Blake McBride wrote:

Compiled on a 64 bit Linux box.

...
gcc -DHAVE_CONFIG_H -I. -I..-std=c99 -Wall -Werror -pthread
-I/usr/include/gtk-3.0 -I/usr/include/atk-1.0
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz
-I/usr/include/freetype2 -I/usr/include/pixman-1
-I/usr/include/libpng12 -I/home/blake/Backup/apl/src  -g -O2 -MT
aplwrap-pstat.o -MD -MP -MF .deps/aplwrap-pstat.Tpo -c -o
aplwrap-pstat.o `test -f 'pstat.c' || echo './'`pstat.c
In file included from /usr/include/string.h:638:0,
 from pstat.c:3:
In function ‘memset’,
inlined from ‘get_pstat’ at pstat.c:62:9:
/usr/include/x86_64-linux-gnu/bits/string3.h:81:30: error: call to
‘__warn_memset_zero_len’ declared with attribute warning: memset used
with constant zero length parameter; this could be due to transposed
parameters [-Werror]
   __warn_memset_zero_len ();
  ^
cc1: all warnings being treated as errors
make[2]: *** [aplwrap-pstat.o] Error 1
make[2]: Leaving directory `/home/blake/Backup/aplwrap.git/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/blake/Backup/aplwrap.git'
make: *** [all] Error 2

[Bug-apl] aplwrap 2.1

[Chris Moller]

 * Added a status line to aplwrap (by David Lamkins).
 * Added capabilities to aplwrap and aplplot to allow plots to be
   embedded in the aplwrap transcript.

Re: [Bug-apl] aplwrap assertion failures

[Chris Moller]

What version of GTK are you using?  I'm running 3.10.9 though in 
configure.ac I'm only checking for versions >= 3.0.12.  There may be 
some incompatibility.



On 09/12/14 08:39, Blake McBride wrote:

Greetings,

I was in the middle of editing a function using the regular 
del-editor, I copied and pasted a line, I then exited aplwrap by 
clicking on the x in the upper left hand corner of the screen without 
closing the function I was editing.  Aplwrap gave me:


(aplwrap:29325): Gtk-CRITICAL **: gtk_main_quit: assertion 'main_loops 
!= NULL' failed


(aplwrap:29325): GLib-GObject-WARNING **: invalid unclassed pointer in 
cast to 'GtkTextView'


(aplwrap:29325): Gtk-CRITICAL **: gtk_text_view_scroll_to_mark: 
assertion 'GTK_IS_TEXT_VIEW (text_view)' failed
*** Error in `aplwrap': malloc(): smallbin double linked list 
corrupted: 0x01f88cc0 ***



Thanks.

Blake

Re: [Bug-apl] aplwrap assertion failures

[Chris Moller]

Can you try putting in a newer version?  3.8.7 is from November of last 
year.  They've done a  lot of bug-fixing since then and it would be good 
to know if the bug is on my end or in GTK.




On 09/12/14 09:40, Blake McBride wrote:

Looks like I am running 3.8.7

On Fri, Sep 12, 2014 at 8:25 AM, Chris Moller <mailto:mol...@mollerware.com>> wrote:


What version of GTK are you using?  I'm running 3.10.9 though in
configure.ac <http://configure.ac> I'm only checking for versions
>= 3.0.12.  There may be some incompatibility.



On 09/12/14 08:39, Blake McBride wrote:

Greetings,

I was in the middle of editing a function using the regular
del-editor, I copied and pasted a line, I then exited aplwrap by
clicking on the x in the upper left hand corner of the screen
without closing the function I was editing.  Aplwrap gave me:

(aplwrap:29325): Gtk-CRITICAL **: gtk_main_quit: assertion
'main_loops != NULL' failed

(aplwrap:29325): GLib-GObject-WARNING **: invalid unclassed
pointer in cast to 'GtkTextView'

(aplwrap:29325): Gtk-CRITICAL **: gtk_text_view_scroll_to_mark:
assertion 'GTK_IS_TEXT_VIEW (text_view)' failed
*** Error in `aplwrap': malloc(): smallbin double linked list
corrupted: 0x01f88cc0 ***


Thanks.

Blake

Re: [Bug-apl] aplwrap assertion failures

[Chris Moller]

No, I don't get get a failure, but as you pointed out in an earlier
post, the copied 'abc' is uneditable--and I just saw that David has
fixed that.  I'll have that patch up in a couple of minutes.

Chris

On 09/12/14 11:47, Blake McBride wrote:

Here are the steps that reproduce the problem:

1.  Execute aplwrap

2.  Type the following:

  ∇test
[1] abc
[2]

3.  Highlight and COPY (^C) the 'abc'

4.  Click on the end of the [2] line

5.  PASTE (^V) the 'abc' (has no quotes)

6.  Hit the backspace key 3 times

7.  Hit the X in the upper corner to force aplwrap to exit.  This
causes the error.

Does this give you errors too?

Thanks.

Blake


On Fri, Sep 12, 2014 at 9:05 AM, Chris Moller mailto:mol...@mollerware.com>> wrote:


On 09/12/14 09:58, Blake McBride wrote:

I am using vanilla LinuxMint 16.  GTK comes with it.  Upgrading
to test is sort of a big job that messes up auto-update.  Let me
see if I can get an exact sequence to duplicate the problem
instead.  Is that okay?


Sure.  And I might have a spare machine I can install 3.8.7 on
just to see what happens.



    On Fri, Sep 12, 2014 at 8:49 AM, Chris Moller
mailto:mol...@mollerware.com>> wrote:

Can you try putting in a newer version?  3.8.7 is from
November of last year.  They've done a lot of bug-fixing
since then and it would be good to know if the bug is on my
end or in GTK.




On 09/12/14 09:40, Blake McBride wrote:

Looks like I am running 3.8.7

On Fri, Sep 12, 2014 at 8:25 AM, Chris Moller
mailto:mol...@mollerware.com>> wrote:

What version of GTK are you using?  I'm running 3.10.9
though in configure.ac <http://configure.ac> I'm only
checking for versions >= 3.0.12. There may be some
incompatibility.



On 09/12/14 08:39, Blake McBride wrote:

Greetings,

I was in the middle of editing a function using the
regular del-editor, I copied and pasted a line, I then
exited aplwrap by clicking on the x in the upper left
hand corner of the screen without closing the function
I was editing.  Aplwrap gave me:

(aplwrap:29325): Gtk-CRITICAL **: gtk_main_quit:
assertion 'main_loops != NULL' failed

(aplwrap:29325): GLib-GObject-WARNING **: invalid
unclassed pointer in cast to 'GtkTextView'

(aplwrap:29325): Gtk-CRITICAL **:
gtk_text_view_scroll_to_mark: assertion
'GTK_IS_TEXT_VIEW (text_view)' failed
*** Error in `aplwrap': malloc(): smallbin double
linked list corrupted: 0x01f88cc0 ***


Thanks.

Blake

Re: [Bug-apl] aplwrap needs to be able to edit paste lines

[Chris Moller]

I just applied that patch and pushed it to github.  Blake, can you try 
it and see if you still get errors?


Thx


On 09/12/14 12:20, David B. Lamkins wrote:

I sent Chris a patch for this issue.

On Fri, 2014-09-12 at 07:51 -0700, David B. Lamkins wrote:

I noticed that last night.

The GTK+ framework preserves text attributes during copy and paste.
Since the transcript text is not editable, neither is a pasted copy of
some selection of that text.

I'll see whether I can figure out how to override that behavior.

Meanwhile, you can use aplwrap's "copy-down" feature. Select some text
in the transcript and press Enter; the selection will be copied down to
the input area; this copy is editable.

On Fri, 2014-09-12 at 07:32 -0500, Blake McBride wrote:

Greetings,


If I type a line, before I hit enter I can backspace or arrow around
the line to edit it.  This is very convenient when you type in a long
line and realize you made a typo somewhere in the middle.  You are
able to correct the problem without retyping the rest of the line.


Unfortunately, sometime you want to copy from somewhere else, paste
the line where you are, and then make a small edit to it.  Aplwrap
will allow you to edit a line you type but not a line you paste.
  Treating the paste like a typed in line is very beneficial.


Thanks.


Blake

Re: [Bug-apl] aplwrap needs to be able to edit paste lines

[Chris Moller]

It all works fine here:

Fedora release 20 (Heisenbug)

kernel 3.14.5-200.fc20.x86_64 #1 SMP GNU/Linux

gtk3-3.10.9-1.fc20.x86_64


On 09/12/14 12:43, Blake McBride wrote:

Dear David,

I am using the latest git on aplwrap but the backspace on paste still 
doesn't work for me.


Glad to hear someone else is getting the crash error.

Thanks.

Blake

On Fri, Sep 12, 2014 at 11:38 AM, David B. Lamkins <mailto:dlamk...@gmail.com>> wrote:


To be clear: this patch is for the copy/paste behavior.

There's still the crash on exit; I'll write about that in the other
thread.

On Fri, 2014-09-12 at 12:27 -0400, Chris Moller wrote:
> I just applied that patch and pushed it to github.  Blake, can
you try
> it and see if you still get errors?
>
> Thx
>
>
> On 09/12/14 12:20, David B. Lamkins wrote:
>
> > I sent Chris a patch for this issue.
> >
> > On Fri, 2014-09-12 at 07:51 -0700, David B. Lamkins wrote:
> > > I noticed that last night.
> > >
> > > The GTK+ framework preserves text attributes during copy and
paste.
> > > Since the transcript text is not editable, neither is a
pasted copy of
> > > some selection of that text.
> > >
> > > I'll see whether I can figure out how to override that behavior.
> > >
> > > Meanwhile, you can use aplwrap's "copy-down" feature. Select
some text
> > > in the transcript and press Enter; the selection will be
copied down to
> > > the input area; this copy is editable.
> > >
> > > On Fri, 2014-09-12 at 07:32 -0500, Blake McBride wrote:
> > > > Greetings,
> > > >
> > > >
> > > > If I type a line, before I hit enter I can backspace or
arrow around
> > > > the line to edit it.  This is very convenient when you
type in a long
> > > > line and realize you made a typo somewhere in the middle. 
You are

> > > > able to correct the problem without retyping the rest of
the line.
> > > >
> > > >
> > > > Unfortunately, sometime you want to copy from somewhere
else, paste
> > > > the line where you are, and then make a small edit to it. 
Aplwrap

> > > > will allow you to edit a line you type but not a line you
paste.
> > > >  Treating the paste like a typed in line is very beneficial.
> > > >
> > > >
> > > > Thanks.
> > > >
> > > >
> > > > Blake
> > > >
> > > >
> >
> >
> >
>

Re: [Bug-apl] aplwrap assertion failures

[Chris Moller]

Can you run it under valgrind?  That should find memory problems.


On 09/12/14 12:51, David B. Lamkins wrote:

FWIW: commenting out the gtk_text_view_scroll_to_mark() call in
scroll_to_cursor() does not affect the crash that I'm seeing (which is
different in its details from the crash that Blake reported). I still
get a memory corruption report, though...

On Fri, 2014-09-12 at 09:46 -0700, David B. Lamkins wrote:

I reached similar conclusions. It seems that copy/paste tickles this
bug.

Copy, then paste, then evaluate, then click the close box: this is
enough to give me GTK+ errors and even stack dumps.

These are probably the important clues:

GLib-GObject-WARNING **: invalid unclassed pointer in cast to
'GtkTextView'
(aplwrap:29325): Gtk-CRITICAL **: gtk_text_view_scroll_to_mark:
assertion 'GTK_IS_TEXT_VIEW (text_view)' failed

gtk_text_view_scroll_to_mark() appears (in aplwrap code) only in
scroll_to_cursor(). Is the cast in that function incorrect?

On Fri, 2014-09-12 at 10:47 -0500, Blake McBride wrote:

Here are the steps that reproduce the problem:


1.  Execute aplwrap


2.  Type the following:


   ∇test
[1] abc
[2]


3.  Highlight and COPY (^C) the 'abc'


4.  Click on the end of the [2] line


5.  PASTE (^V) the 'abc' (has no quotes)


6.  Hit the backspace key 3 times


7.  Hit the X in the upper corner to force aplwrap to exit.  This
causes the error.


Does this give you errors too?


Thanks.


Blake



On Fri, Sep 12, 2014 at 9:05 AM, Chris Moller 
wrote:

 On 09/12/14 09:58, Blake McBride wrote:

 > I am using vanilla LinuxMint 16.  GTK comes with it.
 >  Upgrading to test is sort of a big job that messes up
 > auto-update.  Let me see if I can get an exact sequence to
 > duplicate the problem instead.  Is that okay?

 Sure.  And I might have a spare machine I can install 3.8.7 on
 just to see what happens.

     >
 > On Fri, Sep 12, 2014 at 8:49 AM, Chris Moller
 >  wrote:
 > Can you try putting in a newer version?  3.8.7 is
 > from November of last year.  They've done a  lot of
 > bug-fixing since then and it would be good to know
 > if the bug is on my end or in GTK.
 >
 >
 >
 >
 > On 09/12/14 09:40, Blake McBride wrote:
 >
 > > Looks like I am running 3.8.7
 > >
 > > On Fri, Sep 12, 2014 at 8:25 AM, Chris Moller
 > >  wrote:
 > > What version of GTK are you using?  I'm
 > > running 3.10.9 though in configure.ac I'm
 > > only checking for versions >= 3.0.12.
 > > There may be some incompatibility.
 > >
 > >
 > >
 > > On 09/12/14 08:39, Blake McBride wrote:
 > >
 > > > Greetings,
 > > >
 > > >
 > > > I was in the middle of editing a
 > > > function using the regular del-editor, I
 > > > copied and pasted a line, I then exited
 > > > aplwrap by clicking on the x in the
 > > > upper left hand corner of the screen
 > > > without closing the function I was
 > > > editing.  Aplwrap gave me:
 > > >
 > > >
 > > > (aplwrap:29325): Gtk-CRITICAL **:
 > > > gtk_main_quit: assertion 'main_loops !=
 > > > NULL' failed
 > > >
 > > >
 > > > (aplwrap:29325): GLib-GObject-WARNING
 > > > **: invalid unclassed pointer in cast to
 > > > 'GtkTextView'
 > > >
 > > >
 > > > (aplwrap:29325): Gtk-CRITICAL **:
 > > > gtk_text_view_scroll_to_mark: assertion
 > > > 'GTK_IS_TEXT_VIEW (text_view)' failed
 > > > *** Error in `aplwrap': malloc():
 > > > smallbin double linked list corrupted:
 > > > 0x01f88cc0 ***
 > > >
 > > >
 > > >
 > > >
 > > > Thanks.
 > > >
 > > >
 > > > Blake
 > > >
 > > >
 > >
 > >
 > >
 > >
 >
 >
 >
 >

Re: [Bug-apl] aplwrap assertion failures

[Chris Moller]

I just applied and pushed David's patch, the question remaining why it
showed up only in some environments and not others.

On 09/12/14 15:04, David B. Lamkins wrote:

I believe I've found the cause of this problem.

There's something special (I don't know what) about the exit behavior of
GTK+ in the case that there's something on the application's clipboard.
With nothing on the clipboard, application exit was fine. With something
on the clipboard, aplwrap's apl_exit() was called twice (?) which caused
a double-free of plot_pipe_name; that was almost certainly responsible
for the heap corruption I saw.

Also, it looked as if the GtkTextBuffer and associated objects got torn
down while APL was still alive; this was responsible for a lot of GTK+
assertion failures in my tests.

Both of these issues are fixed. I'll send Chris the patch.


On Fri, 2014-09-12 at 12:55 -0400, Chris Moller wrote:

Can you run it under valgrind?  That should find memory problems.


On 09/12/14 12:51, David B. Lamkins wrote:


FWIW: commenting out the gtk_text_view_scroll_to_mark() call in
scroll_to_cursor() does not affect the crash that I'm seeing (which is
different in its details from the crash that Blake reported). I still
get a memory corruption report, though...

On Fri, 2014-09-12 at 09:46 -0700, David B. Lamkins wrote:

I reached similar conclusions. It seems that copy/paste tickles this
bug.

Copy, then paste, then evaluate, then click the close box: this is
enough to give me GTK+ errors and even stack dumps.

These are probably the important clues:

GLib-GObject-WARNING **: invalid unclassed pointer in cast to
'GtkTextView'
(aplwrap:29325): Gtk-CRITICAL **: gtk_text_view_scroll_to_mark:
assertion 'GTK_IS_TEXT_VIEW (text_view)' failed

gtk_text_view_scroll_to_mark() appears (in aplwrap code) only in
scroll_to_cursor(). Is the cast in that function incorrect?

On Fri, 2014-09-12 at 10:47 -0500, Blake McBride wrote:

Here are the steps that reproduce the problem:


1.  Execute aplwrap


2.  Type the following:


   ∇test
[1] abc
[2]


3.  Highlight and COPY (^C) the 'abc'


4.  Click on the end of the [2] line


5.  PASTE (^V) the 'abc' (has no quotes)


6.  Hit the backspace key 3 times


7.  Hit the X in the upper corner to force aplwrap to exit.  This
causes the error.


Does this give you errors too?


Thanks.


Blake



On Fri, Sep 12, 2014 at 9:05 AM, Chris Moller 
wrote:

 On 09/12/14 09:58, Blake McBride wrote:

 > I am using vanilla LinuxMint 16.  GTK comes with it.
 >  Upgrading to test is sort of a big job that messes up
 > auto-update.  Let me see if I can get an exact sequence to
 > duplicate the problem instead.  Is that okay?

 Sure.  And I might have a spare machine I can install 3.8.7 on
     just to see what happens.

 >
 > On Fri, Sep 12, 2014 at 8:49 AM, Chris Moller
 >  wrote:
 > Can you try putting in a newer version?  3.8.7 is
 > from November of last year.  They've done a  lot of
 > bug-fixing since then and it would be good to know
 > if the bug is on my end or in GTK.
 >
 >
 >
 >
 > On 09/12/14 09:40, Blake McBride wrote:
 >
 > > Looks like I am running 3.8.7
 > >
 > > On Fri, Sep 12, 2014 at 8:25 AM, Chris Moller
 > >  wrote:
 > > What version of GTK are you using?  I'm
 > > running 3.10.9 though in configure.ac I'm
 > > only checking for versions >= 3.0.12.
 > > There may be some incompatibility.
 > >
 > >
 > >
 > > On 09/12/14 08:39, Blake McBride wrote:
 > >
 > > > Greetings,
 > > >
 > > >
 > > > I was in the middle of editing a
 > > > function using the regular del-editor, I
 > > > copied and pasted a line, I then exited
 > > > aplwrap by clicking on the x in the
 > > > upper left hand corner of the screen
 > > > without closing the function I was
 > > > editing.  Aplwrap gave me:
 > > >
 > > >
 > > > (aplwrap:29325): Gtk-CRITICAL **:
 >

Re: [Bug-apl] aplwrap - editing functions with errors

[Chris Moller]

Actually, saving shouldn't close the window in any event.  I'll poke at
it.  Right now, I'm looking at the open-function problem.


On 09/12/14 18:46, Blake McBride wrote:

Greetings,

Let's say you create a large APL function using File / New.  If just
one line has an open quote that isn't closed, you lose all of your
work.  I think aplwrap should test the result of ⎕FX before it exits.
 If ⎕FX fails, display the line number with the error and remain in
the editor so all of your work isn't lost.

Thanks.

Blake

Re: [Bug-apl] aplwrap - File / Open auto-select issue

[Chris Moller]

I just pushed a patch I think might fix this.  Let me know how it goes..

cm


On 09/12/14 17:24, Blake McBride wrote:
When you bring up File / Open, aplwrap displays a list of functions. 
 The first one appears auto-selected, but if you click OK you find it 
wasn't.  If you click on it first and then click okay, it works.  The 
point is it appears selected but it isn't.  When you do actually 
select it, there is no visual change that indicates it.  It shouldn't 
appear auto-selected.


Thanks.

Blake

Re: [Bug-apl] aplwrap - bottom display

[Chris Moller]

It's easy enough to put the same thing in an info dialogue under Help.
I'll stuff that in tonight or tomorrow but keep the status line switchable.


On 09/12/14 20:30, David B. Lamkins wrote:

I find the APL process stats to be useful in gauging performance issues
related to time, I/O and memory (see APL_STATUS_LINE.md for a key to the
fields).

I can see your point, though: the status line does look "busy" and it
eats up a line or two of vertical space.

Putting this display in its own window is outside of my wheelhouse.

In keeping with the "principle of least surprise", I'm sending Chris a
patch to disable the APL process stats by default. They'll be enabled
using the --apl-stats command-line option.


On Fri, 2014-09-12 at 16:29 -0500, Blake McBride wrote:

The bottom of my aplwrap screen displays:


#0 ∆e: 1.18 ∆u: 0.00 ∆s: 0.00 ∆v: 52,043,776 ∆r: 3,239,936 ∆f: 983 ∆F:
0 ∆b: 0.00 ∆rc: 37,908 ∆wc: 134 ∆rb: 0 ∆wb: 0 ∆ic: 29 ∆oc: 12 ∆cw: 0





This is getting kind of crazy.  My suggestion is this - get rid of
that display entirely.  Add a Help / Info menu option that brings up a
window with a verbose version of that information.


Thanks.


Blake

Re: [Bug-apl] aplwrap - bottom display

[Chris Moller]

File>>Settings now has a toggle to turn the status line on and off.
I'll add the info pop-up tomorrow and, if I'm feeling enthusiastic, I'll
stick in a ~/.aplwrap to retain the states.


On 09/12/14 21:09, David Lamkins wrote:


Thanks, Chris. Much appreciated.

On Sep 12, 2014 6:07 PM, "Chris Moller" mailto:mol...@mollerware.com>> wrote:

It's easy enough to put the same thing in an info dialogue under
Help.  I'll stuff that in tonight or tomorrow but keep the status
line switchable.


On 09/12/14 20:30, David B. Lamkins wrote:

I find the APL process stats to be useful in gauging performance issues
related to time, I/O and memory (see APL_STATUS_LINE.md for a key to the
fields).

I can see your point, though: the status line does look "busy" and it
eats up a line or two of vertical space.

Putting this display in its own window is outside of my wheelhouse.

In keeping with the "principle of least surprise", I'm sending Chris a
patch to disable the APL process stats by default. They'll be enabled
using the --apl-stats command-line option.


On Fri, 2014-09-12 at 16:29 -0500, Blake McBride wrote:

The bottom of my aplwrap screen displays:


#0 ∆e: 1.18 ∆u: 0.00 ∆s: 0.00 ∆v: 52,043,776 ∆r: 3,239,936 ∆f: 983 ∆F:
0 ∆b: 0.00 ∆rc: 37,908 ∆wc: 134 ∆rb: 0 ∆wb: 0 ∆ic: 29 ∆oc: 12 ∆cw: 0





This is getting kind of crazy.  My suggestion is this - get rid of
that display entirely.  Add a Help / Info menu option that brings up a
window with a verbose version of that information.


Thanks.


Blake

Re: [Bug-apl] aplwrap - bottom display

[Chris Moller]

Sorry--I spent most of last week putting out fires in Toronto.  I'll try
to get caught up on aplwrap stuff over the next couple of days.

cm


On 09/21/14 16:32, Blake McBride wrote:

Greetings,

I like the ability to not see the pstsat line.  However I fond the
following problem.

Click File / Settings / Open pstat window.

The pstat window displays.  The "Close" button on the pstat window
does not work until you click "OK" on the "Settings" popup.

Thanks.

Blake


On Fri, Sep 12, 2014 at 9:53 PM, David B. Lamkins mailto:dlamk...@gmail.com>> wrote:

I like it. From an implementation viewpoint, that seems cleaner than
what I was trying to do with the command-line option.

Thanks. :)

    On Fri, 2014-09-12 at 22:44 -0400, Chris Moller wrote:
> File>>Settings now has a toggle to turn the status line on and off.
> I'll add the info pop-up tomorrow and, if I'm feeling enthusiastic,
> I'll stick in a ~/.aplwrap to retain the states.
>
>
> On 09/12/14 21:09, David Lamkins wrote:
>
> > Thanks, Chris. Much appreciated.
> >
> > On Sep 12, 2014 6:07 PM, "Chris Moller" mailto:mol...@mollerware.com>>
> > wrote:
> > It's easy enough to put the same thing in an info dialogue
> > under Help.  I'll stuff that in tonight or tomorrow
but keep
> > the status line switchable.
> >
> >
> > On 09/12/14 20:30, David B. Lamkins wrote:
> >
> > > I find the APL process stats to be useful in gauging
performance issues
> > > related to time, I/O and memory (see
APL_STATUS_LINE.md for a key to the
> > > fields).
> > >
> > > I can see your point, though: the status line does
look "busy" and it
> > > eats up a line or two of vertical space.
> > >
> > > Putting this display in its own window is outside of
my wheelhouse.
> > >
> > > In keeping with the "principle of least surprise",
I'm sending Chris a
> > > patch to disable the APL process stats by default.
They'll be enabled
> > > using the --apl-stats command-line option.
> > >
> > >
> > > On Fri, 2014-09-12 at 16:29 -0500, Blake McBride wrote:
> > > > The bottom of my aplwrap screen displays:
> > > >
> > > >
> > > > #0 ∆e: 1.18 ∆u: 0.00 ∆s: 0.00 ∆v: 52,043,776 ∆r:
3,239,936 ∆f: 983 ∆F:
> > > > 0 ∆b: 0.00 ∆rc: 37,908 ∆wc: 134 ∆rb: 0 ∆wb: 0 ∆ic:
29 ∆oc: 12 ∆cw: 0
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > This is getting kind of crazy.  My suggestion is
this - get rid of
> > > > that display entirely.  Add a Help / Info menu
option that brings up a
> > > > window with a verbose version of that information.
> > > >
> > > >
> > > > Thanks.
> > > >
> > > >
> > > > Blake
> > > >
> > > >
> > >
> > >
> >
> >
>

Re: [Bug-apl] About aplwrap

[Chris Moller]

Hi, y'all,

I just stuck this patch in.  It works fine for me, but, Christian, if 
you could try it in your environment, I'd appreciate it.


Chris  (also, BTW, "Christian" who happens to have a son named Robert 
Christian Moller)



On 03/29/16 18:42, Christian Robert wrote:

Hi Chris,

  I found a bug in 
https://github.com/ChrisMoller/aplwrap/blob/master/src/txtbuf.c
  The bug randomly make aplwrap to coredump, especially if you yse the 
copy down

  feature. Look for the word "HERE" below ...


int
handle_copy_down ()
{
  GtkTextIter start_iter, end_iter;
  if (gtk_text_buffer_get_selection_bounds (buffer, &start_iter, 
&end_iter)) {

//  Case 1: selection is not empty
//
//  If selection does not span newline
//copy selection to end of buffer
//If selection does not end with a space
//  append a space to end of buffer
//*Do not* scroll to end!
gchar *text = gtk_text_buffer_get_text (buffer,
&start_iter,
&end_iter,
FALSE);
if (text == NULL || strchr (text, '\n')) return 0;

gtk_text_buffer_get_end_iter (buffer, &end_iter);
gtk_text_buffer_place_cursor (buffer, &end_iter);
gtk_text_buffer_insert_at_cursor (buffer, text, -1);
if (text[strlen(text)-1] != ' ')
  gtk_text_buffer_insert_at_cursor (buffer, " ", -1);

g_free (text);
return 1;
  }
  else {
//  Case 2: selection is empty
//
//  If cursor is in previous input
//copy previous input to end of buffer
//scroll to end of buffer
GtkTextIter insert_iter;
GtkTextMark *mark = gtk_text_buffer_get_insert (buffer);
gtk_text_buffer_get_iter_at_mark (buffer, &insert_iter, mark);
if (gtk_text_iter_has_tag (&insert_iter, get_tag(TAG_INP))) {
  gint sz;
  gchar *text = get_input_text (&sz);
  gchar *ztext = g_try_malloc (sz+1-6);
  if (ztext) {
memcpy(ztext, text+6, sz-6);
ztext[sz] = '\0';//  <--- *HERE*
handle_history_replacement (ztext);
g_free (ztext);
  }
  return 1;
}
else if (gtk_text_iter_has_tag (&insert_iter, get_tag(TAG_LCK)))
  return 1;
return 0;
  }
}




should be:

   ztext[sz-6] = '\0';


or better, delete that line, the memcpy() above always include the 
final '\0', I've traced it.



thanks for committing that change.

Christian Robert,
Poly.

[Bug-apl] aplwrap

[Chris Moller]

I've no idea how many people use aplwrap, but just in case it's greater 
than zero...


The code has rotted a bit since I last tinkered with it--a couple of 
GTK+ functions have been deprecated and the calling convention of a 
couple others changed slightly.  I've patched all that; if you try it, 
you should get a clean build.  The only problem you might see is a 
warning about aclocal and automake--I haven't had time to put a 
latest/greatest Fedora on any of my boxes--but it should build anyway.  
If the warning bugs you, rebuilding the configure script by rerunning 
./autogen.sh should fix it, and I'll try to schedule myself an upgrade 
sometime soon.


Happy hacking,
Chris Moller

[Bug-apl] Possible bug in APL

[Chris Moller]

Doing some other stuff involving libapl.so, I was running valgrind 
against my own code when this popped up:



==14122== Source and destination overlap in mempcpy(0x778a9e1, 0x778a9e1, 4)
==14122==    at 0x4C34FF0: mempcpy (vg_replace_strmem.c:1524)
==14122==    by 0x7E06634: realpath@@GLIBC_2.3 (in /usr/lib64/libc-2.27.so)
==14122==    by 0x7441092: LibPaths::search_APL_lib_root() (LibPaths.cc:186)
==14122==    by 0x7441173: LibPaths::init(char const*, bool) 
(LibPaths.cc:53)

==14122==    by 0x7422B96: init_1(char const*, bool) (Common.cc:77)
==14122==    by 0x7509C09: init_libapl (libapl.cc:435)
==14122==    by 0x4048F9: main (gapl.c:685)


The line in LibPaths.cc is:

   unused = realpath(APL_lib_root, APL_lib_root);

which could obviously cause a collision.

I don't know if this is a real problem or not, but I thought I ought to  
mention it to someone.


Chris Moller

Re: [Bug-apl] Possible bug in APL

[Chris Moller]

I tried building apl-1.7.tar.gz, but running ./configure gave me:

   svn: E155007: '/home/moller/Downloads/apl-1.7/src/Archive.cc' is not
   a working copy

and then build gives me:

g++ -DHAVE_CONFIG_H -I. -I..    -Werror -Wall -I sql    -rdynamic -g -O2 
-MT apl-Avec.o -MD -MP -MF .deps/apl-Avec.Tpo -c -o apl-Avec.o `test -f 
'Avec.cc' || echo './'`Avec.cc

In file included from Svar_DB.hh:32,
 from Symbol.hh:30,
 from SystemVariable.hh:26,
 from Quad_RL.hh:24,
 from Workspace.hh:31,
 from Assert.cc:28:
Svar_record.hh: In member function 'void Svar_record::clear()':
Svar_record.hh:183:50: error: 'void* memset(void*, int, size_t)' 
clearing an object of non-trivial type 'struct Svar_record'; use 
assignment or value-initialization instead [-Werror=class-memaccess]

    void clear()   { memset(this, 0, sizeof(*this)); }
^
Svar_record.hh:174:8: note: 'struct Svar_record' declared here
 struct Svar_record
    ^~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:1838: apl-Assert.o] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from Svar_DB.hh:32,
 from Symbol.hh:30,
 from UserFunction.hh:29,
 from Macro.hh:24,
 from main.cc:38:
Svar_record.hh: In member function 'void Svar_record::clear()':
Svar_record.hh:183:50: error: 'void* memset(void*, int, size_t)' 
clearing an object of non-trivial type 'struct Svar_record'; use 
assignment or value-initialization instead [-Werror=class-memaccess]

    void clear()   { memset(this, 0, sizeof(*this)); }
^
Svar_record.hh:174:8: note: 'struct Svar_record' declared here
 struct Svar_record
    ^~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:1796: apl-main.o] Error 1
mv -f .deps/apl-Avec.Tpo .deps/apl-Avec.Po
In file included from Svar_DB.hh:32,
 from Symbol.hh:30,
 from SystemVariable.hh:26,
 from Quad_RL.hh:24,
 from Workspace.hh:31,
 from Archive.hh:28,
 from Archive.cc:29:
Svar_record.hh: In member function 'void Svar_record::clear()':
Svar_record.hh:183:50: error: 'void* memset(void*, int, size_t)' 
clearing an object of non-trivial type 'struct Svar_record'; use 
assignment or value-initialization instead [-Werror=class-memaccess]

    void clear()   { memset(this, 0, sizeof(*this)); }
^
Svar_record.hh:174:8: note: 'struct Svar_record' declared here
 struct Svar_record
    ^~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:1810: apl-Archive.o] Error 1
make[3]: Leaving directory '/home/moller/Downloads/apl-1.7/src'
make[2]: *** [Makefile:3174: all-recursive] Error 1
make[2]: Leaving directory '/home/moller/Downloads/apl-1.7/src'
make[1]: *** [Makefile:509: all-recursive] Error 1
make[1]: Leaving directory '/home/moller/Downloads/apl-1.7'
make: *** [Makefile:396: all] Error 2


All this on Fedora release 28 (Twenty Eight)

[0] ~/Downloads/apl-1.7 >g++ --version 12:08:58
g++ (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[0] ~/Downloads/apl-1.7 >uname -a 12:09:42
Linux hpbox.mollernet.net 4.16.13-300.fc28.x86_64 #1 SMP Wed May 30 
14:31:00 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[0] ~/Downloads/apl-1.7 >


I'm no C++ guy, but I was going to look more closely into this when I 
got time.  I've had other recent problems with GCC 8.1, so I tend to 
suspect that, but that's just a guess.



Chris



On 25/06/18 11:54, Juergen Sauermann wrote:

Hi Chris,

even after a close look at the GNU APL code I can't see anything wrong 
with how realpath() is being called.


To me it looks more like a bug in glibc 2.3, although the valgrind 
message suggests that this bug causes no harm
(a memory area is copied to itself, which is an overlap but one that 
causes no harm).


It also looks to me as if you are using an older GNU APL version 
because I cannot
find the line in Libpath.cc that you quote below in the current GNU 
APL code.


Thank you nevertheless for reporting this.

/// Jürgen



On 06/24/2018 02:29 PM, Chris Moller wrote:


Doing some other stuff involving libapl.so, I was running valgrind 
against my own code when this popped up:



==14122== Source and destination overlap in mempcpy(0x778a9e1, 
0x778a9e1, 4)

==14122==    at 0x4C34FF0: mempcpy (vg_replace_strmem.c:1524)
==14122==    by 0x7E06634: realpath@@GLIBC_2.3 (in 
/usr/lib64/libc-2.27.so)
==14122==    by 0x7441092: LibPaths::search_APL_lib_root() 
(LibPaths.

Re: [Bug-apl] Possible bug in APL

[Chris Moller]

I got that non-working version of apl-1.7.tar.gz from 
ftp.gnu.org/pub/gnu/apl, dated 17 March 2017, so I guess it's a bit 
out-of-date.


I just now got a chance to pull down the savannah svn version, which 
./configures fine, but there a few compile errors with g++ (GCC) 8.1.1 
20180502 (Red Hat 8.1.1-1).  They're all the same nit-picking bug 
complaining about memcpy:


error: ‘void* memcpy(void*, const void*, size_t)’ writing to an object 
of type ‘class Token’ with no trivial copy-assignment; use 
copy-initialization instead [-Werror=class-memaccess]



Here's the relevant portion of an svn diff:


Index: src/Executable.cc
===
--- src/Executable.cc   (revision 1054)
+++ src/Executable.cc   (working copy)
@@ -794,9 +794,9 @@
    for (;t1 < t2; ++t1, --t2)
    {
  char tt[sizeof(Token)];
- memcpy(tt, t1, sizeof(Token));
- memcpy(t1, t2,   sizeof(Token));
- memcpy(t2, tt, sizeof(Token));
+ memcpy(static_cast (tt), t1, sizeof(Token));
+ memcpy(static_cast (t1), t2, sizeof(Token));
+ memcpy(static_cast (t2), tt, sizeof(Token));
    }
 }
 //-
Index: src/InputFile.cc
===
--- src/InputFile.cc    (revision 1054)
+++ src/InputFile.cc    (working copy)
@@ -40,7 +40,7 @@
 //-
 InputFile & InputFile::operator =(const InputFile & other)
 {
-   memcpy(this, &other, sizeof(InputFile));   // illegally duplicates 
strings!
+  memcpy(static_cast (this), &other, sizeof(InputFile));   // 
illegally duplicates strings!

    ::new (&object_filter) UCS_string_vector(other.object_filter);
    new (&filename) UTF8_string(&other.filename[0], other.filename.size());
    return *this;
Index: src/Token.cc
===
--- src/Token.cc    (revision 1054)
+++ src/Token.cc    (working copy)
@@ -840,9 +840,9 @@
    for (;t1 < t2; ++t1, --t2)
    {
  char tt[sizeof(Token)];
- memcpy(tt, t1, sizeof(Token));
- memcpy(t1, t2,   sizeof(Token));
- memcpy(t2, tt, sizeof(Token));
+ memcpy(static_cast (tt), t1, sizeof(Token));
+ memcpy(static_cast (t1), t2, sizeof(Token));
+    memcpy(static_cast (t2), tt, sizeof(Token));
    }
 }


(If you just do the obvious and (void *) cast the target argument, it 
complains that you're using an "old style" cast.)


I don't have any older g++ versions around, so I have no idea if this 
patch will break anything.



Chris



On 26/06/18 13:43, Juergen Sauermann wrote:

Hi Chris,

the *svn E155007* happens if you unpack a GNU APL tar file (as opposed to
checking out GNU APL from SVN, which is the proposed method). See
https://savannah.gnu.org/svn/?group=apl.

The other error was fixed already in *SVN* version *1052* (see
http://svn.savannah.gnu.org/viewvc/apl/trunk/src/Svar_record.hh?r1=1051&r2=1052
for details.

Fro the first error message I can see that you have SVN installed. So 
checking out

the latest version of GNU APL is simply runnung this command:

*|svn co http://svn.savannah.gnu.org/svn/apl|*

That should give you the latest SVN version (currently *1053*) of GNU 
APL where

both errors above should disappear.

File *apl-1.7.tar.gz* (whereever you found that) is too old to compile 
under

the most recent *gcc* versions.

/// Jürgen

[Bug-apl] Yet another editor thingy.

[Chris Moller]

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 '#cc' -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///.apl

   where  is the user's userid,  is the process id of the APL
   session, and  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.")

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

[Chris Moller]

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 '#cc'
-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///.apl

where  is the user's userid,  is the process id of the APL
session, and  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.")

[Bug-apl] Another trivial g++ 8.1.1 incompatibility

[Chris Moller]

This is the same as the last batch--don't know how I  missed it the 
first time:



   Index: Svar_DB.cc
   ===
   --- Svar_DB.cc  (revision 1055)
   +++ Svar_DB.cc  (working copy)
   @@ -316,7 +316,8 @@
    del, log);
    if (response)
   {
   -    memcpy(&cache, response->get__SVAR_RECORD_IS__record().data(),
   +    memcpy(static_cast (&cache),
   + response->get__SVAR_RECORD_IS__record().data(),
    sizeof(Svar_record));
 delete response;
   }

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

[Chris Moller]

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 '#cc'
-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 variable

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

[Chris Moller]

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  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 '#cc' -font 'Dej

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

[Chris Moller]

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 == EOF)
   {
   +   if (errno == EINTR) {
   + clearerr (stdin);
   + CIN.unsetf( std::ios_base::unitbuf );
   + goto again;
   +   }
    if (got_WINCH)
   {
 got_WINCH = false;


On 29/07/18 22:00, Chris Moller wrote:


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  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:

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

[Chris Moller]

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, gvim, nano, and probably other editors (those are the 
ones I've tested) and when the function is saved it will fixed in APL.  
Two versions are included, libedif and libedif2, the former, which I 
usually ⎕fx as 'edif', runs in the APL process and defaults to opening 
the function in vi.  libedif2, which I usually ⎕fx as 'edif2', spawns 
separate processes for the editors (defaulting to emacs) it opens, 
allowing the user to go on using APL while the editor is open--including 
testing saved functions real-time without having to close the 
editor--and allowing any number of edit windows to be open 
simultaneously on different functions.


Feedback welcome, and 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'
    or
    edif2 'function_name'

Both of these 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..  (In the case of a new function, the
boilerplate name can be edited as necessary:

    fubar

can be edited to

    z←x fubar y

and the right thing will be fixed in APL.  (Even existing functions can be
modified this way.))

The two versions of the function differ in that the first version, edif,
suspends the current APL session until the editor is closed, while the
second version, edif2, opens the editor in a separate process, in a
separate window, while the APL session remains active.  This allows
functions to be edited and tested concurrently without having to go
into and out of the editor.  edif2 also allows multiple editor windows
to be open simultaneously on different functions.

Both versions have a dyadic form:

    'editor' edif 'function_name'
    or
    'editor' edif2 'function_name'

where 'editor' is the editor to be invoked.  For example:

    'vi' edif 'fubar'

would open function fubar using the vi editor.

    'emacs' edif2 'fu'
    'emacs' edif2 'bar'

would open functions fu and bar in separate emacs windows.

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="nano"

will cause edif to default to using the nano editor.  Similarly, the EDIF2
variable affects the default edif2 editor.

edif has been tested with emacs, vi, and nano; edif2 with emacs and gvim.
The default editor for edif is vi; the default for edif2 is

   "emacs --geometry=40x20  -background '#cc' -font 'DejaVu Sans 
Mono-10'"


The dyadic form is a one-shot thing--edif doesn't remember editors
specified this way and the monadic form will go back to using the
default or environment-specified editor.

edif may be included in the workspace with:

    'libedif.so' ⎕fx 'edif'

and edif2 with:

    'libedif2.so' ⎕fx 'edif2'

Of course, you can use any function names you like and, as long as you use
different names, both versions can be used at the same time.

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.

By the way, "edif" is short for "editor interface."



Implimentation note:

edif and edif2 work by storing an editable version of the specified
function in:

/var/run/user///.apl

where  is the user's userid,  is the process id of the APL
session, and  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.



On 30/07/18 10:52, Juergen Sauermann wrote:

Hi Chris,

thanks, done in *SVN 1060*.

/// Jürgen


On 07/30/2018 03:59 PM, Chris Moller wrote:


Here's an even simpler, mor

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

[Chris Moller]

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 showed up in SVN 
1060, but that seems to be not quite right. That patch was an 
alternative to a slightly clumsier patch I'd tried earlier, somaybe 
reverting to the original patch would help:



Index: LineInput.cc
===
--- LineInput.cc    (revision 1060)
+++ LineInput.cc    (working copy)
@@ -968,9 +968,10 @@
   {
 if (errno == EINTR)
    {
- clearerr(stdin);
- CIN.unsetf(ios_base::unitbuf);
- goto again;
+    clearerr (stdin);
+    CIN.unsetf( std::ios_base::unitbuf );
+    CERR.unsetf( std::ios_base::unitbuf );
+    return UNI_ASCII_CR;
    }

    if (got_WINCH)

If you could give that a try and let me know if it fixes things in your 
environment, I'd appreciate it.



Thanks,

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 
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.

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, gvim, nano, and probably other editors 
(those are the ones I've tested) and when the function is saved it 
will fixed in APL.  Two versions are included, libedif and libedif2, 
the former, which I usually ⎕fx as 'edif', runs in the APL process 
and defaults to opening the function in vi.  libedif2, which I 
usually ⎕fx as 'edif2', spawns separate processes for the editors 
(defaulting to emacs) it opens, allowing the user to go on using APL 
while the editor is open--including testing saved functions real-time 
without having to close the editor--and allowing any number of edit 
windows to be open simultaneously on different functions.


Feedback welcome, and 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'
    or
    edif2 'function_name'

Both of these 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..  (In the case of a new function, the
boilerplate name can be edited as necessary:

    fubar

can be edited to

    z←x fubar y

and the right thing will be fixed in APL.  (Even existing functions 
can be

modified this way.))

The two versions of the function differ in that the first version, edif,
suspends the current APL session until the editor is closed, while the
second version, edif2, opens the editor in a separate process, in a
separate window, while the APL session remains active.  This allows
functions to be edited and tested concurrently without having to go
into and out of the editor.  edif2 also allows multiple editor windows
to be open simultaneously on different functions.

Both versions have a dyadic form:

    'editor' edif 'function_name'
    or
    'editor' edif2 'function_name'

where 'editor' is the editor to be invoked.  For example:

    'vi' edif 'fubar'

would open function fubar using the vi editor.

    'emacs' edif2 'fu'
    'emacs' edif2 'bar'

would open functions fu and bar in separate emacs windows.

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="nano"

will cause edif to default to using the nano editor. Similarly, the EDIF2
variable affects the default edif2 editor.

edif has been tested with emacs, vi, and nano; edif2 with emacs and gvim.
The default editor for edif is vi; the default for edif2 is

   "emacs --geometry=40x20  -background '#cc' -font 'DejaVu Sans 
Mono-10'"


The dyadic form is a one-shot thing--edif doesn't remember editors
specified this way and the monadic form will go back to using the
default or environment-specified editor.

edif may be included in the workspace with:

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

[Chris Moller]

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 your 
save-state suggestion.  It seems to be a highly intermittent thing, 
which, in combination with fork()/exec()/terminate, possibly suggests a 
race condition somewhere.


--Chris


On 02/08/18 11:40, Juergen Sauermann wrote:

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 do not understand is:

1. according to https://en.cppreference.com/w/cpp/io/manip/unitbuf, the
unitbuf bit
changes only the timing of the output but not the output itself. So it
buys you some
time but is not guaranteed to do that. My concern is that you may
introduce some
unpredictable behaviour into the main input loop of the GNU interpreter.

2. Wouldn't it be cleaner if you save the state of CIN and CERR when you
enter your editor
and restore it when leaving it? Right now the state of CIN and CERR
seems to change after
hitting ^C for the first time.

/// Jürgen


On 08/02/2018 03:14 PM, Chris Moller wrote:

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 showed up in SVN
1060, but that seems to be not quite right.  That patch was an
alternative to a slightly clumsier patch I'd tried earlier, somaybe
reverting to the original patch would help:


Index: LineInput.cc
===
--- LineInput.cc    (revision 1060)
+++ LineInput.cc    (working copy)
@@ -968,9 +968,10 @@
    {
  if (errno == EINTR)
     {
- clearerr(stdin);
- CIN.unsetf(ios_base::unitbuf);
- goto again;
+    clearerr (stdin);
+    CIN.unsetf( std::ios_base::unitbuf );
+    CERR.unsetf( std::ios_base::unitbuf );
+    return UNI_ASCII_CR;
     }
  
     if (got_WINCH)


If you could give that a try and let me know if it fixes things in
your environment, I'd appreciate it.


Thanks,

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
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.

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, gvim, nano, and probably other editors
(those are the ones I've tested) and when the function is saved it
will fixed in APL.  Two versions are included, libedif and libedif2,
the former, which I usually ⎕fx as 'edif', runs in the APL process
and defaults to opening the function in vi.  libedif2, which I
usually ⎕fx as 'edif2', spawns separate processes for the editors
(defaulting to emacs) it opens, allowing the user to go on using APL
while the editor is open--including testing saved functions
real-time without having to close the editor--and allowing any
number of edit windows to be open simultaneously on different
functions.

Feedback welcome, and 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'
     or
     edif2 'function_name'

Both of these 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..  (In the case of a new function, the
boilerplate name can be edited as necessary:

     fubar

can be edited to

     z←x fubar y

and the right thing will be fixed in APL.  (Even existing functions
can be
modified this way.))

The two versions of the function differ in that the first version, edif,
suspends the current APL session until the editor is closed, while the
second version, edif2, opens the editor in a separate process, in a
separate window, while the APL session remains ac

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

[Chris Moller]

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 hacking at it.  It 
doesn't appear to be directly related to the EINTR patch in 
LineInput::get_uni(), though at least stdin has to be cleared when errno == 
EINTR.

-- Chris


On 02/08/18 13:12, Chris Moller wrote:


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 your 
save-state suggestion.  It seems to be a highly intermittent thing, 
which, in combination with fork()/exec()/terminate, possibly suggests 
a race condition somewhere.


--Chris

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

[Chris Moller]

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 
written to the screen by CIN, resulting in a ERESTARTSYS.  I don't know 
if that resulted in an EINTR after the first fgetc() in 
LineInput::get_uni(), but it doesn't matter--LineInput::get_uni() has no 
way to retry the CIN write. What does cause a retry is setting 
SA_RESTART in my signal handlers.  So far as I can tell, that fixes the 
problem.


LineInput.cc needs one more tiny patch to remove an unnecessary step:

Index: LineInput.cc
===
--- LineInput.cc    (revision 1061)
+++ LineInput.cc    (working copy)
@@ -969,7 +969,6 @@
 if (errno == EINTR)
    {
  clearerr(stdin);
- CIN.unsetf(ios_base::unitbuf);
  goto again;
    }

In addition to that first fgetc() in LineInput::get_uni(), there are two 
more.  So far as I know, edif2 hasn't caused any signal problems with 
those fgetc()s, but it's not impossible.  It might be worthwhile putting 
in some code to catch EOF/EINTR conditions on them too.


--Chris


On 03/08/18 16:34, Chris Moller wrote:

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 hacking at it.  It 
doesn't appear to be directly related to the EINTR patch in 
LineInput::get_uni(), though at least stdin has to be cleared when errno == 
EINTR.

-- Chris

On 02/08/18 13:12, Chris Moller wrote:


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 your 
save-state suggestion. It seems to be a highly intermittent thing, 
which, in combination with fork()/exec()/terminate, possibly suggests 
a race condition somewhere.


--Chris

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

[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://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 
cumbersome.


But the apl session gets blocked during editing (edif2).

Currently I have no clue, how to analyze it.

Thank you again.

Hans-Peter

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

[Chris Moller]

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 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
cumbersome.

But the apl session gets blocked during editing (edif2).

Currently I have no clue, how to analyze it.

Thank you again.

Hans-Peter

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

[Chris Moller]

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 @@
   {
 if (errno == EINTR)
    {
- clearerr(stdin);
- CIN.unsetf(ios_base::unitbuf);
- goto again;
+    clearerr (stdin);
+    CIN.unsetf( std::ios_base::unitbuf );
+    CERR.unsetf( std::ios_base::unitbuf );
+    return UNI_ASCII_CR;
    }

I think it's still a good idea to catch EINTR just to avoid having nulls 
returned:



Index: LineInput.cc
===
--- LineInput.cc    (revision 1061)
+++ LineInput.cc    (working copy)
@@ -969,7 +969,6 @@
 if (errno == EINTR)
    {
  clearerr(stdin);
- CIN.unsetf(ios_base::unitbuf);
  goto again;
    }


I.e., getting rid of the CIN.unsetf(ios_base::unitbuf), making the code 
look like:



const int b0 = fgetc(stdin);
   if (b0 == EOF)
  {
    if (errno == EINTR)
   {
 clearerr(stdin);
 goto again;
   }

   if (got_WINCH)



Thanks,

Chris


On 10/08/18 09:11, Juergen Sauermann wrote:

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, 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 cumbersome.


But the apl session gets blocked during editing (edif2).

Currently I have no clue, how to analyze it.

Thank you again.

Hans-Peter

Re: [Bug-apl] ⎕GTK

[Chris Moller]

Excellent!


On 10/08/18 13:32, Juergen Sauermann wrote:

Hi,

I have added a new system function *⎕GTK *to GNU APL.

*⎕GTK* is based on libgtk+ version 3 and provides a simple (and
therefore somewhat restricted) way of creating and  managing GUIs
from an APL program.

Think of it as a replacement for *⎕* and *⍞* as to create more intuitive
user interfaces to APL programs.

*⎕GTK* is described in *HOWTOs/Quad-GTK.h**t**ml*.

Enjoy,
/// Jürgen

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

[Chris Moller]

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)* - if at all needed -
should go to a different place.

The new code would be this:

*//-**
**Unicode**
**LineInput::get_uni()**
**{**
**again:**
**
**const int b0 = fgetc(stdin);**
**   if (b0 == EOF)**
**  {**
**    if (errno == EINTR)   goto again;
  }
**
**   ...*

Could you please check if your editor still works with that?

I also noticed another *fgetc() *below the one shown above. I suppose that
I should check for EINTR .in that one as well.

Best Regards,
/// Jürgen



On 08/10/2018 03:35 PM, Chris Moller wrote:


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 @@
   {
 if (errno == EINTR)
    {
- clearerr(stdin);
- CIN.unsetf(ios_base::unitbuf);
- goto again;
+    clearerr (stdin);
+    CIN.unsetf( std::ios_base::unitbuf );
+    CERR.unsetf( std::ios_base::unitbuf );
+    return UNI_ASCII_CR;
    }

I think it's still a good idea to catch EINTR just to avoid having 
nulls returned:



Index: LineInput.cc
===
--- LineInput.cc    (revision 1061)
+++ LineInput.cc    (working copy)
@@ -969,7 +969,6 @@
 if (errno == EINTR)
    {
  clearerr(stdin);
- CIN.unsetf(ios_base::unitbuf);
  goto again;
    }


I.e., getting rid of the CIN.unsetf(ios_base::unitbuf), making the 
code look like:



const int b0 = fgetc(stdin);
   if (b0 == EOF)
  {
    if (errno == EINTR)
   {
 clearerr(stdin);
 goto again;
   }

   if (got_WINCH)



Thanks,

Chris


On 10/08/18 09:11, Juergen Sauermann wrote:

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, 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 cumbersome.


But the apl session gets blocked during editing (edif2).

Currently I have no clue, how to analyze it.

Thank you again.

Hans-Peter

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

[Chris Moller]

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 these days is in boring old C.


So, yeah, I think it's safe to say that any and all references to 
unitbuf should go in a different place: the bit bucket.


--CM


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)* - if at all needed -
should go to a different place.

The new code would be this:

*//-**
**Unicode**
**LineInput::get_uni()**
**{**
**again:**
**
**const int b0 = fgetc(stdin);**
**   if (b0 == EOF)**
**  {**
**    if (errno == EINTR)   goto again;
  }
**
**   ...*

Could you please check if your editor still works with that?

I also noticed another *fgetc() *below the one shown above. I suppose that
I should check for EINTR .in that one as well.

Best Regards,
/// Jürgen



On 08/10/2018 03:35 PM, Chris Moller wrote:


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 @@
   {
 if (errno == EINTR)
    {
- clearerr(stdin);
- CIN.unsetf(ios_base::unitbuf);
- goto again;
+    clearerr (stdin);
+    CIN.unsetf( std::ios_base::unitbuf );
+    CERR.unsetf( std::ios_base::unitbuf );
+    return UNI_ASCII_CR;
    }

I think it's still a good idea to catch EINTR just to avoid having 
nulls returned:



Index: LineInput.cc
===
--- LineInput.cc    (revision 1061)
+++ LineInput.cc    (working copy)
@@ -969,7 +969,6 @@
 if (errno == EINTR)
    {
  clearerr(stdin);
- CIN.unsetf(ios_base::unitbuf);
  goto again;
    }


I.e., getting rid of the CIN.unsetf(ios_base::unitbuf), making the 
code look like:



const int b0 = fgetc(stdin);
   if (b0 == EOF)
  {
    if (errno == EINTR)
   {
 clearerr(stdin);
 goto again;
   }

   if (got_WINCH)



Thanks,

Chris


On 10/08/18 09:11, Juergen Sauermann wrote:

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, 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 cumbersome.


But the apl session gets blocked during editing (edif2).

Currently I have no clue, how to analyze it.

Thank you again.

Hans-Peter

[Bug-apl] edif update

[Chris Moller]

I just committed a minor patch to edif, fixing a relatively low 
probability bug involving a possible message queue name collision if you 
have two or more APL sessions open simultaneously.


https://github.com/ChrisMoller/edif

--cm

Re: [Bug-apl] edif update / ⎕IO is 0

[Chris Moller]

I  wasn't closely following the first series of posts about this bug 
but, for what it's worth, I can reproduce it regardless of whether edif 
or edif2 has been ⎕fx-ed.  Neither edif nor edif2 do anything with ⎕io.



[0] ~tinkering/apl-natives/vis/src >apl -L startup -q $@
  ⎕io
1
  edif2 'qio_test'
  qio_test
1
  ⎕io
1
  ⎕io←0
  edif2 'qio_test'
  qio_test
0
  ⎕io
0

Chris


On 16/08/18 13:29, Hans-Peter Sorge wrote:


Hello,

The ⎕IO bug  is back.

(note: ⎕IO ←→ 0 seems to be set to 0 using edif2)


      ∇qio_test[⎕]∇

    ∇
[0]   qio_test
[1]   ⎕IO
    ∇

  ⎕IO←1
  ⎕IO
1
    qio_test
1
    ⍎¨ 'qio_test' 'qio_test'
1
1

  ⎕IO←0

  ⎕IO

0

    qio_test
0
    ⍎¨ 'qio_test' 'qio_test'
1
1

Greetings

Hans-Peter

Re: [Bug-apl] edif update / ⎕IO is 0

[Chris Moller]

Not that I expected otherwise, but edif and edif2 still work as expected.

cm


On 16/08/18 15:14, Juergen Sauermann wrote:

Hi Hans-Peter,

thanks, hopefully fixed in *SVN 1069*.

Best Regards,
/// Jürgen


On 08/16/2018 07:29 PM, Hans-Peter Sorge wrote:


Hello,

The ⎕IO bug  is back.

(note: ⎕IO ←→ 0 seems to be set to 0 using edif2)


      ∇qio_test[⎕]∇

    ∇
[0]   qio_test
[1]   ⎕IO
    ∇

  ⎕IO←1
  ⎕IO
1
    qio_test
1
    ⍎¨ 'qio_test' 'qio_test'
1
1

  ⎕IO←0

  ⎕IO

0

    qio_test
0
    ⍎¨ 'qio_test' 'qio_test'
1
1

Greetings

Hans-Peter



Am 14.08.2018 um 18:17 schrieb Chris Moller:


I just committed a minor patch to edif, fixing a relatively low 
probability bug involving a possible message queue name collision if 
you have two or more APL sessions open simultaneously.


https://github.com/ChrisMoller/edif

--cm

Re: [Bug-apl] edif update / ⎕IO is 0

[Chris Moller]

I can't make it fail, but I'll look closer in the morning.

Is there any chance you have multiple APL processes running 
concurrently? Apparently, that causes problems I hadn't caught before.



Chris


On 17/08/18 17:14, Hans-Peter Sorge wrote:


Hello Chris,

edif2 blocks the apl session again.

edif: latest git.

apl:  1069M

Best Regards,

Hans-Peter


Am 16.08.2018 um 21:31 schrieb Chris Moller:


Not that I expected otherwise, but edif and edif2 still work as expected.

cm


On 16/08/18 15:14, Juergen Sauermann wrote:

Hi Hans-Peter,

thanks, hopefully fixed in *SVN 1069*.

Best Regards,
/// Jürgen


On 08/16/2018 07:29 PM, Hans-Peter Sorge wrote:


Hello,

The ⎕IO bug  is back.

(note: ⎕IO ←→ 0 seems to be set to 0 using edif2)


      ∇qio_test[⎕]∇

    ∇
[0]   qio_test
[1]   ⎕IO
    ∇

  ⎕IO←1
  ⎕IO
1
    qio_test
1
    ⍎¨ 'qio_test' 'qio_test'
1
1

  ⎕IO←0

  ⎕IO

0

    qio_test
0
    ⍎¨ 'qio_test' 'qio_test'
1
1

Greetings

Hans-Peter



Am 14.08.2018 um 18:17 schrieb Chris Moller:


I just committed a minor patch to edif, fixing a relatively low 
probability bug involving a possible message queue name collision 
if you have two or more APL sessions open simultaneously.


https://github.com/ChrisMoller/edif

--cm

Re: [Bug-apl] edif update / ⎕IO is 0

[Chris Moller]

Hi, Hans-Peter,

I'm still trying to figure things out.  At least I think I understand 
the double-free problem and, thinking about it, that may be a clue to 
the rest of it.


Chris



On 18/08/18 15:29, Hans-Peter Sorge wrote:


Hello Chris,

I have just one process running.

I recompiled and reinstalled edif to make sure it's the most recent 
version.


During editing with emacs:

session is blocked, then in APL session

Ctrl C
fg

'some data' ENTER  - no response

in emacs: save

in APL session:
   'some data' replayed
'some data' response

-

There is on other quirk too:


  'libedif.so' ⎕fx 'edif2'
edif2
  'libedif.so' ⎕fx 'edif2'
edif2
  )off
double free or corruption (fasttop)
Abgebrochen (Speicherabzug geschrieben) [segmentation fault]

Best regards,
Hans-Peter


Am 18.08.2018 um 02:39 schrieb Chris Moller:


I can't make it fail, but I'll look closer in the morning.

Is there any chance you have multiple APL processes running 
concurrently? Apparently, that causes problems I hadn't caught before.



Chris


On 17/08/18 17:14, Hans-Peter Sorge wrote:


Hello Chris,

edif2 blocks the apl session again.

edif: latest git.

apl:  1069M

Best Regards,

Hans-Peter


Am 16.08.2018 um 21:31 schrieb Chris Moller:


Not that I expected otherwise, but edif and edif2 still work as 
expected.


cm


On 16/08/18 15:14, Juergen Sauermann wrote:

Hi Hans-Peter,

thanks, hopefully fixed in *SVN 1069*.

Best Regards,
/// Jürgen


On 08/16/2018 07:29 PM, Hans-Peter Sorge wrote:


Hello,

The ⎕IO bug  is back.

(note: ⎕IO ←→ 0 seems to be set to 0 using edif2)


      ∇qio_test[⎕]∇

    ∇
[0]   qio_test
[1]   ⎕IO
    ∇

  ⎕IO←1
  ⎕IO
1
    qio_test
1
    ⍎¨ 'qio_test' 'qio_test'
1
1

  ⎕IO←0

  ⎕IO

0

    qio_test
0
    ⍎¨ 'qio_test' 'qio_test'
1
1

Greetings

Hans-Peter



Am 14.08.2018 um 18:17 schrieb Chris Moller:


I just committed a minor patch to edif, fixing a relatively low 
probability bug involving a possible message queue name 
collision if you have two or more APL sessions open simultaneously.


https://github.com/ChrisMoller/edif

--cm

Re: [Bug-apl] edif update / ⎕IO is 0

[Chris Moller]

Hi, Hans-Peter,

That quirk where you quad-fx edif2 twice...

When edif2 starts, it fork()s a process to watch for changes in the 
working-file copies of the functions passed to emacs, and it also opens 
a POSIX message queue so the monitor process can communicate changes to 
APL.  When you quad-fx-ed edif2 twice, all that was duplicated--two 
monitor processes, another sender on the queue, and more signals being 
emitted.  I've put a patch in (but haven't committed it yet, and it 
should fix the segfault) that prevents all that, but my question is 
whether the "session blocked" bug happens only after the second 
quad-fx.  I just can't reproduce the blocking bug here, so I'm looking 
desperately for some non-obvious cause.


Thanks,
Chris

On 08/18/18 15:29, Hans-Peter Sorge wrote:


Hello Chris,

I have just one process running.

I recompiled and reinstalled edif to make sure it's the most recent 
version.


During editing with emacs:

session is blocked, then in APL session

Ctrl C
fg

'some data' ENTER  - no response

in emacs: save

in APL session:
   'some data' replayed
'some data' response

-

There is on other quirk too:


  'libedif.so' ⎕fx 'edif2'
edif2
  'libedif.so' ⎕fx 'edif2'
edif2
  )off
double free or corruption (fasttop)
Abgebrochen (Speicherabzug geschrieben) [segmentation fault]

Best regards,
Hans-Peter


Am 18.08.2018 um 02:39 schrieb Chris Moller:


I can't make it fail, but I'll look closer in the morning.

Is there any chance you have multiple APL processes running 
concurrently? Apparently, that causes problems I hadn't caught before.



Chris


On 17/08/18 17:14, Hans-Peter Sorge wrote:


Hello Chris,

edif2 blocks the apl session again.

edif: latest git.

apl:  1069M

Best Regards,

Hans-Peter


Am 16.08.2018 um 21:31 schrieb Chris Moller:


Not that I expected otherwise, but edif and edif2 still work as 
expected.


cm


On 16/08/18 15:14, Juergen Sauermann wrote:

Hi Hans-Peter,

thanks, hopefully fixed in *SVN 1069*.

Best Regards,
/// Jürgen


On 08/16/2018 07:29 PM, Hans-Peter Sorge wrote:


Hello,

The ⎕IO bug  is back.

(note: ⎕IO ←→ 0 seems to be set to 0 using edif2)


      ∇qio_test[⎕]∇

    ∇
[0]   qio_test
[1]   ⎕IO
    ∇

  ⎕IO←1
  ⎕IO
1
    qio_test
1
    ⍎¨ 'qio_test' 'qio_test'
1
1

  ⎕IO←0

  ⎕IO

0

    qio_test
0
    ⍎¨ 'qio_test' 'qio_test'
1
1

Greetings

Hans-Peter



Am 14.08.2018 um 18:17 schrieb Chris Moller:


I just committed a minor patch to edif, fixing a relatively low 
probability bug involving a possible message queue name 
collision if you have two or more APL sessions open simultaneously.


https://github.com/ChrisMoller/edif

--cm

Re: [Bug-apl] edif update / ⎕IO is 0

[Chris Moller]

Yeah, all of that makes sense--unless they're explicitly unlinked, named 
POSIX message queues remain in existence as long as any process 
continues to exist that opened them, and clearing a workspace doesn't 
terminate the APL process. I'll have to look into what notification, if 
any, native functions get when the WS is cleared.


All this is proving the old maxim that new software, no matter how much 
you test it, never survives unscathed its first user experiences.  Sorry...


Chris



On 20/08/18 10:38, Hans-Peter Sorge wrote:


Hello Chris,

The session stays blocked - what ever I try fiddling around.

During this fiddling I came across on other situation that makes the 
edif2 case even more interesting:


(EDIF2 is a work space having edif2 as function only)

The first session (eg. after reboot) has a double free corruption in 
either case.

1) 'libedif.so' ⎕fx 'edif2'  ..  'libedif.so' ⎕fx 'edif2' .. )off
or
2) )load a WS having function edif2 then  'libedif.so' ⎕fx 'edif2' .. 
)off



[joy@joyw520 ~]$ apl

  'libedif.so' ⎕fx 'edif2'
edif2

       )clear
CLEAR WS
  )load EDIF2
SAVED 2018-08-20 16:03:15 (GMT+2)
  'libedif.so' ⎕fx 'edif2'
edif2
  )off
double free or corruption (fasttop)
Abgebrochen (Speicherabzug geschrieben)


The following case is not expected. Yet one could argue )save does 
some cleaning.


[joy@joyw520 ~]$  apl

  'libedif.so' ⎕fx 'edif2'
edif2
  )save EDIF2
NOT SAVED: THIS WS IS CLEAR WS
  )drop EDIF2
2018-08-20  16:10:32 (GMT+2)
  )save EDIF2
2018-08-20  16:10:36 (GMT+2)
  'libedif.so' ⎕fx 'edif2'
edif2
  )off

Goodbye.
Session duration: 133.863 seconds


But now, on a naked WS, the corruption is gone  sofar I could not 
repeat a subsequent corruption until after a reboot!


[joy@joyw520 ~]$ apl

  'libedif.so' ⎕fx 'edif2'
edif2
  'libedif.so' ⎕fx 'edif2'
edif2
  )off

Goodbye.
Session duration: 6.48602 seconds

Best regards,
Hans-Peter

Am 20.08.2018 um 05:26 schrieb Chris Moller:

Hi, Hans-Peter,

That quirk where you quad-fx edif2 twice...

When edif2 starts, it fork()s a process to watch for changes in the 
working-file copies of the functions passed to emacs, and it also 
opens a POSIX message queue so the monitor process can communicate 
changes to APL.  When you quad-fx-ed edif2 twice, all that was 
duplicated--two monitor processes, another sender on the queue, and 
more signals being emitted.  I've put a patch in (but haven't 
committed it yet, and it should fix the segfault) that prevents all 
that, but my question is whether the "session blocked" bug happens 
only after the second quad-fx.  I just can't reproduce the blocking 
bug here, so I'm looking desperately for some non-obvious cause.


Thanks,
Chris

On 08/18/18 15:29, Hans-Peter Sorge wrote:


Hello Chris,

I have just one process running.

I recompiled and reinstalled edif to make sure it's the most recent 
version.


During editing with emacs:

session is blocked, then in APL session

Ctrl C
fg

'some data' ENTER  - no response

in emacs: save

in APL session:
   'some data' replayed
'some data' response

-

There is on other quirk too:


  'libedif.so' ⎕fx 'edif2'
edif2
  'libedif.so' ⎕fx 'edif2'
edif2
  )off
double free or corruption (fasttop)
Abgebrochen (Speicherabzug geschrieben) [segmentation fault]

Best regards,
Hans-Peter


Am 18.08.2018 um 02:39 schrieb Chris Moller:


I can't make it fail, but I'll look closer in the morning.

Is there any chance you have multiple APL processes running 
concurrently? Apparently, that causes problems I hadn't caught before.



Chris


On 17/08/18 17:14, Hans-Peter Sorge wrote:


Hello Chris,

edif2 blocks the apl session again.

edif: latest git.

apl:  1069M

Best Regards,

Hans-Peter


Am 16.08.2018 um 21:31 schrieb Chris Moller:


Not that I expected otherwise, but edif and edif2 still work as 
expected.


cm


On 16/08/18 15:14, Juergen Sauermann wrote:

Hi Hans-Peter,

thanks, hopefully fixed in *SVN 1069*.

Best Regards,
/// Jürgen


On 08/16/2018 07:29 PM, Hans-Peter Sorge wrote:


Hello,

The ⎕IO bug  is back.

(note: ⎕IO ←→ 0 seems to be set to 0 using edif2)


      ∇qio_test[⎕]∇

    ∇
[0]   qio_test
[1]   ⎕IO
    ∇

  ⎕IO←1
  ⎕IO
1
    qio_test
1
    ⍎¨ 'qio_test' 'qio_test'
1
1

  ⎕IO←0

  ⎕IO

0

    qio_test
0
    ⍎¨ 'qio_test' 'qio_test'
1
1

Greetings

Hans-Peter



Am 14.08.2018 um 18:17 schrieb Chris Moller:


I just committed a minor patch to edif, fixing a relatively 
low probability bug involving a possible message queue name 
collision if you have two or more APL sessions open 
simultaneously.


https://github.com/ChrisMoller/edif

--cm

Re: [Bug-apl] edif update / ⎕IO is 0

[Chris Moller]

Yet another bugfix committed to https://github.com/ChrisMoller/edif.git

Mostly, what it does is detect multiple ⎕fx invocations of libedif2.so 
and short-circuits them, leaving the inotify() process intact and the 
message queue opened only once.  It also detects )clear and 
closes/unlinks the queue, kills the inotify() process, and closes any 
open editor processes.


Chris

On 20/08/18 10:38, Hans-Peter Sorge wrote:


Hello Chris,

The session stays blocked - what ever I try fiddling around.

During this fiddling I came across on other situation that makes the 
edif2 case even more interesting:


(EDIF2 is a work space having edif2 as function only)

The first session (eg. after reboot) has a double free corruption in 
either case.

1) 'libedif.so' ⎕fx 'edif2'  ..  'libedif.so' ⎕fx 'edif2' .. )off
or
2) )load a WS having function edif2 then  'libedif.so' ⎕fx 'edif2' .. 
)off



[joy@joyw520 ~]$ apl

  'libedif.so' ⎕fx 'edif2'
edif2

       )clear
CLEAR WS
  )load EDIF2
SAVED 2018-08-20 16:03:15 (GMT+2)
  'libedif.so' ⎕fx 'edif2'
edif2
  )off
double free or corruption (fasttop)
Abgebrochen (Speicherabzug geschrieben)


The following case is not expected. Yet one could argue )save does 
some cleaning.


[joy@joyw520 ~]$  apl

  'libedif.so' ⎕fx 'edif2'
edif2
  )save EDIF2
NOT SAVED: THIS WS IS CLEAR WS
  )drop EDIF2
2018-08-20  16:10:32 (GMT+2)
  )save EDIF2
2018-08-20  16:10:36 (GMT+2)
  'libedif.so' ⎕fx 'edif2'
edif2
  )off

Goodbye.
Session duration: 133.863 seconds


But now, on a naked WS, the corruption is gone  sofar I could not 
repeat a subsequent corruption until after a reboot!


[joy@joyw520 ~]$ apl

  'libedif.so' ⎕fx 'edif2'
edif2
      'libedif.so' ⎕fx 'edif2'
edif2
  )off

Goodbye.
Session duration: 6.48602 seconds

Best regards,
Hans-Peter

Am 20.08.2018 um 05:26 schrieb Chris Moller:

Hi, Hans-Peter,

That quirk where you quad-fx edif2 twice...

When edif2 starts, it fork()s a process to watch for changes in the 
working-file copies of the functions passed to emacs, and it also 
opens a POSIX message queue so the monitor process can communicate 
changes to APL.  When you quad-fx-ed edif2 twice, all that was 
duplicated--two monitor processes, another sender on the queue, and 
more signals being emitted.  I've put a patch in (but haven't 
committed it yet, and it should fix the segfault) that prevents all 
that, but my question is whether the "session blocked" bug happens 
only after the second quad-fx.  I just can't reproduce the blocking 
bug here, so I'm looking desperately for some non-obvious cause.


Thanks,
Chris

On 08/18/18 15:29, Hans-Peter Sorge wrote:


Hello Chris,

I have just one process running.

I recompiled and reinstalled edif to make sure it's the most recent 
version.


During editing with emacs:

session is blocked, then in APL session

Ctrl C
fg

'some data' ENTER  - no response

in emacs: save

in APL session:
   'some data' replayed
'some data' response

-

There is on other quirk too:

....
      'libedif.so' ⎕fx 'edif2'
edif2
  'libedif.so' ⎕fx 'edif2'
edif2
  )off
double free or corruption (fasttop)
Abgebrochen (Speicherabzug geschrieben) [segmentation fault]

Best regards,
Hans-Peter


Am 18.08.2018 um 02:39 schrieb Chris Moller:


I can't make it fail, but I'll look closer in the morning.

Is there any chance you have multiple APL processes running 
concurrently? Apparently, that causes problems I hadn't caught before.



Chris


On 17/08/18 17:14, Hans-Peter Sorge wrote:


Hello Chris,

edif2 blocks the apl session again.

edif: latest git.

apl:  1069M

Best Regards,

Hans-Peter


Am 16.08.2018 um 21:31 schrieb Chris Moller:


Not that I expected otherwise, but edif and edif2 still work as 
expected.


cm


On 16/08/18 15:14, Juergen Sauermann wrote:

Hi Hans-Peter,

thanks, hopefully fixed in *SVN 1069*.

Best Regards,
/// Jürgen


On 08/16/2018 07:29 PM, Hans-Peter Sorge wrote:


Hello,

The ⎕IO bug  is back.

(note: ⎕IO ←→ 0 seems to be set to 0 using edif2)


      ∇qio_test[⎕]∇

    ∇
[0]   qio_test
[1]   ⎕IO
    ∇

  ⎕IO←1
  ⎕IO
1
    qio_test
1
    ⍎¨ 'qio_test' 'qio_test'
1
1

  ⎕IO←0

  ⎕IO

0

    qio_test
0
    ⍎¨ 'qio_test' 'qio_test'
1
1

Greetings

Hans-Peter



Am 14.08.2018 um 18:17 schrieb Chris Moller:


I just committed a minor patch to edif, fixing a relatively 
low probability bug involving a possible message queue name 
collision if you have two or more APL sessions open 
simultaneously.


https://github.com/ChrisMoller/edif

--cm

Re: [Bug-apl] edif update / ⎕IO is 0

[Chris Moller]

Aha!  That both versions, edif and edif2, fail the same was a great 
clue!  Another patch just committed...



On 20/08/18 13:03, Hans-Peter Sorge wrote:


Hello Chris,

The session blocking was my fault. Sorry for having you mislead on this.

I used

'libedif.so' ⎕fx 'edif2'

instead of

'libedif2.so' ⎕fx 'edif2'

--
However, the latest version still segfaults on
'libedif2.so' ⎕fx 'edif2'
'libedif2.so' ⎕fx 'edif2'
)off

and
'libedif.so' ⎕fx 'edif2'
'libedif.so' ⎕fx 'edif2'
)off


Best regards,
Hans-Peter


Am 20.08.2018 um 18:48 schrieb Chris Moller:

Yet another bugfix committed to https://github.com/ChrisMoller/edif.git

Mostly, what it does is detect multiple ⎕fx invocations of 
libedif2.so and short-circuits them, leaving the inotify() process 
intact and the message queue opened only once.  It also detects 
)clear and closes/unlinks the queue, kills the inotify() process, and 
closes any open editor processes.


Chris

On 20/08/18 10:38, Hans-Peter Sorge wrote:


Hello Chris,

The session stays blocked - what ever I try fiddling around.

During this fiddling I came across on other situation that makes the 
edif2 case even more interesting:


(EDIF2 is a work space having edif2 as function only)

The first session (eg. after reboot) has a double free corruption in 
either case.

1) 'libedif.so' ⎕fx 'edif2'  ..  'libedif.so' ⎕fx 'edif2' .. )off
or
2) )load a WS having function edif2 then  'libedif.so' ⎕fx 'edif2' 
.. )off



[joy@joyw520 ~]$ apl

  'libedif.so' ⎕fx 'edif2'
edif2

       )clear
CLEAR WS
  )load EDIF2
SAVED 2018-08-20 16:03:15 (GMT+2)
  'libedif.so' ⎕fx 'edif2'
edif2
  )off
double free or corruption (fasttop)
Abgebrochen (Speicherabzug geschrieben)


The following case is not expected. Yet one could argue )save does 
some cleaning.


[joy@joyw520 ~]$  apl

  'libedif.so' ⎕fx 'edif2'
edif2
  )save EDIF2
NOT SAVED: THIS WS IS CLEAR WS
  )drop EDIF2
2018-08-20  16:10:32 (GMT+2)
  )save EDIF2
2018-08-20  16:10:36 (GMT+2)
  'libedif.so' ⎕fx 'edif2'
edif2
  )off

Goodbye.
Session duration: 133.863 seconds


But now, on a naked WS, the corruption is gone  sofar I could 
not repeat a subsequent corruption until after a reboot!


[joy@joyw520 ~]$ apl

  'libedif.so' ⎕fx 'edif2'
edif2
  'libedif.so' ⎕fx 'edif2'
edif2
  )off

Goodbye.
Session duration: 6.48602 seconds

Best regards,
Hans-Peter

Am 20.08.2018 um 05:26 schrieb Chris Moller:

Hi, Hans-Peter,

That quirk where you quad-fx edif2 twice...

When edif2 starts, it fork()s a process to watch for changes in the 
working-file copies of the functions passed to emacs, and it also 
opens a POSIX message queue so the monitor process can communicate 
changes to APL.  When you quad-fx-ed edif2 twice, all that was 
duplicated--two monitor processes, another sender on the queue, and 
more signals being emitted.  I've put a patch in (but haven't 
committed it yet, and it should fix the segfault) that prevents all 
that, but my question is whether the "session blocked" bug happens 
only after the second quad-fx.  I just can't reproduce the blocking 
bug here, so I'm looking desperately for some non-obvious cause.


Thanks,
Chris

On 08/18/18 15:29, Hans-Peter Sorge wrote:


Hello Chris,

I have just one process running.

I recompiled and reinstalled edif to make sure it's the most 
recent version.


During editing with emacs:

session is blocked, then in APL session

Ctrl C
fg

'some data' ENTER  - no response

in emacs: save

in APL session:
   'some data' replayed
'some data' response

-

There is on other quirk too:


  'libedif.so' ⎕fx 'edif2'
edif2
  'libedif.so' ⎕fx 'edif2'
edif2
  )off
double free or corruption (fasttop)
Abgebrochen (Speicherabzug geschrieben) [segmentation fault]

Best regards,
Hans-Peter


Am 18.08.2018 um 02:39 schrieb Chris Moller:


I can't make it fail, but I'll look closer in the morning.

Is there any chance you have multiple APL processes running 
concurrently? Apparently, that causes problems I hadn't caught 
before.



Chris


On 17/08/18 17:14, Hans-Peter Sorge wrote:


Hello Chris,

edif2 blocks the apl session again.

edif: latest git.

apl:  1069M

Best Regards,

Hans-Peter


Am 16.08.2018 um 21:31 schrieb Chris Moller:


Not that I expected otherwise, but edif and edif2 still work as 
expected.


cm


On 16/08/18 15:14, Juergen Sauermann wrote:

Hi Hans-Peter,

thanks, hopefully fixed in *SVN 1069*.

Best Regards,
/// Jürgen


On 08/16/2018 07:29 PM, Hans-Peter Sorge wrote:


Hello,

The ⎕

Re: [Bug-apl] edif update / ⎕IO is 0

[Chris Moller]

Hi, Hans-Peter,

Something occurred to me last night...

When edif2 starts, it fork()s but instead of exec()ing it just goes into 
an inotify() read loop,  That leaves two APL processes running and when 
they're killed they both call the edif2 close_fun().  Among other 
things, close_fun() frees various bits of malloc()ed space and the 
double-free bug occurred when one or more of those spaces was freed 
twice.  (At least, I think that's what was happening...)  My last patch 
was to put in a test in before free()ing, but it occurred to me that the 
test&free stuff isn't atomic so there's a small but non-zero race 
window.  To deal with that, I just put in another that patch that adds a 
process-shared mutex to make the tests/frees effectively atomic.  (It 
would have been more straight forward to use pthread_create() for the 
inotify() loop, but I didn't think of it...)


No urgency, but if you want to try the patch in your environment, that 
would be great.  It works on my machines, but obviously that's no guarantee.


Thanks,
Chris

(Now maybe I can get a good night's sleep...)


On 20/08/18 17:58, Hans-Peter Sorge wrote:


YES - Thank You -

I'll have a good night sleep now:-)

Peter

Re: [Bug-apl] edif update / ⎕IO is 0

[Chris Moller]

Yeah, I've noticed that APL gets unhappy when stdout/stderr interferes 
with its pty.  I tried to pull down a trial version of slickedit just to 
see what was going on, but stopped when it asked me for a credit card on 
which to charge 300USD, so I'm only guessing that the output you're 
seeing is stdout or stderr.   I did a little experiment with a dummy 
"editor"  (actually hello.c) just to see what happens when you dump a 
lot of stuff to stderr, but that didn't cause any memory issues even 
when I ran under valgrind.  Something I can try would be to 
close(STDERR_FILENO),and maybe close(STDOUT_FILENO) before 
exec()ing--any  editor edif2 can use will almost certainly use GTK+, Qt, 
or something other than standard IO.  (I'd use the axis form, like 
edif2[1] would suppress stderr, or something similar.  The "corrupted 
double-linked list" message comes from malloc, so I'm guessing 
unallocated memory is being stepped on, but valgrind didn't catch any of 
that so I'm not sure what's causing it.


I'll look into the inotify stuff.

Chris



On 08/22/18 16:15, Hans-Peter Sorge wrote:

Hi Chris,

it' a stubborn case (the latest version).

I have an other case that fails (vs is script starting slickedit) :

 apl ... session:

   'libedif2.so' ⎕fx 'edif2'
edif2
   'vs' edif2 ''
   /var/run/user/2000/21616/.apl ### output from scrip vs

### output from slickedit ->

/opt/slickedit-pro2015/bin/vs_exe -sc /home/joy/.slickedit -sr
/home/joy/.slickedit /var/run/user/2000/21616/.apl    ### slickedit

SlickEdit: An instance of SlickEdit is already being displayed on this X
server. The existing instance is being activated.

If you want to bring up a new copy of SlickEdit, use +new option.

You can turn off this message by setting
VSLICKXNOPLUSNEWMSG=1

### output from slickedit -<


### this is intermittent. might happen after several editor calls

   'vs' edif2 ''
corrupted double-linked list
Abgebrochen (Speicherabzug geschrieben)

### session end


The message sent from slickedit seems to corrupt the memory.

The problem happened in previous version too (w/o pthread_mutex_..)

Trivial feature request

[Chris Moller]

Hi, Jürgen,

A really minor request:

Index: src/main.cc
===
--- src/main.cc (revision 1210)
+++ src/main.cc (working copy)
@@ -425,6 +425,7 @@
    CERR << "executing --LX '" << lx << "'" << endl;

 Command::process_line(lx);
+   if (uprefs.auto_OFF) Command::cmd_OFF(0);
   }

    // maybe )LOAD the CONTINUE or SETUP workspace. Do that unless the user


What this does, obviously, is allow command-line one-liners like, for 
example:


   apl --OFF -s --LX "((4 5 6)+(7 8 9))÷2"

Without the patch, apl just goes into accepting-input mode; with it, apl 
can be used, for example, to evaluate expressions in scripts:


   VAL=`apl --OFF -s --LX "((4 5 6)+(7 8 9))÷2"`

Thanks,
Chris Moller

Re: Trivial feature request

[Chris Moller]

No, actually, I hadn't meant that, but I certainly don't object.

On 01/01/2020 21:39, Blake McBride wrote:

I hope you mean:

Index: src/main.cc
===
--- src/main.cc (revision 1210)
+++ src/main.cc (working copy)
@@ -425,6 +425,7 @@
CERR << "executing --LX '" << lx << "'" << endl;

Command::process_line(lx);
+ if (uprefs.auto_OFF)
+         Command::cmd_OFF(0);
}


(Putting a newline between an "if" condition and the statement means 
you can put a breakpoint on the condition.)


Thanks.

Blake


On Wed, Jan 1, 2020 at 8:33 PM Chris Moller <mailto:mol...@mollerware.com>> wrote:


Hi, Jürgen,

A really minor request:

Index: src/main.cc
===
--- src/main.cc (revision 1210)
+++ src/main.cc (working copy)
@@ -425,6 +425,7 @@
    CERR << "executing --LX '" << lx << "'" << endl;

 Command::process_line(lx);
+   if (uprefs.auto_OFF) Command::cmd_OFF(0);
   }

    // maybe )LOAD the CONTINUE or SETUP workspace. Do that unless
the user


What this does, obviously, is allow command-line one-liners like,
for example:

apl --OFF -s --LX "((4 5 6)+(7 8 9))÷2"

Without the patch, apl just goes into accepting-input mode; with
it, apl can be used, for example, to evaluate expressions in scripts:

VAL=`apl --OFF -s --LX "((4 5 6)+(7 8 9))÷2"`

Thanks,
Chris Moller

Re: Trivial feature request

[Chris Moller]

Would it be worthwhile having --eval imply --noColor?  The most common 
use of --eval, I suspect, will just want the numerical result.


Chris



On 03/01/2020 14:21, Dr. Jürgen Sauermann wrote:

Hi Chris,

I decided to implement the requested feature differently. In order to
reduce the number of command line options needed to achieve
the desired effect, I have added a new command line option *--eval*
which can be used like this:

*apl --eval "((4 5 6)+(7 8 9))÷2" **
**5.5 6.5 7.5**
*
Keep in mind that the shell processes the line before apl
gets it, so the quotes above are removed etc. To get the
quotes into apl they need to be escaped according to the
shell's rules.

*SVN 1215*.

Best regards,
Jürgen


On 1/2/20 3:33 AM, Chris Moller wrote:

Hi, Jürgen,

A really minor request:

Index: src/main.cc
===
--- src/main.cc (revision 1210)
+++ src/main.cc (working copy)
@@ -425,6 +425,7 @@
    CERR << "executing --LX '" << lx << "'" << endl;

 Command::process_line(lx);
+   if (uprefs.auto_OFF) Command::cmd_OFF(0);
   }

    // maybe )LOAD the CONTINUE or SETUP workspace. Do that unless 
the user



What this does, obviously, is allow command-line one-liners like, for 
example:


apl --OFF -s --LX "((4 5 6)+(7 8 9))÷2"

Without the patch, apl just goes into accepting-input mode; with it, 
apl can be used, for example, to evaluate expressions in scripts:


VAL=`apl --OFF -s --LX "((4 5 6)+(7 8 9))÷2"`

Thanks,
Chris Moller

Re: Trivial feature request

[Chris Moller]

Excellent!

Thanks,
Chris

On 05/01/2020 11:35, Dr. Jürgen Sauermann wrote:

Hi Chris,

yes, fixed in *SVN 1220*.

Best Regards,
Jürgen


On 1/5/20 4:09 PM, Chris Moller wrote:
Would it be worthwhile having --eval imply --noColor?  The most 
common use of --eval, I suspect, will just want the numerical result.


Chris

Probably minor bug

[Chris Moller]

Shape.hh: In member function 'Shape Shape::insert_axis(Axis, ShapeItem) 
const':
Shape.hh:69:46: error: ''target_mem_ref' not supported by 
dump_expr' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]

   69 |  loop(r, MAX_RANK)   rho[r] = other.rho[r];
  |                   ~~~^

Just to finish the build, I patched around the bug by editing out the 
Wall and the Werror in the Makefile, so:


[moller@hpbox]~tinkering/gnuapl/trunk% apl -v 10:47:53
BUILDTAG:
-
    Project:    GNU APL
    Version / SVN:  1.8 / 1210
    Build Date: 2019-12-19 17:09:01 UTC
    Build OS:   Linux 4.19.3-200.fc28.x86_64 x86_64
    config.status: 
'PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib64/pkgconfig:/usr/lib/pkgconfig'

    Archive SVN:    1161

[moller@hpbox]~tinkering/gnuapl/trunk% gcc --version 10:49:35
gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)

[moller@hpbox]~tinkering/gnuapl/trunk% cat /etc/redhat-release 10:51:45
Fedora release 32 (Thirty Two)

[moller@hpbox]~tinkering/gnuapl/trunk% uname -a 10:52:29
Linux hpbox 5.6.19-300.fc32.x86_64 #1 SMP Wed Jun 17 16:10:48 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux

Re: Probably minor bug

[Chris Moller]

Sorry, I missed your README.  But a good number of years ago I was in 
the compiler group for Red Hat and, if I haven't rusted out entirely, 
I'll take a look at the bug.  No guarantees...


Chris

On 2020-06-27 12:16, Dr. Jürgen Sauermann wrote:

Hi Chris,

this warning is haunting us for quite a while now.

I have written a *README-11-bogus-compiler-warnings* with work-arounds.

Unfortunately the loop below is not entirely bogus (what happens is 
that for some r
the uninitialized value *other.rho[r] *is being copied to the 
never-used value *rho[r]*).


Unfortunately the obvious fix for the warning has shown to cause 
significant perfomance
impacts because it prevents loop unrolling (and there was a separate 
trouble report

concerning that performance drop on bug-apl).

At that time I filed a gcc trouble report:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905

asking to fix this, but I am afraid that this may take some time.
My bug report was merged into a meta-bug which is open since 2005:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639

Best Regards,
Jürgen


On 6/27/20 5:01 PM, Chris Moller wrote:
Shape.hh: In member function 'Shape Shape::insert_axis(Axis, 
ShapeItem) const':
Shape.hh:69:46: error: ''target_mem_ref' not supported by 
dump_expr' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]

   69 |  loop(r, MAX_RANK)   rho[r] = other.rho[r];
  | ~~~^

Just to finish the build, I patched around the bug by editing out the 
Wall and the Werror in the Makefile, so:


[moller@hpbox]~tinkering/gnuapl/trunk% apl -v 10:47:53
BUILDTAG:
-
    Project:    GNU APL
    Version / SVN:  1.8 / 1210
    Build Date: 2019-12-19 17:09:01 UTC
    Build OS:   Linux 4.19.3-200.fc28.x86_64 x86_64
    config.status: 
'PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib64/pkgconfig:/usr/lib/pkgconfig'

    Archive SVN:    1161

[moller@hpbox]~tinkering/gnuapl/trunk% gcc --version 10:49:35
gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)

[moller@hpbox]~tinkering/gnuapl/trunk% cat /etc/redhat-release 10:51:45
Fedora release 32 (Thirty Two)

[moller@hpbox]~tinkering/gnuapl/trunk% uname -a 10:52:29
Linux hpbox 5.6.19-300.fc32.x86_64 #1 SMP Wed Jun 17 16:10:48 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

aplwrap

[Chris Moller]

I haven't any if idea if anyone is still using the aplwrap thing David 
Lamkins and I hacked together a few years ago, but I just updated it, 
which mostly consisted of replacing a couple of GTK+/glib things that 
had been deprecated.   You can also set the foreground and background 
colours now, in case you want your screen(s) to be more attention-getting.


Anyway:  https://github.com/ChrisMoller/aplwrap

Chris Moller

Re: aplwrap

[Chris Moller]

Try running

./autogen.sh

from the top level aplwrap directory and then re-run

./configure

Most likely, you have a different version of automake installed and 
running autogen.sh will rebuild the ./configure file to match your system.


HTH,

Chris

On 2020-06-28 13:36, Blake McBride wrote:

Hi Chris,

I'd like to try aplwrap on my LinuxMint 19.3 system but I get:

$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... gcc3
checking whether to enable maintainer-specific portions of 
Makefiles... yes

checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for GTK... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
$ make
 cd . && /bin/bash /home/blake/Backup/aplwrap.git/missing 
automake-1.16 --foreign
/home/blake/Backup/aplwrap.git/missing: line 81: automake-1.16: 
command not found

WARNING: 'automake-1.16' is missing on your system.
         You should only need it if you modified 'Makefile.am' or
         'configure.ac <http://configure.ac>' or m4 files included by 
'configure.ac <http://configure.ac>'.

         The 'automake' program is part of the GNU Automake package:
         <https://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <https://www.gnu.org/software/autoconf>
         <https://www.gnu.org/software/m4/>
         <https://www.perl.org/>
Makefile:338: recipe for target 'Makefile.in' failed
make: *** [Makefile.in] Error 1


I didn't modify any files - and I have automake 1.15.1 installed (what 
comes with this version of the OS).


Thanks!

Blake McBride


On Sun, Jun 28, 2020 at 10:03 AM Chris Moller <mailto:mol...@mollerware.com>> wrote:


I haven't any if idea if anyone is still using the aplwrap thing
David Lamkins and I hacked together a few years ago, but I just
updated it, which mostly consisted of replacing a couple of
GTK+/glib things that had been deprecated.   You can also set the
foreground and background colours now, in case you want your
screen(s) to be more attention-getting.

Anyway: https://github.com/ChrisMoller/aplwrap

Chris Moller

Re: aplwrap

[Chris Moller]

aplwrap needs to have the GNU APL source around to get stuff out of 
Avec.hh.  Normally, it gets the location of that directory by running


apl --show_src_dir

and if that doesn't work for whatever reason, it can't build.  A long 
time ago, I had a ./configure option "--with-apl-source-dir" to manually 
set that, but the option seems to have vanished.  I'll stick it back in, 
but a quick work-around would be to manually set the path at line 7 of 
./configure.ac


On 2020-06-28 14:31, Blake McBride wrote:

$ ./autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac <http://configure.ac>: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac <http://configure.ac>: tracing
autoreconf: configure.ac <http://configure.ac>: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
autoreconf: Leaving directory `.'
$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking whether to enable maintainer-specific portions of 
Makefiles... yes

checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for GTK... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
$ make
make  all-recursive
make[1]: Entering directory '/home/blake/Backup/aplwrap.git'
Making all in src
make[2]: Entering directory '/home/blake/Backup/aplwrap.git/src'
./buildinfo > build.h-new
diff build.h build.h-new 2>/dev/null || mv build.h-new build.h
rm -f build.h-new
make  all-am
make[3]: Entering directory '/home/blake/Backup/aplwrap.git/src'
gcc -DHAVE_CONFIG_H -I. -I.. 
 -DMANUALS_PATH=\"/usr/local/share/doc/aplwrap\"  -std=c99 -Wall 
-Werror -pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo 
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo 
-I/usr/include/pixman-1 -I/usr/include/freetype2 
-I/usr/include/libpng16 -I/usr/include/freetype2 
-I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/libpng16 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/home/blake/Backup/apl/src  -g -O2 -MT aplwrap-aplwrap.o -MD -MP -MF 
.deps/aplwrap-aplwrap.Tpo -c -o aplwrap-aplwrap.o `test -f 'aplwrap.c' 
|| echo './'`aplwrap.c

In file included from aplwrap.c:11:0:
Avec.h:32:10: fatal error: Avec.def: No such file or directory
 #include 
          ^~
compilation terminated.
Makefile:396: recipe for target 'aplwrap-aplwrap.o' failed
make[3]: *** [aplwrap-aplwrap.o] Error 1
make[3]: Leaving directory '/home/blake/Backup/aplwrap.git/src'
Makefile:281: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/blake/Backup/aplwrap.git/src'
Makefile:434: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/blake/Backup/aplwrap.git'
Makefile:333: recipe for target 'all' failed
make: *** [all] Error 2

On Sun, Jun 28, 2020 at 1:20 PM Chris Moller <mailto:mol...@mollerware.com>> wrote:


Try running

./autogen.sh

from the top level aplwrap directory and then re-run

./configure

Most likely, you have a different version of automake installed
and running autogen.sh will rebuild the ./configure file to match
your system.

HTH,

Chris

On 2020-06-28 13:36, Blake McBride wrote:

Hi Chris,

I'd like to try aplwrap on my LinuxMint 19.3 system but I get:

$ ./configure
checking for a BSD-compatible

Re: aplwrap

[Chris Moller]

PS:  You have to rerun ./autogen.sh after patching configure.ac

On 2020-06-28 14:53, Chris Moller wrote:
aplwrap needs to have the GNU APL source around to get stuff out of 
Avec.hh.  Normally, it gets the location of that directory by running


apl --show_src_dir

and if that doesn't work for whatever reason, it can't build.  A long 
time ago, I had a ./configure option "--with-apl-source-dir" to 
manually set that, but the option seems to have vanished.  I'll stick 
it back in, but a quick work-around would be to manually set the path 
at line 7 of ./configure.ac