[Dynamite] wiki back (hurray)

[Ian Holmes]

On Tue, 21 Mar 2000, Guy Slater wrote:

> Ian,

> I've had an initial look at this and it looks very cool indeed
> - this should save weeks.

Thanks.

> I can't really comment on the perl, but the output looks good.
> (BTW, it hangs on adhah@sanger (perl 5.004_04),
>  but was ok on ics-linux2 (perl 5.005_03) - no idea why).

Ulp. I just tried it, did it loop on this:

	Use of uninitialized value at ./idlstubs.pl line 226.

I've fixed this (& two related bugs) now, interesting that .000_09
revisions make that much difference (I have 5.005_03).

I think it works now. It's in ~ihh/Telegraph/idlstubs.pl on adnah.

Yes the perl is pretty scary, but basically it

  (1) preprocesses the IDL file into a single whitespace-stripped
      string, with an array of comments (one for each char in the
      string)

  (2) builds a parse tree for the stripped IDL string

  (3) prints output to a layout structure that is designed
      to organise text associated with nodes in a tree

It would be pretty easy to chop and change the program's output around
if you had any requests. I've been doing this quite a lot already.

> Is Euclid another Berkeley ref ?

Yes - it's the street that runs north off campus (Telegraph is south).

> What is the euclid_defs.h file for ?

For all our central #define's, typedefs & mappings to GLib.

> The main thing that strikes me looking at the code is that we need
> to decide how much of glib we are going to use.  I've been using
> it for the code I'm writing for Ensembl, and like it a lot.

Good, I would like to sync this all closely with your Ensembl code base.

>
> ie, using g_new and g_malloc not malloc,
>           g_new0 and g_malloc0 not calloc,
>           g_print not fprintf
>
> There is some advocacy on this issue at
> http://www.gtk.org/faq/gtkfaq-8.html#ss8.4
> I think this makes sense, particularly for memory management.

I think you are definitely right that we should use names like
g_malloc or perhaps tg_malloc, and I've changed the perl now so that
all the library functions it mentions are defined in one place.

I'm wary of being dependent on linking externally to GLib in case it
damages our portability.

Still, I'm very much in favour of using the GLib code somehow, maybe
in the short term linking directly to GLib and having typedefs in
"euclid_defs.h", e.g.

   typedef GArray tgArray;
   typedef GPtrArray tgPtrArray;

Then in the medium term we could plan to replace these typedefs with
chunks of GLib code that we can just suck in and redistribute with
appropriate acknowledgements. How does that sound..?

There are a couple of extra cool bits of GLib that I would like to
make use of.

(begin vague wishlist/ideas)

For an IDL typedef of the form

    typedef sequence<X> MySet;

i.e. with the new typename ending in "Set", then I want the
autogenerated code to use GTrees (balanced binary trees) rather than
GArrays, so it will be optimised for dynamic set operations.

Also if we have a struct whose name is "X_Y_kv" then it is assumed to
be in the following form

    struct X_Y_kv {
        X key;
        Y value;
    };

and when we put something like this:

    typedef sequence<X_Y_kv> MyMap;

then Euclid will implement this as a Set with sort & get_by_key
functions and cmp-prototypes that look at the key... i.e. effectively
a map from X's to Y's. If X is "string" then we use a GLib keyed data
list.

(end vague wishlist/ideas)

This needs to be thought out a bit more. The point is that if you use a
data structure as often as (say) a balanced tree and you can autogenerate
code for it in a clean way, then it saves you a lot of effort; but we need
to make sure it's still compliant IDL.

If you have any requests I'll prioritise them. I think we should
definitely use Quarks as well.

> (Also, I wouldn't use 'ditto' anywhere in the comments ;)

:) Changed..

> Any ideas about how we should write makefiles for this lot ?
> manual/automake ?

I think we should autogenerate them along with the C eventually, but
for now.. probably manual.

This is a program that hopefully other people will use, so if you have
a wishlist then please tell me - the more this helps you the better. 

Ian

>      
> Guy. 
> --
> 
> 

-- 
Ian Holmes  ....  Howard Hughes Medical Institute  ....  ihh@fruitfly.org