Jul 10 1997
===========
jeremy checked in a few aesthetic changes.  nothing vital,
just want to clean out my working directory.
here are some random thoughts i had written down:
	-----------------------------------------------------------
	problems specific to my code:
	
	 - i would like to allow "operation" statements.
	
	 - the front end does syntax checks and most of the
	   semantic checks for us, but the back end may
	   impose extra semantic constraints.  currently i
	   do this in the "dump()" pass over the parse tree.
	   this is bad because semantic errors abort the
	   traversal of the parse tree, so the user is only
	   informed about the first error in the idl file,
	   so the user has to run the compiler as many times
	   as there are errors in the idl file.  very bad.
	   i will add a separate "verify()" pass, this
	   should not break anything.  i hope.
	
	general problems:
	
	 - the way "#include" directives are handled makes
	   it impossible to do things right.  the
	   preprocessing phase eliminates the explicit
	   information about what file #includes what.  some
	   of this info is reconstructed from the #line
	   directives, but you are limited to asking whether
	   the current syntax tree node was defined in the
	   main idl file or not.  this is not sufficient to
	   be able to generate the right #include directives
	   in the generated header files.
	
	 - and finally, the biggest flaw is that writing a
	   back end is just way too complicated.  the back
	   ends i have built each support a wide range of
	   applications.  the time (and hassle) invested was
	   worth it because we can use the compilers to
	   build many different apps.  but the shared
	   inventor library is complicated enough that i
	   wish i had an application-specific back end.
	   this won't happen, though, 'cause it's not worth
	   the investment.  if we could find an easier way
	   to specify the functionality of a back end, it
	   would make building complex applications easier.
	
	 - idl's integer types have a definite number of
	   bits each, but for pbio we really want to use
	   "c" semantics, i.e. the sizes are whatever is
	   right for the machine.  this would be a huge
	   change in idl semantics, one that i would
	   hesitate to recommend.
	
	=======================================================
	==== problems that have been remedied
	=======================================================
	
	 - the trouble with using sgi's compiler boils down
	   to a simple lexical difference: the gnu
	   preprocessor indicates __LINE__ and __FILE__
	   information by outputting a line of the form:
		# <linenumber> "<filename>"
	   where sgi uses:
		#line <linenumber> "<filename>"
	   the fix for this one is easy, and i will
	   (eventually) take care of it.
	
	 - speaking of config stuff... we really need to get
	   lex/yacc working on the various platforms, and
	   not rely on "you have to build those on this
	   particular type of machine".  i'm not sure
	   exactly what the source of this problem is.
	
	 - sunsoft's back end doesn't have classes for these
	   four syntax tree nodes: Decl, Type, ConcreteType,
	   and Scope.  at first it seems like you don't need
	   these because they are abstract nodes and never
	   show up in an actual syntax tree.  but that
	   doesn't fit with the way the complier is designed
	   (i.e. to build a back end, subclass the syntax
	   tree nodes and override the "dump()" method).  in
	   particular, it is really helpful to be able to
	   define your own subclass of the Scope node.  i
	   tried to add these nodes to my back end, but in
	   doing this i created an ambiguity problem: for
	   some reason the compiler can't resolve which
	   "BE_Scope::dump()" method is being invoked.  and
	   this confuses me greatly.
		*** this was not actually what the compiler
		was complaining about... it was the scope
		management stuff, which has been fixed.
	
	 - put pbio&xtde generated code in current directory.
	
	 - change default behavior from complain&abort to
	   warn&ignore.
	-----------------------------------------------------------

Sep 23 1996
===========
jeremy finally committed the back end for the pbio compiler.  mostly the
changes are localized to the subdirs be_generic/ and be_pbio/.  exceptions:
  ./Makefile.in, added ability to choose between back ends.
  ./fe_dynarray, had to hack the grammer to handle dynamic arrays.

May 25 1996
===========
jeremy cleaned up a few things:
- configure.in: changed UNKNOWNs to IRIXn
- be_classes.cc: commented out some unref'd variables, fixed nested /*/**/
- drv_main.cc: commented out unref'd variable
- drv_fork.cc: added #includes for prototypes of fork() and wait()
- drv_preproc.cc: added #includes for prototypes of fork() and wait()
- ast_argument.cc: direction_to_string return value, hopefully never used !!!
- ast_constant.cc: exprtype_to_string return value, hopefully never used !!!
- ast_constant.cc: only code exprtype_to_string if needed
- ast_expression.cc: marked some silly comparisons as "pointless"
- ast_expression.cc: gave other methods a default return, probably never used.

Apr 26 1996 (16:46:52)
===========

Now idl2c is solaris code.
I will process "context". This imply in:
- adding CORBA_Context paramenter (THIS I'VE ALREADY DONE!! NICE
SURPRISE) 
- adding this info for app description

Apr 26 1996 (14:07:30)
===========

I want to deal with "context" now. Actually the concept of context in
IDL is similar to the attribute list in OTL, so I just want to map one
into the other.

I think I will build this on Solaris so it runs faster. So I will now
change the idl_make_vars and recompile everything.



16/Feb/96
=========

** added #ifdef _IDLtoC_<hfilename> for the .h file being generated

** started attribute manipulation code generation. I added notes 
about this on idl2c.tex. I am stoping to work on this until Karsten
comes back and tell me what the deal is with this Utah's IDL to C
compiler that Mustaq mentioned a few hours ago.  


15/Feb/96
=========

******CHANGE in exception generation:
On pg 104 of the idl document we have information about how to
handle exception. There I noticed that "CORBA_expection_id" returns a
pointer to a string, and the example program dealing with exceptions
on page105 compares this value returned with the "defined" value for
the exception.  But so far I had generated an integer ... Now it
generates a string identifier.


** Changed the directory from CORBA/IDL/myCFE to COBS/IDLtoC.

** Put IDLtoC under CVS

** I dealt with teh problem of getting errors in "make fe", because
the new time stamps (resulting from CVS checkout) made lex/yacc run
again, and our lex/yaccs are not C++ capable, so the output was
different from the original one from SunSoft ... I had to copy the
original file on top of the ones.

** Corrected superflous ";" in be_attribute

** Added check on the output of fout (to make sure that we detect when
a file coudn't be open) 


14/fev/96
=========
I didn't write many notes here, but I did lot of work and got
things done about a week ago. I have the document be/idl2c.tex
explaining a lot of things. 

Today I did some tests:
- I tried to see if there were "local defined types" associated with
interfaces, since while generating translation for AST_interface I was
completely ignoring that part of its UTL_Scope. Test
idl_specs/teste.idl has a typedef inside an interface that generates a
local type definition: fortunately this local type is associated with
the root. This means that I don't have anything to change concerning
this.

- "Object" is a valid type, I tested its use as an argument, no
problem, the CORBA_Object translation is associated to it.

- Interfaces forwarded can be used in any other way the original
interface can be.

25/jan/96
=========

running an example:
	idl -v -d idl_specs/array.idl 


??/jan/96
=========
Changed RANLIB ...


 13/jan/96
=========
- I am changing idl_make_vars file in order to make the target SUNOS 4.x (the
default is Solaris 2.x
- I made CC being g++
