On 15/04/14 14:24, Stefan Schmidt wrote: > Hello. > > On Tue, 2014-04-15 at 10:52, Tom Hacohen wrote: >> On 14/04/14 11:44, Stefan Schmidt wrote: >>> Hello. >>> >>> On Sun, 2014-04-13 at 12:53, Tom Hacohen wrote: >>>> >>>> I figure we are doing this to get higher coverage values/more real/catch >>>> some tiny more issues, but I'm not sure it's worth it. Might be a good idea >>>> to make it sane (default, or at least info, not debug). I know, things >>>> might break without us noticing in some debug paths, but it's not worth. >>> >>> Eveything we don't run regulary will bitrot. E.g. I just tried to run >>> make examples in efl triggered due to T1161 and I get a different >>> error with missing evas_table.eo.legacy.h which basically means we >>> will ahve at leats two problem in make examples right now. >>> >>> This should be no blame but showing that everything that gets not run >>> at least a day will bitrot. >>> >>> If you think the debug paths are not worth to run them we should go >>> ahead and remove them instead of having code nobody uses. >>> >>>> A better idea, would maybe, if we really want it, to have a "make >>>> debug-coverage" that can be used on the buildbot, I don't know. Though it's >>>> really annoying for clients, and they should, if they wanna test for >>>> coverage in that case, just set the env var. >>>> >>>> Any thoughts? >>> >>> Why make it more complicated? I see two things we can do here to fix >>> the problems we currently have: >>> >>> 1) Produce less noise in eolian with debug enabled. Daniel and his >>> team are already looking into this. >>> >>> 2) Remove noisy debug in other areas and remove debug paths if they >>> are worthless. >>> >>> As a band aid until 1) is done I removed the debug flag for coverage >>> builds. >>> >>> regards >>> Stefan Schmidt >>> >> >> I think Daniel fixed it. Have you re-enabled debug? > > Yes, he told me. I just haven't seen his change before pushed mine to > have a workign build. Will revert my band aid later today and see how > the nightly goes. > >> Anyhow, the problem is that some debug info is useful for devs of >> things, but not for users/common paths. >> >> Maybe we should have a new class called dev debug, which is just for the >> debuggers of the components. Compiled out when not doing dev builds, and >> even with coverage it's off by default (i.e will only start from the >> current debug, user-debug). > > To me this sound like another level where everyone has different > understandings for. Which is one of the problems we have with all our > logging. Developer tend to rate debug infos on their own code which > they are working on higher than other parts of the code they care less > about. :) > > We have different log daomians and log level for all this. Its just > that we are using them all very differently. I'm not conviced that a > dev-debug would help here but I'm also not against it. This whole > debugging levels is a can of worms I did not want to open. :)
Essentially, what I want is a log level that does not turn on when debugging is turned on globally. :) While there are cases in which general debugging is useful and good, there are others (like this one), that are very specific and not global. -- Tom. ------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
