Re: [Orbit-python-list] Updates

[Roland M. <ma...@ec...>]

Jason Tackaberry (2000-08-21 23:05:33 -0400) :

>    * Implemented preprocessing of IDL files at runtime to determine which
>      IDL files offer which modules.  Implications on performance are yet
>      to be determined.  This approach may not scale very well at all for
>      hundreds of IDL files.  It also could be broken in some cases; the
>      preprocessor is not a complete IDL parser, so it may not work 100%.
>      Time shall tell.  Uses the IDLPATH environment variable to get a
>      list of paths to scan, otherwise defaults to the current
>      directory.
>    * hook __import__ to automagically load IDL files discovered by the
>      processor that are required for the requested module
[...]
> The IDL directory preprocessor is a particularly interesting addition, and
> it remains to be seen if this approach won't completely flop.  For me, at
> least, it works pretty well, but my setup is somewhat limited (basically
> just GNOME with Bonobo).  On my system it takes about 0.30 seconds to
> preprocess 3 directories with about 50 IDL files, and 0.04 seconds once
> cached.

I'm not sure I think it's always a good idea to do it automagically.
I mean, yes, it can be handy, but I feel it would be preferable to
continue to specify the IDL file(s) to load.  I'm not sure about that,
but I think it's less risky to "load_idl (blah)" and then "import
mymodule".  Supposing there are several IDL files describing a
similarly named module...  Supposing there are a great many IDL files
and we only need one...  Supposing many things, I think that can lead
to breakage.  I don't really like the idea of ORBit-Python doing
things in my back.  On the other hand, I'm totally in favour of an
automatisation (does that word exist in English?) of things.  As I
said, I'm all for the "load_idl (blah)" then "import blahmod".  That
could also be a "preprocess_idl_dirs (blah)" then "import blahmod".

  Of course, you're the boss :-)

  On another point, I just scanned through src/process_idl.c, and it
appears you parse the IDL files by hand.  Well, why not, but you said
it yourself, that's not a complete IDL parser.  Why not use the libIDL
like in src/idl.c, with the appropriate tree_pre_func and
tree_post_func?

>    * Pass -D__ORBIT_IDL__ -D__BONOBO_COMPILATION to libIDL so that we can
>      load Bonobo IDLs

  Here again, I feel that could (should?) be optional arguments to
load_idl.  On the other hand, I don't know what these arguments do to
IDL_parse_filename, so they might be completely innocent.

>    * introduced more memory leaks, and probably more bugs.

  No memory leak seen from here for the first tests.  I haven't tried
the big one yet, since the module mappings have changed and I'll have
to check and fix where it broke.

  Ah, and I fixed the patch I had uploaded.  Now it works (well,
should work anyway).

  Have a nice day.

Roland.
-- 
Roland Mas

Qu'est-ce qui est jaune, qui pèse deux cents kilos et qui chante ?
Un sumotori qui a bu trop de saké.