Re: try-GNU-APL non-functional

[Dr . Jürgen Sauermann]

  
  
Hi,
  
  http://juergen-sauermann.de/try-GNU-APL
  is up again. Seems like the server on which it is being
  hosted was restarted some days ago. I have changed the setup now
  so that try-GNU-APL is
  started automatically when the machine is  rebooted.
  
  Happy Xmas to all,
  Jürgen Sauermann
  
  

On 12/23/19 9:01 PM, Adám Brudzewsky
  wrote:


  
  It appears that try-GNU-APL isn't quite working. At
least, I can't make it answer 2+2, neither using Firefox, nor
Chrome.
  


  

Format issue with Try APL

[Blake McBride]

Greetings,

I took a look at the Try APL site http://juergen-sauermann.de/try-GNU-APL

I noticed a format / spacing problem.   I am attaching a PNG file the
depicts the problem.

Thanks!

Blake

Re: ⍬ bug?

[Dr . Jürgen Sauermann]

  
  
Hi David,
  
  not sure either if this is a bug. The APL standard has quite a
  specification gap
  when it comes to binding strength. In GNU APL, the binding between
  values
  (aka strand notation) is stronger than the binding between values
  and functions.
  
  For example:
  
    V←⍳0

∇Z←F
 Z←⍳0
∇
  
  Both V and F result in the same value ⍬:
  
    V≡F
1

  However, they are parsed differently:
  
    2 V 3⊃a
3
  
  2 F 3⊃a
 2    99 
  
  In the first case: 2 V 3⊃a
the value V binds strongly to 2 and 3 so that value (2
  V 3)
 becomes the left argument of ⊃. In the second case:  2 F 3
the value 3 binds
stronger to ⊃ than to F so that first  is evaluated 3⊃a
  and then the result of ⊃ is
  tied to the F and 2.
  
  In GNU APL ⍬ is a niladic function, so it behaves
  like F above.
  
  This behaviour could be changed, but I hesitate to do that
  since it might break
  existing code. The impact of such a change would not only
  affect ⍬ but all niladic
  functions.

  Best Regards,
  Jürgen Sauermann

  

On 12/24/19 2:49 AM, David Tran wrote:


  
  
Ooops, missing something on my examples, correction:  (
  missing ⊂ on ⍳3 )



a ← 'abc'(⊂⍳3)99


the 3 examples are the same:
2(⍳0)3⊃a
2⍬3⊃a
(2⍬3)⊃a

  
  
  
On Mon, Dec 23, 2019 at 7:20
  PM David Tran  wrote:


  
Hi,


Not sure this is a bug or not, for me, (⍳0) ≡ ⍬, so it
  seems that both can be replaced each other; consider below
  example:


a←'abc'(⍳3)99


2(⍳0)3⊃a ⍝ ≡ 3
2⍬3⊃a ⍝ ≡ 2 ⍬ 99
(2⍬3)⊃a ⍝ ≡ 3


Doesn't the second example should return 3 as first
  example, without the need parentheses as third example?


(btw. my version is build from SVN around Oct )





Thanks,
Dave






  

  


  

Re: ⍬ bug?

[Elias Mårtenson]

I think such a change would make sense. A niladic function is in some sense
a shortcut to writing a specific value, so it should probably be treated as
such.

It a little odd that:
  1 2 X 4
is different from:
  1 2 (X) 4

Regards,
Elias

On Tue, 24 Dec 2019, 14:48 Dr. Jürgen Sauermann, 
wrote:

