Results 1 to 6 of 6

Thread: Enlightenment Introduces Eolian, EFL C Generator

  1. #1
    Join Date
    Jan 2007
    Posts
    15,655

    Default Enlightenment Introduces Eolian, EFL C Generator

    Phoronix: Enlightenment Introduces Eolian, EFL C Generator

    The newest component to the Enlightenment Foundation Libraries (EFL) is Eolian, an EO object parser and C code generator...

    http://www.phoronix.com/vr.php?view=MTYyMDA

  2. #2
    Join Date
    Aug 2011
    Posts
    572

    Default

    This very much sounds like the entire GTK+ -> GObject process all over again..

  3. #3
    Join Date
    Jan 2009
    Posts
    1,498

    Default

    Quote Originally Posted by Ancurio View Post
    This very much sounds like the entire GTK+ -> GObject process all over again..
    I had the same thought. Considering that this is rasterman I'd bet this is considerably lighter weight.
    Slightly curious about the format of the eolian metadata files...

  4. #4
    Join Date
    Aug 2011
    Posts
    572

    Default

    I have to day though that the "multiple inheritance" part is a bit intriguing, as that feature was intentionally left out of GObject (interfaces don't count).

  5. #5
    Join Date
    Jan 2012
    Posts
    65

    Default

    Quote Originally Posted by Ancurio View Post
    This very much sounds like the entire GTK+ -> GObject process all over again..
    in some ways it is just like that. i even looked at gobject with the view of using it, but it wasn't right for us. eo has several things different. it's more geared towards our needs and our existing objects we already had buried higher up the stack (this just moves it down the stack and unifies it). one of the big things that is different is the eoid mapping. for compatibility objects still come out as a Eo * (a pointer), but it's no longer actually a pointer to memory you can dereference. it's really a table ID stuffed into a pointer with generation counts (generation counts is something windows uses for GUIDs and that is actually a good idea, and this averts many false positives). it means that you don't direct-access an object by address, but via indirection making your code far safer at runtime to "oopses" (kept an object ptr/ref/id around then used it long after deletion - yes we do refcounting too, but let's say you forgot). this indirection of course costs, so to mitigate that, we can batch calls to share a single table deref across multiple method calls. e.g.:


    eo_do(obj,
    gui_move(x, y),
    gui_resize(width, height),
    color_set(r, g, b, a),
    visible_set(1));


    this is rather common - to actually set multiple properties or call multiple methods in a batch-like situation. this means we can share the table deref across 3, 4, 5 or more calls in a row.

  6. #6
    Join Date
    Jan 2012
    Posts
    65

    Default

    Quote Originally Posted by Ancurio View Post
    I have to day though that the "multiple inheritance" part is a bit intriguing, as that feature was intentionally left out of GObject (interfaces don't count).
    it was an explicit requirement to do multiple inheritance, so it's there. we have multiple inheritance already implicit in our api's but have had to duplicate stuff all over. this should improve that.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •