Re: [Bug-apl] FILE_IO library

[Juergen Sauermann]

Hi,

the ⍝⍝ comes from way doxygen works.

For example, // is a C/C++ comment while /// is a C/C++ comment
understood by doxygen.

In VHDL, -- is a VHDL comment while --- is a VHDL comment understood by 
doxygen. etc.


I didn't want to go as far as using ⍝⍝⍝ (and no need to since ⍝ alone is 
a comment.


Looking at the output of doxygen, it is definitely needed to be able to 
distinguish between
normal comments and doxygen comments. Otherwise well-documented programs 
will look

rather odd in the generated documentation.

Doxygen also distinguishes between long and short comments. Not sure if 
we need that;

with short comments alone you can produce pretty good documentation.

/// Jürgen


On 08/01/2014 01:01 AM, David B. Lamkins wrote:

On Fri, 2014-08-01 at 00:32 +0800, Elias Mårtenson wrote:

So you are basically suggesting using the same principle as me, just
using two ⍝ symbols instead of one? I'm OK with that. :-)

I have a difficult time imagining a use case that'd have two different
kinds of comments at the beginning of a function.

However, on the off chance that someone really needs to hide some of the
header comment from documentation extraction, how about -- rather than
always having to double-up the ⍝ -- recognizing a "cut line". For
example:

∇foo
   ⍝ This is part of the formal documentation.
   ⍝ So is this.
   ⍝ And all subsequent lines up to the cut:
   ⍝--
   ⍝ The ⍝-- is the cut line. That line and all
   ⍝ immediately following comment lines are
   ⍝ omitted from the formal documentation.
   ⍝ I showed the cut line by itself; there's no
   ⍝ strong reason to not allow (ignored) text
   ⍝ on the same line.
   statement1
   statement2
   ⍝ This comment follows an APL statement, so
   ⍝ is not part of the formal documentation of
   ⍝ this function.
∇



Should be first line be the "summary"? Should we allow leading spaces
before the ⍝⍝?

I'm not convinced of the value of a summary, but would rather not be
limited to one line.

Leading whitespace should always be insignificant.



Should we assume that the content of the doc comment is HTML or some
other kind of markup?


I'm not at all fond of HTML markup as program documentation. It's
cumbersome and ugly and interferes with reading of the source code.
Also, mixed syntaxes tend to confuse syntax-aware text editors.

If there's a strong need for markup, please consider a lightweight
syntax. Emacs docstrings are a good example. A small subset of Markdown
would also be reasonable, IMO.

Re: [Bug-apl] FILE_IO library

[Elias Mårtenson]

So, should we settle for double ⍝ then? In other words, like this:

∇Z←foo X
  ⍝⍝ Doc comment
  ⍝⍝ This one too
  ⍝ But not this one
  Z←X+1
∇

Regards,
Elias


On 1 August 2014 17:56, Juergen Sauermann 
wrote:

> Hi,
>
> the ⍝⍝ comes from way doxygen works.
>
> For example, // is a C/C++ comment while /// is a C/C++ comment
> understood by doxygen.
>
> In VHDL, -- is a VHDL comment while --- is a VHDL comment understood by
> doxygen. etc.
>
> I didn't want to go as far as using ⍝⍝⍝ (and no need to since ⍝ alone is a
> comment.
>
> Looking at the output of doxygen, it is definitely needed to be able to
> distinguish between
> normal comments and doxygen comments. Otherwise well-documented programs
> will look
> rather odd in the generated documentation.
>
> Doxygen also distinguishes between long and short comments. Not sure if we
> need that;
> with short comments alone you can produce pretty good documentation.
>
> /// Jürgen
>
>
>
> On 08/01/2014 01:01 AM, David B. Lamkins wrote:
>
>> On Fri, 2014-08-01 at 00:32 +0800, Elias Mårtenson wrote:
>>
>>> So you are basically suggesting using the same principle as me, just
>>> using two ⍝ symbols instead of one? I'm OK with that. :-)
>>>
>> I have a difficult time imagining a use case that'd have two different
>> kinds of comments at the beginning of a function.
>>
>> However, on the off chance that someone really needs to hide some of the
>> header comment from documentation extraction, how about -- rather than
>> always having to double-up the ⍝ -- recognizing a "cut line". For
>> example:
>>
>> ∇foo
>>⍝ This is part of the formal documentation.
>>⍝ So is this.
>>⍝ And all subsequent lines up to the cut:
>>⍝--
>>⍝ The ⍝-- is the cut line. That line and all
>>⍝ immediately following comment lines are
>>⍝ omitted from the formal documentation.
>>⍝ I showed the cut line by itself; there's no
>>⍝ strong reason to not allow (ignored) text
>>⍝ on the same line.
>>statement1
>>statement2
>>⍝ This comment follows an APL statement, so
>>⍝ is not part of the formal documentation of
>>⍝ this function.
>> ∇
>>
>>
>>> Should be first line be the "summary"? Should we allow leading spaces
>>> before the ⍝⍝?
>>>
>> I'm not convinced of the value of a summary, but would rather not be
>> limited to one line.
>>
>> Leading whitespace should always be insignificant.
>>
>>
>>> Should we assume that the content of the doc comment is HTML or some
>>> other kind of markup?
>>>
>>>  I'm not at all fond of HTML markup as program documentation. It's
>> cumbersome and ugly and interferes with reading of the source code.
>> Also, mixed syntaxes tend to confuse syntax-aware text editors.
>>
>> If there's a strong need for markup, please consider a lightweight
>> syntax. Emacs docstrings are a good example. A small subset of Markdown
>> would also be reasonable, IMO.
>>
>>
>>
>>
>

Re: [Bug-apl] Matching ]keyb on WASD keyboard

[Juergen Sauermann]

Hi Blake,

