Re: [Bug-apl] Minor build issues
Hi David, thanks. I have simplified the info directory entry for GNU APL a little. Maybe they don't like quotes in the entry. SVN 405. I have added ACLOCAL_AMFLAGS = -I m4 to the top-level Makefile.am Not sure if that fixes the aclocal problem; if not then I need more information (actual printouts) so that I can google the problem. It could also be that if there are (autoconf/make-) generated files in your directory, and you update from SVN, that autoconf incorrectly believes that some files need to be rebuilt. Because SVN does not (and cannot) maintain time relations. As far as I understand, a normal build should not need aclocal to run at all. /// Jürgen On 07/29/2014 07:05 PM, 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). 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/
Re: [Bug-apl] Build error SVN 403 on OS X 10.8.5
Hi Peter, thanks, fixed in SVN 405. /// Jürgen On 07/29/2014 08:49 PM, Peter Teeson wrote: 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] ANSI escapes, readline and quote-quad
Hi David, thanks. readline is unpredictable at times. It looks like they intercept the output, discarding 27 91 55 and leaving only the final 109 (*m* in ASCII). My plan is to remove readline completely, but this is a bigger thing to do so it won't be in the 1.4 release. /// Jürgen On 07/30/2014 08:41 AM, David Lamkins wrote: 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/
Re: [Bug-apl] ]usercmd left argument
Hi David, yes. Done in SVN 406. /// Jürgen On 07/29/2014 06:53 PM, David Lamkins wrote: 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/
Re: [Bug-apl] Subtle parsing problem
Hi Elias,
what you propose is i actually exactly what happens under the hood.
When you enter {⍵} 1 then {⍵} triggers the creation of a function λ1:
Z←λ1 ⍵
Z←⍵
and the original {⍵} 1 is being replaced by λ1 1.
The "problem" with niladic functions below is not at all related to
lambdas but demanded
by the right to left evaluation in APL. Since niladic functions have no
argument the are evaluated
as soon as the run-time parser sees them. Thats why your right lambda is
evaluated before the SEL operator,
The reason why the left lambda is evaluated after the SEL is because the
phrase containing it, i.e. {...} SEL B
is longer than the niladic lambda {...} alone.
The same would have happened if you had used defined functions or
primitive functions instead of lambdas.
So your dream may have come true - except that it maybe turned out to be
a nightmare?
/// Jürgen
On 07/29/2014 03:17 PM, Elias Mårtenson wrote:
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"
mailto:juergen.sauerm...@t-online.de>>
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
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] Subtle parsing problem
OK, first of all, none of what follows are actually proposals or anything
like that. They merely describe how I would have designed the language to
make lambda functions behave more like they do in Lisp. It all comes down
to having a concept that is referred to as "first class functions" in
functional programming. The idea is that functions can be treated as any
other type of value. They can be passed along to other functions, etc.
First, an assignment:
foo ← {⍵+1} {⍵+2}
foo now contains an array containing two functions.
Let's look at what foo contains:
foo
# #
Here, # is used to represent a function. Note that Lambdas are scalar
values.
bar ← foo[1]
bar now contains the function {⍵+1}. Note that since functions are scalar
values, bar would be seen in the output of )VARS and not )FNS.
Obviously, in this hypothetical variant of APL, you need a way to call a
function that is a scalar value. This is similar to how you use FUNCALL or
APPLY in Lisp to do this. Let's just re-use lamp for this:
(⍎bar)10
11
In Lisp there is also a way to bind the "function slot" of a symbol to a
lambda so that is behaves like a normal function.
Now, I can think of a few ways how proper first-class functions can be
retrofitted in APL (involving some symbol that can be used to refer to a
function as a first-class value. I.e. instead of using a symbol to force
evaluation of a function, you'd do the opposite; have a symbol force the
treatment of a function as a first-class value).
This is a discussion best reserved for another day though. :-)
Regards,
Elias
On 30 July 2014 21:43, Juergen Sauermann
wrote:
> Hi Elias,
>
> what you propose is i actually exactly what happens under the hood.
> When you enter {⍵} 1 then {⍵} triggers the creation of a function λ1:
>
> Z←λ1 ⍵
> Z←⍵
>
> and the original {⍵} 1 is being replaced by λ1 1.
>
> The "problem" with niladic functions below is not at all related to
> lambdas but demanded
> by the right to left evaluation in APL. Since niladic functions have no
> argument the are evaluated
> as soon as the run-time parser sees them. Thats why your right lambda is
> evaluated before the SEL operator,
> The reason why the left lambda is evaluated after the SEL is because the
> phrase containing it, i.e. {...} SEL B
> is longer than the niladic lambda {...} alone.
>
> The same would have happened if you had used defined functions or
> primitive functions instead of lambdas.
>
> So your dream may have come true - except that it maybe turned out to be a
> nightmare?
>
> /// Jürgen
>
>
>
> On 07/29/2014 03:17 PM, Elias Mårtenson wrote:
>
> 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)/d
Re: [Bug-apl] ]usercmd left argument
Thank you. On Wed, Jul 30, 2014 at 6:18 AM, Juergen Sauermann < juergen.sauerm...@t-online.de> wrote: > Hi David, > > yes. Done in SVN 406. > > /// Jürgen > > > > On 07/29/2014 06:53 PM, David Lamkins wrote: > >> 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/ >> > > -- "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
Hi again, I believe I have found a solution for the sporadic aclocal etc. stuff. I activated the maintainer-mode option of ./configure and check files into SVN after ./configure --disable-maintainer-mode. That is supposed to prevent rebuilding files with autoconf/automake. I also added a top-level make target SVNUP that does this (see top-level 'make help'). /// Jürgen On 07/30/2014 02:22 PM, Juergen Sauermann wrote: Hi David, thanks. I have simplified the info directory entry for GNU APL a little. Maybe they don't like quotes in the entry. SVN 405. I have added ACLOCAL_AMFLAGS = -I m4 to the top-level Makefile.am Not sure if that fixes the aclocal problem; if not then I need more information (actual printouts) so that I can google the problem. It could also be that if there are (autoconf/make-) generated files in your directory, and you update from SVN, that autoconf incorrectly believes that some files need to be rebuilt. Because SVN does not (and cannot) maintain time relations. As far as I understand, a normal build should not need aclocal to run at all. /// Jürgen On 07/29/2014 07:05 PM, 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). 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] Component FIle Systems
Hi, I have added David's and Blake's Component File Systems. Thank you very much for contributing them! Please check if the files are OK (two folders below wslib5). From my side everything is ready for GNU APL 1.4 now - I will build the release package shortly if nobody objects. /// Jürgen
[Bug-apl] Strange T∆ output... OS X 10.8.5
I launched apl --noColor --silent Version / SVN: 1.3 / 7603 When I trace this line: i←(2|j)/j←⍳×/k←⍴Y it produces this display Please display the tiff because when I copy/paste mail shows this 13579111315 which is not what I see on the Terminal. but it should display this value for i adj[5] 1 3 5 7 9 11 13 15 What could be happening? Thanks Peter
Re: [Bug-apl] Remaining APserver issues
I've checked, and here are the results. I noticed that sometimes the APserver gets killed when I )OFF the interpreter, and sometimes it doesn't. $ *dist/bin/apl --silent -l 37* 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 22704 argc: 4 argv[0]: 'dist/bin/apl' argv[1]: '--silent' argv[2]: '-l' argv[3]: '37' 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 Then, I check for listeners from another terminal: $ *netstat -an | grep 16366* tcp0 0 127.0.0.1:16366 0.0.0.0:* LISTEN $ *ps -ef | grep AP* emarten+ 22712 1 0 10:34 pts/300:00:00 ./dist/bin/APserver --port 16366 emarten+ 22733 28324 0 10:36 pts/100:00:00 grep AP I then quit the APL session: *)off* And then check connections again: $ *ps -ef | grep AP* emarten+ 22712 1 0 10:34 pts/300:00:00 ./dist/bin/APserver --port 16366 emarten+ 22750 28324 0 10:38 pts/100:00:00 grep AP em-desktop$ *netstat -an | grep 16366* tcp0 0 127.0.0.1:16366 0.0.0.0:* LISTEN As we can see, the APserver is still listening. I now try to start the APL interpreter again, and it properly connects to the *old* APserver: $ *dist/bin/apl --silent -l 37* 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... connected to APserver, socket is 3 using Svar_DB on APserver! PID is 22768 argc: 4 argv[0]: 'dist/bin/apl' argv[1]: '--silent' argv[2]: '-l' argv[3]: '37' uprefs.user_do_svars: 1 uprefs.system_do_svars: 1 uprefs.requested_id:0 uprefs.requested_par: 0 id.proc: 1001 at ProcessorID.cc:77 Processor ID was completely initialized: 1001:0:0 system_do_svars is: 1 We can see that it's actually connected by checking the APserver status again: $ *netstat -an | grep 16366* tcp0 0 127.0.0.1:16366 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:44102 127.0.0.1:16366 ESTABLISHED tcp0 0 127.0.0.1:16366 127.0.0.1:44102 ESTABLISHED em-desktop$ *ps -ef | grep AP* emarten+ 22712 1 0 10:34 pts/300:00:00 ./dist/bin/APserver --port 16366 emarten+ 22782 28324 0 10:40 pts/100:00:00 grep AP Now, let's )OFF the interpreter which promptly kills the APserver that was originally started in the first invocation of apl: $ *netstat -an | grep 16366* tcp0 0 127.0.0.1:44102 127.0.0.1:16366 TIME_WAIT em-desktop$ *ps -ef | grep AP* emarten+ 22790 28324 0 10:41 pts/100:00:00 grep AP Regards, Elias On 29 July 2014 21:17, Elias Mårtenson wrote: > 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 net
