Re: [Bug-apl] SVN 595

[Fausto Saporito]

Hello all,

if I understood well all the logic... it seems that get_v_Quad_LX()
creates the exception.
But I cannot find where it's defined... unfortunately I don't know too much C++.

regards,
Fausto


2015-04-10 8:23 GMT+02:00 Fausto Saporito <address@hidden>:
> Another bit of scavenging :)
>
> I modified the source files Workspace.cc and SymbolTable.cc to print
> some debug info: this is the result
>
>       )load multprex
> loading )DUMP file /Users/fausap/workspaces/multprex.apl...
> WAS CLEAR WS
>       )dump
> ---> IN SYMBOLTABLE.CC <---
> Initializing dump function
> Counted symbols...
> Sorted symbols...
> Pass 1: functions... done
> Pass 2: variables... done
> ---> IN WORKSPACE.CC <---
> Dumped [multprex] on file. Now printing info...
>
> Process apl floating point exception: 8
>
> the interesting thing is the problem are the defines... or the
> inclusion... I don't know.
>
> In my modified Workspace.cc there're these lines:
>
> =========================
> int variable_count = 0;
>    the_workspace.symbol_table.dump(outf, function_count, variable_count);
>    cout << "---> IN WORKSPACE.CC <---" << endl;
>    cout << "Dumped [" << wname << "] on file. Now printing info..." << endl;
>
>    // system variables
>    //
>
> #define ro_sv_def(x, _txt)
> #define rw_sv_def(x, _txt) if (ID:: x != ID::Quad_SYL) { get_v_ ##
> x().dump(outf);   ++variable_count; }
> #include "SystemVariable.def"
>
>    cout << "Set some DEFINEs. Now printing info..." << endl;
> =========================
>
> As you can see the second COUT is never printed...
>
> 2015-04-10 7:51 GMT+02:00 Fausto Saporito <address@hidden>:
>> Just another bit of information:
>>
>> this code is never executed (from Workspace.cc), I got before this the
>> floating point exception error.
>>
>>   COUT << "DUMPED WORKSPACE '" << wname << "'" << endl
>>         << " TO FILE '" << filename << "'" << endl
>>         << " (" << function_count << " FUNCTIONS, " << variable_count
>>         << " VARIABLES)" << endl;
>>
>> regards,
>> Fausto
>>
>>
>> 2015-04-09 19:41 GMT+02:00 Fausto Saporito <address@hidden>:
>>> Hi Jürgen,
>>>
>>> I still have a problem :) but maybe it's my problematic emacs... under
>>> cocoa is very slow.
>>> I have also a latest version, but gnu-pal-mode doesn't work with emacs
>>> 25.x I don't know why... it cannot find apl :)
>>>
>>> By the way, I get a "Process apl floating point exception: 8" when i'm
>>> doing a )DUMP, I tried with clang and with gcc.
>>>
>>> The dumped file is ok... so I suppose the exception is after the
>>> process wrote on the filesystem...
>>>
>>> regards,
>>> Fausto
>>>
>>>
>>>
>>> 2015-04-09 15:20 GMT+02:00 Juergen Sauermann <address@hidden>:
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>