Omegahat FAQ

Installation

Compilation

Could you explain what a jweb file is and what reads and generates these files. (thanks to John Wiggins.) Good question. A .jweb file is my extension for a file containing Java source that is written in what is called a "literate programming" style, specifically designed to be processed by noweb. The idea of literate programming is to write the code for the reader, not the computer. This means that we mix "chunks" of TeX/LaTeX that provide details of the code targeted at the humar reader with code segments. As well as making the code more comprehensible and easier to return to, it also tends to keep documentation more closely coupled with code (e.g. number and type of arguments, etc.). The file is processed by the noweb tools to produce either the code (via a tangle operation) or TeX code that can be turned into nicely formatted and typeset Postscript, PDF, etc. So, the .jweb files are created in an editor by the developer (me for example). Then, in e.g. Omegahat, the makefiles take care of converting .jweb files to .java files and from these compile the .class files. The noweb tools are freely available from Norman Ramsey's Web pages. http://www.eecs.harvard.edu/~nr/noweb/ While we have used noweb for quite some time, it does have deficiencies. I am currently gradually developing a style and some tools which use XML for literate programming. Why are there so many warnings during the compilation? The warnings you should see fall into two categories: when building grammar files via Antlr, and deprecation warning messages from the Java compiler. The latter you can ignore (or correct) and are due to some code being developed for the early Java1.1 releases with an API that has since been enhanced by Sun. The messages from Antlr will be fixed when we finalize the language. At present, I don't think they should alarm us, but I welcome opinions. When I attempt to run make in $OMEGA_HOME/Config I get an error about GNUmakefile.rules. What is this and how do I fix it? To fix it, re-run make. This is an incremental build problem where the makefile needs other makefiles that it will itself build. You may need to run make three times! I find it more natural to have the class files in a different directory than the source. How can I do this? You can use the -d flag for the javac compiler in Sun's JDK. This specifies a top-level directory into which the packages' class files are written. You can have this specified for each invocation of javac by editing the local.config file in the $OMEGA_HOMEConfig/ directory and appending -d directory to the value of JCFLAGS For example, JCFLAGS= -g -d /tmp/ClassFiles An alternative is to use the -sourcepath flag. In spite of the ease with which this can be done, I think it complicates matters. Firstly, one has to add this directory to one's CLASSPATH environment variable. Secondly, the dependencies in the compilation are more complicated and can be wrong. At best this means lengthier compilation times when files are recompiled unnecessarily. At worst, one can not recopmile class files when the source is more recent and end up debugging for a long time. The benefit of not having the class files show in listings of source directories can be handled using correct filters built into things like dired, completions in shell expansions, etc. What about using another compiler such as Jikes or Guavac? The basic hooks are available for specifying a different compiler. Basically, in the file local.config, provide a value for JAVAC identifying the executable to use for a compiler. For many of the compilers, you will also need to specify where the core Java classes can be found. For example, to use Jikes along with the Kaffe classes, I use the settings JAVAC=/usr/local/src/Jikes/jikes/src/jikes JAVA_CORE_CLASSES=/usr/local/share/kaffe/Klasses.jar We also need a VM so as to build the grammar using the Antlr parser generator. So specify a value for the JAVA variable. Using the Jikes/Kaffe setup, I get warnings about the .jar files not being "valid zip file"s. So, I simply unjar them and specify values in the local.config file for the different places to find the class packages (i.e. remove the jar fule use.) JAS=${OMEGA_HOME}/Jars Repeat this for SWING, ANTLR JHELP, JAS Proceeding, I get several warnings about the paintBoder method in the Swing JComponent class not overriding the corresponding method in Component. The Environment, Interfaces, Models and Numerics modules all build (with the same errors in Numerics). As for running, of course one needs a JVM. Using JDK1.2, I get problems with the prompt - the second time it is evaluated it turns into the expression itself rather than the result of the expression. But basic expressions work. x = 1 y = 3 x+y classLists().elementAt(0).size() So far, we have only successfully used the Sun JDK. It would be good to hear from people who have used this or any other setup on Windows. To compile Omegahat, you need to build the grammar, so you need a JVM. What about using other Virtual Machines such as Japhar and Kaffe: Good question. A .jweb file is my extension for a file containing Java source that is written in what is called a "literate programming" style, specifically designed to be processed by noweb. The idea of literate programming is to write the code for the reader, not the computer. This means that we mix "chunks"