> Hi David,
>
> not sure either if this is a bug. The APL standard has quite a
> specification gap
> when it comes to binding strength. In GNU APL, the binding between values
> (aka strand notation) is stronger than the binding between values and
> functions.
>
> For example:
>
> *  V←⍳0*
>
> *∇Z←F*
> * Z←⍳0*
> *∇*
>
> Both V and F result in the same value *⍬*:
>
> *  V≡F*
> *1*
>
> However, they are parsed differently:
>
> *  2 V 3⊃a*
>
>
> *3 **  2 F 3⊃a*
> * 299 *
>
> In the first case: *2 V 3⊃a* the value *V* binds strongly to 2 and 3 so
> that value *(2 V 3)*
>  becomes the left argument of *⊃*. In the second case:  *2 F 3* the value
> 3 binds
> stronger to *⊃* than to *F* so that first  is evaluated *3⊃a* and then
> the result of *⊃* is
> tied to the *F* and *2*.
>
> In GNU APL *⍬* is a niladic function, so it behaves like *F* above.
>
> This behaviour could be changed, but I hesitate to do that since it might
> break
> existing code. The impact of such a change would not only affect *⍬* but
> all niladic
> functions.
>
> Best Regards,
> Jürgen Sauermann
>
>
> On 12/24/19 2:49 AM, David Tran wrote:
>
> Ooops, missing something on my examples, correction:  ( missing ⊂ on ⍳3 )
>
> a ← 'abc'(⊂⍳3)99
>
> the 3 examples are the same:
> 2(⍳0)3⊃a
> 2⍬3⊃a
> (2⍬3)⊃a
>
> On Mon, Dec 23, 2019 at 7:20 PM David Tran  wrote:
>
>> Hi,
>>
>> Not sure this is a bug or not, for me, (⍳0) ≡ ⍬, so it seems that both
>> can be replaced each other; consider below example:
>>
>> a←'abc'(⍳3)99
>>
>> 2(⍳0)3⊃a ⍝ ≡ 3
>> 2⍬3⊃a ⍝ ≡ 2 ⍬ 99
>> (2⍬3)⊃a ⍝ ≡ 3
>>
>> Doesn't the second example should return 3 as first example, without the
>> need parentheses as third example?
>>
>> (btw. my version is build from SVN around Oct )
>>
>>
>> Thanks,
>> Dave
>>
>>
>>
>>
>

Re: Format issue with Try APL

[Dr . Jürgen Sauermann]

  
  
Hi Blake,
  
  thanks, hopefully fixed. This web stuff remains entirely dubious
  to me,
  so don't expect too much.
  
  Best Regards,
  Jürgen
  

On 12/24/19 1:59 PM, Blake McBride
  wrote:


  
  Greetings,


I took a look at the Try APL site http://juergen-sauermann.de/try-GNU-APL


I noticed a format / spacing problem.   I am attaching a
  PNG file the depicts the problem.


Thanks!


Blake


  


  

Re: ⍬ bug?

[Dr . Jürgen Sauermann]

  
  
Hi,
  
  yes. In some sense. Actually
  
  1 2 X 4
  
  is the same as 1 2 (X) 4
  
  because there is a rule that says so. However, the point here is
  that
  
1 2 X 4
  
  can be (very) different from

(1 2 X 4)

The difference does not occur in simple examples, but may in
more complex ones.
  
1 2
  X 4   + 1
  
  is generally different from
  
(1 2 X 4)   + 1

