Hi Jürgen,
yes... I had in my $HOME a directory called apl... :)
but I have a strange behavior: if I start apl (simply without any
parameters) all the errors disappear, but I have problem between
"colors" and my mac terminal app. I have black background and green
foreground (a little bit nostalgic :) ) but in this way I cannot see
the replies from the interpreter... and when I do a )off, I have to
reset the terminal because everything is black.
if I start apl --noColor I have again the SVar_DB error!!!
regards,
Fausto
2015-04-08 15:44 GMT+02:00 Juergen Sauermann <juergen.sauerm...@t-online.de>:
> Hi Fausto,
>
> correct. The convention used by GNU APL is that APserver lives in the same
> directory as apl or in the subdirectory APs of that directory. That
> directory is listed as
> APL_bin_path in the output below.
>
> In your case APL_bin_path is the current directory (also seen in argv[0]:
> 'apl' below).
>
> Therefore APserver should be present in the current directory '.' or in
> './APs/'. which probably isn't the case.
> Most likely you have a file apl in the current directory (which is first in
> your $PATH). If you remove it
> (or remove '.' from our path which most people do these days for security
> reasons) then /usr/local/.bin/apl
> and /usr/local/.bin/APserver will be used instead of ./apl.
>
> Nothing really to worry about - APserver is only for backward compatibility
> with IBM APL2 in order to provide shared variables
> and is not needed/used by most people.
>
> /// Jürgen
>
>
>
> On 04/08/2015 12:45 PM, Fausto Saporito wrote:
>
> Hello Jürgen,
>
> thanks for the hints about the configure/make.
>
> About SVar_DB , here is the output.
> I noticed the error about APserver, but it's present in /usr/local/bin
> as the apl executable.
> The problem could be he's trying to start ./APserver (and obviously)
> that file is not present in the current directory.
>
> regards,
> Fausto
>
> sizeof(Svar_record) is 328
> sizeof(Svar_partner) is 28
> increasing rlimit RLIMIT_NPROC from 709 to infinity
>
> initializing paths from argv[0] = apl
> initializing paths from $PATH =
> .:/Users/fausap/bin:/Users/fausap/Library/Haskell/bin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/3.4/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
> APL_bin_path is: .
> APL_bin_name is: apl
> Reading config file /usr/local/etc/gnu-apl.d/preferences ...
> Not reading config file /Users/fausap/.config/gnu-apl/preferences (not
> found/readable)
> Reading config file /usr/local/etc/gnu-apl.d/parallel_thresholds ...
> Not reading config file
> /Users/fausap/.config/gnu-apl/parallel_thresholds (not found/readable)
> 0 input files:
> using ANSI terminal output ESC sequences (or those configured in your
> preferences file(s))
> using ANSI terminal input ESC sequences(or those configured in your
> preferences file(s))
> Using TCP socket towards APserver...
> connecting to 127.0.0.1 TCP port 16366
> (this is expected to fail, unless APserver was started manually)
> starting a new APserver listening on 127.0.0.1 TCP port 16366
> Executable ./APserver not found (this is OK when apl was started
> from the src directory): No such file or directory
> Executable ./APs/APserver not found.
> This could means that 'apl' was not installed ('make install') or that it
> was started in a non-standard way. The expected location of APserver is
> either the same directory as the binary 'apl' or the subdirectory 'APs' of
> that directory (the directory should also be in $PATH).
> connecting to 127.0.0.1 TCP port 16366
> (this is supposed to succeed.)
> ::connect() to existing APserver failed: Invalid argument
> thread_contexts_count: 1
> busy_worker_count: 0
> active_core_count: 1
> thread # 0: 0x7fff79dbe300 pool sema: 42 RUN job: 0 no-name
>
> Parallel::set_core_count(): keeping current core count of 1
> thread_contexts_count: 1
> busy_worker_count: 0
> active_core_count: 1
> thread # 0: 0x7fff79dbe300 pool sema: 42 RUN job: 0 no-name
>
>
>
> ______ _ __ __ __ ___ ____ __
>
> / ____// | / // / / / / | / __ \ / /
>
> / / __ / |/ // / / / / /| | / /_/ // /
>
> / /_/ // /| // /_/ / / ___ | / ____// /___
>
> \____//_/ |_/ \____/ /_/ |_|/_/ /_____/
>
>
>
> Welcome to GNU APL version 1.5 / 595M
>
>
> Copyright (C) 2008-2015 Dr. Jürgen Sauermann
> Banner by FIGlet: www.figlet.org
>
>
>
> This program comes with ABSOLUTELY NO WARRANTY;
> for details run: apl --gpl.
>
>
>
> This program is free software, and you are welcome to redistribute it
> according to the GNU Public License (GPL) version 3 or later.
>
>
> PID is 16583
> argc: 3
> argv[0]: 'apl'
> argv[1]: '-l'
> argv[2]: '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
>
>
>
> 2015-04-08 12:34 GMT+02:00 Juergen Sauermann
> <juergen.sauerm...@t-online.de>:
>
> Hi Fausto,
>
> the simple ./configure (without arguments) does a "fast" install which
> assumes
> that the sources were freshly unpacked from the GNU APL project tar file.
>
> If you fetch from SVN then the fast install will not recognize changes in
> #included files.
> This can be fixed with the --enable-maintainer-mode option of ./configure.
> The normal
> way to do this is make develop after ./configure (which not only sets
> --enable-maintainer-mode
> but also other ./configure options that are useful for debugging.
>
> Regarding APserver/Svar_DB, please start apl with -l 37 and let me know what
> it says.
>
> /// Jürgen
>
>
> On 04/07/2015 07:03 PM, Fausto Saporito wrote:
>
> Hello,
>
> starting new thread, maybe it's better :)
>
> I noticed after I sent my last email that a make clean (on my system)
> doesn't clean everything. Some object files were still present.
>
> So I did a make distclean, and reconfigured everything... now I can
> confirm with clang the libemacs error is not present anymore.
>
> The Svar_DB error is still present, but maybe this could be related to
> the way I start apl... (i.e. using emacs).
>
> regards,
> fausto
>
>
>
>