of TeX/LaTeX that provide details of the code targeted at the humar reader with
code segments.
As well as making the code more comprehensible and easier to return to, it also tends to keep documentation more closely coupled with code (e.g. number and type of arguments, etc.). The file is processed by the noweb tools to produce either the code (via a tangle operation) or TeX code that can be turned into nicely formatted and typeset Postscript, PDF, etc.
So, the .jweb files are created in an editor by the developer (me for example). Then, in e.g. Omegahat, the makefiles take care of converting .jweb files to .java files and from these compile the .class files.
The noweb tools are freely available from Norman Ramsey's Web pages. http://www.eecs.harvard.edu/~nr/noweb/
While we have used noweb for quite some time, it does have deficiencies. I am currently gradually developing a style and some tools which use XML for literate programming.
Why are there so many warnings during the compilation? The warnings you should see fall into two categories: when building grammar files via Antlr, and deprecation warning messages from the Java compiler. The latter you can ignore (or correct) and are due to some code being developed for the early Java1.1 releases with an API that has since been enhanced by Sun. The messages from Antlr will be fixed when we finalize the language. At present, I don't think they should alarm us, but I welcome opinions. When I attempt to run make in $OMEGA_HOME/Config I get an error about GNUmakefile.rules. What is this and how do I fix it? To fix it, re-run make. This is an incremental build problem where the makefile needs other makefiles that it will itself build. You may need to run make three times! I find it more natural to have the class files in a different directory than the source. How can I do this? You can use the -d flag for the javac compiler in Sun's JDK. This specifies a top-level directory into which the packages' class files are written. You can have this specified for each invocation of javac by editing the local.config file in the $OMEGA_HOMEConfig/ directory and appending -d directory to the value of JCFLAGS For example, JCFLAGS= -g -d /tmp/ClassFiles An alternative is to use the -sourcepath flag. In spite of the ease with which this can be done, I think it complicates matters. Firstly, one has to add this directory to one's CLASSPATH environment variable. Secondly, the dependencies in the compilation are more complicated and can be wrong. At best this means lengthier compilation times when files are recompiled unnecessarily. At worst, one can not recopmile class files when the source is more recent and end up debugging for a long time. The benefit of not having the class files show in listings of source directories can be handled using correct filters built into things like dired, completions in shell expansions, etc. What about using another compiler such as Jikes or Guavac? The basic hooks are available for specifying a different compiler. Basically, in the file local.config, provide a value for JAVAC identifying the executable to use for a compiler. For many of the compilers, you will also need to specify where the core Java classes can be found. For example, to use Jikes along with the Kaffe classes, I use the settings JAVAC=/usr/local/src/Jikes/jikes/src/jikes JAVA_CORE_CLASSES=/usr/local/share/kaffe/Klasses.jar We also need a VM so as to build the grammar using the Antlr parser generator. So specify a value for the JAVA variable. Using the Jikes/Kaffe setup, I get warnings about the .jar files not being "valid zip file"s. So, I simply unjar them and specify values in the local.config file for the different places to find the class packages (i.e. remove the jar fule use.) JAS=${OMEGA_HOME}/Jars Repeat this for SWING, ANTLR JHELP, JAS Proceeding, I get several warnings about the paintBoder method in the Swing JComponent class not overriding the corresponding method in Component. The Environment, Interfaces, Models and Numerics modules all build (with the same errors in Numerics). As for running, of course one needs a JVM. Using JDK1.2, I get problems with the prompt - the second time it is evaluated it turns into the expression itself rather than the result of the expression. But basic expressions work. x = 1 y = 3 x+y classLists().elementAt(0).size() So far, we have only successfully used the Sun JDK. It would be good to hear from people who have used this or any other setup on Windows. To compile Omegahat, you need to build the grammar, so you need a JVM. What about using other Virtual Machines such as Japhar and Kaffe: The warnings you should see fall into two categories: when building grammar files via Antlr, and deprecation warning messages from the Java compiler. The latter you can ignore (or correct) and are due to some code being developed for the early Java1.1 releases with an API that has since been enhanced by Sun.
The messages from Antlr will be fixed when we finalize the language. At present, I don't think they should alarm us, but I welcome opinions.
When I attempt to run make in $OMEGA_HOME/Config I get an error about GNUmakefile.rules. What is this and how do I fix it? To fix it, re-run make. This is an incremental build problem where the makefile needs other makefiles that it will itself build. You may need to run make three times! I find it more natural to have the class files in a different directory than the source. How can I do this? You can use the -d flag for the javac compiler in Sun's JDK. This specifies a top-level directory into which the packages' class files are written. You can have this specified for each invocation of javac by editing the local.config file in the $OMEGA_HOMEConfig/ directory and appending -d directory to the value of JCFLAGS For example, JCFLAGS= -g -d /tmp/ClassFiles An alternative is to use the -sourcepath flag. In spite of the ease with which this can be done, I think it complicates matters. Firstly, one has to add this directory to one's CLASSPATH environment variable. Secondly, the dependencies in the compilation are more complicated and can be wrong. At best this means lengthier compilation times when files are recompiled unnecessarily. At worst, one can not recopmile class files when the source is more recent and end up debugging for a long time. The benefit of not having the class files show in listings of source directories can be handled using correct filters built into things like dired, completions in shell expansions, etc. What about using another compiler such as Jikes or Guavac? The basic hooks are available for specifying a different compiler. Basically, in the file local.config, provide a value for JAVAC identifying the executable to use for a compiler. For many of the compilers, you will also need to specify where the core Java classes can be found. For example, to use Jikes along with the Kaffe classes, I use the settings JAVAC=/usr/local/src/Jikes/jikes/src/jikes JAVA_CORE_CLASSES=/usr/local/share/kaffe/Klasses.jar We also need a VM so as to build the grammar using the Antlr parser generator. So specify a value for the JAVA variable. Using the Jikes/Kaffe setup, I get warnings about the .jar files not being "valid zip file"s. So, I simply unjar them and specify values in the local.config file for the different places to find the class packages (i.e. remove the jar fule use.) JAS=${OMEGA_HOME}/Jars Repeat this for SWING, ANTLR JHELP, JAS Proceeding, I get several warnings about the paintBoder method in the Swing JComponent class not overriding the corresponding method in Component. The Environment, Interfaces, Models and Numerics modules all build (with the same errors in Numerics). As for running, of course one needs a JVM. Using JDK1.2, I get problems with the prompt - the second time it is evaluated it turns into the expression itself rather than the result of the expression. But basic expressions work. x = 1 y = 3 x+y classLists().elementAt(0).size() So far, we have only successfully used the Sun JDK. It would be good to hear from people who have used this or any other setup on Windows. To compile Omegahat, you need to build the grammar, so you need a JVM. What about using other Virtual Machines such as Japhar and Kaffe: To fix it, re-run make. This is an incremental build problem where the makefile needs other makefiles that it will itself build. You may need to run make three times!
I find it more natural to have the class files in a different directory than the source. How can I do this? You can use the -d flag for the javac compiler in Sun's JDK. This specifies a top-level directory into which the packages' class files are written. You can have this specified for each invocation of javac by editing the local.config file in the $OMEGA_HOMEConfig/ directory and appending -d directory to the value of JCFLAGS For example, JCFLAGS= -g -d /tmp/ClassFiles An alternative is to use the -sourcepath flag. In spite of the ease with which this can be done, I think it complicates matters. Firstly, one has to add this directory to one's CLASSPATH environment variable. Secondly, the dependencies in the compilation are more complicated and can be wrong. At best this means lengthier compilation times when files are recompiled unnecessarily. At worst, one can not recopmile class files when the source is more recent and end up debugging for a long time. The benefit of not having the class files show in listings of source directories can be handled using correct filters built into things like dired, completions in shell expansions, etc. What about using another compiler such as Jikes or Guavac? The basic hooks are available for specifying a different compiler. Basically, in the file local.config, provide a value for JAVAC identifying the executable to use for a compiler. For many of the compilers, you will also need to specify where the core Java classes can be found. For example, to use Jikes along with the Kaffe classes, I use the settings JAVAC=/usr/local/src/Jikes/jikes/src/jikes JAVA_CORE_CLASSES=/usr/local/share/kaffe/Klasses.jar We also need a VM so as to build the grammar using the Antlr parser generator. So specify a value for the JAVA variable. Using the Jikes/Kaffe setup, I get warnings about the .jar files not being "valid zip file"s. So, I simply unjar them and specify values in the local.config file for the different places to find the class packages (i.e. remove the jar fule use.) JAS=${OMEGA_HOME}/Jars Repeat this for SWING, ANTLR JHELP, JAS Proceeding, I get several warnings about the paintBoder method in the Swing JComponent class not overriding the corresponding method in Component. The Environment, Interfaces, Models and Numerics modules all build (with the same errors in Numerics). As for running, of course one needs a JVM. Using JDK1.2, I get problems with the prompt - the second time it is evaluated it turns into the expression itself rather than the result of the expression. But basic expressions work. x = 1 y = 3 x+y classLists().elementAt(0).size() So far, we have only successfully used the Sun JDK. It would be good to hear from people who have used this or any other setup on Windows. To compile Omegahat, you need to build the grammar, so you need a JVM. What about using other Virtual Machines such as Japhar and Kaffe: You can use the -d flag for the javac compiler in Sun's JDK. This specifies a top-level directory into which the packages' class files are written. You can have this specified for each invocation of javac by editing the local.config file in the $OMEGA_HOMEConfig/ directory and appending -d directory to the value of JCFLAGS For example,
JCFLAGS= -g -d /tmp/ClassFiles

