From: Erik W. <om...@te...> - 2000-12-29 10:09:27
|
I just committed the new INFO and ERROR subsystems to CVS. Very little code is converted to use them yet because we need to decide at a policy level what kinds of events are responded to how. Some things can get by with a g_return_if_fail, but others can't. How do we decide what can be ignored and what has to fault the program, at least under the default case? Also, I started to look into using varargs to let us create our own printf formats, like %O for an object. I have code to parse and manipulate the format string as necessary, but manipulating the varargs struct is much harder, and something that shouldn't be done anyway. The only option I can see is to parse and respond to the format string ourselves, using printf to handle the format oddities. What this varargs trick might let us do is hook into the format string mangling and allow error handlers to extract the interesting pointers from the format string. This would get rid of the fairly rigid approach of: ERROR(element,format,args...) ERROR_OBJECT(element,object,format,args...) We just go straight to: ERROR(format,args...) But then we'd want to put some restrictions on the error message formats, i.e. the element(s) in question must come first. As for the INFO system, there is no thresholding as of now. Again, we need to develop a policy as to what gets shown as INFO, and how we're going to split them up into groups or levels. The list of groups must be created before any real work can begin as far as putting INFO everywhere. I'm going to sleep now. Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/ Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/ __ / \ SEUL: Simple End-User Linux - http://www.seul.org/ | | M E G A Helping Linux become THE choice _\ /_ for the home or office user |