|
From: | Juergen Sauermann |
Subject: | Re: [Bug-apl] SVN 595 |
Date: | Thu, 09 Apr 2015 15:20:15 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
Hi Fausto, done in SVN 600. I thought I had given it 200 ms but it seems like it was only 20 ms. Since we all know how slow emacs is, I gave APserver 2 seconds extra when GNU APL was started in emacs mode. /// Jürgen On 04/08/2015 07:54 PM, Fausto Saporito
wrote:
Hi Jürgen, now if I run "/usr/local/bin/apl --emacs" is ok... but if I call (this is the way the emacs module gnu-apl-mode calls the interpreter) : MacMac:~ fausap$ /usr/local/bin/apl --rawCIN --emacs --emacs_arg 0 Network listener started. Connection information: mode:tcp addr:61198 ::connect() to existing APserver failed: Invalid argument ______ _ __ __ __ ___ ____ __ / ____// | / // / / / / | / __ \ / / / / __ / |/ // / / / / /| | / /_/ // / / /_/ // /| // /_/ / / ___ | / ____// /___ \____//_/ |_/ \____/ /_/ |_|/_/ /_____/ Welcome to GNU APL version 1.5 / 598M 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() maybe adding more delay could do the trick :) regards, Fausto 2015-04-08 18:17 GMT+02:00 Juergen Sauermann <address@hidden>:Hi Fausto, I see. Probably a race condition between apl and APserver (because this does not happen on my machine). I have added a delay in SVN 598. /// Jürgen On 04/08/2015 05:36 PM, Fausto Saporito wrote: 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 <address@hidden>: 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 <address@hidden>: 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 <address@hidden>: 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 <address@hidden>: 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 |
[Prev in Thread] | Current Thread | [Next in Thread] |