from:"Juergen Sauermann"


Hi,

thanks. fixed in SVN 112.

/// Jürgen

On 01/29/2014 08:45 AM, Elias Mårtenson wrote:
In the function Tokenizer::scan_real(), there is a call to exp10(). 
This function is unique to glibc and does not exist on OSX (and likely 
not on FreeBSD either, although I haven't checked).


Changing the call to exp10(x) to pow(10, x) makes it work.

Regards,
Elias

Re: [Bug-apl] Print width


Hi Kacper,

I see. I have changed back to the old ⎕PW behavior and made 79 the
default ⎕PW value. SVN version 113.

/// Jürgen

On 01/28/2014 08:55 PM, Kacper Gutowski wrote:

On 2014-01-28 14:23:01, Juergen Sauermann wrote:

that was on purpose because the default ⎕PW is 80 and on some
80 column terminals this causes an extra empty line to be printed.

If there are terminals like that, wouldn't it be easier to just initialize
⎕PW to 79 while keeping relation between this value and way wrapping occurs
the same as in other systems?  It's a bit annoying when you have some
pretty-printing functions that read value of ⎕PW to decide how to format
output.

Anyway, it's not that easy as width being ⎕PW-1.  When printing mixed
arrays X such that (⎕PW-1)=¯1↑⍴⍕X, i.e. ones that should fill the whole
line but not wrap, they sometimes get wrapped too.

   ⎕PW←30
   (⎕PW-1)⍴'X'
X
   10|⍳⎕PW÷2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   1,(⎕PW-3)⍴'X'
1 XXX
   1,⍨(⎕PW-3)⍴'X'⍝ Last element wrapped for no reason?
XXX
   1
   ⍕1,⍨(⎕PW-3)⍴'X'   ⍝ See? No reason at all.
XXX 1
   'X',1,(⎕PW-5)⍴'X' ⍝ ⋆Two⋆ lines printed.
X 1 X
   
   ⍕'X',1,(⎕PW-5)⍴'X'⍝ Single line as expected.

X 1 X

Especially take a look at the last example.  There is exactly nothing to
wrap but additional line still appears.

-k

Re: [Bug-apl] Mismatched free( )/delete/delete [ ], invalid read of 4 bytes, & uninitialized values


Hello Freg,

I checked that class Cell has no destructor, so delete and delete [] 
will not make a difference.


I have changed to delete [] to make valgrind happy, see SVN 114.

I will also look into your updated email but this will take a bit longer 
since I will be AFK for two weeks.


Best Regards,
Juergen



On 01/28/2014 06:53 PM, Frederick H. Pitts wrote:

Hello Jrgen,

With regard to item 1:

a) I've rerun the valgrind test against SVN 111 and valgrind still
complains.

b) Before I suggested adding the '[]' to the 'delete', I made the change
and performed the valgrind test.  Valgrind did not complain about double
deletions.  It is possible the APL program I'm using does not contain
code that triggers the double deletion.  Can you point me to or send me
APL code that triggers the double deletion if 'delete []' is used?

Also, please be aware that I've email'd a modified version of the
original email that points out additional places where valgrind detects
new/delete mismatches and a uninitialized value.

Regards,

Fred

Re: [Bug-apl] Inverse Tranfer Form fails to reconstruct variable


Hi Fred,

I believe you should use the variable name instead of the variable value 
with ⎕TF, eg:


1 ⎕TF 'R' instead of 1 ⎕TR R and

2 ⎕TF 'R' instead of 2 ⎕TR R

Also saw that you use -T -- cool!

Best Regards,
Juergen



On 01/29/2014 06:01 AM, Frederick H. Pitts wrote:

Gentle people,

Please find attached QUADTF.tc.gz. gunzip it and run apl (svn rev 110)
thus

apl --TM 2 -T QUADTF.tc

Examine QUADTF.tc.log and observe that the SCORES variable is not being
reconstructed in the workspace with either the migration or extended
form of the inverse transfer form.

Regards,

Fred

Re: [Bug-apl] Inverse Tranfer Form fails to reconstruct variable


Hi Fred,

I'm afraid you are right. Fixed in SVN 115.

I do have a regression test suite (almost every bug report is
entered into it). In the 1 ⎕TF case the test cases were wrong as well
since I did not notice the lacking ' on the inverse transformation.

/// Jürgen




On 01/29/2014 03:44 PM, Frederick H. Pitts wrote:

Hello Juergen,

Please see the third paragraph of the 'Informal Description' of 11.6.6
Transfer Form in ISO/IEC 13751:2000(E), page 185 and the example
presented in 'Creating the Inverse Transfer Form' in "APL2 Programming:
Language Reference", page 339.  Both references indicate the Inverse
Transfer Form expect the right hand argument to be the result of having
performed the forward Transfer Form, not the variable name the result
was assigned to.

Is anyone actively working on build a regression suite using -T?

Regards,

Fred

On Wed, 2014-01-29 at 14:23 +0100, Juergen Sauermann wrote:

Hi Fred,

I believe you should use the variable name instead of the variable value
with ⎕TF, eg:

1 ⎕TF 'R' instead of 1 ⎕TR R and

2 ⎕TF 'R' instead of 2 ⎕TR R

Also saw that you use -T -- cool!

Best Regards,
Juergen



On 01/29/2014 06:01 AM, Frederick H. Pitts wrote:

Gentle people,

Please find attached QUADTF.tc.gz. gunzip it and run apl (svn rev 110)
thus

apl --TM 2 -T QUADTF.tc

Examine QUADTF.tc.log and observe that the SCORES variable is not being
reconstructed in the workspace with either the migration or extended
form of the inverse transfer form.

Regards,

Fred

Re: [Bug-apl] Cleanup when SIGINT or SIGHUP is encountered


Hi Elias,

thanks, included in SVN 116.

/// Jürgen


On 01/29/2014 03:07 PM, Elias Mårtenson wrote:
Currently, the cleanup() function is never called when the process is 
killed. This causes the Emacs plugin to leave the socket file in /tmp. 
It would also prevent the terminal colour settings from being restored.


Attached is a patch that fixes this for these signals.

My only concern is with the naming of the "old" variable in the 
handler. The two variables, both having "old" in the name is ugly. :-)


Regards,
Elias

Re: [Bug-apl] Near-real numbers not handled properly

2014-02-11 Thread Juergen Sauermann


Hi,

thanks, fixed in SVN 117.

/// Jürgen


On 01/30/2014 10:23 PM, Kacper Gutowski wrote:

Hi,
It seems that functions requiring “near-real numbers” as arguments throw
DOMAIN ERROR when given a value represented internally as complex even
if imaginary part is exactly equal zero.

   1 > 0J0
DOMAIN ERROR
   1>0
   ^^
   1 ⌊ 0J0
DOMAIN ERROR
   1⌊0
   ^^
etc.

Note: from ISO's definition of near-real one can infer that 0J0 is always
near-real regardless of real-tolerance.  On the other hand 0J0 is never
demoted by GNU APL from complex to real.  This isn't relevant to examples
above but the problem initially hit me this way:

   ⌈/(3⍴2)⊤2
DOMAIN ERROR
   ⌈/(3⍴2)⊤2
   ^ ^


-k

Re: [Bug-apl] Small workspace of an example from "APL in Exposition" corrupts keyboard input after reload

2014-02-12 Thread Juergen Sauermann


Hi,

thanks, fixed in SVN 118.

/// Jürgen


On 02/02/2014 01:19 PM, ds.jaypee wrote:

Environment:
- GNU APL 1.2 or latest checkout from SVN, built from source
- OS X Mavericks, MacBookPro 8 GB RAM, More than 10 GB free disk space

Workspace,
- Manually edited and tested on Dyalog APL,
- Exported as UTF8 text
- Text sucessfully copied and pasted in clear Dyalog APL workspace, 
functions tested 'PARSE S3' provides expected result.

- Same text successfully copied and pasted in GNU APL, workspace saved

Problem:
Goal: Load Workspace in GNU APL, use and extend the functions
Fact: Loading is successful
Fact: After loading, PARSE '(A+B)' displays expected result
Symptom: After  loading input of APL characters is broken, iota is 
echoed as \U+00C3

Symptom: 'PARSE S3' crashes GNU APL

Attachment:
- APL source as text (with and without line numbers)
- Workspace XML

Jean-Pierre de SOZA

Re: [Bug-apl] "SYSTEM_LIMIT (fun_oper)" error

2014-02-12 Thread Juergen Sauermann

Hi Fred,

when designing derived functions I had the choice between a faster
variant that
uses pre-allocated memory for derived functions and a somewhat slower
variant
that uses dynamic memory allocation (i.e. new/delete directly or
indirectly (eg. vector<>)).

Since this happens on a performance critical path, I decided in favour
of the faster variant, assuming that
16 or so operators per statement is not too limiting. The downside was,
of course, a limit on the number
of operators per statement. The limit can be changed in file
*SystemLimits.def *line 22 to whatever makes sense;

the only effect is a little more memory consumed per )SI entry.

Increasing the limit does not help with the problem of Conway's "Game
of Life" because for every limit you

chose there is a number of iterations that will hit the limit.

As I have pointed out at
http://forums.anandtech.com/showthread.php?p=35685622, instead of reshaping

the statement S, one can iterate over S using each:

∇ N LIFE M
⍎¨N⍴⊂S←'⎕←''-''⍪M←(3=T)∨M∧2=T←⊃+/(V⌽¨⊂M),(V⊖¨⊂M),(V,⌽V)⌽¨(V,V←1 ¯1)⊖¨⊂M'
∇

This runs in constant space and does not hit a system limit.

/// Jürgen

On 01/31/2014 11:44 PM, Frederick H Pitts wrote:

Gentle people,

When I attempt to run the attached life.apl.gz (after uncompressing)
with

apl -f life.apl

partial output occurs and then "SYSTEM LIMIT (fun_oper) appears with the
offending apl statement after that. Investigation of the interpreter
source code reveals the "SYSTEM LIMIT (fun_oper)" message is emitted
because more than 16 operators are present in the apl statement as well
there should be since the statement was generated by catenating together
120 strings containing 4 dyadic each operators (¨) per string.
Admittedly this apl program is a contrived one-liner of Conway's "Game
of Life", but I can foresee the 16 operators per APL statement being too
restrictive for some "real" applications. Experimenting on my own, I
raised the limit to 4096 with no negative consequences that I could see.
What is the resource that is going to limit how many operators can
appear in a given statement and is 16 a reasonable number for that
limit? I hope the limit can be several orders of magnitude higher than
16.

If anyone is interested in running the program, run it as shown above
in a 43 by 132 ansi terminal with a huge scrollback buffer. After the
program completes, scroll to where the output starts and then page down
one screen at a time to see how "life" evolves. I've initialized the
game with the R-pentomino which generates lots of activity and takes
1103 generations to become stable. Of course you will have to increase
the MAX_FUN_OPER parameter in SystemLimits.def to run more than 3 or 4
generations.

Regards,

Fred Pitts
Retired Chemical Engineer

Re: [Bug-apl] Print width

2014-02-13 Thread Juergen Sauermann


Hi Kacper,

I have rewritten the ⎕PW line break algorithm.

A problem remaining is that there seems to be no precise description of
how this should look like, in particular for nested arrays.

The old algorithm tried to not break nested arrays (which caused the 
output to be longer than ⎕PW if

a nested item was big).

The new algorithm breaks at ⎕PW or earlier if possible.

Please let me know if you still have problems with the new algorithm.

Not sure, though, what is wrong with:

  ⎕PW⍴'='
==


/// Jürgen



On 02/02/2014 11:24 PM, Kacper Gutowski wrote:

As of revision 116, the problems with wrapping mixed arrays whose ⍕ is of
⎕PW width (or ⎕PW-1 before r113) still persist.

But there is another issue with wrapping which I think may be related.
When displaying nested vector whose elements are vectors, only the first
element is treated as expected.  All subsequent elements only start a new
line when they were to wrap and then continue without wrapping past ⎕PW.

   ⎕PW←30
   ⍴¨⍨,¨5 6 14
  5 5 5 5 5  6 6 6 6 6 6
14 14 14 14 14 14 14 14 14 14 14 14 14 14
   
   ⍴¨⍨,¨15 3 4 5 15

  15 15 15 15 15 15 15 15 15 15
15 15 15 15 15
3 3 3  4 4 4 4
5 5 5 5 5
15 15 15 15 15 15 15 15 15 15 15 15 15 15 15
   ⎕PW⍴'='
==


-k

Re: [Bug-apl] No errro message when defining functions using

2014-02-13 Thread Juergen Sauermann


Hi Elias,

not on my machine:

  ⎕FX 'foo[x]' 'x'
1
  )fns

Could it be that you had foo defined earlier?

The syntax error is then due to a niladic function called with an axis
(which is no a valid pattern in APL).

The return value of 1 is the index of the line that has caused the error 
(foo[x]).


/// Jürgen


On 02/07/2014 01:57 PM, Elias Mårtenson wrote:
When I try to define a function that takes no arguments, but does 
include an axis argument, the normal function editor complains:


*∇foo[x]*
bad editor command '∇foo[x]' : problem 'Bad function header at
Nabla.cc:495'
DEFN ERROR
  ∇foo[x]
^


However, if I try to define the same function using ⎕FX, it gets defined:

*⎕FX 'foo[x]' 'x'*
1
*)fns*
EMACS_NATIVEbar foo


But, it cannot be called:

*foo[1]*
1
SYNTAX ERROR
  foo[1]
  ^  ^


Regards,
Elias

Re: [Bug-apl] Unique of nested arrays doesn't work


Hi,

thanks, fixed in SVN 120.

/// Jürgen


On 02/07/2014 03:33 PM, Daniel H. Leidisch wrote:

Hello!

Unique with nested arrays results in a domain error:

   ∪1⍴¨1 2 3 4 1
DOMAIN ERROR
   ∪1⍴¨1 2 3 4 1
   ^
   ∪'foo' 'bar' 'baz' 'foo'
DOMAIN ERROR
   ∪'foo' 'bar' 'baz' 'foo'
   ^

Both examples work in Dyalog, NGN, and, according to their
documentation, MicroAPL. I'm at r116.


Regards,

Daniel

Re: [Bug-apl] Overbar not allowed in Gnu APL variable names but is in ISO/IEC 13751:2000(E)


Hi Fred,

I have added overbar to the characters allowed in variable names. see 
SVN 121.


I haven't seen ¯ in variable names either, but IBM APL2 supports them and
so do we now. Note that ∆ and ⍙ are also valid characters (even as first 
character) in names.


I would not use ⍺, ⍶, ⍵, and ⍹ because they have a special meaning in 
lambdas (aka. direct functions).
and should not (but can) be used outside lambdas. Using them outside 
lambdas may affect portability.


/// Jürgen


On 02/11/2014 12:06 AM, Frederick H. Pitts wrote:

Gentle persons,

On page 41 of ISO/IEC 13751:2000(E), the literal-identifier (which is
the same thing as a variable name) is defined to be composed of a letter
followed by zero or more letters, digits, underbars and overbars.  The
overbar is also used to distinguish negative numbers per the standards
document.

When I attempt to use the overbar in a variable name in Gnu APL, svn
116, a SYNTAX ERROR is reported.

I have to admit I've never seen the overbar used in an APL variable
name.  On the other hand, having more symbols to chose from when one is
creating variable names is a plus for me.  I am pleased to find that the
standalone alpha and omega symbols can be used as variable name.

Regards,

Fred

Re: [Bug-apl] Trouble with GNU APL 1.2


Hi Thomas,

looks more like a signed/unsigned problem to me. Or order
of constuctors.

I have made the order of constructors more explicit and I have
added some more information printed when this happens, see SVN 122.

Please let me know if this helps.

/// Jürgen


On 02/11/2014 07:10 AM, Thomas Baruchel wrote:

Hi Jürgen,

I just downloaded GNU APL 1.2 and compile dit with success on a Linux 64 bit 
computer. But it crashes at startup
(see screenshot attached). Is it a 64-bits problem (see the size of the Unicode 
code)?

Regards,

Re: [Bug-apl] A little APL plugin for Vim


Hi Thomas,

yes that was it. Cool.
Maybe its worthwhile to mention this in the .vim file.

/// Jürgen


On 02/14/2014 04:47 PM, baruc...@gmx.com wrote:

Juergen Sauermann  wrote:

in my vim it merely shows

:emenu APL.I

Hummm...

   :set wildmenu

is the key. I have it in my .vimrc but you can activate it on the fly for a try.

Regards,

Re: [Bug-apl] Potential performance optimisation tested


Hi,

I have added the proposed optimisation, SVN 123.
Hope it does not break anything.

/// Jürgen



On 02/02/2014 03:35 PM, Frederick H. Pitts wrote:

Elias,

This approach to optimizating Gnu APL sounds very reasonable to me.  I
hope it succeeds.  May Conway's "Game of Life" go faster. :-)

Fred

On Sun, 2014-02-02 at 21:19 +0800, Elias Mårtenson wrote:

I made a test implementation of a performance optimisation for GNU
APL. The short story is that it seems to work for limited tests, but
there may be issues with my approach and I don't want to spend any
more time on it unless Jürgen agrees it's a good idea. After all, I
may have completely misunderstood the architecture of GNU APL and my
approach may be fundamentally broken.


When doing some benchmarking I noticed a lot of time was spent
allocating, initialising and freeing Value instances. I realised that
many such allocations are not actually needed. Take the following
expression for example:


 ,1+2×foo


In this case, the following things happen:
  1. The multiplication function (implemented by eval_skalar_AB)
 creates a new array and fills it with the result of the
 operation (in this case, bif_multiply) on each cell.
  2. The addition function is then called, resulting in an
 identical flow as in the multiplication above.
  3. The ravel function is then called (Bif_COMMA::ravel),
 resulting in yet another array being created which is simply
 copied from B. Note that the ravel is identical between Z and
 B in this case.
 From a performance perspective, I saw a particular low-hanging fruit
in the ravel call in the last point. Since the value that came from
the addition is never used anywhere else, one can simply change the
shape of B in-place and return it immediately.


My experiment involved creating a new VF (value flag) value; VF_temp
that indicates that the value may be reused. This flag is then set for
all values that are only used once (for example, the return value from
a primitive or user function). If a value needs to be preserved, it is
copied, and the flag is not set.


What all of this means is that values that are returned from a
function, can be reused if it makes sense. There are several cases
where this is the case. For example:
   * The comma function (as discussed above)
   * Reshape, especially when the shape of Z matches that of B
   * Scalar functions. If the sizes of the arguments of plus, for
 example, matches, then A or B can be reused if they are marked
 as temporary.
   * The each operator can (maybe?) push the result straight into
 the source array.
I've only done very basic testing, but the ravel operator on a large
array went from taking a second or so to pretty much zero. Same should
be true for reshape, although that one crashes for me right now. :-)
  Scalar functions still have to process the elements, so their timing
can't go to zero, but at least the should save the time spent setting
up the result array and creating new values.


Please let me know what you think.


Elias

Re: [Bug-apl] Implementing realtime variable viewer support


Hi Elias,

I believe deriving from class Symbol is not the right way because there 
can be multiple
pointers to the original symbol around and when you simply replace a 
symbol in class Workspace

then you have a mix of the original and the new derived symbol.

I have therefore added a callback function in class Symbol that is 
called on changes of the symbol.


Use it like this:

void my_monitor(const Symbol & symbol, Symbol_Event sev)
{
   // ...
}

Symbol * monitored = ...

monitored->set_monitor_callback(my_monitor);   // start monitoring
monitored->set_monitor_callback(0);// stop monitoring

See SVN 124.

/// Jürgen


On 02/12/2014 05:58 AM, Elias Mårtenson wrote:
I was watching this video where they take advantage of the )ED command 
in Dyalog which supports realtime updated views of a variable: 
http://youtu.be/a9xAKttWgP4?t=5m2s


At 5:02 into the above video, the presenter types )ED variablename 
which opens a window that with the content of a variable. This is a 
very neat feature.


Obviously, I wanted to see the same thing in GNU APL (for myself, I'd 
like to see it in an Emacs buffer). So, I started work on this 
(exactly what method should be used to invoke this feature is a 
subject for a separate email thread which I will post shortly).


The key feature that is needed is a way to be informed when a variable 
is changed. Changes to a variable seems to be done through calls to 
method of Symbol. The key methods are Symbol::assign(), 
Symbol::assign_indexed() and Symbol::push_value().


The approach I started experimenting with is to create a subclass of 
Symbol which provides callback functionality when these methods are 
called, which I can then use to send a message to Emacs when the 
values are changed. I'm not done with this yet, so I'm not ready to 
say if this say if it works fully at this point.


Now, I would like to know three things:

  * Is my approach of subclassing Symbol the best way to do it?
Assuming it is, the question is:
  * How should I create the new subclassed symbol as a copy of the old
one? Would it make sense to create a copy constructor for this
class that the subclass can take advantage of?
  * Finally, I'd need to expose a function on Workspace that allows me
to replace a symbol with my monitorable (is that a word?) version.

I suppose an alternative approach to all of this would be to add the 
callback functionality right into the Symbol class, but that would 
have negative potential performance implications.


What are your thoughts on this?

Regards,
Elias

Re: [Bug-apl] External tools acting on interpreter commands (nabla and )ED)


Hi,

I dare to disagree. In my opinion the ∇ editor is very useful in APL 
scripts (not used as
interactive editor, but to define functions used later on in the 
script). Functions specified with
∇ are IMHO much more readable than functions specified with ⎕FX, in 
particular when they are long.


The advantage of having one more char available may not be worth the 
confusion and

incompatibilities that it may create.

/// Jürgen


On 02/12/2014 10:17 AM, Nick Lobachevsky wrote:

Function definition mode (typing ∇ followed by a symbol name) is an
artifact of the kind of terminal hardware supported by APL (the IBM
2741 with its iconic typeballs) in the 1960s.   As such, nearly 50
years later, it may be worth rethinking some of these things to take
advantage of newer editor and windowing technologies in common use.

In my opinion, in a windowed environment, function definition mode can
be safely disabled provided the system can provide an alternative
editor for functions and possibly variables.  In SS Windows, Dyalog
APL invokes an editor when you double click with the cursor positioned
over a name.  APL2000 invokes a full screen editor when you type ∇
followed by a name.  Function definition mode seems to be retained in
some implementations simply to be part of a faithful replica of
APL\360.

Removing function definition mode would have the side effect of
freeing the ∇ character for other uses.

Re: [Bug-apl] Unique of nested arrays doesn't work


Hi Kacper,

thanks, should be fixed in SVN 125.

/// Jürgen


On 02/14/2014 06:16 PM, Kacper Gutowski wrote:

On 2014-02-14 16:15:33, Juergen Sauermann wrote:

fixed in SVN 120.

In r122, it doesn't give domain error anymore, but I think that
results are not correct:

   ⎕RL
1
   8⎕CR Y←⊂[1]?2 10⍴2
┌→──┐
│┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐│
││2 2│ │2 2│ │2 1│ │1 1│ │2 2│ │1 2│ │1 1│ │2 2│ │1 2│ │1 2││
│└───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘│
└∊──┘
   8⎕CR Z←∪Y
┌→┐
│┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐│
││2 2│ │2 1│ │1 1│ │2 2│ │1 2│ │1 1│ │1 2││
│└───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘│
└∊┘
   8⎕CR ((Y⍳Y)=⍳⍴Y)/Y←,Y   ⍝ ←→ ∪Y
┌→──┐
│┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐│
││2 2│ │2 1│ │1 1│ │1 2││
│└───┘ └───┘ └───┘ └───┘│
└∊──┘
   Z[1] ≡ Z[4]
1


-k

Re: [Bug-apl] No errro message when defining functions using


Hi,

 I am afraid that the failed line number is about the granularity of 
error information available.
For finer location info (column number) the parser would need to track 
the column; currently it

doesn't.

Since ⎕FX is a system functions (which can be called many times) there 
is no interface to
provide the error cause. I could create a static member of class Parse 
that stores the last

parse error and/or its source location.

Note that the majority of parse errors in ∇ and ⎕FX are bad function 
headers. There are only a few
errors detected on the function body - they typically occur when a 
function is executed and not when

it is defined.

/// Jürgen


On 02/14/2014 07:05 AM, Elias Mårtenson wrote:
Thank you. I did not realise that the number indicated the line where 
the error occurred. I have updated the Emacs mode to display an error 
message and highlight the line where the error occurred now.


Is there a way to get more detailed information as to what the error 
was? Right now I simply display "Parse error" but it would be nice if 
it was a bit more precise.


Regards,
Elias


On 14 February 2014 01:35, Juergen Sauermann 
mailto:juergen.sauerm...@t-online.de>> 
wrote:


Hi Elias,

not on my machine:


  ⎕FX 'foo[x]' 'x'
1
  )fns

Could it be that you had foo defined earlier?

The syntax error is then due to a niladic function called with an axis
(which is no a valid pattern in APL).

The return value of 1 is the index of the line that has caused the
error (foo[x]).

/// Jürgen



On 02/07/2014 01:57 PM, Elias Mårtenson wrote:

When I try to define a function that takes no arguments, but does
include an axis argument, the normal function editor complains:

*∇foo[x]*
bad editor command '∇foo[x]' : problem 'Bad function header
at Nabla.cc:495'
DEFN ERROR
∇foo[x]
  ^


However, if I try to define the same function using ⎕FX, it gets
defined:

*⎕FX 'foo[x]' 'x'*
1
*)fns*
EMACS_NATIVEbar foo


But, it cannot be called:

*foo[1]*
1
SYNTAX ERROR
foo[1]
^  ^


Regards,
Elias

Re: [Bug-apl] Small workspace of an example from "APL in Exposition" corrupts keyboard input after reload


Hi Jean-Pierre,

I have debugged the matter a little further.

It seems like the readline library sometimes skips too few characters.

For example, after entering

  ∇C[⎕]∇

and then recalling the line and deleting the last character with Backspace,
the new line should be:

  ∇C[⎕]

However, it is actually ∇C[⎕] plus the first two bytes of the trailing ∇ 
(which has
3 bytes in UTF8 encoding). So the backspace only deletes the last byte 
instead of the last char.


I have no explanation yet why this occurs only after )LOADing a workspace.

As a short-term work-around I am now discarding the last char and print 
a short message,
rather than Assert()ing, see SVN 126. The behavior on my machine seems 
to be somewhat

different from yours.

I have put the issue on my mid-term TODO list. It could be that I have 
to remove

use of libreadline completely, which takes a while.

/// Jürgen



On 02/12/2014 09:07 PM, ds.jaypee wrote:

Hallo Jürgen,
I confirm that the crash is resolved.
However, the APL input corruption is still present.
Basically after reload, you cannot type any new APL character

Here is a screen dump, in case you cannot reproduce it in your 
environment:

Best regards,
Jean-Pierre

Re: [Bug-apl] Re : Re: Trouble with GNU APL 1.2


Hi Thomas,

your SVN checkout was correct.

I was on vacation for two weeks and I am working on the backlog that
has built up in the meantime.

/// Jürgen



On 02/16/2014 11:22 AM, Thomas Baruchel wrote:

looks more like a signed/unsigned problem to me. Or order
of constuctors.

I have made the order of constructors more explicit and I have
added some more information printed when this happens, see SVN 122.

Hi, I am not a great expert with SVN. I did:

  svn co svn://svn.savannah.gnu.org/apl/trunk

was it the right thing to do? Then I compiled and I have an UTF8 error/crash at 
startup again (see attached).

BTW. I got no answer for my readline proposal: 
http://lists.gnu.org/archive/html/bug-apl/2014-02/msg00032.html
Do you think it could be a good idea? Did you try the rlwrap trick in order to 
have a glance at the expected
result?

Regards,

Re: [Bug-apl] Problems with shared variables


Hi,

I believe the problems below are fixed in SVN 128.

Ad 1) I changed the assertions Symbol.cc to short warnings visible in )MORE.

The kill() should work now as well, looking at errno rather than
just the return value of kill().

Ad 2) hopefully fixed.

Ad 3) hopefully fixed.

I could further improve the shared variables for workspace-to-workspace
communication, but this is some effort and before doing it I would like to
know if someone is seriously interested in it. The idea would be a 
single process

managing all shared variables and TCP rather than UDP for communication with
that process.

/// Jürgen



On 02/12/2014 12:49 PM, Kacper Gutowski wrote:

Hello,
There are multiple problems with shared variables facility.


1. Shared variable protocol is not safe in multi user environment.

When user starts apl with shared variables enabled, it removes all
other users' sessions from shared database as “stale” so currently
even honest user without malicious intent will disrupt all the other
users' work if they use shared variables (their programs will fail
assertions at Symbol.cc:156 or 695).

It happens because users can't kill one another's processes.  But
please note that trying to work around this won't do any good as
there should be no reliable way of determining if other user's
process is alive.  But I don't think we want variables to be shared
between users in the first place (despite of what comment at
Svar_DB.cc:678 says).  I think that shm name should be suffixed
with UID or username and permissions should be set appropriately (0600).

If we really need it shared between users, it should not be possible to
destroy everything with simple dd if=/dev/urandom of=/dev/shm/apl-svars.
I don't know how it was technically done in APL2, but User's Guide
mentions some configuration file that described which shares were
allowed so presumably there was some control over it.



2. Annoying warnings about missing APs on general offer.

   0 ⎕SVO 'X'
No binary found for AP 0 (interpreter path = /usr/bin)
1

And also:

   ⎕SVQ⍬
Could not open /usr/bin/APs : No such file or directory



3. Shared variables not working correctly:

   • When number of elements on their ravel list exceeds 255,
 vectors are truncated to their length modulo 256 while higher
 rank arrays cause errors on reference.

   0⎕SVO'X'
No binary found for AP 0 (interpreter path = /usr/bin)
1
   X←⍳260
   X
1 2 3 4
   ⍴X
4
   X←16 16⍴0
   ⍴X
16 16
   X
DOMAIN ERROR
   X
   ^
   →
   5↑,X

==
Assertion failed: 0
in Function:  init
in file:  Cell.cc:47

Call stack:


-- Stack trace at Cell.cc:47

0x7f83c299c995 __libc_start_main
0x434105  main
0x51caed   Workspace::immediate_execution(bool)
0x4613cdCommand::process_line()
0x46032b Command::process_line(UCS_string&)
0x469128  Executable::execute_body() const
0x4dc660   StateIndicator::run()
0x48941aPrefix::reduce_statements()
0x4853e4 Prefix::reduce_MISC_F_B_()
0x4dd33f  StateIndicator::eval_B(Token&, Token&)
0x490546   Bif_F12_COMMA::eval_B(Value_P)
0x490388Bif_COMMA::ravel(Shape const&, Value_P)
0x458a11 Cell::init(Cell const&)
0x44293f  do_Assert(char const*, char const*, char const*, int)


