On Sun, Mar 14, 2010 at 7:05 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sun, 14 Mar 2010 12:33:20 -0300 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> said: > >> On Sun, Mar 14, 2010 at 11:49 AM, Carsten Haitzler <ras...@rasterman.com> >> wrote: >> > On Sun, 14 Mar 2010 10:20:11 -0300 Gustavo Sverzut Barbieri >> > <barbi...@profusion.mobi> said: >> > >> >> On Sun, Mar 14, 2010 at 12:48 AM, Enlightenment SVN >> >> <no-re...@enlightenment.org> wrote: >> >> > Log: >> >> > fix more runtime wornings... added ELM_ERROR_ABORT! :) >> >> >> >> couldn't/shouldn't you use the EINA_MAGIC or EINA_SAFETY macros and >> >> then get the same system there as well? I'm thinking about this being >> >> used in Ecore and Evas as well. >> >> >> >> This is a case for the eina_magic. >> > >> > eina_magic is not useful - no magic numbers for checking. it's literally >> > checking types. and types are strings (but that happens to work with a >> > pointer comparison due to stringshare). and eina_safety macros simply dont >> > output useful information in the same way - as literally the strings need >> > to be printed - not the "inline in the code" expression (as one is a >> > dynamic return from a func). what's there now works well. i don't see a >> > need to do much more and throw everything into eina for what is a >> > case-specific checking and output. >> >> well, eina magic does print strings, but yeah, the magic number is not >> dynamically allocated... maybe something that we could add to >> eina_magic... in the same fashion as ecore_event_type_new(), have an >> eina_magic_number_new()? > > there is little point - the check is a "if this fails - complain". it's an > if... in a macro. total over-engineering. its getting the type string - it > possibly could use strcmp. it happens not to though. but u'd have to make it > do > that - and then all u do is have to allow aribtrary code to do the check - > then > arbitrary code to handle the complaint output - at that point your macro is a > glorified if (x) then y; else z; - no point. > >> Another option, we could use the same thing and use the stringshare >> pointer as the magic number, that would work nicely as well. > > but the magic number isnt put into a struct ala eina_magic. there is little > point in trying to over-engineer what is a 1 line macro and then the "custom > handler" func we already now have.
the point is that it is common, so we know for sure how to turn things on and off... You see in both IRC and with newcomers at various places that we have constant duplication of some things that worth nothing duplicating... there is ELM_ENGINE, but ECORE_EVAS_ENGINE was there... the engine names are all different everywhere. Same for how to enable logging, or rather, how to disable then. Now runtime type checking, it is the same. Take the role of a packager, for example. If one is doing a custom system and wants to remove all checking since he want to assume the risks for such performance hit, then he must do it in various ways to get these things in Evas, Ecore, Eina and Elementary... given that the way Eina was designed is to allow to unify these things. In a related note, the other day you committed lots of printf, that was impossible to remove without going into code and removing your lines... and that impacted other developers out there, particularly the Editje developers. Now most of those printf()s are gone, but if someone want to trace what happens, he needs to go, understand, think and and re-introduce the printfs... again :-( That is bad, and this is one more reason to get used to eina_log... the API has zero runtime costs if you set a maximum log level before compiling, it should have minimal cost if runtime disabled, and may allow things like logging to other files, useful to avoid mixing E17 with all its children applications that get ~/.xsession-errors to grow so big gdm and others stop logging after some amount. Anyway, i know it is PITA to get used to some things that we have almost zero cost to implement over and over again, but we must consider that the "implementation time" is not the only thing to be considered here. That's why we use our basic data types and even strlen... god, it's 1 line to implement strlen, why don't we do it all the time? :-) I know it is my fault as well... if I did the work of converting all these things to eina before, this wouldn't happen... but time is also short on this side as well :-/ -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
