CVOS Documentation
Stephen Walton wrote on Jan 10, 2000
Michele De La Pena wrote: > Documentation on the C Interface to the IRAF Virtual Operating System > (CVOS) is now available. Questions: 1. How is this related to the IRAF group's OpenIRAF effort? Is the C language API from OpenIRAF going to resemble that of CVOS? I'd hate to start programming using the latter only to find I had to rewrite stuff. 2. Does CVOS require STSDAS? I don't have all of STSDAS installed since I don't really need much of it, only core IRAF and the TABLES package. -- Stephen Walton, Professor, Dept. of Physics & Astronomy, Cal State Northridge stephen.walton@csun.edu
Michele De La Pena wrote on Jan 10, 2000
With regard to the question on the C Interface to the IRAF Virtual Operating System... 1. How is this (the CVOS) related to the IRAF group's OpenIRAF effort? Included in the scope of the OpenIRAF effort by the IRAF group is the notion of creating language bindings, particularly C bindings. The CVOS effort was begun and developed by the Science Software Group (SSG aka STSDAS group) at STScI before the OpenIRAF effort became official. In our discussions with Doug, he has indicated there should be little change in the "official" IRAF C interface once it is developed from that of the CVOS. By this I mean the function signatures (function name and argument list) should be the same as those of the CVOS. The only foreseeable changes are how the IRAF libraries are initialized and the handling of exceptions. The initialization issue may require a change to a line or two of code, and the exception handling may be transparent. Doug would be the best person to comment on further issues and the time-scale for the "official" C bindings. In any case, SSG is committed to supporting the CVOS until such time that the official C bindings are released and all of our software is updated, as necessary, to the official bindings. 2. Does CVOS require STSDAS? The CVOS is distributed as part of the STSDAS package. The source code for the CVOS is located in stsdas$lib/cvos. If you do not have STSDAS installed, you do not have access to the CVOS. If you have further questions, please do not hesitate to inquire. I would suggest you obtain a copy of the documentation, just to get an idea as to what is required in order to use the CVOS. Best, Michele ------------------------------------------------------------------------- Michele D. De La Pena email: delapena@stsci.edu Senior Scientific Programmer phone: 410-338-4713 Space Telescope Science Institute fax: 410-338-4767 3700 San Martin Drive Baltimore, MD 21218 "The nice thing about standards is there are so many to choose from." -------------------------------------------------------------------------
Doug Tody wrote on Jan 11, 2000
Hi All,
Steve Walton asked the following in regard to Michelle's posting (for STScI)
regarding the ST CVOS interface. CVOS is a C interface to the IRAF VOS, or
core libraries.
> 1. How is this [the STScI CVOS interface] related to the IRAF group's
> OpenIRAF effort? Is the C language API from OpenIRAF going to resemble
> that of CVOS? I'd hate to start programming using the latter only to find
> I had to rewrite stuff.
The native IRAF multilanguage support, being developed under a NASA funded
ADP grant, is partially implemented and we hope to release a beta version
later this year.
The answer to Steve's question is that the interfaces will be similar, but
of course not identical in all respects. The most fundamental things,
e.g. most library calls, are the same, but the "stuff around the edges",
e.g. the way the main is written or the way structures and exception
handling are treated, will differ. Most existing code should be unaffected
or minimally affected, but some changes will be required.
The actual implementation will be completely different since the IRAF
version will integrate multilanguage support directly into the HSI (XC
and MKPKG), with the binding jacket routines being added directly to the
system libraries, with each routine stored as a separate object module as
at present. The integrated version will autogenerate the bindings for
each target language directly from the SPP sources whenever mkpkg is run,
just as the SPP "bindings" are autogenerated now. Some changes to the
IRAF sources will be required to make this work. The changes are minor,
but will affect many system source files.
What will be the same in the CVOS and the native IRAF multilanguage support
is the basic mapping of a SPP library function into a C function. That is,
o A "c_" is added to the external name of each function, e.g.,
"c_immap" is the C binding for "immap". Bindings for other languages
will be handled similarly.
o Where possible arguments in the C binding are passed call-by-value
as in typical C code. That is, input only arguments are passed by
value.
o SPP pointer variables are converted to and from C pointers in a
functional call (both arguments and return values) where possible.
o Strings are automatically converted to and from the C and SPP
representations in a function call, where possible.
These features have been chosen to agree with common C programming practice
and to provide the cleanest possible interface for C language programming.
Extensions to SPP have been defined to provide the extra information needed
to implement the above mappings, without having to maintain binding
information separately from the sources. This includes a provision to
identify which routines in an interface are private and which are public.
Bindings are generated only for public functions. The major extensions
to the SPP syntax are a provision for identifying whether arguments are
input-only, output-only, or updatable (used for both input and output),
and a provision to specify the element type of a pointer for cases where
pointer conversion is required. These changes are independent of the
target language, so once the IRAF sources support this, bindings can be
autogenerated for any supported target language. We only plan to support
C in the first version however.
IRAF tasks written in C will be identical to SPP tasks except for the
source language. Among other things, this means that they must use the
IRAF LIBC interface for C-style standard i/o. Host programs that depend
upon multilanguage support to call the IRAF VOS routines may or may not
use IRAF LIBC depending upon whether they are to be called as IRAF tasks.
IRAF LIBC is not currenly ANSI compliant. Some minor ANSI enhancements
were made in V2.11.3, but full support for ANSI C will require incompatible
interface changes which will break existing code, so this is not possible
until a complete conversion is performed. These incompatibilities are
due to differences in old BSD stdio and ANSI stdio, not to anything in
IRAF LIBC.
- Doug
Stephen Walton wrote on Jan 12, 2000
I want to thank Doug and Michelle for their clarifications. I for one am looking forward to this capability very much, especially the Fortran bindings. Now let's see, once I have the C VOS I can use SWIG to generate Python bindings on top of them...wow. Steve
Perry Greenfield wrote on Jan 12, 2000
> > I want to thank Doug and Michelle for their clarifications. I for one > am looking forward to this capability very much, especially the Fortran > bindings. > > Now let's see, once I have the C VOS I can use SWIG to generate Python > bindings on top of them...wow. > > Steve Since Steve mentioned it, some may be interested to know that we (STScI) are developing a Python CL for IRAF which will allow running IRAF tasks (and most CL scripts too) from Python in a convenient way. It supports the IRAF parameter mechanism, package structure, graphics, and image display interaction. Anyone interested in Python can contact me for more information. We hope to release an early beta on the timescale of a month or so. Perry Greenfield (perry@stsci.edu)
Michael C. B. Ashley wrote on Jan 13, 2000
Hi folks, On Wed, 12 Jan 2000, Perry Greenfield wrote: > Since Steve mentioned it, some may be interested to know that we (STScI) > are developing a Python CL for IRAF which will allow running IRAF tasks > (and most CL scripts too) from Python in a convenient way. This is a very interesting development. Any reason for choosing Python over Perl (which is much more widely known)? I must admit to getting overloaded with different scripting languages: I'm using IRAF scripting, bash, expect, Tcl, Perl, and now it looks like I need Python! I wrote a small script using expect to allow calling IRAF from UNIX scripts: it works by running an IRAF process in the background, and communicating with it via named pipes. You can send any IRAF command to it, just like with an interactive session. Since it keeps IRAF running, you don't need to reload packages and the environment each time you send a command. While it worked well under Linux, I couldn't get the pipes right with Solaris, so I didn't pursue the development. It would be good if the various groups working on IRAF scripting could coordinate and get a product out quickly. IMHO this is the main thing holding IRAF back from taking over the world :-). Regards, Michael -- Michael Ashley; Department of Astrophysics, University of NSW; For further information: "finger mcba@ugrad.phys.unsw.edu.au"
Stephen Walton wrote on Jan 24, 2000
"Michael C. B. Ashley" wrote:
> On Wed, 12 Jan 2000, Perry Greenfield wrote:
>
> > Since Steve mentioned it, some may be interested to know that we (STScI)
> > are developing a Python CL for IRAF which will allow running IRAF tasks
> > (and most CL scripts too) from Python in a convenient way.
>
> This is a very interesting development. Any reason for choosing Python
> over Perl (which is much more widely known)?
I don't presume to speak for Perry, but it is the opinion of Paul Dubois
(editor of the "Scientific Computing" department of _Computers in
Science and Engineering_ magazine) that Python is the best suited of the
Big Three scripting languages (Python, Perl, Tcl) for scientific work.
I've written a few short scripts in both Perl and Python and generally
prefer the latter, but admit to not being an expert (and to having sat
through too many Fortran vs. C debates 10 years ago to have much desire
to fire up another language war!).
> It would be good if the various groups working on IRAF scripting could
> coordinate and get a product out quickly. IMHO this is the main thing
> holding IRAF back from taking over the world :-).
Interesting thought. I've been able to do much of what I want in the
IRAF CL. The big drawback is that intermediate image results end up
being written as temporary files. I'd hope the Python CL will allow
something like:
>>> h = imopen("myfile.imh")
>>> image = h.pixels() # load pixel data into Python Numeric array
>>> image = Numeric.ceil(image + 0.5) # round real data
>>> fimage = FFT.fft(image) # take image FFT
This would be Way Cool!
--
Stephen Walton, Professor, Dept. of Physics & Astronomy, Cal State
Northridge
stephen.walton@csun.edu
Last post on Jan 24, 2000