Free idl software for linux

Alma is a software with the following functionalities :
- Reads several sources (languages, models, ...),
- Helps to design for object-oriented modeling (definition of classes, relations, patterns, ...)
- Modifies the structure and the code
- Outputs new sources, documentation, diagrams, ...
It is designed for object-oriented modelisation (definition of classes and relations) and for migrating (help to convert) code written in old languages to newer ones. It meets two needs : having a simplified software modeling workshop for small projects and make easier rewritings, ports and encapsulation of non-OO code.
This tool will be usefull for developers who get a code and wish to integrate it in a new project, to rewrite a program in a new language, and for the conceptor/architect who will have the possibilities to declare and manipulate classes.
Alma is able t oread these sources:
- C/C++ (simplified, no preprocessor)
- Class (compiled with jikes)
- Fortran 77 (partial implementation)
- IDL (quite complete implementation, no preprocessor)
- Java (quite complete implementation)
- JavaP (result of javap)
- JSP (Java Server Page)
- MDL (files from Irrational Rose)
- Pascal (partial implementation)
- TLD (Taglib for JSP)
- XMI (XML Metadata Interchange, see the site, partial)
- XSD (XML Schema, see the site, partial)
Alma is able to generate source-code for these languages:
- Autotest (Source code for automatic testing)
- BDL
- C (headers and bodies)
- C++ (headers and bodies)
- Delphi (Object Pascal)
- Eiffel
- Gui (Editing JPanels)
- HTML documentation (similar to the javadoc tool)
- IDL (OMG, see the site)
- Java
- Lisp
- Natural (french)
- ODL (ODMG, see the site)
- Python
- Rebol (see the site)
- Resume
- Ruby (see the site)
- Sql (releases 2 and 3)
- SrcHtml
- Tom (see the site)
- Uml (only inheriting and relations diagrams)
- UXF (UML in a XML format, see the site)
- XMI
- XmlProto (Description of a GUI in XML, should be used with Prototype)
- XSD

Numarray provides array manipulation and computational capabilities similar to those found in IDL, Matlab, or Octave. Using numarray, it is possible to write many efficient numerical data processing applications directly in Python without using any C, C++ or Fortran code (as well as doing such analysis interactively within Python or PyRAF).
For algorithms that are not well suited for efficient computation using array facilities it is possible to write C functions (and eventually Fortran) that can read and write numarray arrays that can be called from Python.
Numarray is a re-implementation of an older Python array module called Numeric. In general its interface is very similar. It is mostly backward compatible and will be becoming more so in future releases. Numarray offers more capability than Numeric but is still behind Numeric in some areas:
numarray is efficient for large arrays (>20,000 elements) but is slower than Numeric for small arrays by a factor of 2 to 4.
numarray has a smaller selection of addon packages. numarray currently has ports of Numeric packages for linear algebra, random numbers, and fourier transforms. numarray has native packages for convolution and multi-dimensional image processing. Most Numeric extensions (C or Fortran) can be ported to numarray with minimal effort.
numarray is sufficiently developed to be useful for a number of applications, and is being used in the Hubble Space Telescope data processing pipeline (for the Advanced Camera for Surveys) and to develop the Cosmic Origins Spectrograph pipeline. PyFITS is also based on it. Most of STScIs future astronomical data processing applications will be built using its capabilities.
Numarray is being developed as an Open Source project on SourceForge from which the current development source code may be obtained. The Science Software Branch at STScI is leading this development effort.
STScI has settled on the matplotlib plotting package as the recommended 2-d data visualization tool for numarray data. While its support for numarray and Tkinter is now present, we are holding off a bit before recommending its use for all users. If you dont mind possible problems with installation or some holes in functionality it can be used now. We are in the process of improving the installation documentation for use with numarray.
Although matplotlib has its heritage in trying to emulate matlab plotting capabilities from Python, it does not require matlab. Currently the documentation is geared towards those more familiar with matlab, though many users will have no problem generating simple plots with it. It is still undergoing considerable development (by the original author, John Hunter, and with contributions by STScI and others) and we hope to fill the holes in functionality in the coming months. Nevertheless, it is capable of doing many things now.
Enhancements:
ENHANCEMENTS
- Speed improvement for numarray operators. The Python level hook mapping numarray operators onto universal functions has been moved down to C.
- Speed improvement for string-array comparisons, any(), all(). String correlation is ~10x faster.
- Better operation with py2exe to help it automatically detect the core numarray extensions to include in an installer.
- scipy newcore compatible lower case type names (e.g. int32 not Int32)
- scipy newcore dtype keyword and .dtypechar attribute.
BUGS FIXED / CLOSED
- 1323355 Apps fail with import_libnumarray
- 1315212 Infinite loop converting some scalar strings into a list
- 1298916 rank-0 tostring() broken
- 1297948 records.array fails to create empty fields
- 1286291 import sys missing from array_persist.py
- 1286168 Generic sequences in ``strings.array()``
- 1236392 Outdated web link in announcements
- 1235219 LinearAlgebraError not imported in linear_algebra

