- User Since
- Jan 24 2013, 11:44 AM (290 w, 5 d)
Wed, Jul 25
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.
May 19 2018
Apr 26 2018
so it's indeed a false positive, line 70:
Apr 9 2018
to me looks like a false positive, paste the coverity error or link to the report?
Mar 11 2018
ohh... then it makes more sense.
Mar 9 2018
Cedric, could you confirm that eina_future_as_value() IS returning something valid (ie: non-EINA_VALUE_EMPTY?
Mar 5 2018
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.
Jan 22 2018
why not demote efl_name, since it's mostly for debug/tracking purposes.
Jan 19 2018
interesting, what's the expectation about name?
Jan 6 2018
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.
Jan 5 2018
my takes on this:
Nov 21 2017
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.
Nov 17 2017
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.
Nov 6 2017
do you know if the objects get deleted?
Oct 28 2017
i really dislike this kind of approach... IMO efl_main should be in the core lib and headers.
Oct 25 2017
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.
Oct 19 2017
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.
Oct 16 2017
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.
Oct 10 2017
Sep 11 2017
promise/future was rewritten and this bug is gone.
Sep 4 2017
as reported by T5981
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...
Sep 1 2017
Aug 30 2017
@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:
Aug 29 2017
Aug 27 2017
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.
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
Aug 26 2017
Aug 25 2017
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.
Aug 23 2017
Aug 17 2017
Aug 14 2017
i guess it's not needed anymore
Aug 2 2017
Jul 27 2017
Jul 25 2017
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.
Jul 21 2017
I can't check right now, but AFAIR the ecore con/ipc had a flag to set cloexec and would reflect to efl_net
Jul 10 2017
@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...)
Jun 16 2017
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:
Jun 15 2017
In my mind toolbar, menu or list should be the same like this:
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.
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).
Jun 14 2017
@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.
Jun 8 2017
what's wrong with doing the define if the symbol wasn't defined?
Jun 5 2017
you better reach @q66 for details.
May 16 2017
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
Apr 18 2017
Apr 13 2017
ok, will look into it, basically remove from clients list when eos happens. right?
Apr 12 2017
Apr 11 2017
@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*).
Apr 10 2017
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:
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.
Apr 8 2017
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.