There are 24 lines in /etc/passwd
User rlratzel is on line 21
This is the 4th line: lp:x:4:7:lp:/var/spool/lpd:
This is the 21st line: rlratzel:x:500:500:Rick L. Ratzel:/home/rlratzel:/bin/bash

Elmer allows developers to write code in Python and execute it in Tcl. The resulting Tcl interface to the Python code generated by Elmer is transparent to the Tcl user... Python calls appear as Tcl calls ( "foo( 1, "a" )" in Python appears as "foo 1 a" in Tcl, for example) and Python and Tcl data types are automatically mapped (Tcl lists are converted to Python lists, Python dictionaries are returned as Tcl associative arrays, etc.). Elmer also supports Python's "freeze" module, allowing a Python developer to deliver a single library consisting of several Python files "frozen" in to the Tcl application...no need to set PYTHONPATH or have Python source files accompanying the Tcl application.

Elmer also allows C programmers to use Python code...by specifying the C-mode option to Elmer, a C program can run the same Python code as shown in the Tcl example above, as if it was written in C...the C programmer need not know that the module was written in Python (or any other language for that matter), just like in the Tcl example above.

Elmer has been used in large software projects, where different teams wrote re-usable modules in different languages (namely, Python, Tcl, and C). Elmer has allowed the large number of Python modules written to be seamlessly used in Tcl and C programs without having to re-write them in the native languages.

Elmer allows various data types to pass between Python and Tcl (or C) as native types (when supported). For example, a Python dictionary of strings to lists-of-floats is automatically converted to a Tcl associative array of strings and lists-of-floats. A Tcl string is automatically converted to a Python string object...no special quoting required. Python objects are even handled and can be passed to other Python code through the Tcl interpreter.

Elmer allows developers to leverage the strengths of various languages without the restrictions of language barriers. Developers do not need to learn special APIs or access the internals of the language...all code appears native to the language of the application, even if not written in the host language. The intended interface for the Python module is preserved and not wrapped around obfuscating "eval" calls or other mechanisms which hinder readability and re-usability.

Although the core features of Elmer have gone unchanged for several years, and it has been successfully used in a large commercial project by many different kinds of developers, it is still considered beta. Your feedback is greatly appreciated!

A: Elmer is more analogous to swig than it is to critcl, I believe. Elmer allows you to use a python module in a tcl or C program, where the module's interface is native to the target language (tcl or C)...effectively allowing python to extend tcl or C. Elmer accomplishes this just like swig does: it generates a wrapper ("glue" code). Elmer also automatically converts the python data types to/from the target language's corresponding type, if supported (ie. python lists become tcl lists, a char* in C becomes a python string object, etc.). Swig allows you to extend java, perl, python, tcl, etc. with C or C++ by generating a wrapper for the C/C++ for use with the target language. critcl, if I understand it right, allows you to write C code inline with your tcl code, and compiles/links it on-the-fly...very interesting! Elmer requires you to have separate files for the python code which is to extend the C or tcl application, as well as a separate compilation step for the generated wrapper code (just like swig does).