An alternative is to use the -sourcepath flag.
In spite of the ease with which this can be done, I think it complicates matters. Firstly, one has to add this directory to one's CLASSPATH environment variable. Secondly, the dependencies in the compilation are more complicated and can be wrong. At best this means lengthier compilation times when files are recompiled unnecessarily. At worst, one can not recopmile class files when the source is more recent and end up debugging for a long time. The benefit of not having the class files show in listings of source directories can be handled using correct filters built into things like dired, completions in shell expansions, etc.
What about using another compiler such as Jikes or Guavac? The basic hooks are available for specifying a different compiler. Basically, in the file local.config, provide a value for JAVAC identifying the executable to use for a compiler. For many of the compilers, you will also need to specify where the core Java classes can be found. For example, to use Jikes along with the Kaffe classes, I use the settings JAVAC=/usr/local/src/Jikes/jikes/src/jikes JAVA_CORE_CLASSES=/usr/local/share/kaffe/Klasses.jar We also need a VM so as to build the grammar using the Antlr parser generator. So specify a value for the JAVA variable. Using the Jikes/Kaffe setup, I get warnings about the .jar files not being "valid zip file"s. So, I simply unjar them and specify values in the local.config file for the different places to find the class packages (i.e. remove the jar fule use.) JAS=${OMEGA_HOME}/Jars Repeat this for SWING, ANTLR JHELP, JAS Proceeding, I get several warnings about the paintBoder method in the Swing JComponent class not overriding the corresponding method in Component. The Environment, Interfaces, Models and Numerics modules all build (with the same errors in Numerics). As for running, of course one needs a JVM. Using JDK1.2, I get problems with the prompt - the second time it is evaluated it turns into the expression itself rather than the result of the expression. But basic expressions work. x = 1 y = 3 x+y classLists().elementAt(0).size() So far, we have only successfully used the Sun JDK. It would be good to hear from people who have used this or any other setup on Windows. To compile Omegahat, you need to build the grammar, so you need a JVM. What about using other Virtual Machines such as Japhar and Kaffe: The basic hooks are available for specifying a different compiler. Basically, in the file local.config, provide a value for JAVAC identifying the executable to use for a compiler. For many of the compilers, you will also need to specify where the core Java classes can be found.
For example, to use Jikes along with the Kaffe classes, I use the settings
JAVAC=/usr/local/src/Jikes/jikes/src/jikes JAVA_CORE_CLASSES=/usr/local/share/kaffe/Klasses.jar
We also need a VM so as to build the grammar using the Antlr parser generator. So specify a value for the JAVA variable.
Using the Jikes/Kaffe setup, I get warnings about the .jar files not being "valid zip file"s. So, I simply unjar them and specify values in the local.config file for the different places to find the class packages (i.e. remove the jar fule use.)
JAS=${OMEGA_HOME}/Jars
Repeat this for SWING, ANTLR JHELP, JAS
Proceeding, I get several warnings about the paintBoder method in the Swing JComponent class not overriding the corresponding method in Component.
The Environment, Interfaces, Models and Numerics modules all build (with the same errors in Numerics).
As for running, of course one needs a JVM. Using JDK1.2, I get problems with the prompt - the second time it is evaluated it turns into the expression itself rather than the result of the expression. But basic expressions work.
x = 1 y = 3 x+y classLists().elementAt(0).size()

