Tue, Nov 19
Wed, Nov 6
Tue, Nov 5
I tried to improve descriptions for efl_loop_message_future.eo and efl_loop_message_future_handler.eo.
They look like actually unused, though.
I mean they are created and assigned but there isn't a place that accesses or call some apis to those things.
Am I wrong?
Thu, Oct 31
Mon, Oct 28
Fri, Oct 25
This has been sitting here for a month and we need to do something about it, because the current state is not ideal:
The C# generator automatically adds docs to properties saying "The default value is X", taking that value from the the EO file.
But the truth is that implementations are free to use any default value they please, regardless of what the EO file says.
Default values currently in the EO files were chosen to match the implementations, but it is almost guaranteed that they will fall out of sync in the future.
Oct 17 2019
Oct 16 2019
Oct 15 2019
Oct 12 2019
Oct 11 2019
Oct 10 2019
Oct 9 2019
Oct 7 2019
Oct 4 2019
Added a patch that solves the issue of getting empty summaries.
Oct 2 2019
Oct 1 2019
To clarify, this should fail only in src/lib, since we don't necessarily want to enforce this for all usages of eolian (e.g., tests/apps).
Sep 30 2019
How about looking at it this way: Missing docs should always generate a warning. The switch would only control if the build stops or not, sort of like treat-warnings-as-errors.
This is what happens with the C# compiler, it always complains about missing docs, but we added a switch to make it abort too.
The point here is that it would be a cmdline option to eolian binaries which would be documented and use an eolian API call to enable the verification.
No. This would create disparity in how the API behaves depending on an arbitrary switch, which is completely unacceptable.
@q66 this should be enforced by eolian at build time and fail the build if a stable class is detected without @since
Sep 27 2019
Yeah. I've got the same ff and Ubuntu 18.04
If I shift-click, which opens a new window, then links work on that new window.
This looks like a FireFox-specific issue (since other browsers work).
I'll have to let somebody with actual web knowledge handle this.
Tested with Firefox with no addons, Help->Restart with Add-ons Disabled,
and i confirm the reported behavior, links doesn't work.