btw, in the past 2 years I'm doing a lot of React-Native development and although they export a platform-native Button, it's rarely used in real projects, which goes with TouchableOpacity and other basic forms.

so it's indeed a false positive, line 70:

to me looks like a false positive, paste the coverity error or link to the report?

ohh... then it makes more sense.

Cedric, could you confirm that eina_future_as_value() IS returning something valid (ie: non-EINA_VALUE_EMPTY?

Hi Cedric,

could you provide a .c and a call log so I can try to see what's happening? To me I don't see how "it's too late", _eina_promise_unlink(p) just isolates it, but you get the scheduler as the first parameter of _value_steal_and_link(), alongside with the value (which contains the other/child promise) and the future... so all the information should be there.

Hi Cedric,

why not demote efl_name, since it's mostly for debug/tracking purposes.

interesting, what's the expectation about name?

as said in IRC, I disagree but as I'm not doing any work on this... I'm shut up and stop bugging about this, IMO, messy design.

my takes on this:

whenever doing this, *PLEASE* use Efl.Io interfaces, so it's similar everywhere (ie: API will be mostly the same as the one for Efl.Net), namely Efl.Io.Reader, Efl.Io.Closer and the likes. For UNIX, you can benefit from Efl.Io.Reader.Fd and similar, not sure how is that on Windows.

I agree with jpeg. The mixin is a nice place to scan the format string and validate it against the given value type. While printf format are not that simple nowadays, it's something doable in short time.

do you know if the objects get deleted?

i really dislike this kind of approach... IMO efl_main should be in the core lib and headers.

hi... the last commit rEFL8661fe234c7e doesn't seem to address my comments... still not passing the format_string to the callback and not handling other types of eina value, just assumes it's a double. Add the runtime type check to avoid bugs to pass unnoticed.

either use efl.loop or efl.core... but efl.ui is not an option.

https://git.enlightenment.org/core/enlightenment.git/tree/src/bin/e_main.c#n1214 defines -i-really-know-what-i-am-doing-and-accept-full-responsibility-for-it to set really_know = 1:

for the record, the one in Enlightenment to disable some stupid checks could be removed as well.

ah, last but not least, the implementation of the default format_func should be something like:

just did a review on the ML about this patch, my suggestions:

• naming: use format_cb (or format_func) and format_template for properties names;
• pass format_template to format_cb function.
• for format_cb implementation, always check eina_value_type_get() for the expected type! Don't assume it's what you want and blindly eina_value_get()... in case of mistakes/errors, it will likely lead to stack corruption which is a PAIN to find and solve... so it's a simple if to help debugging.

promise/future was rewritten and this bug is gone.

as reported by T5981

New implementation by @iscaro landed with 5bd8c9a78d7bc21a956b775fb250e8e14711d5b9

Hi, the reworked future/promise landed today and looks like it fix this issue. Could you take a look with recent GIT (post de4825a274e81dc3035c70b38c3086b6446cba19)

merged in master after cedric fixed the mempool from...

blocking the merge of new eina future branch (D5131), since @iscaro already converted Efl.Io.Copier and Efl.Net to use it and that's when we noticed the problem :-/

@raster, it's not what you thought... it's much more like what's done with ecore_main_loop_thread_safe_call_sync(), however it's simpler as you can see below:

as for "await" in other languages, if they are all based on a future (as in JavaScript), then yes. The logic is pretty, pretty simple:

@cedric maybe you overlooked it based on the _await() which is very minimalist. Take the complex_chain from Future & Promise, it would look much simpler as you can see:

also note that eina_thread_create() doesn't allow us to provide a stack size, so on Linux it's 2MB per thread -- quite a lot. If we create a new eina primitive, even if an internal primitive to set attributes then we could easily reduce the overhead... most coroutines should run under 16-32kb.

This could help T5301

And we could generate the code using structs, details at https://sourceforge.net/p/enlightenment/mailman/enlightenment-devel/thread/CANkykrD_hC5vw3n6QRfzWNmu8OEiwhAZ05Wpj4UNYMAXCuS4jw%40mail.gmail.com/#msg36013936

The current implementation in GIT expects the documentation at an unusual place. While I'd expect this to work:

found some issues, fixes at https://git.enlightenment.org/core/efl.git/log/?h=devs/barbieri/future

I've reviewed this PR with @iscaro, looks very good to me after more than 10 interactions we reached a point we're very satisfied with safety, simplicity and overall implementation.

i guess it's not needed anymore

looks good to me

thanks @iscaro and @stefan_schmidt

many thanks, I was looking into ecore_con_server_add() from ecore_con_legacy.c... from your bt it shows ecore_ipc_server_add() which does no close_on_exec... clearly a bug. Prior to efl_net_server_serve() we must have a block like in ecore_con_legacy.c:

still no time to test/debug, but an inspection of the source says the logic should be correct. Could you check the logs for ERR messages? What about DBG messages in ecore-con?

I had some minutes to check and the legacy API had no such flag, so indeed the legacy API must set close_on_exec to true regardless of the default.

I can't check right now, but AFAIR the ecore con/ipc had a flag to set cloexec and would reflect to efl_net

@felipealmeida void *data is what? how to automatically notify it's not used and can be destroyed, what's in it? etc.

@cedric, how is the rewrite/rework of the promise/future? I'm not following git that closely, but seems no work to make it usable and race free... if we want to push users to this new pattern, it must work reliably AND must be easy to work with (like in JS, where it's almost transparent...)