thanks, applied. Will be contained in the next SVN.

/// Jürgen


On 08/01/2014 06:14 AM, Blake McBride wrote:
Enclosed is an update to my WASD keyboard configuration.  The GNU APL 
distribution should be updated with this.  I added/corrected the 
following:


χ
¥
⍹
⍶
⍙
£
¢

I now exactly match ]keyb.

Thanks.

Blake

Re: [Bug-apl] FILE_IO library

[Juergen Sauermann]

Hi,

from my side - yes.

/// Jürgen



On 08/01/2014 12:00 PM, Elias Mårtenson wrote:

So, should we settle for double ⍝ then? In other words, like this:

∇Z←foo X
  ⍝⍝ Doc comment
  ⍝⍝ This one too
  ⍝ But not this one
  Z←X+1
∇

Regards,
Elias


On 1 August 2014 17:56, Juergen Sauermann 
mailto:juergen.sauerm...@t-online.de>> 
wrote:


Hi,

the ⍝⍝ comes from way doxygen works.

For example, // is a C/C++ comment while /// is a C/C++ comment
understood by doxygen.

In VHDL, -- is a VHDL comment while --- is a VHDL comment
understood by doxygen. etc.

I didn't want to go as far as using ⍝⍝⍝ (and no need to since ⍝
alone is a comment.

Looking at the output of doxygen, it is definitely needed to be
able to distinguish between
normal comments and doxygen comments. Otherwise well-documented
programs will look
rather odd in the generated documentation.

Doxygen also distinguishes between long and short comments. Not
sure if we need that;
with short comments alone you can produce pretty good documentation.

/// Jürgen



On 08/01/2014 01:01 AM, David B. Lamkins wrote:

On Fri, 2014-08-01 at 00:32 +0800, Elias Mårtenson wrote:

So you are basically suggesting using the same principle
as me, just
using two ⍝ symbols instead of one? I'm OK with that. :-)

I have a difficult time imagining a use case that'd have two
different
kinds of comments at the beginning of a function.

However, on the off chance that someone really needs to hide
some of the
header comment from documentation extraction, how about --
rather than
always having to double-up the ⍝ -- recognizing a "cut line". For
example:

∇foo
   ⍝ This is part of the formal documentation.
   ⍝ So is this.
   ⍝ And all subsequent lines up to the cut:
   ⍝--
   ⍝ The ⍝-- is the cut line. That line and all
   ⍝ immediately following comment lines are
   ⍝ omitted from the formal documentation.
   ⍝ I showed the cut line by itself; there's no
   ⍝ strong reason to not allow (ignored) text
   ⍝ on the same line.
   statement1
   statement2
   ⍝ This comment follows an APL statement, so
   ⍝ is not part of the formal documentation of
   ⍝ this function.
∇


Should be first line be the "summary"? Should we allow
leading spaces
before the ⍝⍝?

I'm not convinced of the value of a summary, but would rather
not be
limited to one line.

Leading whitespace should always be insignificant.


Should we assume that the content of the doc comment is
HTML or some
other kind of markup?

I'm not at all fond of HTML markup as program documentation. It's
cumbersome and ugly and interferes with reading of the source
code.
Also, mixed syntaxes tend to confuse syntax-aware text editors.

If there's a strong need for markup, please consider a lightweight
syntax. Emacs docstrings are a good example. A small subset of
Markdown
would also be reasonable, IMO.

Re: [Bug-apl] FILE_IO library

[Juergen Sauermann]

Hi,

do you have an example? Seems to work outside emacs:

*  ⎕FX 'FOO' '1' '' '3'**
**FOO**
**  ⎕CR 'FOO'**
**FOO**
**1 **

**3 **
*
/// Jürgen

On 08/01/2014 04:15 AM, Elias Mårtenson wrote:
Oh yeah, now that you mention it I remember seeing the same thing. 
Blank lines gets eaten when the function is defined using ⎕FX. You can 
see that when using the function editor in the Emacs mode.

Re: [Bug-apl] FILE_IO library

[Elias Mårtenson]

OK, I'll update the Emacs code to do this.

Regards,
Elias


On 1 August 2014 18:11, Juergen Sauermann 
wrote:

>  Hi,
>
> from my side - yes.
>
> /// Jürgen
>
>
>
>
> On 08/01/2014 12:00 PM, Elias Mårtenson wrote:
>
> So, should we settle for double ⍝ then? In other words, like this:
>
>  ∇Z←foo X
>   ⍝⍝ Doc comment
>   ⍝⍝ This one too
>   ⍝ But not this one
>   Z←X+1
> ∇
>
>  Regards,
>  Elias
>
>
> On 1 August 2014 17:56, Juergen Sauermann 
> wrote:
>
>> Hi,
>>
>> the ⍝⍝ comes from way doxygen works.
>>
>> For example, // is a C/C++ comment while /// is a C/C++ comment
>> understood by doxygen.
>>
>> In VHDL, -- is a VHDL comment while --- is a VHDL comment understood by
>> doxygen. etc.
>>
>> I didn't want to go as far as using ⍝⍝⍝ (and no need to since ⍝ alone is
>> a comment.
>>
>> Looking at the output of doxygen, it is definitely needed to be able to
>> distinguish between
>> normal comments and doxygen comments. Otherwise well-documented programs
>> will look
>> rather odd in the generated documentation.
>>
>> Doxygen also distinguishes between long and short comments. Not sure if
>> we need that;
>> with short comments alone you can produce pretty good documentation.
>>
>> /// Jürgen
>>
>>
>>
>> On 08/01/2014 01:01 AM, David B. Lamkins wrote:
>>
>>> On Fri, 2014-08-01 at 00:32 +0800, Elias Mårtenson wrote:
>>>
 So you are basically suggesting using the same principle as me, just
 using two ⍝ symbols instead of one? I'm OK with that. :-)

