Well, I fixed the root cause: 9ca573f40f1065cc717c0c5aabb787671bab852b

Still makes edje_cc hang, after introduction of 7f53d9158395504151e1ff3dcae715a799d913a8.

lgtm

It definitely generated title headings last time I tried... that's the reason I added the distinction in the first place.

35b2a10dd5e05e668e025697075076851acff845

This is already done differently

You shouldn't need this. A title header is already emitted by the writer itself, see writer.lua, the __ctor method. It just uses the Dokuwiki title plugin by default, if you don't have it, pass --disable-title and it will fall back to headers.

No. This would create disparity in how the API behaves depending on an arbitrary switch, which is completely unacceptable.

2946cb3c325f27d77354ac1b83b614e3a1d9e1d5

Yeah, so it was the issue then :) I suspected something with alignment/padding with the union'd definition of Eolian_Expression not playing nice with the typecast, looks like my suspicion was correct.

can you try again after the latest commit?

i'll need a better backtrace for this...

This appears to be wrong. The "default values" are only allowed for property values {} block as well as for @out parameters, Eolian will not accept them for @in parameters. I.e. those values are default fallbacks.

Please don't, I already have this mostly done with other changes and this just creates more work for me.

as @segfaultxavi said

In T8184#142189, @tasn wrote:

In T8184#142185, @q66 wrote:

@raster that's because requires is not extends, requires pretty much specifies a list of classes that are required to be in inheritance tree of the thing using the mixin; by specifying it, you tell eolian that it's guaranteed it'll be there, and the mixin can safely implement it.

Yeah, we understand what "requires" means, as in why the name is there. Though how is it different than implements? As that's exactly what's going on here?

@raster that's because requires is not extends, requires pretty much specifies a list of classes that are required to be in inheritance tree of the thing using the mixin; by specifying it, you tell eolian that it's guaranteed it'll be there, and the mixin can safely implement it.

As of afc011d8931006bd020ba5130a581580f709edcf, usage of ptr() is banned in stable API. That's bound to be good enough for now, and removing it from beta is a separate task, so closing this as resolved.

this doesn't correctly fix the eolian_type_c_type_get usage yet, which means this will behave wrong with the tag; i still see EOLIAN_C_TYPE_DEFAULT/PARAM/RETURN being passed around.

OK, I did that for now, but we'll need to figure out a proper one...

I think we've got this down, eolian properly checks and verifies this

this is now banned in stable API... removal still pending

Hm, what should be do about this? Do we want this to be thread-safe? Because the error API is not...

Closing this as the system is generally sound. Syntax changes may happen but no design alterations

Please rebase for the @class -> @static method change

Okay, but I'm not sure why you assigned this to me, considering I'm not dealing with widgets.

Hm? why not just rename current @class to @static (which is easy and quick) and then only re-add @class later if it ends up being needed?

If it's just renaming to @static, then that's fine and easy

I think this is good

But the proper thing to do later on would be to create a wrapper type with the same layout as Eina_Slice (or Eina_Rw_Slice) but make it templated in order to respect Eolian's typeinfo. But for now this is fine

I added an initial syntax for this in the commit above. Please comment if you have any suggestions, objections etc.

I landed the patch so this can proceed probably.

Just running tests before landing this now.

Hm, I think it's fine.