[Bug-apl] Compilation failure

[David B. Lamkins]

Updated to revision 1018.

Output of clang++ -v:
clang version 4.0.1 (tags/RELEASE_401/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/7
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/7
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

The failed compilation step:

clang++ -DHAVE_CONFIG_H -I. -I..-Wall -I sql -Wold-style-cast -Werror 
-I/usr/include -I/usr/i
nclude   -g -O2 -MT apl-Quad_FFT.o -MD -MP -MF .deps/apl-Quad_FFT.Tpo -c -o 
apl-Quad_FFT.o `test
-f 'Quad_FFT.cc' || echo './'`Quad_FFT.cc
Quad_FFT.cc:80:9: error: 'delete' applied to a pointer that was allocated with 
'new[]'; did you m
ean 'delete[]'? [-Werror,-Wmismatched-new-delete]
delete wp;
^
  []
Quad_FFT.cc:71:23: note: allocated with 'new[]' here
double * wp = new double[N];
  ^
Quad_FFT.cc:224:9: error: 'delete' applied to a pointer that was allocated with 
'new[]'; did you
mean 'delete[]'? [-Werror,-Wmismatched-new-delete]
delete wp;
^
  []
Quad_FFT.cc:210:23: note: allocated with 'new[]' here
double * wp = new double[N];
  ^
2 errors generated.

-- 
Whoever has lived long enough to find out what life is, knows how deep a debt
of gratitude we owe to Adam, the first great benefactor of our race.  He
brought death into the world.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"

Re: [Bug-apl] Improved contribution workflow

[David B. Lamkins]

On Wed, Sep 27, 2017 at 12:00:08PM -0400, bug-apl-requ...@gnu.org wrote:
> From: Juergen Sauermann 
> To: Elias Mårtenson , "bug-apl@gnu.org"
>  
> Subject: Re: [Bug-apl] Improved contribution workflow

[... snip ...]
> As to Mercurial and git, I am really not a fan of them. Mercurial is kind of
> bearable because you can use it from SVN.
> But the way in which people work on github is, IMHO, horrible, even though 
> they
> seem to be successful. This is probably
> due to my own lack of knowledge about git, but what I have seen so far is not
> motivating me to increase that knowledge.

I can certainly appreciate the sentiment. I'd like to share my own experience 
as a git user, FWIW.

Until three years ago I had been a strong proponent of SVN. I understood as 
much of the workflow as I needed. Really the only downside of SVN, for me, was 
having to occasionally ping someone who had locked a needed file for too long.

Then I joined an R&D outfit that uses git on the engineering side. (The 
business folks use SVN.) I have to say that my early experiences with git were 
unpleasant, mainly due to the *huge* "surface area" of the toolkit and the lack 
of a (IMO, at least) well-written concept guide. Mind you, there's *tons* of 
"how to" posts and articles, some of which have been useful. But the general 
approach is "here's how I did this" with little explanation beyond the commands 
and arguments necessary to solve the problem...

AIUI, one of the reasons for the depth of git is that it supports a plethora of 
workflows. There are other factors, of course: the fact that git is a 
distributed system and offers a bunch of "plumbing" for custom system 
integration probably contributes to the bloat. The question you need to answer 
-- and I don't think there's a one-size-fits-all perspective -- is how you feel 
about the tradeoff between git's complexity and its capabilities.

Again, AIUI: It's quite likely that if you're working on a project having many 
contributors, then the project will have an established git workflow with 
guidelines (or even requirements) as tohow to do common tasks. The most 
difficult situation, I think, is to learn git on your own as a sole (or 
principal) contributor, with only the man pages and the afforementioned 
resources for deciphering git.

GitHub takes away some of the complexity at the expense of hiding a lot of the 
more clever bits of git. (I personally am not a fan of web UIs for technical 
tasks.) The downside is that folks who learn only the GitHub (or GitLab, or 
...) interface tend to invent Rube Goldberg-like workflows or to completely 
ignore, say, the notion of "upstream". Take a peek at Arduino-related repos for 
a great example of this: I once had to (attempt to) track down the source of 
some GPS code that originated for an Arduino shield; there were multiple 
upstreams, each of which had tens or hundreds of forks. The code that I was 
trying to identify, though, no longer existed. But these are all git repos, no 
matter how many there are, right? Yeah, right. Unfortunately, none of the "ease 
of use" of the web UI does much (if anything) to inform its users regarding 
useful workflows. It turned out that the owner of the "ancestral" upstream 
wiped and rewrote the repo for every release; the early release that I needed 
to consult didn't exist anywhere...

Personally, I'd advise taking at least a peek at git if the opportunity 
presents itself. Regardless of whether you want to adopt git, you will 
encounter useful projects that do present their assets as a git repo; you'd be 
well-served to know some basic commands such as switching branches and viewing 
the commit log. But I wouln't suggest jumping ship from a system with which 
you're already comfortable.

(That said, I *do* have a recommendation for a GNU Autotools replacement: Meson 
and Ninja. I've begun to adopt that build toolchain for my personal and work 
projects, and am quite pleased with what I've seen so far. For an example of a 
small project built using Meson and Ninja, see the xs shell that I maintain: 
.)

-- 
"The chain which can be yanked is not the eternal chain."
-- G. Fitch

Re: [Bug-apl] apl -v?

[David B. Lamkins]

Thank you.


On Sun, Aug 20, 2017 at 11:30:40AM +0200, Juergen Sauermann wrote:
> Hi David,
> 
> yes, thanks. Should be fixed in SVN 1000.
> 
> /// Jörgen
> 
> 
> On 08/19/2017 06:50 PM, David B. Lamkins wrote:
> 
> Just wondering...
> 
> 
> 
> 
> When I do
> 
> $ apl -v
> 
> the
> 
> config.status:
> 
> line has always shown
> 
> unknown configure options .
> 
> 
> 
> 
> Is this normal? Should it show the options I've passed to ./configure?
> 
> 
> 

-- 
"BTW, does Jesus know you flame?"
-- Diane Holt, dia...@binky.uucp, to Ed Carp

[Bug-apl] apl -v?

[David B. Lamkins]

Just wondering...




When I do

$ apl -v

the

config.status:

line has always shown

unknown configure options .




Is this normal? Should it show the options I've passed to ./configure?

-- 
TRANSACTION CANCELLED - FARECARD RETURNED

[Bug-apl] SVN 991 compilation error

[David B. Lamkins]

Again, this is with:

./configure RATIONAL_NUMBERS_WANTED=yes PERFORMANCE_COUNTERS_WANTED=yes 
CORE_COUNT_WANTED=-3



clang++ -DHAVE_CONFIG_H -I. -I..-Wall -I sql -Wold-style-cast -Werror 
-I/usr/include -I/usr/include   -g -O2 -MT apl-Value.o -MD -MP -MF 
.deps/apl-Value.Tpo -c -o apl-Value.o `test -f 'Value.cc' || echo './'`Value.cc
Value.cc:502:45: error: 'reinterpret_cast' to class 'Value *' from its base at 
non-zero offset 'DynamicObject *' behaves differently from 'static_cast' 
[-Werror,-Wreinterpret-base-class]
  CERR << " Value: " << reinterpret_cast(obj)
^~
Value.cc:502:45: note: use 'static_cast' to adjust the pointer correctly while 
downcasting
  CERR << " Value: " << reinterpret_cast(obj)
^~~~
static_cast
Value.cc:570:45: error: 'reinterpret_cast' to class 'Value *' from its base at 
non-zero offset 'DynamicObject *' behaves differently from 'static_cast' 
[-Werror,-Wreinterpret-base-class]
  CERR << " Value: " << reinterpret_cast(obj)
^~
Value.cc:570:45: note: use 'static_cast' to adjust the pointer correctly while 
downcasting
  CERR << " Value: " << reinterpret_cast(obj)
^~~~
static_cast
2 errors generated.

[Bug-apl] old-style cast: SVN 988

[David B. Lamkins]

clang++ -DHAVE_CONFIG_H -I. -I..-Wall -I sql -Wold-style-cast -Werror 
-I/usr/include -
 -f 'main.cc' || echo './'`main.cc
main.cc:84:26: error: use of old-style cast [-Werror,-Wold-style-cast]
   CERR << "thread: " << (const void *)pthread_self() << endl;


This is with the same ./configure flags as my previous report:

./configure RATIONAL_NUMBERS_WANTED=yes PERFORMANCE_COUNTERS_WANTED=yes 
CORE_COUNT_WANTED=-3

Re: [Bug-apl] SVN 984 changes

[David B. Lamkins]

With the following configure options and building after a make clean, I see a 
lot of warnings about old-style casts:

./configure RATIONAL_NUMBERS_WANTED=yes PERFORMANCE_COUNTERS_WANTED=yes 
CORE_COUNT_WANTED=-3

On Sun, Aug 06, 2017 at 01:44:58PM +0200, Juergen Sauermann wrote:
> Hi,
> 
> I would like to inform you about 2 changes that I made in SVN 984.
> 
> 1. Use of C++ casts instead of C casts
> I have replaced every old-style C cast by either a C++ cast (static_cast<>(),
> reinterpret_cast<>(),
> or const_cast<>()).
> The reason for this change is to keep up with the changes in the C++ language.
> Also, the Makefiles were changed to not allow C casts any longer.
> 
> 2. APL_Float as class.
> I have change the code so that one can use a class  APL_Float instead of the
> previous typedef double APL_FLoat. An example class is provided in file
> APL_Float_as_class.hh and the decision if a typedef or a class shall be used
> is made in APL_types.hh via  #define APL_Float_is_class 0 or 1. This change
> simplifies, for example, the introduction of libraries for higher precision
> arithmetic.
> 
> I hope all this still compiles on your machines. Make clean and a new ./
> configure is
> required after SVN up.
> 
> Best Regards,
> Jürgen Sauermann
> 

-- 
Any fool can paint a picture, but it takes a wise person to be able to sell it.

Re: [Bug-apl] )HELP ...

[David B. Lamkins]

On Tue, Apr 18, 2017 at 10:49:28AM +0800, Elias Mårtenson wrote:
> Hello David,
> 
> Having a standardised format is what makes this so useful. The whole point of
> this is to make sure that everybody uses the same convention so third-party
> tools can integrate with the system. If everybody “adopts the convention they
> prefer”, as you suggest, such a system would not be very useful. With regards
> to the format, I think you are exaggerating the complexity a bit. It's really
> only two rules:
> 
>  1. The documentation block is prefixed by ⍝⍝
>  2. The first line is the short summary.
> 
> Using a special format to describe documentation is very important. The reason
> is that you absolutely don't want to display “normal” comments as 
> documentation
> . Using ⍝⍝ tells the system that the person who wrote the documentation
> intended this to be documentation, and not just merely a plain comment.

Is "all the leading comment lines until the first non-comment line" that 
complex? I'm just trying to be precise about what's a "header comment" and 
what's not.

Given the double-lamp convention, what's the expected behavior if I drop a 
double-lamp comment in the middle of my APL code? Is that still part of the 
header comment?

The problem with adopting a convention from an existing tool is that it locks 
everyone into using that tool, whether it's their preference to use that tool 
or not. Because GNU APL can deal with program text stored on a Unicode file, 
any tool can process that file. I think it's presumptive to declare any 
particular markup format as "standard". Let the user decide.

> The Emacs mode dynamically pops up this documentation string whenever the
> cursor is on top of a function name, and you really don't want arbitrary
> comments to be displayed there.

What's an "arbitrary" comment? In my proposal, the comments at the top of the 
function are the header comment. Every comment after the first line of APL code 
or empty line is not part of the header comment.

The only thing the double-lamp convention does is to let you use grep rather 
than a simple parsert that can identify the start of a user-defined function 
and a comment-only line. That's really not difficult. And of course the "grep" 
approach opens up questions like the one I raised above about "header" comments 
tucked into the middle of a function.

> This system of having dedicated documentation strings is very well established
> in multiple languages, for example:
> 
>   • Java (uses /**)
>   • C++ (doxygen, uses /**)
>   • Python (uses triple-quote """like this""". An empty string conveniently is
> a no-op in Python)
>   • Common Lisp ("a plain string" as the first form, like Python this ends up
> being a no-op)
>   • Emacs Lisp (same syntax as Common Lisp, the documentation is tightly
> integrated in the help system)
> 
> As you can see, this is nothing new, and has proven to be incredibly useful in
> multiple languages.

Let's not conflate the importance of documentation with the syntax of the 
comments. All I'm arguing for is to not impose a special syntax on "header" 
comments. A header comment is simply the comments at the top of the function. 
Period. Doesn't need to be any more complex than that.

-- 
Thieves respect property; they merely wish the property to become
their property that they may more perfectly respect it.
-- G.K. Chesterton, "The Man Who Was Thursday"

[Bug-apl] )HELP ...

[David B. Lamkins]

Thank you to everyone who contributed to the recent extension to )HELP. This'll 
be far more convenient that flipping between APL and two PDF references.

Regarding help for user-defined functions, I'd like to offer a suggestion:

I've noticed quite a bit of talk about adopting syntax and/or semantics (e.g. 
tags) from the conventions used by other languages and documentation extractors.

I'd like to suggest that it's in everyone's interest for the format of header 
comments to remain as neutral as possible, leaving open the possibility for 
everyone to adopt (or invent) whatever convention they prefer.

The way I see it, the only real concern should be how to delimit the end of a 
header comment. I'd like to suggest that every lamp line starting with the 
first line of the function is a header comment regardless of indentation or 
markup. The end of the header comment is simply the first non-lamp line; this 
could be either a line of APL code or an empty line (and I prefer visual 
equivalence, so a line of only whitespace would be considered empty for this 
purpose). If the first line of the function is visually empty or a line of APL 
code, then the function has no header comment.

Again, thanks!

David

-- 
I've found my niche.  If you're wondering why I'm not there, there was
this little hole in the bottom ...
-- John Croll

[Bug-apl] quad-SQL documentation

[David B. Lamkins]

I thought it'd be nice to have quad-SQL documented in the info pages, so I 
copied doc strings from the SQL workspace. Patch attached.
Index: doc/apl.texi
===
--- doc/apl.texi(revision 846)
+++ doc/apl.texi(working copy)
@@ -702,6 +702,7 @@
 * Section 3.14::   ⎕SI - State Indicator
 * Section 3.15::   ⎕DLX: Knuth's Dancing Links Algorithm
 * Section 3.16::   History and TAB completion
+* Section 3.17::   ⎕SQL - SQL Database Interface
 @end menu
 
 There are a few possibly useful features in GNU APL:
@@ -1906,6 +1907,127 @@
 2d. Input starting with letters, ∆, or ⍙ is completed as a user defined
 function or variable name.
 
+
+@nodeSection 3.17
+@section ⎕SQL - SQL Database Interface
+
+As of GNU APL 1.6, the native function SQL has been replaced by the
+system function ⎕SQL, described below.
+
+@verbatim 
+  ⎕sql[0]''
+Available function numbers:
+type  ⎕SQL[1] file  - open a database file, return reference ID for it
+  ⎕SQL[2] ref   - close database
+query ⎕SQL[3,db] params - send SQL query
+query ⎕SQL[4,db] params - send SQL update
+  ⎕SQL[5] ref   - begin a transaction
+  ⎕SQL[6] ref   - commit current transaction
+  ⎕SQL[7] ref   - rollback current transaction
+  ⎕SQL[8] ref   - list tables
+ref   ⎕SQL[9] table - list columns for table
+@end verbatim
+
+@verbatim
+  type  ⎕SQL[1] file
+@end verbatim
+
+Connect to database of type L using connection arguments R.
+
+L must be a string indicating the database type. Current supported
+values are 'postgresql' and 'sqlite'.
+
+R is the connection parameters which depends on the type of
+database:
+
+  - For type≡'sqlite': the argument is string pointing to the
+database file.
+
+  - For type≡'postgresql', the argument is a standard connect
+string as described in the PostgreSQL documentation.
+
+This function returns a database handle that should be used when
+using other SQL functions. This value should be seen as an opaque
+handle. It is, however, guaranteed that the handle is a scalar
+value.
+
+@verbatim
+  ⎕SQL[2] ref
+@end verbatim
+
+Disconnect from database R.
+
+R is the database handle that should be disconnected. After this
+function has been called, no further operations are to be performed
+on this handle. Future calls to SQL∆Connect may reuse previously
+disconnected handles.
+
+@verbatim
+  query ⎕SQL[3,db] params
+@end verbatim
+
+Execute a select statement and return the result table.
+
+The axis parameter indicates the database handle.
+
+L is a select statement to be executed. Positional parameters can
+be supplied by specifying a question mark "?" in the statemement.
+
+R is an array containing the values for the positional parameters.
+If the array is of rank 2, the statement will be executed multiple
+times with each row being the values for each call.
+
+The return value is a rank-2 array representing the result of the
+select statement. Null values are returned as ⍬ and empty strings
+are returned as ''.
+
+@verbatim
+  query ⎕SQL[4,db] params
+@end verbatim
+
+Execute an SQL statement that does not return a result.
+
+This function is identical to SQL∆Select with the exception that it
+is used on statements which do not return a result table.
+
+@verbatim
+  ⎕SQL[5] ref
+@end verbatim
+
+Begin a transaction.
+
+@verbatim
+  ⎕SQL[6] ref
+@end verbatim
+
+Commit a transaction.
+
+@verbatim
+  ⎕SQL[7] ref
+@end verbatim
+
+Rolls back the current transaction.
+
+@verbatim
+  ⎕SQL[8] ref
+@end verbatim
+
+Return an array containing the name of all tables.
+
+@verbatim
+  ref   ⎕SQL[9] table
+@end verbatim
+
+Return an array containing information about the columns in the
+given table. Currently, the column layout is as follows:
+
+  Name
+  Type
+
+More columns containing extra information may be added in a future
+release.
+
+
 @c 
 @node Chapter 4
 @chapter Limitations and Missing Features

Re: [Bug-apl] SVN 839 doesn't compile

[David B. Lamkins]

There's one remaining when compiling 843 under clang. The attached patch fixes 
that as well as the remaining error reported by gcc.



On Tue, Jan 10, 2017 at 03:54:36PM -0800, David Lamkins wrote:
> Worth noting: There are now no warnings or notes when compiling under gcc 
> 6.3.1.
> 
> On Tue, Jan 10, 2017 at 3:45 PM, David Lamkins  wrote:
> > Thank you, Juergen.
> >
> > SVN 843 compiles under gcc 6.3.1.
> >
> > This is the sole remaining error when compiling with clang 3.8.0:
> >
> > clang++ -DHAVE_CONFIG_H -I. -I..-Werror -Wall -Wno-strict-aliasing
> > -Wno-deprecated-declarations -I/usr/include -I sql  -I/usr/include -I
> > sql   -g -O2 -MT apl-UserFunction_header.o -MD -MP -MF
> > .deps/apl-UserFunction_header.Tpo -c
> >  -o apl-UserFunction_header.o `test -f 'UserFunction_header.cc' ||
> > echo './'`UserFunction_header.cc
> > Tokenizer.cc:604:42: error: explicitly assigning value of variable of
> > type 'APL_Float' (aka 'double') to itself [-Werror,-Wself-assign]
> > if (!imag_need_float)   imag_flt = imag_flt;
> >  ^ 
> > Tokenizer.cc:637:45: error: explicitly assigning value of variable of
> > type 'APL_Float' (aka 'double') to itself [-Werror,-Wself-assign]
> > if (!imag_need_float)   degrees_flt = degrees_flt;
> > ~~~ ^ ~~~
> > 2 errors generated.
> >
> >
> > On Tue, Jan 10, 2017 at 11:54 AM, Juergen Sauermann
> >  wrote:
> >> Hi,
> >>
> >> I believe that I fixed most warnings, *SVN 842*.
> >>
> >> Since there were many warnings and from different sources, I might have
> >> overlooked
> >> some of them (or introduced new ones). Please keep reporting them.
> >>
> >> /// Jürgen
> >>
> >
> >
> >
> > --
> > "I think as musicians, we have more vision than we credit ourselves
> > for. We should dive into it without reserve, and take the sort of
> > risks it takes to be divisive and impactful. Things have yet to be
> > done."
> >Aaron Fowler Clark
> >
> > "Do not seek to follow in the footsteps of the masters. Seek what they 
> > sought."
> >Matsuo Basho
> >
> > "Knowledge speaks; wisdom listens."
> >Jimi Hendrix
> >
> > http://soundcloud.com/davidlamkins
> > http://reverbnation.com/lamkins
> > http://reverbnation.com/lcw
> > http://lamkins-guitar.com/
> > http://lamkins.net/
> > http://successful-lisp.com/
> 
> 
> 
> -- 
> "I think as musicians, we have more vision than we credit ourselves
> for. We should dive into it without reserve, and take the sort of
> risks it takes to be divisive and impactful. Things have yet to be
> done."
>Aaron Fowler Clark
> 
> "Do not seek to follow in the footsteps of the masters. Seek what they 
> sought."
>Matsuo Basho
> 
> "Knowledge speaks; wisdom listens."
>Jimi Hendrix
> 
> http://soundcloud.com/davidlamkins
> http://reverbnation.com/lamkins
> http://reverbnation.com/lcw
> http://lamkins-guitar.com/
> http://lamkins.net/
> http://successful-lisp.com/
Index: src/APs/AP210.cc
===
--- src/APs/AP210.cc(revision 843)
+++ src/APs/AP210.cc(working copy)
@@ -201,7 +201,7 @@
 
 delete var_D.data;
 var_D.data = new CDR_string(buffer, nb);
-delete buffer;
+delete[] buffer;
 return 0;
   }
else if (code == 'D')   // char (var size)
Index: src/Tokenizer.cc
===
--- src/Tokenizer.cc(revision 843)
+++ src/Tokenizer.cc(working copy)
@@ -601,7 +601,7 @@
 bool imag_need_float = false;
 const bool imag_valid = tokenize_real(src, imag_need_float,
   imag_flt, imag_int);
-if (!imag_need_float)   imag_flt = imag_flt;
+if (!imag_need_float)   (void)imag_flt;
 
 if (!imag_valid)
{
@@ -634,7 +634,7 @@
 bool imag_need_float = false;
 const bool imag_valid = tokenize_real(src, imag_need_float,
   degrees_flt, degrees_int);
-if (!imag_need_float)   degrees_flt = degrees_flt;
+if (!imag_need_float)   (void)degrees_flt;
 
 if (!imag_valid)
{

[Bug-apl] SVN 839 doesn't compile

[David B. Lamkins]

GNU APL SVN 839 does not compile. Tested with gcc 6.3.1 and clang 3.8.0 using 
./configure; make clean all .

Here are the compilation errors. I can post the entire make transcript if it'd 
help.

gcc
===

g++ -DHAVE_CONFIG_H -I. -I..-Werror -Wall -Wno-strict-aliasing 
-I/usr/include -I sql  -I/usr/include -I sql  -rdynamic -g -O2 -MT apl-Common.o 
-MD -MP -MF .deps/apl-Common.Tpo -c -o apl-Common.o `test -f 'Common.cc' || 
echo './'`Common.cc
Command.cc: In static member function ‘static void 
Command::lib_common(std::ostream&, const UCS_string&, int)’:
Command.cc:1022:17: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
 if (col == (col_width.size() - 1) || c == (directories.size() - 1))
 ^

g++ -DHAVE_CONFIG_H -I. -I..-Werror -Wall -Wno-strict-aliasing 
-I/usr/include -I sql  -I/usr/include -I sql  -rdynamic -g -O2 -MT 
apl-Executable.o -MD -MP -MF .deps/apl-Executable.Tpo -c -o apl-Executable.o 
`test -f 'Executable.cc' || echo './'`Executable.cc
Error.cc: In member function ‘void Error::print(std::ostream&) const’:
Error.cc:60:9: error: this ‘if’ clause does not guard... 
[-Werror=misleading-indentation]
 if (symbol_name.size())
 ^~
Error.cc:63:27: note: ...this statement, but the latter is misleadingly 
indented as if it is guarded by the ‘if’
   out << "   Thrown at:  " << throw_loc << endl
   ^~~

g++ -DHAVE_CONFIG_H -I. -I..-Werror -Wall -Wno-strict-aliasing 
-I/usr/include -I sql  -I/usr/include -I sql  -rdynamic -g -O2 -MT 
apl-FloatCell.o -MD -MP -MF .deps/apl-FloatCell.Tpo -c -o apl-FloatCell.o `test 
-f 'FloatCell.cc' || echo './'`FloatCell.cc
Executable.cc: In member function ‘UCS_string 
Executable::extract_lambda_text(Fun_signature, int) const’:
Executable.cc:691:19: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
  if (tidx >= text.size())
  ~^~
cc1plus: all warnings being treated as errors



clang
=

clang++ -DHAVE_CONFIG_H -I. -I..-Werror -Wall -Wno-strict-aliasing 
-I/usr/include -I sql  -I/usr/include -I sql   -g -O2 -MT apl-Assert.o -MD -MP 
-MF .deps/apl-Assert.Tpo -c -o apl-Assert.o `test -f 'Assert.cc' || echo 
'./'`Assert.cc
In file included from Archive.cc:41:
In file included from ./Macro.hh:24:
In file included from ./UserFunction.hh:29:
./Symbol.hh:39:1: error: 'ValueStackItem' defined as a struct here but 
previously declared as a class [-Werror,-Wmismatched-tags]
struct ValueStackItem
^
./Archive.hh:40:1: note: did you mean struct here?
class ValueStackItem;
^
struct
In file included from Assert.cc:28:
In file included from ./Workspace.hh:30:
In file included from ./Quad_RL.hh:24:
./SystemVariable.hh:82:17: error: 'NL_SystemVariable::push_label' hides 
overloaded virtual function [-Werror,-Woverloaded-virtual]
   virtual void push_label(int label) {}
^
./Symbol.hh:175:17: note: hidden overloaded virtual function 
'Symbol::push_label' declared here: type mismatch at 1st parameter 
('Function_Line' vs 'int')
   virtual void push_label(Function_Line label);

clang++ -DHAVE_CONFIG_H -I. -I..-Werror -Wall -Wno-strict-aliasing 
-I/usr/include -I sql  -I/usr/include -I sql   -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 Archive.cc:51:
In file included from ./Workspace.hh:30:
In file included from ./Quad_RL.hh:24:
./SystemVariable.hh:82:17: error: 'NL_SystemVariable::push_label' hides 
overloaded virtual function [-Werror,-Woverloaded-virtual]
   virtual void push_label(int label) {}
^
./Symbol.hh:175:17: note: hidden overloaded virtual function 
'Symbol::push_label' declared here: type mismatch at 1st parameter 
('Function_Line' vs 'int')
   virtual void push_label(Function_Line label);
^
In file included from main.cc:42:
In file included from ./Workspace.hh:30:
In file included from ./Quad_RL.hh:24:
./SystemVariable.hh:82:17: error: 'NL_SystemVariable::push_label' hides 
overloaded virtual function [-Werror,-Woverloaded-virtual]
   virtual void push_label(int label) {}
^
./Symbol.hh:175:17: note: hidden overloaded virtual function 
'Symbol::push_label' declared here: type mismatch at 1st parameter 
('Function_Line' vs 'int')
   virtual void push_label(Function_Line label);
^
1 error generated.
   ^

Re: [Bug-apl] Profile keyword flagged as invalid

[David B. Lamkins]

Thank you.

On Mon, Dec 26, 2016 at 11:01:17PM +0100, Juergen Sauermann wrote:
> Hi David,
> 
> fixed in SVN 832 (I hope). Should have been only a warning without an effect.
> 
> /// Jürgen
> 
> 
> On 12/26/2016 10:44 PM, David B. Lamkins wrote:
> 
> The recent addition to the user preferences parser causes APL to report 
> that the 'Profile' keyword is invalid.
> 
> 
> 

[Bug-apl] Profile keyword flagged as invalid

[David B. Lamkins]

The recent addition to the user preferences parser causes APL to report that 
the 'Profile' keyword is invalid.

Re: [Bug-apl] How to organize programs

[David B. Lamkins]

There are a couple of existing guidelines. If you poke around in wslib5, you'll 
see examples of both.


http://www.gnu.org/software/apl/Library-Guidelines.html

This is intended for modern APLs (i.e. those which are able to load APL 
programs as Unicode) in general; this document links to another which admits 
GNU APL extensions.

Hallmarks of this approach include separating libraries into different 
workspaces according to functionality and generality, and the inclusion of 
metadata within the APL file.


Another approach is taken by my package manager.

https://github.com/TieDyedDevil/apl-pkg/blob/master/doc/TUTORIAL.md
https://github.com/TieDyedDevil/apl-pkg/blob/master/doc/API.md

This is a more heavyweight approach, depending as it does on the mechanisms of 
the package manager.

At the moment, the package manager runs only on GNU APL. The architecture and 
design, however, will eventually accomodate any modern APL (again, defined by 
the ability to load Unicode files). In the long run, the package manager will 
be aware of versioned packages (and constraints on loading those packages) and 
will be able to pull packages across the `net.



On Mon, Dec 26, 2016 at 05:53:22PM +0100, Alexey Veretennikov wrote:
> Hi,
> 
> The question is rather silly but raised since earlier in discussion
> Jurgen mentioned what the workspaces is the outdate way to work with
> APL.
> 
> So what is the current (modern) ways supported by GNU APL would be?
> I could imagine the organization of the program the following:
> 1) set of UTF-8 text files containing functions (possibly 1 function per file)
> 2) one main script file loading these functions, setting the data
> variables and performing the execution.
> 
> In the old ways it could be the main workspace which copies necessary
> functions from other workspaces as a part of commands from ⎕LX variable
> and performing the execution.
> 
> In addition Dyalog APL provides something called SALT - Simple APL
> Library Toolkit - a way to organize APL objects as a separate files and
> manipulate them. From the documentation: "One of SALT's function, Snap ,
> also enables the construction of a directory structure corresponding to
> the namespace structure of a workspace, where each file in the structure
> contains the script of an APL object in the workspace."
> 
> 
> -- 
> Br,
> /Alexey
> 
> 