>>> I have a difficult time imagining a use case that'd have two different
>>> kinds of comments at the beginning of a function.
>>>
>>> However, on the off chance that someone really needs to hide some of the
>>> header comment from documentation extraction, how about -- rather than
>>> always having to double-up the ⍝ -- recognizing a "cut line". For
>>> example:
>>>
>>> ∇foo
>>>⍝ This is part of the formal documentation.
>>>⍝ So is this.
>>>⍝ And all subsequent lines up to the cut:
>>>⍝--
>>>⍝ The ⍝-- is the cut line. That line and all
>>>⍝ immediately following comment lines are
>>>⍝ omitted from the formal documentation.
>>>⍝ I showed the cut line by itself; there's no
>>>⍝ strong reason to not allow (ignored) text
>>>⍝ on the same line.
>>>statement1
>>>statement2
>>>⍝ This comment follows an APL statement, so
>>>⍝ is not part of the formal documentation of
>>>⍝ this function.
>>> ∇
>>>
>>>
 Should be first line be the "summary"? Should we allow leading spaces
 before the ⍝⍝?

>>> I'm not convinced of the value of a summary, but would rather not be
>>> limited to one line.
>>>
>>> Leading whitespace should always be insignificant.
>>>
>>>
 Should we assume that the content of the doc comment is HTML or some
 other kind of markup?

  I'm not at all fond of HTML markup as program documentation. It's
>>> cumbersome and ugly and interferes with reading of the source code.
>>> Also, mixed syntaxes tend to confuse syntax-aware text editors.
>>>
>>> If there's a strong need for markup, please consider a lightweight
>>> syntax. Emacs docstrings are a good example. A small subset of Markdown
>>> would also be reasonable, IMO.
>>>
>>>
>>>
>>>
>>
>
>

Re: [Bug-apl] FILE_IO library

[Elias Mårtenson]

I just checked my code, and it actually passes empty strings as a
one-character string containing a single space instead. I think I did that
in order to avoid some problems I had earlier with empty lines. Here's the
code that does it:
https://github.com/lokedhs/gnu-apl-mode/blob/master/native/DefCommand.cc#L49

With this code, blank lines gets eliminated. Are you suggesting I change
this to use Str0(LOC) instead?

Regards,
Elias


On 1 August 2014 18:27, Elias Mårtenson  wrote:

> OK, I'll update the Emacs code to do this.
>
> Regards,
> Elias
>
>
> On 1 August 2014 18:11, Juergen Sauermann 
> wrote:
>
>>  Hi,
>>
>> from my side - yes.
>>
>> /// Jürgen
>>
>>
>>
>>
>> On 08/01/2014 12:00 PM, Elias Mårtenson wrote:
>>
>> So, should we settle for double ⍝ then? In other words, like this:
>>
>>  ∇Z←foo X
>>   ⍝⍝ Doc comment
>>   ⍝⍝ This one too
>>   ⍝ But not this one
>>   Z←X+1
>> ∇
>>
>>  Regards,
>>  Elias
>>
>>
>> On 1 August 2014 17:56, Juergen Sauermann 
>> wrote:
>>
>>> Hi,
>>>
>>> the ⍝⍝ comes from way doxygen works.
>>>
>>> For example, // is a C/C++ comment while /// is a C/C++ comment
>>> understood by doxygen.
>>>
>>> In VHDL, -- is a VHDL comment while --- is a VHDL comment understood by
>>> doxygen. etc.
>>>
>>> I didn't want to go as far as using ⍝⍝⍝ (and no need to since ⍝ alone is
>>> a comment.
>>>
>>> Looking at the output of doxygen, it is definitely needed to be able to
>>> distinguish between
>>> normal comments and doxygen comments. Otherwise well-documented programs
>>> will look
>>> rather odd in the generated documentation.
>>>
>>> Doxygen also distinguishes between long and short comments. Not sure if
>>> we need that;
>>> with short comments alone you can produce pretty good documentation.
>>>
>>> /// Jürgen
>>>
>>>
>>>
>>> On 08/01/2014 01:01 AM, David B. Lamkins wrote:
>>>
 On Fri, 2014-08-01 at 00:32 +0800, Elias Mårtenson wrote:

> So you are basically suggesting using the same principle as me, just
> using two ⍝ symbols instead of one? I'm OK with that. :-)
>
 I have a difficult time imagining a use case that'd have two different
 kinds of comments at the beginning of a function.

 However, on the off chance that someone really needs to hide some of the
 header comment from documentation extraction, how about -- rather than
 always having to double-up the ⍝ -- recognizing a "cut line". For
 example:

 ∇foo
⍝ This is part of the formal documentation.
⍝ So is this.
⍝ And all subsequent lines up to the cut:
⍝--
⍝ The ⍝-- is the cut line. That line and all
⍝ immediately following comment lines are
⍝ omitted from the formal documentation.
⍝ I showed the cut line by itself; there's no
⍝ strong reason to not allow (ignored) text
⍝ on the same line.
statement1
statement2
⍝ This comment follows an APL statement, so
⍝ is not part of the formal documentation of
⍝ this function.
 ∇


> Should be first line be the "summary"? Should we allow leading spaces
> before the ⍝⍝?
>
 I'm not convinced of the value of a summary, but would rather not be
 limited to one line.

 Leading whitespace should always be insignificant.


> Should we assume that the content of the doc comment is HTML or some
> other kind of markup?
>
>  I'm not at all fond of HTML markup as program documentation. It's
 cumbersome and ugly and interferes with reading of the source code.
 Also, mixed syntaxes tend to confuse syntax-aware text editors.

 If there's a strong need for markup, please consider a lightweight
 syntax. Emacs docstrings are a good example. A small subset of Markdown
 would also be reasonable, IMO.