In T5567#89097, @cedric wrote:

In T5567#89085, @barbieri wrote:

In T5567#89083, @cedric wrote:

In T5567#89068, @barbieri wrote:

Felipe, I believe that this is good, just make it a standard format and usable in general not just for menus, but any structure. Example:

Efl_Model *model = efl_model_from_json("[{'label': 'File', 'icon': 'file'}, ....]");

Efl_Model *model = efl_model_from_xml("<item label='File' icon='file'/>....");

Efl_Model *model = efl_model_from_yaml(
" - label: File\n"
"   icon: file\n"
"...");

IOW all that matters is the structure, they have children, each with some properties. All of these helpers could take schemas to further validade and use proper types, otherwise just fallback to strings and use eina_value conversions when something else is desired.

I am not a fan of this solution either as it has no type checking

read the part I said about schema, all of these guys have associated schemas that provide type and structue checking... and these will be used anyway, at least if we want models, those are already the most common formats as well as from SQL... recall REST uses XML or JSON, GraphQL uses JSON...

We are talking about menu and toolbar here, right ? Is it a real normal use case to get this populated from a GraphQL, XML or whatever ? If we are talking about MVVM in general, I do agree, but that is a different discussion. Here the discussion is how to make data model easy to use in the scenario of toolbar and menu becoming a view of it.

In T5567#89086, @cedric wrote:

I don't think we can do va_args, but we can do arrays I guess. In C, we could have some helpers for that. With the eo function being :

