[pyorbit] pyIDL

[James Henstridge]

Actually I may have broken some stuff (I was not sure how much of the
stuff in the misc directory was working, since it looked a bit corrupted).
The change in libIDLmodule.c was the following:

--- libIDLmodule.c      1999/09/10 07:42:31     1.1
+++ libIDLmodule.c      1999/09/13 14:08:13     1.2
@@ -292,8 +292,7 @@
                IDLtree2Object(self->tree->u.idl_attr_dcl.param_type_spec),
                IDLtree2Object(self->tree->u.idl_attr_dcl.simple_declarations));
        case IDLN_OP_DCL:
-               return Py_BuildValue("(iiNNNNN)",
-                       (int) self->tree->u.idl_op_dcl.f_noscript,
+               return Py_BuildValue("(iNNNNN)",
                        (int) self->tree->u.idl_op_dcl.f_oneway,
                        IDLtree2Object(self->tree->u.idl_op_dcl.op_type_spec),
                        IDLtree2Object(self->tree->u.idl_op_dcl.ident),

It would probably cause problems for anything which was using the
resulting tuple.  We could put in a dummy value into the tuple, but it may
be a bit cleaner to change pyIDL a bit.  You would probably know best
what this change would affect.

James.

--
Email: james at daa.com.au
WWW:   http://www.daa.com.au/~james/


On Tue, 14 Sep 1999, Michael Robinson wrote:

> James Henstridge <james at daa.com.au> writes:
> >It was the f_noscript attribute of the _IDL_OP_DCL structure.  The start
> >of the structure in the IDL.h header file looks like the following:
> >
> >struct _IDL_OP_DCL {
> >        unsigned __f_noscript           : 1;    /* Deprecated */
> 
> I didn't use that for anything, so presumably nothing is broken by removing
> it (unless weird struct member alignment issues are involved).
> 
> Has anybody gotten the py-idl script to compile any sample IDL?
> 
> 	-Michael Robinson