Hi
just to clarify with example:
MacMac:~ fausap$ /usr/local/bin/apl --noColor
______ _ __ __ __ ___ ____ __
/ ____// | / // / / / / | / __ \ / /
/ / __ / |/ // / / / / /| | / /_/ // /
/ /_/ // /| // /_/ / / ___ | / ____// /___
\____//_/ |_/ \____/ /_/ |_|/_/ /_____/
Welcome to GNU APL version 1.5 / 597M
Copyright (C) 2008-2015 Dr. Jürgen Sauermann
Banner by FIGlet: www.figlet.org
This program comes with ABSOLUTELY NO WARRANTY;
for details run: /usr/local/bin/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.
)off
Goodbye.
and now the error :
MacMac:~ fausap$ /usr/local/bin/apl --emacs
::connect() to existing APserver failed: Invalid argument
______ _ __ __ __ ___ ____ __
/ ____// | / // / / / / | / __ \ / /
/ / __ / |/ // / / / / /| | / /_/ // /
/ /_/ // /| // /_/ / / ___ | / ____// /___
\____//_/ |_/ \____/ /_/ |_|/_/ /_____/
Welcome to GNU APL version 1.5 / 597M
Copyright (C) 2008-2015 Dr. Jürgen Sauermann
Banner by FIGlet: www.figlet.org
This program comes with ABSOLUTELY NO WARRANTY;
for details run: /usr/local/bin/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.
Svar_DB not connected in Svar_DB::is_registered_id()
)off
Goodbye.
regards,
Fausto
2015-04-08 17:28 GMT+02:00 Fausto Saporito <fausto.sapor...@gmail.com>:
> Hi Jürgen,
>
> ok. for some reason if I run "/usr/local/bin/apl --noColor" I have no
> error, if I run "apl --noColor" without the full path I got the error.
> But without any switch (--noColor or --emacs) it's ok even if I run
> apl or /usr/local/bin/apl
>
> Really I cannot understand this.
>
> regards,
> Fausto
>
>
> 2015-04-08 17:11 GMT+02:00 Juergen Sauermann <juergen.sauerm...@t-online.de>:
>> Hi Fausto,
>>
>> you can set different colors in the GNU APL preferences file(s), e.g.
>> /usr/local/etc/gnu-apl.d/preferences.
>> There is a section for screens with dark backgrounds (commented out). There
>> is no reliable way to figure
>> which colors are used when apl is started. Therefore apl sends the "RESET"
>> sequence in the preferences file
>> when it exits.
>>
>> The --noColor option is not related to APserver. You may want to try an
>> absolute path to the apl binary to
>> be sure which one is being used.
>>
>> /// Jürgen
>>
>>
>> On 04/08/2015 04:04 PM, Fausto Saporito wrote:
>>
>> 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
>>
>>
>>
>>
>>