Re: [Bug-apl] ⎕FIO[1] behavior

[David B. Lamkins]

Thank you.

On Sat, Dec 24, 2016 at 05:25:54PM +0100, Juergen Sauermann wrote:
> Hi David,
> 
> thanks, fixed in SVN 827.
> 
> I believe the reason was that some ⎕FIO functions return valid positive
> integers but can also
> fail (with an also positive errno). To distinguish between errrors and integer
> results I made all errors
> negative.
> 
> I have now adapted ⎕FIO[2] to accept both positive and negative errno values.
> 
> /// Jürgen
> 
> 
> On 12/23/2016 10:05 PM, David B. Lamkins wrote:
> 
> I think that the behavior of ⎕fio[1] changed at some point. This is 
> supposed to return the value of errno (a positive value), but now returns 
> -errno, causing ⎕fio[2] ⎕fio[1] ⍬ to always return "Unknown error ...".
> 
> 
> 

[Bug-apl] ⎕FIO[1] behavior

[David B. Lamkins]

I think that the behavior of ⎕fio[1] changed at some point. This is supposed to 
return the value of errno (a positive value), but now returns -errno, causing 
⎕fio[2] ⎕fio[1] ⍬ to always return "Unknown error ...".

Re: [Bug-apl] Calling external editor from APL session

[David B. Lamkins]

No worries, Jürgen. My choice of project name is a poor representation of the 
scope of its capabilities.

On Wed, Dec 21, 2016 at 09:31:01PM +0100, Juergen Sauermann wrote:
> Hi David,
> 
> truly sorry that I forgot to mention it.
> 
> /// Jürgen
> 
> 
> On 12/21/2016 08:55 PM, David B. Lamkins wrote:
> 
> This seems like a good time to again mention my APL package manager.
> 
> [1]https://github.com/TieDyedDevil/apl-pkg
> 
> This provides, among other things:
> 
>  - a way to organize APL code,
>  - analysis tools, and
>  - editor integration.
> 
> I'll start with editor integration, since that's the current topic of 
> interest. You can edit any function that the package manager has loaded with 
> the command:
> 
>   ]pkg edit 
> 
> This opens the function in an external editor, positioning the cursor to 
> the header line of the function within the .apl file from which the function 
> was loaded.
> 
> The editor itself defaults to `vi`; this can be be changed by naming your 
> favorite editor in the package manager's configuration file. In the editor, 
> the keyboard is mapped for APL without using `loadkeys` or `xmodmap`.
> 
> The package also provides a wrapper script `awe` (for APL Workbench 
> Environment) that, among other things, establishes a proper environment to 
> support the editor. By default this is `dvtm` in the Linux console and your 
> window manager under X. The `awe` script also supports `tabbed` (an XEmbed 
> container) and `dvtm` under X.
> 
> The package manager's analysis tools include:
> 
>  - apropos (find APL functions, variables or operators by partial name)
>  - refs (list all non-local names referenced by a function)
>  - uses (list all functions that use a given user-defined function, 
> variable or operator)
>  - undefs (list names referenced but not defined)
>  - unrefs (list named defined but not referenced)
>  - locate (identify the file from which a function or operator has been 
> loaded)
>  - inspect (inspect/edit variables via navigation of their nested 
> structure)
> 
> Then there's the actual package management functionality. Simply put, a 
> package is a collection of source code in one or more .apl files. A package 
> may depend upon other packages; dependencies are loaded as needed. You may 
> program the package loader (on a per-package basis) to perform different 
> actions depending upon certain environmental queries, e.g. what's the OS?
> 
> A package's loader may shell out to do non-APL things. For example, you 
> can compile the code of a shared library to be loaded as a native function 
> using GNU APL's quad-FX extension.
> 
> All of the above is already implemented. I use the package manager to 
> develop the package manager and some other utility libraries, such as my 
> ISO-compliant component file library.
> 
> [2]https://github.com/TieDyedDevil/iso-apl-cf
> 
> In the longer run, I intend to implement versioned dependency loading and 
> the ability to load packages from the `net.
> 
> 
> 
> On Wed, Dec 21, 2016 at 01:35:36PM +0100, Juergen Sauermann wrote:
> 
> Hi Alexey,
> 
> I am myself not familiar with emacs and, as a matter of fact, I do 
> not even
> have it
> installed on my machine. I believe the most efficient way to write 
> APL programs
> these days is to edit the functions and variables offline in a 
> separate .apl
> file which
> is then run in a separate window. Like you write a C/C++ program 
> beforehand.
> compile it, and then execute it. With that approach you can use 
> whatever editor
> you prefer and you have all the functions and variables in a single 
> file and in
> a
> consistent state. It also simplifies the documentation and publishing 
> of APL
> programs lot.
> You can also check-in the .apl files into a revision control system, 
> diff them,
> and so on.
> 
> The interactive mode of APL (including function editing) has always 
> had severe
> limitations
> and I have provided it only for compatibility and for the elder APL 
> programmers
> who are used to it.
> The interactive mode was definitely an improvement over the punch 
> cards used
> when APL was invented,
> but today the capabilities of computers are very different and I 
> would not
> recommend the interactive mode
> for newcomers to APL.
> 
> 
> 
> References:
> 
> [1] https://github.com/TieDyedDevil/apl-pkg
> [2] https://github.com/TieDyedDevil/iso-apl-cf

Re: [Bug-apl] Calling external editor from APL session

[David B. Lamkins]

This seems like a good time to again mention my APL package manager.

https://github.com/TieDyedDevil/apl-pkg

This provides, among other things:

 - a way to organize APL code,
 - analysis tools, and
 - editor integration.

I'll start with editor integration, since that's the current topic of interest. 
You can edit any function that the package manager has loaded with the command:

  ]pkg edit 

This opens the function in an external editor, positioning the cursor to the 
header line of the function within the .apl file from which the function was 
loaded.

The editor itself defaults to `vi`; this can be be changed by naming your 
favorite editor in the package manager's configuration file. In the editor, the 
keyboard is mapped for APL without using `loadkeys` or `xmodmap`.

The package also provides a wrapper script `awe` (for APL Workbench 
Environment) that, among other things, establishes a proper environment to 
support the editor. By default this is `dvtm` in the Linux console and your 
window manager under X. The `awe` script also supports `tabbed` (an XEmbed 
container) and `dvtm` under X.

The package manager's analysis tools include:

 - apropos (find APL functions, variables or operators by partial name)
 - refs (list all non-local names referenced by a function)
 - uses (list all functions that use a given user-defined function, variable or 
operator)
 - undefs (list names referenced but not defined)
 - unrefs (list named defined but not referenced)
 - locate (identify the file from which a function or operator has been loaded)
 - inspect (inspect/edit variables via navigation of their nested structure)

Then there's the actual package management functionality. Simply put, a package 
is a collection of source code in one or more .apl files. A package may depend 
upon other packages; dependencies are loaded as needed. You may program the 
package loader (on a per-package basis) to perform different actions depending 
upon certain environmental queries, e.g. what's the OS?

A package's loader may shell out to do non-APL things. For example, you can 
compile the code of a shared library to be loaded as a native function using 
GNU APL's quad-FX extension.

All of the above is already implemented. I use the package manager to develop 
the package manager and some other utility libraries, such as my ISO-compliant 
component file library.

https://github.com/TieDyedDevil/iso-apl-cf

In the longer run, I intend to implement versioned dependency loading and the 
ability to load packages from the `net.