loc project provides the capability to count source and comment lines in multiple languages, currently including C/C++, Matlab/Octave, IDL, Java, Lisp, , Perl, PHP, Python, Fortran, SAS, shell, SQL, and Tcl/Expect.
Multiple files can be scanned, with recusion through subdirectories, and the grand total counts will also be given.
This program requires an ANSI C (1989 or 1999) compiler and a POSIX-compatible system, but should port easily to any conforming system.
The Makefile is configured to use gcc, to install the software in /usr/local/{bin,man}, and to use the native install program. If these are not suitable, modify the Makefile as needed.
Installation:
1. Unpack the tarball.
2. Configure the Makefile if necessary.
3. Run "make".
4. Run "make install" as root.
Enhancements:
- Support for several new languages was added.

XCOM project is a system designed to support component based programming in Linux. Although the system primarily targets Linux other POSIX supporting operating systems and Win32 class operating systems are planned to be supported.
The following design goals are followed in making the current system:
- Binary interface standard
- Simplicity and ease of use
- Good C++ support
- Portability
Main features:
- Specialized IDL compiler generating C++ code.
- In-process components.
- Embedded metadata.
- Most of the common numeric data types.
- Narrow and wide string types.
- array, sequence, and struct types.
- Error reporting via exceptions.
The IDL compiler generates C++ code which conforms to the binary standard of XCOM. When the generated code is compiled its binary layout conforms to the XCOMs binary format. Most notably, other component systems uses virtual functions to implement this kind of functionality, but in XCOM a mix of templates and inheritance is used to provide a similar mechanism without using virtual functions because the mechanisms used for implementing virtual function mechanism may change from compiler to compiler. Also the binary format rules of the XCOM is designed to be not overly C++ oriented and not prohibit implementing remoting in the future.
The generated C++ code permits the use of the system without delving to the binary details, such as reference counting and memory management. In most of the scenarios all of these can be handled behind the scenes.
Error reporting via exceptions are also supported natively provided only the IDL defined exception objects are allowed to propagate through interface methods. Inheritance between exception types are also supported in order to support complex usage scenarios.
Enhancements:
- The project has been revived.
- It is compatible with new GCC versions, and has switched to the CMake build system.

Open Office Software Development Kit is an add-on for OpenOffice suite.
It provides the necessary tools and documentation for programming the OpenOffice.org APIs and creating own extensions (UNO components) for OpenOffice.org.
The highlight of the SDK is the 900-page Developers Guide. This comprehensive guide provides a detailed description of the OpenOffice.org API concepts, the OpenOffice.org UNO component model and how to use the API in the context of the different application areas. At the close of each chapter, there is at least one example that demonstrates how to use a specific API.
Developers who are new to OpenOffice.org will also find the OpenOffice.org developer page useful.
Main features:
- 900-page Developers Guide (HTML + PDF version)
- XML file format specification
- IDL reference with cross references to the Developers Guide and vice versa
- C/C++ and Java UNO reference documentation
- development and deployment tools
- code samples for Java, C++, OpenOffice.org Basic and OLE
- easy-to-use build environment for the included samples

Gnome Devtool Libraries project contains components and libraries that are intended to be shared between GNOME development tools, including gnome-debug,
gnome-build, and anjuta2.

The current pieces of GDL include:

- A symbol browser bonobo component (symbol-browser-control).

- A docking widget (gdl).

- A utility library that also contains the stubs and skels for the symbol browser and text editor components (gdl, idl).

Discussion of GDL development takes place on the gnome-devtools@gnome.org
mailing list and on #devel-apps at irc.gnome.org.

GDL is licensed under the terms of the GPL.

Installation:

The simplest way to compile this package is:

1. `cd to the directory containing the packages source code and type `./configure to configure the package for your system. If youre using `csh on an old version of System V, you might need to type `sh ./configure instead to prevent `csh from trying to execute `configure itself.

Running `configure takes awhile. While running, it prints some messages telling which features it is checking for.

2. Type `make to compile the package.

3. Optionally, type `make check to run any self-tests that come with the package.

4. Type `make install to install the programs and any data files and documentation.

5. You can remove the program binaries and object files from the source code directory by typing `make clean. To also remove the files that `configure created (so you can compile the package for a different kind of computer), type `make distclean. There is also a `make maintainer-clean target, but that is intended mainly for the packages developers. If you use it, you may have to get all sorts of other programs in order to regenerate files that came with the distribution.

Automated support for compound RPC calls is a project which augments RPCGEN to support NFSv4-style compound procedures.

NFSv4 specifies that the RPC calls be batched into a "compound" call. There is no support for this in RPCGEN.

By rearranging the ONC IDL for NFSv4 into AutoGen definitions, these templates will emit the original IDL *plus* all the code to package, send, distribute, collect, return, and dispatch the results.

The distributed program author merely needs to call and supply server procedures for the routines specified in the IDL.

Templates for these calls and service routines is provided, too. The NFSv4 definitions are included.

CORBA::omniORB is a Perl module implementing CORBA 2.x via omniORB.

SYNOPSIS

use CORBA:::omniORB ids => [ IDL:Account/Account:1.0 => undef,
IDL:Account/Counter:1.0 => undef ];

The omniORB module is a Perl interface to the omniORB ORB. It is meant, in the spirit of omniORB, to be a clean, simple, system, at the expense of speed, if necessary.

Arguments to use omniORB

Arguments in the form of key value pairs can be given after the use CORBA::omniORB statement.

ids

The value of the argument is a array reference which contains pairs of the form:

REPOID => FALLBACK_IDL_FILE

REPOID is the repository id of an interface to pre-load. FALLBACK_IDL_FILE is the name of an IDL file to load the interface from if it is not found in the interface repository. This capability is not yet implemented.