Hi Xiao-Yong,
I know, there are a few differences between APL2 and the ISO
standard. In such cases
APL2 rules because a standard which is not implemented is less
useful than an implementation
of it.
/// Jürgen
not even 3[1] is good of even (3)[1]it has to be (,3)l1]it has
to be an ARRAY so the index can work
if this behavior is changed to do what apl2 has then this is no longer apl -
remember apl goes right to left
On Wed, 15 Feb 2017 14:44:18 -0600
Xiao-Yong Jin wrote:
> ISO/IE
ISO/IEC 13751:2000(E) disagrees.
On page 158, section 10.2.14 Indexed Reference,
there is an example
1 2 3[2]
2
> On Feb 15, 2017, at 2:22 PM, Juergen Sauermann
> wrote:
>
> Hi Xiao-Yong,
>
> IBM APL2.
>
> [] binds stronger than anything else.
>
> Thus 3[1 2] is evaluated first, giving
Hi Xiao-Yong,
IBM APL2.
[]
binds stronger than anything else.
Thus 3[1 2]
is evaluated first, giving the RANK ERROR.
/// Jürgen
On 02/15/2017 09:14 PM, Xiao-Yong Jin
wrote:
Feature or bu
you are really trying to takeindex of just 3 with 3[2 1 3]hence the
need for the ( )
On Wed, 15 Feb 2017 14:14:21 -0600
Xiao-Yong Jin wrote:
> Feature or bug?
>
> 1 2 3[2 1 3]
> RANK ERROR
> 1 2 3[2 1 3]
> ^^
> )sic
> (1 2 3)[2 1 3]
> 2 1 3
>
>
Feature or bug?
1 2 3[2 1 3]
RANK ERROR
1 2 3[2 1 3]
^^
)sic
(1 2 3)[2 1 3]
2 1 3
Hi Elias,
OK, could also be caused by multi-line macros or so. Sometimes the
line numbers displayed by diff are different
from those displayed in vi.
Thanks again,
/// Jürgen
On 02/15/2017 04:10 PM, Elias Mårtenson
wrote:
That's weird. I made the diff based on the most recent version in svn.
Regards,
Elias
On 15 Feb 2017 23:05, "Juergen Sauermann"
wrote:
> Hi Elias,
>
> yes, thanks for providing it. *SVN 887*.
>
> It seems like out line numbers are slightly out of sync.
>
> /// Jürgen
>
>
> On 02/15/2017 07:19 A
Hi Elias,
yes, thanks for providing it. SVN 887.
It seems like out line numbers are slightly out of sync.
/// Jürgen
On 02/15/2017 07:19 AM, Elias Mårtenson
wrote:
Jürgen? Could you merge the fix?
the glob length is 4K :)
if not your bash or shell then it is ap100 that is broken
On Tue, 14 Feb 2017 22:06:01 -0600
Frederick Pitts wrote:
> enztec,
>
> In a terminal interactive bash shell
>
> /bin/ls /apl/ap100/Sound/pl*
> /bin/ls /apl/ap100/Sound/pla*
>
> and in an apl interacti
Hi again,
fixed in SVN 886.
/// Jürgen
On 02/15/2017 03:12 PM, Juergen
Sauermann wrote:
Hi Kacper,
very interesting observation, thanks! It seems that on my box it
also occurs, but at much
Hi Kacper,
very interesting observation, thanks! It seems that on my box it
also occurs, but at much
longer strings:
100⎕SVO'OS'
1
OS←'echo
abcdefghijklmnopqrtsuvwxyzABCDEFGHIJKLM'
abcdefghijkl
Hi again,
please disregard my posting below, the mail from Kacper has shown
me a way to reproduce the fault.
/// Jürgen
On 02/15/2017 02:51 PM, Juergen
Sauermann wrote:
Hi Frederick,
First of al
Hi Frederick,
First of all, I believe the aclocal problem could be fixed
with running autoreconf before ./configure in
the same directory.
Regarding the SVN version, i am currently fairly confused. I am
working with two SVN repositories: a loca
On 15 February 2017 at 03:59, Frederick Pitts wrote:
> But the problem does seem specific to my platform.
I can reproduce it under debian testing. It appears that strings
longer than 12 are somehow misinterpreted by AP100 and garbage is
sent to popen. It doesn't seem to have anything to do with
enztec,
Juergen had me type the apl statements directly into an
interactive interpreter session (i.e., no cut-n-paste) and the same
error occurred on my machine. Also, I ran 'od -c foobar.apl', looked
for unexpected characters and did not find any. So it is not bad
characters hidden in t
16 matches
Mail list logo