On Wed, Dec 21, 2016 at 01:35:36PM +0100, Juergen Sauermann wrote:
> Hi Alexey,
> 
> I am myself not familiar with emacs and, as a matter of fact, I do not even
> have it
> installed on my machine. I believe the most efficient way to write APL 
> programs
> these days is to edit the functions and variables offline in a separate .apl
> file which
> is then run in a separate window. Like you write a C/C++ program beforehand.
> compile it, and then execute it. With that approach you can use whatever 
> editor
> you prefer and you have all the functions and variables in a single file and 
> in
> a
> consistent state. It also simplifies the documentation and publishing of APL
> programs lot.
> You can also check-in the .apl files into a revision control system, diff 
> them,
> and so on.
> 
> The interactive mode of APL (including function editing) has always had severe
> limitations
> and I have provided it only for compatibility and for the elder APL 
> programmers
> who are used to it.
> The interactive mode was definitely an improvement over the punch cards used
> when APL was invented,
> but today the capabilities of computers are very different and I would not
> recommend the interactive mode
> for newcomers to APL.

[Bug-apl] r819 has severe performance issue

[David B. Lamkins]

Revision 819 causes *severe* performance issues for my APL Packager.

https://github.com/TieDyedDevil/apl-pkg
(Use the `percy` branch.)

$ git clone https://github.com/TieDyedDevil/apl-pkg
# cd apl-pkg
$ git branch percy
$ ./install.sh
$ awe

Normally the system comes up in a second or so; under r819 it takes tens of 
minutes to complete, during which one CPU core is pegged. (It's slow enough 
that I first thought that some altered edge condition must've caused an 
infinite loop.)

Memory usage is stable.

FWIW, this happens in the packager's boot loader, so there's not a lot of APL 
code involved.

https://github.com/TieDyedDevil/apl-pkg/blob/percy/boot/gnu-apl-linux.apl

Once past the boot loader (which took about 90 minutes on my Haswell i7 
notebook), virtually every packager operation is noticeably slow. If I had to 
guess, I'd suspect that either branching or APL function calls are eating a lot 
of cycles unnecessarily; my code uses lots of both.

[Bug-apl] Packager updated for GNU APL 1.6

[David B. Lamkins]

With the release of GNU APL 1.6, I thought that this would be a good time to 
update the APL Package Manager.

https://github.com/TieDyedDevil/apl-pkg

The big change here is that the development branch (percy) has been merged onto 
master. There are a lot of new features (see below). There won't be a tagged 
release; I strongly suggest that you clone the git repo and pull updates 
periodically.

This remains a development release since the primary feature of the percy 
release (i.e. versioned packages) is not fully implemented. This won't affect 
you; just don't try to add version constraints to the depends_on: entries in 
your _metadata_ files.

Note that akt has been updated since the last release. It is essential that you 
re-run `./install.sh` to rebuild akt, or run `$ make -C extra/akt`.

There have been a lot of changes since the last release. From the 
doc/CHANGES.md file:

Features


- The `]pkg inspect ` command runs an interactive inspector.
  The inspector shows attributes of the variable and provides commands to
  navigate through the data. Use the inspector's `h` command to list available
  commands.

- The `]pkg time ` command executes the expression and displays
  its execution time.

- The `]pkg ident platform` command displays information about the platform
  upon which the package manager runs.

- The `]pkg ident environment` command displays information about the
  runtime environment.

- The `]pkg ident configuration` command displays the APL Packager's
  configuration settings.

- The `]pkg setpw` command updates ⎕PW to match the detected terminal width.

- The `]pkg locate  header` command displays the function's
  information plus its header line and header comments (i.e. all of the
  full-line comments immediately following the header line, up to the first
  line that's not a comment).

- The `]pkg help` command's display brackets metasyntactic variables to
  distinguish them from literal keywords.

- The `]pkg names ` command rejects an invalid prefix.

- The `]pkg packages` command displays a legend for the flags in the `L`
  column.

- The `awe` command confirms that `apl.pkg` in APL's LIB 0 is a symlink.
  This is a check against both inadvertent removal and replacement by a
  file (e.g. a )DUMP file).

- The `awe` command invokes `tabbed` when available. This is done only when
  running under X, when the configured terminal is known to `awe`'s built-in
  list (`xterm`, `urxvt` and `st`) and `awe` is not invoked from within an
  Xembed container. See `doc/PREFERENCES.md` for a description of settings
  which affect embedding.

- The `awe` commands accepts option `-i #` to set the shared variable
  processor ID.

- Displays now wrap at the terminal's actual width if the `tput` command
  is available.

- The command dispatcher now displays a usage message, rather than a list
  of all commands and their syntax, for an ill-formed command.

- The command dispatcher now displays a list of commands having a matching
  prefix when presented with an ambiguous prefix.

[Bug-apl] Yet another lambda proposal...

[David B. Lamkins]

I've been following the lambda discussion with some interest, and would like to 
propose yet another alternative for your consideration.

In brief, let's eliminate possible confusion with Dyalog's lambda 
implementation by adopting a syntax which clearly differentiates GNU APL's 
lambdas from Dyalog lambdas.

Dyalog lambdas have features which will not be reproduced in GNU APL, most 
notably multiple lines, guards, nested lambdas and lexical variables.

So rather than having something that looks similar to Dyalog lambdas but isn't, 
how about using a different syntax...?

The basic form of a GNU APL lambda, apart from the enclosing decoration, is 
simply an expression that assigns a result to .

It's the enclosing decoration, the { }, that confuses APL programmers who've 
been exposed to Dyalog lambdas. So let's not use { }...

I'd suggest that because [ ] is already an outlier in the APL syntax rules, 
it'd make sense to extend this outlier syntax for lambdas. The canonical form 
of a lambda would become:

'['']'

You can easily disambiguate this from array indexing by noticing '[' , 
which can't occur in an array index.

The distinctive syntax will serve to inform the reader that this is in fact a 
GNU APL lambda and not a Dyalog lambda.

Aside from the parsing change, we'd need to add  to existing keyboard 
layouts. Perhaps as Alt+q or r or s or f or z for their proximity to the 
s and s (on US keyboards; maybe the choice'd be narrowed by 
considering keyboard layouts in other countries) or as Alt+g to associate 
 with  for defining different kinds of functions...

In theory, you could allow traditional APL indexing inside the lambda, but I'd 
suggest that - for ease of reading - a lambda should disallow bracketed array 
indices; use  instead.

Obviously you could extend this syntax to allow variable localization. I think 
that the form '['[ ';'  ] ... ']' would 
read more naturally, but that's a minor point.

Personally I'd like to see lambdas behave as pure functions, without access to 
variables outside the lexical scope of the lambda. If you need control over 
variable scope, write a traditional function.

 

[Bug-apl] akt 2.1

[David B. Lamkins]

https://github.com/TieDyedDevil/akt

This is akt version 2.1. It correctly suspends in a shell which supports job 
control. I've also reintroduced the -z option to suppress the action of the 
suspend character (typically ^Z), in case this is desirable.

Re: [Bug-apl] Linux console APL

[David B. Lamkins]

You're running a terminal emulator. The console to which I'm referring is the 
canonical Linux console that you get on a system without X, or by pressing 
Ctrl-Alt-F1 through Ctrl-Alt-F6 in most graphical desktop environments.

For more context, look at the README-3-keyboard file in the GNU APL 
distribution; section 5: loadkeys.

On Sat, Jul 30, 2016 at 10:15:51AM -0500, Blake McBride wrote:
> I am not sure I understand what you are talking about with respect to
> "start_unicode".  I literally do nothing except run GNU APL with atk.  That's
> all I ever need.  It does everything.  The console/terminal program that comes
> with LinuxMint works fine.  All of the APL characters appear as expected.
> 
> Blake
> 
> On Fri, Jul 29, 2016 at 12:12 AM, David B. Lamkins <[1]da...@lamkins.net>
> wrote:
> 
> I thought I'd share this (new to me) discovery...
> 
> I've experimented with running APL in the Linux console. In the past I've
> followed the advice to download the APL console font and use the
> start_unicode command. That works fine, of course. The only inconvenience
> is having to run start_unicode again to restore the normal console font.
> 
> But fbterm offers an alternative. This is a terminal emulator that runs in
> the console's frame buffer. It's fully aware of modern Linux fonts, which
> means that I can use GNU FreeMono to get the APL glyphs. What's really
> interesting, I think, is that fbterm searches all of your installed fonts
> looking for a font to present each character. I'm not clear on the 
> details,
> but it ends up choosing (at least on my system) some very nice glyphs for
> both APL and non-APL characters without needing to fiddle with FreeType
> rendering options.
> 
> On top of that, fbterm supports up to ten windows. That means I don't have
> to remember to run a multiplexer (screen, dvtm, tmux).
> 
> In Fedora 24, I installed fbterm and fbterm-udevrules. The latter ensures
> that fbterm has access the framebuffer when you run it as a non-root user.
> 
> In case you're asking "why bother?": I'm trying to move away from GUIs for
> most of my work. I run X now primarily to interact with "rich" web content
> (primarily Facebook and Youtube). I find that not having a full-featured
> web browser a keystroke away helps me to concentrate on my work. That, and
> the console just "feels faster" than even a tiling window manager.
> 
> 
> 
> 
> References:
> 
> [1] mailto:da...@lamkins.net

[Bug-apl] Linux console APL

[David B. Lamkins]

I thought I'd share this (new to me) discovery...

I've experimented with running APL in the Linux console. In the past I've 
followed the advice to download the APL console font and use the start_unicode 
command. That works fine, of course. The only inconvenience is having to run 
start_unicode again to restore the normal console font.

But fbterm offers an alternative. This is a terminal emulator that runs in the 
console's frame buffer. It's fully aware of modern Linux fonts, which means 
that I can use GNU FreeMono to get the APL glyphs. What's really interesting, I 
think, is that fbterm searches all of your installed fonts looking for a font 
to present each character. I'm not clear on the details, but it ends up 
choosing (at least on my system) some very nice glyphs for both APL and non-APL 
characters without needing to fiddle with FreeType rendering options.

On top of that, fbterm supports up to ten windows. That means I don't have to 
remember to run a multiplexer (screen, dvtm, tmux).

In Fedora 24, I installed fbterm and fbterm-udevrules. The latter ensures that 
fbterm has access the framebuffer when you run it as a non-root user.

In case you're asking "why bother?": I'm trying to move away from GUIs for most 
of my work. I run X now primarily to interact with "rich" web content 
(primarily Facebook and Youtube). I find that not having a full-featured web 
browser a keystroke away helps me to concentrate on my work. That, and the 
console just "feels faster" than even a tiling window manager.

Re: [Bug-apl] akt (APL Keyboard Translator) version 2.0

[David B. Lamkins]

You're welcome. I hope you find it useful.

There will be another release after I figure out how to resolve an 
"interesting" job-control issue.

Briefly, if you $ akt someapp and then type ^Z to suspend someapp, you'll have 
open a new shell and $ kill -CONT `pidof someapp` in order to resume.

This isn't a problem for GNU APL, which ignores the TSTP signal.

If you intend to use a program that does respond to the TSTP signal (typically 
bound to ^Z), such as vim, then the safest approach is to use akt to start a 
shell and then start your editor from within the shell, like this:

$ akt sh
$ vim myfile.apl

For some reason, this two-step approach starts the shell with intact job 
control; programs started in this shell suspend and resume as you'd expect.

You might think that passing a command to an interactive shell would avoid the 
issue:

$ akt sh -c "vim myfile.apl"

It doesn't. Not only does this shell start without job control, but it seems to 
actually exec() rather than fork() the editor; take a look at the processes and 
you'll see that sh doesn't exist as vim's parent.

You can force the shell to remain involved by passing a command that it can't 
simply exec:

$ akt sh -c ":;vim myfile.apl"

Even so, the shell in this case doesn't have job control.

I'm new to this pty stuff. I wonder whether my having used BSD's forkpty() is 
causing the problem. I plan to try a rewrite using the POSIX/Linux 98 pty API 
and see whether that makes a difference.



On Mon, Jul 25, 2016 at 06:57:58PM -0500, Blake McBride wrote:
> Very nice!!  Thank you!!!
> 
> Blake
> 
> On Sun, Jul 24, 2016 at 7:24 PM, David B. Lamkins <[1]da...@lamkins.net> 
> wrote:
> 
> ... and it's finished! See [2]https://github.com/TieDyedDevil/akt .
> 
> I rewrote the state machine from scratch, ridding the program of quite a
> few bugs and annoyances.
> 
> 
> 
> 
> References:
> 
> [1] mailto:da...@lamkins.net
> [2] https://github.com/TieDyedDevil/akt

Re: [Bug-apl] akt (APL Keyboard Translator) version 2.0

[David B. Lamkins]

... and it's finished! See https://github.com/TieDyedDevil/akt .

I rewrote the state machine from scratch, ridding the program of quite a few 
bugs and annoyances.

[Bug-apl] patch: Keep invalid input out of listener and history

[David B. Lamkins]

I've attached a patch that serves to silently ignore unrecognized escape 
sequences and invalid Unicode while in the line editor. This makes it much 
easier to recover from, for example, inadvertently pressing an unhandled cursor 
key while entering an expression.
Index: src/LineInput.cc
===
--- src/LineInput.cc(revision 780)
+++ src/LineInput.cc(working copy)
@@ -907,6 +907,9 @@
lec.paste();
continue;
 
+  case Invalid_Unicode:
+   continue;
+
   default:  // regular APL character
lec.insert_char(uni);
continue;
@@ -1016,10 +1019,6 @@
   //
   if (ESCmap::need_more(seq, s))   continue;
 
-  CERR << endl << "Unknown ESC sequence: ESC";
-  loop(ss, s)   CERR << " " << HEX2(seq[ss + 1]);
-  CERR << endl;
-
   return Invalid_Unicode;
 }
   }

[Bug-apl] akt (APL Keyboard Translator) version 2.0

[David B. Lamkins]

A while ago I wrote a small utility to remap a keyboard and pipe the output to 
another program. It worked, but there are some programs (shells, some visual 
editors) that either won't function with input from a pipe or (GNU APL) behave 
differently with piped input. This was `akt` version 1, which had some rough 
edges beyond the interoperability issues.

I've just completed `akt` version 2. This takes an entirely different approach. 
Rather than pipe the translated keystrokes to another program, `akt` version 2 
attaches to the other program via a pseudo-tty. To run GNU APL, simply `akt apl 
...`. To edit an APL file in vim, it's `akt vim ...`. You can even run a shell 
with an APL keyboard: `akt sh`.

I haven't yet put `akt` version 2 in its own repo. It's part of my development 
version of the package manager. You can download the needed files as:

$ curl -LO 
https://raw.githubusercontent.com/TieDyedDevil/apl-pkg/percy/extra/akt/akt.c
$ curl -LO 
https://raw.githubusercontent.com/TieDyedDevil/apl-pkg/percy/extra/akt/Makefile

Build the program:

$ make akt

Put it on your $PATH, then:

$ akt apl

Use the Alt key to access APL characters. The keyboard layout is here:

$ curl -LO 
https://raw.githubusercontent.com/TieDyedDevil/apl-pkg/percy/extra/keyboard1.txt

Re: [Bug-apl] .apl.history file?

[David B. Lamkins]

Thanks, Jürgen.

I see what's happening now: The history file is not enabled when input is from 
a pipe, which is the case when I run akt|apl. The history file works as 
expected when input is from a terminal.

I guess I should finally get around to rewriting akt to use forkpty(). :)