menu = efl_model_array_properties_new(container, EFL_MODEL_ARRAY("label", EFL_MODEL_STRING("File"), "icon", EFL_MODEL_STRING("file"));

And the helper macro being :

menu = efl_model_properties_new(container, "label", EFL_MODEL_STRING("File"), "icon", EFL_MODEL_STRING("file"));

In T5567#89083, @cedric wrote:

In T5567#89068, @barbieri wrote:

Felipe, I believe that this is good, just make it a standard format and usable in general not just for menus, but any structure. Example:

Efl_Model *model = efl_model_from_json("[{'label': 'File', 'icon': 'file'}, ....]");

Efl_Model *model = efl_model_from_xml("<item label='File' icon='file'/>....");

Efl_Model *model = efl_model_from_yaml(
" - label: File\n"
"   icon: file\n"
"...");

IOW all that matters is the structure, they have children, each with some properties. All of these helpers could take schemas to further validade and use proper types, otherwise just fallback to strings and use eina_value conversions when something else is desired.

I am not a fan of this solution either as it has no type checking

dude, this is a problem with helpers, not with model. Of course you can create a function that does that, like specifically for menus/toolbars:

Raster, your security concerns are really valid and worth enforcing.

Felipe, I believe that this is good, just make it a standard format and usable in general not just for menus, but any structure. Example:

In my mind toolbar, menu or list should be the same like this:

In T5567#89029, @felipealmeida wrote:

Function pointers will work. There's absolutely no problem at all with lifetime in the developed version. The method gets three parameters in the place of a function pointer: The function pointer itself, a void* private data, a function pointer to free the void* private data. That is all that is needed.

Cedric, the extra cost I dare to bet it's not extra, it's less as it's central and basically walk an array doing strcpy() x explicitly declared chain of strcpy(). Everything else is the same, you must parse the arguments and convert them to the data type, then call. Also, read it right, currently what I'm proposing is already being done at edje-external layer... which is edje-specific, just move that out of edje and make it automatically (and dynamically) generated.

Why using data model for this is not a good idea? In theory it is simple, light and easy to use... or it should, if not we're doing it wrongly... actually given the number of items, only "ease of use" matters...

My point is that you have all the information and the binary format in ram, it's the Eolian database. It's just a matter of dumping it in the generated code.

In T5577#89003, @q66 wrote:

In T5577#88995, @barbieri wrote:

what I wonder (actually I should know, but I never remember) and maybe @q66 can clarify is if we have that information available in runtime and how/where?

We don't have any structural information about eo objects available directly via runtime api. What you *can* do however is check the class of an object, get its name, parse the respective .eo file, and retrieve the information via libeolian if that's what you mean. But obviously that involves on-demand parsing.

In T5301#88816, @jpeg wrote:

In T5301#88201, @ajwillia.ms wrote:

I also think that EXPAND should be the default - it's more intuitive and it forces the user to adjust sizing to better balance what's visible (I.e. Button bar not expand vertical, buttons not expand horizontal).
Currently folk have to struggle with why things are all small and for things like text entries, scrollers or images they may not even be visible by default...

This is a good question. We can easily change the default value for visibility, align and weight when we are using efl_add vs. a legacy _add API. It's just a bit of work marking all legacy objects as such and changing the default value inside the finalizer. It can be done.
The problem is only which values really are the best?

Guys, maybe I got the wrong message, but the Model kind of factory for menu and toolbars fit perfectly.

+1 on those.

Last but not least, with this infrastructure in place we could implement not only edje_external, but also Glade-like "widget tree description" (for those that don't recall glade, it was a XML that declares GTK widgets).

In T5577#88974, @woohyun wrote:

One more.

About this task, we also need to decide what params would be supported for this edje-external.
All properties ? or Some of them ?

In T5577#88932, @cedric wrote:

I am not a fine of runtime introspection as you pay the cost of compilation time... at run time.

@jpeg, what if we expose both termination states and link animations using these explicitly...

indeed, I believe when he said "eolian" is already the generation of the edje-external modules from each object.

what's wrong with doing the define if the symbol wasn't defined?

you better reach @q66 for details.

In T5307#87966, @DaveMDS wrote:

For the moment I'm not a fan of the idea: 1 style = 1 class

What about when an app define it's own new style for a widget?
in this case there cannot be a new class generated of course...

sorry but these are not of use... you need a valgrind suppression to hide dlopen() from eina_module_load() as these are from optimizations. Maybe it's provided with valgrind, otherwise you need to create one.

this may not be enough for couple of reasons:

• no main loop is executed, from your bug report it seems like the main loop is cleaning up the file at a future point, which can be the problem;
• image is not shown, not sure if this would impact this test or not, but evas is usually optimized enough to only use pixels of images that are visible, then you may be skipping those code paths that can trigger your bug

lgtm

ok, will look into it, basically remove from clients list when eos happens. right?

+1

@bu5hm4n read what you wrote and you'll notice how hackish it reads:

I don't get this... effectively we deal with the internal objects, thus why not return them? If they may be of different types, return the base type, or an interface/mixin (in ".eo", for usage it's always an Eo*).

yes, efl_promise_fulfill(Promise, Eina_Value) and variants like efl_promise_fulfill_bool(Promise, Bool)

well, calling a "single class" but then pointing users to N styles, all with their own API is the same... "N" api to look at the end. But at least one is Eo, the classes users know how to work with, they learn once and replicate. It's also saner if you think of external providers... you can download a "MyCompany.Combobox" that extends in a different way... I doubt "MyCompany" could extend the styles of a widget... but a subclass is always that, can come from external libraries and the application own code.

You're keeping "part" as "part" just because of legacy :-) That's what I mean.

In your example it's just properties... seriously:

SafePointer

You don't need safepointer... actually given the amount of usage of promise/future in Efl once it's deployed (jobs, timers, idlers...) we should be using mempool, then we can use a mempool property to safety-check based on that. Like you always allocate multiple of pagesize() blocks, keep a list of blocks. Upon API entry, check if the pointer is inside one block. If so, check if the slot is alive.

I'd like to see two things here:

Like my comment T5307#85241 i think we're screwing up in order to cope with legacy. If we say a style is actually a subclass of our class, then it can define more properties, which are the parts you're mentioning. The class.constructor could then walk the properties and check their backing store (edje parts, eet fields, dbus interfaces...)

my take on this is we'll stick some bad design just to cope with legacy... Eo on its own is good enough without extensions to do that. What is different from a new button class per style (ie: 1 style = 1 subclass)? The base class can then use introspection to automatically provide methods that convert to message or part_text_set or swallow.

see if it solved your problem, I'll check out maelstorm later.

looking into this in my spare time, where is azy nowadays? checked git.enlightenment.org and couldn't find it.

In D4775#80502, @zmike wrote:

I like this idea, and I think it would be great to have something like this in EDC. Some comments:

• There are no docs for any of the enum properties (fill, anchor_line). If I understand, fill is for sizing and anchor_line is the place on the "anchor" part to which the current part will be aligned?
• I think that using anchors in an edc description should probably trigger errors if any of the internal properties (relative, align, fixed, ...) are set in the same description and vice versa, just to avoid confusion?
• Probably this should have corresponding embryo script programs
• While I think this could be an improvement for some developers over the current layout system, I think it's still a bit confusing. I read through the Qt docs but it seems like in the context of EDC some of these terms are a little out of place somehow. I'll think on whether I can give a better description for my thoughts here...