So far, we have only successfully used the Sun JDK. It would be good to hear from people who have used this or any other setup on Windows.
To compile Omegahat, you need to build the grammar, so you need a JVM.
What about using other Virtual Machines such as Japhar and Kaffe

When I compile the CORBA C++ code, I get lots of errors about s_object and/or SEXP. How do I fix this?

This indicates that you don't have either SHOME or RHOME set. This should be set to the installation directory of the appropriate package. You can find these by running the application and issuing the command

getenv("SHOME")
       or getenv("R_HOME") in the case of R.
% R
 >  getenv("R_HOME")
                    R_HOME 
 "/home/duncan/Projects/R/R" 

  So you can set R_HOME to this and restart the compilation.


 setenv R_HOME /home/duncan/Projects/R/R




Documentation

  
    
When attempting to build the HTML files using
	JavaDoc, I get warnings of the form:
	No package, class, or source file found named

	
    
 The problem usually lies in the fact that there are no
	Java files in those directories. In the Omegahat source
	 this means that the Java files have not been created from
	their noweb (.jweb) counterparts. 
To fix this, first make the target java and then JavaDocs.
That is
  make java JavaDocs
	
  
 



Runtime Behavior, Errors and Warnings



  
    
    
       When I compile a Java class, some methods do not appear to be
	in it.
	
    
	First of all, check this via the command
	MyClass.method
	
	and see what you get.
	