>>>
>>
>>
>

Re: [Bug-apl] FILE_IO library

[Elias Mårtenson]

It's changed. You can pull the new version of SQL.apl which now has
double-lamps for the docstrings.


On 1 August 2014 18:27, Elias Mårtenson  wrote:

> OK, I'll update the Emacs code to do this.
>
> Regards,
> Elias
>
>
> On 1 August 2014 18:11, Juergen Sauermann 
> wrote:
>
>>  Hi,
>>
>> from my side - yes.
>>
>> /// Jürgen
>>
>>
>>
>>
>> On 08/01/2014 12:00 PM, Elias Mårtenson wrote:
>>
>> So, should we settle for double ⍝ then? In other words, like this:
>>
>>  ∇Z←foo X
>>   ⍝⍝ Doc comment
>>   ⍝⍝ This one too
>>   ⍝ But not this one
>>   Z←X+1
>> ∇
>>
>>  Regards,
>>  Elias
>>
>>
>> On 1 August 2014 17:56, Juergen Sauermann 
>> wrote:
>>
>>> Hi,
>>>
>>> the ⍝⍝ comes from way doxygen works.
>>>
>>> For example, // is a C/C++ comment while /// is a C/C++ comment
>>> understood by doxygen.
>>>
>>> In VHDL, -- is a VHDL comment while --- is a VHDL comment understood by
>>> doxygen. etc.
>>>
>>> I didn't want to go as far as using ⍝⍝⍝ (and no need to since ⍝ alone is
>>> a comment.
>>>
>>> Looking at the output of doxygen, it is definitely needed to be able to
>>> distinguish between
>>> normal comments and doxygen comments. Otherwise well-documented programs
>>> will look
>>> rather odd in the generated documentation.
>>>
>>> Doxygen also distinguishes between long and short comments. Not sure if
>>> we need that;
>>> with short comments alone you can produce pretty good documentation.
>>>
>>> /// Jürgen
>>>
>>>
>>>
>>> On 08/01/2014 01:01 AM, David B. Lamkins wrote:
>>>
 On Fri, 2014-08-01 at 00:32 +0800, Elias Mårtenson wrote:

> So you are basically suggesting using the same principle as me, just
> using two ⍝ symbols instead of one? I'm OK with that. :-)
>
 I have a difficult time imagining a use case that'd have two different
 kinds of comments at the beginning of a function.

 However, on the off chance that someone really needs to hide some of the
 header comment from documentation extraction, how about -- rather than
 always having to double-up the ⍝ -- recognizing a "cut line". For
 example:

 ∇foo
⍝ This is part of the formal documentation.
⍝ So is this.
⍝ And all subsequent lines up to the cut:
⍝--
⍝ The ⍝-- is the cut line. That line and all
⍝ immediately following comment lines are
⍝ omitted from the formal documentation.
⍝ I showed the cut line by itself; there's no
⍝ strong reason to not allow (ignored) text
⍝ on the same line.
statement1
statement2
⍝ This comment follows an APL statement, so
⍝ is not part of the formal documentation of
⍝ this function.
 ∇


> Should be first line be the "summary"? Should we allow leading spaces
> before the ⍝⍝?
>
 I'm not convinced of the value of a summary, but would rather not be
 limited to one line.

 Leading whitespace should always be insignificant.


> Should we assume that the content of the doc comment is HTML or some
> other kind of markup?
>
>  I'm not at all fond of HTML markup as program documentation. It's
 cumbersome and ugly and interferes with reading of the source code.
 Also, mixed syntaxes tend to confuse syntax-aware text editors.

 If there's a strong need for markup, please consider a lightweight
 syntax. Emacs docstrings are a good example. A small subset of Markdown
 would also be reasonable, IMO.




>>>
>>
>>
>

Re: [Bug-apl] Determining data type...

[Peter Teeson]

Thank you Kacper for both your original reply and this clarification.
My eyesight is not what it used to be… we persevere however.

respect…

Peter

On 2014-07-31, at 10:53 PM, Kacper Gutowski  wrote:

> On 2014-07-31 22:49:06, Peter Teeson wrote:
>> David used theta as well. Is that also an available symbol?
>> i.e. a greek letter not otherwise used by the APL language?
> 
> You're probably refering to ⍬.  This is not a theta.  This symbol
> is called zilde and it should look like zero with superimposed
> tilde.  It's not specifically related to lambdas.
> Zilde stands for a numeric vector of zero length (just like '' is
> a character vector).  You can write (0⍴0) instead of ⍬.
> 
> 
> -k

Re: [Bug-apl] FILE_IO library

[Juergen Sauermann]

Hi Elias,

as far as I can see you use a nested vector of strings as right argument 
of ⎕FX.

In that case Str0() is the best way to represent an empty line.

Another thing I saw is that you instantiate a Quad_FX object. That is 
unnecessary

because there is an instance called fun for every system function already.
You should use Quad_FX::fun instead.

/// Jürgen


On 08/01/2014 12:37 PM, Elias Mårtenson wrote:
I just checked my code, and it actually passes empty strings as a 
one-character string containing a single space instead. I think I did 
that in order to avoid some problems I had earlier with empty lines. 
Here's the code that does it: 
https://github.com/lokedhs/gnu-apl-mode/blob/master/native/DefCommand.cc#L49 



With this code, blank lines gets eliminated. Are you suggesting I 
change this to use Str0(LOC) instead?


Regards,
Elias

Re: [Bug-apl] 80 core performance results

[Elias Mårtenson]

Were you able to deduce anything from the test results?
On 11 May 2014 23:02, "Juergen Sauermann" 
wrote:

>  Hi Elias,
>
> thanks, already interesting. If you could loop around the core count:
>
> *for ((i=1; $i<=80; ++i)); do*
> * ./Parallel $i*
> * ./Parallel_OMP $i*
> *done*
>
> then I could understand the data better. Also not sure if something
> is wrong with the benchmark program. On my new 4-core with OMP I get
> fluctuations from:
>
> eedjsa@server65 ~/apl-1.3/tools $ ./Parallel_OMP 4
> Pass 0: 4 cores/threads, 8229949 cycles total
> Pass 1: 4 cores/threads, 8262 cycles total
> Pass 2: 4 cores/threads, 4035 cycles total
> Pass 3: 4 cores/threads, 4126 cycles total
> Pass 4: 4 cores/threads, 4179 cycles total
>
> to:
>
> eedjsa@server65 ~/apl-1.3/tools $ ./Parallel_OMP 4
> Pass 0: 4 cores/threads, 11368032 cycles total
> Pass 1: 4 cores/threads, 4042228 cycles total
> Pass 2: 4 cores/threads, 7251419 cycles total
> Pass 3: 4 cores/threads, 3846 cycles total
> Pass 4: 4 cores/threads, 2725 cycles total
>
> The fluctuations with the manual parallel for are smaller:
>
> Pass 0: 4 cores/threads, 87225 cycles total
> Pass 1: 4 cores/threads, 245046 cycles total
> Pass 2: 4 cores/threads, 84632 cycles total
> Pass 3: 4 cores/threads, 63619 cycles total
> Pass 4: 4 cores/threads, 93437 cycles total
>
> but still considerable. The picture so far suggests that OMP fluctuates
> much
> more (in the start-up + sync time) than manual with the highest OMP
> start-up above manual
> and the lowest far below. One change on my  TODO list is to use futexes
> instead of mutexes
> (like OMP does), probably not an issue under Solaris sunce futextes are
> linux-specific.
>
> /// Jürgen
>
>
> On 05/11/2014 04:23 AM, Elias Mårtenson wrote:
>
> Here are the files that I promised earlier.
>
>  Regards,
> Elias
>
>
>

Re: [Bug-apl] FILE_IO library

[Elias Mårtenson]

Thank you. I will implement this shortly. Make sure you update it before
the 1.4 release.

Regards,
Elias
On 1 Aug 2014 20:57, "Juergen Sauermann" 
wrote:

>  Hi Elias,
>
> as far as I can see you use a nested vector of strings as right  argument
> of ⎕FX.
> In that case Str0() is the best way to represent an empty line.
>
> Another thing I saw is that you instantiate a Quad_FX object. That is
> unnecessary
> because there is an instance called fun for every system function already.
> You should use Quad_FX::fun instead.
>
> /// Jürgen
>
>
> On 08/01/2014 12:37 PM, Elias Mårtenson wrote:
>
> I just checked my code, and it actually passes empty strings as a
> one-character string containing a single space instead. I think I did that
> in order to avoid some problems I had earlier with empty lines. Here's the
> code that does it:
> https://github.com/lokedhs/gnu-apl-mode/blob/master/native/DefCommand.cc#L49
>
>  With this code, blank lines gets eliminated. Are you suggesting I change
> this to use Str0(LOC) instead?
>
>  Regards,
> Elias
>
>
>
>
>
>

Re: [Bug-apl] 80 core performance results

[Juergen Sauermann]

Hi Elias,

yes - actually a lot. I haven't looked through all files, but
at 80, 60, and small core counts.

The good news is that all results look plausible now. There are some 
variations

in the data, of course, but the trend is clear:

The total time for OMP (the rightmost value in the plot, i.e. x == 
corecount + 10) is consistently
about twice the total time for a hand-crafted fork/sync. The benchmark 
was made in such way
that it only shows the fork/join times. Column N ≤ corecount shows the 
time when the N'th core

started execution of its task.

I have attached a plot for the 80 core result (4 hand-crafted runs in 
red and 4 OMP runs in green).

And the script that created the plots using gnuplot.

/// Jürgen


On 08/01/2014 03:16 PM, Elias Mårtenson wrote:


Were you able to deduce anything from the test results?

On 11 May 2014 23:02, "Juergen Sauermann" 
mailto:juergen.sauerm...@t-online.de>> 
wrote:


Hi Elias,

thanks, already interesting. If you could loop around the core count:

*for ((i=1; $i<=80; ++i)); do**
** ./Parallel $i**
** ./Parallel_OMP $i**
**done*

then I could understand the data better. Also not sure if something
is wrong with the benchmark program. On my new 4-core with OMP I get
fluctuations from:

eedjsa@server65 ~/apl-1.3/tools $ ./Parallel_OMP 4
Pass 0: 4 cores/threads, 8229949 cycles total
Pass 1: 4 cores/threads, 8262 cycles total
Pass 2: 4 cores/threads, 4035 cycles total
Pass 3: 4 cores/threads, 4126 cycles total
Pass 4: 4 cores/threads, 4179 cycles total

to:

eedjsa@server65 ~/apl-1.3/tools $ ./Parallel_OMP 4
Pass 0: 4 cores/threads, 11368032 cycles total
Pass 1: 4 cores/threads, 4042228 cycles total
Pass 2: 4 cores/threads, 7251419 cycles total
Pass 3: 4 cores/threads, 3846 cycles total
Pass 4: 4 cores/threads, 2725 cycles total

The fluctuations with the manual parallel for are smaller:

Pass 0: 4 cores/threads, 87225 cycles total
Pass 1: 4 cores/threads, 245046 cycles total
Pass 2: 4 cores/threads, 84632 cycles total
Pass 3: 4 cores/threads, 63619 cycles total
Pass 4: 4 cores/threads, 93437 cycles total

