Re: [Bug-apl] Subtle parsing problem
Hi Elias,
this is because your lambdas are niladic. The right lambda is called
before SEL,
while the left lambda is called by SEL. From SEL's perspective, 'then';
is a function
while 'else' is a value.
/// Jürgen
On 07/29/2014 07:21 AM, Elias Mårtenson wrote:
I was writing an operator that acts as an "if"-statement, calling one
of two functions depending on the value of the argument:
∇Z ← (then SEL else) arg
→(arg=1)/do¯then
→(arg=0)/do¯else
⎕ES 'Illegal value for arg'
→0
do¯then:
Z ← then arg
→0
do¯else:
Z ← else arg
∇
Note that the then and else functions are called with an argument
"arg". When I call this operator with two nihilic lambda functions, I
get very strange behaviour:
* ⊣ ({⎕←'was true'} SEL {⎕←'was false'}) 0*
was false
* ⊣ ({⎕←'was true'} SEL {⎕←'was false'}) 1*
was false
was true
I would expect to get an error message here, or perhaps seeing (⎕NC
'⍵') to be 0. I certainly didn't expect to see both functions be
called. My suspicion is that there is a problem with the parser
somewhere, but I think Jürgen will have to look at this one.
Regards,
Elias
Re: [Bug-apl] Subtle parsing problem
Hmm, so having a right-hand nildaic function passed to an operator simply
doesn't work. Oh well, makes sense once you think about it. :-)
This was all part of experimentation I was playing around with while
thinking about the power operator. Have you given that one any thought yet?
Regards,
Elias
On 29 July 2014 19:55, Juergen Sauermann
wrote:
> Hi Elias,
>
> this is because your lambdas are niladic. The right lambda is called
> before SEL,
> while the left lambda is called by SEL. From SEL's perspective, 'then'; is
> a function
> while 'else' is a value.
>
> /// Jürgen
>
>
>
> On 07/29/2014 07:21 AM, Elias Mårtenson wrote:
>
> I was writing an operator that acts as an "if"-statement, calling one of
> two functions depending on the value of the argument:
>
> ∇Z ← (then SEL else) arg
> →(arg=1)/do¯then
> →(arg=0)/do¯else
> ⎕ES 'Illegal value for arg'
> →0
> do¯then:
> Z ← then arg
> →0
> do¯else:
> Z ← else arg
> ∇
>
> Note that the then and else functions are called with an argument "arg".
> When I call this operator with two nihilic lambda functions, I get very
> strange behaviour:
>
> * ⊣ ({⎕←'was true'} SEL {⎕←'was false'}) 0*
> was false
> * ⊣ ({⎕←'was true'} SEL {⎕←'was false'}) 1*
> was false
> was true
>
> I would expect to get an error message here, or perhaps seeing (⎕NC '⍵')
> to be 0. I certainly didn't expect to see both functions be called. My
> suspicion is that there is a problem with the parser somewhere, but I think
> Jürgen will have to look at this one.
>
> Regards,
> Elias
>
>
>
Re: [Bug-apl] Subtle parsing problem
Hi,
I have put the power operator onto my long-term TODO list (aka
README-4-compliance), SVN 402.
BTW the somewhat unexpected behavior of your niladic functions comes
from the IMHO broken syntax
of the rank operator (which allows values where unaware people would
expect functions). Before that
your right lambda would have returned a value and the SEL would have
triggered a syntax error.
My concern in the context of lambdas is that if we drive that too far
then we would create new cases
that nobody can understand anymore.
/// Jürgen
On 07/29/2014 02:11 PM, Elias Mårtenson wrote:
Hmm, so having a right-hand nildaic function passed to an operator
simply doesn't work. Oh well, makes sense once you think about it. :-)
This was all part of experimentation I was playing around with while
thinking about the power operator. Have you given that one any thought
yet?
Regards,
Elias
On 29 July 2014 19:55, Juergen Sauermann
mailto:juergen.sauerm...@t-online.de>>
wrote:
Hi Elias,
this is because your lambdas are niladic. The right lambda is
called before SEL,
while the left lambda is called by SEL. From SEL's perspective,
'then'; is a function
while 'else' is a value.
/// Jürgen
On 07/29/2014 07:21 AM, Elias Mårtenson wrote:
I was writing an operator that acts as an "if"-statement, calling
one of two functions depending on the value of the argument:
∇Z ← (then SEL else) arg
→(arg=1)/do¯then
→(arg=0)/do¯else
⎕ES 'Illegal value for arg'
→0
do¯then:
Z ← then arg
→0
do¯else:
Z ← else arg
∇
Note that the then and else functions are called with an argument
"arg". When I call this operator with two nihilic lambda
functions, I get very strange behaviour:
* ⊣ ({⎕←'was true'} SEL {⎕←'was false'}) 0*
was false
* ⊣ ({⎕←'was true'} SEL {⎕←'was false'}) 1*
was false
was true
I would expect to get an error message here, or perhaps seeing
(⎕NC '⍵') to be 0. I certainly didn't expect to see both
functions be called. My suspicion is that there is a problem with
the parser somewhere, but I think Jürgen will have to look at
this one.
Regards,
Elias
Re: [Bug-apl] Remaining APserver issues
Hi Elias, looks like either no APserver is running or the APserver listens on another socket. Check with netstat -l -p. That should show a line like: tcp0 0 localhost:16366 *:* LISTEN 2631/APserver If the APserver does not get killed then this is the problem I had earlier but could not reproduce. If you can reproduce it, please uncomment the *#define USE_POLL***at the beginning of *APserver.cc* and reinstall. That will tell us if *poll()* works better than *select()*. If not, we could try tcp_keepalive to see if that works better. /// Jürgen On 07/29/2014 05:27 AM, Elias Mårtenson wrote: The following happens on my Arch Linux system. When I start the apl binary (without Emacs) I'm getting a "connection refused" error. The log with *-l 37* is reproduced below. The APserver is properly started (I can see it in the process listing), but after I call )OFF, it doesn't get killed. Note that if I start APserver separately, I do not get any errors, and everything seems to work correctly. Here's the output from -l 37 (errors highlighted in red): $ *dist/bin/apl -l 37 --silent* sizeof(Svar_record) is328 sizeof(Svar_partner) is 28 initializing paths from argv[0] = dist/bin/apl initializing paths from $PWD = /home/emartenson/src/apl APL_bin_path is: ./dist/bin APL_bin_name is: apl Reading config file /home/emartenson/src/apl/dist/etc/gnu-apl.d/preferences ... config file /home/emartenson/.config/gnu-apl/preferences is not present/readable 0 input files: Using TCP socket towards APserver... connecting to 127.0.0.1 TCP port 16366 (this is expected to fail, unless APserver was started manually) forking new APserver listening on 127.0.0.1 TCP port 16366 connecting to 127.0.0.1 TCP port 16366 (this is supposed to succeed.) ::connect() to existing APserver failed: Connection refused PID is 24054 argc: 4 argv[0]: 'dist/bin/apl' argv[1]: '-l' argv[2]: '37' argv[3]: '--silent' uprefs.user_do_svars: 1 uprefs.system_do_svars: 1 uprefs.requested_id:0 uprefs.requested_par: 0 Svar_DB not connected in Svar_DB::is_registered_id() id.proc: 1001 at ProcessorID.cc:77 Processor ID was completely initialized: 1001:0:0 system_do_svars is: 1 * ⎕SVQ⍳0* Svar_DB not connected in Svar_DB::get_offering_processors() 100 210 Regards. Elias
Re: [Bug-apl] Remaining APserver issues
I don't think so. The APserver is definitely started. Also, if I start another apl it's able to connect to the previous one. My theory is the same as before, I think that apl attempts to connect to APserver before it's ready to accept connections. Also, given the fact that apl never connects to APserver, it's not very strange that it's not killed when apl exits. In the case where I start a second apl that connects to the first APserver, it does get killed properly. Regards, Elias On 29 Jul 2014 21:02, "Juergen Sauermann" wrote: > Hi Elias, > > looks like either no APserver is running or the APserver listens on > another socket. > Check with netstat -l -p. That should show a line like: > > tcp0 0 localhost:16366 *:* > LISTEN 2631/APserver > > If the APserver does not get killed then this is the problem I had earlier > but could not reproduce. > If you can reproduce it, please uncomment the *#define USE_POLL* at the > beginning of *APserver.cc* > and reinstall. That will tell us if *poll()* works better than *select()*. > If not, we could try tcp_keepalive to > see if that works better. > > /// Jürgen > > On 07/29/2014 05:27 AM, Elias Mårtenson wrote: > > The following happens on my Arch Linux system. > > When I start the apl binary (without Emacs) I'm getting a "connection > refused" error. The log with *-l 37* is reproduced below. > > The APserver is properly started (I can see it in the process listing), > but after I call )OFF, it doesn't get killed. > > Note that if I start APserver separately, I do not get any errors, and > everything seems to work correctly. > > Here's the output from -l 37 (errors highlighted in red): > > $ *dist/bin/apl -l 37 --silent* > sizeof(Svar_record) is328 > sizeof(Svar_partner) is 28 > > initializing paths from argv[0] = dist/bin/apl > initializing paths from $PWD = /home/emartenson/src/apl > APL_bin_path is: ./dist/bin > APL_bin_name is: apl > Reading config file > /home/emartenson/src/apl/dist/etc/gnu-apl.d/preferences ... > config file /home/emartenson/.config/gnu-apl/preferences is not > present/readable > 0 input files: > Using TCP socket towards APserver... > connecting to 127.0.0.1 TCP port 16366 > (this is expected to fail, unless APserver was started manually) > forking new APserver listening on 127.0.0.1 TCP port 16366 > connecting to 127.0.0.1 TCP port 16366 > (this is supposed to succeed.) > ::connect() to existing APserver failed: Connection refused > PID is 24054 > argc: 4 > argv[0]: 'dist/bin/apl' > argv[1]: '-l' > argv[2]: '37' > argv[3]: '--silent' > uprefs.user_do_svars: 1 > uprefs.system_do_svars: 1 > uprefs.requested_id:0 > uprefs.requested_par: 0 > Svar_DB not connected in Svar_DB::is_registered_id() > id.proc: 1001 at ProcessorID.cc:77 > Processor ID was completely initialized: 1001:0:0 > system_do_svars is: 1 > * ⎕SVQ⍳0* > Svar_DB not connected in Svar_DB::get_offering_processors() > 100 210 > > Regards. > Elias > > >
Re: [Bug-apl] Remaining APserver issues
Hi, that makes me think that APserver is listening on a different socket type than the one apl is using. Therefore, netstat -l -p to see where APserver listens and apl -l 37 to see where apl tries to connect. /// Jürgen On 07/29/2014 03:07 PM, Elias Mårtenson wrote: I don't think so. The APserver is definitely started. Also, if I start another apl it's able to connect to the previous one. My theory is the same as before, I think that apl attempts to connect to APserver before it's ready to accept connections. Also, given the fact that apl never connects to APserver, it's not very strange that it's not killed when apl exits. In the case where I start a second apl that connects to the first APserver, it does get killed properly. Regards, Elias On 29 Jul 2014 21:02, "Juergen Sauermann" mailto:juergen.sauerm...@t-online.de>> wrote: Hi Elias, looks like either no APserver is running or the APserver listens on another socket. Check with netstat -l -p. That should show a line like: tcp0 0 localhost:16366 *:* LISTEN 2631/APserver If the APserver does not get killed then this is the problem I had earlier but could not reproduce. If you can reproduce it, please uncomment the *#define USE_POLL***at the beginning of *APserver.cc* and reinstall. That will tell us if *poll()* works better than *select()*. If not, we could try tcp_keepalive to see if that works better. /// Jürgen On 07/29/2014 05:27 AM, Elias Mårtenson wrote: The following happens on my Arch Linux system. When I start the apl binary (without Emacs) I'm getting a "connection refused" error. The log with *-l 37* is reproduced below. The APserver is properly started (I can see it in the process listing), but after I call )OFF, it doesn't get killed. Note that if I start APserver separately, I do not get any errors, and everything seems to work correctly. Here's the output from -l 37 (errors highlighted in red): $ *dist/bin/apl -l 37 --silent* sizeof(Svar_record) is328 sizeof(Svar_partner) is 28 initializing paths from argv[0] = dist/bin/apl initializing paths from $PWD = /home/emartenson/src/apl APL_bin_path is: ./dist/bin APL_bin_name is: apl Reading config file /home/emartenson/src/apl/dist/etc/gnu-apl.d/preferences ... config file /home/emartenson/.config/gnu-apl/preferences is not present/readable 0 input files: Using TCP socket towards APserver... connecting to 127.0.0.1 TCP port 16366 (this is expected to fail, unless APserver was started manually) forking new APserver listening on 127.0.0.1 TCP port 16366 connecting to 127.0.0.1 TCP port 16366 (this is supposed to succeed.) ::connect() to existing APserver failed: Connection refused PID is 24054 argc: 4 argv[0]: 'dist/bin/apl' argv[1]: '-l' argv[2]: '37' argv[3]: '--silent' uprefs.user_do_svars: 1 uprefs.system_do_svars: 1 uprefs.requested_id:0 uprefs.requested_par: 0 Svar_DB not connected in Svar_DB::is_registered_id() id.proc: 1001 at ProcessorID.cc:77 Processor ID was completely initialized: 1001:0:0 system_do_svars is: 1 *⎕SVQ⍳0* Svar_DB not connected in Svar_DB::get_offering_processors() 100 210 Regards. Elias
Re: [Bug-apl] Subtle parsing problem
I agree in part. My opinion is that all of these problems would be solvable
if immediate lambdas required an explicit function call to be evaluated.
I.e. {⍵} 1 should not evaluate to 1, but rather the function itself and the
number one. Then, having a separate symbol to force evaluation.
Sadly, this is not the case, of course,so the above is just me dreaming. :-)
That said, I believe that lambdas should be extended to become more
"functional" and generic. This includes lexical closures as well as proper
first-class functions. To do so, however, would require first looking at
how other APL's do it, as there is no reason to reinvent the wheel. Also,
there are more important things to do first. :-)
Regards,
Elias
On 29 Jul 2014 20:48, "Juergen Sauermann"
wrote:
> Hi,
>
> I have put the power operator onto my long-term TODO list (aka
> README-4-compliance), SVN 402.
>
> BTW the somewhat unexpected behavior of your niladic functions comes from
> the IMHO broken syntax
> of the rank operator (which allows values where unaware people would
> expect functions). Before that
> your right lambda would have returned a value and the SEL would have
> triggered a syntax error.
>
> My concern in the context of lambdas is that if we drive that too far then
> we would create new cases
> that nobody can understand anymore.
>
> /// Jürgen
>
>
> On 07/29/2014 02:11 PM, Elias Mårtenson wrote:
>
> Hmm, so having a right-hand nildaic function passed to an operator simply
> doesn't work. Oh well, makes sense once you think about it. :-)
>
> This was all part of experimentation I was playing around with while
> thinking about the power operator. Have you given that one any thought yet?
>
> Regards,
> Elias
>
>
> On 29 July 2014 19:55, Juergen Sauermann
> wrote:
>
>> Hi Elias,
>>
>> this is because your lambdas are niladic. The right lambda is called
>> before SEL,
>> while the left lambda is called by SEL. From SEL's perspective, 'then';
>> is a function
>> while 'else' is a value.
>>
>> /// Jürgen
>>
>>
>>
>> On 07/29/2014 07:21 AM, Elias Mårtenson wrote:
>>
>> I was writing an operator that acts as an "if"-statement, calling one
>> of two functions depending on the value of the argument:
>>
>> ∇Z ← (then SEL else) arg
>> →(arg=1)/do¯then
>> →(arg=0)/do¯else
>> ⎕ES 'Illegal value for arg'
>> →0
>> do¯then:
>> Z ← then arg
>> →0
>> do¯else:
>> Z ← else arg
>> ∇
>>
>> Note that the then and else functions are called with an argument
>> "arg". When I call this operator with two nihilic lambda functions, I get
>> very strange behaviour:
>>
>> * ⊣ ({⎕←'was true'} SEL {⎕←'was false'}) 0*
>> was false
>> * ⊣ ({⎕←'was true'} SEL {⎕←'was false'}) 1*
>> was false
>> was true
>>
>> I would expect to get an error message here, or perhaps seeing (⎕NC '⍵')
>> to be 0. I certainly didn't expect to see both functions be called. My
>> suspicion is that there is a problem with the parser somewhere, but I think
>> Jürgen will have to look at this one.
>>
>> Regards,
>> Elias
>>
>>
>>
>
>
Re: [Bug-apl] Remaining APserver issues
I will definitely check this when I get back to the office tomorrow. I'll keep you posted. Thanks and regards, Elias On 29 July 2014 21:13, Juergen Sauermann wrote: > Hi, > > that makes me think that APserver is listening on a different socket type > than the one apl is using. > Therefore, netstat -l -p to see where APserver listens and apl -l 37 to > see where apl tries to connect. > > /// Jürgen > > > > > On 07/29/2014 03:07 PM, Elias Mårtenson wrote: > > I don't think so. The APserver is definitely started. Also, if I start > another apl it's able to connect to the previous one. > > My theory is the same as before, I think that apl attempts to connect to > APserver before it's ready to accept connections. > > Also, given the fact that apl never connects to APserver, it's not very > strange that it's not killed when apl exits. > > In the case where I start a second apl that connects to the first > APserver, it does get killed properly. > > Regards, > Elias > On 29 Jul 2014 21:02, "Juergen Sauermann" > wrote: > >> Hi Elias, >> >> looks like either no APserver is running or the APserver listens on >> another socket. >> Check with netstat -l -p. That should show a line like: >> >> tcp0 0 localhost:16366 *:* >> LISTEN 2631/APserver >> >> If the APserver does not get killed then this is the problem I had >> earlier but could not reproduce. >> If you can reproduce it, please uncomment the *#define USE_POLL* at the >> beginning of *APserver.cc* >> and reinstall. That will tell us if *poll()* works better than *select()*. >> If not, we could try tcp_keepalive to >> see if that works better. >> >> /// Jürgen >> >> On 07/29/2014 05:27 AM, Elias Mårtenson wrote: >> >> The following happens on my Arch Linux system. >> >> When I start the apl binary (without Emacs) I'm getting a "connection >> refused" error. The log with *-l 37* is reproduced below. >> >> The APserver is properly started (I can see it in the process listing), >> but after I call )OFF, it doesn't get killed. >> >> Note that if I start APserver separately, I do not get any errors, and >> everything seems to work correctly. >> >> Here's the output from -l 37 (errors highlighted in red): >> >> $ *dist/bin/apl -l 37 --silent* >> sizeof(Svar_record) is328 >> sizeof(Svar_partner) is 28 >> >> initializing paths from argv[0] = dist/bin/apl >> initializing paths from $PWD = /home/emartenson/src/apl >> APL_bin_path is: ./dist/bin >> APL_bin_name is: apl >> Reading config file >> /home/emartenson/src/apl/dist/etc/gnu-apl.d/preferences ... >> config file /home/emartenson/.config/gnu-apl/preferences is not >> present/readable >> 0 input files: >> Using TCP socket towards APserver... >> connecting to 127.0.0.1 TCP port 16366 >> (this is expected to fail, unless APserver was started manually) >> forking new APserver listening on 127.0.0.1 TCP port 16366 >> connecting to 127.0.0.1 TCP port 16366 >> (this is supposed to succeed.) >> ::connect() to existing APserver failed: Connection refused >> PID is 24054 >> argc: 4 >> argv[0]: 'dist/bin/apl' >> argv[1]: '-l' >> argv[2]: '37' >> argv[3]: '--silent' >> uprefs.user_do_svars: 1 >> uprefs.system_do_svars: 1 >> uprefs.requested_id:0 >> uprefs.requested_par: 0 >> Svar_DB not connected in Svar_DB::is_registered_id() >> id.proc: 1001 at ProcessorID.cc:77 >> Processor ID was completely initialized: 1001:0:0 >> system_do_svars is: 1 >> * ⎕SVQ⍳0* >> Svar_DB not connected in Svar_DB::get_offering_processors() >> 100 210 >> >> Regards. >> Elias >> >> >> >
[Bug-apl] Typos in info
1) In section 1.3, in the description of the `--` option, there's an em-dash rather than two hyphens. 2) In section 2.1.3, Example 1 the 37 (for some reason that I don't understand) displays as a header (large and bold). I've seen this on all of my installations. 3) In section 2.1.3, one of the instances of execve is misspelled as exeve. 4) Section 2.10 header should be `User-defined Command`. 5) Section 2.11.3: `... present in other APL interpreters ...` 6) I know this was discussed previously, but don't recall the resolution: Section 3.1 shows a low approximation to the integer limits. -- "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/
[Bug-apl] ]usercmd left argument
For a mode-1 ]usercmd, the left argument passed to the user function is a list of tokens. Would it be possible to pass the ravel of each token? Currently, a sequence of single-character tokens get collapsed into a single token. -- "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/
[Bug-apl] Minor build issues
1) Sometimes a make complains that aclocal- is missing. It is in fact present, but a different version. It's possible to clear this warning by doing a make distclean followed by ./configure and make. I'm not sure what triggers this; I suspect that the `missing` script doesn't get rebuilt when the tools it's checking get updated. 2) Sometimes the info top page (not the APL top, but the system top) gets corrupted and shows additional copies of the `APL` entry along with some "random" control and high-bit characters. I have no idea what triggers this. Here's an example from one of my installations. Note that the presentation may be a bit different from what I see in Emacs; GMail tries to make sense of the apparently-Unicode characters. BTW, this seems to be an Emacs-only thing; running info in a terminal does not list an entry for APL in the top page. File: dir,Node: TopThis is the top of the INFO tree This (the Directory node) gives a menu of major topics. Typing "q" exits, "?" lists all Info commands, "d" returns here, "h" gives a primer for first-timers, "mEmacs" visits the Emacs manual, etc. In Emacs, you can click mouse button 2 on a menu item or cross reference to select it. * Menu: Programming * APL: (apl). (Almost) full implementation of the "Programming Language APL, Extended" (aka. ISO 13751). * Libtool: (libtool). Generic shared library support script. * cvsclient: (cvsclient). The CVS client/server protocol. * flex: (flex). Fast lexical analyzer generator (lex replacement). * gdbm: (gdbm). The GNU Database. 2Z* APL: (apl). (Almost) full implementation of the "Programming Language APL, Extended" (aka. ISO 13751). pVppVpBp"`Z``r`P2* APL: (apl). (Almost) full implementation of the "Programming Language APL, Extended" (aka. ISO 13751). -- "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/
[Bug-apl] One more info issue
I'm not sure where it'd best be noted, but the info file makes no mention of alternatively starting a .apl file with the lamp-bang sequence. -- "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] Minor build issues
To be clear w.r.t. issue #2: It's the /usr/local/share/info/dir file that gets munged. On Tue, Jul 29, 2014 at 10:05 AM, David Lamkins wrote: > 1) Sometimes a make complains that aclocal- is missing. It is in > fact present, but a different version. It's possible to clear this warning > by doing a make distclean followed by ./configure and make. I'm not sure > what triggers this; I suspect that the `missing` script doesn't get rebuilt > when the tools it's checking get updated. > > 2) Sometimes the info top page (not the APL top, but the system top) gets > corrupted and shows additional copies of the `APL` entry along with some > "random" control and high-bit characters. I have no idea what triggers > this. Here's an example from one of my installations. Note that the > presentation may be a bit different from what I see in Emacs; GMail tries > to make sense of the apparently-Unicode characters. > > BTW, this seems to be an Emacs-only thing; running info in a terminal does > not list an entry for APL in the top page. > > File: dir,Node: TopThis is the top of the INFO tree > > This (the Directory node) gives a menu of major topics. > Typing "q" exits, "?" lists all Info commands, "d" returns here, > "h" gives a primer for first-timers, > "mEmacs" visits the Emacs manual, etc. > > In Emacs, you can click mouse button 2 on a menu item or cross reference > to select it. > > * Menu: > > Programming > * APL: (apl). (Almost) full implementation of the > "Programming Language APL, Extended" > (aka. ISO 13751). > * Libtool: (libtool). Generic shared library support script. > * cvsclient: (cvsclient). The CVS client/server protocol. > * flex: (flex). Fast lexical analyzer generator (lex > replacement). > * gdbm: (gdbm). The GNU Database. > 2Z * APL: (apl). (Almost) full implementation of the > "Programming Language APL, Extended" > (aka. ISO 13751). > p V pp V pBp"`Z ` `r `P2 * APL: (apl). (Almost) full > implementation of the > "Programming Language APL, Extended" > (aka. ISO 13751). > > > -- > "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/ > -- "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] One more info issue
Hi David, it is not mentioned because GNU APL accepts ⍝! as a library marker (and makes such libraries readable by other APL interpreters because ⍝! is just an ordinary APL comment) but such files will most likely not be understood by execve. So this is more a library convention and mentioned in the Library Guidelines document than a GNU APL feature. /// Jürgen On 07/29/2014 07:08 PM, David Lamkins wrote: I'm not sure where it'd best be noted, but the info file makes no mention of alternatively starting a .apl file with the lamp-bang sequence. -- "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] One more info issue
OK. Thanks for the pointer. On Tue, Jul 29, 2014 at 10:32 AM, Juergen Sauermann < juergen.sauerm...@t-online.de> wrote: > Hi David, > > it is not mentioned because GNU APL accepts ⍝! as a library marker (and > makes such libraries > readable by other APL interpreters because ⍝! is just an ordinary APL > comment) but such files > will most likely not be understood by execve. > > So this is more a library convention and mentioned in the Library > Guidelines document than a GNU APL feature. > > /// Jürgen > > > > On 07/29/2014 07:08 PM, David Lamkins wrote: > >> I'm not sure where it'd best be noted, but the info file makes no mention >> of alternatively starting a .apl file with the lamp-bang sequence. >> >> -- >> "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/ >> > > -- "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] Typos in info
Hi David, thanks, fixed in SVN 403. For 2) I don't know. Looks OK in my xterm when doing 'info apl'. Wrong editor? /// Jürgen On 07/29/2014 06:50 PM, David Lamkins wrote: 1) In section 1.3, in the description of the `--` option, there's an em-dash rather than two hyphens. 2) In section 2.1.3, Example 1 the 37 (for some reason that I don't understand) displays as a header (large and bold). I've seen this on all of my installations. 3) In section 2.1.3, one of the instances of execve is misspelled as exeve. 4) Section 2.10 header should be `User-defined Command`. 5) Section 2.11.3: `... present in other APL interpreters ...` 6) I know this was discussed previously, but don't recall the resolution: Section 3.1 shows a low approximation to the integer limits. -- "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/
[Bug-apl] Build error SVN 403 on OS X 10.8.5
Did a brand new checkout, ./configure, make /Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/FloatCell.cc:393:39: Call to 'pow' is ambiguous FloatCell.cc:393:39: error: call to 'pow' is ambiguous const APL_Float z = pow(A->get_real_value(), b); ^~~ extern double pow(double, double); ^ pow(double __x, int __i) ^ pow(float __x, float __y) ^ pow(long double __x, long double __y) ^ pow(float __x, int __n) ^ pow(long double __x, int __n) ^ 1 error generated. make[1]: *** [FloatCell.o] Error 1 make[1]: *** Waiting for unfinished jobs mv -f .deps/ComplexCell.Tpo .deps/ComplexCell.Po mv -f .deps/Function.Tpo .deps/Function.Po mv -f .deps/Error.Tpo .deps/Error.Po mv -f .deps/Id.Tpo .deps/Id.Po mv -f .deps/DerivedFunction.Tpo .deps/DerivedFunction.Po mv -f .deps/Executable.Tpo .deps/Executable.Po mv -f .deps/Command.Tpo .deps/Command.Po make: *** [all-recursive] Error 1
Re: [Bug-apl] Typos in info
Sorry. I forgot to mention that the rendering problem of #2 is visible when looking at the info node in Emacs. It is probably a bug somewhere in Emacs. On Tue, Jul 29, 2014 at 11:18 AM, Juergen Sauermann < juergen.sauerm...@t-online.de> wrote: > Hi David, > > thanks, fixed in SVN 403. > > For 2) I don't know. Looks OK in my xterm when doing 'info apl'. Wrong > editor? > > /// Jürgen > > > > On 07/29/2014 06:50 PM, David Lamkins wrote: > >> 1) In section 1.3, in the description of the `--` option, there's an >> em-dash rather than two hyphens. >> >> 2) In section 2.1.3, Example 1 the 37 (for some reason that I don't >> understand) displays as a header (large and bold). I've seen this on all of >> my installations. >> >> 3) In section 2.1.3, one of the instances of execve is misspelled as >> exeve. >> >> 4) Section 2.10 header should be `User-defined Command`. >> >> 5) Section 2.11.3: `... present in other APL interpreters ...` >> >> 6) I know this was discussed previously, but don't recall the resolution: >> Section 3.1 shows a low approximation to the integer limits. >> >> >> -- >> "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/ >> > > -- "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/
[Bug-apl] ANSI escapes, readline and quote-quad
Here's another unexpected (and doubtless unintended) side-effect of readline. See attached file. -- "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/ lamkins-readline-ansi-escape-bug.apl Description: Binary data