On Wed, Jul 20, 2016 at 12:40:41PM +0200, Juergen Sauermann wrote:
> Hi David,
> 
> yes, it is in place (despite of its name which was not changed when readline
> was removed, so
> that existing preferences files would still work).
> 
> Maybe you want to check with apl -l 37 in which order the preferences files 
> are
> read.
> 
> You can also modify the LineInput constructor like this to see what filename 
> is
> being used:
> 
> LineInput::~LineInput()
> {
>    if (initial_termios_errno)   return;
> 
> Q(write_history)
> Q(uprefs.line_history_path.c_str())
> ...
> 
> 
> /// Jürgen
> 
> 
> 
> On 07/20/2016 04:11 AM, David B. Lamkins wrote:
> 
> Is the history file mechanism still in place?
> 
> I have set READLINE_HISTORY_PATH in ~/.gnu-apl/preferences to 
> /home/dlamkins/.apl.history .
> 
> GNU APL doesn't create the history file, nor does it write to the file if 
> I create it.
> 
> 
> 
> 

[Bug-apl] .apl.history file?

[David B. Lamkins]

Is the history file mechanism still in place?

I have set READLINE_HISTORY_PATH in ~/.gnu-apl/preferences to 
/home/dlamkins/.apl.history .

GNU APL doesn't create the history file, nor does it write to the file if I 
create it.

[Bug-apl] clang++ warning in SymbolTable.cc

[David B. Lamkins]

clang++ -DHAVE_CONFIG_H -I. -I..   -g -O2 -MT apl-SymbolTable.o -MD -MP -MF 
.deps/apl-SymbolTable.Tpo -c -o apl-SymbolTable.o `test -f 'SymbolTable.cc' || 
echo './'`SymbolTable.cc
SymbolTable.cc:240:4: warning: 'delete' applied to a pointer that was allocated 
with 'new[]'; did you mean 'delete[]'? [-Wmismatched-new-delete]
   delete sorted_names;
   ^
 []
SymbolTable.cc:207:36: note: allocated with 'new[]' here
const UCS_string ** sorted_names = new const UCS_string *[count];
   ^

[Bug-apl] More stale values

[David B. Lamkins]

See attached WS.
#!/usr/local/bin/apl --script
 
⍝
⍝ dbl-check-2.apl 2016-07-11 21:42:51 (GMT-7)
⍝
 

∇z←pkg⍙alp
 z←'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
∇
∇z←pkg⍙dig
 z←'1234567890'
∇
∇z←pkg⍙empty_string text;m
 ⍝ Remove content from quoted string, leaving only a pair of quotes.
 ⍝ This is useful to hide quoted text from analysis.
 z←((¯1⌽m)∨m←~≠\text=)/text
 z←(~2↓(m,0 0)∧(0 0,m←z=))/z
∇
∇z←(pred pkg⍙filter1) list
 ⍝ Filter items of list according to unary predicate.
 z←(,⊃pred¨list)/list
∇

∇z←pkg⍙function_refs func;labels;name;locals;tokens;ids
 ⍝ For a function expressed as a list of lines, return a list of all
 ⍝ nonlocal names used in the function.
 z←labels←⍬
 (name locals)←pkg⍙header_info pkg⍙parse 1⊃func
 more:
 func←1↓func
 →(0=⍴func)/done
 tokens←pkg⍙parse pkg⍙empty_string pkg⍙strip_comment 1⊃func
 ids←pkg⍙is_id pkg⍙filter1 tokens
 ids←(~ids∊locals)/ids
 labels←labels,pkg⍙label tokens
 z←z,ids
 →more
 done:
 z←∪z~labels
∇

∇z←pkg⍙header_info tokens;queue;locals;t;op;name
 ⍝ Given a parsed function or operator header line, return the
 ⍝ function or operator name and a list of local variable names.
 ⍝
 ⍝ z←foo;locals
 ⍝ z←foo b;locals
 ⍝ z←a foo b;locals
 ⍝ z←(x foo);locals
 ⍝ z←(x foo) b;locals
 ⍝ z←(x foo y);locals
 ⍝ z←(x foo y) b;locals
 ⍝ z←a (x foo) b;locals
 ⍝ z←a (x foo y) b;locals
 queue←locals←name←⍬
 op←0
 more:
 →(0=⍴tokens)/end
 t←1⊃tokens
 tokens←1↓tokens
 →('←'∊t)/assign
 →('('∊t)/op_start
 →((')'∊t)∧(op=1))/op_end
 →(';'∊t)/locals_list
 ⍎(pkg⍙is_id t)/'queue←queue,⊂t'
 →more
 assign:
 locals←locals,queue
 queue←⍬
 →more
 op_start:
 locals←locals,queue
 queue←⍬
 op←1
 →more
 op_end:
 locals←locals,⊂1⊃queue
 name←2⊃queue
 ⍎(3=⍴queue)/'locals←locals,⊂3⊃queue'
 queue←⍬
 →more
 locals_list:
 ⍎(pkg⍙is_id t)/'locals←locals,⊂t'
 →(0=⍴tokens)/end
 t←1⊃tokens
 tokens←1↓tokens
 →locals_list
 end:
 →(0≠⍴name)/out
 ⍎(1=⍴queue)/'name←1⊃queue ◊ queue←⍬'
 ⍎(2=⍴queue)/'name←1⊃queue ◊ queue←1↓queue'
 ⍎(3=⍴queue)/'name←2⊃queue ◊ queue←1 0 1/queue'
 out:
 z←name (locals,queue)
∇

∇z←pkg⍙id1
 z←'⎕∆⍙_'
∇

∇z←pkg⍙idX
 z←'∆⍙_¯'
∇

∇z←pkg⍙is_id token
 ⍝ Return true if token is a valid identifier.
 z←((1↑,token)∊pkg⍙id1,pkg⍙alp)∧(∧/(1↓,token)∊pkg⍙idX,pkg⍙alp,pkg⍙dig)
∇

∇z←pkg⍙label tokens
 ⍝ Given a parsed function line, return the name of a label which
 ⍝ appears on that line.
 z←(1⌽∨/¨':'=¨tokens)/tokens
∇

∇z←pkg⍙nu1
 z←'¯'
∇

∇z←pkg⍙nuX
 z←'JE¯.'
∇

∇z←pkg⍙parse text;c;i;n;f
 ⍝ Parse text into a list of identifiers and interstital text. Note
 ⍝ that the interstitial text preserves blanks; this is useful when we
 ⍝ want to rewrite the identifiers in a text without changing the
 ⍝ layout.
 z←c←⍬
 i←n←0
 more:
 →(0=⍴text)/done
 f←1↑text
 text←1↓text
 →((f∊pkg⍙nuX,pkg⍙dig)∧(n=1))/accum
 →(((f∊pkg⍙idX,pkg⍙alp,pkg⍙dig)∧(i=1))∨((f∊pkg⍙nuX,pkg⍙dig)∧(n=1)))/accum
 →((f∊pkg⍙id1,pkg⍙alp)∧(i=0))/start_id
 →((f∊pkg⍙nu1,pkg⍙dig)∧(i=0)∧(n=0))/start_num
 ⍎((0≠⍴c)∧(i=1)∨(n=1))/'z←z,⊂c ◊ c←⍬'
 i←n←0
 →accum
 start_id:
 i←1
 →flush
 start_num:
 n←1
 flush:
 ⍎(0≠⍴c)/'z←z,⊂c ◊ c←⍬'
 accum:
 c←c,f
 →more
 done:
 z←z,⊂c
∇

∇pkg⍙refresh_fn_refs;ft;all;outdated;fdef;times;fn;fns;names;i;entry;new;refs
 ⍝ Refresh pkg⍙⍙fn_refs_cache.
 ft←0=⍴pkg⍙⍙fn_refs_cache
 ⍎(ft)/'⎕←⊂''Building complete function references cache...'''
 all←pkg⍙⍙strip_trailing_blanks¨⊂[2]⎕nl 3 4
 →(0=⍴pkg⍙⍙fn_refs_cache)/add_new
 ⍝ Remove deleted
 pkg⍙⍙fn_refs_cache←(~(1⊃¨pkg⍙⍙fn_refs_cache)∊⊂¨all)/pkg⍙⍙fn_refs_cache
 ⍝ Update changed
 →(0=⍴pkg⍙⍙fn_refs_cache)/add_new
 outdated←⍬
 names←1⊃¨pkg⍙⍙fn_refs_cache
 times←2⊃¨pkg⍙⍙fn_refs_cache
 fns←all
 more1: →(0=⍴fns)/update
 fn←↑fns
 fns←1↓fns
 i←names⍳⊂fn
 →(i>⍴names)/more1
 →(times[i]≡⊂2 ⎕at fn)/more1
 outdated←outdated,⊂fn
 →more1
 update:
 names←1⊃¨pkg⍙⍙fn_refs_cache
 pkg⍙⍙fn_refs_cache←(~names∊outdated)/pkg⍙⍙fn_refs_cache
 more2: →(0=⍴outdated)/add_new
 fn←↑outdated
 outdated←1↓outdated
 fdef←⊂[2]⎕cr fn
 →(0=⍴fdef)/more2
 entry←⊂(fn) (2 ⎕at fn) ((⊂⍋⊃refs)⌷refs←pkg⍙function_refs fdef)
 pkg⍙⍙fn_refs_cache←pkg⍙⍙fn_refs_cache,entry
 →more2
 ⍝ Add new
 add_new:
 new←all
 →(0=⍴pkg⍙⍙fn_refs_cache)/more3
 new←(~all∊1⊃¨pkg⍙⍙fn_refs_cache)/all
 more3: →(0=⍴new)/done
 fn←↑new
 new←1↓new
 fdef←⊂[2]⎕cr fn
 →(0=⍴fdef)/more3
 entry←⊂(fn) (2 ⎕at fn) ((⊂⍋⊃refs)⌷refs←pkg⍙function_refs fdef)
 pkg⍙⍙fn_refs_cache←pkg⍙⍙fn_refs_cache,entry
 →more3
 done:
 ⍎(ft)/'⎕←⊂''Done. Updates will be done incrementally.'' ◊ ⎕←'
∇

∇z←pkg⍙strip_comment text
 ⍝ Strip an APL comment from text.
 z←(~∨\(text='⍝')>≠\text=)/text
∇

∇z←pkg⍙⍙strip_trailing_blanks v
 ⍝ Strip trailing blanks from a string.
 v←∊v
 z←(~⌽∧\' '=⌽⊃v)/⊃v
∇

pkg⍙⍙fn_refs_cache←0 ⍝ prototype...
  pkg⍙⍙fn_refs_cache←0⍴pkg⍙⍙fn_refs_cache

pkg⍙refresh_fn_refs

)check

[Bug-apl] Quad-PS?

[David B. Lamkins]

What's the purpose of Quad-PS (Print Style)? I've been unable to find a 
description.

[Bug-apl] Stale values

[David B. Lamkins]

The attached code creates a number of stale values.
#!/usr/local/bin/apl --script
 
⍝
⍝ stale 2016-07-04 22:15:49 (GMT-7)
⍝
 

∇ucmd_args pkg args;⎕io;_cmd_info;_verbs;verb;action;rc;pm
 ⍝ This is the APL Package Manager's top-level command dispatcher.
 ⎕io←1
 ⍎(0≠⎕nc 'ucmd_args')/'args←1↓ucmd_args'
 ⍎(1=≡args)/'args←⊂args'
 _cmd_info←pkg_cmd_info
 _verbs←1⊃¨_cmd_info
 verb←_verbs pkg⍙prefix_match 1↑args
 action←(_verbs∊verb)/_verbs
 →(0=⍴action)/unmatched
 args←1↓args
 rc←⍎'pkg⍙cmd_',(↑action),' args'
 →rc/0
 usage:
 ⎕←'usage:',((1⊃¨_cmd_info)⍳action)⊃_cmd_info
 →0
 unmatched:
 →(0=⍴⍴args)/show
 ⎕←⊂'Unrecognized command'
 pm←_verbs pkg⍙prefix_matches 1↑args
 →(0=⍴pm)/0
 ⎕←'Possibly:',pm
 →0
 show:
 pkg⍙sink pkg⍙cmd_help ''
∇

∇z←pkg⍙alp
 z←'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
∇

∇z←pkg⍙dig
 z←'1234567890'
∇

∇z←pkg⍙id1
 z←'⎕∆⍙_'
∇

∇z←pkg⍙idX
 z←'∆⍙_¯'
∇

∇z←pkg⍙nu1
 z←'¯'
∇

∇z←pkg⍙nuX
 z←'JE¯.'
∇

∇z←pkg⍙empty_string text;m
 ⍝ Remove content from quoted string, leaving only a pair of quotes.
 ⍝ This is useful to hide quoted text from analysis.
 z←((¯1⌽m)∨m←~≠\text=)/text
 z←(~2↓(m,0 0)∧(0 0,m←z=))/z
∇

∇z←(pred pkg⍙filter1) list
 ⍝ Filter items of list according to unary predicate.
 z←(,⊃pred¨list)/list
∇

∇z←pkg⍙function_refs func;labels;name;locals;tokens;ids
 ⍝ For a function expressed as a list of lines, return a list of all
 ⍝ nonlocal names used in the function.
 z←labels←⍬
 (name locals)←pkg⍙header_info pkg⍙parse 1⊃func
 more:
 func←1↓func
 →(0=⍴func)/done
 tokens←pkg⍙parse pkg⍙empty_string pkg⍙strip_comment 1⊃func
 ids←pkg⍙is_id pkg⍙filter1 tokens
 ids←(~ids∊locals)/ids
 labels←labels,pkg⍙label tokens
 z←z,ids
 →more
 done:
 z←∪z~labels
∇

∇z←pkg⍙header_info tokens;queue;locals;t;op;name
 ⍝ Given a parsed function or operator header line, return the
 ⍝ function or operator name and a list of local variable names.
 ⍝
 ⍝ z←foo;locals
 ⍝ z←foo b;locals
 ⍝ z←a foo b;locals
 ⍝ z←(x foo);locals
 ⍝ z←(x foo) b;locals
 ⍝ z←(x foo y);locals
 ⍝ z←(x foo y) b;locals
 ⍝ z←a (x foo) b;locals
 ⍝ z←a (x foo y) b;locals
 queue←locals←name←⍬
 op←0
 more:
 →(0=⍴tokens)/end
 t←1⊃tokens
 tokens←1↓tokens
 →('←'∊t)/assign
 →('('∊t)/op_start
 →((')'∊t)∧(op=1))/op_end
 →(';'∊t)/locals_list
 ⍎(pkg⍙is_id t)/'queue←queue,⊂t'
 →more
 assign:
 locals←locals,queue
 queue←⍬
 →more
 op_start:
 locals←locals,queue
 queue←⍬
 op←1
 →more
 op_end:
 locals←locals,⊂1⊃queue
 name←2⊃queue
 ⍎(3=⍴queue)/'locals←locals,⊂3⊃queue'
 queue←⍬
 →more
 locals_list:
 ⍎(pkg⍙is_id t)/'locals←locals,⊂t'
 →(0=⍴tokens)/end
 t←1⊃tokens
 tokens←1↓tokens
 →locals_list
 end:
 →(0≠⍴name)/out
 ⍎(1=⍴queue)/'name←1⊃queue ◊ queue←⍬'
 ⍎(2=⍴queue)/'name←1⊃queue ◊ queue←1↓queue'
 ⍎(3=⍴queue)/'name←2⊃queue ◊ queue←1 0 1/queue'
 out:
 z←name (locals,queue)
∇

∇z←pkg⍙is_id token
 ⍝ Return true if token is a valid identifier.
 z←((1↑,token)∊pkg⍙id1,pkg⍙alp)∧(∧/(1↓,token)∊pkg⍙idX,pkg⍙alp,pkg⍙dig)
∇

∇z←pkg⍙label tokens
 ⍝ Given a parsed function line, return the name of a label which
 ⍝ appears on that line.
 z←(1⌽∨/¨':'=¨tokens)/tokens
∇

∇z←pkg⍙parse text;c;i;n;f
 ⍝ Parse text into a list of identifiers and interstital text. Note
 ⍝ that the interstitial text preserves blanks; this is useful when we
 ⍝ want to rewrite the identifiers in a text without changing the
 ⍝ layout.
 z←c←⍬
 i←n←0
 more:
 →(0=⍴text)/done
 f←1↑text
 text←1↓text
 →((f∊pkg⍙nuX,pkg⍙dig)∧(n=1))/accum
 →(((f∊pkg⍙idX,pkg⍙alp,pkg⍙dig)∧(i=1))∨((f∊pkg⍙nuX,pkg⍙dig)∧(n=1)))/accum
 →((f∊pkg⍙id1,pkg⍙alp)∧(i=0))/start_id
 →((f∊pkg⍙nu1,pkg⍙dig)∧(i=0)∧(n=0))/start_num
 ⍎((0≠⍴c)∧(i=1)∨(n=1))/'z←z,⊂c ◊ c←⍬'
 i←n←0
 →accum
 start_id:
 i←1
 →flush
 start_num:
 n←1
 flush:
 ⍎(0≠⍴c)/'z←z,⊂c ◊ c←⍬'
 accum:
 c←c,f
 →more
 done:
 z←z,⊂c
∇

∇z←pkg⍙strip_comment text
 ⍝ Strip an APL comment from text.
 z←(~∨\(text='⍝')>≠\text=)/text
∇

pkg⍙function_refs ⊂[2] ⎕cr 'pkg'

)check

[Bug-apl] Pick-each crash

[David B. Lamkins]

  ↑¨⊂⊂''



SEGMENTATION FAULT


-- Stack trace at main.cc:85

0x7fbef4feb731 __libc_start_main
0x40a7a2
0x57521a
0x444918
0x4465e3
0x474a96
0x521fe0
0x4af81e
0x4abbb8
0x47949c
0x42a98d
0x4c76c3
0x4c2e2c
0x444801
0x7fbef62b3c30
0x40a6d1




Same result with
  ↑¨⊂⊂⍬

[Bug-apl] Times-reduce fails to report domain error

[David B. Lamkins]

Times-reduce fails to report a domain error.

  ×/⍳170
7.257415615E306
  ×/⍳171



Note that scan does report the error.

  ×\⍳171
DOMAIN ERROR
  ×\⍳171
  ^ ^

[Bug-apl] Execute user-defined command

[David B. Lamkins]

Execute of a user-defined command no longer works.

  ]usercmd ]foo foo
User-defined command ]foo installed.
  ∇a foo b
[1] 1
[2] ∇
  ]foo
1
  ⍎']foo'

[Bug-apl] Execute system command

[David B. Lamkins]

I know that this is not covered by the spec, but this is useful and used to 
work.

I've included several examples to help narrow down the problem. The last test 
causes a stack trace.


  ⊃⍎')LIBS'
Library root: /home/dlamkins/APL/apl-pkg-repo  
   
Library reference number mapping:  
   
---
Ref Conf  PathState   Err  
---
 0 PUSER /home/dlamkins/APL/workspacespresent  
 1 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib1   missing (2)  
 2 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib2   missing (2)  
 3 PSYS  /usr/local/lib/apl/wslib3present  
 4 PSYS  /usr/local/lib/apl/wslib4present  
 5 PSYS  /usr/local/lib/apl/wslib5present  
 6 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib6   missing (2)  
 7 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib7   missing (2)  
 8 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib8   missing (2)  
 9 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib9   missing (2)  
===
   
  ll←⊃⍎')LIBS'
  ll
Library root: /home/dlamkins/APL/apl-pkg-repo  
   
Library reference number mapping:  
   
---
Ref Conf  PathState   Err  
---
 0 PUSER /home/dlamkins/APL/workspacespresent  
 1 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib1   missing (2)  
 2 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib2   missing (2)  
 3 PSYS  /usr/local/lib/apl/wslib3present  
 4 PSYS  /usr/local/lib/apl/wslib4present  
 5 PSYS  /usr/local/lib/apl/wslib5present  
 6 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib6   missing (2)  
 7 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib7   missing (2)  
 8 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib8   missing (2)  
 9 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib9   missing (2)  
===
   
  ⍎')LIBS'
 Library root: /home/dlamkins/APL/apl-pkg-repo  Library reference number mapping
  :  ---
   Ref Conf  PathState  
   Err -
  --  0 PUSER /home/dlamkins/APL/workspacesprese
  nt  1 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib1   missing (
  2)  2 BIN   /home/dlamkins/APL/apl-pkg-repo/wslib2   missing (
  2)  3 PSYS  /usr/local/lib/apl/wslib3present  
  4 PSYS  /usr/local/lib/apl/wslib4present  5 PS
  YS  /usr/local/lib/apl/wslib5present  6 BIN   
  /home/dlamkins/APL/apl-pkg-repo/wslib6   missing (2)  7 BIN   
  /home/dlamkins/APL/apl-pkg-repo/wslib7   missing (2)  8 BIN   
  /home/dlamkins/APL/apl-pkg-repo/wslib8   missing (2)  9 BIN   
  /home/dlamkins/APL/apl-pkg-repo/wslib9   missing (2) =
  ==  
  ⍴⍎')LIBS'
19
  lll←⍎')LIBS'
Incomplete value at Symbol.cc:132
Addr:0x1822750
Rank:1
Shape:   ⊏19⊐
Flags:   --
First:   ┏→┓
┃Library root: /home/dlamkins/APL/apl-pkg-repo┃
┗━┛ 
Dynamic: DynamicObject: 0x1822758 (Value: 0x1822750) :
prev:  0x1825e18
next:  0x1817e38
allocated: PrimitiveFunction.cc:2817
value history disabled


==
Assertion failed: 0
in Function:  assign
in file:  Symbol.cc:135

Call stack:

-

[Bug-apl] APL Package Manager

[David B. Lamkins]

https://github.com/TieDyedDevil/apl-pkg

Here's news for those of you interested in the APL Package Manager:

Changes introduced by GNU APL svn r740+ broke the package manager due to my 
inadvertent use of some code that was not standard-compliant but still valid in 
GNU APL up through svn r739.

I've backported fixes from my development branch into the master branch and 
have also published a 0.3.1 release with the ammended code.

Now the master branch, the percy branch and the 0.3.1 release all work as 
designed with the current GNU APL svn version.