but still considerable. The picture so far suggests that OMP
fluctuates much
more (in the start-up + sync time) than manual with the highest
OMP start-up above manual
and the lowest far below. One change on my  TODO list is to use
futexes instead of mutexes
(like OMP does), probably not an issue under Solaris sunce
futextes are linux-specific.

/// Jürgen


On 05/11/2014 04:23 AM, Elias Mårtenson wrote:

Here are the files that I promised earlier.

Regards,
Elias





CORES=$1

cat << ENDCAT > plot_cmd
#! /usr/bin/gnuplot

set terminal png
set output "result_$CORES.png"

  plot \
"./cores_${CORES}_pass_1.manual" with lines 1, \
"./cores_${CORES}_pass_2.manual" with lines 1, \
"./cores_${CORES}_pass_3.manual" with lines 1, \
"./cores_${CORES}_pass_4.manual" with lines 1, \
"./cores_${CORES}_pass_1.omp" with lines 2, \
"./cores_${CORES}_pass_2.omp" with lines 2, \
"./cores_${CORES}_pass_3.omp" with lines 2, \
"./cores_${CORES}_pass_4.omp" with lines 2

ENDCAT

chmod 755 plot_cmd
./plot_cmd

Re: [Bug-apl] FILE_IO library

[Elias Mårtenson]

OK, it's been committed now. Now it's possible to put blank lines in the
function editor.

Regards,
Elias


On 1 August 2014 21:15, Elias Mårtenson  wrote:

> Thank you. I will implement this shortly. Make sure you update it before
> the 1.4 release.
>
> Regards,
> Elias
> On 1 Aug 2014 20:57, "Juergen Sauermann" 
> wrote:
>
>>  Hi Elias,
>>
>> as far as I can see you use a nested vector of strings as right  argument
>> of ⎕FX.
>> In that case Str0() is the best way to represent an empty line.
>>
>> Another thing I saw is that you instantiate a Quad_FX object. That is
>> unnecessary
>> because there is an instance called fun for every system function already.
>> You should use Quad_FX::fun instead.
>>
>> /// Jürgen
>>
>>
>> On 08/01/2014 12:37 PM, Elias Mårtenson wrote:
>>
>> I just checked my code, and it actually passes empty strings as a
>> one-character string containing a single space instead. I think I did that
>> in order to avoid some problems I had earlier with empty lines. Here's the
>> code that does it:
>> https://github.com/lokedhs/gnu-apl-mode/blob/master/native/DefCommand.cc#L49
>>
>>  With this code, blank lines gets eliminated. Are you suggesting I
>> change this to use Str0(LOC) instead?
>>
>>  Regards,
>> Elias
>>
>>
>>
>>
>>
>>

Re: [Bug-apl] Error defining operators using lambda

[Juergen Sauermann]

Hi Elias,

thanks, fixed in SVN 411.

/// Jürgen


On 08/01/2014 04:13 AM, Elias Mårtenson wrote:

The following definition throws a SYNTAX ERROR:

*  foo ← { (1 ⍶ ⍵) }*
SYNTAX ERROR
foo←foo
^   ^

Calling it directly works though:

*  +{1 ⍶ ⍵} 10*
11

Regards,
Elias

Re: [Bug-apl] FILE_IO library

[Juergen Sauermann]

Hi Elias,

thanks, included in SVN 411.

/// Jürgen


On 08/01/2014 03:58 PM, Elias Mårtenson wrote:
OK, it's been committed now. Now it's possible to put blank lines in 
the function editor.


Regards,
Elias


On 1 August 2014 21:15, Elias Mårtenson > wrote:


Thank you. I will implement this shortly. Make sure you update it
before the 1.4 release.

Regards,
Elias

On 1 Aug 2014 20:57, "Juergen Sauermann"
mailto:juergen.sauerm...@t-online.de>> wrote:

Hi Elias,

as far as I can see you use a nested vector of strings as
right  argument of ⎕FX.
In that case Str0() is the best way to represent an empty line.

Another thing I saw is that you instantiate a Quad_FX object.
That is unnecessary
because there is an instance called fun for every system
function already.
You should use Quad_FX::fun instead.

/// Jürgen


On 08/01/2014 12:37 PM, Elias Mårtenson wrote:

I just checked my code, and it actually passes empty strings
as a one-character string containing a single space instead.
I think I did that in order to avoid some problems I had
earlier with empty lines. Here's the code that does it:

https://github.com/lokedhs/gnu-apl-mode/blob/master/native/DefCommand.cc#L49


With this code, blank lines gets eliminated. Are you
suggesting I change this to use Str0(LOC) instead?

Regards,
Elias

Re: [Bug-apl] FILE_IO library

[David B. Lamkins]

My mistake. I went back and checked my code; I was passing ⍬ rather than
'' for an empty line.

I've fixed my code; the package manager will now load APL which has
empty lines in function definitions.

On Fri, 2014-08-01 at 12:17 +0200, Juergen Sauermann wrote:
> Hi,
> 
> do you have an example? Seems to work outside emacs:
> 
>   ⎕FX 'FOO' '1' '' '3'
> FOO
>   ⎕CR 'FOO'
> FOO
> 1  
>
> 3  
> 
> /// Jürgen
> 
> On 08/01/2014 04:15 AM, Elias Mårtenson wrote:
> 
> > Oh yeah, now that you mention it I remember seeing the same thing.
> > Blank lines gets eaten when the function is defined using ⎕FX. You
> > can see that when using the function editor in the Emacs mode.
> > 
> > 
> > 
> 

[Bug-apl] apl.xkb

[Blake McBride]

GNU APL comes with a file named apl.xkb under the support-files directory.
 I just did some testing of it with a normal (non-apl) keyboard.  The
mappings in that file are way out-of-date and do not match ]keyb output.
 That would also be true of the compiled version of that file - apl.xkm.