SI stack:

Depth:0
Exec: 0x1feb4c0
Pmode:◊  5↑,X
PC:   3 VALUE3«5»
Stat: 5↑,X
err_code: 0x0
thrown:   at StateIndicator.cc:39
e_msg_1:  'No Error'
e_msg_2:  ''
e_msg_3:  ''


==


-- Stack trace at StateIndicator.cc:674

0x7f83c299c995 __libc_start_main
0x434105  main
0x51caed   Workspace::immediate_execution(bool)
0x4613cdCommand::process_line()
0x46032b Command::process_line(UCS_string&)
0x469128  Executable::execute_body() const
0x4dc660   StateIndicator::run()
0x48941aPrefix::reduce_statements()
0x4853e4 Prefix::reduce_MISC_F_B_()
0x4dd4aa  StateIndicator::eval_B(Token&, Token&)



   • When array is not simple.

   X←'abc' 'def'
   ⍴X
2
   X
DOMAIN ERROR
   X
   ^
   X←⊂1
   X
0


-k

Re: [Bug-apl] A suggestion concerning the readline library


Hi Thomas,

welcome to the world of APL!

I did not know rlwrap before, but I just installed it and tried APL with 
it. Cool!


As you may have seen there were some problems in GNU APL recently that seems
to be readline related. The root cause of these problems is still 
unknown. After having
GNU APL ./configured with  --without-readline and then started it from 
rlwrap, it looks
like these problems do not occur (more tests needed, though) and full 
readline functionality

is still there.

As you may have seen as well, Elias is working on emacs integration with 
GNU APL. It would
be good if there were a common solution for emacs, vim, and other 
editors. IBM APL2 has

an )EDITOR command while GNU APL has not (yet).

I personally find it strange to open an editor for a single line of 
input, but it makes sense to
do that for larger objects like APL functions or larger variables. For 
one-liners xterm combined

with middle-mouse-button copy/past is still the fastest way to edit.

I would be interested what is needed to start an editor via libreadline.

Best Regards,
Jürgen Sauermann


On 02/13/2014 05:18 PM, Thomas Baruchel wrote:

Hi, first of all, I am a new APL user; I wish to learn APL mostly with GNU APL 
(I installed NGN + nodejs as well as Dyalog APL on my raspberry however).
Since I have been coding in several other languages for many years, I would be 
happy to help if I can.

First of all, I started a new blog: http://apl-adventures.tumblr.com/ with all 
my experiments.

Please, could you have a look at my second "trick" on the following post: 
http://apl-adventures.tumblr.com/post/76529518369/some-tricks-for-using-apl-under-linux

In two words, I tried to launch GNu APL from rlwrap. It can sound weird since 
GNU APL has its own readline support, but I
found something very useful to me. rlwrap uses the readline library with a 
custom function allowing to launch an editor
from the readline library at any time for a one-line shot. (you hit 
Ctrl-something, you get your EDITOR (environment
variable) launched, Vim, emacs or whatever, you finish editing your line, you 
save, you leave, and you have your line
interpreted).

Since an APL line is something more complicated than a line in other languages 
(unicode characters, etc.), I think it could
be useful to do the same in GNU APL: define a special readline function (the 
user can decide to use it or not from his/her
own ~/.inpurtc file) and launch the EDITOR from the REPL.

I had a look at the GNU readline manual and found it should be quite easy to do 
it.

What do you think of the idea?

Regards,

Re: [Bug-apl] Unexpected DOMAIN ERROR when * is applied to conforming numeric vectors


Hi Fred,

thanks, fixed in SVN 129.

/// Jürgen


On 02/14/2014 06:17 PM, Frederick H. Pitts wrote:

Gentle people,

Please exercise the attached SHALLIT0.tc.gz to confirm that a DOMAIN
ERROR occurs on the last executable statement.  I'm currently using Gnu
APL, svn 117.

It appears that the DOMAIN ERROR occurs when the * function is applied
to

P * 0 1 0

where 0 1 0 is the third column of the intermediate 3 by 18 matrix
resulting from the evaluation of the expression to the right of the ×.⋆

Regards,

Fred
Retired Chemical Engineer

Re: [Bug-apl] Re : Re: Trouble with GNU APL 1.2


Hi Thomas,

I have found the root cause of your problem. It was non-ASCII characters 
(é) in the filename


/home/thomas/Téléchargements/GNUAPL/trunk/workspaces/CONTINUE

I have fixed this in SVN 130. There might be more such cases; pleas keep 
reporting them.


/// Jürgen



On 02/16/2014 11:22 AM, Thomas Baruchel wrote:

looks more like a signed/unsigned problem to me. Or order
of constuctors.

I have made the order of constructors more explicit and I have
added some more information printed when this happens, see SVN 122.

Hi, I am not a great expert with SVN. I did:

  svn co svn://svn.savannah.gnu.org/apl/trunk

was it the right thing to do? Then I compiled and I have an UTF8 error/crash at 
startup again (see attached).

BTW. I got no answer for my readline proposal: 
http://lists.gnu.org/archive/html/bug-apl/2014-02/msg00032.html
Do you think it could be a good idea? Did you try the rlwrap trick in order to 
have a glance at the expected
result?

Regards,

Re: [Bug-apl] Gnu APL and ANSI escape sequences


Hi Fred,

I believe you simply need to create the sequence and insert it into the 
other text as appropriate, eg:


  ESCSEQ←(⎕UCS 27),'[0;35;48m'⍝ RED foreground

  'Hello',ESCSEQ,'World'
HelloWorld

Note that ⎕UCS is more portable than ⎕AV or ⎕AF.

/// Jürgen


On 02/14/2014 10:04 PM, Frederick H. Pitts wrote:

Gentle people,

Is there a way for a Gnu APL program to send ANSI escape sequences to
the terminal in which the iterpreter is running?

If not, I wish to propose the following:  The ⍞ handling be extended by
implementing an alternative mode where only the content of the last
assign to ⍞ be retained in quote-quad-prompt instead of appending the
content of all consecutive assigns up to the point ⍞ is referenced. In
the alternative mode quote-quad-prompt should be emptied when ⍞ is
referenced, just like it is currently.  The alternative mode could be
activated by setting a boolean control flag (e.g., ⎕QQ ← 1 or maybe
adding another element to ⎕FC).  As the ⍞ handling currently works,
assigning a ANSI escape sequence to ⍞ produces the desired result on the
screen, but as soon as one references ⍞ (even after assigning a
character vector not containing escape sequences) garbage appears in the
user's response.

Please find attached ANSI_TEST.apl.gz.  The file demonstrates the above
issue.

If there is a way for Gnu APL to send escape sequences to its terminal,
please let me know and I apologize for wasting your time.

Regards

Fred
Retired Chemical Engineer

Re: [Bug-apl] Small workspace of an example from "APL in Exposition" corrupts keyboard input after reload


Hi Jean-Pierre,

I believe I found the reason for this problem, see SVN 132.

When the workspace is )LOADed or )COPYed and ⎕NLT is assigned.
Assigning ⎕NLT calls setlocale(), which in turn seems to mess up 
libreadline.


As of SVN 132:

* ⎕NLT is not assigned when )LOADing a workspace,
* when assigning ⎕NLT I call setlocale only if its value has changed,
* after calling setlocale() I call rl_initialize().

/// Jürgen



On 02/16/2014 04:39 PM, ds.jaypee wrote:

Hi Jürgen,

I've successfully tried this ugly workaround, it heals the symptom, 
not the cause...

In Workspace.cc/Workspace::load_WS()
[...]
   // got open file. We assume that from here on everything will be fine.
   // clear current WS and load it from file
   //
   the_workspace.clear_WS(CERR, true);
   in.read_Workspace();
   Input::init(); / Kludge alert ! /
   return Workspace::get_LX();
}
Regards,
Jean-Pierre

Le 15/02/2014 20:06, Juergen Sauermann a écrit :

Hi Jean-Pierre,

I have debugged the matter a little further.

It seems like the readline library sometimes skips too few characters.

For example, after entering

  ∇C[⎕]∇

and then recalling the line and deleting the last character with 
Backspace,

the new line should be:

  ∇C[⎕]

However, it is actually ∇C[⎕] plus the first two bytes of the 
trailing ∇ (which has
3 bytes in UTF8 encoding). So the backspace only deletes the last 
byte instead of the last char.


I have no explanation yet why this occurs only after )LOADing a 
workspace.


As a short-term work-around I am now discarding the last char and 
print a short message,
rather than Assert()ing, see SVN 126. The behavior on my machine 
seems to be somewhat

different from yours.

I have put the issue on my mid-term TODO list. It could be that I 
have to remove

use of libreadline completely, which takes a while.

/// Jürgen



On 02/12/2014 09:07 PM, ds.jaypee wrote:

Hallo Jürgen,
I confirm that the crash is resolved.
However, the APL input corruption is still present.
Basically after reload, you cannot type any new APL character

Here is a screen dump, in case you cannot reproduce it in your 
environment:

Best regards,
Jean-Pierre

Re: [Bug-apl] Re : Re: Trouble with GNU APL 1.2


Hi Thomas,

single-expression lambdas should work already in the latest SVN version,
only the documentation is missing.

Multi-line and multi-statement lambdas will not be implemented because I
believe they are awkward and turn APL into a different language.

/// Jürgen


On 02/17/2014 12:54 PM, baruc...@gmx.com wrote:

Juergen Sauermann  wrote:

I have found the root cause of your problem. It was non-ASCII characters
(é) in the filename

Thank you very much for all your work; it seems to work fine now.

Do you already have an idea of the release date of the version allowing direct 
definition?

Regards,

Re: [Bug-apl] Implementing realtime variable viewer support


Hi Elias,

The name of a Symbol uniquely identifies a symbol within one Workspace 
(and there is only one Workspace).


The only cases where the pointer changes is when a new workspace with 
the same symbol name

is loaded or when the symbol is explicitly )ERASEd or  ?EXed.

I all these cases you should get an SEV_ERASED event via the callback 
function.

After that event the pointer is no longer valid and should be discarded. You
should never ignore an SEV_ERASED event.

/// Jürgen


On 02/16/2014 05:03 PM, Elias Mårtenson wrote:

Hello Jürgen,

In my work to implement the variable viewer, I need some information 
from you, if you are willing to share.


When the user closes the last trace window for a symbol, the system 
needs to unregister the listener for this symbol. This means I need to 
know what I can use to uniquely identify a symbol.


Since there can be multiple symbols with the same name in different 
workspaces, I clearly can't use the name as identifier.


The easiest thing to use would of course be the pointer to the Symbol 
instance itself. However, I don't know if I can rely on this never 
changing. Can this instance ever be changed? I.e. can I use &symbol as 
a key into a std::map that tracks all active listeners?


Regards,
Elias

Re: [Bug-apl] Dyadic / (replicate) does not work with ¨ (each)


Hi,

I have changed the parser to degrade / and friends from operator to 
function in the examples below.


One remaining case is (with / any of / ⌿ \ or ⍀):

S//B

where the left / is a function when S is a value and and an operator if 
S is a
function (which is not known at parse time). The binding rules do not 
help in this

case because there are different bindings when / is a function and when
/ is an operator. Both cases are valid. To deal with this special case,
one can put S in parentheses:

(S)//B

In that case S is assumed to be a value (and the left / is function 
compress).


See SVN 133.

/// Jürgen


On 02/15/2014 07:49 AM, Nick Lobachevsky wrote:

The / and \ symbols (and their first coordinate versions ⌿ and ⍀) were
overloaded from the start.  Not enough characters on the 2741 typeball
or something.  Symbol pressure.
First, they are the compression and expansion functions.
1 0 1 / 1 2 3
Second, they are the reduction and scan operators.
+/1 2 3
This was well and good until the introduction of APL2 language
extensions such as allowing user functions and functions other than
the 21 scalar dyadic functions as the function argument to scan and
reduction (plus/1 2 3).  Now use of / in the context of an operator
argument results in a syntactic ambiguity.  For more info, check APL2
binding strength.

http://www.scribd.com/doc/124733639/APL2-Language-Reference-Manual

There were some papers from Phil Benkhard at IBM.

Normally, the workaround to this problem was for the programmer to
supply a cover function for reduction, exactly as in your example.
IBM APL2 and APL2000 would need this.  Dyalog, however, has got this
to work, but not without consequences.  Consider the following:

   //(1 0 1) (1 2 3)
1 3

This would read as "compress reduction".  (In C++ and Java etc. it
would be a comment)

Dyalog also has a system function called []VFI, a kind of portmaneu of
[]VI and []FI, introduced by STSC in the 1960s, available today with
APL2000.  []VI '1 2 3 cat' would return 1 1 1 0, the 1s marking valid
numbers, while []FI '1 2 3 cat' would return 1 2 3 0, converting valid
strings to numbers and invalid ones to zero.  A typical usage might be
([]VI x)/[]FI x.  Dyalog combined them together, such that []VFI '1 2
3 cat' would return a nested vector (1 1 1 0).  But I digress, but to
show there actually exists a practical application.

   //⎕VFI '1 2 3 cat'
1 2 3

But now try

   +///⎕VFI '1 2 3 cat'