I do *not* provide support for the packaged GNU APL 1.5 release. Note that 
Jüergen recommends building GNU APL from the head of the svn tree; the packaged 
release is mainly for trial purposes.

If you're interested in tracking the current development version of the package 
manager, please run the percy branch from the git repo. The percy branch has a 
number of new features, but the main feature -- versioned dependencies -- is 
not yet available for use. See doc/CHANGES.md for additional details.

Re: [Bug-apl] Tab completion doesn't track )ERASE

[David B. Lamkins]

I see. I had assumed (incorrectly) that )ERASE and ⎕EX have the same effect.

IIUC, the names interned by any definition are available to tab completion 
until they are )ERASEd, even if they are no longer associated with an APL 
object in the workspace. I noticed that tab completion sees even names that 
have only ever been available as localized names in a function.

Is there a portable way to unintern a name from the symbol table? The ISO 
standard doesn't seem to specify whether 

  ⍎')system_command ...'

should be supported.



On Mon, Jun 27, 2016 at 01:58:07PM +0200, Juergen Sauermann wrote:
> Hi David,
> 
> ⎕EX only deletes the current-referent of a name (= the name at the
> top of the )SI stack) but not its global-referent.
> 
> If you use )ERASE instead of ⎕EX then tab-completion will recognize this.
> 
> /// Jürgen
> 
> 
> On 06/27/2016 07:05 AM, David B. Lamkins wrote:
> 
> Tab completion doesn't know that a symbol has been removed.
> 
> In the following,  is the tab character.
> 
>   ⎕fx 'foo'
> foo
>   f
>   ⎕ex 'foo'
> 1
>   ⎕nc 'foo'
> 0
>   f
> VALUE ERROR
>   foo
>   ^
> 
> 
> 
> 

[Bug-apl] Tab completion doesn't track )ERASE

[David B. Lamkins]

Tab completion doesn't know that a symbol has been removed.

In the following,  is the tab character.

  ⎕fx 'foo'
foo
  f
  ⎕ex 'foo'
1
  ⎕nc 'foo'
0
  f
VALUE ERROR
  foo
  ^

[Bug-apl] Quad-EC

[David B. Lamkins]

When used to invoke ⎕FX, ⎕EC returns only the value of executing ⎕FX and not 
any of the values representing the kind of statement executed and its success 
or failure.

  ]boxing 8
  ⎕ec '⎕fx ''foo'''
┌→──┐
│foo│
└───┘
  ⎕ec '⍳3'
┌→──┐
│1 ┌→──┐ ┌→┐│
│  │0 0│ │1 2 3││
│  └───┘ └─┘│
└∊──┘

[Bug-apl] Quad-EA

[David B. Lamkins]

When called with a defined function (not a lambda), ⎕EA returns an incorrect 
result.

NOTE: The same issue affects ⎕EB and ⎕EC.

  ]boxing 8
  ∇z←foo
[1] z←1
[2] ∇
  foo
┌─┐
│1│
└─┘
  '0' ⎕ea 'foo'
┌→──┐
│1 ┌→──┐ ┌─┐│
│  │0 0│ │1││
│  └───┘ └─┘│
└∊──┘
  bar←{1}
  bar
┌─┐
│1│
└─┘
  '0' ⎕ea 'bar'
┌─┐
│1│
└─┘

[Bug-apl] Option parsing patch

[David B. Lamkins]

This patch corrects a problem with the -p and -l options not recognizing their 
arguments.

Index: src/UserPreferences.cc
===
--- src/UserPreferences.cc  (revision 739)
+++ src/UserPreferences.cc  (working copy)
@@ -182,7 +182,7 @@
for (size_t a = 1; a < expanded_argv.size(); )
{
  const char * opt = expanded_argv[a++];
- const char * val = (a < expanded_argv.size() - 1)
+ const char * val = (a < expanded_argv.size())
   ? expanded_argv[a] : 0;
 
  if (!strcmp(opt, "-l"))

Re: [Bug-apl] Outer product with replicate error

[David B. Lamkins]

While `$ info apl` speaks to the issues around function/operator ambiguity, it 
does not make any mention of the outer product case.

I suspect that the failure of "outer product expand" is an oversight. This case 
is disambiguated by noticing the outer product during the right-to-left scan 
that GNU APL does anyway (step 3 in the referenced info page).

Outer product is a common idiom dating from the earliest days of APL. It 
doesn't make any sense to require special (i.e. specific to GNU APL) syntax for 
this particular case.


On Sat, May 14, 2016 at 01:31:13PM -0500, Xiao-Yong Jin wrote:
> 
> > On May 14, 2016, at 7:51 AM, David Tran  wrote:
> > 
> > Hi,
> > 
> > Newbie study "MasteringDyalogAPL"; got error on page #388 example:
> > 
> >   3 0 2 ∘./ 5 1 7
> > SYNTAX ERROR
> >   3 0 2∘./5 1 7
> >   ^  ^
> > 
> > bug? ( or this is a specify feature of Dyalog and not APL2 ? )
> 
> It’s documented in the info page of gnu apl.  A feature (bug?) of the parser 
> treats / as an operator in this case.  Simple workaround would be
> 
>   3 0 2 ∘.{⍺/⍵} 5 1 7
>  5 5 5  1 1 1  7 7 7 
>  
>  5 51 17 7   
> 
> I have too limited experience to say whether it is good or bad.  Perhaps the 
> parser should accept some exceptional cases?
> 
> Best,
> Xiao-Yong
> 
> 
> 

Re: [Bug-apl] GNU APL in a browser over the net

[David B. Lamkins]

It's possibly just a configuration problem. I took a quick look at the 
shellinabox file `vt100.jspp`; the code at lines 2489-2452 should generate the 
ESC prefix when the alt/meta key is active, but alt must be enabled. Presumably 
there's a config file or dialog for this.

As an aside, it looks like the alt key configuration has a secondary dependency 
based upon whether the code is running on a Mac or not. I don't have the line 
reference handy, but it's earlier in the same file.


On Sat, May 07, 2016 at 01:11:27AM -0500, Blake McBride wrote:
> GNU APL works in a browser over the net via:  
> [1]https://github.com/shellinabox
> /shellinabox.git
> 
> The only problem I had was when I used it with akt, the alt-keys didn't work
> correctly.  My guess is that there is a mapping problem in shellinabox.  So,
> APL programs work great in it, but you can't program in it.
> 
> Blake
> 
> 
> References:
> 
> [1] https://github.com/shellinabox/shellinabox.git

Re: [Bug-apl] About aplwrap

[David B. Lamkins]

Thank you, Chris.


On Tue, Mar 29, 2016 at 07:27:59PM -0400, Chris Moller wrote:
>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
>  [1]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.
> 
> References
> 
>1. https://github.com/ChrisMoller/aplwrap/blob/master/src/txtbuf.c

Re: [Bug-apl] Near Proof of concept of an )edit somefunction_name

[David B. Lamkins]

Hi Christian,

To close the loop on this:

I don't remember and didn't write down Chris Moller's credentials.

Given that Chris hasn't been around for a long while, you might want to 
consider forking the project if you're unable to contact Chris directly.

Sorry...

David



On Wed, Mar 23, 2016 at 11:12:35PM -0700, David B. Lamkins wrote:
> Thanks for the patch. I'll check this weekend: If I still have access I'll 
> push the change.
> 
> On Wed, Mar 23, 2016 at 11:21:40PM -0400, Christian Robert wrote:
> > David,
> > 
> >  Do you still have access to the aplwrap GitHub login ?
> > 
> >  This evening I had tracked down why it sometime (aplwrap) abort/coredump 
> > on me.
> > 
> >  this is a one line change into file src/txtbuf.c
> >  since I made that change I can no longer make it abort on me.
> > 
> > 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';  // <-- *before*
> > ztext[sz-6] = '\0';// <-- *after*
> > 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;
> >   }
> > }
> > 
> > 
> > It may be also a good idea to make it work without Warning with gtk-3.0 
> > (warnings stop the compilation, had to remove -Werror in Makefiles)
> > and it also complain about:
> > 
> > WARNING: 'aclocal-1.13' is missing on your system.
> > WARNING: 'automake-1.13' is missing on your system.
> > 
> > solved by manually run aclocal and automake after ./configure ...
> > 
> > 
> > Xtian.
> > 
> > 
> > On 2016-03-21 22:43, David B. Lamkins wrote:
> > >On Tue, Mar 22, 2016 at 09:50:02AM +0800, Elias Mårtenson wrote:
> > >>There was another project that
> > >>aimed to provide something similar, using a dedicated application
> > >>called aplwrap. What happened to that?
> > >
> > >Chris Moller wrote aplwrap. I contributed some improvements and was the 
> > >last person to work on the project. (Chris was kind enough to share his 
> > >GitHub login with me when he got busy with other commitments; I haven't 
> > >heard from Chris since then.)
> > >
> > >Chris Moller also wrote aplplot, which can be used standalone or from 
> > >aplwrap.
> > >
> > >To the best of my knowledge, aplwrap *should* still be viable. I 
> > >personally stopped using aplwrap when my own apl-pkg project reached the 
> > >point where I was comfortable working within that environment.
> > 

Re: [Bug-apl] Near Proof of concept of an )edit somefunction_name

[David B. Lamkins]

Thanks for the patch. I'll check this weekend: If I still have access I'll push 
the change.

On Wed, Mar 23, 2016 at 11:21:40PM -0400, Christian Robert wrote:
> David,
> 
>  Do you still have access to the aplwrap GitHub login ?
> 
>  This evening I had tracked down why it sometime (aplwrap) abort/coredump on 
> me.
> 
>  this is a one line change into file src/txtbuf.c
>  since I made that change I can no longer make it abort on me.
> 
> 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';  // <-- *before*
> ztext[sz-6] = '\0';// <-- *after*
> 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;
>   }
> }
> 
> 
> It may be also a good idea to make it work without Warning with gtk-3.0 
> (warnings stop the compilation, had to remove -Werror in Makefiles)
> and it also complain about:
> 
> WARNING: 'aclocal-1.13' is missing on your system.
> WARNING: 'automake-1.13' is missing on your system.
> 
> solved by manually run aclocal and automake after ./configure ...
> 
> 
> Xtian.
> 
> 
> On 2016-03-21 22:43, David B. Lamkins wrote:
> >On Tue, Mar 22, 2016 at 09:50:02AM +0800, Elias Mårtenson wrote:
> >>There was another project that
> >>aimed to provide something similar, using a dedicated application
> >>called aplwrap. What happened to that?
> >
> >Chris Moller wrote aplwrap. I contributed some improvements and was the last 
> >person to work on the project. (Chris was kind enough to share his GitHub 
> >login with me when he got busy with other commitments; I haven't heard from 
> >Chris since then.)
> >
> >Chris Moller also wrote aplplot, which can be used standalone or from 
> >aplwrap.
> >
> >To the best of my knowledge, aplwrap *should* still be viable. I personally 
> >stopped using aplwrap when my own apl-pkg project reached the point where I 
> >was comfortable working within that environment.
> >
> >In apl-pkg I took the approach of shelling out to an external editor. No 
> >particular reason, save that I wasn't particularly interested in writing an 
> >editor in APL, which would have gootten pretty complicated had I attempted 
> >to emulate some kind of full-screen interface.
> >
> >FWIW, apl-pkg is much more than a wrapper around an external editor. Similar 
> >to gnu-apl-mode, apl-pkg provides a number of tools for 
> >programming-in-the-large.
> >
> >Before aplwrap and apl-pkg I very much liked gnu-apl-mode. A couple years 
> >back -- after having used Emacs for four decades -- I wanted to *finally* 
> >learn vi, so I ditched Emacs and switched everything over to vim (and more 
> >recently, vis).
> >
> >Referenced Projects:
> >https://github.com/ChrisMoller/aplwrap
> >https://github.com/tiedyeddevil
> >

Re: [Bug-apl] Near Proof of concept of an )edit somefunction_name

[David B. Lamkins]

On Tue, Mar 22, 2016 at 11:46:21AM +0800, Elias Mårtenson wrote:
>On 22 March 2016 at 10:43, David B. Lamkins <[1]da...@lamkins.net>
>wrote:
> 
>  FWIW, apl-pkg is much more than a wrapper around an external editor.
>  Similar to gnu-apl-mode, apl-pkg provides a number of tools for
>  programming-in-the-large.
> 
>Of course. I did not intend to disparage your (or anybody else's) work.
>My intention was to raise the level of discussion from a small
>implementation detail as to how to start an external editor to the more
>important issue of how to provide a pleasurable development environment
>(which the commandline+external editor is not, IMHO).

Understood. If I gave the impression that I took offense, it was unintentional.

I only wanted to add a bit of exposition for the benefit of folks who don't 
remember aplwrap.

> 
>  Before aplwrap and apl-pkg I very much liked gnu-apl-mode. A couple
>  years back -- after having used Emacs for four decades -- I wanted
>  to *finally* learn vi, so I ditched Emacs and switched everything
>  over to vim (and more recently, vis).
> 
>As someone who lives in Emacs, and have done so since the late 80's, I
>find it surprising that you decided to move to vi, but that's not for
>me to judge. :-)
>My personal opinion is that Emacs is the awesomest thing ever, but the
>more tools the better. :-)

Believe me, I know. :) I'm one of those Emacs users who used Emacs for 
*everything*. Log in, start Emacs, do all of my work (and mail, and news, and 
web, and music, and ...), and log out. :)

But after forty years, several bouts with RSI (mostly pointer-related, but also 
"Emacs pinky") and numerous occasions of having to work as a guest on systems 
where Emacs wasn't installed, I figured it was time to learn vi. (Nano, of 
course, is broadly available but not especially helpful.) It took me about 
three weeks to make the transition.

>Regards,
>Elias
> 
> References
> 
>1. mailto:da...@lamkins.net

Re: [Bug-apl] Near Proof of concept of an )edit somefunction_name

[David B. Lamkins]

On Tue, Mar 22, 2016 at 09:50:02AM +0800, Elias Mårtenson wrote:
>There was another project that
>aimed to provide something similar, using a dedicated application
>called aplwrap. What happened to that?

Chris Moller wrote aplwrap. I contributed some improvements and was the last 
person to work on the project. (Chris was kind enough to share his GitHub login 
with me when he got busy with other commitments; I haven't heard from Chris 
since then.)

Chris Moller also wrote aplplot, which can be used standalone or from aplwrap.

To the best of my knowledge, aplwrap *should* still be viable. I personally 
stopped using aplwrap when my own apl-pkg project reached the point where I was 
comfortable working within that environment.

In apl-pkg I took the approach of shelling out to an external editor. No 
particular reason, save that I wasn't particularly interested in writing an 
editor in APL, which would have gootten pretty complicated had I attempted to 
emulate some kind of full-screen interface.

FWIW, apl-pkg is much more than a wrapper around an external editor. Similar to 
gnu-apl-mode, apl-pkg provides a number of tools for programming-in-the-large.

Before aplwrap and apl-pkg I very much liked gnu-apl-mode. A couple years back 
-- after having used Emacs for four decades -- I wanted to *finally* learn vi, 
so I ditched Emacs and switched everything over to vim (and more recently, vis).

Referenced Projects:
https://github.com/ChrisMoller/aplwrap
https://github.com/tiedyeddevil

Re: [Bug-apl] Feature suggestion: multiple function arguments

[David B. Lamkins]

On Thu, Mar 17, 2016 at 10:51:11AM +0800, Elias Mårtenson wrote:
>On 17 March 2016 at 00:41, David B. Lamkins <[1]da...@lamkins.net>
>wrote:
> 
>  I'm not sure what you mean by this. Were we to follow the model of
>  Lisp's macroexpansion, the expander would simply be an APL program
>  that reads some program text -- possibly but not necessarily
>  containing local syntax extensions -- and rewrite that text in
>  APL2/GNU APL code without the syntax extensions. It'd be up to the
>  rewriter to handle any necessary lexical and syntactic analysis
>  necessary to perform the program tranformation.
> 
>That's the problem. If your rewriter works on the level of the reader
>(i.e. working directly with the string of characters that make up the
>code) then your extension would essentially have to reimplement the
>entire language parser.

Of course. And yes, that is what I was suggesting.

I assume that the parser-in-APL problem would be solved a small number of 
times; those interested could share the work. 

Now, this is obviously not an ideal approach. I assume that the rewriter would 
need to read every executed line of APL code at least once. Even if the 
rewritten code is cached, there'll still be a performance hit due to the 
necessity of the rewriter scanning every executed line using code written in 
interpreted APL.

On the other hand, having the full generality of a rewriter-in-APL would offer 
the ability to create DSLs and not simply extend the semantics of APL-like 
expressions. Kinda like Lisp... ;)

[... snip ...]
>In Lisp, the custom READTABLE is applied on a single translation unit
>(i.e. a single .lisp file). Something similar could be implemented in
>APL as well.

OK. I can see that.

[... snip ...]
>  Clearly quad-AV is necessary for compatibility with legacy APL code;
>  as such, it'd be ill-advised to break that compatibility.
> 
>I agree. But at the same time, I don't think I've ever run a single
>line of legacy code in my life. I only started using API a few years
>ago (with the release of GNU APL), so for me (and possibly any other
>newcomer to the language) Quad-AV is completely pointless.
>I'm not sure I agree that holding back the language to benefit legacy
>code is the best idea. I completely agree that legacy code should
>continue to work, but preventing obvious improvements because of
>restrictions introduced in an era where Unicode didn't even exist
>doesn't make much sense to me.
>In other words, what I am suggesting is: If you use characters outside
>of Quad-AV in your code, then Quad-AV will cease to work.

I'm kind of in the same boat. I learned APL on microcomputers in the `80s. The 
nested-array implementations were already in play by then, but not in the 
implementations to which I had access. I'm finding APL2 to be quite a different 
language than APL, in many respects. I didn't save any of my own "legacy" code, 
so haven't had to deal with compatibility issues.

A larger question is: Does quad-AV have any value at all in new code? It's 
inherently non-portable (in that the collation order is unspecified) and 
contains a proper subset of the code points in quad-UCS.

Re: [Bug-apl] Feature suggestion: multiple function arguments

[David B. Lamkins]

On Wed, Mar 16, 2016 at 01:17:36PM +0800, Elias Mårtenson wrote:
>On 16 March 2016 at 09:23, David B. Lamkins <[1]da...@lamkins.net>
>wrote:
> 
>  On Tue, Mar 15, 2016 at 11:35:59AM +0800, Elias Mårtenson wrote:
> 
> 
>  The lexical rewriter could be a plugin, but it could also be an APL
>  function. Imagine being able to assign an APL function to
>  quad-SOMETHINGOROTHER to define your own local syntax. You'd still
>  be running APL2 code under the covers, but you'd be able to define
>  your own syntax for anything that can be rewritten (presumably less
>  conveniently) in APL2. Remember that the rewriter would have full
>  access to the underlying APL2 interpreter, so you'd be able write
>  entire programs to support the processing of some new syntax.
>  (If the above sounds familiar, it's probably because it's an
>  amalgamation of ideas from Lisp.)
> 
>It does indeed sound a lot like Lisp form rewriting. I'm all for this
>idea, and I'd be willing to make a test implementation of it, as long
>as someone (else) can can come up with a decent way of actually create
>a way to unambiguously state the input to be transformed (the
>equivalent of the DEFMACRO destructuring form in Lisp).

