'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 Details
- User Since
- Apr 12 2013, 5:06 PM (406 w, 3 d)
- Availability
- Available
Aug 17 2020
Jul 18 2020
Jul 15 2020
Jul 12 2020
May 12 2020
@rvandegrift arm64 should also be okay in most distros
May 11 2020
Also, there are luajit patchsets for both ppc64(le) and s390x, most distros ship them. As for amd64, why would that be broken?
The new ffi stuff has nothing to do with evas filters, the code for that will need to be fixed separately, but yes, right now you need 5.1
Apr 18 2020
This should be fixed in 1afb26428899cf24da45b73540f711ee27679fdb
Feb 24 2020
lgtm
Feb 13 2020
Feb 6 2020
Feb 5 2020
Jan 30 2020
Jan 27 2020
this was created in order to have classes that only have static methods (i.e. I guess as a crutch to be able to have free-standing functions in eo). If we still need this we can land it
Jan 22 2020
Jan 9 2020
this looks fine to me but better reviewed by @bu5hm4n
otherwise looks good to me, but fix the thing @zmike said
the ifdef is no good, because that changes the layout/values of the enum depending on if you're compiling with BETA_API_SUPPORT or not, which sucks from ABI perspective; you need to make it have a placeholder of some sort in the other case
Jan 7 2020
the whole reason the keyword is still there is pretty much these 4 enums, nothing else in the tree uses it... i'd prefer to do away with it entirely
Dec 23 2019
Hm, it displays now. Previously phab would not show it.
I think the revision is wrong, it doesn't contain the previous changes but it should because they were reverted
Dec 22 2019
We should do the same thing for enums.
Dec 19 2019
I implemented that already, it's behind an env var (EOLIAN_ENFORCE_SINCE)
Dec 13 2019
Hm, I guess it should check it. I'll look into it and see how viable it is. If we can't change it it shouldn't be a big deal though.
Dec 6 2019
?
Dec 4 2019
T8491 is fixed now.
Dec 3 2019
Otherwise looks good to me
yeah, i'm on it
Dec 2 2019
Nov 29 2019
Nov 21 2019
Nov 13 2019
Well, I fixed the root cause: 9ca573f40f1065cc717c0c5aabb787671bab852b
Still makes edje_cc hang, after introduction of 7f53d9158395504151e1ff3dcae715a799d913a8.
Nov 5 2019
Oct 9 2019
It definitely generated title headings last time I tried... that's the reason I added the distinction in the first place.
35b2a10dd5e05e668e025697075076851acff845
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.
Sep 30 2019
No. This would create disparity in how the API behaves depending on an arbitrary switch, which is completely unacceptable.
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?
Sep 27 2019
i'll need a better backtrace for this...
Sep 20 2019
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.
Sep 19 2019
Please don't, I already have this mostly done with other changes and this just creates more work for me.
Sep 13 2019
as @segfaultxavi said
Sep 12 2019
@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.
Sep 10 2019
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.
Sep 9 2019
Sep 6 2019
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...