A common cause of this is not recompiling.
Remove the .class file and recompile to ensure it is made.


A more subtle cause	of this error arises when using
noweb. Sometimes one forgets to reference the chunk defining
the method(s) in the class definition.
Check that there is a reference!
  
  
   When I run, I get errors about
      legitimate classes, something of the form
No class def errjava.lang.NoClassDefFoundError: Models/lib/Language/FormulaParsing (wrong name: org/omegahat/Models/lib/Language/FormulaParsing)
      
      
   This happens when the working directory is within the omegahat
      source tree and the
      CLASSPATH variable contains an element
      .
      Basically, the internal Java class loader finds a reference
      to the file, say,
      Models/lib/Language/FormulaParsing.class
      but  this is actually the class
      org.omegahat.Models.lib.Language.FormulaParsing.
      and so there is a mismatch. This is the error message.

  

   When I run the script, nothing happens
       except I get the message
        omegahat: -classpath:  command not found
      
   This is simply an incomplete installation.
       Change directory to the
       $OMEGA_HOME/Config
          and issue the command
        make  runConfig
      
  

   When I run the omegahat script
       I get the message
Warning:: org.omegahat.Environment.Tools.ClassList.ClassList:: `/usr/jdk1.2/jre/classes' is neither a directory or an archiveclass java.io.File:      
      


    This is because the Java script is inserting that entry into
        the default classpath. We take all the elements of the classpath
        and process them. We warn when an element does not exist
        since it may be a mistake in the user's classpath specification
        and may lead to some things not working in the session.
        So nothing to worry about.

  

  
       Why is the startup time for an Omegahat session so long?
       
   Simple reason is that we are reading lots of files.
       To provide flexibility, we run a minimal main()
       Java method that arranges to read Omegahat scripts which
       construct the prompt & input reader, the evaluator, etc.
       Secondly, we build an entire list of all the class names
       in the classpath elements. This requires reading numerous
       directories and Jar files. You can simplify this by
       running Omegahat within a directory that has few or
       no sub-directories.

      
       There is a mechanism to read serialized versions of the tables
       that are computed just a single time. These tables are not
       currently in the distribution.
  

   How do get the full Java error messages?
   When an error occurs in an Omegahat command,
       a very simple error message is displayed and a stack
       trace of the Omegahat expressions is displayed in attempt
       to identify the particular sub-expression that caused
       the problem. (We will add more elaborate debuggers
       as time allows. The design is there, just not the implementation.)
       However, if you want to see the real Java stack trace,
       you can change the default error handler.
       The Omegahat command
              options().remove("errorHandler")
      
       can be invoked before the first error handler is
       created. (I do this in the script
          $HOME/.omegahatrc.)
       Alternatively, if you want to clear the current error
       handler, you must also
       invoke the command
              errorHandler(null)
      

  

   How do I arrange for Omegahat to show more than the first 5
       elements
       and the last 3 elements of a collection (Vector, array, etc.)
       when they are displayed?

   This is controlled by the currently active output
      filter associated with the evaluator, accessible
       via the command
                  output()
       .
       By default, this is an object of class
      BasicTaskDisplay.
      (Use the command output().getClass() to check this.)
       This allows one to specify values for the number of initial and
      end elements of the collection that are shown.
       You can display the first k values
      with a command
              output().below(k)
      
      This remains in effect until it is explicitly changed.

  

   It would be nice to have a particular action performed each
       time I start an Omegahat session.
       How do I do this?
   Add the appropriate commands for the action to the file
       $HOME/.omgahatrc
       You can also use this to set properties that you want to
       override without changing the default properties file
       OmegaOptions.

  

   When I source a file, I cannot use environment variables, e.g
        source("$HOME/.omegahatrc")         

   Well, environment variables are not directly accessible from within
      the JVM and nor do they make an enormous amount of sense
      in the context of a portable, applet-capable environment.
       However, it is possible to add C code linked with JNI to get
      access to these. See also Signals.
      
      The answer to a different but related question is
      to consider using the
      FileLocator class.
      This allows one to register certain directories, jar files, etc.
      in which files can be located.
       The default initialization of the Omegahat environment
       adds
      

      

  

   It would be nice to be able to test a class,
       recompile and reload it. Why can't I do this?
   This is a "feature" of Java, as I understand the JVM
      specification. It is in the interest of security.
      It is not clear how one would handle objects
      in the system that were created with the old class
      definition, given that it no longer existed.
      It is of course possible to come up with different
      naming schemes, etc. that are hidden from the user.
      We'll see what we can do with the ClassLoader
      class in Java.
      
      The best we can offer currently is to allow you to
      recompile a class before it is first loaded, but
      after the session has been started.


  

  

      Where are the mathematical functions such as
       log, sin, etc?
      
  
       Well, just as we do not need any Omegahat data structures
      because we can directly use those in Java, we do not need
      to provide these mathematical functions.
      One can invoke them as static methods of the class
      Math.
      For example,
          Math.log(10)
    Math.sin(Math.PI/2)
      
      
       Rather than having to explicitly type the Math.
      prefix, one can register this class as a source of "functions".
      
       addFunctionTable(Math)
      
      Then we invoke the calls above as
             log(10)
       sin(PI/2)
      
      We can also register objects which provide non-static methods
      with data potentially cached across calls.
      See addFunctionTable()

  

  
       
       I get warning messages like the following:
      No class def errjava.lang.NoClassDefFoundError: Test/org/omegahat/Environment/IO/PromptSource (wrong name: org/omegahat/Environment/IO/PromptSource)
No class def errjava.lang.NoClassDefFoundError: ClassFiles/org/omegahat/Environment/IO/PromptSource (wrong name: org/omegahat/Environment/IO/PromptSource)
No class def errjava.lang.NoClassDefFoundError: Test/org/omegahat/Environment/IO/PromptSource (wrong name: org/omegahat/Environment/IO/PromptSource)

      
  
      This is caused by the way we resolve classes and build the
      entire list of all classes in each element of the
      classpath (and locally dynamically added classpath elements
      within the session).
      The example resuts from putting the directory /tmp/
       in the classpath when the Omegahat classes are themselves
       located in /tmp/Test/.
      Thus when we are looking for the class PromptSource, we
      find it first in the element /tmp/
      as the file
      /tmp/Test/org/omegahat/Environment/IO/PromptSource.class
      and when we try to load it, we find that the class contained
      in this file is not
      tmp.Test.org.omegahat.Environment.IO.PromptSource
      Hence the warning about the wrong name.
      
      A general practice is to ensure that these directories
      containing  classes do not contain other  packages nested within
      them.
      



  

   When I hit Ctrl-C (on Unix) to interrupt a task,
       the Omegahat session terminates. Can this be fixed?
  

      
       Kevin Hester
      has implemented the basic facility to do this with JNI code.
    The class 
      SignallableEvaluator
      and 
      UserLevelSignalHandler
      provide a framework (that used to work) for this.
      A simple way to install this is , to grab the code
      from Kevin Hester's site and compile it and install
       it in $OMEGA_HOME/lib
      (assuming your LD_LIBRARY_PATH variable includes this).
      

       There are still "interesting" issues about threads, evaluation,
      etc.




Duncan Temple Lang
<duncan@research.bell-labs.com>

Last modified: Wed Jan 31 06:54:11 EST 2001