I'm not sure what you mean by this. Were we to follow the model of Lisp's 
macroexpansion, the expander would simply be an APL program that reads some 
program text -- possibly but not necessarily containing local syntax extensions 
-- and rewrite that text in APL2/GNU APL code without the syntax extensions. 
It'd be up to the rewriter to handle any necessary lexical and syntactic 
analysis necessary to perform the program tranformation.

> 
>  Also, quad-SOMETHINGOROTHER would be a nightmare in shared code
>  unless there was a good way to support localization (in the APL
>  sense, not the I18N sense).
> 
>The extensions would be part of the program itself, just like in Lisp.
>I don't see a problem here.

I anticipated that a system variable or function would hold the program that 
does the rewriting. Were I to load two programs (e.g. a main program and a 
library) that used this facility in different ways, there'd be a conflict.

>I'm not entirely sure why Quad-AV even needs to exist in a modern
>program? We should be able to use all of Unicode to name our functions.

Clearly quad-AV is necessary for compatibility with legacy APL code; as such, 
it'd be ill-advised to break that compatibility.

Extending the GNU APL lexer to accept additional code points in names would be 
an extension to the language. It'd break backward compatibility (you could 
write GNU APL programs that APL2 wouldn't be able to load), but legacy APL2 
programs would still run in GNU APL.

>Regards,
>Elias
> 
> References
> 
>1. mailto:da...@lamkins.net

Re: [Bug-apl] Feature suggestion: multiple function arguments

[David B. Lamkins]

On Tue, Mar 15, 2016 at 11:35:59AM +0800, Elias Mårtenson wrote:
>I was thinking of something similar, but the problem is that creating a
>plugin API that lets you implement trains is incredibly difficult,
>since you need to hook deep into the parser.
> 
>As for more simple extensions, we already have almost all that is
>needed in the plugin API, with the exception of being able to define
>new function symbols.
> 

First of all, I'm not volunteering for this task, but...

While I agree that adding hooks to allow arbitrary special cases in the parser 
would be an architecturally weak approach, it might be useful to add a single 
hook that would support code to perform a lexical rewrite before handing an 
expression to the APL2-compatible built-in parser.

The lexical rewriter could be a plugin, but it could also be an APL function. 
Imagine being able to assign an APL function to quad-SOMETHINGOROTHER to define 
your own local syntax. You'd still be running APL2 code under the covers, but 
you'd be able to define your own syntax for anything that can be rewritten 
(presumably less conveniently) in APL2. Remember that the rewriter would have 
full access to the underlying APL2 interpreter, so you'd be able write entire 
programs to support the processing of some new syntax.

(If the above sounds familiar, it's probably because it's an amalgamation of 
ideas from Lisp.)

I don't know whether this would help or not w.r.t. function trains.

Also, quad-SOMETHINGOROTHER would be a nightmare in shared code unless there 
was a good way to support localization (in the APL sense, not the I18N sense).

>The latter is something that I would like very much. In other words, I
>would like the ability to define functions (single-letter ideally)
>using characters outside of quad-AV.
> 
>Jürgen has previously explained that there are technical difficulties
>in expanding the character repertoire outside 255 characters, but I
>still feel this is one old limitation that deserves being eliminated.

I understand why we need to limit quad-AV to 256 elements. But what about 
composed characters? Would it be enough to alias the Unicode "compose" 
codepoint to the ASCII "backspace" (that is already, I'm assuming, in 
quad-AV...)?

Of course, you'd need a terminal that's able to compose glyphs on-the-fly. :\

[Bug-apl] APL Package Manager release 0.3 (Evey)

[David B. Lamkins]

https://github.com/TieDyedDevil/apl-pkg/releases

Date:2015-10-06
Contact: [David B. Lamkins](mailto:da...@lamkins.net)

Announcing the 3rd Release of APL Package Manager
=

The APL Package Manager is a tool to manage the development
and deployment of APL software built from a collection of
packages.

In its third release, named Evey, the APL Package Manager
supports GNU APL version 1.5 or later on GNU/Linux hosts.
This release introduces a completed package dependency
manager which not only loads dependent packages (which
has been a feature from the very first release) but also
correctly unloads unreferenced dependencies when using the
new `]pkg unload` command. Furthermore, the `]pkg load`
command does not reload packages which have already been
loaded.

The `]pkg packages` display now distinguishes four distinct
cases for a package's loaded state. These are denoted by
the following flag characters in the `L` column: `*` for a
top-level package (i.e. named in a `]pkg load` command),
`+` for a package loaded as a dependency, `-` for a package
removed with the `]pkg expunge` command but still required
as a dependency and ` ` for a package which is neither
loaded nor required.

Additionally, editor support has been reworked. Please see
`doc/EDITOR.md` for details.

See `doc/CHANGES` for further details regarding these and
other changes.

About the APL Package Manager
-

Although APL is very good for interactive programming
based upon structured datasets, the ISO/IBM version
of the language lacks modern facilities for
programming-in-the-large. This historical limitation fosters
a culture of reinvention rather than reuse. Large software
systems were built using APL in the days of top-down
software management. Those days are gone.

The APL Package Manager defines and checks a set of
conventions to support reuse of code among far-flung and
self-managed APLers.

The central shared artifact of the APL Package Manager is a
package. A package collects one or more cohesive APL source
code files together with descriptive metadata, optional
documentation and data files, optional source code files
in other languages (e.g. for building helper applications
and interfaces), plus a control file to load the package;
these are all located within a single directory that may be
distributed as an archive file or a source code repository.

Packages may be used alongside traditional APL workspace
files or source code files. APL source code files are easily
packaged with help from the APL Package Manager.

The APL Package Manager supports deployment of completed
systems.

Future releases of the APL Package Manager will implement
additional tools and features, version management, and
remote repositories.

The APL Package Manager is designed to support additional
APL interpreters and host platforms.

The APL Package Manager is open source software distributed
under the MIT License.

[Bug-apl] DUMP date patch

[David B. Lamkins]

When loading a DUMPed file, the reported date is incorrect. See attached patch.
Index: src/Workspace.cc
===
--- src/Workspace.cc(revision 678)
+++ src/Workspace.cc(working copy)
@@ -704,8 +704,8 @@
 
   out << "DUMPED "
   << setfill('0') << (1900 + t->tm_year) << "-"
-  << setw(2)  << t->tm_mon   << "-"
-  << setw(2)  << (t->tm_mday + 1)<< " "
+  << setw(2)  << (t->tm_mon + 1) << "-"
+  << setw(2)  << t->tm_mday  << " "
   << setw(2)  << t->tm_hour  << ":"
   << setw(2)  << t->tm_min   << ":"
   << setw(2)  << t->tm_sec   << " (GMT"

Re: [Bug-apl] ⎕TZ should not be saved

[David B. Lamkins]

One of the nice things about XML is that you can manipulate it according to 
your needs. Take a look at xsltproc (1).

http://xmlsoft.org/XSLT/xsltproc.html
http://www.w3.org/TR/xslt

On Sat, Sep 12, 2015 at 08:48:07AM -0500, Blake McBride wrote:
>Hi Juergen,
>I see your point, and it makes sense.  One caviet though, I don't know
>if this is the case or not but, I hope that when a )DUMP occurs the
>functions and variables are sorted.  )DUMP makes more sense to use in a
>SCCS.  If I change one function, I wouldn't want a different sort of
>the )DUMP file to make the SCCS think more changed.  Does )DUMP sort
>its output?
>Thanks!
>Blake

Re: [Bug-apl] Locked Functions

[David B. Lamkins]

This was covered quite a while back, Mike; you probably missed it.

Not hiding the content of a locked function is intentional as it goes against 
the spirit of open software.

Take a look at quad-FX: the optional left argument can be used to prevent 
suspension. I use this in the iso-apl-cf package.

On Tue, Sep 08, 2015 at 06:33:08PM -0700, Mike Duvos wrote:
>The workings of locked functions are supposed to be completely
>concealed from the user, and if an error appears in one, it is
>considered to have occurred in the line invoking the locked function,
>as if it were a primitive.
>We can see this in APL2.
>  ∇FOO
>[1]   BAR⍫
>  ∇BAR
>[1]   →1∇
> 
>   FOO
>INTERRUPT
>  FOO
>  ^
> 
>In GNU APL, however, we can get suspensions in locked functions and the
>things they call on our state indicator.
>  FOO
>^CATTENTION
>BAR[1]  →1
> ^
>  )si
>BAR[1]
>FOO[1]
>⋆
>I was wondering what the standard says about this, as it is definitely
>contrary to the APL2 documentation.

[Bug-apl] APL Package Manager -- 2nd Release

[David B. Lamkins]

I've released the 2nd version of the APL Package Manager. 

home page:
https://github.com/TieDyedDevil/apl-pkg

summary announcement:
https://github.com/TieDyedDevil/apl-pkg/blob/master/doc/ANNOUNCE.md

change list:
https://github.com/TieDyedDevil/apl-pkg/blob/master/doc/CHANGES.md

Re: [Bug-apl] How to create profile in preferences file?

[David B. Lamkins]

Thank you, Jüergen.

It turns out that there is a problem with the implementation:

In main.cc::init_apl(), uprefs.parse_argv() is called after the calls to
uprefs.read_config_file(). As a result, read_config_file() never sees
the value set by the -p N command-line argument.

If I move the call to parse_argv() ahead of the calls to
read_config_file(), the Profile entries are recognized as per your
intent.

I didn't investigate the semantics of option processing. The -p N
parsing may need to be a special case in order for the command-line
options to override the preferences when parse_argv() is invoked from
its current position in the code. Perhaps it's sufficient to call
parse_argv() both before and after the calls to read_config_file().

On Thu, 2014-11-27 at 12:58 +0100, Juergen Sauermann wrote:
> Hi David,
> 
> the plan was this:
> 
>
>...
> 
> Profile 1
> 
>
> ...
> 
> Profile 2
> 
>
>...
> 
> The profile number 0 stands for "all profiles"
> 
> Not sure if I ever tested this.
> 
> /// Jürgen
> 
> 
> On 11/27/2014 08:19 AM, David B. Lamkins wrote:
> 
> > I'd like to create multiple profiles in the GNU APL preferences file and
> > and select one at runtime using the -p N command-line option. I
> > apologize if I've overlooked something in the documentation, but I can't
> > find an example of how this works.
> > 
> > 
> > 
> 

[Bug-apl] How to create profile in preferences file?

[David B. Lamkins]

I'd like to create multiple profiles in the GNU APL preferences file and
and select one at runtime using the -p N command-line option. I
apologize if I've overlooked something in the documentation, but I can't
find an example of how this works.

[Bug-apl] APLwrap 2.2

[David B. Lamkins]

I tagged and pushed APLwrap 2.2 today. This is the same code that has
been on the repository since October 19th. I've only bumped the version
number and added a summary of changes (attached).

Changes from APLwrap version 2.1 to 2.2
---

- Improve reliability of prompt recognition.

- Support explicit creation of a new file editor, rather than having
  to go through export followed by import.

- Remove export commands.

- Add --shortcuts command-line option.

- Improve completion function's wraparound logic.

- Fix completion function's origin-dependence.

- Completion function handles empty completion list.

- Bind Alt-Delete to delete uncommitted input.

- When saving a buffer under a different name, existing buffers with
  that name adopt the new content.

- Implement Revert for edit window.

- Implement search in transcript and edit windows.
  (APL characters not yet supported. Requires GTK+ 3.10 or later.)

- Implement substring search in Open Object dialog.
  (APL characters not yet supported.)

- Add help menu to edit window.

- Don't lose unsaved edit windows when closing transcript.

- Fix crash that may occur while closing an edit window.

- Add tabbed notebook to display APLwrap manuals.

- Add keyboard accelerators for commonly used menu items.

- Remember recently used folders as sidebar shortcuts in Open File dialog.

- Keep function editor window open upon syntax error.

- Implemented file Open, Save and Save As.

- Fit Open Object selector to width of longest name.

- Add mnemonics to menus and menu items.

- Editor line and column numbers are now displayed in origin 0.

- Editor line and column numbers update in sync with cursor movement,
  whether via keyboard or mouse.

- Edit window opens with cursor at <0,0>.

- Bind Alt-PageUp and Alt-PageDown to move backward and forward by APL
  prompt through the transcript.

- Add a pstat window.

- Implement mouse-2 paste in transcript.

- APL prompts are now highlighted with a light-blue background.

- Save and restore settings.

- Add a toggle for the pstat line.

[Bug-apl] Patch for cursor key "Unknown ESC sequence: ..." behavior

[David B. Lamkins]

Details are in the attached patch file.

Eliminate "Unknown ESC sequence: ..." messages caused by applying
modifiers (shift, alt and ctrl) to cursor keys.

Holding down a modifier key adds parameters to the cursor key escape
sequence. `ESC [ x` becomes `ESC [ 1 ; # x`, where `#` depends upon
the modifier key.

This patch causes ESCmap::is_equal() and ESCmap::has_prefix() to
ignore parameters when matching incoming key sequences. The cursor
keys now have identical behavior whether or not a modifier key is
present.


Index: src/LineInput.cc
===
--- src/LineInput.cc	(revision 501)
+++ src/LineInput.cc	(working copy)
@@ -80,13 +80,15 @@
 bool
 ESCmap::has_prefix(const char * seq, int seq_len) const
 {
-   if (seq_len >= len)   return false;
+   int ss = 0;
loop(s, seq_len)
   {
-if (seq[s] != seqence[s])   return false;
+if (!isdigit(seq[s]) && seq[s] != ';') {
+  if (seq[s] != seqence[ss++])   return false;
+}
   }
 
-   return true;
+   return ss < len;
 }
 //-
 void
@@ -100,13 +102,15 @@
 bool
 ESCmap::is_equal(const char * seq, int seq_len) const
 {
-   if (len != seq_len)   return false;
+   int ss = 0;
loop(s, seq_len)
   {
-if (seq[s] != seqence[s])   return false;
+if (!isdigit(seq[s]) && seq[s] != ';') {
+  if (seq[s] != seqence[ss++])   return false;
+}
   }
 
-   return true;
+   return ss == len;
 }
 //=
 LineHistory::LineHistory(int maxl)

[Bug-apl] akt 1.2.1

[David B. Lamkins]

I plan for this to be the final release of akt.

Changes since 1.1 are:

1. Command line option -n causes akt to pass Ctrl-C to the output rather
than signaling the listening process. This is to be used with programs
(e.g. nano) that expect to see a typed Ctrl-C instead of receiving a
SIGINT signal.

2. akt checks that its input is a tty.

[Bug-apl] akt 1.1

[David B. Lamkins]

I've updated akt to version 1.1.

https://github.com/TieDyedDevil/akt

The significant changes since 1.0 are:

