V52FT001 Call-in example problem

[Sean]

Hi,

Running V52FT01 sourceforge binary installed in /opt/gtm/V52FT01.
mumps -direct works as expected.

I have compiled the call-in example on fedora core 6 as follows:

gcc -Os -Wall -c main.c -I. -I/opt/gtm/V52FT01

linked:

gcc main.o -o test1 -L/opt/gtm/V52FT01 -lgtmshr -lc

set the env var:

export GTMCI=`pwd`/calltab.ci

run:

./test1

output:

srcstr = /opt/library/V43001E
$piece(/opt/library/V43001E,"/",4) is V43001E
After set $piece(srcstr,"/",4) = V44002
srcstr = /opt/library/V44002

then I get back to a command prompt in the gnome terminal session, but the terminal session is corrupt.  If I hit enter everything shows up on a single line and I can't type anything else in that terminal.  I can reset it, but the only thing that works is to close that session and start a new one.

[stuffduff@dhcppc1 ~]$ cd Desktop/GT.M-python/
[stuffduff@dhcppc1 GT.M-python]$ export GTMCI=`pwd`/calltab.ci
[stuffduff@dhcppc1 GT.M-python]$ ./test1
srcstr = /opt/library/V43001E
$piece(/opt/library/V43001E,"/",4) is V43001E
After set $piece(srcstr,"/",4) = V44002
srcstr = /opt/library/V44002
[stuffduff@dhcppc1 GT.M-python]$ [stuffduff@dhcppc1 GT.M-python]$ [stuffduff@dhcppc1 GT.M-python]$ [stuffduff@dhcppc1 GT.M-python]$ [stuffduff@dhcppc1 GT.M-python]$ [stuffduff@dhcppc1 GT.M-python]$ [stuffduff@dhcppc1 GT.M-python]$ [stuffduff@dhcppc1 GT.M-python]$ [stuffduff@dhcppc1 GT.M-python]$

So I made a simplified version:

#include <stdio.h>
#include "gtmxc_types.h"
#define BUF_LEN 1024
int main()
{
  gtm_char_t       msgbuf[BUF_LEN], dststr[100];
  gtm_char_t       srcstr[] = "/opt/library/V43001E";
  gtm_status_t     status;

  printf("srcstr = %s\n", srcstr);

  return 0;
}

Which I compiled and ran.  The output was as expected and the terminal window continued to function normally.  So I added back the init & exit w/o any other calls:

#include <stdio.h>
#include "gtmxc_types.h"
#define BUF_LEN 1024
int main()
{
  gtm_char_t       msgbuf[BUF_LEN], dststr[100];
  gtm_char_t       srcstr[] = "/opt/library/V43001E";
  gtm_status_t     status;

  status = gtm_init();
  if (status != 0)
  {
          gtm_zstatus(msgbuf, BUF_LEN);
          return status;
  }

  printf("srcstr = %s\n", srcstr);

  status = gtm_exit();
  if (status != 0)
  {
          gtm_zstatus(msgbuf, BUF_LEN);
          fprintf(stderr, "%s\n", msgbuf);
          return status;
  }

  return 0;
}

This time I reproduced the error as before.

So I believe that somewhere in the interaction with the call-in interface some extra control characters are getting generated and causing the problem.  Since there is no indication of an OPEN or USE command in the m example, thinking that the call-in functionality works by calling the 'm' functionality by it's underlying 'C' code interface.  So at this point I'm not really sure how to go about debugging this.

Would building GT.M on my platform be the way to address this problem?

Any suggestions sincerely appreciated,

Sean

[Steven Estes]

Sean,

This is a known GTM issue (recently discovered). We are having some discussions about the best way to fix it and plan to fix it in a future release.

The issue is that during initialization (in gtm_startup specifically) we make a call to the io initialization routine which saves the attributes of the current terminal session and sets them the way GTM likes. The problem is that during the callin "gtm_exit()" call, the io rundown for terminals is specifically avoided so the terminal is not set back the way it was. One of the changed settings is character echo so nothing appears.

Rebuilding GTM on your system won't help the situation. A bug fix must be made. If you are not using a terminal for the code in question (likea job'd off routine or something) then the issue does not show..

Sorry for the inconvenience..

Steve

[Steven Estes]

Sean,

Just to be clear, if your callin routines that are calling gtm_init() and gtm_exit() would save the terminal characteristics prior to the gtm_init() call (see setterm.c for what is saved/changed) and restore the terminal characteristics just after calling gtm_exit() (see resetterm.c for how restored), you can work around this problem..

Steve

[Sean]

Steve,

Thanks.  It's more an annoyance than anything else,  but it will probably save me some debugging time so I'll see about adding it to my wrapper.

Sean

[Sean]

It's really more like 'a twisty maze of passeges all alike' in there.  I can't seem to build the io_std_device.in to pass to either setterm or resetterm without going through io_init to initialize it.

  io_init(1);
  setterm(io_std_device.in);
  status = gtm_init();

The above won't compile without a definition to correct this error: ‘io_init_ch’ undeclared but I can't seem to find it anywhere.  Without a correctly built & initialized io_std_device I'm just generating a segfault in setterm at tt_ptr = (d_tt_struct *) ioptr->dev_sp;.

But even if that works, if io_init is where the terminal settings are munged, and it's what builds a valid io_std_device then I'm still looking for a paddle.

[Sean]

Came up with something else interesting.  Got some code that set & reset the terminal and it too also failed.  New strategy came out something like this:

reset_input_mode (void)
{
  tcsetattr (STDIN_FILENO, TCSANOW, &saved_attributes);
}

int main
{
  ...

  if (!isatty (STDIN_FILENO))
  {
    fprintf (stderr, "Not a terminal.\n");
    exit (EXIT_FAILURE);
  }
 
  tcgetattr (STDIN_FILENO, &saved_attributes);
  atexit ((void(*)())reset_input_mode);

  status = gtm_init();
  if (status != 0)
  {
          gtm_zstatus(msgbuf, BUF_LEN);
          return status;
  }
  ...

}

This worked.  By using atexit, my reset call got placed on the stack prior to any settings caused by the init call.  When the program terminated, the atexit was called after the last GTM call that was on the stack.