From icrazy at gmail.com  Wed Sep  3 11:11:54 2008
From: icrazy at gmail.com (Kuang He)
Date: Wed, 3 Sep 2008 14:11:54 -0400
Subject: [sac-dev] A possible way to fix "WARNING: Number 4003 integer
	too large"
In-Reply-To: <D52FB74B-B45B-42B2-8270-C57E4DEF63E8@uri.edu>
References: <fd0f51b90808280948l30ec5df4t815f66f0bdc2eacf@mail.gmail.com>
	<D52FB74B-B45B-42B2-8270-C57E4DEF63E8@uri.edu>
Message-ID: <fd0f51b90809031111p66bc5756k4b67d939f0fa8e65@mail.gmail.com>

On Thu, Aug 28, 2008 at 1:01 PM, Brian Savage <savage at uri.edu> wrote:
> You are correct in that this routine contains a bug and
> you are again correct that it will be changed to use the strtol() routine
> in future releases.  I have routines ready to replace this one and the
> one in cnvatf.c as well.  This is major change to the code as it is heavily
> used and the ramifications of changing it need to be dealt with properly.

Dear Brian,

When we are on this point, how is the status of the testing suite? I
saw this in the History file of the source code.

Is it still just an idea, or is it already a work in progress? How can
can we contribute to that? If we had a unit testing suite already, it
would be a lot safer to refactor the code.

Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

> Thanks for your interest. If you have other suggestions or code/bug fixes we
> would be glad hear them.
>
> Cheers
> Brian
>
> On Aug 28, 2008, at  12:48 PM , Kuang He wrote:
>> I met this "WARNING: Number 4003 integer too large" when I tried to
>> multiply my data by a factor of 10^9, and found in the changelog that
>> it is a known bug.
>>
>> [...]
>> In my opinion, instead of using magic numbers 1000000000 and 100000
>> above, it might be better to use strtol() to convert strings to
>> longints. strtol() can also show if the resulting value is out of
>> range (using errno ERANGE). Based on the linux manpage of strtol()
>> I've been reading, this function conforms to SVr4, 4.3BSD, C89, C99
>> and POSIX.1-2001, so there should be no portability problems of using
>> this at all .
>> --
>> Kuang He

From savage at uri.edu  Wed Sep  3 12:11:08 2008
From: savage at uri.edu (Brian Savage)
Date: Wed, 3 Sep 2008 15:11:08 -0400
Subject: [sac-dev] A possible way to fix "WARNING: Number 4003 integer
	too large"
In-Reply-To: <fd0f51b90809031111p66bc5756k4b67d939f0fa8e65@mail.gmail.com>
References: <fd0f51b90808280948l30ec5df4t815f66f0bdc2eacf@mail.gmail.com>
	<D52FB74B-B45B-42B2-8270-C57E4DEF63E8@uri.edu>
	<fd0f51b90809031111p66bc5756k4b67d939f0fa8e65@mail.gmail.com>
Message-ID: <639A1019-A348-4F1D-B4C2-9DF149ED57ED@uri.edu>

Kuang He,

A testing suite is currently only residing on my system.
I have used it minimally to test the output of certain commands, but  
it would be nice to have a better or standard way
to create and test the system before it is released.  This is  
especially true for the sacio and sac libraries.  As well as the  
sacswap program, thank you very much by the way.

I can see a testing suite as two different beasts.  One version might  
be an interface to SAC itself and the other would be to specific  
functions within SAC.  A macro vs micro approach.  Keep in mind that  
the tests need to be run on Linux, OSX and Solaris.  Solaris is the  
trouble one in the group.  My feelings are that a micro approach to  
the functions would be easier to implement and allow us finer grain  
control on how they behave.

If you would like to give your input, it would be most helpful.

Cheers
Brian




On Sep 3, 2008, at  2:11 PM , Kuang He wrote:

> On Thu, Aug 28, 2008 at 1:01 PM, Brian Savage <savage at uri.edu> wrote:
>> You are correct in that this routine contains a bug and
>> you are again correct that it will be changed to use the strtol()  
>> routine
>> in future releases.  I have routines ready to replace this one and  
>> the
>> one in cnvatf.c as well.  This is major change to the code as it  
>> is heavily
>> used and the ramifications of changing it need to be dealt with  
>> properly.
>
> Dear Brian,
>
> When we are on this point, how is the status of the testing suite? I
> saw this in the History file of the source code.
>
> Is it still just an idea, or is it already a work in progress? How can
> can we contribute to that? If we had a unit testing suite already, it
> would be a lot safer to refactor the code.
>
> Best regards,
>
> -- 
> Kuang He
> Department of Physics
> University of Connecticut
> Storrs, CT 06269-3046
>
> Tel: +1.860.486.4919
> Web: http://www.phys.uconn.edu/~he/
>
>> Thanks for your interest. If you have other suggestions or code/ 
>> bug fixes we
>> would be glad hear them.
>>
>> Cheers
>> Brian
>>
>> On Aug 28, 2008, at  12:48 PM , Kuang He wrote:
>>> I met this "WARNING: Number 4003 integer too large" when I tried to
>>> multiply my data by a factor of 10^9, and found in the changelog  
>>> that
>>> it is a known bug.
>>>
>>> [...]
>>> In my opinion, instead of using magic numbers 1000000000 and 100000
>>> above, it might be better to use strtol() to convert strings to
>>> longints. strtol() can also show if the resulting value is out of
>>> range (using errno ERANGE). Based on the linux manpage of strtol()
>>> I've been reading, this function conforms to SVr4, 4.3BSD, C89, C99
>>> and POSIX.1-2001, so there should be no portability problems of  
>>> using
>>> this at all .
>>> --
>>> Kuang He
> _______________________________________________
> sac-dev mailing list
> sac-dev at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/sac-dev


From icrazy at gmail.com  Wed Sep  3 17:38:20 2008
From: icrazy at gmail.com (Kuang He)
Date: Wed, 3 Sep 2008 20:38:20 -0400
Subject: [sac-dev] SAC testing suite (was: Re: A possible way to fix
	"WARNING: Number 4003 integer too large")
Message-ID: <fd0f51b90809031738g2117458dyc6d442c0c6ce3b7d@mail.gmail.com>

Dear Brian,

Probably folks here have much more experience on building testing
suites than I do, but since you ask, I'll share my two cents.

