wingolog

13 responses

1. wingo says:

   Wisdom:

   <bilboed> dwarves and gnomes rarely get along
   <bilboed> there's the reason

2. Benjamin Otte says:

   Conway's Law.

3. Emmanuele Bassi says:

   because DWARF doesn't describe signals and properties, along with concepts of namespaces, enumeration and flag descriptions, that are kind of central to the whole concept of a project called "GObject Introspection". if you discount GObject as whole, then it's not weird that the point of the project is lost along with it.

4. wingo says:

   Hi Emmanuele :)

   It is true that DWARF does not describe all of these, though it does have some support for namespaces and enumerated values. But my point was that it is extensible. Surely it is easier and simpler to add (e.g.) a GType attribute to an existing type DIE than it is to make a whole new toolchain.

5. Colin Walters says:

   > Why is it that we in GNOME came to view GLib as the lowest level
   of our stack?

   Because it has GMainContext, which is the fundamental tool for writing applications that don't suck (e.g. do async I/O).

   > and could be on Windows if we put it there.

   That's a major reason. The second is that in order to gather all of the data, we need to build the library, and execute it. Then after we gather the data, we'd have to modify the library, which is just kind of gross.

   https://bugzilla.gnome.org/show_bug.cgi?id=592311

   The third reason is that the separate typelib files in $libdir/girepository-1.0/Foo-1.0.typelib act as a lookup table, mapping "Foo-1.0" that gets typed in js/python into a .typelib file which then points to the .so to load.

   We wouldn't have to want to parse all .so files to find which one has Foo-1.0. (Though we could solve this with symlinks too I guess).

6. Colin Walters says:

   Also, patches accepted...

7. wingo says:

   Thanks for stopping by, Colin, and for being gracious towards a troll ;-)

   So, just putting this out there: we can change the compiler. We can get GCC to emit arbitrary attributes on types and parameters, and place them into the binary that it compiles, in the .debug_info (or into any other section). Depending on how it worked out things, one could avoid needing to load the library at build-time.

8. Colin Walters says:

   Note that gobject-introspection came before GCC had plugins (there is also the question about tying an important part of the stack deeply to gcc).

   Anyways, certainly putting the typelib (as it exists today) inside the shared library as a separate section, and having a symlink in $libdir/girepository-1.0 would be kind of useful. Going beyond that would involve a lot of work; if you break libgirepository API you have a lot of porting to do...

   Approaching things from the other end and trying to kill g-ir-scanner in favor of a gcc plugin is far more interesting to me.

   But all of this is predicated on having someone actually do work...

9. Jasper St. Pierre says:

   GIR is meant to be an intermediate format that's easy to parse and emit, specialized towards what language bindings need to do. That's not what DWARF is about.

   Does DWARF have a simple mechanism of marking a char * as being as string, or saying that it needs to be UTF-8, or that it needs to be in the native LANG-based locale? Grepping through the PDF, I don't see an answer to that.

10. wingo says:

    Hello Jasper. It is true that DWARF is a more general facility, but it is sufficient for the needs of GIR.

    For example, one could define a function as taking const char * UTF8 str. UTF8 could be __attribute__((property("encoding", "utf-8"))) with new enough GCC. That could then get written into the .debug_info as a type attribute that all could use: debuggers, bindings generators, etc. We would have to hack GCC to plumb through this information, but it is doable.

    Or, you could put type information into comments ;-)

11. Brendan Miller says:

    The last time I checked, it wasn't so easy to consume or generate ELF and DWARF information. Is there a well documented, high quality library that is BSD or LGPL (not GPL)?

12. Logan says:

    If we're throwing out alternatives to GIR, why not ECMA 335? Seems to cover the use case quite well and there's at least somewhat GNOME affiliated implementations.

13. wingo says:

    Hi Logan,

    Yours is a good question. I think it's fair to say that in GNOME, some of the solutions that we have implemented on the library level would be better made at the language and runtime level -- where by "runtime" I mean the language runtime. CIL is a good example of solutions at the language and runtime level.

    CIL is less interesting than ELF and DWARF (IMO) for libraries written in C, as it's not part of the toolchain for C.

    Finally I would note that I really respect the work that folks like Colin have put into GIR. We are better off having GIR than not. I just think it would be better implemented on another level, by digging down to lower layers like the compiler and the dynamic linker.

Comments are closed.