simply because the order of evaluation differs between X and +.
More generally, if
you put the left argument of a dyadic function in parentheses
then that most likely
(though not neccessarily) changes the valuation order (and hence
the result). I know
that this is odd, but so are niladic functions when it comes to
parsing. According to
the IBM APL 2 parentheses rules, the parantheses around (⍬) are
redundant (and
make no difference while the parentheses around (⍳0)
are not redundant. As a
consequence, even though ⍳0 yields essentially ⍬ they are not
entirely equivalent.

Best Regards,
Jürgen Sauermann


  

On 12/24/19 3:16 PM, Elias Mårtenson
  wrote:


  
  I think such a change would make sense. A niladic
function is in some sense a shortcut to writing a specific
value, so it should probably be treated as such.


It a little odd that:
  1 2 X 4
is different from:
  1 2 (X) 4


Regards, 
Elias 
  
  
  
On Tue, 24 Dec 2019, 14:48 Dr.
  Jürgen Sauermann, 
  wrote:


   Hi David,
  
  not sure either if this is a bug. The APL standard has
  quite a specification gap
  when it comes to binding strength. In GNU APL, the binding
  between values
  (aka strand notation) is stronger than the binding between
  values and functions.
  
  For example:
  
    V←⍳0

∇Z←F
 Z←⍳0
∇
  
  Both V and F result in the same value ⍬:
  
    V≡F
1

  However, they are parsed differently:
  
    2 V
  3⊃a
3
  
  2 F 3⊃a
 2    99 
  
  In the first case: 2
  V 3⊃a the value V binds strongly to 2 and
3 so that value (2 V 3)
 becomes the left argument of ⊃. In the second
case:  2 F 3
the value 3 binds
stronger to ⊃ than to F so that first  is
  evaluated 3⊃a and then the result of ⊃
  is
  tied to the F and 2.
  
  In GNU APL ⍬ is a niladic function, so it
  behaves like F above.
  
  This behaviour could be changed, but I hesitate to
  do that since it might break
  existing code. The impact of such a change would
  not only affect ⍬ but all niladic
  functions.

  Best Regards,
  Jürgen Sauermann

  

On 12/24/19 2:49 AM, David Tran wrote:


  
Ooops, missing something on my examples,
  correction:  ( missing ⊂ on ⍳3 )



a ← 'abc'(⊂⍳3)99


the 3 examples are the same:
2(⍳0)3⊃a
2⍬3⊃a
(2⍬3)⊃a

  
  
  
On Mon, Dec 23, 2019
  at 7:20 PM David Tran 
  wrote:


  
Hi,


Not sure this is a bug or not, for me, (⍳0) ≡
  ⍬, so it seems that both can be replaced each
  other; consider below example:


a←'abc'(⍳3)99


2(⍳0)3⊃a ⍝ ≡ 3
2⍬3⊃a ⍝ ≡ 2 ⍬ 99
(2⍬3)⊃a ⍝ ≡ 3

Re: Format issue with Try APL

[enztec]

Jurgen 

You are the only one sending your emails as html - it isn't a very security 
minded thing to do - usually only malware and tracking malware use html in 
emails

Thanks




On Tue, 24 Dec 2019 15:20:22 +0100
Dr. Jürgen Sauermann  wrote:

> 
>   
> 
>   
>   
> Hi Blake,
>   
>   thanks, hopefully fixed. This web stuff remains entirely dubious
>   to me,
>   so don't expect too much.
>   
>   Best Regards,
>   Jürgen
>   
> 
> On 12/24/19 1:59 PM, Blake McBride
>   wrote:
> 
>  cite="mid:CABwHSOu-JU9t40yGdN6ZBO_=kbn96+tkhrrw3iqzyate9ww...@mail.gmail.com">
>   
>   Greetings,
> 
> 
> I took a look at the Try APL site  href="http://juergen-sauermann.de/try-GNU-APL";
> 
> moz-do-not-send="true">http://juergen-sauermann.de/try-GNU-APL
> 
> 
> I noticed a format / spacing problem.   I am attaching a
>   PNG file the depicts the problem.
> 
> 
> Thanks!
> 
> 
> Blake
> 
> 
>   
> 
> 
>   
> 
> 

Re: Format issue with Try APL

[Dr . Jürgen Sauermann]

Hi,

the only options of my email client (thunderbird) seem to be plain text,
html,
or both plain text and html. I have seen that my formatting gets lost
when using
plain text. I believe sending such emails to bug-apl is safe, and I have
tagged
you as plain text receiver in my thunderbird address book.

If anyone else prefers plaintext, please let me know.

Mail forwarded from bug-apl is a differnt story, though. You are marked
as plaintext
receiver already, but apparently that setting only applies to emails sent as
"message digest" (whatever that means). Maybe you need to change your
subscription
to bug-apl in order to receive emails that way.

Best Regards,
Jürgen


On 12/24/19 4:38 PM, enz...@gmx.com wrote:
> Jurgen 
>
> You are the only one sending your emails as html - it isn't a very security 
> minded thing to do - usually only malware and tracking malware use html in 
> emails
>
> Thanks
>
>
>
>
> On Tue, 24 Dec 2019 15:20:22 +0100
> Dr. Jürgen Sauermann  wrote:
>
>> 
>>   
>> 
>>   
>>   
>> Hi Blake,
>>   
>>   thanks, hopefully fixed. This web stuff remains entirely dubious
>>   to me,
>>   so don't expect too much.
>>   
>>   Best Regards,
>>   Jürgen
>>   
>> 
>> On 12/24/19 1:59 PM, Blake McBride
>>   wrote:
>> 
>> > cite="mid:CABwHSOu-JU9t40yGdN6ZBO_=kbn96+tkhrrw3iqzyate9ww...@mail.gmail.com">
>>   
>>   Greetings,
>> 
>> 
>> I took a look at the Try APL site > href="http://juergen-sauermann.de/try-GNU-APL";
>> 
>> moz-do-not-send="true">http://juergen-sauermann.de/try-GNU-APL
>> 
>> 
>> I noticed a format / spacing problem.   I am attaching a
>>   PNG file the depicts the problem.
>> 
>> 
>> Thanks!
>> 
>> 
>> Blake
>> 
>> 
>>   
>> 
>> 
>>   
>> 
>>

Re: Format issue with Try APL

[enztec]

Hi

Thank you - now i can follow along with the new apl mailing list controversies 
^h^h^h topics

speaking of which - i am glad to see you are sticking with svn - i am trying to 
avoid git stuff especially on github now - i don't need microsoft knowing what 
software i use etc :) and i'm sure when it gets hacked (again?) some hacker 
will use it to learn who has older un-updated software versions and use that 
info for no good purpose. :) if not downright malware code insertion

