xOn Sun, 14 Mar 2010 19:18:50 -0300 Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> said:
> 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.
the elm one isnt turned on or off at compile time - and runtime.. it has an env
var of its own. nicely namespaced. export ELM_ERROR_ABORT=1 is simple. now if
we do it.. as per your example, the eina-log way - u need to have a more
complex and less easily guessed/known way...:
export EINA_LOG_LEVELS=eina_module:4
ok - lets take the example:
export EINA_SAFETY_ABORT=elementary:ecore:...
etc. now i have a single env that i need to know the name of n strings inside
- it is no easier - if anything it's harder. you havent improved anything
really. you've satisfied your needs of thinking you've simplified things. you
really haven't. :) so now i need to know i set some unrelated env var (EINA..
how am i meant to know that an EINA env var modified an elementary action?) and
i also need to know the correct string to use/set (elementary?elm?) etc. right
now you need to know 2 things only. u have ELM_* as the namespace for env vars
affecting elementary and *_ERROR_ABORT sets behavior to enable aborting on
errors (so u can trap via bt). that imho is just as simple - if not simpler.
> 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.
none of them provide any ways of removing the checks - so it's moot. if they
did it'd be via a configure option... and if that was the case they would each
provide that as a --disable-safety-checks for example - the rest is up to the
autofoo (if they all set the same -DDEFINE=x or they set something in config.h
- is rather moot). :)
> 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
i was debugging. and those help with the debugging. it impacted them with
noise. it impacted me - and others too. thats debugging. i wanted my existing
fixes upstream asap even if there was noise.
> and and re-introduce the printfs... again :-( That is bad, and this
i have no intention of keeping things like that. there is no point using
eina-log. logging will not stay. i dont want it cluttering up the code not to
mention eina's default loggin output is undesirable for what i want. i dont
want its colorisation and line number and file name output etc. - but then yes
- i'd have to create a custom log output callback (yet more complexity just not
needed when printf does the job) and / or disable color and file output,
function output all in the "name" of using eina log - then i'd have to create a
special logging domain name so i can enable/disable it... all for when its a
teporary bit of noise that will go in TO track a bug (to follow logic flow
through 100's or 1000's of fn calls) and then find out where the logic hole is
- remove the issue, then remove the printfs as they wont be needed anymore. i'd
remove the eina log calls too. this is not the kind of thing you would ever
really log. i'm debugging and gdb simply doesnt do what i want nicely.
i use eina-log if i have some output i intend to display on an error/warning
etc. etc... and i intend to keep it.
> 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.
a totally separate issue. :)
> 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? :-)
because above - i dont intend to keep the output - it was temporary noise in
hunting down bugs. as for the "elm type checking" - also a different issue. i
dont see how eina improves much here. forma code point of view - it becomes
nothing but a glorified if {x} then {y} else {z} - the env var i think is done
more simply the way it is done now. you dont save anything (as per above
example).
> 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 :-/
true. if there is already a style in place - i know i will continue to follow
it. even if its not eina-log or whatever - i'll continue. as such eina_magic
works for ecore and evas - it doesnt work for elm. the magic thing is just
different - its not a magic number anymore - its a type check at a higher
level. so the thing it was built for doesnt work anymore. if every possible use
cas3e of it was covered - you'd have a very complicated magic system just in
the name of trying to "put it all into eina". i dont think there is any big win
either way of using eina for temporary bug hunting hooks nor for elm's magic
check stuff. if one day we see the same thing in more places than elm - then we
can consider making something generic. but until then - little point. :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
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
