Frederik Tilmann
Dear SAC developers
what are the plans regarding the 'external function' functionality of
SAC, i.e. the possibility to create SAC extensions by using through
creating a libext.so file with ones own functions, which are then loaded
through
SAC> load <function-name>
I see that the SAC command "load" does no longer appear to be
documented. As of version 101.5c some aspects of this still seem to run,
though (I requested up-to-date version of sac, waiting for IRIS
approval). I can
"load rotinc" (rotinc being the name of an external function I implemented)
and my function can access the header and data of the files in memory.
Curiously only updates to float header variables are transferred to SAC,
though, but not changes to khdr (string header variables) or the data (I
have not tested other header variables). Of course, these limitations
make the functionality pretty useless, but the fact that some aspects
still work makes me hopeful.
Before I invest more time can I ask whether
1. abandoning this functionality has been a strategic or inadvertent but
largely irrersible decision
2. in principle there is a wish to continue to support this but nobody
had the time to look into problems (in this case I could try to have a
look, although someone familiar with SAC externals would obviously do a
better job)
3. this is working for other people (in which case I can try and find
what is wrong with my setup)
Cheers
Frederik Tilmann
what are the plans regarding the 'external function' functionality of
SAC, i.e. the possibility to create SAC extensions by using through
creating a libext.so file with ones own functions, which are then loaded
through
SAC> load <function-name>
I see that the SAC command "load" does no longer appear to be
documented. As of version 101.5c some aspects of this still seem to run,
though (I requested up-to-date version of sac, waiting for IRIS
approval). I can
"load rotinc" (rotinc being the name of an external function I implemented)
and my function can access the header and data of the files in memory.
Curiously only updates to float header variables are transferred to SAC,
though, but not changes to khdr (string header variables) or the data (I
have not tested other header variables). Of course, these limitations
make the functionality pretty useless, but the fact that some aspects
still work makes me hopeful.
Before I invest more time can I ask whether
1. abandoning this functionality has been a strategic or inadvertent but
largely irrersible decision
2. in principle there is a wish to continue to support this but nobody
had the time to look into problems (in this case I could try to have a
look, although someone familiar with SAC externals would obviously do a
better job)
3. this is working for other people (in which case I can try and find
what is wrong with my setup)
Cheers
Frederik Tilmann
-
Dear All -
This feature is dead in SAC. Its functionality can be achieved through use of the SAC macro language.
Notwithstanding it being undocumented, the main problem with load is that it has no defined API within SAC. Thus it is simply unmaintainable. That, pure and simply, is why you think it is broken now: SAC’s internals have moved on from where they once were.
Use of the macro language and external programs is just as effective a way to provide new SAC command line functionality. And, it is eminently maintainable because it uses the SAC I/O library, which is a documented API.
On 10 Oct 2014, at 19:47, Frederik Tilmann <tilmann<at>gfz-potsdam.de> wrote:
Dear SAC developers
George Helffrich
what are the plans regarding the 'external function' functionality of SAC, i.e. the possibility to create SAC extensions by using through creating a libext.so file with ones own functions, which are then loaded through
SAC> load <function-name>
I see that the SAC command "load" does no longer appear to be documented. As of version 101.5c some aspects of this still seem to run, though (I requested up-to-date version of sac, waiting for IRIS approval). I can
"load rotinc" (rotinc being the name of an external function I implemented)
and my function can access the header and data of the files in memory.
Curiously only updates to float header variables are transferred to SAC, though, but not changes to khdr (string header variables) or the data (I have not tested other header variables). Of course, these limitations make the functionality pretty useless, but the fact that some aspects still work makes me hopeful.
Before I invest more time can I ask whether
1. abandoning this functionality has been a strategic or inadvertent but largely irrersible decision
2. in principle there is a wish to continue to support this but nobody had the time to look into problems (in this case I could try to have a look, although someone familiar with SAC externals would obviously do a better job)
3. this is working for other people (in which case I can try and find what is wrong with my setup)
Cheers
Frederik Tilmann
_______________________________________________
sac-dev mailing list
sac-dev<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/sac-dev
george.helffrich<at>bris.ac.uk
-
Dear Frederik,
Let me see if I can expand on what George has said.
The load function has not been updated for about 10 years. It was also a complex feature that, as George stated, did not have an API that made it difficult to ensure compatibility across multiple platforms. The load command should probably be removed to avoid this confusion.
Without knowing exactly what your "rotinc" package is doing it is difficult to determine if that functionality can be done entirely with SAC the program. But, I am certain the functionality can be accomplished using the SAC I/O library.
Is there some specific functionality that you need from SAC the program for rotinc or is the rotinc package a more complex piece of software ?
Cheers,
Brian Savage
On Oct 10, 2014, at 9:56 PM, George Helffrich wrote:
Dear All -
This feature is dead in SAC. Its functionality can be achieved through use of the SAC macro language.
Notwithstanding it being undocumented, the main problem with load is that it has no defined API within SAC. Thus it is simply unmaintainable. That, pure and simply, is why you think it is broken now: SAC’s internals have moved on from where they once were.
Use of the macro language and external programs is just as effective a way to provide new SAC command line functionality. And, it is eminently maintainable because it uses the SAC I/O library, which is a documented API.
On 10 Oct 2014, at 19:47, Frederik Tilmann <tilmann<at>gfz-potsdam.de> wrote:
Dear SAC developers
George Helffrich
what are the plans regarding the 'external function' functionality of SAC, i.e. the possibility to create SAC extensions by using through creating a libext.so file with ones own functions, which are then loaded through
SAC> load <function-name>
I see that the SAC command "load" does no longer appear to be documented. As of version 101.5c some aspects of this still seem to run, though (I requested up-to-date version of sac, waiting for IRIS approval). I can
"load rotinc" (rotinc being the name of an external function I implemented)
and my function can access the header and data of the files in memory.
Curiously only updates to float header variables are transferred to SAC, though, but not changes to khdr (string header variables) or the data (I have not tested other header variables). Of course, these limitations make the functionality pretty useless, but the fact that some aspects still work makes me hopeful.
Before I invest more time can I ask whether
1. abandoning this functionality has been a strategic or inadvertent but largely irrersible decision
2. in principle there is a wish to continue to support this but nobody had the time to look into problems (in this case I could try to have a look, although someone familiar with SAC externals would obviously do a better job)
3. this is working for other people (in which case I can try and find what is wrong with my setup)
Cheers
Frederik Tilmann
_______________________________________________
sac-dev mailing list
sac-dev<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/sac-dev
george.helffrich<at>bris.ac.uk
_______________________________________________
sac-dev mailing list
sac-dev<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/sac-dev
-
George Helffrich
Brian Savage
