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
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
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 th
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 pr
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 A
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
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, th
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, ne
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 i
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."
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 t
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
h
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 doin
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
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 ordina
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
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);
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)
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-g
19 matches
Mail list logo