I then tested my WASD map file - apl.wasd.xkb.  That file correctly maps a
non-apl keyboard to map correctly with ]keyb output.

Although my WASD config file was made for my WASD keyboard design, it also
completely correctly maps to non-APL keyboards too.

I suggest that:

1.  support-files/apl.wasd.kbd be copied to apl.xkb

2.  remove apl.xkm

3.  Update the docs to use apl.xkb rather than apl.xkm (just substitute
apl.xkm with apl.xkb in README-3-keyboard

Thanks.

Blake

[Bug-apl] README-3-keyboard

[Blake McBride]

That file contains a picture of a keyboard (]keyb output) that does not
match the actual output of ]keyb.  I suggest we fix that.


Also, apl.xmodmap matches the old layout and not the new (]keyb) map.
 Please let me know if you would like me to correct it.

Thanks.

Blake

[Bug-apl] apl.dyalog.xmodmap

[Blake McBride]

This keyboard map better defines the keyboard (per ]keyb) but it too is out
of date.

Re: [Bug-apl] FILE_IO library

[Elias Mårtenson]

I've fixed the Quad_FX::fun thing as well now.

Regards,
Elias


On 1 August 2014 20:57, Juergen Sauermann 
wrote:

>  Hi Elias,
>
> as far as I can see you use a nested vector of strings as right  argument
> of ⎕FX.
> In that case Str0() is the best way to represent an empty line.
>
> Another thing I saw is that you instantiate a Quad_FX object. That is
> unnecessary
> because there is an instance called fun for every system function already.
> You should use Quad_FX::fun instead.
>
> /// Jürgen
>
>
>
> On 08/01/2014 12:37 PM, Elias Mårtenson wrote:
>
> I just checked my code, and it actually passes empty strings as a
> one-character string containing a single space instead. I think I did that
> in order to avoid some problems I had earlier with empty lines. Here's the
> code that does it:
> https://github.com/lokedhs/gnu-apl-mode/blob/master/native/DefCommand.cc#L49
>
>  With this code, blank lines gets eliminated. Are you suggesting I change
> this to use Str0(LOC) instead?
>
>  Regards,
> Elias
>
>
>
>
>
>

Re: [Bug-apl] Can't break out of the middle on a display operation

[Blake McBride]

On Mon, Jul 21, 2014 at 5:33 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:

>  Hi Blake,
>
> unfortunately the rules for APL output are such that you cannot "print as
> you go".
>


Try ⍳10

That should be able to print as you go - IBM APL does.  Right now there is
a significant delay - that I presume is unnecessarily using a significant
amount of memory to hold the formatted string.

Of course, you still can't ^C out of that either - but that's a different
matter.

I understand that in many situations you must format the whole thing before
you can can see how it lays out.  But that is not true in cases where it
clearly doesn't fit (like ⍳10) and many, many cases where it is too
large to have a reasonable format.  Those are the cases when
print-as-you-go can be done and would be without delay, and save
significant memory - and hopefully easier to interrupt.

Thanks.

Blake



>
> For example before printing the second item in the first row, the first
> column must have
> been formatted completely in order to know the width of the first column.
>
> I will see what I can do for aborting the formatting process or the
> printout with ^C.
>
> /// Jürgen
>
>
>
> On 07/21/2014 11:57 AM, Blake McBride wrote:
>
> Dear Juergen,
>
>  I don't think that really solves the problem because:
>
>  A.  You have to remember to set it - and then to set it only to get
> around what amounts to a bug - not being able to hit ^C
>
>  B.  Whatever you set it to, you still have a problem with lengths that
> approach that length.
>
>  C.  What if you are not in development, the user types a very large
> number accidentally in response to a prompt, the program dies and tries to
> display the arguments.  You end up with a hung program that no one can
> interrupt.
>
>  I don't understand why you have to format the whole thing before
> printing anything (which is what I presume because of the long delay).
>  Presumably hand-in-hand, I don't understand what you can't catch ^C there
> too.
>
>  Thanks.
>
>  Blake
>
>
>
> On Mon, Jul 21, 2014 at 4:47 AM, Juergen Sauermann <
> juergen.sauerm...@t-online.de> wrote:
>
>>  Hi Blake,
>>
>> I guess the proposed solution for both was ⎕SYL. Like:
>>
>> *  ⎕SYL[27] ← 1*
>>
>> /// Jürgen
>>
>>
>>
>> On 07/21/2014 12:26 AM, Blake McBride wrote:
>>
>> Are my two items below a dead issue?
>>
>>  Thanks!
>>
>>  Blake
>>
>>
>> On Tue, Jul 8, 2014 at 9:58 PM, Blake McBride 
>> wrote:
>>
>>> I think the layout function need two modifications:
>>>
>>>  1.  enable ^C
>>>
>>>  2.  at least for large data, output as you go rather than format the
>>> whole thing and then output the whole thing
>>>
>>>  --blake
>>>
>>>
>>>
>>> On Tue, Jul 8, 2014 at 9:27 PM, Elias Mårtenson 
>>> wrote:
>>>
 There is already the SIGINT signal which is processed by GNU APL to
 interrupt a function execution. However, this interruptability is not
 extended to the layout function.


 On 9 July 2014 09:09, Peter Teeson  wrote:

