'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 (253 w, 3 d)
Wed, Feb 14
I think this would be a good fit for a Lua script.
yeah, a wizard option is a good idea
IMO it'd be best to actually remove those because most people I've seen use E were annoyed by those and removed them immediately; the maximizing behavior would be much more useful and expected for most.
Tue, Feb 13
I applied your patch.
yeah, I don't think we can fix this with autotools. Maybe meson would help though, @bu5hm4n any ideas?
Dec 18 2017
Dec 7 2017
yeah, you're probably right; the current legacy field was never even meant to be a proper feature, more like a temporary hack to get enums for legacy APIs to behave as we want them to...
Dec 6 2017
Nov 2 2017
I'd unlink it from T5826 but leave it open...
Nov 1 2017
i guess i'll just close this since part information is already done since a few days ago...
Since I won't have time for the proper solution in near future (because of other work elsewhere) I'll let @ajwillia.ms proceed with his workaround for the time being. A real solution will be implemented later as time allows, but not bound by this project.
Oct 30 2017
This should be fixed by the maintainer.
Oct 27 2017
We'll definitely need this, but I'm not sure whether processing some sort of XML from Doxygen is the best way to go at it... since this is just C we're dealing with, it's fairly simple as far as the language in headers goes; perhaps we could parse it manually (it shouldn't really be a big deal) which would allow for simpler integration into dokuwiki (doxygen carries a lot of clutter we'd have to strip off into the result). But I will need to investigate this to be able to tell for sure.
Oct 24 2017
i expect to have it done by tomorrow evening...
Oct 23 2017
alright, let's get it in during this week
Oct 17 2017
Oct 13 2017
Yeah, the test was wrong and so was the generator...
just FYI, keep in mind that if you "pass" the defined function as an argument in Eolian, it will actually generate *three* arguments in C; data, the actual funcptr, and a "free" funcptr (Eina_Free_Cb) - this is necessary to track lifetimes.
Oct 11 2017
you're right, that should be fixed.
Sep 8 2017
yeah, the generation for this should probably be changed; it's just a tad difficult because there is no real indication of what the group should be... OTOH, this issue should not be very relevant anymore, because the old Doxygen documentation is getting deprecated anyway...
Aug 30 2017
I implemented a fix for the bytecode confusion in 67d1c0e51c01ba159f88adc6446cc31cee79c808 so similar cases should not happen again.
Aug 28 2017
this is what happens when people push into eolian without letting me review first... i didn't feel like calling out the responsible person at first because it was a change that needed doing anyway but i guess i will have to:
Aug 18 2017
The right way really is to remove the bytecode if it fails loading and try loading the source file... so I guess I will do just that
looks like leftover cached bytecode made with previous version of luajit...
Aug 10 2017
Aug 3 2017
we should also figure out how to integrate the doxygen docs and the dokuwiki, because having two separate systems is just bad...
Jul 28 2017
yeah, i think we can just proceed with this, if there are no further objections
Jul 27 2017
Jul 19 2017
Yeah, if the function becomes three parameters, it's technically possible to implement. I just fear that this is 1) not really necessary 2) rather ugly API-wise... Also, the way Eolian currently works doesn't assume multiple things can be generated from one, so that'd have to be updated as well...
I don't think eolian_gen is the right place to put this at all. It should go into the validator in the library. If you want me to implement this, I can...
Jul 17 2017
yeah, will be a pretty simple fix
Jun 28 2017
Jun 16 2017
That sounds potentially sensible to me. EDD is coming up soon so we can also discuss the details more there.
Jun 15 2017
I guess it's possible in theory, though it's more work than you think and I'm not sure if I like the idea yet. Also it doesn't properly handle types and other dependent things (which are shared between classes and multiple translation units) and I could probably think up a billion other potential issues that could get in the way, so the extra complexity is by no means small. Having to care about where things are put in the binary sounds super nasty and I hate it, too. So this is definitely not something to think about for this release cycle, if at all.
Jun 14 2017
@jpeg they won't work unless we figure out lifetime and memory management tracking... if you have ideas, feel free to suggest
May 22 2017
The change 7007c3314d31d1c80d1670500d899ed9d7350a79 is a pretty bad idea as it seems to break build. It's never good to deifne a thing in two places like this, because it *will* result in conflict in Eolian for a good reason; the solution would be either putting the undefined type in the .eot file so it's in a single place, or just revert the commit for now.
May 19 2017
yeah, _EXTRA_OPS should work for this purpose, even though it wasn't really written with this report in mind.
Apr 6 2017
This is also something we could look into, however I've been doing some prototyping in my local tree and still not sure how I'd approach this. We should probably discuss this more and find some reasonable way for 1.20.
Yeah, I agree with @cedric here. This is something to look into. The parts syntax is probably good enough. I don't like the @part variant.
I've been thinking about this and even trying stuff in my tree, and I'm honestly still not sure whether it's a good idea... I can see we might need something like this at some point, I'm just not sure if it's worth it to define something that is internal anyway, not visible to public API, and not visible to bindings in .eo...
Mar 7 2017
it does, just needs regeneration on website. well then
I implemented this in bf7b3e5dfca740e5e1096fbbfb81cffb980f1b2a. I'll leave this open for now, so if you have any suggestions, i'll deal with those before closing.
Feb 24 2017
All the points except the event stuff are dealt with now, and event stuff is T5208, so closing.
Dec 21 2016
yes, it works @artem.popov - if you had it expand to 0, this was before the recent bug fixes in the Eolian expression handling code (unlike previously, Eolian now fully validates all expressions and whether they match their data type, instead of silently expanding to 0 - but the particular 0 expansion previously was caused by a bug in the expr evaluator). If you still have it happening, a locally installed libeolian is probably at fault - autotools somehow prefers system libs as dependencies instead of the in-tree ones. The above fix expands to this with properly updated EFL:
Nov 29 2016
The suffix abbreviation was meant to be just a simple thing to remove duplicates when two words follow each other. I do not consider this a bug fix since it potentially significantly changes some API names as well as Eolian behavior, so this sounds like a thing to be discussed and thought about first. Keep in mind that i'm not against having a feature like that as long as it's justified, but just pushing a patch like this without any prior conversation is wrong, and this doesn't go for just this patch.
Excuse me, but seriously guys? This lack of communication kinda pisses me off.
Nov 3 2016
it's because autotools sucks and build is using installed libeolian library instead of in-tree during build; remove $PREFIX/lib/libeolian.so*
Oct 31 2016
well it looks fine to me right now, but ping @tasn
Oct 25 2016
@barbieri deserves a spanking for this one, but it also helped me realize that eolian generator does not validate (so it only fails in elua), so I fixed that too now
Oct 19 2016
Oct 12 2016
I updated the generator to use an Eolian API instead manually concatenating now in d3d63ea8d39378b254728390809c44163bbadb63
Oct 10 2016
Hm, let's see. So if we're going to do this (need comments from @tasn too, as I'm not going to make this decision by myself) I'd at least properly do it for all object types (i.e. treat suffixes _MIXIN and _INTERFACE in the same manner). Also, I'm thinking this would be best added as a new API into the Eolian library. That way the generator won't have to special-case this, and it'll potentially help other generators too.
Sep 9 2016
Aug 23 2016
BTW, here's a tip: if the "get" method in your class serves as some sort of singleton getter, (i.e. you want blah_get to retrieve some instance of Blah) name your method blah_get, and Eolian will automatically turn double words like blah_blah_get() to just blah_get().
We decided to make the names "get" and "set" reserved, so just don't use them as method names... the appropriate Eolian changes to verify this will come later.
Aug 11 2016
it is, but LuaJIT can actually JIT FFI calls and as a result generate the same code as a function pointer call would in C, while C calls are interpreted/slow (both because of the call itself, and argument/result marshalling)
Aug 9 2016
Well, my point was more about external scripts (say, ones part of potential third party Enlightenment themes). If EFL supports all four versions (luajit, 5.1, 5.2, 5.3) and a script that is part of an Enlightenment theme gets written against 5.2 or for example using a LuaJIT language extension, it will not work with EFL builds built against a different version of Lua (therefore preventing usage of that theme in that build of Enlightenment).
That's nice to know, but it's sort of useless anyway if we can't properly test on those targets, as with something the size of EFL things are bound to be broken in various places on untested setups...
Aug 2 2016
@aerodynamik I looked at the lua ffi a while ago, it wasn't really very usable and it had some semantics differences compared to luajit ffi
elua (which will become increasingly more used, once the efl lua bindings are fully functional) doesn't work without luajit at all (even now), bob (when it's written) will not work without luajit, etc.
Jul 31 2016
@zmike not familiar either, this stuff is only used by openbsd and freebsd/netbsd/etc use PAM just like linux, sorry
Jul 19 2016
Sounds good, let's do it when merge window opens.
I think we're good in that case. Do we want to drop it for 1.18 or leave it for next release?
windows and mac os support is fine. I tested it myself since I had luajit integrated in my game engine and didn't experience any issues.
We basically have two options. Either maintain support with all Lua versions - which is theoretically possible but then we can't guarantee that all scripts will keep working on all EFL installations (because of subtle language/library differences) and we'll have to drop it later anyway, or just drop everything but luajit... the choice is yours
Jun 14 2016
I have looked into this and it will require some changes around the place. Either way I will aim to get it in for 1.18.
I added the necessary code to support this in 70d28666628a09c70895d4d426b719f9362b394f but apparently there are eo files in the EFL that don't conform to this (which is obviously wrong and as things will be broken under certain cases) so it's disabled for the time being... i will close this and deal with the issue further.
Jun 13 2016
I fixed the cursor position thing in 922e4e918182c4a6d012973a237b89b9248a017c so it will now correctly display at the beginning of the doc (I fixed it for other tokens as well). The rest of the report is not a bug, so closing.
Jun 9 2016
Implemented in 375179b47fa62dba2a1168d1e4e6a7ab877f7414.
May 25 2016
how about the other cases across the EFL where an identical thing is done?
that's my point, we shouldn't use ptrdiff_t for return, as it will break things, but using a branchless sign like i suggested would probably be a good idea (even though a decent compiler will optimize your version anyway)
perhaps changing the compare func to return something like ptrdiff_t kdiff = key1 - key2; return (kdiff > 0) - (kdiff < 0); would be the best idea.
actually there is an ABI problem, as eina_hash_new can take an arbitrary external key compare func, which we would break by changing the signature
May 23 2016
Yo, fixed in 4bdb1f73b8ec55d4d00a2ce6607d47f388150ed2.
May 17 2016
Closing this, fixed in 7782c0bcb956263e4b58b9ee5640381fe7b3c4f9