1. Ctrl-C causes akt to signal SIGINT to the process on the receiving
end of the output pipe.
2. Ctrl-C quits akt if its output is not piped.
3. akt exits when the process on the receiving end of the output pipe
terminates.
4. NUL characters (Ctrl-@, Ctrl-` or Ctrl-space) are now passed through
to the output.
5. You can now type a bare ESC. (Use akt with vi, if you like.)
6. You can no longer use ESC as a prefix key. Set your terminal emulator
to map Alt to an ESC prefix.
7. Corrected three improperly mapped APL characters.

Re: [Bug-apl] Another option for APL keyboard mapping

[David B. Lamkins]

> Doesn't this amount to a GNU/APL-specific implementation of the
> standard X Compose mechanism?
> 
> https://lists.gnu.org/archive/html/bug-apl/2014-05/msg4.html

Not exactly. akt's mapping is targeted rather than global to the login
session. More important (from my perspective) is that the mappings are
as an APLer would expect, in the sense that there's an actual modifier
key (as opposed to a prefix) to access the APL characters.

Depending upon what you're doing, the first difference could be seen as
either a strength or a weakness. If you need to type APL everywhere, the
compose map is an excellent choice. If you only need APL input for
selected command-line applications, akt gives you the benefit of a
familiar APL keyboard rather than needing to compose every APL
character.

To be clear, although akt's target audience is GNU APL users, it is not
specific to GNU APL. akt can be used with any command-line application
that accepts Unicode input on stdin. I just used akt|nano to make an
APL-aware text editor...

[Bug-apl] akt feedback

[David B. Lamkins]

Thanks, Blake.

Having to disable the terminal's alt-key menu access is expected. I'll
add that to the README.

(Funny story: I briefly added alt-key access to aplwrap's top-level
menus. I quickly realized my mistake...)

Having to type an extra character (not necessarily a CR) is required to
detect that the pipe is broken. That's already documented. (There
doesn't appear to be a portable way to detect a broken pipe without
attempting a write.)

Thanks for the errata regarding the key map. I'll resolve those as soon
as I have a few free moments.

One more thing to be mindful of: `akt` currently has no way to send a
kill signal to apl, so it won't be possible to interrupt a long
computation. I think I might be able to resolve this by grovelling
through parts of the /proc fs. That might take a bit more time for me to
resolve. Meanwhile, don't do anything that'll require interruption... ;)

Re: [Bug-apl] Another option for APL keyboard mapping

[David B. Lamkins]

Fair enough. I'll put high-bit controls on the TODO list along with
alternate prefixes.

On Thu, 2014-10-23 at 14:26 +0800, Elias Mårtenson wrote:
> I have no idea. Probably not. :-) The point, however, is that if there
> is a standard way of doing it, that should be used. And I believe
> there is a most standard way (or am I wrong? I might mis-remember).
> 
> 
> Regards,
> Elias
> 
> On 23 October 2014 14:24, David B. Lamkins  wrote:
> Interesting. I knew about the high-bit controls, but honestly
> can't
> remember the last time I saw a system that used them. Aside
> from xterm
> (given appropriate configuration), are high-bit controls used
> on any of
> your available platforms?
> 
> On Thu, 2014-10-23 at 14:09 +0800, Elias Mårtenson wrote:
> > If you have never seen anything else, then I must assume
> that you
> > haven't looked hard enough. :-)  In fact, the usual way was
> to simply
> > set the high bit to 1 to indicate Alt. Emacs implemented a
> workaround
> > for terminals that did not support this (the Esc-prefix) and
> many
> > terminal emulators have adopted this these days, making it
> full-circle
> > if you will.
> >
> >
> > Regards,
> > Elias
> >
> > On 23 October 2014 14:06, David B. Lamkins
>  wrote:
> > Thanks, Elias.
> >
> > I was inspired by what I saw coming out of
> `showkey`, so I
> > looked at the
> > source and realized that the foundation was very
> simple. The
> > only really
> > tricky part was distinguishing between the ANSI CSI
> (a
> > two-character
> > prefix of all ANSI cursor and function keys) and the
> APL `←`
> > which is
> > identical to the CSI but has nothing following until
> the next
> > key press.
> >
> > Like you, I had a moment where I thought this ought
> to be
> > integrated in
> > GNU APL. Then I realized that GNU APL needs to see
> the Unicode
> > representation of the APL characters so that curses
> can do the
> > right
> > thing with the cursor keys.
> >
> > That said, I'd be happy to share `akt` as a
> contribution to
> > the
> > "keyboards" section of the GNU APL distribution.
> >
> > I don't understand your concern regarding ESC as a
> prefix. ESC
> > prefixing
> > has been consistently available in all of the
> terminal
> > emulators I've
> > seen in the past decade or more on Macs, PCs and
> many flavors
> > of Linux.
> > I'd be surprised if that feature suddenly
> disappeared.
> >
> > Even if one did encounter a terminal emulator that
> doesn't map
> > Alt to an
> > ESC prefix, one may always type the ESC key as a
> prefix...
> >
> > It'd be easy to allow specification of a different
> > single-character
> > prefix, but I don't understand the need. What am I
> missing?
> > Something
> > having to do with the layout of non-US keyboards...?
> Non-ANSI
> > terminal
> > emulators...? Personal preference...?
> >
> > I do plan to look into curses, but that solution has
> a larger
> > "surface
> > area". `akt` was just a quick and simple hack to
> have a
> > lightweight
> > keyboard mapper while I slowly wrap my head around
> curses for
> > a
> > different project.
> >
> >
> >
> 
> 
> 
> 
> 

Re: [Bug-apl] Another option for APL keyboard mapping

[David B. Lamkins]

Interesting. I knew about the high-bit controls, but honestly can't
remember the last time I saw a system that used them. Aside from xterm
(given appropriate configuration), are high-bit controls used on any of
your available platforms?

On Thu, 2014-10-23 at 14:09 +0800, Elias Mårtenson wrote:
> If you have never seen anything else, then I must assume that you
> haven't looked hard enough. :-)  In fact, the usual way was to simply
> set the high bit to 1 to indicate Alt. Emacs implemented a workaround
> for terminals that did not support this (the Esc-prefix) and many
> terminal emulators have adopted this these days, making it full-circle
> if you will.
> 
> 
> Regards,
> Elias
> 
> On 23 October 2014 14:06, David B. Lamkins  wrote:
> Thanks, Elias.
> 
> I was inspired by what I saw coming out of `showkey`, so I
> looked at the
> source and realized that the foundation was very simple. The
> only really
> tricky part was distinguishing between the ANSI CSI (a
> two-character
> prefix of all ANSI cursor and function keys) and the APL `←`
> which is
> identical to the CSI but has nothing following until the next
> key press.
> 
> Like you, I had a moment where I thought this ought to be
> integrated in
> GNU APL. Then I realized that GNU APL needs to see the Unicode
> representation of the APL characters so that curses can do the
> right
> thing with the cursor keys.
> 
> That said, I'd be happy to share `akt` as a contribution to
> the
> "keyboards" section of the GNU APL distribution.
> 
> I don't understand your concern regarding ESC as a prefix. ESC
> prefixing
> has been consistently available in all of the terminal
> emulators I've
> seen in the past decade or more on Macs, PCs and many flavors
> of Linux.
> I'd be surprised if that feature suddenly disappeared.
> 
> Even if one did encounter a terminal emulator that doesn't map
> Alt to an
> ESC prefix, one may always type the ESC key as a prefix...
> 
> It'd be easy to allow specification of a different
> single-character
> prefix, but I don't understand the need. What am I missing?
> Something
> having to do with the layout of non-US keyboards...? Non-ANSI
> terminal
> emulators...? Personal preference...?
> 
> I do plan to look into curses, but that solution has a larger
> "surface
> area". `akt` was just a quick and simple hack to have a
> lightweight
> keyboard mapper while I slowly wrap my head around curses for
> a
> different project.
> 
> 
> 

Re: [Bug-apl] Another option for APL keyboard mapping

[David B. Lamkins]

Thanks, Elias.

I was inspired by what I saw coming out of `showkey`, so I looked at the
source and realized that the foundation was very simple. The only really
tricky part was distinguishing between the ANSI CSI (a two-character
prefix of all ANSI cursor and function keys) and the APL `←` which is
identical to the CSI but has nothing following until the next key press.

Like you, I had a moment where I thought this ought to be integrated in
GNU APL. Then I realized that GNU APL needs to see the Unicode
representation of the APL characters so that curses can do the right
thing with the cursor keys.

That said, I'd be happy to share `akt` as a contribution to the
"keyboards" section of the GNU APL distribution.

I don't understand your concern regarding ESC as a prefix. ESC prefixing
has been consistently available in all of the terminal emulators I've
seen in the past decade or more on Macs, PCs and many flavors of Linux.
I'd be surprised if that feature suddenly disappeared. 

Even if one did encounter a terminal emulator that doesn't map Alt to an
ESC prefix, one may always type the ESC key as a prefix...

It'd be easy to allow specification of a different single-character
prefix, but I don't understand the need. What am I missing? Something
having to do with the layout of non-US keyboards...? Non-ANSI terminal
emulators...? Personal preference...?

I do plan to look into curses, but that solution has a larger "surface
area". `akt` was just a quick and simple hack to have a lightweight
keyboard mapper while I slowly wrap my head around curses for a
different project.

Re: [Bug-apl] patch for help and commands

[David B. Lamkins]

Thank you.

On Sun, 2014-10-19 at 15:03 +0200, Juergen Sauermann wrote:
> Hi David,
> 
> thanks, included in SVN 491.
> 
> I have not removed the display of user-defined commands in )HELP.
> 
> /// Jürgen
> 
> 
> On 10/18/2014 09:41 AM, David B. Lamkins wrote:
> > See attached. Description is in patch header.
> >
> 

[Bug-apl] patch for help and commands

[David B. Lamkins]

See attached. Description is in patch header.

This patch brings consistency to the help display and changes the
behavior of some commands:

 - ]BOXING without an argument displays the current state
 - ]USERCMD REMOVE-ALL works
 - ]USERCMD without an argument displays defined user commands
 - ]HELP and )HELP no longer display defined user commands
 - ]SYMBOL error messages are less cryptic
 - )HIST checks for invalid argument
 - ]COLOR and ]XTERM check for invalid argument
 - ]COLOR ON and ]XTERM ON are inhibited if environment TERM=dumb
 - ]XTERM or ]COLOR without an argument displays the current state
 - )DROP has proper tab-completion hinting

Index: src/Command.cc
===
--- src/Command.cc	(revision 490)
+++ src/Command.cc	(working copy)
@@ -389,10 +389,44 @@
 }
 //-
 void 
+Command::cmd_XTERM(ostream & out, const UCS_string & arg)
+{
+   const char * term = getenv("TERM");
+   if (!strncmp(term, "dumb", 4) && arg.starts_iwith("ON"))
+  {
+out << "impossible on dumb terminal" << endl;
+  }
+   else if (arg.starts_iwith("OFF") || arg.starts_iwith("ON"))
+  {
+Output::toggle_color(arg);
+  }
+   else if (arg.size() == 0)
+  {
+out << "]COLOR/XTERM ";
+if (Output::color_enabled()) out << "ON"; else out << "OFF";
+out << endl;
+  }
+   else
+  {
+out << "BAD COMMAND" << endl;
+return;
+  }
+}
+//-
+void 
 Command::cmd_BOXING(ostream & out, const UCS_string & arg)
 {
 int format = arg.atoi();
 
+   if (arg.size() == 0)
+  {
+
+out << "]BOXING ";
+if (boxing_format == -1) out << "OFF"; else out << boxing_format;
+out << endl;
+return;
+  }
+
if (arg.starts_iwith("OFF"))   format = -1;
 
switch (format)
@@ -615,26 +649,14 @@
 #define cmd_def(cmd_str, _cod, arg, _hint) \
CERR << "  " cmd_str " " #arg << endl;
 #include "Command.def"
-   out << endl;
-
-   if (user_commands.size())
-  {
-out << "User defined commands:" << endl;
-loop(u, user_commands.size())
-   {
- out << "  " << user_commands[u].prefix << " → ";
- if (user_commands[u].mode)   out << "A ";
- out << user_commands[u].apl_function << " B"
- << " (mode " << user_commands[u].mode << ")" << endl;
-   }
-  }
 }
 //-
 void 
 Command::cmd_HISTORY(ostream & out, const UCS_string & arg)
 {
-   if (arg.starts_iwith("CLEAR"))   LineInput::clear_history(out);
-   else LineInput::print_history(out);
+   if (arg.size() == 0)  LineInput::print_history(out);
+   else if (arg.starts_iwith("CLEAR"))   LineInput::clear_history(out);
+   else  out << "BAD COMMAND" << endl;
 }
 //-
 void
@@ -1172,16 +1194,24 @@
 Command::cmd_USERCMD(ostream & out, const UCS_string & cmd,
  vector & args)
 {
+   // ]USERCMD
// ]USERCMD REMOVE-ALL
// ]USERCMD REMOVE]existing-command
// ]USERCMD ]new-command  APL-fun
// ]USERCMD ]new-command  APL-fun  mode
//
-   if (args.size() < 2)
+   if (args.size() == 0)
   {
-out << "BAD COMMAND" << endl;
-Workspace::more_error() =
-   UCS_string("too few parameters in command ]USERCMD");
+if (user_commands.size())
+   {
+ loop(u, user_commands.size())
+{
+  out << user_commands[u].prefix << " → ";
+  if (user_commands[u].mode)   out << "A ";
+  out << user_commands[u].apl_function << " B"
+  << " (mode " << user_commands[u].mode << ")" << endl;
+}
+   }
 return;
   }
 
Index: src/Output.cc
===
--- src/Output.cc	(revision 490)
+++ src/Output.cc	(working copy)
@@ -385,13 +385,16 @@
 void 
 Output::toggle_color(const UCS_string & arg)
 {
-int a = 0;
-   while (a < arg.size() && arg[a] < UNI_ASCII_SPACE)   ++a;
-
if (arg.starts_iwith("ON")) colors_enabled = true;
else if (arg.starts_iwith("OFF"))   colors_enabled = false;
elsecolors_enabled = !colors_enabled;
 }
+//-
+bool
+Output::color_enabled()
+{
+   return Output::colors_enabled;
+}
 //=
 void
 CIN_ostream::set_cursor(int y, int x)
Index: src/SymbolTable.cc
===
--- 

[Bug-apl] ScalarBenchmark for inner and outer products

[David B. Lamkins]

I'm seeing zero start-up costs for inner and outer products when running
ScalarBenchmark.apl.


  = Mat1_IRC +.× Mat1_IRC  ===

Benchmarking start-up cost for Mat1_IRC +.× Mat1_IRC ...
 Length   Sequ Cycles   Para Cycles   Linear Sequ Linear Para 
 ==   ===   ===   === === 
 25 0 0 0   0 
 25 0 0 0   0 
 25 0 0 0   0 
 25 0 0 0   0 
 16 0 0 0   0 
 16 0 0 0   0 
 16 0 0 0   0 
 16 0 0 0   0 
 16 0 0 0   0 
 16 0 0 0   0 
 16 0 0 0   0 
  9 0 0 0   0 
  9 0 0 0   0 
  9 0 0 0   0 
  9 0 0 0   0 
  9 0 0 0   0 
  4 0 0 0   0 
  4 0 0 0   0 
  4 0 0 0   0 
  1 0 0 0   0 

regression line sequential:0 + 0×N cycles
regression line parallel:  0 + 0×N cycles

  = Vec1_IRC ∘.× Vec1_IRC  ===

Benchmarking start-up cost for Vec1_IRC ∘.× Vec1_IRC ...
 Length   Sequ Cycles   Para Cycles   Linear Sequ Linear Para 
 ==   ===   ===   === === 
 25 0 0 0   0 
 25 0 0 0   0 
 25 0 0 0   0 
 25 0 0 0   0 
 16 0 0 0   0 
 16 0 0 0   0 
 16 0 0 0   0 
 16 0 0 0   0 
 16 0 0 0   0 
 16 0 0 0   0 
 16 0 0 0   0 
  9 0 0 0   0 
  9 0 0 0   0 
  9 0 0 0   0 
  9 0 0 0   0 
  9 0 0 0   0 
  4 0 0 0   0 
  4 0 0 0   0 
  4 0 0 0   0 
  1 0 0 0   0 

regression line sequential:0 + 0×N cycles
regression line parallel:  0 + 0×N cycles


But then in the summary section -- just above ]PSTAT -- I see:


-- Mat1_IRC +.× Mat1_IRC -- 
average sequential startup cost: 359 cycles
average parallel startup cost:   832 cycles
per item cost sequential:  0 cycles
per item cost parallel:0 cycles
parallel break-even length:  not reached

-- Vec1_IRC ∘.× Vec1_IRC -- 
average sequential startup cost: 359 cycles
average parallel startup cost:   832 cycles
per item cost sequential:  0 cycles
per item cost parallel:0 cycles
parallel break-even length:  not reached


Here the startup costs are nonzero, but the per-item costs are all zero.

This doesn't look right... Or am I missing something?

In case it might shed some additional light, here's the final section of
the ]PSTAT output. The rest looks reasonable except for
epsilon-underbar, which reports all zeroes.


╔═╦╤══╤══╤══╤══╗
║Function ║│N │  ⌀ VLEN  │ ⌀ cycles │ cyc÷VLEN ║
╟─╫┼──┼──┼──┼──╢
║   f B overhead  ║ 18446744003448130869 │  283 │ 1993 │ 34818579233229 
│ 17466187239 ║
║ A f B overhead  ║ 18446743954621671206 │ 1114 │   84 │ 1447585256996 
│ 17221844259 ║
║   scalar B  ║  130198460 │  283 │ 3873 │   460065 │  118 ║
║ A scalar B  ║   91680403 │ 1114 │  949 │82298 │   86 ║
║ clone B ║ 233950109373 │ 75391125 │  131 │ 3103 │   23 ║
║ A f.g B ║

[Bug-apl] APLwrap update (preview/beta) - request for feedback

[David B. Lamkins]

APLwrap has undergone a lot of changes and fixes since its 2.1 release
(see attached). I'd like to tag and commit a 2.2 release in the near
future.

If you're an APLwrap user, I'd appreciate it if you'd pull the latest
version from GitHub, give it a good workout, and report any lingering
bugs.

Thank you.
- When saving a buffer under a different name, existing buffers with
  that name adopt the new content.

- Implement Revert for edit window.

- Implement search in transcript and edit windows.
  (APL characters not yet supported. Requires GTK+ 3.10 or later.)

- Implement substring search in Open Object dialog.
  (APL characters not yet supported.)

- Add help menu to edit window.

- Don't lose unsaved edit windows when closing transcript.

- Fix crash that may occur while closing an edit window.

- Add tabbed notebook to display APLwrap manuals.

- Add keyboard accelerators for commonly used menu items.

- Remember recently used folders as sidebar shortcuts in Open File dialog.

- Keep function editor window open upon syntax error.

- Implemented file Open, Save and Save As.

- Fit Open Object selector to width of longest name.

- Add mnemonics to menus and menu items.

- Editor line and column numbers are now displayed in origin 0.

- Editor line and column numbers update in sync with cursor movement,
  whether via keyboard or mouse.

- Edit window opens with cursor at <0,0>.

- Bind Alt-PageUp and Alt-PageDown to move backward and forward by APL
  prompt through the transcript.

- Add a pstat window.

- Implement mouse-2 paste in transcript.

- APL prompts are now highlighted with a light-blue background.

- Save and restore settings.

- Add a toggle for the pstat line.

[Bug-apl] aplwrap build problem

[David B. Lamkins]

The "build.h" issue is corrected in commit 0b576f6.

Re: [Bug-apl] aplwrap: error with function with blank lines

[David B. Lamkins]

Thank you. Fixed and pushed.

On Wed, 2014-10-08 at 14:30 -0500, Blake McBride wrote:
> If you edit a function with blank lines, you get the following error
> on the console for each blank line that exists:
> 
> 
> (aplwrap:30307): Gtk-CRITICAL **: gtk_text_buffer_emit_insert:
> assertion 'g_utf8_validate (text, len, NULL)' failed
> 
> 
> 
> Thanks.
> 
> 
> Blake
> 
> 

Re: [Bug-apl] Error compiling latest aplwrap

[David B. Lamkins]

Thank you. Fix pushed.

On Mon, 2014-10-06 at 17:45 -0500, Blake McBride wrote:
> 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/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-edit.o -MD -MP -MF .deps/aplwrap-edit.Tpo -c -o aplwrap-edit.o
> `test -f 'edit.c' || echo './'`edit.c
> edit.c: In function ‘message_dialog’:
> edit.c:72:29: error: format not a string literal and no format
> arguments [-Werror=format-security]
>  message);
>  ^
> cc1: all warnings being treated as errors
> make[2]: *** [aplwrap-edit.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
> 
> 

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

[David B. Lamkins]

Changed and pushed.

Blake, don't commit any syntax errors in origin-0 until you get the
libemacs update. ;)


On Tue, 2014-10-07 at 01:18 +0800, Elias Mårtenson wrote:
> I try not to make incompatible changes. I would love to completely
> redesign it at some point but for now you can consider that part
> stable. If I need to redesign that part I'll probably simply implement
> a new command. 
> 
> Regards, 
> Elias 
> 
> On 7 Oct 2014 01:11, "David B. Lamkins"  wrote:
> Did I? I guess it's a matter of interpretation. Emacs uses
> origin-1 for
> line numbers, while APL uses origin-0.
> 
> Clearly it makes sense to maintain the Emacs sense of line
> numbers.
> 
> It's still proper to commit the fix (with the +1) since
> otherwise
> gnu-apl-mode will be wrong in the case where APL runs in
> origin-0.
> 
> This won't fix Blake's issue. I'll need to parse the wire
> protocol and
> adjust the result. Just how stable is the wire protocol...?
> 
> On Mon, 2014-10-06 at 11:18 +0800, Elias Mårtenson wrote:
> > Thanks. I'll integrate it once I get home. Although you
> missed a +1
> > there. The error is reported as a line number, not an APL
> jump index,
>         > which is conceptually different thing.
> >
> > Regards,
> > Elias
> >
> > On 6 Oct 2014 01:05, "David B. Lamkins" 
> wrote:
> > Thanks, Blake. This is best fixed in libemacs.
> >
> > Elias: The attached patch makes a failed function
> definition
> > report an
> > origin-independent line number.
> >
> > On Sun, 2014-10-05 at 07:29 -0500, Blake McBride
> wrote:
> > > Looks good, but one very small problem - when it
> reports the
> > line
> > > number with the error, it is off by one.  In other
> words,
> > line
> > > references in the editor (and in APL) start at 0,
> but when
> > it reports
> > > the error it reports the line number as if they
> start at 1.
> > >
> > >
> > > Thanks.
> > >
> > >
> > > Blake
> > >
> > >
> > >
> > > On Sat, Oct 4, 2014 at 3:17 PM, David B. Lamkins
> > 
> > > wrote:
> > > Fixed and pushed.
> > >
> > > On Sat, 2014-10-04 at 08:08 -0500, Blake
> McBride
> > wrote:
> > > > This is still a problem.  It can create
> a real
> > loss of work.
> > > >
> > > >
> > > > Thanks.
> > > >
> > > >
> > > > Blake
> > > >
> > > >
> > > >
> > > > On Fri, Sep 12, 2014 at 6:18 PM, Chris
> Moller
> > > 
> > > > wrote:
> > > > 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,
> > > > >
> > > > >
> > > >

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

[David B. Lamkins]

Did I? I guess it's a matter of interpretation. Emacs uses origin-1 for
line numbers, while APL uses origin-0.

Clearly it makes sense to maintain the Emacs sense of line numbers.

It's still proper to commit the fix (with the +1) since otherwise
gnu-apl-mode will be wrong in the case where APL runs in origin-0.

This won't fix Blake's issue. I'll need to parse the wire protocol and
adjust the result. Just how stable is the wire protocol...?

On Mon, 2014-10-06 at 11:18 +0800, Elias Mårtenson wrote:
> Thanks. I'll integrate it once I get home. Although you missed a +1
> there. The error is reported as a line number, not an APL jump index,
> which is conceptually different thing. 
> 
> Regards, 
> Elias 
> 
> On 6 Oct 2014 01:05, "David B. Lamkins"  wrote:
> Thanks, Blake. This is best fixed in libemacs.
> 
> Elias: The attached patch makes a failed function definition
> report an
> origin-independent line number.
> 
> On Sun, 2014-10-05 at 07:29 -0500, Blake McBride wrote:
> > Looks good, but one very small problem - when it reports the
> line
> > number with the error, it is off by one.  In other words,
> line
> > references in the editor (and in APL) start at 0, but when
> it reports
> > the error it reports the line number as if they start at 1.
> >
> >
> > Thanks.
> >
> >
> > Blake
> >
> >
> >
> > On Sat, Oct 4, 2014 at 3:17 PM, David B. Lamkins
> 
> > wrote:
> > Fixed and pushed.
> >
> > On Sat, 2014-10-04 at 08:08 -0500, Blake McBride
> wrote:
> > > This is still a problem.  It can create a real
> loss of work.
> > >
> > >
> > > Thanks.
> > >
> > >
> > > Blake
> > >
> > >
> > >
> > > On Fri, Sep 12, 2014 at 6:18 PM, Chris Moller
> > 
> > > wrote:
> > > 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 - editing functions with errors

[David B. Lamkins]

APLwrap doesn't actually interpret the wire protocol beyond looking for
'error' in the first line. Additional lines, up to but not including the
terminating sentinel, are simply collected and displayed.

On Mon, 2014-10-06 at 11:32 +0800, Elias Mårtenson wrote:
> That's a display issue. ☺ I'm sure aplwrap can provide an option to
> display it in that way for people who prefer that (most people
> probably don't care since one never actually interacts with jump
> indexes very often directly) 
> 
> What David's patch does is to harmonise the underlying wire protocol.
> It has no bearing on what is displayed in aplwrap. 
> 
> Regards, 
> Elias 
> 
> On 6 Oct 2014 11:29, "Blake McBride"  wrote:
> Conceptually different but significantly confusing if they are
> not displayed as the same number.
> 
> On Sun, Oct 5, 2014 at 10:18 PM, Elias Mårtenson
>  wrote:
> Thanks. I'll integrate it once I get home. Although
> you missed a +1 there. The error is reported as a line
> number, not an APL jump index, which is conceptually
> different thing. 
>     
>     Regards, 
> Elias 
> 
> On 6 Oct 2014 01:05, "David B. Lamkins"
>  wrote:
> Thanks, Blake. This is best fixed in libemacs.
> 
> Elias: The attached patch makes a failed
> function definition report an
> origin-independent line number.
> 
> On Sun, 2014-10-05 at 07:29 -0500, Blake
> McBride wrote:
> > Looks good, but one very small problem -
> when it reports the line
> > number with the error, it is off by one.  In
> other words, line
> > references in the editor (and in APL) start
> at 0, but when it reports
> > the error it reports the line number as if
> they start at 1.
> >
> >
> > Thanks.
>         >
>     >
> > Blake
> >
> >
> >
> > On Sat, Oct 4, 2014 at 3:17 PM, David B.
> Lamkins 
> > wrote:
> > Fixed and pushed.
> >
> > On Sat, 2014-10-04 at 08:08 -0500,
> Blake McBride wrote:
> > > This is still a problem.  It can
> create a real loss of work.
> > >
> > >
> > > Thanks.
> > >
> > >
> > > Blake
> > >
> > >
> > >
> > > On Fri, Sep 12, 2014 at 6:18 PM,
> Chris Moller
> > 
> > > wrote:
> > > 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
>

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

[David B. Lamkins]

Thanks, Blake. This is best fixed in libemacs.

Elias: The attached patch makes a failed function definition report an
origin-independent line number.

On Sun, 2014-10-05 at 07:29 -0500, Blake McBride wrote:
> Looks good, but one very small problem - when it reports the line
> number with the error, it is off by one.  In other words, line
> references in the editor (and in APL) start at 0, but when it reports
> the error it reports the line number as if they start at 1.
> 
> 
> Thanks.
> 
> 
> Blake
> 
> 
> 
> On Sat, Oct 4, 2014 at 3:17 PM, David B. Lamkins 
> wrote:
> Fixed and pushed.
> 
> On Sat, 2014-10-04 at 08:08 -0500, Blake McBride wrote:
> > This is still a problem.  It can create a real loss of work.
> >
> >
> > Thanks.
> >
> >
> > Blake
> >
> >
> >
> > On Fri, Sep 12, 2014 at 6:18 PM, Chris Moller
> 
> > wrote:
> > 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
> > >
> > >
> >
> >
> >
> >
> 
> 
> 
> 

diff --git a/native/DefCommand.cc b/native/DefCommand.cc
index 7b07986..bba2278 100644
--- a/native/DefCommand.cc
+++ b/native/DefCommand.cc
@@ -72,7 +72,8 @@ void DefCommand::run_command( NetworkConnection &conn, const std::vectorget_ravel( 0 ).get_int_value();
+<< value->get_ravel( 0 ).get_int_value() -
+   Workspace::get_IO();
 }
 else if( value->is_char_string() ) {
 out << "function defined\n"

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

[David B. Lamkins]

Fixed and pushed.

On Sat, 2014-10-04 at 08:08 -0500, Blake McBride wrote:
> This is still a problem.  It can create a real loss of work.
> 
> 
> Thanks.
> 
> 
> Blake
> 
> 
> 
> On Fri, Sep 12, 2014 at 6:18 PM, Chris Moller 
> wrote:
> 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: line counter should start at zero

[David B. Lamkins]

Fixed and pushed.

Re: [Bug-apl] SVN 480 - assertion failure

[David B. Lamkins]

Thank you. Confirmed fixed.

I'll keep an eye open for stale values.


On Tue, 2014-09-30 at 18:03 +0200, Juergen Sauermann wrote:
> Hi David,
> 
> thanks, fixed in SVN 482.
> 
> The fix is part of a new release scheme that avoids scanning the ravel
> of non-nested APL values
> and should speed up the destruction of such values considerably. There
> is a small chance that
> previously nested stale values occur, please report them if so
> (command )CHECK).
> 
> /// Jürgen
> 
> 
> On 09/24/2014 10:06 PM, David B. Lamkins wrote:
> 
> > I haven't been able to reduce this to a simple test case. There's a
> > lot of context, some of which apparently contributes to this bug.
> > 
> > If I comment out the Assert() on Value.cc:58, my program proceeds
> > without error with no apparent ill effects; I get a clean report
> > from )CHECK.
> > 
> > With the Assert() in place, I see this stack trace:
> > 
> > ==
> > Assertion failed: containing_value == 0
> > in Function:  set_containing_value
> > in file:  Value.cc:58
> > 
> > Call stack:
> > 
> > 
> > -- Stack trace at Value.cc:58
> > 
> > 0x7fd7bc397d65 __libc_start_main
> > 0x43ec25  main
> > 0x55506d   Workspace::immediate_execution(bool)
> > 0x484182Command::process_line()
> > 0x479c55 Command::do_APL_expression(UCS_string&)
> > 0x48dc95  Executable::execute_body() const
> > 0x50aff0   StateIndicator::run()
> > 0x4b9db3Prefix::reduce_statements()
> > 0x4b4f96 Prefix::reduce_A_B__()
> > 0x54fbd4  Value::glue(Token&, Token&, Token&, char const*)
> > 0x54f882   Value::glue_closed_closed(Token&, Value_P, Value_P, char 
> > const*)
> > 0x4bb34ePointerCell::PointerCell(Value_P, Value&)
> > 0x54cd0c 
> > 0x44cdc1  do_Assert(char const*, char const*, char const*, int)
> > 
> > 
> > SI stack:
> > 
> > Depth:8
> > Exec: 0x277b4e8
> > Safe ex:  no
> > Pmode:∇ pkg⍙⍙apl_check[34]
> > PC:   129 (
> > Stat: z←(pkg⍙loading_prefix '') pkg⍙invalid_assign ↑tokens
> > err_code: 0x0
> > thrown:   at StateIndicator.cc:40
> > e_msg_1:  'No Error'
> > e_msg_2:  ''
> > e_msg_3:  ''
> > 
> > Depth:7
> > Exec: 0x21f7218
> > Safe ex:  no
> > Pmode:∇ pkg⍙import_apl[50]
> > PC:   403 (
> > Stat: →(2 check_fn l)/assign_error
> > err_code: 0x0
> > thrown:   at StateIndicator.cc:40
> > e_msg_1:  'No Error'
> > e_msg_2:  ''
> > e_msg_3:  ''
> > 
> > Depth:6
> > Exec: 0x2427f58
> > Safe ex:  no
> > Pmode:∇ pkg⍙load_one_package[10]
> > PC:   39 'z←
> > Stat: z←pkg⍙⍙apl_check pkg⍙import_apl fp
> > err_code: 0x0
> > thrown:   at StateIndicator.cc:40
> > e_msg_1:  'No Error'
> > e_msg_2:  ''
> > e_msg_3:  ''
> > 
> > Depth:5
> > Exec: 0x25bb548
> > Safe ex:  no
> > Pmode:∇ pkg⍙load[14]
> > PC:   70 'forms←
> > Stat: forms←pkg⍙load_one_package¨⊃ppl
> > err_code: 0x0
> > thrown:   at StateIndicator.cc:40
> > e_msg_1:  'No Error'
> > e_msg_2:  ''
> > e_msg_3:  ''
> > 
> > Depth:4
> > Exec: 0x2368488
> > Safe ex:  no
> > Pmode:∇ pkg⍙load_from_manifest[3]
> > PC:   19 RETURN_VOID
> > Stat: pkg⍙load¨pkg⍙read_manifest name
> > err_code: 0x0
> > thrown:   at StateIndicator.cc:40
> > e_msg_1:  'No Error'
> > e_msg_2:  ''
> > e_msg_3:  ''
> > 
> > Depth:3
> > Exec: 0x25b4af0
> > Safe ex:  yes
> > Pmode:⍎  pkg⍙load_from_manifest'system-1'
> > PC:   3
> > ==
> > Assertion failed: idx < items_valid
> > in Function:  operator[]
> > in file:  Simple_string.hh:136
> > 
> > Call stack:
> > *** do_Assert() called recursively ***
> > ==
> > 
> 

[Bug-apl] SVN 480 - assertion failure

[David B. Lamkins]

I haven't been able to reduce this to a simple test case. There's a lot
of context, some of which apparently contributes to this bug.

If I comment out the Assert() on Value.cc:58, my program proceeds
without error with no apparent ill effects; I get a clean report from
)CHECK.

With the Assert() in place, I see this stack trace:



==
Assertion failed: containing_value == 0
in Function:  set_containing_value
in file:  Value.cc:58

Call stack:


-- Stack trace at Value.cc:58

0x7fd7bc397d65 __libc_start_main
0x43ec25  main
0x55506d   Workspace::immediate_execution(bool)
0x484182Command::process_line()
0x479c55 Command::do_APL_expression(UCS_string&)
0x48dc95  Executable::execute_body() const
0x50aff0   StateIndicator::run()
0x4b9db3Prefix::reduce_statements()
0x4b4f96 Prefix::reduce_A_B__()
0x54fbd4  Value::glue(Token&, Token&, Token&, char const*)
0x54f882   Value::glue_closed_closed(Token&, Value_P, Value_P, char 
const*)
0x4bb34ePointerCell::PointerCell(Value_P, Value&)
0x54cd0c 
0x44cdc1  do_Assert(char const*, char const*, char const*, int)


SI stack:

Depth:8
Exec: 0x277b4e8
Safe ex:  no
Pmode:∇ pkg⍙⍙apl_check[34]
PC:   129 (
Stat: z←(pkg⍙loading_prefix '') pkg⍙invalid_assign ↑tokens
err_code: 0x0
thrown:   at StateIndicator.cc:40
e_msg_1:  'No Error'
e_msg_2:  ''
e_msg_3:  ''

Depth:7
Exec: 0x21f7218
Safe ex:  no
Pmode:∇ pkg⍙import_apl[50]
PC:   403 (
Stat: →(2 check_fn l)/assign_error
err_code: 0x0
thrown:   at StateIndicator.cc:40
e_msg_1:  'No Error'
e_msg_2:  ''
e_msg_3:  ''

Depth:6
Exec: 0x2427f58
Safe ex:  no
Pmode:∇ pkg⍙load_one_package[10]
PC:   39 'z←
Stat: z←pkg⍙⍙apl_check pkg⍙import_apl fp
err_code: 0x0
thrown:   at StateIndicator.cc:40
e_msg_1:  'No Error'
e_msg_2:  ''
e_msg_3:  ''

Depth:5
Exec: 0x25bb548
Safe ex:  no
Pmode:∇ pkg⍙load[14]
PC:   70 'forms←
Stat: forms←pkg⍙load_one_package¨⊃ppl
err_code: 0x0
thrown:   at StateIndicator.cc:40
e_msg_1:  'No Error'
e_msg_2:  ''
e_msg_3:  ''

Depth:4
Exec: 0x2368488
Safe ex:  no
Pmode:∇ pkg⍙load_from_manifest[3]
PC:   19 RETURN_VOID
Stat: pkg⍙load¨pkg⍙read_manifest name
err_code: 0x0
thrown:   at StateIndicator.cc:40
e_msg_1:  'No Error'
e_msg_2:  ''
e_msg_3:  ''

Depth:3
Exec: 0x25b4af0
Safe ex:  yes
Pmode:⍎  pkg⍙load_from_manifest'system-1'
PC:   3
==
Assertion failed: idx < items_valid
in Function:  operator[]
in file:  Simple_string.hh:136

Call stack:
*** do_Assert() called recursively ***
==

[Bug-apl] What is the correct key code for diamond?

[David B. Lamkins]

U+25CA (from src/Avec.def)

Re: [Bug-apl] aplwrap - bottom display

[David B. Lamkins]

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

[David B. Lamkins]

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 assertion failures

[David B. Lamkins]

Cool. Thanks for the report.

I rarely invoke aplwrap from a shell window (I usually use GNOME's
Alt-F2 launcher), so I tend to miss chatter sent to the terminal.


On Fri, 2014-09-12 at 15:18 -0500, Blake McBride wrote:
> Works for me now without errors.  Thanks to all!!
> 
> On Fri, Sep 12, 2014 at 2:30 PM, Chris Moller 
> wrote:
> 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
> > > > > > 
> > > > > > 
>

Re: [Bug-apl] aplwrap assertion failures

[David B. Lamkins]

I suspect it might have something to do with timing.

The window's "destroy" signal invokes aplwrap_quit(), which then
terminates the APL process.

The termination of the APL process invokes (due to the
g_child_watch_add() call) apl_exit(), which then tries to terminate the
APL process.

I suspect that, depending upon the details of one's kernel, scheduler
and GTK+, it's conceivable that (for the sake of supposition; I have no
concrete evidence this case could actually work) the window-destroy path
could complete and let aplwrap terminate before the secondary apl_exit()
call ever gets a chance to run.

That much seems plausible. (To me, at least.)

What I can't grok is how the clipboard content has anything to do with
the termination behavior. Maybe there's an extra content switch to send
the clipboard to the GNOME shell...?

On Fri, 2014-09-12 at 15:30 -0400, Chris Moller wrote:
> I just applied and pushed David's patch, the question remaining why it
> showed up only in some environments and not others.

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

[David B. Lamkins]

My supposition about the lock key(s) turned out to be correct. I was
able to reproduce Blake's issue by engaging Caps Lock.

Chris, I'll send you a patch.

On Fri, 2014-09-12 at 10:00 -0700, David B. Lamkins wrote:
> I just did a pull and recompile. The copy/paste works as expected.
> 
> 
> 
> Hmmm... thinking... looking at the code... 
> 
> I'll bet you have a lock key (shift lock? num lock?) engaged.
> 
> I'll have to go through and mask those out. Sorry...
> 
> Might not get to this until tonight...
> 
> 
> On Fri, 2014-09-12 at 12:52 -0400, Chris Moller wrote:
> > 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
> > >  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

[David B. Lamkins]

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

Re: [Bug-apl] aplwrap assertion failures

[David B. Lamkins]

Good idea. I'll give that a try tonight.

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

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

[David B. Lamkins]

I just did a pull and recompile. The copy/paste works as expected.



Hmmm... thinking... looking at the code... 

I'll bet you have a lock key (shift lock? num lock?) engaged.

I'll have to go through and mask those out. Sorry...

Might not get to this until tonight...


On Fri, 2014-09-12 at 12:52 -0400, Chris Moller wrote:
> 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
> >  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

[David B. Lamkins]

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

Re: [Bug-apl] aplwrap assertion failures

[David B. Lamkins]

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 needs to be able to edit paste lines

[David B. Lamkins]

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 needs to be able to edit paste lines

[David B. Lamkins]

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

[David B. Lamkins]

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