> In Sharp APL (IPSA) we had a "panic int" which interrupted whatever
> was being computed after a predetermined time.
> It was inherent to the interpreter because we ran a timesharing system.
> I don't recall the exact details but it went something like this;
>
> 1) Workspace gets swapped in for execution and is given a quantum of
> CPU time
> 2) At the end of that quantum a second but quite small (relative to
> the normal ) additional amount of CPU was allocated
>  to see if that would allow an interrupt at a "suitable" point in the
> function/operation that was going on.
> 3) If that extra time was not sufficient the workspace was arbitrarily
> interrupted and AFAICR the user got )CLEAR WS.
>
> That's probably not exactly correct (I never read the actual assembly
> code for that part of the interpreter).
> But the idea worked for us.
>
> On a single user system there is no real need for a specific quantum;
> the OS takes care of  scheduling.
> But perhaps a "panic int" concept in some form or other might be
> useful?
> Perhaps allowing the user to decide if they want to continue?
> Perhaps with a default value? Perhaps assignable by the user?
>
> respect…
>
> Peter
>
> On 2014-07-08, at 1:50 PM, Blake McBride  wrote:
>
> > If I do:
> >
> >   z←⍳100
> >
> > the operation is very fast.  But if I do:
> >
> >   ⍳100
> >
> > it is very slow, presumably because it is formatting the whole thing
> for display.  No problem.
> >
> > The problem is that during its effort to format for display, I
> cannot use ^C.  ^C appears to work fine in normal situations - but not
> during the format for display time.  During format-for-display time ^C is
> ignored.
> >
> > This caused me a problem when I accidentally mis-typed something.
>  The mis-type caused some

[Bug-apl] GNU APL on a Mac

[Blake McBride]

Greetings,

I understand that some have gotten GNU APL working on a Mac.  I've not
tried this, and the doc files (such as README-3-keyboard) do not mention
it.  It would be great if someone who has GNU APL running on a Mac could
provide instructions that could be added to the various README files.

Same for Windows.

Thanks.

Blake

Re: [Bug-apl] GNU APL on a Mac

[Peter Teeson]

Back in March this year I wrote up a small guide which you can find in the doc 
folder. 
It's title is APL-on-Macintosh.pdf Should you run into issues I may be able to 
help.

And of course if you find errors in the pdf or poorly written bits 
please let me know and I will correct it.

respect…

Peter

On 2014-08-01, at 1:18 PM, Blake McBride  wrote:

> Greetings,
> 
> I understand that some have gotten GNU APL working on a Mac.  I've not tried 
> this, and the doc files (such as README-3-keyboard) do not mention it.  It 
> would be great if someone who has GNU APL running on a Mac could provide 
> instructions that could be added to the various README files.
> 
> Same for Windows.
> 
> Thanks.
> 
> Blake
> 

Re: [Bug-apl] GNU APL on a Mac

[Blake McBride]

Dear Peter,

Wow.  I somehow missed that.  Really great job!

Thanks!

Blake



On Fri, Aug 1, 2014 at 12:45 PM, Peter Teeson 
wrote:

> Back in March this year I wrote up a small guide which you can find in the
> doc folder.
> It's title is APL-on-Macintosh.pdf Should you run into issues I may be
> able to help.
>
> And of course if you find errors in the pdf or poorly written bits
> please let me know and I will correct it.
>
> respect…
>
> Peter
>
> On 2014-08-01, at 1:18 PM, Blake McBride  wrote:
>
> > Greetings,
> >
> > I understand that some have gotten GNU APL working on a Mac.  I've not
> tried this, and the doc files (such as README-3-keyboard) do not mention
> it.  It would be great if someone who has GNU APL running on a Mac could
> provide instructions that could be added to the various README files.
> >
> > Same for Windows.
> >
> > Thanks.
> >
> > Blake
> >
>
>

Re: [Bug-apl] GNU APL on a Mac

[Peter Teeson]

Let me know if there are problems.
These days I always use the latest svn update rather than the tar ball release.
Of course that's after the initial svn co.

respect…

Peter
On 2014-08-01, at 2:19 PM, Blake McBride  wrote:
> Dear Peter,
> 
> Wow.  I somehow missed that.  Really great job!  
> 
> Thanks!
> 
> Blake
> 
> 
> 
> On Fri, Aug 1, 2014 at 12:45 PM, Peter Teeson  wrote:
> Back in March this year I wrote up a small guide which you can find in the 
> doc folder.
> It's title is APL-on-Macintosh.pdf Should you run into issues I may be able 
> to help.
> 
> And of course if you find errors in the pdf or poorly written bits
> please let me know and I will correct it.
> 
> respect…
> 
> Peter
> 
> On 2014-08-01, at 1:18 PM, Blake McBride  wrote:
> 
> > Greetings,
> >
> > I understand that some have gotten GNU APL working on a Mac.  I've not 
> > tried this, and the doc files (such as README-3-keyboard) do not mention 
> > it.  It would be great if someone who has GNU APL running on a Mac could 
> > provide instructions that could be added to the various README files.
> >
> > Same for Windows.
> >
> > Thanks.
> >
> > Blake
> >
> 
> 

[Bug-apl] One more patch for indentation

[David B. Lamkins]

Elias,

Here's a patch that allows gnu-apl-indent-amounts to be specified in a
file's mode-line. See additional comments in the patch file (attached).
This patch allows specification of gnu-apl-indent-amounts as a
buffer-local variable in the mode line of a file.

For example:
⍝ -*- mode: gnu-apl; gnu-apl-indent-amounts: (0 1 1 2) -*-

The local variable is accepted only if well-formed and reasonable.

diff --git a/gnu-apl-mode.el b/gnu-apl-mode.el
index 9b8210f..bda6a12 100644
--- a/gnu-apl-mode.el
+++ b/gnu-apl-mode.el
@@ -110,6 +110,13 @@ The ∇s are always flush-left, as are all lines outside of functions."
(integer :tag "Number of spaces before comment line   ")
(integer :tag "Number of spaces before label  ")
(integer :tag "Number of space before other lines "))
+  :safe '(lambda (v)
+   (and (listp v)
+(= 4 (length v))
+(every 'integerp v)
+(every '(lambda (n)
+  (and (>= n 0) (<= n 6)))
+   v)))
   :group 'gnu-apl)
 
 ;;;###autoload