LENGTH ERROR

   +/⊃(//)⎕VFI '1 2 3 cat'
  1 2 3

This would be a "plus reduction compress reduction", which also does
not return the expected answer of 6.

   +/⊃//⎕VFI '1 2 3 cat'
LENGTH ERROR

   +/⊃(//)⎕VFI '1 2 3 cat'
6

This works in Dyalog, possibly some others.  Plus reduction reduce,
and this works because of the (relatively) new dyadic reduction, 2+/1
2 3 4 5.

   +//(2) (1 2 3 4 5)
  3 5 7 9

In short, to avoid this problem altogether, possibly to avoid
introducing problems in the language parser, some implementations may
disallow / and \ functions as operator arguments.

Re: [Bug-apl] Unterminated strings does not result in error

2014-02-18 Thread Juergen Sauermann


Hi Elias,

this is a feature.

/// Jürgen


On 02/18/2014 04:38 AM, Elias Mårtenson wrote:

If I type the following:

*'foo*


It is parsed as:

*'foo'*


Instead of giving an error. Is this expected behaviour? To me, it 
would make much more sense if this was flagged as a syntax error.


Regards,
Elias

Re: [Bug-apl] Calling Value::print() with different ⎕PW

2014-02-18 Thread Juergen Sauermann


Hi Elias,

normally you do something like this:

// const Value & value;

PrintContext pctx(style, Workspace::get_PP(), Workspace::get_CT(), 
Workspace::get_PW());

PrintBuffer pb(value, pctx);
UCS_string ucs(pb, value.get_rank(), pctx.get_PW());
...

You can use your own ⎕PW value instead of Workspace::get_PW() above.

It is generally a bad idea if programs or functions other then the 
interpreter itself modify the data structures
of the interpreter because the functions of the interpreter make certain 
assumptions regarding the state of
its data structures. If other functions modify these data structures, 
then it becomes impossible for me to

maintain the interpreter.

/// Jürgen



On 02/18/2014 04:58 AM, Elias Mårtenson wrote:
In my native code, I would like to be able to get a printable 
representation of a Value_P as if ⎕PW was set to some very large value 
(effectively unlimited).


What is the most efficient way to do this?

I was trying to call assign on the return value from 
Workspace::get_v_Quad_PW(), but I got a DOMAIN ERROR (I suppose I made 
some silly mistake somewhere though) but I don't think that might be 
the best way to it.


Regards,
Elias

Re: [Bug-apl] Question regarding the power operator (as in Dyalog APL)

2014-02-18 Thread Juergen Sauermann


Hi Thomas,

currently the power operator is not on my TODO list. I may implement it
at some point in time, but the mere fact that it is described in 
"Mastering Dyalog APL"

- which is a very good book - does not suffice.

In most cases the power operator can be replaced with a simple loop (I 
know that
the functional programmers don't like that :-) ) or by the EACH 
operator, eg.


(⍳5){Z←Z+1}¨Z←2

/// Jürgen


On 02/18/2014 01:15 PM, baruc...@gmx.com wrote:

Hi,

as a newbie to APL, I bought "Mastering Dyalog APL" in order to discover
the language; I am aware that several variants exist, and I want to use
GNU APL as much as possible because of its license.

Coming from functional programming and J, I miss the "power" operator
which is described in "Mastering Dyalog APL" and which does exist in J.
In Dyalog APL, the symbol ⍣ (U2363) is mapped to such a feature, which is
very useful for some "loopless pieces of code" as well as for inserting
some "inline" conditional structures.

Do you think such an operator may be implemented in GNU APL as well?

Best regards,

Re: [Bug-apl] Novice question regarding APL

2014-02-19 Thread Juergen Sauermann


Hi Thomas,

you can use ⎕INP like this:

TEXT←⎕INP 'END-OF-TEXT' ⍝ the subsequent lines until 'END-OF-TEXT'
1 1 1 0 0 0
1 0 0 0 0 0
0 1 0 0 0 0
1 1 1 1 1 1
0 0 0 1 0 0
0 0 0 0 1 0
'END-OF-TEXT'

MATRIX←⊃⍎¨TEXT

/// Jürgen


On 02/19/2014 07:28 AM, baruc...@gmx.com wrote:

Hi Jürgen,

I  can now solve my first problems from the Project Euler with GNU APL.
I am very happy with that.

But I couldn't figure out how I can directly embed a matrix in a script file
(other than reshapping a huge single-line vector).

For instance, here is my solution in J programming language for problem n° 191 
(Project Euler) :

 matrix =: (". ;. _2) 0 : 0
   1 1 1 0 0 0
   1 0 0 0 0 0
   0 1 0 0 0 0
   1 1 1 1 1 1
   0 0 0 1 0 0
   0 0 0 0 1 0
 )
 
 echo +/ (matrix&(+/ .*)) ^: 29 ] 1 1 0 1 0 0


Is there a way of including such a multiline matrix in a GNU APL script file?

Thank you very much,

best regards,

Re: [Bug-apl] How to get SEV_ERASED event?

2014-02-19 Thread Juergen Sauermann


Hi,

A←1 2 3
⎕EX 'A'

/// Jürgen


On 02/19/2014 10:15 AM, Elias Mårtenson wrote:
I have a hard time testing the Emacs mode's treatment of SEV_ERASE, as 
I can't seem to get such event. Nothing I tried (including calling 
)ERASE on it) causes this to happen.


When is this event sent?

Regards,
Elias

Re: [Bug-apl] Lambda functions are not loaded from a workspace

2014-02-19 Thread Juergen Sauermann


Hi,

thanks, fixed in SVN 134.

/// Jürgen


On 02/19/2014 08:04 AM, Elias Mårtenson wrote:
When loading a workspace that was previously saved using the )SAVE 
command, any functions defined using name←{...} are not loaded.


The functions are there, as they can be seen in the XML file, but they 
are ignored when loading.


Regards,
Elias

Re: [Bug-apl] Problems with shared variables

2014-02-20 Thread Juergen Sauermann


Hi,

thanks, should work in SVN 136.

/// Jürgen


On 02/20/2014 11:57 AM, Kacper Gutowski wrote:

On 2014-02-16 18:09:06, Juergen Sauermann wrote:

Ad 1) I changed the assertions Symbol.cc to short warnings visible in )MORE.

I wouldn't guess to check )MORE upon getting VALUE ERROR on shared
variable, but I guess it's better than failed assertion.


Ad 3) hopefully fixed.

I've mistakenly put example X←1 under this point, but a simple scalar
of 1 is changed to 0.  This is still broken in r135:

   0⎕SVO'X'
1
   X←1
   X
0
   X←2
   X
2


I could further improve the shared variables for workspace-to-workspace
communication, but this is some effort and before doing it I would like to
know if someone is seriously interested in it. The idea would be a
single process
managing all shared variables and TCP rather than UDP for communication with
that process.

It appears to work correctly for cooperating users now.  Malicious user,
however, can still easily destroy other users' coupling of shared variables.
I'm not going to push for changing it right now because I don't see any way
to exploit it beyond denial of service and I'm not using shared variables
for anything serious, but I think that it should be done eventually.


-k

Re: [Bug-apl] Problems with shared variables

2014-02-20 Thread Juergen Sauermann

Hi,

the normal 3-line error printout is documented by IBM and shall remain 
as is for compatibility.

I will, however, put more information about errors in )MORE such as file 
names, strerror() stings and the like.

Pleas feel free to indicate where the information related to errors is 
not sufficient.

/// Jürgen

On 02/20/2014 12:16 PM, Elias Mårtenson wrote:

On 20 Feb 2014 18:57, "Kacper Gutowski" <mailto:mwgam...@gmail.com>> wrote:

>
> On 2014-02-16 18:09:06, Juergen Sauermann wrote:
> > Ad 1) I changed the assertions Symbol.cc to short warnings visible 
in )MORE.

>
> I wouldn't guess to check )MORE upon getting VALUE ERROR on shared
> variable, but I guess it's better than failed assertion.

Hmm, this makes me think about a new feature for the Emacs mode: some 
kind of warning in the modeline when there is an unread )MORE message.

Would this be useful? Do you get these kinds of messages often? I 
rarely look for it.

> It appears to work correctly for cooperating users now.  Malicious user,
> however, can still easily destroy other users' coupling of shared 
variables.
> I'm not going to push for changing it right now because I don't see 
any way
> to exploit it beyond denial of service and I'm not using shared 
variables

> for anything serious, but I think that it should be done eventually.

I suppose some proper authentication and authorisation mechanism is 
needed too. Then comes the question of encryption. Things like 
Kerberos is easy to add and is powerful. However, it does require 
infrastructure a lot of people don't have.

Regards,
Elias

Re: [Bug-apl] Bug when assigning variable to result of function call on self


Hi Elias,

yes. Fixed in SVN 137.

/// Jürgen


On 02/21/2014 04:02 AM, Elias Mårtenson wrote:
On 20 February 2014 17:24, Kacper Gutowski > wrote:


In this function, next is 2 (a label) rather than function you
defined earlier.  So you literally have [3] S←2 S.


Thank you. This explains the problem. Very silly of me.

The crash when saving the resulting workspace should still be a bug 
though, yes?


Regards,
Elias

Re: [Bug-apl] Problems with shared variables

Hi,

I believe )MORE should somehow be aligned with the display of other errors.
The theory seems to be that when an error occurs then a rather rigidly 
formatted,

3-line error output is produced:

VALUE ERROR
  a+5
  ^

Line 1 is the name of the error, line 2 the offending input and line 3 
showing

one or two carets marking the token in line 2 that have caused the error.

Unfortunately line 1 is not very verbose about further details.
In this situation, )MORE may show more details about the error.
In theory, line 1 should show a + at the end when )MORE has more 
information.

like in:

VALUE ERROR+

I haven't done that yet, because I was not using )MORE in the beginning. 
I'll add that.

/// Jürgen

On 02/21/2014 03:47 AM, Elias Mårtenson wrote:

Jürgen,

I will put a check for )MORE availability in the end_input function 
and display a notification in Emacs when it contains something. Would 
this be the right approach?

Regards,
Elias

On 20 February 2014 23:44, Juergen Sauermann 
mailto:juergen.sauerm...@t-online.de>> 
wrote:

Hi,

the normal 3-line error printout is documented by IBM and shall
remain as is for compatibility.

I will, however, put more information about errors in )MORE such
as file names, strerror() stings and the like.

Pleas feel free to indicate where the information related to
errors is not sufficient.

/// Jürgen

On 02/20/2014 12:16 PM, Elias Mårtenson wrote:

On 20 Feb 2014 18:57, "Kacper Gutowski" mailto:mwgam...@gmail.com>> wrote:
>
    > On 2014-02-16 18:09:06, Juergen Sauermann wrote:
> > Ad 1) I changed the assertions Symbol.cc to short warnings
visible in )MORE.
>
> I wouldn't guess to check )MORE upon getting VALUE ERROR on shared
> variable, but I guess it's better than failed assertion.

Hmm, this makes me think about a new feature for the Emacs mode:
some kind of warning in the modeline when there is an unread
)MORE message.

Would this be useful? Do you get these kinds of messages often? I
rarely look for it.

> It appears to work correctly for cooperating users now.
 Malicious user,
> however, can still easily destroy other users' coupling of
shared variables.
> I'm not going to push for changing it right now because I don't
see any way
> to exploit it beyond denial of service and I'm not using shared
variables
> for anything serious, but I think that it should be done
eventually.

I suppose some proper authentication and authorisation mechanism
is needed too. Then comes the question of encryption. Things like
Kerberos is easy to add and is powerful. However, it does require
infrastructure a lot of people don't have.

Regards,
Elias

Re: [Bug-apl] More "Mismatched free() / delete / delete []" valgrind errors


Hi Fred,

thanks, fixed in SVN 140.

/// Jürgen


On 02/21/2014 03:18 AM, Frederick H. Pitts wrote:

Gentle people,

