SAC Developers

A forum for SAC developers to exchange ideas about SAC enhancements, bug fixes, etc.

Email address
sac-dev@lists.ds.iris.edu
Type
Subscribers
178
Moderated by
IRIS Webmaster
Related tags
None
April
March
February
January
December
November
October
September (1)
August
July
June
May
April
March
February
January
December
November
October
September
August
July
June
May
April
March
February
January
December
November
October
September
August
July
June
May
April
March
February
January
December
November
October
September
August
July
June
May
April
March
February
January
December
November
October
September
August
July
June
May
April
March
February
January
December
November
October
September
August
July
June
May
April
March
February
January
December
November
October
September
August
July
June
May
April
March
February
January
December
November
October
September
August
July
June
May
April
March
February
January
December
November
October
September
August
July
June (2)
May
April
March
February
January
December
November
October (3)
September
August
July (1)
June
May
April
March
February
January
December (1)
November
October
September
August
July
June
May
April (2)
March
February (1)
January (2)
December
November (1)
October
September (2)
August (1)
July
June (11)
May
April
March
February
January
December
November
October
September
August
July
June
May
April (1)
March
February
January
December
November
October
September
August (2)
July
June
May (1)
April (1)
March (1)
February
January
December
November
October
September
August
July
June (2)
May
April
March (2)
February (5)
January

Active Message Threads for November 2005

George Helffrich
2005-11-30 18:02:05 - 2005-11-30 23:23:10
This patch eliminates warning messages when building on MacOS X 10.2 systems George
Replies
George Randall
2005-11-30 20:02:04 - 2005-11-30 22:52:00
SAC developers, I'd like to advocate for having SAC use the platform native byte order and defer any conversion to sactosac. I've seen and used several scripting packages to read/write sac headers and data (python, matlab, and perl) that are useful in platform native byte order. The python and perl kits essentially function as a shell like way to scan sac files based on the header, and do any basic file level manipulation to organize data sets etc. I would hate to see these efforts get compli… [more]
Replies
George Helffrich
2005-11-30 17:55:16
This patch to src/makefile yields a successful build on Mac OS X 10.2 systems George
No replies
Brian Savage
2005-11-21 23:10:05 - 2005-11-30 04:53:51
I forgot to post to the list, but instead sent just to George. This is George's response to me. Hi Brian - On Monday, November 21, 2005, at 06:22 PM, Brian Savage wrote: > It sounds like whatever we decide, the file formats (SAC and SGF) need > to be documented. Amen. But where? There really isn't any "formal" SAC documentation any more, just broken links hanging around on the web and outdated pieces of paper that I have from old SAC manuals. It would be valuable to have that roff sourc… [more]
Replies
George Helffrich
2005-11-22 00:44:19
From Arthur Snoke's response: > ... I don't agree with your statement that the byte order cannot be > discerned easily for SGF files. The first "word" in an SGF file is a > 4-byte integer which is (using od -t -d2 on the Sun) 00000 00005 for > big endian and 01280 00000 on PC/Linux. Am I missing something? The reason Arthur's tactic works is because SAC always writes SGF files with a stanza that writes: bufsize: 16 color: 7 line: 1 hwsize: 0.013 … [more]
No replies
Brian Savage
2005-11-21 23:09:16
It sounds like whatever we decide, the file formats (SAC and SGF) need to be documented. Concerning SGF. If it has always written the files in the same way, why change it, make it the standard and document it. Concerning SAC. If we decide all SAC files should be in big endian format (or even little) I am certain there will be an outcry from the community who uses Sac for processing and as a data file format. If we specify an endianness, we are introducing more bugs on linux machines as the… [more]
No replies
Brian Savage
2005-11-20 00:20:48 - 2005-11-21 18:51:17
I have done a bit of thinking about the byte-order situation and problem with using write header. I can confirm that using read header and write header on a sac file in the opposite byte order does not work and basically destroys the sac file. My thought for fixing this bug is as follows: On read: Add a variable which tracks if the file needed to be swapped on read or read header. On write header: if file not swapped on read: write header if file was swapped on read: swap heade… [more]
Replies
George Helffrich
2005-11-15 21:37:28
This appears to be a breathtaking step backward in capability. If I understand GTK properly, it is: 1) not network capable like X11 (meaning you can't run SAC on one machine and display the graphics on another machine); 2) would demand open source for SAC due to it coming under the GPL. (2) was the motive, I thought, for opting for the {Free,Net}BSD version of readline rather than GNU readline recently. (1) is a drastic limitation in capability, if I understand GTK rightly: you have… [more]
Replies
Brian Savage
2005-11-04 19:09:05 - 2005-11-15 01:32:41
All, I am trying to write a simple program in C using the sacio.a library. I was doing this to provide an exmaple bit of code people could use as a base to start from. I am running into problems. I read in a file using rsac1, mutiply the data by 10 and then use wsac1 to write it out to a differnet file name. If the infile file exists and the output file does not exist, everything works as fine. If both the input and output files exist, then a output file is written with a one less c… [more]
Replies
10:16:27 v.22510d55