If I understand you correctly, the idea of the macro approach you
mentioned is to create something using Expect
(http://expect.nist.gov/) to interact with SAC as if a human being is
operating on it, or more simply just to write shell scripts to feed
commands to SAC using *nix pipes. This is obviously doable, but I
agree with you that it does not offer a fine-grained control on all
the functions we want to test, and could be more difficult to
implement (using Expect surly will make things even more complicated).

Many open source software packages already have testing suites which
come with their source codes. I think they cannot afford not having
one, since a lot of them are still under active development. Humans
are not perfect, so no matter how careful we are, we are prone to
introduce new bugs when trying to develop new features, fix old bugs,
etc. I've looked at Perl's testing suite before, and it is in a
directory called t in its source code. I put one of files here as an
example, so that people can get a feeling how they look:

http://maxwell.phys.uconn.edu/~icrazy/sac/num.pl.txt

For example, we can generate a seismogram and perform FFT on it using
a FFT implementation that is known to work well, then put the original
values and the spectrum we get after doing FFT into the FFT part of
the testing suite. Each time we run the testing suite, it will try to
get a spectrum out of the same dataset we provide using the FFT
function in SAC and then compare the result with the known result. If
these two sets of results are the same (due to floating number
precisions, we consider they are the same as long as they differ very
little), the suite will print something like "FFT ok", otherwise "FFT
not ok". Similarly, we can write similar testing functions for other
functions in SAC. It is gonna take quite some time to implement the
testing suite, but I think it is well worth it.

By the way, how come "Solaris is the trouble one in the group"? What
is wrong with Solaris? (I don't use Solaris.)

As a related note, I was wondering how we are doing building tests on
different systems, since SAC needs to support Linux, OSX and Solaris.
There is a tool called Buildbot (http://buildbot.net/trac), which will
automatically rebuild and test the source code tree on all the
available systems each time something has changed (e.g. a programmer
commits a change to the CVS system), so that build problems will be
pinpointed quickly. Users of Buildbot include famous open source
projects such as KDE, Python, Zope, OpenOffice, etc. For example, this
is the one of the Buildbot summary pages for Python, just to give you
a visualization.

http://www.python.org/dev/buildbot/stable/

Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

On Wed, Sep 3, 2008 at 3:11 PM, Brian Savage <savage at uri.edu> wrote:
> A testing suite is currently only residing on my system.
> I have used it minimally to test the output of certain commands, but it
> would be nice to have a better or standard way
> to create and test the system before it is released.  This is especially
> true for the sacio and sac libraries.  As well as the sacswap program, thank
> you very much by the way.
>
> I can see a testing suite as two different beasts.  One version might be an
> interface to SAC itself and the other would be to specific functions within
> SAC.  A macro vs micro approach.  Keep in mind that the tests need to be run
> on Linux, OSX and Solaris.  Solaris is the trouble one in the group.  My
> feelings are that a micro approach to the functions would be easier to
> implement and allow us finer grain control on how they behave.
>
> If you would like to give your input, it would be most helpful.

From icrazy at gmail.com  Fri Sep  5 23:06:16 2008
From: icrazy at gmail.com (Kuang He)
Date: Sat, 6 Sep 2008 02:06:16 -0400
Subject: [sac-dev] Bugs found
Message-ID: <fd0f51b90809052306t12f0f733q88159bcdcd840439@mail.gmail.com>

Hi,

I'm using SAC v101.1 on a linux box (Ubuntu 8.04), and the glibc
version is 2.7 (2.7-10ubuntu3, to be exact).

$ uname -a
Linux ....... 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008
i686 GNU/Linux

Bug 1: Trying to use Ctrl+D to quit SAC instead of using the command
`quit' will always cause a segmentation fault.

$ sac
SAC> [Press CTRL+D]
Segmentation fault

Bug 2: Putting a space after the comma in something like "&1,DIST"
will _sometimes_ cause SAC to suddenly abort, with a message from
glibc indicating possible double free. Below is an example of a case
where this problem does not show up and another case where the problem
does show up.

$ sac
SAC> r vel.sac
SAC> evaluate to dist &1,dist
SAC> evaluate to dist &1, dist
 ERROR interpreting command:  evaluate to dist '           dist
 ILLEGAL OPTION:

$ sac
SAC> r vel.sac
SAC> evaluate to dist1 &1,dist
SAC> message %dist1
 2.84897$
SAC> evaluate to dist1 &1, dist
*** glibc detected *** /usr/local/sac/bin/sac: double free or
corruption (!prev): 0x0843f020 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7c9ba85]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7c9f4f0]
/usr/local/sac/bin/sac[0x805d749]
/usr/local/sac/bin/sac[0x80c81fe]
/usr/local/sac/bin/sac[0x804e60f]
/usr/local/sac/bin/sac[0x804b991]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7c46450]
/usr/local/sac/bin/sac[0x804b5b1]
======= Memory map: ========
08048000-08197000 r-xp 00000000 08:01 1309634    /usr/local/sac/bin/sac
08197000-0819d000 rw-p 0014e000 08:01 1309634    /usr/local/sac/bin/sac
0819d000-08443000 rw-p 0819d000 00:00 0          [heap]
b7a00000-b7a21000 rw-p b7a00000 00:00 0
b7a21000-b7b00000 ---p b7a21000 00:00 0
b7c0c000-b7c0d000 rw-p b7c0c000 00:00 0
b7c0d000-b7c11000 r-xp 00000000 08:01 671763     /usr/lib/libXdmcp.so.6.0.0
b7c11000-b7c12000 rw-p 00003000 08:01 671763     /usr/lib/libXdmcp.so.6.0.0
b7c12000-b7c14000 r-xp 00000000 08:01 671752     /usr/lib/libXau.so.6.0.0
b7c14000-b7c15000 rw-p 00001000 08:01 671752     /usr/lib/libXau.so.6.0.0
b7c15000-b7c2c000 r-xp 00000000 08:01 671564     /usr/lib/libxcb.so.1.0.0
b7c2c000-b7c2d000 rw-p 00016000 08:01 671564     /usr/lib/libxcb.so.1.0.0
b7c2d000-b7c2e000 r-xp 00000000 08:01 671723     /usr/lib/libxcb-xlib.so.0.0.0
b7c2e000-b7c2f000 rw-p 00000000 08:01 671723     /usr/lib/libxcb-xlib.so.0.0.0
b7c2f000-b7c30000 rw-p b7c2f000 00:00 0
b7c30000-b7d79000 r-xp 00000000 08:01 2812605    /lib/tls/i686/cmov/libc-2.7.so
b7d79000-b7d7a000 r--p 00149000 08:01 2812605    /lib/tls/i686/cmov/libc-2.7.so
b7d7a000-b7d7c000 rw-p 0014a000 08:01 2812605    /lib/tls/i686/cmov/libc-2.7.so
b7d7c000-b7d7f000 rw-p b7d7c000 00:00 0
b7d7f000-b7dac000 r-xp 00000000 08:01 2779973    /lib/libncurses.so.5.6
b7dac000-b7daf000 rw-p 0002c000 08:01 2779973    /lib/libncurses.so.5.6
b7daf000-b7dd2000 r-xp 00000000 08:01 2812613    /lib/tls/i686/cmov/libm-2.7.so
b7dd2000-b7dd4000 rw-p 00023000 08:01 2812613    /lib/tls/i686/cmov/libm-2.7.so
b7dd4000-b7dd6000 r-xp 00000000 08:01 2812611    /lib/tls/i686/cmov/libdl-2.7.so
b7dd6000-b7dd8000 rw-p 00001000 08:01 2812611    /lib/tls/i686/cmov/libdl-2.7.so
b7ddb000-b7de5000 r-xp 00000000 08:01 2779880    /lib/libgcc_s.so.1
b7de5000-b7de6000 rw-p 0000a000 08:01 2779880    /lib/libgcc_s.so.1
b7de6000-b7de8000 rw-p b7de6000 00:00 0
b7de8000-b7ecc000 r-xp 00000000 08:01 672597     /usr/lib/libX11.so.6.2.0
b7ecc000-b7ecf000 rw-p 000e4000 08:01 672597     /usr/lib/libX11.so.6.2.0
b7ecf000-b7ed0000 rw-p b7ecf000 00:00 0
b7ed0000-b7ee5000 r-xp 00000000 08:01 670455     /usr/lib/libICE.so.6.3.0
b7ee5000-b7ee6000 rw-p 00014000 08:01 670455     /usr/lib/libICE.so.6.3.0
b7ee6000-b7ee8000 rw-p b7ee6000 00:00 0
b7ee8000-b7eef000 r-xp 00000000 08:01 671742     /usr/lib/libSM.so.6.0.0
b7eef000-b7ef0000 rw-p 00006000 08:01 671742     /usr/lib/libSM.so.6.0.0
b7ef0000-b7ef2000 rw-p b7ef0000 00:00 0
b7ef2000-b7ef3000 r-xp b7ef2000 00:00 0          [vdso]
b7ef3000-b7f0d000 r-xp 00000000 08:01 2779919    /lib/ld-2.7.so
b7f0d000-b7f0f000 rw-p 00019000 08:01 2779919    /lib/ld-2.7.so
bf86b000-bf880000 rw-p bffeb000 00:00 0          [stack]
Aborted

The file vel.sac used above can be found at:

http://maxwell.phys.uconn.edu/~icrazy/sac/vel.sac


Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

From icrazy at gmail.com  Fri Sep  5 23:22:34 2008
From: icrazy at gmail.com (Kuang He)
Date: Sat, 6 Sep 2008 02:22:34 -0400
Subject: [sac-dev] Bugs found
In-Reply-To: <fd0f51b90809052306t12f0f733q88159bcdcd840439@mail.gmail.com>
References: <fd0f51b90809052306t12f0f733q88159bcdcd840439@mail.gmail.com>
Message-ID: <fd0f51b90809052322o846a0c8kd890ee3e274b2b87@mail.gmail.com>

On Sat, Sep 6, 2008 at 2:06 AM, Kuang He <icrazy at gmail.com> wrote:
> [...]
> Bug 2: Putting a space after the comma in something like "&1,DIST"
> will _sometimes_ cause SAC to suddenly abort, with a message from
> glibc indicating possible double free. Below is an example of a case
> where this problem does not show up and another case where the problem
> does show up.
>
> $ sac
> SAC> r vel.sac
> SAC> evaluate to dist &1,dist
> SAC> evaluate to dist &1, dist
>  ERROR interpreting command:  evaluate to dist '           dist
>  ILLEGAL OPTION:
>
> $ sac
> SAC> r vel.sac
> SAC> evaluate to dist1 &1,dist
> SAC> message %dist1
>  2.84897$
> SAC> evaluate to dist1 &1, dist
> *** glibc detected *** /usr/local/sac/bin/sac: double free or
> corruption (!prev): 0x0843f020 ***
> ======= Backtrace: =========
> /lib/tls/i686/cmov/libc.so.6[0xb7c9ba85]
> [...]

I googled on this error message, and someone suggested using

$ export MALLOC_CHECK_=0

before running SAC. The above environment variable setting will ask
glibc to ignore the multi free() to particular memory, which seemed to
have solved the problem for now, but still, it is possible that this
problem is due to a coding error.

Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

From icrazy at gmail.com  Fri Sep  5 23:43:33 2008
From: icrazy at gmail.com (Kuang He)
Date: Sat, 6 Sep 2008 02:43:33 -0400
Subject: [sac-dev] Feature proposal -- saving command history to a disk file
	for later use
Message-ID: <fd0f51b90809052343k72012585s894a85d9a9a720da@mail.gmail.com>

Dear SAC users and devs,

There is a useful feature in softwares like bash, which can save
command history to a disk file and load it the next time they run. In
this way, people can use hotkeys like Up Arrow, Down Arrow, Alt+P,
Alt+N, etc. to access the commands they've used not only in the
current session but also in the previous sessions. I hope that SAC can
have the same feature so as to make our lives a bit easier.

The feature should not be difficult to implement, and if people
(hopefully both users and devs) think it is desirable, I'll start to
do it. :-)

Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

From icrazy at gmail.com  Sun Sep  7 20:34:03 2008
From: icrazy at gmail.com (Kuang He)
Date: Sun, 7 Sep 2008 23:34:03 -0400
Subject: [sac-dev] Bugs found
In-Reply-To: <fd0f51b90809052306t12f0f733q88159bcdcd840439@mail.gmail.com>
References: <fd0f51b90809052306t12f0f733q88159bcdcd840439@mail.gmail.com>
Message-ID: <fd0f51b90809072034t6a209a9bw988925315eccb4a@mail.gmail.com>

On Sat, Sep 6, 2008 at 2:06 AM, Kuang He <icrazy at gmail.com> wrote:
> I'm using SAC v101.1 on a linux box (Ubuntu 8.04), and the glibc
> version is 2.7 (2.7-10ubuntu3, to be exact).
>
> $ uname -a
> Linux ....... 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008
> i686 GNU/Linux
>
> Bug 1: Trying to use Ctrl+D to quit SAC instead of using the command
> `quit' will always cause a segmentation fault.
>
> $ sac
> SAC> [Press CTRL+D]
> Segmentation fault

Here is a quick fix to Bug 1 (based on SAC v101.1):

$ diff -u src/co/zgpmsg.c.old src/co/zgpmsg.c
--- src/co/zgpmsg.c.old 2008-09-07 23:18:09.000000000 -0400
+++ src/co/zgpmsg.c     2008-09-07 23:28:07.000000000 -0400
@@ -96,6 +96,14 @@
 process_line(char *p) {
   int i;

+  if (p == NULL) {  /* user has pressed CTRL+D */
+    if ((p = malloc(5)) == NULL) {
+      printf("%s:%d: error allocating p.\n", __FILE__, __LINE__);
+      exit(1);
+    }
+    strncpy(p, "quit", 4);
+    p[4] = '\0';
+  }
   select_loop_continue(SELECT_OFF); /* Turn off select loop */
   select_loop_message(p, SELECT_MSG_SET); /* Set the outgoing message */


Probably there are better ways to do this.

There is another file src/co/zgpmsg.c, which seems to be an old
version of src/co/zgpmsg.c, and is still in the Makefile. Do I need to
change this file as well? Please advise.

Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

From icrazy at gmail.com  Sun Sep  7 23:17:41 2008
From: icrazy at gmail.com (Kuang He)
Date: Mon, 8 Sep 2008 02:17:41 -0400
Subject: [sac-dev] Bugs found
In-Reply-To: <fd0f51b90809052306t12f0f733q88159bcdcd840439@mail.gmail.com>
References: <fd0f51b90809052306t12f0f733q88159bcdcd840439@mail.gmail.com>
Message-ID: <fd0f51b90809072317q42ff5cd0n61468e42d4b452a6@mail.gmail.com>

On Sat, Sep 6, 2008 at 2:06 AM, Kuang He <icrazy at gmail.com> wrote:
> I'm using SAC v101.1 on a linux box (Ubuntu 8.04), and the glibc
> version is 2.7 (2.7-10ubuntu3, to be exact).
>
> $ uname -a
> Linux ....... 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008
> i686 GNU/Linux
> .....
> Bug 2: Putting a space after the comma in something like "&1,DIST"
> will _sometimes_ cause SAC to suddenly abort, with a message from
> glibc indicating possible double free. Below is an example of a case
> where this problem does not show up and another case where the problem
> does show up.
>
> $ sac
> SAC> r vel.sac
> SAC> evaluate to dist1 &1,dist
> SAC> message %dist1
>  2.84897$
> SAC> evaluate to dist1 &1, dist
> *** glibc detected *** /usr/local/sac/bin/sac: double free or
> corruption (!prev): 0x0843f020 ***
> ======= Backtrace: =========
> /lib/tls/i686/cmov/libc.so.6[0xb7c9ba85]
> /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7c9f4f0]
> ....

With Brian's help, I was able to locate the place in the source code
that caused this problem (his OSX machines don't have this problem):
line 93 of src/cpf/cfmt.c . The code there does not have double
free()'s, but code snippets shown below just do not make any sense to
me: temporal variable strtemp1 gets created and destroyed, without
doing anything useful at all. Commenting out these does solve the
problem.

$ diff -u src/cpf/cfmt.c.old src/cpf/cfmt.c
--- src/cpf/cfmt.c.old  2008-09-08 00:07:33.000000000 -0400
+++ src/cpf/cfmt.c      2008-09-08 01:48:27.000000000 -0400
@@ -86,11 +86,14 @@
                        iend_ = ibeg + nchar + 2;
                        if( iend_ <= MCMSG ){
                                kmsg[ibeg - 1] = kmcom.kcom[j - 1][0];
+                               /*
                                 strtemp1 = malloc(MCMSG+1-(ibeg+1));
                                 strncpy(strtemp1,kmsg+ibeg,MCMSG+1-(ibeg+1));
                                 strtemp1[MCMSG+1-(ibeg+1)] = '\0';
                                copykc( (char*)kmcom.kcom[j + 1],9,
nchar, strtemp1);
                                 free(strtemp1);
+                               */
                                kmsg[iend_ - 2] = kmcom.kcom[j - 1][0];
                                kmsg[iend_ - 1] = ' ';
                                if( j == cmcom.jcom )
@@ -103,11 +106,13 @@
                        nchar = (long)( Flnum[j + 1] + 0.1 );
                        iend_ = ibeg + nchar;
                        if( iend_ <= MCMSG ){
+                               /*
                                 strtemp1 = malloc(MCMSG+1-ibeg);
                                 strncpy(strtemp1,kmsg+ibeg-1,MCMSG+1-ibeg);
                                 strtemp1[MCMSG+1-ibeg] = '\0';
                                copykc( (char*)kmcom.kcom[j + 1],9,
nchar, strtemp1);
                                 free(strtemp1);
+                               */
                                kmsg[iend_ - 1] = ' ';
                                if( j == cmcom.jcom )
                                        iarrow = ibeg - ndiff;


By the way, I think wrapping all the uses of free() to FREE() shown
below would be a good idea. The catch is just that since the code base
is too big, it'll take quite some time to change all of them.

#define FREE(ptr)   do { if (ptr) free(ptr); } while (0)


Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

From savage at uri.edu  Mon Sep  8 07:40:39 2008
From: savage at uri.edu (Brian Savage)
Date: Mon, 8 Sep 2008 10:40:39 -0400
Subject: [sac-dev] Bugs found
In-Reply-To: <fd0f51b90809072317q42ff5cd0n61468e42d4b452a6@mail.gmail.com>
References: <fd0f51b90809052306t12f0f733q88159bcdcd840439@mail.gmail.com>
	<fd0f51b90809072317q42ff5cd0n61468e42d4b452a6@mail.gmail.com>
Message-ID: <0162F387-ECC7-4081-966B-2D9E350773A9@uri.edu>

Kuang He,

Good work in tracking down both bugs.
I will look them over in a couple of days, after Wednesday probably.
These fixes will have to wait until after 101.2.

Cheers
Brian

On Sep 8, 2008, at  2:17 AM , Kuang He wrote:

> On Sat, Sep 6, 2008 at 2:06 AM, Kuang He <icrazy at gmail.com> wrote:
>> I'm using SAC v101.1 on a linux box (Ubuntu 8.04), and the glibc
>> version is 2.7 (2.7-10ubuntu3, to be exact).
>>
>> $ uname -a
>> Linux ....... 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008
>> i686 GNU/Linux
>> .....
>> Bug 2: Putting a space after the comma in something like "&1,DIST"
>> will _sometimes_ cause SAC to suddenly abort, with a message from
>> glibc indicating possible double free. Below is an example of a case
>> where this problem does not show up and another case where the  
>> problem
>> does show up.
>>
>> $ sac
>> SAC> r vel.sac
>> SAC> evaluate to dist1 &1,dist
>> SAC> message %dist1
>>  2.84897$
>> SAC> evaluate to dist1 &1, dist
>> *** glibc detected *** /usr/local/sac/bin/sac: double free or
>> corruption (!prev): 0x0843f020 ***
>> ======= Backtrace: =========
>> /lib/tls/i686/cmov/libc.so.6[0xb7c9ba85]
>> /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7c9f4f0]
>> ....
>
> With Brian's help, I was able to locate the place in the source code
> that caused this problem (his OSX machines don't have this problem):
> line 93 of src/cpf/cfmt.c . The code there does not have double
> free()'s, but code snippets shown below just do not make any sense to
> me: temporal variable strtemp1 gets created and destroyed, without
> doing anything useful at all. Commenting out these does solve the
> problem.
>
> $ diff -u src/cpf/cfmt.c.old src/cpf/cfmt.c
> --- src/cpf/cfmt.c.old  2008-09-08 00:07:33.000000000 -0400
> +++ src/cpf/cfmt.c      2008-09-08 01:48:27.000000000 -0400
> @@ -86,11 +86,14 @@
>                         iend_ = ibeg + nchar + 2;
>                         if( iend_ <= MCMSG ){
>                                 kmsg[ibeg - 1] = kmcom.kcom[j - 1][0];
> +                               /*
>                                  strtemp1 = malloc(MCMSG+1-(ibeg+1));
>                                  strncpy(strtemp1,kmsg+ibeg,MCMSG+1- 
> (ibeg+1));
>                                  strtemp1[MCMSG+1-(ibeg+1)] = '\0';
>                                 copykc( (char*)kmcom.kcom[j + 1],9,
> nchar, strtemp1);
>                                  free(strtemp1);
> +                               */
>                                 kmsg[iend_ - 2] = kmcom.kcom[j - 1] 
> [0];
>                                 kmsg[iend_ - 1] = ' ';
>                                 if( j == cmcom.jcom )
> @@ -103,11 +106,13 @@
>                         nchar = (long)( Flnum[j + 1] + 0.1 );
>                         iend_ = ibeg + nchar;
>                         if( iend_ <= MCMSG ){
> +                               /*
>                                  strtemp1 = malloc(MCMSG+1-ibeg);
>                                  strncpy(strtemp1,kmsg+ibeg-1,MCMSG 
> +1-ibeg);
>                                  strtemp1[MCMSG+1-ibeg] = '\0';
>                                 copykc( (char*)kmcom.kcom[j + 1],9,
> nchar, strtemp1);
>                                  free(strtemp1);
> +                               */
>                                 kmsg[iend_ - 1] = ' ';
>                                 if( j == cmcom.jcom )
>                                         iarrow = ibeg - ndiff;
>
>
> By the way, I think wrapping all the uses of free() to FREE() shown
> below would be a good idea. The catch is just that since the code base
> is too big, it'll take quite some time to change all of them.
>
> #define FREE(ptr)   do { if (ptr) free(ptr); } while (0)
>
>
> Best regards,
>
> -- 
> Kuang He
> Department of Physics
> University of Connecticut
> Storrs, CT 06269-3046
>
> Tel: +1.860.486.4919
> Web: http://www.phys.uconn.edu/~he/
> _______________________________________________
> sac-dev mailing list
> sac-dev at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/sac-dev


From icrazy at gmail.com  Mon Sep  8 17:18:12 2008
From: icrazy at gmail.com (Kuang He)
Date: Mon, 8 Sep 2008 20:18:12 -0400
Subject: [sac-dev] SAC 101.2 compilation error with readline (patch provided)
Message-ID: <fd0f51b90809081718s53213369kdaf3ef8463628d16@mail.gmail.com>

Hi all,

I just got the source code of SAC 101.2 today, and found that if it is
configured with readline (), the compile process would halt at the
step of compiling src/co/zgpmsg.c (and later src/co/zgtmsg.c). The
error message is:

$ ./configure --enable-readline
$ make
....
gcc -DHAVE_CONFIG_H -I. -I. -I../inc        -I../inc  -c -o
co/zgpmsg.o co/zgpmsg.c
In file included from /usr/include/readline/chardefs.h:26,
                 from /usr/include/readline/keymaps.h:36,
                 from /usr/include/readline/readline.h:39,
                 from co/zgpmsg.c:93:
/usr/include/ctype.h:116: error: expected identifier or '(' before 'int'
/usr/include/ctype.h:116: error: expected ')' before '?' token
/usr/include/ctype.h:119: error: expected identifier or '(' before 'int'
/usr/include/ctype.h:119: error: expected ')' before '?' token
make[1]: *** [co/zgpmsg.o] Error 1
make[1]: Leaving directory `/home/icrazy/tt/sac-101.2/src'
make: *** [all-recursive] Error 1

After spending some time with it, I found an easy way to illustrate
the problem to you. I'll create a test program, with the two culprit
lines of code extracted from co/zgpmsg.c .

$ cd ~/src/sac-101.2
$ cat src/co/tt.c
#include "stdu.h"
#include <readline/readline.h>

$ gcc -DHAVE_CONFIG_H  -I. -Iinc -c -o src/co/tt src/co/tt.c
In file included from /usr/include/readline/chardefs.h:26,
                 from /usr/include/readline/keymaps.h:36,
                 from /usr/include/readline/readline.h:39,
                 from src/co/tt.c:5:
/usr/include/ctype.h:116: error: expected identifier or '(' before 'int'
/usr/include/ctype.h:116: error: expected ')' before '?' token
/usr/include/ctype.h:119: error: expected identifier or '(' before 'int'
/usr/include/ctype.h:119: error: expected ')' before '?' token

However, if I put a line ``#include <ctype.h>'' at the start of tt.c,
this problem disappears. That is how I figure out that there is
something in the header file src/co/stdu.h interfering with
/usr/include/ctype.h .

Below is a code snippet found at lines 116 and 119 (see above error
messages) in the file /usr/include/ctype.h, which comes with the
package libc6-dev 2.7-10ubuntu3 on my Ubuntu box.

/* Return the lowercase version of C.  */
extern int tolower (int __c) __THROW;
/* Return the uppercase version of C.  */
extern int toupper (int __c) __THROW;

If preprocessed correctly (verified using `gcc -E' on another simple
working C program that simply includes <ctype.h>), these lines would
become:

xtern int tolower (int __c) __attribute__ ((__nothrow__));
extern int toupper (int __c) __attribute__ ((__nothrow__));

And the above error messages result from these lines becoming

extern int _toupper (int) __attribute__ ((__nothrow__));
extern int _tolower (int) __attribute__ ((__nothrow__));

Fixing the problem is easy: getting rid of some duplicate definitions
of tolower() and toupper() in src/co/stdu.h would make this problem go
away. These functions (macros) are defined in C89, C99, 4.3BSD, so any
modern *nix system should have them already defined anyway.

$ git diff HEAD^ HEAD
diff --git a/src/co/stdu.h b/src/co/stdu.h
index f889826..f3bfa2d 100755
--- a/src/co/stdu.h
+++ b/src/co/stdu.h
@@ -23,13 +23,6 @@ extern int strappend();
 extern int strcopy();
 extern int strnumat();

-
-#ifndef CYGWIN
-/*     macro expansions        */
-#define tolower(c)     ((c>='A' && c<='Z') ? (c+('a'-'A')) : c)
-#define toupper(c)     ((c>='a' && c<='z') ? (c-('a'-'A')) : c)
-#endif /* CYGWIN */
-
 #define TRUE   1
 #define FALSE  0
 #define SET    1


Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

From icrazy at gmail.com  Tue Sep  9 18:12:53 2008
From: icrazy at gmail.com (Kuang He)
Date: Tue, 9 Sep 2008 21:12:53 -0400
Subject: [sac-dev] Patch to a buffer overflow bug
Message-ID: <fd0f51b90809091812l36433fd4vd9dd9e8c45a407a5@mail.gmail.com>

Hi,

The string sachistory below is overrun by 1 byte.

diff --git a/src/co/select.c b/src/co/select.c
index 580db77..578360b 100644
--- a/src/co/select.c
+++ b/src/co/select.c
@@ -162,10 +162,11 @@ sac_history_file_set(char *name) {
     /* Null name signifies default */
     home = getenv("HOME");
     if(home) {
-      len = strlen(home) + strlen(SAC_HISTORY_FILE) + 1;
+      /* "+ 2": characters '/' and '\0' */
+      len = strlen(home) + strlen(SAC_HISTORY_FILE) + 2;
       sachistory = (char *)malloc(sizeof(char) * len);
       sprintf(sachistory,"%s/%s", home, SAC_HISTORY_FILE);
-      sachistory[len] = '\0';
+      sachistory[len - 1] = '\0';
     } else {
       sachistory = NULL;
     }


Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

From icrazy at gmail.com  Wed Sep 10 14:31:25 2008
From: icrazy at gmail.com (Kuang He)
Date: Wed, 10 Sep 2008 17:31:25 -0400
Subject: [sac-dev] Patch to prevent an accidental close of the plotting
	window
Message-ID: <fd0f51b90809101431n4ff38a22r8c74f69149b858b1@mail.gmail.com>

Hi all,

BUG: When a user accidentally closes the plotting window, SAC will crash.

$ sac
 SEISMIC ANALYSIS CODE [09/04/2008 (Version 101.2)]
 Copyright 1995 Regents of the University of California

SAC> fg seis
SAC> p
[ ... closing plotting window ... ]
SAC> Seismic Analysis Code (SAC): Fatal IO Error 11 (Resource
temporarily unavailable) on the X server

Attached please find a patch for SAC 101.2 (provided by George
Helffrich and adapted a little by me) to prevent this by disabling the
"X" (close window) button of the plotting window. To apply this patch:

$ cd /path/to/sac
$ patch -p1 < prevent-accidental-close-of-plotting-window.diff

Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: prevent-accidental-close-of-plotting-window.diff
Type: application/octet-stream
Size: 1925 bytes
Desc: not available
URL: <http://www.iris.washington.edu/pipermail/sac-dev/attachments/20080910/dddc809f/attachment.obj>

From savage at uri.edu  Thu Sep 11 14:49:47 2008
From: savage at uri.edu (Brian Savage)
Date: Thu, 11 Sep 2008 17:49:47 -0400
Subject: [sac-dev] Patch to prevent an accidental close of the plotting
	window
In-Reply-To: <fd0f51b90809101431n4ff38a22r8c74f69149b858b1@mail.gmail.com>
References: <fd0f51b90809101431n4ff38a22r8c74f69149b858b1@mail.gmail.com>
Message-ID: <BB5FCE22-4A49-47A4-8A8D-752E78CA9DEC@uri.edu>

Kuang He,

I got your patches applied to code base and quickly checked them.
I received five (5) bugs from you, correct ?

- Ctrl-D - This appears to work correctly.
- X11 Closing window - This appears to disable the "close" window button
	At least on my mac.  Was this the intention.  Or did you want it to  
do something like "enddevice x"
- evaluate bug - This works as well.  I think there is something else  
going on here
	Try running the command twice,  The message is slightly different  
between the first and second time.
- sachistory - Easy fix, but important
- tolower/toupper - This needs to be pulled out and checked for at ./ 
configure time

Side note:
When you compile with the --enable-readline does it actually use the  
readline library or a libedit library.
If you are using a readline library, could you check running sac  
within a script to see how it behaves.

Cheers
Brian

On Sep 10, 2008, at  5:31 PM , Kuang He wrote:

> Hi all,
>
> BUG: When a user accidentally closes the plotting window, SAC will  
> crash.
>
> $ sac
>  SEISMIC ANALYSIS CODE [09/04/2008 (Version 101.2)]
>  Copyright 1995 Regents of the University of California
>
> SAC> fg seis
> SAC> p
> [ ... closing plotting window ... ]
> SAC> Seismic Analysis Code (SAC): Fatal IO Error 11 (Resource
> temporarily unavailable) on the X server
>
> Attached please find a patch for SAC 101.2 (provided by George
> Helffrich and adapted a little by me) to prevent this by disabling the
> "X" (close window) button of the plotting window. To apply this patch:
>
> $ cd /path/to/sac
> $ patch -p1 < prevent-accidental-close-of-plotting-window.diff
>
> Best regards,
>
> -- 
> Kuang He
> Department of Physics
> University of Connecticut
> Storrs, CT 06269-3046
>
> Tel: +1.860.486.4919
> Web: http://www.phys.uconn.edu/~he/<prevent-accidental-close-of- 
> plotting-window.diff>_______________________________________________
> sac-dev mailing list
> sac-dev at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/sac-dev


From icrazy at gmail.com  Thu Sep 11 16:16:21 2008
From: icrazy at gmail.com (Kuang He)
Date: Thu, 11 Sep 2008 19:16:21 -0400
Subject: [sac-dev] Patch to prevent an accidental close of the plotting
	window
In-Reply-To: <BB5FCE22-4A49-47A4-8A8D-752E78CA9DEC@uri.edu>
References: <fd0f51b90809101431n4ff38a22r8c74f69149b858b1@mail.gmail.com>
	<BB5FCE22-4A49-47A4-8A8D-752E78CA9DEC@uri.edu>
Message-ID: <fd0f51b90809111616m21b0614eta4552f0b1765d6a1@mail.gmail.com>

Dear Brian,

On Thu, Sep 11, 2008 at 5:49 PM, Brian Savage <savage at uri.edu> wrote:
> Kuang He,
>
> I got your patches applied to code base and quickly checked them.
> I received five (5) bugs from you, correct ?

Yes, that is correct.

> - Ctrl-D - This appears to work correctly.
> - X11 Closing window - This appears to disable the "close" window button
>        At least on my mac.  Was this the intention.  Or did you want it to
> do something like "enddevice x"

That behavior is intended by George's patch since he said he did not
want the action to result in the close of all the windows, but
actually what I want it to do is something like "ed x".

When I was going through the archives of sac-dev yesterday, I found
that you did have provided a patch to do exactly that back in 2005,
but it seems that patch never got merged into the code base. Maybe we
could reuse that patch. What do you think?

http://www.iris.washington.edu/pipermail/sac-dev/2005-October/000000.html

> - evaluate bug - This works as well.  I think there is something else going
> on here
>        Try running the command twice,  The message is slightly different
> between the first and second time.

I've noticed this and also suspect that there is something else going
on here. The code snippets I've commented out in the post

http://www.iris.washington.edu/pipermail/sac-dev/2008-September/000086.html

do not seem to have double free problem to me. Yet commenting them out
can solve the problem. I don't know whether it is just glibc that is
being paranoid.

George mentioned the below to me in an email.

       Here is the Fortran code for that part of the program, perhaps
slightly more illuminating as to what it is doing:
       -----
         nchar=nint(flnum(j+1))
         iend=ibeg+nchar+2
         if(iend.le.mcmsg)then
           kmsg(ibeg:ibeg)=kval(1:1)
           call copykc(j+2,nchar,kmsg(ibeg+1:))
           kmsg(iend-1:iend-1)=kval(1:1)
           kmsg(iend:iend)=' '
           if(j.eq.jcom)iarrow=ibeg
           ibeg=iend+1
         endif
      -----
     Here, the call to copykc moves the text of the message from the
     tokenized parse text (indexed by j, and implicitly used by copykc)
     into the output message text.  Commenting that part out may fix a
     double free, but it also eliminates the message!  However, it
     looks like the calling sequence for copykc is different, so there
     might have been subsequent changes to the C code.

I don't know whether you have the history of that (perhaps quite old)
change in the C code in the CVS. If you do, we might be able to figure
out what is going on.

> - sachistory - Easy fix, but important
> - tolower/toupper - This needs to be pulled out and checked for at
> ./configure time
>
> Side note:
> When you compile with the --enable-readline does it actually use the
> readline library or a libedit library.
> If you are using a readline library, could you check running sac within a
> script to see how it behaves.

Yes, when I compiled with --enable-readline, it did end up with using
readline library instead of libedit.

$ ldd $HOME/bin/sac | grep readline
        libreadline.so.5 => /lib/libreadline.so.5 (0xb7e66000)

I tried to run sac within a shell script, and it works OK.

$ cat run
#!/bin/sh
sac tt

$ cat tt
fg seis
w test
quit

$ rm test && ./run
 SEISMIC ANALYSIS CODE [09/08/2008 (Version 101.2)]
 Copyright 1995 Regents of the University of California

$ ll test
-rw-rw-rw- 1 icrazy icrazy 4.6K Sep 11 18:44 test

However, if I feed something to SAC through redirection, the one
compiled with libedit works OK, but the one compiled with readline has
the following problem.

$ sac tt
[ ... Works OK ... ]

$ sac < tt
 SEISMIC ANALYSIS CODE [09/08/2008 (Version 101.2)]
 Copyright 1995 Regents of the University of California

SAC> readline: readline_callback_read_char() called with no handler!
Aborted

Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

From savage at uri.edu  Thu Sep 11 18:37:34 2008
From: savage at uri.edu (Brian Savage)
Date: Thu, 11 Sep 2008 21:37:34 -0400
Subject: [sac-dev] Patch to prevent an accidental close of the plotting
	window
In-Reply-To: <fd0f51b90809111616m21b0614eta4552f0b1765d6a1@mail.gmail.com>
References: <fd0f51b90809101431n4ff38a22r8c74f69149b858b1@mail.gmail.com>
	<BB5FCE22-4A49-47A4-8A8D-752E78CA9DEC@uri.edu>
	<fd0f51b90809111616m21b0614eta4552f0b1765d6a1@mail.gmail.com>
Message-ID: <6E166377-7D70-4245-8175-E5E9FCB956B8@uri.edu>

Kuang He

Delete window:
I think that old patch could be used to get the behavior we are  
expecting.

Evaluate:
The code George sent to you looks like a good place to start.  I think  
the code is building an error message, which could be done rather  
easily.

Readline and scripts:
Looks like we need to do some exploration into this and possibly look  
into checking if we are using readline or libedit. Either readline and  
libedit react differently when run within a script or there might be a  
way to make them behave the same way.

Cheers
Brian

On Sep 11, 2008, at 7:16 PM, "Kuang He" <icrazy at gmail.com> wrote:

> Dear Brian,
>
> On Thu, Sep 11, 2008 at 5:49 PM, Brian Savage <savage at uri.edu> wrote:
>> Kuang He,
>>
>> I got your patches applied to code base and quickly checked them.
>> I received five (5) bugs from you, correct ?
>
> Yes, that is correct.
>
>> - Ctrl-D - This appears to work correctly.
>> - X11 Closing window - This appears to disable the "close" window  
>> button
>>       At least on my mac.  Was this the intention.  Or did you want  
>> it to
>> do something like "enddevice x"
>
> That behavior is intended by George's patch since he said he did not
> want the action to result in the close of all the windows, but
> actually what I want it to do is something like "ed x".
>
> When I was going through the archives of sac-dev yesterday, I found
> that you did have provided a patch to do exactly that back in 2005,
> but it seems that patch never got merged into the code base. Maybe we
> could reuse that patch. What do you think?
>
> http://www.iris.washington.edu/pipermail/sac-dev/2005-October/000000.html
>
>> - evaluate bug - This works as well.  I think there is something  
>> else going
>> on here
>>       Try running the command twice,  The message is slightly  
>> different
>> between the first and second time.
>
> I've noticed this and also suspect that there is something else going
> on here. The code snippets I've commented out in the post
>
> http://www.iris.washington.edu/pipermail/sac-dev/2008-September/000086.html
>
> do not seem to have double free problem to me. Yet commenting them out
> can solve the problem. I don't know whether it is just glibc that is
> being paranoid.
>
> George mentioned the below to me in an email.
>
>       Here is the Fortran code for that part of the program, perhaps
> slightly more illuminating as to what it is doing:
>       -----
>         nchar=nint(flnum(j+1))
>         iend=ibeg+nchar+2
>         if(iend.le.mcmsg)then
>           kmsg(ibeg:ibeg)=kval(1:1)
>           call copykc(j+2,nchar,kmsg(ibeg+1:))
>           kmsg(iend-1:iend-1)=kval(1:1)
>           kmsg(iend:iend)=' '
>           if(j.eq.jcom)iarrow=ibeg
>           ibeg=iend+1
>         endif
>      -----
>     Here, the call to copykc moves the text of the message from the
>     tokenized parse text (indexed by j, and implicitly used by copykc)
>     into the output message text.  Commenting that part out may fix a
>     double free, but it also eliminates the message!  However, it
>     looks like the calling sequence for copykc is different, so there
>     might have been subsequent changes to the C code.
>
> I don't know whether you have the history of that (perhaps quite old)
> change in the C code in the CVS. If you do, we might be able to figure
> out what is going on.
>
>> - sachistory - Easy fix, but important
>> - tolower/toupper - This needs to be pulled out and checked for at
>> ./configure time
>>
>> Side note:
>> When you compile with the --enable-readline does it actually use the
>> readline library or a libedit library.
>> If you are using a readline library, could you check running sac  
>> within a
>> script to see how it behaves.
>
> Yes, when I compiled with --enable-readline, it did end up with using
> readline library instead of libedit.
>
> $ ldd $HOME/bin/sac | grep readline
>        libreadline.so.5 => /lib/libreadline.so.5 (0xb7e66000)
>
> I tried to run sac within a shell script, and it works OK.
>
> $ cat run
> #!/bin/sh
> sac tt
>
> $ cat tt
> fg seis
> w test
> quit
>
> $ rm test && ./run
> SEISMIC ANALYSIS CODE [09/08/2008 (Version 101.2)]
> Copyright 1995 Regents of the University of California
>
> $ ll test
> -rw-rw-rw- 1 icrazy icrazy 4.6K Sep 11 18:44 test
>
> However, if I feed something to SAC through redirection, the one
> compiled with libedit works OK, but the one compiled with readline has
> the following problem.
>
> $ sac tt
> [ ... Works OK ... ]
>
> $ sac < tt
> SEISMIC ANALYSIS CODE [09/08/2008 (Version 101.2)]
> Copyright 1995 Regents of the University of California
>
> SAC> readline: readline_callback_read_char() called with no handler!
> Aborted
>
> Best regards,
>
> -- 
> Kuang He
> Department of Physics
> University of Connecticut
> Storrs, CT 06269-3046
>
> Tel: +1.860.486.4919
> Web: http://www.phys.uconn.edu/~he/
> _______________________________________________
> sac-dev mailing list
> sac-dev at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/sac-dev

From icrazy at gmail.com  Thu Sep 11 23:31:50 2008
From: icrazy at gmail.com (Kuang He)
Date: Fri, 12 Sep 2008 02:31:50 -0400
Subject: [sac-dev] Mailing list problem
Message-ID: <fd0f51b90809112331u6d6b193ahebc70fad2796d31a@mail.gmail.com>

Hi all,

Actually, this is something related to sac-help mailing list, but
since it is a development issue, I thought it should be more
appropriate to post it here.

In a lot of SAC documents, such as README, doc/README, configure
--help, any help pages, etc. you can see words like this:

    If you experience problems at any stage please report the issue to
sac-help at iris.washington.edu

However, nowadays one has to subscribe to that mailing list first in
order to be able to send an email to it asking for help. Otherwise,
the mailing list system will _silently_ drop the emails from the
queue. I found out about this the hard way, having two of my emails
dropped when I tried to send a message to sac-help without being a
subscriber. One of the mailing list managers Tim Knight told me that:

   The IRIS mailing lists were more open a couple of years ago until
we starting getting a huge number of spam messages, so the policy on
most mailing lists was to close the lists to subscribers only.

Therefore, I was wondering if we need to add something like

    For further information, go to
http://www.iris.washington.edu/mailman/listinfo/sac-help

to each instance where sac-help is mentioned, or maybe kindly ask the
mailing list managers to at least let the system REJECT emails (using
an SMTP error code) rather than silently DISCARD them, or both.


Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

From george at gly.bris.ac.uk  Fri Sep 12 01:03:06 2008
From: george at gly.bris.ac.uk (George Helffrich)
Date: Fri, 12 Sep 2008 09:03:06 +0100
Subject: [sac-dev] Mailing list problem
In-Reply-To: <fd0f51b90809112331u6d6b193ahebc70fad2796d31a@mail.gmail.com>
References: <fd0f51b90809112331u6d6b193ahebc70fad2796d31a@mail.gmail.com>
Message-ID: <81ac85a95f1c3550c8d3dc9de92a4708@gly.bris.ac.uk>

Dear All -

	The behavior Kuang highlights is certainly unfriendly and impairs 
honest efforts to help.  It would be better if sac-help sent reject 
SMTP responses with a link to to join sac-help.  Putting detailed 
mailing list clerical instructions into code warnings seems wasteful of 
developer time and is likely to become outdated again at some point.

On 12 Sep 2008, at 07:31, Kuang He wrote:

> Hi all,
>
> Actually, this is something related to sac-help mailing list, but
> since it is a development issue, I thought it should be more
> appropriate to post it here.
>
> In a lot of SAC documents, such as README, doc/README, configure
> --help, any help pages, etc. you can see words like this:
>
>     If you experience problems at any stage please report the issue to
> sac-help at iris.washington.edu
>
> However, nowadays one has to subscribe to that mailing list first in
> order to be able to send an email to it asking for help. Otherwise,
> the mailing list system will _silently_ drop the emails from the
> queue. I found out about this the hard way, having two of my emails
> dropped when I tried to send a message to sac-help without being a
> subscriber. One of the mailing list managers Tim Knight told me that:
>
>    The IRIS mailing lists were more open a couple of years ago until
> we starting getting a huge number of spam messages, so the policy on
> most mailing lists was to close the lists to subscribers only.
>
> Therefore, I was wondering if we need to add something like
>
>     For further information, go to
> http://www.iris.washington.edu/mailman/listinfo/sac-help
>
> to each instance where sac-help is mentioned, or maybe kindly ask the
> mailing list managers to at least let the system REJECT emails (using
> an SMTP error code) rather than silently DISCARD them, or both.
>
>
> Best regards,
>
> -- 
> Kuang He
> Department of Physics
> University of Connecticut
> Storrs, CT 06269-3046
>
> Tel: +1.860.486.4919
> Web: http://www.phys.uconn.edu/~he/
> _______________________________________________
> sac-dev mailing list
> sac-dev at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/sac-dev
>
                                     George Helffrich
                                     george at geology.bristol.ac.uk


From j.wookey at bristol.ac.uk  Fri Sep 12 07:53:03 2008
From: j.wookey at bristol.ac.uk (James Wookey)
Date: Fri, 12 Sep 2008 07:53:03 -0700
Subject: [sac-dev] Mailing list problem
In-Reply-To: <81ac85a95f1c3550c8d3dc9de92a4708@gly.bris.ac.uk>
References: <fd0f51b90809112331u6d6b193ahebc70fad2796d31a@mail.gmail.com>
	<81ac85a95f1c3550c8d3dc9de92a4708@gly.bris.ac.uk>
Message-ID: <74C5D265-136D-4270-86F2-0032D919AACD@bristol.ac.uk>

Dear all,

The other alternative would be to scrap any mention of mailing lists,  
and simply direct the user to the main SAC web-page for help/bug  
reporting etc. From there it is easy to maintain up to date  
instructions for joining the mailing list, or further information.


> Dear All -
>
> 	The behavior Kuang highlights is certainly unfriendly and impairs  
> honest efforts to help.  It would be better if sac-help sent reject  
> SMTP responses with a link to to join sac-help.  Putting detailed  
> mailing list clerical instructions into code warnings seems wasteful  
> of developer time and is likely to become outdated again at some  
> point.
>
> On 12 Sep 2008, at 07:31, Kuang He wrote:
>
>> Hi all,
>>
>> Actually, this is something related to sac-help mailing list, but
>> since it is a development issue, I thought it should be more
>> appropriate to post it here.
>>
>> In a lot of SAC documents, such as README, doc/README, configure
>> --help, any help pages, etc. you can see words like this:
>>
>>    If you experience problems at any stage please report the issue to
>> sac-help at iris.washington.edu
>>
>> However, nowadays one has to subscribe to that mailing list first in
>> order to be able to send an email to it asking for help. Otherwise,
>> the mailing list system will _silently_ drop the emails from the
>> queue. I found out about this the hard way, having two of my emails
>> dropped when I tried to send a message to sac-help without being a
>> subscriber. One of the mailing list managers Tim Knight told me that:
>>
>>   The IRIS mailing lists were more open a couple of years ago until
>> we starting getting a huge number of spam messages, so the policy on
>> most mailing lists was to close the lists to subscribers only.
>>
>> Therefore, I was wondering if we need to add something like
>>
>>    For further information, go to
>> http://www.iris.washington.edu/mailman/listinfo/sac-help
>>
>> to each instance where sac-help is mentioned, or maybe kindly ask the
>> mailing list managers to at least let the system REJECT emails (using
>> an SMTP error code) rather than silently DISCARD them, or both.
>>
>>
>> Best regards,
>>
>> -- 
>> Kuang He
>> Department of Physics
>> University of Connecticut
>> Storrs, CT 06269-3046
>>
>> Tel: +1.860.486.4919
>> Web: http://www.phys.uconn.edu/~he/
>> _______________________________________________
>> sac-dev mailing list
>> sac-dev at iris.washington.edu
>> http://www.iris.washington.edu/mailman/listinfo/sac-dev
>>
>                                    George Helffrich
>                                    george at geology.bristol.ac.uk
>
> _______________________________________________
> sac-dev mailing list
> sac-dev at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/sac-dev


From snoke at vt.edu  Fri Sep 12 08:05:14 2008
From: snoke at vt.edu (Arthur Snoke)
Date: Fri, 12 Sep 2008 11:05:14 -0400
Subject: [sac-dev] Mailing list problem
In-Reply-To: <74C5D265-136D-4270-86F2-0032D919AACD@bristol.ac.uk>
References: <fd0f51b90809112331u6d6b193ahebc70fad2796d31a@mail.gmail.com>
	<81ac85a95f1c3550c8d3dc9de92a4708@gly.bris.ac.uk>
	<74C5D265-136D-4270-86F2-0032D919AACD@bristol.ac.uk>
Message-ID: <48CA852A.80309@vt.edu>

James Wookey wrote:
> Dear all,
> 
> The other alternative would be to scrap any mention of mailing lists, 
> and simply direct the user to the main SAC web-page for help/bug 
> reporting etc. From there it is easy to maintain up to date instructions 
> for joining the mailing list, or further information.

Towards the end of both the README and readme.buidsac, it says

* If you need help ...
---------------------------------------------------------------------------
1.  Use the online help from within sac
2.  Some features of SAC are described in the CHANGES file in this directory,
     and changes in new versions are summarized in HISTORY.
3.  URL <http://www.iris.edu/manuals/sac/> has links to other resources and
     information about updates.
4.  A place to share problems and find solutions is the sac-help mailing
     list: <sac-help at iris.washington.edu>.  For further information, go to
     URL <http://www.iris.washington.edu/mailman/listinfo/sac-help>

Let me know if you can think of ways to improve this.

Arthur Snoke

From savage at uri.edu  Fri Sep 12 08:21:48 2008
From: savage at uri.edu (Brian Savage)
Date: Fri, 12 Sep 2008 11:21:48 -0400
Subject: [sac-dev] test suite
Message-ID: <A0C4A5BD-674E-44DC-8977-16ABAD018313@uri.edu>

Attachments:
	(1) - testsuite.patch
	(2) - inctim.patch

At the prodding of Kuang He, an initial testing suite has been  
developed for SAC; see attachment, patch against v101.2.

The patch includes the infrastructure to test the individual  
subroutines within SAC to guarantee changes made to the code do not  
begin to break things.   We envision the use by developers and  
possibly users who wish to compile SAC on their own systems.  After  
installing the patch do the normal

% ./configure
% make
then to run the tests do
% make check

The tests are located in the sac/t directory, borrowing the structure  
from perl.  This can be easily changed.

Comments are welcome.  After the test suite evolves a bit I would  
like to add it to the CVS repository to make it a normal part of the  
building, release process.

Note: The tests will currently fail due from the inclusion of src/ucf/ 
inctim.c.  This was done on purpose.  Kuang He provided a patch, see  
attachment, to make the error messages go away, which I believe is  
the correct behavior, but the inctim() routine still has trouble with  
values very close, actually on, half a millisecond.

Cheers
Brian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testsuite.patch
Type: application/octet-stream
Size: 36979 bytes
Desc: not available
URL: <http://www.iris.washington.edu/pipermail/sac-dev/attachments/20080912/53a727c1/attachment-0002.obj>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: inctim.patch
Type: application/octet-stream
Size: 614 bytes
Desc: not available
URL: <http://www.iris.washington.edu/pipermail/sac-dev/attachments/20080912/53a727c1/attachment-0003.obj>

From icrazy at gmail.com  Sat Sep 13 22:16:45 2008
From: icrazy at gmail.com (Kuang He)
Date: Sun, 14 Sep 2008 01:16:45 -0400
Subject: [sac-dev] Some code refactoring
Message-ID: <fd0f51b90809132216v293e5a0bj1d58b6228636b74f@mail.gmail.com>

Hi,

I've attached a patch which has some code refactoring I've done
recently. The affected files are:

      src/bot/crname.c
      src/co/zbasename.c
      src/co/zinquire.c
      src/co/zopen.c
      src/co/zopens.c

I've mainly updated the comments in those files to doxygen style,
following Brian's practice. Some useless goto statements are deleted
as I go along. I've been extremely careful, and tested the code to
make sure that no functionality is changed during the refactoring.

Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refactoring-20080914.diff
Type: application/octet-stream
Size: 20824 bytes
Desc: not available
URL: <http://www.iris.washington.edu/pipermail/sac-dev/attachments/20080914/cb5181fd/attachment-0001.obj>

From icrazy at gmail.com  Sun Sep 14 00:41:41 2008
From: icrazy at gmail.com (Kuang He)
Date: Sun, 14 Sep 2008 03:41:41 -0400
Subject: [sac-dev] [patch] Use a pager to show the help files
Message-ID: <fd0f51b90809140041j2f0872e9oa4b1f21792b85297@mail.gmail.com>

Hi all,

Attached is a patch (against v101.2) to make SAC use a pager specified
by environment variable $PAGER, instead of the current home-grown tool
similar to ``more'', to show the help files. The good thing is that in
this way, people get to use their favorite pager when viewing the help
files. I personally use ``less'', and its biggest advantage over
``more'' is that it can support scrolling backwards using hotkeys like
Up Arrow, PageDown, Ctrl+U, k, etc. Plus, I get to scroll either way
by a few lines or by half a page, i.e. not necessarily by a whole
page.

Known caveat:

- When the user have an unreasonable setting of $PAGER, the error
message of not being able to load the pager might be a bit mysterious
to the users.

$ export PAGER=xxx
$ sac
SAC> h fg
sh: xxx: not found

- I did not check the return value of malloc() in my code, since I was
hoping someone could come up with a uniform way of reporting malloc()
errors so that we could all stick to it. One possible way is to have a
warpper function to malloc(), and use that instead of malloc() all the
time. And yes, I am aware that there are SO MANY malloc()'s in the
code, whose return values have not been checked!

void *
xmalloc(size_t size)
{
    void *p;

    if ((p = malloc(size)) == NULL)
        fprintf(stderr, "Malloc failed: %s", strerror(errno));
    return (p);
}


Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pager-help-file.diff
Type: application/octet-stream
Size: 2622 bytes
Desc: not available
URL: <http://www.iris.washington.edu/pipermail/sac-dev/attachments/20080914/0fe7518c/attachment.obj>

From savage at uri.edu  Sun Sep 14 09:04:13 2008
From: savage at uri.edu (Brian Savage)
Date: Sun, 14 Sep 2008 12:04:13 -0400
Subject: [sac-dev] [patch] Use a pager to show the help files
In-Reply-To: <fd0f51b90809140041j2f0872e9oa4b1f21792b85297@mail.gmail.com>
References: <fd0f51b90809140041j2f0872e9oa4b1f21792b85297@mail.gmail.com>
Message-ID: <A6B7205D-D747-4E74-9992-5BEAB5E93EBB@uri.edu>

Kuang He

Looking over the patches I have a couple of suggestions/comments.

Could we use ANSI C syntax rather than K&R for function declarations.   
This would allow for the easy creation of header files by copying and  
it is a current/standard notation.

Pager use: We need to check the system for the less command on  
compilation.  In fact we could check for less, then more, then  
fallback to the original code in sac.  A change like this might allow  
for syntax highlighting in the help files.  This would mean the  
current paging code needs to be made into a seperate function.  The  
pager value could always be checked for to override the default.

Cheers
Brian

On Sep 14, 2008, at 3:41 AM, "Kuang He" <icrazy at gmail.com> wrote:

> Hi all,
>
> Attached is a patch (against v101.2) to make SAC use a pager specified
> by environment variable $PAGER, instead of the current home-grown tool
> similar to ``more'', to show the help files. The good thing is that in
> this way, people get to use their favorite pager when viewing the help
> files. I personally use ``less'', and its biggest advantage over
> ``more'' is that it can support scrolling backwards using hotkeys like
> Up Arrow, PageDown, Ctrl+U, k, etc. Plus, I get to scroll either way
> by a few lines or by half a page, i.e. not necessarily by a whole
> page.
>
> Known caveat:
>
> - When the user have an unreasonable setting of $PAGER, the error
> message of not being able to load the pager might be a bit mysterious
> to the users.
>
> $ export PAGER=xxx
> $ sac
> SAC> h fg
> sh: xxx: not found
>
> - I did not check the return value of malloc() in my code, since I was
> hoping someone could come up with a uniform way of reporting malloc()
> errors so that we could all stick to it. One possible way is to have a
> warpper function to malloc(), and use that instead of malloc() all the
> time. And yes, I am aware that there are SO MANY malloc()'s in the
> code, whose return values have not been checked!
>
> void *
> xmalloc(size_t size)
> {
>    void *p;
>
>    if ((p = malloc(size)) == NULL)
>        fprintf(stderr, "Malloc failed: %s", strerror(errno));
>    return (p);
> }
>
>
> Best regards,
>
> -- 
> Kuang He
> Department of Physics
> University of Connecticut
> Storrs, CT 06269-3046
>
> Tel: +1.860.486.4919
> Web: http://www.phys.uconn.edu/~he/
> <pager-help-file.diff>
> _______________________________________________
> sac-dev mailing list
> sac-dev at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/sac-dev

From icrazy at gmail.com  Sun Sep 14 09:32:50 2008
From: icrazy at gmail.com (Kuang He)
Date: Sun, 14 Sep 2008 12:32:50 -0400
Subject: [sac-dev] [patch] Use a pager to show the help files
In-Reply-To: <A6B7205D-D747-4E74-9992-5BEAB5E93EBB@uri.edu>
References: <fd0f51b90809140041j2f0872e9oa4b1f21792b85297@mail.gmail.com>
	<A6B7205D-D747-4E74-9992-5BEAB5E93EBB@uri.edu>
Message-ID: <fd0f51b90809140932m3085e9abh3693a3bb15802c0f@mail.gmail.com>

Dear Brian,

On Sun, Sep 14, 2008 at 12:04 PM, Brian Savage <savage at uri.edu> wrote:
> Kuang He
>
> Looking over the patches I have a couple of suggestions/comments.
>
> Could we use ANSI C syntax rather than K&R for function declarations.  This
> would allow for the easy creation of header files by copying and it is a
> current/standard notation.

Sure, I actually prefer ANSI C syntax myself. I used K&R style
function declarations just to conform to the existing code base. I'll
use ANSI C style from now on.

> Pager use: We need to check the system for the less command on compilation.
>  In fact we could check for less, then more, then fallback to the original
> code in sac.

This is a good idea, but I'm not sure how to do it, so could you help
me with this?

> A change like this might allow for syntax highlighting in the help files.

Exactly, and we get to search within help files.

> This would mean the current paging code needs to be made into a
> seperate function.  The pager value could always be checked for to override
> the default.

I can try isolating the current paging code to a separate function.
Where do you think I should put it, in src/ucf/wrhelp.c?


Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

From savage at uri.edu  Sun Sep 14 10:00:15 2008
From: savage at uri.edu (Brian Savage)
Date: Sun, 14 Sep 2008 13:00:15 -0400
Subject: [sac-dev] [patch] Use a pager to show the help files
In-Reply-To: <fd0f51b90809140932m3085e9abh3693a3bb15802c0f@mail.gmail.com>
References: <fd0f51b90809140041j2f0872e9oa4b1f21792b85297@mail.gmail.com>
	<A6B7205D-D747-4E74-9992-5BEAB5E93EBB@uri.edu>
	<fd0f51b90809140932m3085e9abh3693a3bb15802c0f@mail.gmail.com>
Message-ID: <05D801E3-28D3-4097-A880-629BD127419A@uri.edu>

Kuang He,


ANSI C it is. Unless someone else has any objections.

To add in a check for "less" and or "more" see:
Autoconf: Generic Program Checks
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/ 
html_chapter/autoconf_5.html#SEC41
Either one of these should work. You can give a list of programs to  
check for in the order you would like
Macro: AC_CHECK_PROGS (variable, progs-to-check-for, [value-if-not- 
found], [path])
Macro: AC_PATH_PROGS (variable, progs-to-check-for, [value-if-not- 
found], [path])
This should go into the configure.in file, then the bootstrap needs  
to be re-run.

Isolating the original pager code inside src/sac/wrhelp.c is probably  
the best place for it.

Cheers
Brian

On Sep 14, 2008, at 12:32 PM, Kuang He wrote:

> Dear Brian,
>
> On Sun, Sep 14, 2008 at 12:04 PM, Brian Savage <savage at uri.edu> wrote:
>> Kuang He
>>
>> Looking over the patches I have a couple of suggestions/comments.
>>
>> Could we use ANSI C syntax rather than K&R for function  
>> declarations.  This
>> would allow for the easy creation of header files by copying and  
>> it is a
>> current/standard notation.
>
> Sure, I actually prefer ANSI C syntax myself. I used K&R style
> function declarations just to conform to the existing code base. I'll
> use ANSI C style from now on.
>
>> Pager use: We need to check the system for the less command on  
>> compilation.
>>  In fact we could check for less, then more, then fallback to the  
>> original
>> code in sac.
>
> This is a good idea, but I'm not sure how to do it, so could you help
> me with this?
>
>> A change like this might allow for syntax highlighting in the help  
>> files.
>
> Exactly, and we get to search within help files.
>
>> This would mean the current paging code needs to be made into a
>> seperate function.  The pager value could always be checked for to  
>> override
>> the default.
>
> I can try isolating the current paging code to a separate function.
> Where do you think I should put it, in src/ucf/wrhelp.c?
>
>
> Best regards,
>
> -- 
> Kuang He
> Department of Physics
> University of Connecticut
> Storrs, CT 06269-3046
>
> Tel: +1.860.486.4919
> Web: http://www.phys.uconn.edu/~he/
> _______________________________________________
> sac-dev mailing list
> sac-dev at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/sac-dev


From icrazy at gmail.com  Tue Sep 16 00:42:38 2008
From: icrazy at gmail.com (Kuang He)
Date: Tue, 16 Sep 2008 03:42:38 -0400
Subject: [sac-dev] [patch] Use a pager to show the help files
In-Reply-To: <05D801E3-28D3-4097-A880-629BD127419A@uri.edu>
References: <fd0f51b90809140041j2f0872e9oa4b1f21792b85297@mail.gmail.com>
	<A6B7205D-D747-4E74-9992-5BEAB5E93EBB@uri.edu>
	<fd0f51b90809140932m3085e9abh3693a3bb15802c0f@mail.gmail.com>
	<05D801E3-28D3-4097-A880-629BD127419A@uri.edu>
Message-ID: <fd0f51b90809160042x765f0a77w216dc8e18920a49f@mail.gmail.com>

Dear Brian,

Thanks for the tip.

How often do systems that run SAC come without ``more''? I guess it is
rare. In this case, we can maybe use something like this

AC_CHECK_PROGS(SAC_PAGER, [$PAGER less more cat])

in configure.in, and determine which pager to use at runtime in this way:

if environment variable $PAGER is defined and is not empty
     use that (user's preference has more priority)
else
     use PAGER specified by configure script

In the worst scenario users will end up using ``cat'', which means no
paging at all -- this should hardly happen. In this case, users could
still use something like Shift + PageUp/PageDn to scroll back and
forth. The good thing about this approach is that we don't have to
maintain the original pager code any more. What do you think?

One the other hand, for users who install SAC from binary
distributions, how do we decide which pager to use if they don't have
their environment variable $PAGER set? I don't want them end up using
``cat'' or the original pager code, since many of them may already
have ``less'' or ``more'' installed. Maybe after this feature is
merged into the code, we can highly recommend them to set $PAGER in
the manual?


Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

On Sun, Sep 14, 2008 at 1:00 PM, Brian Savage <savage at uri.edu> wrote:
> Kuang He,
>
>
> ANSI C it is. Unless someone else has any objections.
>
> To add in a check for "less" and or "more" see:
> Autoconf: Generic Program Checks
> http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/autoconf_5.html#SEC41
> Either one of these should work. You can give a list of programs to check
> for in the order you would like
> Macro: AC_CHECK_PROGS (variable, progs-to-check-for, [value-if-not-found],
> [path])
> Macro: AC_PATH_PROGS (variable, progs-to-check-for, [value-if-not-found],
> [path])
> This should go into the configure.in file, then the bootstrap needs to be
> re-run.
>
> Isolating the original pager code inside src/sac/wrhelp.c is probably the
> best place for it.

From savage at uri.edu  Tue Sep 16 09:13:53 2008
From: savage at uri.edu (Brian Savage)
Date: Tue, 16 Sep 2008 12:13:53 -0400
Subject: [sac-dev] [patch] Use a pager to show the help files
In-Reply-To: <fd0f51b90809160042x765f0a77w216dc8e18920a49f@mail.gmail.com>
References: <fd0f51b90809140041j2f0872e9oa4b1f21792b85297@mail.gmail.com>
	<A6B7205D-D747-4E74-9992-5BEAB5E93EBB@uri.edu>
	<fd0f51b90809140932m3085e9abh3693a3bb15802c0f@mail.gmail.com>
	<05D801E3-28D3-4097-A880-629BD127419A@uri.edu>
	<fd0f51b90809160042x765f0a77w216dc8e18920a49f@mail.gmail.com>
Message-ID: <1F66F158-7922-471F-8B32-E27D6DECA9D8@uri.edu>

Kuang He

Looks like less is available on Linux and OSX (the GNU version)
I cannot find a version of less on Solaris, but Solaris does have the  
more command.
I would propose doing a check like

AC_CHECK_PROGS(SAC_PAGER, [ less more ])
It would be nice to remove this code as the capability exists  
elsewhere outside of SAC.
There is similar code in src/dfm/xlh.c to do paging for the listhdr  
command, but it is
coupled to the output of the command.  Same for the news command.  
Would you suggest
that we change the way these commands operate as well ?  This could  
be done with a
pipe to the pager.  It might be more trouble than it is worth.  This  
also modifies the current behavior of SAC.

I still think having a fallback to the original SAC paging code is  
the safest thing to do.

Cheers
Brian

On Sep 16, 2008, at  3:42 AM , Kuang He wrote:

> Dear Brian,
>
> Thanks for the tip.
>
> How often do systems that run SAC come without ``more''? I guess it is
> rare. In this case, we can maybe use something like this
>
> AC_CHECK_PROGS(SAC_PAGER, [$PAGER less more cat])
>
> in configure.in, and determine which pager to use at runtime in  
> this way:
>
> if environment variable $PAGER is defined and is not empty
>      use that (user's preference has more priority)
> else
>      use PAGER specified by configure script
>
> In the worst scenario users will end up using ``cat'', which means no
> paging at all -- this should hardly happen. In this case, users could
> still use something like Shift + PageUp/PageDn to scroll back and
> forth. The good thing about this approach is that we don't have to
> maintain the original pager code any more. What do you think?
>
> One the other hand, for users who install SAC from binary
> distributions, how do we decide which pager to use if they don't have
> their environment variable $PAGER set? I don't want them end up using
> ``cat'' or the original pager code, since many of them may already
> have ``less'' or ``more'' installed. Maybe after this feature is
> merged into the code, we can highly recommend them to set $PAGER in
> the manual?
>
>
> Best regards,
>
> -- 
> Kuang He
> Department of Physics
> University of Connecticut
> Storrs, CT 06269-3046
>
> Tel: +1.860.486.4919
> Web: http://www.phys.uconn.edu/~he/
>
> On Sun, Sep 14, 2008 at 1:00 PM, Brian Savage <savage at uri.edu> wrote:
>> Kuang He,
>>
>>
>> ANSI C it is. Unless someone else has any objections.
>>
>> To add in a check for "less" and or "more" see:
>> Autoconf: Generic Program Checks
>> http://www.gnu.org/software/autoconf/manual/autoconf-2.57/ 
>> html_chapter/autoconf_5.html#SEC41
>> Either one of these should work. You can give a list of programs  
>> to check
>> for in the order you would like
>> Macro: AC_CHECK_PROGS (variable, progs-to-check-for, [value-if-not- 
>> found],
>> [path])
>> Macro: AC_PATH_PROGS (variable, progs-to-check-for, [value-if-not- 
>> found],
>> [path])
>> This should go into the configure.in file, then the bootstrap  
>> needs to be
>> re-run.
>>
>> Isolating the original pager code inside src/sac/wrhelp.c is  
>> probably the
>> best place for it.
> _______________________________________________
> sac-dev mailing list
> sac-dev at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/sac-dev
>


From icrazy at gmail.com  Tue Sep 16 14:22:38 2008
From: icrazy at gmail.com (Kuang He)
Date: Tue, 16 Sep 2008 17:22:38 -0400
Subject: [sac-dev] [patch] Use a pager to show the help files
In-Reply-To: <1F66F158-7922-471F-8B32-E27D6DECA9D8@uri.edu>
References: <fd0f51b90809140041j2f0872e9oa4b1f21792b85297@mail.gmail.com>
	<A6B7205D-D747-4E74-9992-5BEAB5E93EBB@uri.edu>
	<fd0f51b90809140932m3085e9abh3693a3bb15802c0f@mail.gmail.com>
	<05D801E3-28D3-4097-A880-629BD127419A@uri.edu>
	<fd0f51b90809160042x765f0a77w216dc8e18920a49f@mail.gmail.com>
	<1F66F158-7922-471F-8B32-E27D6DECA9D8@uri.edu>
Message-ID: <fd0f51b90809161422u3aae1a63xea3e73cf9317d9eb@mail.gmail.com>

Dear Brian,

On Tue, Sep 16, 2008 at 12:13 PM, Brian Savage <savage at uri.edu> wrote:
> There is similar code in src/dfm/xlh.c to do paging for the listhdr command,
> but it is
> coupled to the output of the command.  Same for the news command. Would you
> suggest
> that we change the way these commands operate as well ?  This could be done
> with a
> pipe to the pager.  It might be more trouble than it is worth.  This also
> modifies the current behavior of SAC.

I agree with you. For the time being, maybe we can just leave the
paging part of the listhdr command alone.

> Looks like less is available on Linux and OSX (the GNU version)
> I cannot find a version of less on Solaris, but Solaris does have the more
> command.
> I would propose doing a check like
> AC_CHECK_PROGS(SAC_PAGER, [ less more ])
> It would be nice to remove this code as the capability exists elsewhere
> outside of SAC.
>
> I still think having a fallback to the original SAC paging code is the
> safest thing to do.

There are some problems with checking for available pager programs
during the ./configure stage:

(1) For example, if the user does not have ``less'' during the
./configure stage, SAC will use ``more'' to do the paging. After SAC
is compiled and installed, if the users installs ``less'' but does not
set the environment variable $PAGER, SAC will still be using ``more''
all the time. Yes, it is the user's responsibility to set $PAGER
correctly, but who knows.

(2) If developer A compiles a binary SAC package on a system that has
``less'' installed and distributes it to user B who does not have
``less'' on her system, SAC will still try to use ``less'' as its
pager, which will result in a failure.

To solve this problem, I propose that we check for pager programs at
runtime, following the practice of ``man''. So when SAC starts, it'll
run through this decision process:

if the environment variable $PAGER is set to a non-empty value {
    use it
} else {
   SAC will look for executable files at these locations one by one
        /usr/bin/less
        /bin/less
        /usr/bin/more
        /bin/more
        and will use the first one available.
   If none of the above pages are available, SAC will fall back to its
original paging code.
}

Maybe we could put the above in the initialization part of SAC. How
does that sound?


Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

From icrazy at gmail.com  Tue Sep 16 17:48:35 2008
From: icrazy at gmail.com (Kuang He)
Date: Tue, 16 Sep 2008 20:48:35 -0400
Subject: [sac-dev] We are in need of a coding standard
Message-ID: <fd0f51b90809161748m75e74060n19414f2a55dca7d3@mail.gmail.com>

Hi all,

Eric S. Raymond says in the chapter "Best Practices for Working with
Open-Source Developers" of his book The Art of Unix Programming:

Choose a coding standard. The debate over the choice of standard can
go on forever?regardless, it is too difficult and expensive to
maintain software built using multiple coding standards, and so some
common style must be chosen. Enforce your coding standard ruthlessly,
as consistency and cleanliness of the code are of the highest
priority; the details of the coding standard itself are a distant
second.

Although SAC is still proprietary software, some good standards are
still desirable. At least we should come up some general rules we
agree upon, for example:

- set indentation level to how many spaces (2 or 4 or 8?)

- the position of curly brackets

  if (statement) {	// K&R style
      ...
  } else {
      ...
  }

  or else? (the same thing applies to for, while, do, switch statements)

  void function() {	// Java style
      ...
  }

  or

  void
  function()
  {
      ....
  }

  or

  void function()
  {
      ....
  }

  or else?

- put spaces around operators?

  a = b + c;

  vs.

  a=b+c;

- maximum line length for non-comment lines (72, 75, 78, 80, ...?)

- the order of #include's

  #include <stdio.h>	// system header files first
  #include <stdlib.h>
  #include <sys/wait.h>	// system header files not in the /usr/include directory
			// blank line
  #include "myown.h"	// user header files
  #include "bar.h"

- #define's use variables of all uppercase letters

  #define PI 3.1415926

- style of multi-line comments

  /*
   * this is a comment
   * second line
   */

  or:

  /*
     this is a comment
     second line
   */

  or:

  /* this is a comment
     second line */


We don't need anything fancy, just enough general rules to make the
code written by different people look similar. And we gotta stick to
them.

We also need to talk about how to convert the existing code to confirm
to our coding style once we have one. We can convert all the code
using ``indent'' once and for all. It will make things like ``cvs
diff'' between versions around that point harder to look at, but we
got to do it at some point. I've worked at a place where there is a
huge pile of ancient spaghetti C codes to maintain. The policy is no
matter what you change, you have to run ``indent'' on the files you
have modified before committing your changes. This makes the output of
``cvs diff'' (even with --ignore-all-space) almost unreadable all the
time, since people work on different files at different times.

Inputs are welcome!


Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/


From icrazy at gmail.com  Tue Sep 16 19:52:31 2008
From: icrazy at gmail.com (Kuang He)
Date: Tue, 16 Sep 2008 22:52:31 -0400
Subject: [sac-dev] [patch] Use a pager to show the help files
In-Reply-To: <fd0f51b90809161422u3aae1a63xea3e73cf9317d9eb@mail.gmail.com>
References: <fd0f51b90809140041j2f0872e9oa4b1f21792b85297@mail.gmail.com>
	<A6B7205D-D747-4E74-9992-5BEAB5E93EBB@uri.edu>
	<fd0f51b90809140932m3085e9abh3693a3bb15802c0f@mail.gmail.com>
	<05D801E3-28D3-4097-A880-629BD127419A@uri.edu>
	<fd0f51b90809160042x765f0a77w216dc8e18920a49f@mail.gmail.com>
	<1F66F158-7922-471F-8B32-E27D6DECA9D8@uri.edu>
	<fd0f51b90809161422u3aae1a63xea3e73cf9317d9eb@mail.gmail.com>
Message-ID: <fd0f51b90809161952n5ea9eb49j96d745346e244d85@mail.gmail.com>

On Tue, Sep 16, 2008 at 5:22 PM, Kuang He <icrazy at gmail.com> wrote:
> To solve this problem, I propose that we check for pager programs at
> runtime, following the practice of ``man''. So when SAC starts, it'll
> run through this decision process:
>
> if the environment variable $PAGER is set to a non-empty value {
>    use it
> } else {
>   SAC will look for executable files at these locations one by one
>        /usr/bin/less
>        /bin/less
>        /usr/bin/more
>        /bin/more
>        and will use the first one available.
>   If none of the above pages are available, SAC will fall back to its
> original paging code.
> }

I've implemented the above algorithm, and the patch (against v101.2)
is attached.

If you have applied the previous patch included in:
http://www.iris.washington.edu/pipermail/sac-dev/2008-September/000100.html

You need to reverse that patch first using ``patch -R'', before
applying this patch.

In this patch:

- The original paging code has been isolated to internal_pager(), in
file src/ucf/wrhelp.c

- SAC will try to determine which pager to use and whether to use the
internal pager or not during the initialization stage

- When the user has a broken setting of $PAGER, the error message is clearer:

$ export PAGER=xxxx
$ sac
SAC> h
sh: xxxx: not found
Error loading pager xxxx!

- A global variable pager has been defined in src/top/initsac.c, and I
don't know whether there is a better place for that.


Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pager-help-file2.diff
Type: application/octet-stream
Size: 7192 bytes
Desc: not available
URL: <http://www.iris.washington.edu/pipermail/sac-dev/attachments/20080916/7b57a3c9/attachment.obj>

From icrazy at gmail.com  Thu Sep 18 12:58:53 2008
From: icrazy at gmail.com (Kuang He)
Date: Thu, 18 Sep 2008 15:58:53 -0400
Subject: [sac-dev] Several readline/libedit related fixes
Message-ID: <fd0f51b90809181258x2501c54ew43085877428697f7@mail.gmail.com>

Hi,

I've developed a patch for the readline/libedit related codes. It
includes the following:

- Fix: SAC with readline cannot read commands from STDIN  (sac < macro_file)
- Fix: for SAC compiled with either libedit or readline, when reading
commands from STDIN, the command history gets truncated when SAC exits
- When not using interactive mode (sac < macro_file), do not show the
copyright information. (This is my idea, following the practice of
some other popular software packages such as ``bc'', but this can be
discussed.)
- some code cleanup

TODO:
- We need a way to tell if we are using readline or libedit (rightnow,
macro READLINE only tells us that we are using one of them, but does
not differentiate which one), since on some occasions, the
implementations using the two libraries do differ. For example, we
need to

#include <readline/readline.h>
#include <readline/history.h>

when using readline, but we only need to include the first header file
when using libedit.

- File src/mat/engineCall2.c implicitly assumes that READLINE is
defined, but we still need to wrap up the related code using #ifdef
READLINE ... #endif

By the way, the attached patch is a combination of several smaller
changes in my system, so I can break them up into smaller patches if
that is preferred.


Best regards,

-- 
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: readline-several-fixes.diff
Type: application/octet-stream
Size: 9448 bytes
Desc: not available
URL: <http://www.iris.washington.edu/pipermail/sac-dev/attachments/20080918/8cb40c38/attachment-0001.obj>