In Gnu APL file file_io.cc, lines 597, 617, and 643, `[]' should be
inserted between the `delete' and `del' to match the `new char
[ bytes ... ]' on lines 591, 612, and 636, respectively.

Regards,

Fred
Retired Chemical Engineer

Re: [Bug-apl] Another problem with direct-functions


Hi,

yes. fixed in SVN 142.

/// Jürgen


On 02/21/2014 10:04 PM, baruc...@gmx.com wrote:

Is this another bug:

   R ← { ⍵ }¨⍳15

works in Dyalog APL and NGN APL but not in GNU APL.

Regards,

Re: [Bug-apl] APL line editor: proof of concept (c code)


Hi Thomas,

could be a cool thing. One thing that I am missing is a bit
more information of what it exactly does and how it should
integrate with GNU APL (for example).

Currently I am trying to keep keyboard input and fonts
out of GNU APL as much as possible. The reason is that
different platforms (and different users) have different
means and preferences how they get their keystrokes
into GNU APL.

Simply speaking, GNU APL expects an UTF8-encoded byte
stream on stdin and writes an UTF8-encoded byte stream
to stdout.

Even though GNU APL uses libreadline, it can be ./configured
to run without. My personal feeling regarding libreadline is
somewhat mixed; it has saved me a considerable amount of time
initially, but it has also caused problems in areas where I would
not have expected them in the first place (platforms with 8-bil libreadline,
and native language support to name a few).

My current thinking of how a keyboard mapper should work with
GNU APL is that it should be a stand-alone binary, say mapper,
which produces a UTF8-encoded byte stream that can be piped into GNU APL:

mapper  | apl 

The mapper can then be wrapped into a 2-line script which starts the
above pipe, so that the user does not need to do it every time.

The mapper can then either be distributed with GNU APL (if you want to) or
you can put it on your own URI and I can put a link to it in our 
README-3-keyboard

file.




On 02/23/2014 10:30 PM, baruc...@gmx.com wrote:

Hi, I created a repository on Github. I also created an animation.
Please, have a look at https://github.com/baruchel/APLedit
(then click on apledit.gif and then probably on "raw" in order to
have it in a larger size).

Please, have a look at this animation and tell me what you think of the idea.

I have to figure out now how I will make it interact with GNU APL
(either FIFO or wrapper or something else).

Best regards,

Re: [Bug-apl] No ubuntu packages


Hi Akiva,

not sure if I don't understand the subject?

You can create Debian packages with make DEB in the top-level
directory (provided that you have the necessary debian tools installed).

/// Jürgen


On 02/24/2014 09:29 AM, Akiva wrote:

Also, may be interested in contributing on non-core stuff. I am thinking
of starting a basic gnu apl calculator program in QT.

Thanks; I am really excited about this language.

Re: [Bug-apl] Crash when forgetting to close lambda function


Hi,

thanks, fixed in SVN 145.

/// Jürgen

On 02/25/2014 05:17 PM, Elias Mårtenson wrote:
Very easy to reproduce this one. Simply type a single *{* character. 
This will crash GNU APL with the following stack trace:


Token: 0x4C03001B { at Token.cc:490
(void *)get_Class(): '0x1b' at Token.cc:491


-- Stack trace at Token.cc:492

0x7fc7f415bde5 __libc_start_main
0x4342f5  main
0x51cf6d Workspace::immediate_execution(bool)
0x46180d  Command::process_line()
0x46073b Command::process_line(UCS_string&)
0x4696f8  Executable::execute_body() const
0x4dc830 StateIndicator::run()
0x48a934  Prefix::reduce_statements()
0x488442 Prefix::syntax_error(char const*)
0x46866d  throw_apl_error(ErrorCode, char const*)
0x4e0b5b StateIndicator::update_error_info(Error&)
0x469d88  Executable::set_error_info(Error&, Function_PC2) const
0x4ff8cd   Token::error_info(UCS_string&) const
0x4ff585Token::canonical(PrintStyle) const



-- Stack trace at Token.cc:493

0x7fc7f415bde5 __libc_start_main
0x4342f5  main
0x51cf6d Workspace::immediate_execution(bool)
0x46180d  Command::process_line()
0x46073b Command::process_line(UCS_string&)
0x4696f8  Executable::execute_body() const
0x4dc830 StateIndicator::run()
0x48a934  Prefix::reduce_statements()
0x488442 Prefix::syntax_error(char const*)
0x46866d  throw_apl_error(ErrorCode, char const*)
0x4e0b5b StateIndicator::update_error_info(Error&)
0x469d88  Executable::set_error_info(Error&, Function_PC2) const
0x4ff8cd   Token::error_info(UCS_string&) const
0x4ff594Token::canonical(PrintStyle) const



Regards,
Elias

Re: [Bug-apl] Regression: Lambda functions can no longer be assigned to a variable


Hi,

thanks. Should work again in SVN 146.

Unfortunately the rules governing the syntax of {} are not standardised and
still somewhat unclear to me.

/// Jürgen


On 02/25/2014 05:19 PM, Elias Mårtenson wrote:
This used to work a few versions back, now I'm just getting a SYNTAX 
ERROR:


*foo ← {⍵}*
SYNTAX ERROR
foo←λ1
^   ^
They still work as arguments to operators though:

*{⍵+1}¨1 2 3*
2 3 4

Regards,
Elias

Re: [Bug-apl] Strange text corruption when sending a list to ⍞

2014-02-27 Thread Juergen Sauermann


Hi,

thanks, fixed in SVN 147.

/// Jürgen


On 02/27/2014 11:02 AM, Elias Mårtenson wrote:

When I type the following:

*⍞←1,'x'*


I get a strange result:

1#x


Were # is a non-existing Unicode character (codepoint U+).

Regards,
Elias

Re: [Bug-apl] Bug with lambda functions

2014-02-28 Thread Juergen Sauermann


Hi,

thanks, fixed in SVN 148.

/// Jürgen


On 02/28/2014 01:35 PM, baruc...@gmx.com wrote:

Hi,

I have a bug with:

   ( { ⍵ }¨⍳10 ), ( { - ⍵ }¨ ⍳10)

two lambda on the same line???

Regards,

Re: [Bug-apl] Getting list of quad-commands and system commands

2014-03-01 Thread Juergen Sauermann


Hi Elias,

for commands, you can #define macro cmd_def() and then #include Command.def.
For Quad-vars you can #define macros ro_sv_def() and rw_sv_def and then 
#include SystemVariable.def.


For example, to get the strings for all commands:

#define cmd_def(cmd_str, code, _arg) #cmd_str
#include "Command.def"

To get the strings for all quad variables:

#define ro_sv_def(var) #var
#define rw_sv_def(var) #var
#include "Command.def"

In the latter case you need to replace "Quad_" by "⎕". Or #define
the macro as ID_ ## x (which gives an enum Id) and call id_name() on it
to get an UCS_string.

/// Jürgen


On 03/01/2014 02:42 PM, Elias Mårtenson wrote:
I've recently added smart expansion of symbols in the Emacs mode 
(press TAB and get a list of suggested variable and function names). 
I'd like it to be able to expand system commands and quad commands as 
well. Of course, I could simply hard-code the list of available 
commands, but it would be neater if there was a way of accessing this 
from GNU APL itself.


Also, since the expansion list has room for a description, it would be 
even more awesome if I could access a one-line description of these 
commands and variables. Of course, I could include it on my side, but 
this is something that's useful for not only the Emacs mode, but for 
any user of GNU APL, so would it make sense to include this 
information in the interpreter itself (I'd access it through an API, 
while it can also be made available from some kind of help command 
from the commandline).


Regards,
Elias

Re: [Bug-apl] Getting list of quad-commands and system commands

2014-03-01 Thread Juergen Sauermann


Hi,

providing descriptions of functions is a lot of work. Most people know 
APL after
a short while, and those who need it are probably better off with a good 
APL book.


I wanted to wait with the next release until the rate of error reports 
goes down a little.
Right now it seems to get a little more quiet, so maybe in two weeks 
from now?


/// Jürgen


On 03/01/2014 05:22 PM, Elias Mårtenson wrote:

Thanks. Looks easy enough.

What do you think of the idea of having descriptions of the functions 
embedded in the APL interpreter instead of in the Emacs mode?


Secondly, when do you plan to release 1.3?

Regards,
Elias


On 1 March 2014 23:50, Juergen Sauermann 
mailto:juergen.sauerm...@t-online.de>> 
wrote:


Hi Elias,

for commands, you can #define macro cmd_def() and then #include
Command.def.
For Quad-vars you can #define macros ro_sv_def() and rw_sv_def and
then #include SystemVariable.def.

For example, to get the strings for all commands:

#define cmd_def(cmd_str, code, _arg) #cmd_str
#include "Command.def"

To get the strings for all quad variables:

#define ro_sv_def(var) #var
#define rw_sv_def(var) #var
#include "Command.def"

In the latter case you need to replace "Quad_" by "⎕". Or #define
the macro as ID_ ## x (which gives an enum Id) and call id_name()
on it
to get an UCS_string.

/// Jürgen



On 03/01/2014 02:42 PM, Elias Mårtenson wrote:

I've recently added smart expansion of symbols in the Emacs
mode (press TAB and get a list of suggested variable and
function names). I'd like it to be able to expand system
commands and quad commands as well. Of course, I could simply
hard-code the list of available commands, but it would be
neater if there was a way of accessing this from GNU APL itself.

Also, since the expansion list has room for a description, it
would be even more awesome if I could access a one-line
description of these commands and variables. Of course, I
could include it on my side, but this is something that's
useful for not only the Emacs mode, but for any user of GNU
APL, so would it make sense to include this information in the
interpreter itself (I'd access it through an API, while it can
also be made available from some kind of help command from the
commandline).

Regards,
Elias

Re: [Bug-apl] Problems with shared variables

2014-03-02 Thread Juergen Sauermann


Hi Kacper,

thanks for reporting this. I believe I have fixed this in SVN 149.

There is now a system limit of 65kByte for the size of shared
variables, caused by the UDP protocol used for the communication
between processors.

/// Jürgen


On 03/02/2014 07:42 AM, Kacper Gutowski wrote:

Moreover, integral values in range 1+2⋆31 to (2⋆32)-1
are incorrectly interpreted as their two's complement
negative equivalents:

   0⎕SVO'X'
1
   X←1+2⋆31
   X
¯2147483647


-k



Hi again,

There are still (r148) some problems similar to previously reported.
When passing a big array as shared variable, instead of being
truncated, now its tail is corrupted:

  0⎕SVO'X'
1
  X←489⍴2
  ¯2↑X
2 ¯1254096894

This suggests some nasty out-of-bounds read.
And, if array is even bigger, it gives the following error (after
a few seconds):

  X←3000⍴4
TIMEOUT on signal ASSIGN_VALUE_c
VALUE ERROR
  X←3000⍴4
  ^

-k

Re: [Bug-apl] Commute compress

2014-03-02 Thread Juergen Sauermann


Hi,

I believe this relates to an earlier discussion on this list (around 
Feb. 24, 2014).


You can put the left arg of /⍨ in parentheses which marks it as a value 
at ⎕FX time

(the default interpretation is function) like this:

  (v)/⍨2|v←⍳4

1 3

/// Jürgen



On 03/02/2014 11:31 AM, Daniel H. Leidisch wrote:

Hello!

Commuting compress results in a syntax error:

   v/⍨2|v←⍳4

This works in NARS2000, Dyalog, and NGN. I'm at r148.


Regards,

Daniel

Re: [Bug-apl] Each first

2014-03-02 Thread Juergen Sauermann


Hi Daniel,

thanks for reporting thisd. Fixed in SVN 149.

/// Jürgen


On 03/02/2014 11:37 AM, Daniel H. Leidisch wrote:

Hello!

Each first of a nested lists behaves weirdly.

   ↑¨(1 2) (3 4)
1 3
   ≡↑¨(1 2) (3 4)
1

So far so good, but:

   8⎕cr ↑¨(1 2) (3 4)
┌→──┐
│┌─┐ ┌─┐│
││1│ │3││
│└─┘ └─┘│
└───┘
   (↑¨(1 2) (3 4))⍳3
3

This works (i.e. returns ⎕io+1) in NARS2000 and NGN.


Regards,

Daniel

Re: [Bug-apl] Multiply and add with axis


Hi,

thanks, fixed in SVN 150.

/// Jürgen


On 03/02/2014 11:50 AM, Daniel H. Leidisch wrote:

Hello!

Multiply and add doesn't seem to work with axis specifications:

   (3 5⍴1) ×[1] ⍳3
INDEX ERROR
   (3 5⍴1)×[1]⍳3
   ^  ^
INDEX ERROR
   (3 5⍴1)+[1]⍳3
   ^  ^

This works in NARS2000 and Dyalog:

   (3 5⍴1) ×[1] ⍳3
1 1 1 1 1
2 2 2 2 2
3 3 3 3 3
   (3 5⍴1)+[1]⍳3
2 2 2 2 2
3 3 3 3 3
4 4 4 4 4

Now, I don't have a copy of the standard to check (the pdf file from the
link mentioned in README-7-more-info seems to be corrupted – I couldn't
open it), but according to the draft (disS8485.pdf), these functions
don't take axis specifications. On the other hand, this works:

   (3 5⍴1) +[2] ⍳5
2 3 4 5 6
2 3 4 5 6
2 3 4 5 6


Regards,

Daniel

Re: [Bug-apl] D-fn binding leackage, Nested d-fns


Hello Daniel,

I would like to explain my point of view regarding Lambdas aka. D-funs.

Initially I considered them as not needed; they are not defined in the APL
standard and the rules related to them seem to be rather unclear.

After seeing some requests to support them I started thinking about this
and I figured that they could be somewhat elegant in particular when
used with the EACH operator.

There are still things related to lambdas that I don't like at all because I
believe that they obscure the APL language more than they help.

For example, IMHO the following is definitely unfortunate (even though
possibly convenient and supported in some APL interpreters):

- having different binding rules in lambdas than in normal APL functions,
- "guards" like :IF in lambdas
- probably more...

Nested lambdas are sort of on the border - I could look into this if you
have a convincing example. A good specification of lambdas would also help.
In the meantime you can work around this by eg:

A←{⍵} ◊ {⍵+A 1}1

In GNU APL lambdas create normal user-defined functions and normally follow
their rules. That's why x becomes visible in your example, and IMHO this 
makes

more sense than hiding x in lambdas but not in user-defined functions.

/// Jürgen


On 03/02/2014 11:53 AM, Daniel H. Leidisch wrote:

Hello!

Bindings from inside d-fns/lambdas leak into the global environment:

   x
VALUE ERROR
   x
   ^
   {x←⍵}1
1
   x
1

I didn't read much about this, but as far as I understand, bindings
introduced in these functions are supposed to be lexical locals. Anyway,
this doesn't happen in NARS2000, Dyalog and NGN.


Regards,



On 03/02/2014 11:56 AM, Daniel H. Leidisch wrote:

Hello!

Nesting d-fns doesn't seem to work:

   {⍵+{⍵}1}1
DEFN ERROR

This works in NARS2000, NGN and Daylog. I'm at r148.


Regards,

Daniel

Re: [Bug-apl] Patch: gnu-apl-ansi-colors


Hi David,

thanks, included in SVN 151.

/// Jürgen


On 03/03/2014 04:13 AM, David B. Lamkins wrote:

See attached.

Re: [Bug-apl] [Feature request] "]boxing on" analogue


Hi,

I have added command ]BOXING which takes an argument OFF, 2, 3, 4, 7, 8, 
or 9.

See SVN 152.

/// Jürgen


On 03/02/2014 12:06 PM, Daniel H. Leidisch wrote:

Hello!

When experimenting at the REPL, I often find myself typing n⎕CR
repeatedly at the beginning of lines. As an Emacs user, it wouldn't be a
problem for me to adapt Elias' mode to insert that for me automatically,
but wouldn't it be convenient to have it as a feature of the system
itself?

Maybe something like Dyalog's "]boxing on", but accepting the left
argument of ⎕CR (maybe using 1 or 7 as a default when used with "on"),
and renaming it to something like "cring", "autocr", "format" or
similar.


Regards,

Daniel

Re: [Bug-apl] D-fn binding leackage, Nested d-fns


Hi,

I have added my first shot at recursive lambdas. SVN 153.

/// Jürgen


On 03/03/2014 02:01 PM, Elias Mårtenson wrote:
I would like to suggest that the most convincing example is that of 
consistency. If { } can be used to wrap arbitrary APL code in an 
anonymous function, then it makes sense that you can also nest them.
I'd also like to present my previous email as an example to a 
situation where I wanted nested lambdas.


Regards,
Elias

On 3 March 2014 20:13, Juergen Sauermann 
mailto:juergen.sauerm...@t-online.de>> 
wrote:


Hello Daniel,

I would like to explain my point of view regarding Lambdas aka.
D-funs.

Initially I considered them as not needed; they are not defined in
the APL
standard and the rules related to them seem to be rather unclear.

After seeing some requests to support them I started thinking
about this
and I figured that they could be somewhat elegant in particular when
used with the EACH operator.

There are still things related to lambdas that I don't like at all
because I
believe that they obscure the APL language more than they help.

For example, IMHO the following is definitely unfortunate (even though
possibly convenient and supported in some APL interpreters):

- having different binding rules in lambdas than in normal APL
functions,
- "guards" like :IF in lambdas
- probably more...

Nested lambdas are sort of on the border - I could look into this
if you
have a convincing example. A good specification of lambdas would
also help.
In the meantime you can work around this by eg:

A←{⍵} ◊ {⍵+A 1}1

In GNU APL lambdas create normal user-defined functions and
normally follow
their rules. That's why x becomes visible in your example, and
IMHO this makes
more sense than hiding x in lambdas but not in user-defined functions.

/// Jürgen


On 03/02/2014 11:53 AM, Daniel H. Leidisch wrote:

Hello!

Bindings from inside d-fns/lambdas leak into the global
environment:

   x
VALUE ERROR
   x
   ^
   {x←⍵}1
1
   x
1

I didn't read much about this, but as far as I understand,
bindings
introduced in these functions are supposed to be lexical
locals. Anyway,
this doesn't happen in NARS2000, Dyalog and NGN.


Regards,



On 03/02/2014 11:56 AM, Daniel H. Leidisch wrote:

Hello!

Nesting d-fns doesn't seem to work:

   {⍵+{⍵}1}1
DEFN ERROR

This works in NARS2000, NGN and Daylog. I'm at r148.


Regards,

Daniel

Re: [Bug-apl] Should a native function be expungeable?


Hi,

thanks, fixed in SVN 154.

/// Jürgen


On 03/04/2014 01:26 AM, David B. Lamkins wrote:

Once one defines a native function, should the function be expungeable?
Attempting to )erase the function fails silently; applying ⎕ex to the
native function's name causes a crash.

Re: [Bug-apl] Missing Doxyfile


Hi,

thanks, added in SVN 154.

/// Jürgen


On 03/04/2014 05:46 AM, David B. Lamkins wrote:

The doxygen tool used by the DOXY make target looks for a configuration
file name Doxyfile.

The attached Doxyfile retains all defaults except for

INPUT = . src
SOURCE_BROWSER = YES

which is the minimum required configuration to make Doxygen useful.

Re: [Bug-apl] )COPY and )PCOPY


Hi,

true. fixed in SVN 154.

/// Jürgen


On 03/03/2014 07:32 PM, David B. Lamkins wrote:

)COPY and )PCOPY should not change wsid.

Re: [Bug-apl] Rank operator and function assignment


Hi Elias,

I assume by spec you mean ISO/IEC 13751.

They give the following syntax:

Z ← f ⍤y B (deriving monadically) and
Z ← A f ⍤y B (deriving dyadically).

They say that f ⍤y is a function which is then called with arguments B 
and possibly A.

Thus Z is a value and not a function; the function is created internally.

The problem with ⍤ is its ambiguity regarding y.
y is expected to be a vector with 1, 2, or 3 elements.
Now look at:

  +⍤1 2 3 4 5
AXIS ERROR
  +⍤1 2 3 4 5
  ^^
The problem is that this could mean several things:

  +⍤1 (2 3 4 5)
2 3 4 5
  +⍤1 2 (3 4 5)
3 4 5
  +⍤1 2 3 (4 5)
4 5

In your example,

*  {'foo',⍵}⍤1 4 5⍴⍳10*

first *1 4 5⍴⍳10 i*s computed  and then *{'foo',⍵}⍤y B *with an empty y
and B the result of *1 4 5⍴⍳10*.
The empty y then causes the axis error.

What you probably intended to do is:

*  {'foo',⍵}⍤1 (4 5⍴⍳10)*
foo 1 2 3 4  5
foo 6 7 8 9 10
foo 1 2 3 4  5
foo 6 7 8 9 10

In GNU APL you can put the y in axis brackets to resolve the ambiguity.
I personally believe *⍤*[y] B is a clearer syntax than *⍤*y B.

*  {'foo',⍵}⍤[1] 4 5⍴⍳10*
foo 1 2 3 4  5
foo 6 7 8 9 10
foo 1 2 3 4  5
foo 6 7 8 9 10

/// Jürgen


n 03/04/2014 05:28 PM, Elias Mårtenson wrote:
I was playing around with the Rank Operator, which is something that 
isn't really documented in many places. I only saw references to it in 
the spec, while neither APL2 nor Dyalog mentions it.


Now, there are a few things that behaves strangely, although it may be 
correct.


First of all, the following works (]BOXING is 8):

*xx ← 4 5⍴⍳10*
*  {'foo',⍵}⍤1 xx*
┌→─┐
↓foo 1 2 3 4  5│
│foo 6 7 8 9 10│
│foo 1 2 3 4  5│
│foo 6 7 8 9 10│
└──┘

But the following does not:

*{'foo',⍵}⍤1 4 5⍴⍳10*
RANK ERROR
λ1⍤1 4 5⍴⍳10
^ ^
*({'foo',⍵}⍤1) 4 5⍴⍳10*
RANK ERROR
(λ1⍤1)4 5⍴⍳10
 ^^

Also, the spec says it returns a function, but I can't assign it to a 
variable:


*a ← {'foo',⍵}⍤1*
RANK ERROR
a←λ1⍤1
  ^ ^

I suppose the last one is expected, since *xy←+/* also does not work 
(but should it?)


Is the behaviour correct, or is there a problem with the parsing?

Regards,
Elias

Re: [Bug-apl] Possible improvement to ]BOXING


Hi Elias,

I believe it would be more confusing if ⎕CR is sometimes computed and 
sometimes not.


The example below might be easy to detect but what about cases like Z←8 
⎕CR xxx ◊ Z or

some ⎕CR returned by a function?

/// Jürgen


On 03/04/2014 05:35 AM, Elias Mårtenson wrote:
I love ]BOXING and I'm using it all the time now. It's particularly 
useful when you're a beginner like myself.


Would it be possible to prevent the application of the default ]BOXING 
value when explicitly using ⎕CR? Consider this interaction?


*]BOXING 8*
*'foo' 'bar'*
┌→──┐
│┌→──┐ ┌→──┐│
││foo│ │bar││
│└───┘ └───┘│
└∊──┘
*8⎕CR 'foo' 'bar'*
┌→┐
↓┌→──┐│
││┌→──┐ ┌→──┐││
│││foo│ │bar│││
││└───┘ └───┘││
│└∊──┘│
└─┘

Oops... The last one applies 8⎕CR on output that has already been 
boxed. That can be a bit confusing.


Regards,
Elias

Re: [Bug-apl] Rank operator and function assignment

2014-03-05 Thread Juergen Sauermann


Hi Daniel,

how does NARS2000 define f⍤B and A f⍤B (the standard does not)?

/// Jürgen


On 03/04/2014 07:52 PM, Daniel H. Leidisch wrote:

Hello!

Juergen Sauermann
 writes:


What you probably intended to do is:

*  {'foo',⍵}⍤1 (4 5⍴⍳10)*
foo 1 2 3 4  5
foo 6 7 8 9 10
foo 1 2 3 4  5
foo 6 7 8 9 10

Shouldn't this work, too?

   ({'foo',⍵}⍤1) 4 5⍴⍳10
RANK ERROR
   (λ1⍤1)4 5⍴⍳10
^^

Works in NARS2000.


Regards,

Daniel

Re: [Bug-apl] Rank operator and function assignment


Hi Tobia,

I see, thanks for the explanation.

I will look into this, but can't promise too much short term because
it probably requires some rework of the parser.

/// Jürgen


On 03/06/2014 01:27 AM, Tobia Conforto wrote:

Hi Juergen


how does NARS2000 define f⍤B and A f⍤B (the standard does not)?

I can answer this.
f⍤y is just the function that would be applied to B in f⍤y B, so that one can 
give it a name: g←f⍤y and then apply it: g B

A f⍤B is a syntax error, because f⍤B becomes a function, which then lacks the 
right argument.


In GNU APL you can put the y in axis brackets to resolve the ambiguity.
I personally believe ⍤[y] B is a clearer syntax than ⍤y B.

   {'foo',⍵}⍤[1] 4 5⍴⍳10

This ambiguity between the right argument of the operator and that of the 
derived function (⍵⍵ and ⍵) or more rarely between the two left arguments (⍺ 
and ⍺⍺) is usually resolved using either parentheses around the derived 
function or using the right identity function ⊢ This is true even for other 
common operators:

⊂⍣3⊢⍳3   ⍝ enclose ⍳3 three times
(⊂⍣3)⍳3   ⍝ same

Parentheses around the right argument mean something else in dialects with 
"strands" such as Dyalog:

⊂⍣3(⍳3)   ⍝ this produces the derived function ⊂⍣(3,⊂⍳3) which will 
give an error when applied

I would be wary of bracket notation on the rank operator, because it has a 
different meaning in Nars2000 (which I'm not sure I understand entirely) see 
http://wiki.nars2000.org/index.php/Rank
That page mentions conforming to ISO 13751, so I would check whether the 
bracket notation should have a particular meaning according to it (maybe where 
they define bracket notation in general?)


Tobia

Re: [Bug-apl] Getting list of quad-commands and system commands


Hi Elias,

I have added macro sf_def() which gives the missing system functions, 
SVN 155.


Alternatively you may go for Id.def (which is all symbols known by the 
system)

and check if the UCS_string returned by id_name() starts with ⎕.

/// Jürgen



On 03/06/2014 09:07 AM, Elias Mårtenson wrote:
It doesn't work correctly yet. SystemVariable.def doesn't give me all 
symbols. For example, ⎕DL is not included. How can I get those too?


Regards,
Elias


On 4 March 2014 00:11, Elias Mårtenson <mailto:loke...@gmail.com>> wrote:


And it's done. There is now expansion of both system commands and
quad functions in the Emacs mode.

Regards,
Elias


    On 2 March 2014 01:52, Juergen Sauermann
mailto:juergen.sauerm...@t-online.de>> wrote:

Hi,

providing descriptions of functions is a lot of work. Most
people know APL after
a short while, and those who need it are probably better off
with a good APL book.

I wanted to wait with the next release until the rate of error
reports goes down a little.
Right now it seems to get a little more quiet, so maybe in two
weeks from now?

/// Jürgen



On 03/01/2014 05:22 PM, Elias Mårtenson wrote:

Thanks. Looks easy enough.

What do you think of the idea of having descriptions of the
functions embedded in the APL interpreter instead of in the
Emacs mode?

Secondly, when do you plan to release 1.3?

Regards,
Elias


    On 1 March 2014 23:50, Juergen Sauermann
mailto:juergen.sauerm...@t-online.de>> wrote:

Hi Elias,

for commands, you can #define macro cmd_def() and then
#include Command.def.
For Quad-vars you can #define macros ro_sv_def() and
rw_sv_def and then #include SystemVariable.def.

For example, to get the strings for all commands:

#define cmd_def(cmd_str, code, _arg) #cmd_str
#include "Command.def"

To get the strings for all quad variables:

#define ro_sv_def(var) #var
#define rw_sv_def(var) #var
#include "Command.def"

In the latter case you need to replace "Quad_" by "⎕". Or
#define
the macro as ID_ ## x (which gives an enum Id) and call
id_name() on it
to get an UCS_string.

/// Jürgen



On 03/01/2014 02:42 PM, Elias Mårtenson wrote:

I've recently added smart expansion of symbols in the
Emacs mode (press TAB and get a list of suggested
variable and function names). I'd like it to be able
to expand system commands and quad commands as well.
Of course, I could simply hard-code the list of
available commands, but it would be neater if there
was a way of accessing this from GNU APL itself.

Also, since the expansion list has room for a
description, it would be even more awesome if I could
access a one-line description of these commands and
variables. Of course, I could include it on my side,
but this is something that's useful for not only the
Emacs mode, but for any user of GNU APL, so would it
make sense to include this information in the
interpreter itself (I'd access it through an API,
while it can also be made available from some kind of
help command from the commandline).

Regards,
Elias

Re: [Bug-apl] Suggestions needed: Editing of named lambdas


Hi,

in GNU APL you can have lambdas without result (eg. {}) and they don't 
start with *λ*←.
As Kacper has pointed out you can also have user-defined functions 
starting with *λ*←.


I have no plans to prevent that, but  I have also no idea where the 
lambdas will bring us
in GNU APL. Right now {...} is simply a wrapper for ⎕FX. IMHO it is not 
a good idea to
have two kinds of functions with different rules in one language, even 
if some APL programmers

seem to like that.

I have added a function UserFunction::is_lambda() in SVN 156 that tells 
if the function

was *initially* defined via '{ ... }'.

No idea what happens if you edit the function later on.

/// Jürgen


On 03/06/2014 03:53 AM, Elias Mårtenson wrote:
The Emacs mode allows the user to edit an existing function by 
pressing C-c C-f, or typing ∇ followed by the name of the function. 
This opens up the function editor in a separate window.


However, when the user creates a function using the dfn notation:

avg ← {(+/⍵)÷⍴⍵}


And then tried to edit it using ∇avg, the Emacs mode will run the 
equivalent of ⎕CR 'avg' behind the scenes, and present the following 
in the function editor:


∇λ←avg ⍵
λ←(+/⍵)÷⍴⍵


This will of course fail when the user tries to save the function.

First a question for Jürgen:

*Can I rely on the fact that if the first character in a function 
definition is **λ**, does that guarantee that the function is a 
dfn?* A consequence of this is, for example, that I am guaranteed that 
the function consists of only one statement.


So, I have a few options here and I would like people's input on it:

  * I can simply pop up an error message if an attempt is made to edit
a lambda function (then how should they be edited?)
  * I open the function editor in a special "lambda mode", limiting
the function to a single statement
  * I replace λ, ⍺ and ⍵ with proper variables, thus converting the
lambda function into a normal function when saving.
  * Jürgen allows the use of λ, ⍺ and ⍵ as variables in normal
functions so they behave just like any other function, except with
unusual parameter names.

*What solution do you think should be used?* The current state is 
really not ideal.


Regards,
Elias

Re: [Bug-apl] Implementation of ∩ - Intersection


Hi Elias,

yes, it would make sense. I have added dyadic ∪ (union) and diadic ∩ 
(intersection), see SVN 157.


/// Jürgen


On 03/06/2014 10:27 AM, Elias Mårtenson wrote:
Would it make sense to implement the ∩ function in GNU APL? In Dyalog, 
it represents the intersection function which returns the elements 
that occur in both L and R.


Regards,
Elias

Re: [Bug-apl] Configure wrongly reports Readline missing

2014-03-08 Thread Juergen Sauermann


Hello Jan-Pieter,

I would expect that the check for curses (a little higher/before) the 
check for

readline has indicated a problem.

Could you please send me your config.log?

Thanks,
Jürgen


On 03/06/2014 03:48 PM, Jan-Pieter Jacobs wrote:

Hey,

I noticed (in GNU APL 1.2) that I did not get readline to work.

I tried using "./configure --with-readline" to force Readline to be 
used, but that informed me it was not found (Though it was installed, 
including development packages).
After looking at the config.log, it turned out it was actually 
ncurses-dev that was missing instead.


I don't know whether this qualifies as bug, but it is confusing at 
least :).


Kind regards,

Jan-Pieter Jacobs

Re: [Bug-apl] Plus sign but no )MORE

2014-03-08 Thread Juergen Sauermann


Hi,

thanks, fixed in SVN 158.

/// Jürgen


On 03/07/2014 05:08 PM, Elias Mårtenson wrote:

If I type →2 on the prompt, I get an error message with a plus:

SYNTAX ERROR+


But When I type )MORE, I get the answer:

NO MORE ERROR INFO


Is this correct?

Regards,
Elias

Re: [Bug-apl] svn update conflicts on *.gmo files


Hi David,

you could try:

svn update --accept theirs-full

Unfortunately the gmo files are put into the repository even though they 
are generated.
The Makefile doing this was installed by the NLS package and I don't 
know how to change it.


Simply removing the .gmo files from the repo could also break builds on 
systems where
NLS-related scripts are missing, so I would prefer to not play around 
with the NLS stuff.


/// Jürgen


On 03/09/2014 06:13 AM, David B. Lamkins wrote:

I've noticed that often (not always) when I update my working directory
from the repo, I get conflicts on some *.gmo files.

I've been resolving the conflicts as shown in the transcript. Should I
be doing something different? Is there something that can make these
conflicts stop happening?

$ svn update
Updating '.':
Usrc/buildtag.hh
Usrc/Command.cc
Usrc/UserFunction.hh
Usrc/Output.hh
Usrc/Id.def
Usrc/main.cc
Usrc/PrimitiveFunction.hh
Usrc/SystemVariable.def
Usrc/Tokenizer.cc
Usrc/UserFunction.cc
Usrc/Avec.def
Usrc/Token.def
Usrc/Output.cc
Usrc/PrimitiveFunction.cc
UREADME-4-compliance
Gpo/e...@quot.po
Gpo/e...@boldquot.po
Cpo/e...@quot.gmo
Cpo/e...@boldquot.gmo
Gpo/de.po
Cpo/de.gmo
Gpo/apl.pot
Ugnu-apl.d/preferences
UChangeLog
Updated to revision 158.
Conflict discovered in file 'po/de.gmo'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
 (mc) my side of conflict, (tc) their side of conflict,
 (s) show all options: tc
tc
Resolved conflicted state of 'po/de.gmo'
Conflict discovered in file 'po/e...@boldquot.gmo'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
 (mc) my side of conflict, (tc) their side of conflict,
 (s) show all options: tc
tc
Resolved conflicted state of 'po/e...@boldquot.gmo'
Conflict discovered in file 'po/e...@quot.gmo'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
 (mc) my side of conflict, (tc) their side of conflict,
 (s) show all options: tc
tc
Resolved conflicted state of 'po/e...@quot.gmo'
Summary of conflicts:
   Text conflicts: 0 remaining (and 3 already resolved)

Re: [Bug-apl] Rank operator and function assignment


Hi Kacper,

see some comments inline below.


On 03/04/2014 10:52 PM, Kacper Gutowski wrote:

On 2014-03-04 18:53:29, Juergen Sauermann wrote:

They say that f ⍤y is a function which is then called with arguments B and
possibly A.
Thus Z is a value and not a function; the function is created internally.

I guess the problem is that GNU APL doesn't really have what most people
understand under lambdas even though it supports dfns syntax.  Functions
are not a first-class values.

Yes, GNU APL only supports a limited subset of lambdas,
Not sure though how this is related to how the rank operator is computed.

The problem with ⍤ is its ambiguity regarding y.
y is expected to be a vector with 1, 2, or 3 elements.

Perhaps as a result of the earlier, you can not even disambiguate rank
arguments with parentheses this way (this works in other systems):

   (+⍤1) 2 3 4 5
RANK ERROR
   (+⍤1)2 3 4 5
^  ^
This rank error is thrown because +⍤1 is a valid phrase and is reduced 
first, like in:


  +⍤1
RANK ERROR
  +⍤1
  ^^

This raises the question if we should allow an operator like ⍤ to change 
the syntax of the language
in order to work. To achieve the desired effect of binding 1 to +⍤ we 
would then need to handle
'fun op B' in one way if op is ⍤ and in another way if not. even though 
that is implementable,

i am hesitant to do it because IMHO it obscures the syntax of the language.


By the way, while Elias's example was correctly parsed and interpreted,
I think that parsing is not correct:

   +⍤1 +2 3 4 5
DOMAIN ERROR
   +⍤1+2 3 4 5
   ^^

It is expected to be parsed as +⍤1(+2 3 4 5) and it's not ambiguous at all.
I can't find it in the spec right now, but cf. ∘.=⍨ which is (∘.=)⍨ not ∘.(=⍨).
Correct me if I'm wrong, but afaiu, operators, unlike functions, should be
left associative.
It is actually parsed as +⍤(1 +2 3 4 5) which becomes +⍤3 4 5 6 which 
then throws the domain error:


 +⍤3 4 5 6
DOMAIN ERROR
  +⍤3 4 5 6

If you had set the parentheses as suggested then you would have gotten 
the proper result:


  +⍤1(+2 3 4 5)
2 3 4 5

which is the same as:

  +⍤1(2 3 4 5)
2 3 4 5


Generally speaking, GNU APL computes the rank operator like this:

For pattern fun ⍤ j B (A ⍤ j B handled accordingly):

1. j B is reduced to value C (because Vector binding is stronger than 
the others in IBM APL2).


2. fun ⍤ C is computed. There are two valid cases:

2a. ↑C is nested. In that case ↑C is taken as j and the reso of C as B
2b. ↑C is simple then C should be a vector whose last element is taken 
as B and the others as j.





Additionally, in A+, but also in Dyalog and NARS as I just checked, there
is a monadic ⊢, i.e. an identity function.  It is useful exactly for
this purpose, as it allows writing: +⍤1⊢2 3 4 5.  Monadic ⊢ could also be
used to display shy result regardless of type as in ⊢X←anything.
It's overall pretty nice consistent extension that I'd be happy to see
in GNU APL too.
I can look into this, but it seems to do the same as +⍤1(2 3 4 5). So it 
saves a parenthesis at the
expense of an operator. However, in GNU APL 1(2 3 4 5) is computed at 
⎕FX time, while ⊢ is

computed at runtime, which makes it slower.



-k

Re: [Bug-apl] Rank operator and function assignment


Hi,

actually the example below works if you set the parentheses differently:

  {'foo', ⍵}⍤1 (4 5⍴⍳10)
foo 1 2 3 4  5
foo 6 7 8 9 10
foo 1 2 3 4  5
foo 6 7 8 9 10


The reason why your example below does not work is that your parentheses 
force
{'foo',⍵}⍤1 to be computed first (throwing the rank error because of 
argument 1

which is expected to be a vector).

/// Jürgen


On 03/04/2014 07:52 PM, Daniel H. Leidisch wrote:

Hello!

Juergen Sauermann
 writes:


What you probably intended to do is:

*  {'foo',⍵}⍤1 (4 5⍴⍳10)*
foo 1 2 3 4  5
foo 6 7 8 9 10
foo 1 2 3 4  5
foo 6 7 8 9 10

Shouldn't this work, too?

   ({'foo',⍵}⍤1) 4 5⍴⍳10
RANK ERROR
   (λ1⍤1)4 5⍴⍳10
^^

Works in NARS2000.


Regards,

Daniel

Re: [Bug-apl] Common IO operations


Hi Elias,

sounds like a case for FILE_IO and partition:

1. get a line with fgets() in FILE_IO
2. call partition (dyadic ⊂)

For example (FILE_IO part omitted):

TEXT←"Hello,World,xyz"

(TEXT≠",")⊂TEXT
Hello World xyz

⍴(TEXT≠",")⊂TEXT
3
⊃((TEXT≠",")⊂TEXT)[1]
Hello
⊃((TEXT≠",")⊂TEXT)[2]
World
⊃((TEXT≠",")⊂TEXT)[3]
xyz

/// Jürgen


On 03/09/2014 03:58 PM, Elias Mårtenson wrote:
A common need that I have is to be able to easily read and write data 
from/to files. For me, this data is usually in CSV form.


Up until now, I've loaded them into Emacs and used my tools to push 
the tabular data into variables. However, it would be nicer to have 
something native in GNU APL itself.


I've been thinking of writing a library of functions using the file_io 
native library as the underlying mechanism.


How do other APL's handle this? I've seen the TIE stuff in Dyalog and 
Nars, and they seem painful to use.


Regards,
Elias

Re: [Bug-apl] Ideas for an online demo-version of GNU APl


Hi Thomas,

nice idea, we should try that.

I believe that it should already be possible to start
GNU APL from eg. an apache web-server; the missing
piece could be the backward direction (user input -> webserver).

Security should not be too hard on linux systems.

A problem remaining is where to host this in a permanent fashion.
Probably the GNU project will not be too happy if we use their capacity
for (possibly heavy) APL demos.

/// Jürgen




On 03/09/2014 11:50 PM, baruc...@gmx.com wrote:

Hi,

it is well known that Dyalog APL and NGN APL both have an online demo version
which is a very nice feature:
   * for trying some quick idea when not at home;
   * for letting other people discover GNU APL;
   * for providing some kind of "permanent link" in forums, etc. (for instance
 on "golf" challenge forums;
   * etc.

Both systems are quite different:
   * Dyalog APL has a server-side software
   * NGN APL has a client-side javascript software

Of course, the server-side software needs some special care:
   * security issues if the user is allowed to execute some system commands;
   * CPU/memory/time quotas

Wouldn't it be nice to have GNU APL providing its own demo-version?

I browsed a little and found about Emscripten:
   https://github.com/kripken/emscripten/wiki
   https://github.com/kripken/emscripten/wiki/Tutorial

It looks like even some large projects could be "easely" compiledinto 
javascript.

Do you think it would be easy to do it with GNU APL?

If someone is able to compile it to javascript, I could perfectly write the 
HTML/CSS/Javascript
web interface as a contribution.

Best regards,

Re: [Bug-apl] Proposal for initial multicore support


Hi David,

I think your ideas are correct. I have planned multicore support for GNU 
APL 1.4 and

every help is welcome.

Actually parallel processing was one of the main reasons for me to write 
GNU APL.
I published a Ph.D thesis "A parallel APL computer" (in German) back in 
1990. We had
built a prototype based on multiple MC68020 processors and demonstrated 
that most
APL primitive functions and operators can benefit from parallel 
execution. The only

thing missing at that time was the interpreter (which is now GNU APL).

My thoughts so far were going in the direction of OpenMP which uses a 
similar approach
as the one you describe. But I haven't worked with it yet and there are 
other solutions around.


The most important step is to find the best approach for GNU APL. That 
probably means a lot

of benchmarking and experimenting.

In GNU APL every primitive function is a separate object so we can 
decide on a per-function

basis at what length we go multi-core.

/// Jürgen




On 03/10/2014 06:33 AM, David B. Lamkins wrote:

This weekend I spent a few hours poking around in the GNU APL source
code while thinking about what it might take to exploit a multicore CPU.
I've collected my thoughts on what it might take to do an initial
implementation (see attached).

Juergen (and anyone else who has worked in the code base), I'd
appreciate some feedback regarding the feasibility of my proposal, as
well as your comments about things I've overlooked.

This is something I'd be willing to work on in my spare time.

Re: [Bug-apl] Ideas for an online demo-version of GNU APl


Hi,

yes, I can add a --safe command line option. Shared variables can 
already be disabled with --noSV.


/// Jürgen


On 03/10/2014 12:45 PM, Elias Mårtenson wrote:


I can set it up for testing purposes. I already have some servers 
available.


Would it be possible to add a flag that enables "safe mode"? This 
would restrict the availability of shared variables and native functions?


Regards,
Elias

On 10 Mar 2014 19:19, "Juergen Sauermann" 
mailto:juergen.sauerm...@t-online.de>> 
wrote:


Hi Thomas,

nice idea, we should try that.

I believe that it should already be possible to start
GNU APL from eg. an apache web-server; the missing
piece could be the backward direction (user input -> webserver).

Security should not be too hard on linux systems.

A problem remaining is where to host this in a permanent fashion.
Probably the GNU project will not be too happy if we use their
capacity
for (possibly heavy) APL demos.

/// Jürgen




On 03/09/2014 11:50 PM, baruc...@gmx.com <mailto:baruc...@gmx.com>
wrote:

Hi,

it is well known that Dyalog APL and NGN APL both have an
online demo version
which is a very nice feature:
   * for trying some quick idea when not at home;
   * for letting other people discover GNU APL;
   * for providing some kind of "permanent link" in forums,
etc. (for instance
 on "golf" challenge forums;
   * etc.

Both systems are quite different:
   * Dyalog APL has a server-side software
   * NGN APL has a client-side javascript software

Of course, the server-side software needs some special care:
   * security issues if the user is allowed to execute some
system commands;
   * CPU/memory/time quotas

Wouldn't it be nice to have GNU APL providing its own
demo-version?

I browsed a little and found about Emscripten:
https://github.com/kripken/emscripten/wiki
https://github.com/kripken/emscripten/wiki/Tutorial

It looks like even some large projects could be "easely"
compiledinto javascript.

Do you think it would be easy to do it with GNU APL?

If someone is able to compile it to javascript, I could
perfectly write the HTML/CSS/Javascript
web interface as a contribution.

Best regards,

Re: [Bug-apl] Assertion error when typing ()


Hi Elias,

thanks, fixed in SVN 160.

/// Jürgen


On 03/09/2014 05:46 PM, Elias Mårtenson wrote:
After some playing around, I just decided to type an opening and 
closing paren:


*()*


I then got the following error (trying again after restarting will not 
reproduce the error):


Assertion failed: 0
in Function:  init
in file:  Cell.cc:47

Call stack:


-- Stack trace at Cell.cc:47

0x7f6acde77de5 __libc_start_main
0x434735  main
0x51f53d Workspace::immediate_execution(bool)
0x461fad  Command::process_line()
0x460eab Command::process_line(UCS_string&)
0x469de8  Executable::execute_body() const
0x4de0f0 StateIndicator::run()
0x48b17a  Prefix::reduce_statements()
0x489144 Prefix::reduce_END_B__()
0x4e196a  StateIndicator::statement_result(Token&)
0x4bfc7b Quad_CR::do_CR(long, Value const&)
0x51b8cb  Value::clone(char const*) const
0x4594d1   Cell::init(Cell const&)
0x442e2fdo_Assert(char const*, char const*, char const*, int)


SI stack:

Depth:7
Exec: 0xcbb400
Pmode:◊  ()
PC:   2 RETURN_STATS
Stat: ()
err_code: 0x0
thrown:   at StateIndicator.cc:40
e_msg_1:  'No Error'
e_msg_2:  ''
e_msg_3:  ''

Depth:6
Exec: 0xcb2760
Pmode:◊  1 2 {⎕NC '⍺'} 10)
PC:   5 RETURN_STATS
Stat: 1 2 {⎕NC '⍺'} 10)
err_code: 0x20002
thrown:   at Prefix.cc:1048
e_msg_1:  'SYNTAX ERROR'
e_msg_2:  '  1 2 λ1 10)'
e_msg_3:  '  ^^'

Depth:5
Exec: 0xcb43f8
Pmode:∇ λ1[1]
PC:   3 ⍺
Stat: λ←⍺⍺⍵⍵
err_code: 0x30001
thrown:   at Symbol.cc:681
e_msg_1:  'VALUE ERROR'
e_msg_2:  'λ1[1]  λ←⍺ ⍺ ⍵ ⍵'
e_msg_3:  '   ^'

Depth:4
Exec: 0xcb1430
Pmode:◊  {⍺⍺⍵⍵} 10
PC:   3 RETURN_STATS
Stat: {⍺⍺⍵⍵} 10
err_code: 0x0
thrown:   at StateIndicator.cc:40
e_msg_1:  'No Error'
e_msg_2:  ''
e_msg_3:  ''

Depth:3
Exec: 0xcaf5d0
Pmode:◊  ∘.×⍳10
PC:   6 RETURN_STATS
Stat: ∘.×⍳10
err_code: 0x50001
thrown:   at Function.cc:119
e_msg_1:  'VALENCE ERROR'
e_msg_2:  '  ∘.×⍳10'
e_msg_3:  '  ^  ^'

Depth:2
Exec: 0xcae9b0
Pmode:◊  4/[2]'xyz'
PC:   6 ENDL
Stat: 4/[2]'xyz'
err_code: 0x50006
thrown:   at Value.cc:1072
e_msg_1:  'AXIS ERROR'
e_msg_2:  '  4/[2]'xyz''
e_msg_3:  '  ^   ^'

Depth:1
Exec: 0xcad530
Pmode:◊  4/[1.5]'xyz'
PC:   6 ENDL
Stat: 4/[1.5]'xyz'
err_code: 0x50006
thrown:   at Value.cc:1066
e_msg_1:  'AXIS ERROR'
e_msg_2:  '  4/[1.5]'xyz''
e_msg_3:  '  ^ ^'

Depth:0
Exec: 0xcada70
Pmode:◊  4 5/'xyz'
PC:   3 ENDL
Stat: 4 5/'xyz'
err_code: 0x50003
thrown:   at Bif_OPER1_REDUCE.cc:69
e_msg_1:  'LENGTH ERROR'
e_msg_2:  '  4 5/'xyz''
e_msg_3:  '  ^  ^'


Regards,
Elias

Re: [Bug-apl] Ideas for an online demo-version of GNU APl


Hi,

I have added a --safe command line option that disables shared variables,
native functions, and the )HOST command. SVN 160.

/// Jürgen


On 03/10/2014 12:45 PM, Elias Mårtenson wrote:


I can set it up for testing purposes. I already have some servers 
available.


Would it be possible to add a flag that enables "safe mode"? This 
would restrict the availability of shared variables and native functions?


Regards,
Elias

On 10 Mar 2014 19:19, "Juergen Sauermann" 
mailto:juergen.sauerm...@t-online.de>> 
wrote:


Hi Thomas,

nice idea, we should try that.

I believe that it should already be possible to start
GNU APL from eg. an apache web-server; the missing
piece could be the backward direction (user input -> webserver).

Security should not be too hard on linux systems.

A problem remaining is where to host this in a permanent fashion.
Probably the GNU project will not be too happy if we use their
capacity
for (possibly heavy) APL demos.

/// Jürgen




On 03/09/2014 11:50 PM, baruc...@gmx.com <mailto:baruc...@gmx.com>
wrote:

Hi,

it is well known that Dyalog APL and NGN APL both have an
online demo version
which is a very nice feature:
   * for trying some quick idea when not at home;
   * for letting other people discover GNU APL;
   * for providing some kind of "permanent link" in forums,
etc. (for instance
 on "golf" challenge forums;
   * etc.

Both systems are quite different:
   * Dyalog APL has a server-side software
   * NGN APL has a client-side javascript software

Of course, the server-side software needs some special care:
   * security issues if the user is allowed to execute some
system commands;
   * CPU/memory/time quotas

Wouldn't it be nice to have GNU APL providing its own
demo-version?

I browsed a little and found about Emscripten:
https://github.com/kripken/emscripten/wiki
https://github.com/kripken/emscripten/wiki/Tutorial

It looks like even some large projects could be "easely"
compiledinto javascript.

Do you think it would be easy to do it with GNU APL?

If someone is able to compile it to javascript, I could
perfectly write the HTML/CSS/Javascript
web interface as a contribution.

Best regards,

Re: [Bug-apl] What is the daemon mode?


Hi,

seems like the parent closes stdin/cin. Have to find out why.

/// Jürgen


On 03/10/2014 05:01 PM, baruc...@gmx.com wrote:

Hi,

I tried to figure out how to enable the daemon mode and how to use it,
but with no success; first of all, does it work? Each time I try to
enable it, I have an infinite loop with the )OFF message.

Regards,

Re: [Bug-apl] What is the daemon mode?

2014-03-11 Thread Juergen Sauermann


Hi Thomas,

I fixed the infinite lopp when the interpreter has no input. It now 
stops after
10 attempts within short time (to distinguish that from ^D typed by the 
user).


Deamon mode (-d) simply fork()s the process of the APL interpreter with the
parent process exit()ing and the child continuing the APL interpreter. 
Normally
the terminal remains connected to the parent process so that the child 
process
may have no input (which then ran into the endless loop because the 
child tried

to get input again and again).

To avoid the child having no input, you need to provide that in addition 
to the -d flag,

usually by providing an ,apl script file like this:

apl -d -f script.aplor
apl -d < script.aplor
cat script.apl | apl -d -f -

A script.apl file can be written with a normal text editor or
with the )DUMP command.

/// Jürgen



On 03/10/2014 05:01 PM, baruc...@gmx.com wrote:

Hi,

I tried to figure out how to enable the daemon mode and how to use it,
but with no success; first of all, does it work? Each time I try to
enable it, I have an infinite loop with the )OFF message.

Regards,

Re: [Bug-apl] Experimental OpenMP patch

2014-03-11 Thread Juergen Sauermann


Hi David,

looks good! Some comments, though.

1 .you could adapt src/testcases/Performance.pt with some longer
skalar functions in order to get some performance figures. You can start 
it like this:


./apl -T testcases/Performance.pt

2. I believe we should not bother the user with specifying 
parallelization parameters in ⎕SYL.
I would rather ./configure CORES=n with n=1 meaning no parallel 
execution, CORES=auto
being the number of cores on the build machine, and explicit numbers n>1 
meaning that
n cores shall be used. This would generate slightly faster code than 
computing array bounds

at runtime. Its a bit more hassle for the user, but may pay off soon.

3. Yes, GNU APL throws many exception (almost every APL error was thrown 
from somewhere),
 and I was excpecting that we have to catch them on the throwing 
processor. Not too difficult if

we do it on the top level.

4. It would be good to understand how the OPenMP loops work. I could 
imagined one of two strategies:


- in loop(j, MAX)   thread j executes iteration j, j+CORES, ...
- thread j executes iterations j*MAX/CORES ... (j+1)*MAX/CORES

The first strategy interleaves the data and is more intuitive
while the second uses blocks of data and is more cache-friendly and 
therefore probably

giving better performance.

5. Not sure if your earlier comment on letting the scheduler decide is 
correct. I have been doing
pthread programming in the past and I have seen cases where the 
scheduler fooled itself and
led to cases where the same problem took more than double the capacity 
compared to explicit
affinity on a 4-core CPU. I would expect that APL generates very 
fine-graned and short-lived
pieces of execution and the scheduler may not be optimized for that. I 
guess we have to try that out.


/// Jürgen



On 03/11/2014 08:02 AM, David B. Lamkins wrote:

Juergen's suggestion prompted me to attempt an implementation using
OpenMP rather than the by-hand coding that I had been anticipating.
Attached is a quick-and-dirty patch to enable GNU APL to be build with
OpenMP support.

./configure --with-openmp

There are many rough edges, both in the Makefile and the code.

--with-openmp would ideally check to see whether the compiler supports
OpenMP. It may be necessary to check the compiler version, as different
compilers support different versions of OpenMP. Also, I've assumed
compilation on/for Linux despite the fact that GNU APL and OpenMP should
be buildable with the right Windows compiler.

As one might expect, OpenMP requires that any throw from a worker thread
must be caught by the same thread. I'm almost certain that this
restriction could be violated by GNU APL code as currently written.

The good news, though, is that the changes are benign; in the absence of
--with-openmp, GNU APL's behavior is unchanged.

With OpenMP support, ⎕syl is extended to access some of OpenMPs
parameters.

I've done only trivial testing at this point; just enough to verify that
compiling OpenMP support doesn't obviously break GNU APL.

I haven't confirmed that the OpenMP #pragmas on the key loops in
SkalarFunction.cc have any effect on execution time or processor core
utilization. I hope to do more testing later this week.

Best wishes,
   David

Re: [Bug-apl] Experimental OpenMP patch

2014-03-11 Thread Juergen Sauermann


Hi,

we could do it similar to the LOG macro where you can choose between
more efficient compile-time settings and less efficient run-time settings.

It is important that we do these things properly from the outset to avoid
too many changes later on.

/// Jürgen


On 03/11/2014 04:10 PM, Elias Mårtenson wrote:
May I suggest that being able to choose the number of cores at runtime 
should actually be the default. Remember that most Linux distributions 
will not compile the source on the local machine and instead 
distributes binaries.


Having some #ifdefs would be good, and having runtime user-selected 
(or automatically based on cores) number of threads as default is 
important for this reason.


Regards,
Elias


On 11 March 2014 23:07, Juergen Sauermann 
mailto:juergen.sauerm...@t-online.de>> 
wrote:


Hi David,

looks good! Some comments, though.

1 .you could adapt src/testcases/Performance.pt with some longer
skalar functions in order to get some performance figures. You can
start it like this:

./apl -T testcases/Performance.pt

2. I believe we should not bother the user with specifying
parallelization parameters in ⎕SYL.
I would rather ./configure CORES=n with n=1 meaning no parallel
execution, CORES=auto
being the number of cores on the build machine, and explicit
numbers n>1 meaning that
n cores shall be used. This would generate slightly faster code
than computing array bounds
at runtime. Its a bit more hassle for the user, but may pay off soon.

3. Yes, GNU APL throws many exception (almost every APL error was
thrown from somewhere),
 and I was excpecting that we have to catch them on the throwing
processor. Not too difficult if
we do it on the top level.

4. It would be good to understand how the OPenMP loops work. I
could imagined one of two strategies:

- in loop(j, MAX)   thread j executes iteration j, j+CORES, ...
- thread j executes iterations j*MAX/CORES ... (j+1)*MAX/CORES

The first strategy interleaves the data and is more intuitive
while the second uses blocks of data and is more cache-friendly
and therefore probably
giving better performance.

5. Not sure if your earlier comment on letting the scheduler
decide is correct. I have been doing
pthread programming in the past and I have seen cases where the
scheduler fooled itself and
led to cases where the same problem took more than double the
capacity compared to explicit
affinity on a 4-core CPU. I would expect that APL generates very
fine-graned and short-lived
pieces of execution and the scheduler may not be optimized for
that. I guess we have to try that out.

/// Jürgen




On 03/11/2014 08:02 AM, David B. Lamkins wrote:

Juergen's suggestion prompted me to attempt an implementation
using
OpenMP rather than the by-hand coding that I had been
anticipating.
Attached is a quick-and-dirty patch to enable GNU APL to be
build with
OpenMP support.

./configure --with-openmp

There are many rough edges, both in the Makefile and the code.

--with-openmp would ideally check to see whether the compiler
supports
OpenMP. It may be necessary to check the compiler version, as
different
compilers support different versions of OpenMP. Also, I've assumed
compilation on/for Linux despite the fact that GNU APL and
OpenMP should
be buildable with the right Windows compiler.

As one might expect, OpenMP requires that any throw from a
worker thread
must be caught by the same thread. I'm almost certain that this
restriction could be violated by GNU APL code as currently
written.

The good news, though, is that the changes are benign; in the
absence of
--with-openmp, GNU APL's behavior is unchanged.

With OpenMP support, ⎕syl is extended to access some of OpenMPs
parameters.

I've done only trivial testing at this point; just enough to
verify that
compiling OpenMP support doesn't obviously break GNU APL.

I haven't confirmed that the OpenMP #pragmas on the key loops in
SkalarFunction.cc have any effect on execution time or
processor core
utilization. I hope to do more testing later this week.

Best wishes,
   David

Re: [Bug-apl] Experimental OpenMP patch


Hi Elias,

I believe we should first find out how big the thread dispatch effort 
actually is.
Because coalescing can also fir back by creating unequally distributed 
intermediate results.


For skalar functions you have a parallel eecution time of:

a + b×⌈N÷P where a = startup time (thread dispatch and clean-up), b = 
cost per cell, N = data size, and P = core count.


In eg. A + B + C coalescing would reduce the time from  2×(a + b×⌈N÷P) 
to a + 2 ×(b×⌈N÷P)


On the other hand in A + B ⍴ C things could be completely different 
because ⍴ can create a very unevenly sized right

argument of +.

I guess we have to look into the details of every function and operator 
to see what can be done in terms of parallel execution.
Starting with skalar functions seems to be a good strategy and I believe 
we should finish that first before looking into

more complex scenarios.

/// Jürgen




On 03/11/2014 04:24 PM, Elias Mårtenson wrote:
Oh and one more thing: Have you given any thought to my comments re. 
the coalescing of certain functions to reduce thread dispatch effort? 
(also, add some more functions to the no-copy optimisation?)


Regards,
Elias


On 11 March 2014 23:22, Elias Mårtenson <mailto:loke...@gmail.com>> wrote:


I agree. I just wanted to point out that without a runtime option,
delivering binary versions will be hard, forcing the package
maintainers to choose a default that will surely be wrong for the
majority of users.

That said, being able to choose a compile-time value is good too.

Regards,
Elias


On 11 March 2014 23:20, Juergen Sauermann
mailto:juergen.sauerm...@t-online.de>> wrote:

Hi,

we could do it similar to the LOG macro where you can choose
between
more efficient compile-time settings and less efficient
run-time settings.

It is important that we do these things properly from the
outset to avoid
too many changes later on.

/// Jürgen



On 03/11/2014 04:10 PM, Elias Mårtenson wrote:

May I suggest that being able to choose the number of cores
at runtime should actually be the default. Remember that most
Linux distributions will not compile the source on the local
machine and instead distributes binaries.

Having some #ifdefs would be good, and having runtime
user-selected (or automatically based on cores) number of
threads as default is important for this reason.

Regards,
Elias


On 11 March 2014 23:07, Juergen Sauermann
mailto:juergen.sauerm...@t-online.de>> wrote:

Hi David,

looks good! Some comments, though.

1 .you could adapt src/testcases/Performance.pt with some
longer
skalar functions in order to get some performance
figures. You can start it like this:

./apl -T testcases/Performance.pt

2. I believe we should not bother the user with
specifying parallelization parameters in ⎕SYL.
I would rather ./configure CORES=n with n=1 meaning no
parallel execution, CORES=auto
being the number of cores on the build machine, and
explicit numbers n>1 meaning that
n cores shall be used. This would generate slightly
faster code than computing array bounds
at runtime. Its a bit more hassle for the user, but may
pay off soon.

3. Yes, GNU APL throws many exception (almost every APL
error was thrown from somewhere),
 and I was excpecting that we have to catch them on the
throwing processor. Not too difficult if
we do it on the top level.

4. It would be good to understand how the OPenMP loops
work. I could imagined one of two strategies:

- in loop(j, MAX)   thread j executes iteration j,
j+CORES, ...
- thread j executes iterations j*MAX/CORES ...
(j+1)*MAX/CORES

The first strategy interleaves the data and is more intuitive
while the second uses blocks of data and is more
cache-friendly and therefore probably
giving better performance.

5. Not sure if your earlier comment on letting the
scheduler decide is correct. I have been doing
pthread programming in the past and I have seen cases
where the scheduler fooled itself and
led to cases where the same problem took more than double
the capacity compared to explicit
affinity on a 4-core CPU. I would expect that APL
generates very fine-graned and short-lived
pieces of execution and the scheduler may not be
optimized for that. I guess we have to try that out.

/// Jürgen




On 03/11/2014 08:02 AM

Re: [Bug-apl] Building on OS X 10.8.5 Mountain Lion - partly resolved….


Hi Peter,

I believe you should do something along the lines of:

CXX=llvm-gcc4 ./configure

/// Jürgen


On 03/11/2014 10:29 PM, Peter Teeson wrote:

On 2014-03-11, at 4:30 PM, Peter Teeson  wrote:

Mac Pro Desktop dual quad core CPU's, Mountain Lion OS X 10.8.5

I DL'd the 2014-01-13 APL 1.2 tar.gz and did ./configure.
Blew up because of
configure:2767: checking for gcc
configure:2797: result: no
configure:2860: checking for cc
configure:2907: result: no
configure:2963: checking for cl.exe
configure:2993: result: no
configure:3017: error: in `/Users/pteeson/Desktop/APL/apl-1.2':
configure:3020: error: no acceptable C compiler found in $PATH
See `config.log' for more details.

Apple's Xcode uses llvm-gcc4. I'm not deeply familiar with the whole GNU make 
system.
Do I need to set an environment var for gcc and cc?
Where is the proper place to do this? In configure.ac? AC_PROG_CXX AC_PROG_CC
Or some other way?

Sorry to be so ignorant of naked unix but it's never been necessary for me to 
dig that deep.

Thanks and respect….

Peter Teeson (formerly a 14 year member of the IPSA zoo a.k.a. dev group)

I booted into Lion OS X 10.7.6 and everything built and installed without a 
hitch.
Back in Mountain Lion I searched for llvm-gcc4 and it looks like it was not 
installed by default from the Xcode package.
Further digging uncovered this note in the "What's New in Xcode" document.
"NOTE: LLVM_GCC is not included in Xcode 5"

So that's where things stand right now. It seems to me there are a number of 
options for 10.8 Mountain Lion and forward:
(0) Install GCC4
(1) Try to build using llvm-clang
(2) Boot into 10.7 Lion to use APL

Personally I don't mind trying to do what it takes to try (1). I have the time 
( I'm in my mid 70s) and some experience.
But I'd need some guidance and help with the whole automake and friends to be 
of any use.

Seeking your advice ….

respect….

Peter

Re: [Bug-apl] OpenMP performance: first result


Hi David,

I guess the circle functions and ⋆/⍟ might do a better job in raising 
your motivation!


If I remember correctly then in 1990 we got a speedup of 5-6 on our 32 
processor machine,

which means that the break-even point is at about 6 cores.

Unfortunately my own machine has only 2 cores.

/// Jürgen



On 03/12/2014 07:04 AM, David Lamkins wrote:
WIth the OpenMP patch I put together last night, adding two 
million-element vectors went from about 45ms without OpenMP to about 
32ms with OpenMP.


That's evidence that OpenMP is doing *something*, even though the 
speedup is nowhere near commensurate with the number of cores (8 on 
this machine).


I wasn't expecting much at this early stage. I am, however, encouraged 
by the measurable result.


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


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

Re: [Bug-apl] Test case generation?


Hi,

I'm afraid cut-and-paste is the only tool around.

For performance testin it is probably simpler to )DUMP the 
Perfornmance.pt testcase
at the end and then modify/start the dumped workspace with apl -f. Then 
you don't need

to mess around with the matching of the interpreter output.

Or just cut-and-paste the functions defined in Performance.pt

/// Jürgen


On 03/12/2014 06:29 AM, David Lamkins wrote:

Are there any tools or techniques to assist in the generation of test
cases? The use of specific Unicode characters for pattern-matching
seems a bit fussy...

Re: [Bug-apl] "Largest integer" isnt' really largest?


Hi Elias,

thanks, fixed in SVN 162. In that range it can still happen that
"small" differences occur because an operation may be internally
performed as double and then converted to integer. The double has
48-1 bit precision and the integer 64-1 bit precision. It depends a little
on how the actual operation is implemented.

/// Jürgen


On 03/11/2014 04:32 PM, Elias Mårtenson wrote:

Running ⎕SYL shows the following:

  largest integer   9223372036854775807

Trying to subtract one from this value gives a weird result:

*9223372036854775807-1*
¯9223372036854775808

Regards,
Elias

Re: [Bug-apl] Crash upon throwing an error from quadSYL setters