- User Since
- Dec 2 2019, 7:24 AM (31 w, 3 d)
Mon, Jul 6
Wed, Jul 1
Tue, Jun 30
Ok, I think that's it for this patch. Should I squash the commits it or will it be squashed by who lands the patch?
Removed 6 and 8 from this patch, so we stick with just:
Mon, Jun 29
Ok, took my time to think of the arguments here. So let me reorganize the ideas...
My mind just messed up some phrases in the last comment. Edited to make more sense :^D.
Fri, Jun 26
Readd regexp on non-windows environments.
Replace explicit dependency('zlib') with zlib variable.
Since D12031 has landed, I think this one can be closed.
Thu, Jun 25
Add back the accidentally-removed DLL_EXPORT=1.
Wed, Jun 24
Tue, Jun 23
This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.
Fri, Jun 19
Thu, Jun 18
Tue, Jun 16
Looks good :)
Mon, Jun 15
Ok, I agree that the current EAPI usage is sort of error-prone. I'm closing this and let it for further discussion in a later patch with Felipe's proposal.
Jun 8 2020
Set symbols in config.h
Change EAPI definition where it is already defined.
Jun 5 2020
Jun 4 2020
May 25 2020
Getting the patch straight from devs/stefan/efl-dll works pretty fine and passes tests. :)
Passing tests :)
I applyed the patch locally here (against updated master), but it fails with the same error @stefan_schmidt had.
I would love to see clang-format for that, but it doesn't seem to support it well (https://clang.llvm.org/docs/ClangFormatStyleOptions.html). I tried some small tests but didn't get good results (e.g. it interprets # as preprocessor directives, moving comments to start of line and breaking too long comments with \).
May 22 2020
Figured out what @bu5hm4n was saying, I think.
May 20 2020
Seems reasonable and apparently nothing broke here.
May 19 2020
Works and passes tests here (in Linux).
May 13 2020
May 4 2020
Feb 27 2020
You mean this?
True, my EFL was out of date!
Feb 21 2020
Feb 20 2020
Oh, okay, found the neovim issue: the file is actually called "nvim.desktop", not "neovim.desktop", that's why. My eyes just didn't catch it at first.
About the purpose: understood, gonna update the main post.
Add a test-case.
Feb 19 2020
Feb 18 2020
Feb 17 2020
Just to add some (possibly) useful info:
Feb 14 2020
Got the following build error for efl_mono.dll:
Feb 13 2020
Passes tests and has pretty nice refactors.
Feb 12 2020
Feb 11 2020
Fix mess with arc: considering only last commit, not the entire dependencies.
Add managed name to exception message and simplify ifs.
Feb 10 2020
Indexers have been reverted as not good practices for our use-cases (as stated in D11114).
@felipealmeida So, I've found rEFL581bec9598943cc9274dfe7db1a73a4c878c3cdd, which makes struct immutable because of C# recommendations (and there's the reasoning I was looking for, too). Should we propose to make EO structs generate classes instead, then? Where could I read/who to talk about if it would or not go against the idea of EO structs?
Feb 7 2020
Oops, just realized actually structs don't have properties (https://www.enlightenment.org/contrib/docs/eo). Maybe changing an eo-struct would require creating a new one with modified values, letting mutability only to classes?
As far as I can see from struct_definition.hh, fields are intentionally read-only (don't know the reason, tho), while properties may be writable. Should we change that rule and add a set for them, then? Where could I find the reasoning about who should be read-only, etc.?
Feb 6 2020
Does this commit resolve this task? Or is there something missing?
Jan 28 2020
Looks good to me :)
Updated diff title to describe better what does it change.
Update to reflect changes from 581bec9598943cc9274dfe7db1a73a4c878c3cdd.
Jan 27 2020
Use current indent level instead of arbitrary level 2.