---

btw - i use to use thunderbird until i could no longer compile it on my system 
with no gtk3 and had to find something else to use and luckily i found sylpheed
it has been great to use - the spam and other filters are great and you can use 
gnupg for encrypting email contents as well as using ssl to and from your 
smtp/pop3/imap server

since there is no guarentee of any encryption in the transport once it leaves 
your email hosting server on the way through other relays - email content 
encryption is good - lots of mail relays actually make sure NOT to use relay 
encryption -> makes things quicker and what do they care about your emails 
anyway ;)

I don't remember if thunderbird had this capability back then

http://sylpheed.sraoss.jp/sylpheed

and i saw some bad vulnerabilites continuing in thunderbird not to long ago and 
it seems to be continuing
https://www.mozilla.org/en-US/security/known-vulnerabilities/thunderbird/

Thanks

On Tue, 24 Dec 2019 17:03:48 +0100
Dr. Jürgen Sauermann  wrote:

> Hi,
> 
> the only options of my email client (thunderbird) seem to be plain text,
> html,
> or both plain text and html. I have seen that my formatting gets lost
> when using
> plain text. I believe sending such emails to bug-apl is safe, and I have
> tagged
> you as plain text receiver in my thunderbird address book.
> 
> If anyone else prefers plaintext, please let me know.
> 
> Mail forwarded from bug-apl is a differnt story, though. You are marked
> as plaintext
> receiver already, but apparently that setting only applies to emails sent as
> "message digest" (whatever that means). Maybe you need to change your
> subscription
> to bug-apl in order to receive emails that way.
> 
> Best Regards,
> Jürgen
> 
> 
> On 12/24/19 4:38 PM, enz...@gmx.com wrote:
> > Jurgen 
> >
> > You are the only one sending your emails as html - it isn't a very security 
> > minded thing to do - usually only malware and tracking malware use html in 
> > emails
> >
> > Thanks
> >
> >
> >
> >
> > On Tue, 24 Dec 2019 15:20:22 +0100
> > Dr. Jürgen Sauermann  wrote:
> >
> >> 
> >>   
> >> 
> >>   
> >>   
> >> Hi Blake,
> >>   
> >>   thanks, hopefully fixed. This web stuff remains entirely dubious
> >>   to me,
> >>   so don't expect too much.
> >>   
> >>   Best Regards,
> >>   Jürgen
> >>   
> >> 
> >> On 12/24/19 1:59 PM, Blake McBride
> >>   wrote:
> >> 
> >>  >> cite="mid:CABwHSOu-JU9t40yGdN6ZBO_=kbn96+tkhrrw3iqzyate9ww...@mail.gmail.com">
> >>   
> >>   Greetings,
> >> 
> >> 
> >> I took a look at the Try APL site  >> href="http://juergen-sauermann.de/try-GNU-APL";
> >> 
> >> moz-do-not-send="true">http://juergen-sauermann.de/try-GNU-APL
> >> 
> >> 
> >> I noticed a format / spacing problem.   I am attaching a
> >>   PNG file the depicts the problem.
> >> 
> >> 
> >> Thanks!
> >> 
> >> 
> >> Blake
> >> 
> >> 
> >>   
> >> 
> >> 
> >>   
> >> 
> >>
>