'q66' on IRC; Software Engineer at Samsung Electronics Czech (working for SRUK Open Source Group); OctaForge project maintainer, Elua maintainer, and a heavy Lua (ab)user.
- User Since
- Apr 12 2013, 5:06 PM (326 w, 3 d)
Mon, Jul 8
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
Wed, Jun 26
Mon, Jun 24
I added an initial syntax for this in the commit above. Please comment if you have any suggestions, objections etc.
May 30 2019
May 28 2019
I landed the patch so this can proceed probably.
Just running tests before landing this now.
Hm, I think it's fine.
May 16 2019
May 14 2019
Looking good to me
May 9 2019
Any update on this? Can it be closed? As far as Eolian is concerned it's been done for a while
This has been done for a while.
May 6 2019
May 5 2019
May 3 2019
Apr 24 2019
No, it's not intended, but all you need to do is simply remove the first is_enum check and leave the second one where it is.
Apr 23 2019
The goto is unnecessary, syntax error means a long jump
Apr 19 2019
that helps, i'll add guards for it once I am back
Apr 14 2019
Mar 21 2019
Mar 20 2019
you still missed one
You can't just eina_hash_add into nhash without checking !oobj because if you do and the entry is already present, that's undefined behavior for our hash implementation, so either keep the if or make them eina_hash_set
Mar 18 2019
That works too
I intend to do away with const() as well as ptr() in the current form entirely, so having a new syntax is the better choice for it, besides, immutable by default is a better choice than mutable by default
Or maybe, make them const by default and some kind of event tag to make it mutable where needed?
Understood. Do we need a way to make objects const when possible?
That sounds good to me. So basically the only types allowed are value types, objects and container types, minus list/iterator; everything is annotated without any qualifier, and everything is immutable and passed by reference, except objects. Maybe we should pass objects by const too? So that only @const methods can be called on it. That would make all event data completely immutable.
I'd say that allowing less is always a good thing, as it allows for fewer errors/mistakes, so if we can do away with it, let's do it
I don't think we currently specify how things are *meant* to be; we need to come up with something.
Any proposals on this?
rebase + remove leftover macro usage
The comment in elm_interface_scrollable.c is fine, doesn't need changing.
Mar 15 2019
Looks like this one is good to go https://travis-ci.org/Enlightenment/efl/builds/506793582
Mar 14 2019
rebase + more fixes
Mar 12 2019
Yeah, I'm ok with not having vars, as the abuse potential is there. Constants are another matter, these are constrained and rather trivial.
Mar 11 2019
I decided it's for the best to solve this properly at a later point
marked missing classes beta, rebase
Mar 10 2019
We can not, these are a workaround for beta API enabled but eo API disabled, eo files still depend on those, we need to solve this properly later but that will take more effort than is reasonable right now
Mar 9 2019
previously they weren't assumed anything, any checks regarding beta were simply skipped, but @beta could be used the same; the new behavior checks them, so i only fixed those classes that were newly causing errors
Mar 8 2019
removed outdated comment
Mar 7 2019
can't enable beta guards for types yet, as it triggers too much
brokenness which we can't fix in time
added support for marking function types beta
added generator support, fixed parser bug, rebase
There is also nothing wrong with the test results of your test, that is fully intended; the class is not in the Efl. namespace, therefore it's not treated as a stable class. Putting it in the Efl. namespace makes it warn normally:
Struct fields are checked implicitly by design just like all other types, it does not need any specific code. When a non-beta function/typedecl/whatever is encountered, the validator switches state into "stable" mode and any dependent types (which includes anything in struct fields) are required to be non-beta. I will investigate the other stuff.
Mar 5 2019
I'll take src/lib/elementary/elm_*.eo.
I know this changes Eolian API so since we're in a freeze it's probably not 100% ideal to merge this, but we need this to be able to stabilize at least something at all.
Mar 4 2019
We have no Elm_Win_Type in eo files, nor Eolian provides any facilities to deal with legacy types, so this will need to be fixed manually as manual legacy APIs are pushed into the tree.
Feb 28 2019
Removed in 4b1622b5fc7c6aaafb4d70f187ec5ea797275a26