Re: Error codes
Just to be pedantic... even lazy consensus isn't that fast (3days), but no big deal since we are CTR... On Dec 2, 2011, at 6:33 PM, Stefan Fritsch wrote: On Thursday 01 December 2011, Stefan Fritsch wrote: Any more comments/thoughts? As nobody disagreed, this is now in trunk. I intend to commit it to 2.4 tomorrow. It's already a big step forward and the finishing touches can be done in 2.4.1.
Re: Error codes
On Thursday 01 December 2011, Stefan Fritsch wrote: Any more comments/thoughts? As nobody disagreed, this is now in trunk. I intend to commit it to 2.4 tomorrow. It's already a big step forward and the finishing touches can be done in 2.4.1.
Re: Error codes
On Wednesday 30 November 2011, Guenter Knauf wrote: Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? I am not sure that this is necessary. The error log lines already contain the module name or core. Actually I currently have two scripts, one that tries to identify where to add a number and adds AH, and another one that takes each AH and replaces it with the next free number. So programmers would only need to add AH and run the second script over the source file. The only disadvantage may be that in a list sorted by log number, messages by the same module would not appear next to each other. On the other hand, it should be easy to extend the script to also create a list sorted by module or source file name if that is useful. another suggestion - perhaps add a 3rd char: AHC - core AHM - module then we would have for both core and modules the whole range of error codes ... Sometimes we move code from the core to a module or vice versa. If the code is mostly unchanged, I would want to keep the error message number in this case. So best not encode that in the number, IMHO. If we ever hit the codes, we could either switch to hex or add another digit. Or would it be better to use 5 digits right away? Another thought: Would having the AH0815 numbers verbatim in the source actually hurt search engine users because they get hits on svn.apache.org, github, and whatever. Maybe a macro that hides the actual form would be better? #define APLOGNO(n) AH #n should do the trick. The source would then contain ap_log_error(..., APLOGNO(0815) foo went wrong, ...); which would not produce a hit for AH0815. Thoughts?
Re: Error codes
On Wednesday 30 November 2011, Mikhail T. wrote: On 29.11.2011 23:30, William A. Rowe Jr. wrote: But my point remains, that we allocate each module a block of some 50 codes, such that mod_aaa gets AHM-0049 and mod_aab gets 50-99, etc. How will 3rd-party modules be getting their blocks? One idea would be to have them use other prefixes than AH. But this may be a bad idea if we ever want the number to be used for other things.
Re: Error codes
ap_log_error(..., APLOGNO(0815) foo went wrong, ...); great idea on avoiding svn.a.o search hits.
Re: Error codes
On Wed, Nov 30, 2011 at 01:09, Stefan Fritsch s...@sfritsch.de wrote: On Wednesday 30 November 2011, Guenter Knauf wrote: Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? I am not sure that this is necessary. The error log lines already contain the module name or core. Actually I currently have two scripts, one that tries to identify where to add a number and adds AH, and another one that takes each AH and replaces it with the next free number. So programmers would only need to add AH and run the second script over the source file. The only disadvantage may be that in a list sorted by log number, messages by the same module would not appear next to each other. On the other hand, it should be easy to extend the script to also create a list sorted by module or source file name if that is useful. another suggestion - perhaps add a 3rd char: AHC - core AHM - module then we would have for both core and modules the whole range of error codes ... Sometimes we move code from the core to a module or vice versa. If the code is mostly unchanged, I would want to keep the error message number in this case. So best not encode that in the number, IMHO. If we ever hit the codes, we could either switch to hex or add another digit. Or would it be better to use 5 digits right away? Another thought: Would having the AH0815 numbers verbatim in the source actually hurt search engine users because they get hits on svn.apache.org, github, and whatever. Maybe a macro that hides the actual form would be better? #define APLOGNO(n) AH #n should do the trick. The source would then contain ap_log_error(..., APLOGNO(0815) foo went wrong, ...); which would not produce a hit for AH0815. Thoughts? Any reason *not* to use 5 digits? -- Sent from my toaster.
Re: Error codes
On 11/30/2011 2:09 AM, Stefan Fritsch wrote: Another thought: Would having the AH0815 numbers verbatim in the source actually hurt search engine users because they get hits on svn.apache.org, github, and whatever. Maybe a macro that hides the actual form would be better? #define APLOGNO(n) AH #n should do the trick. The source would then contain ap_log_error(..., APLOGNO(0815) foo went wrong, ...); +1 To me, this is a must. This also adds a somewhat handy anchor when searching for log entries in code that may or may not span multiple lines. -- Daniel Ruggeri
Re: Error codes
On 11/30/2011 2:09 AM, Stefan Fritsch wrote: On Wednesday 30 November 2011, Guenter Knauf wrote: Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? I am not sure that this is necessary. The error log lines already contain the module name or core. You need room for expansion. We will add messages :) If you produced a sequential list of error codes, wouldn't it be more sensical to have all mod_authnz_ldap errors in a contiguous list? I'm not suggesting changing the alpha prefix. Just block out ranges so that any listing of the codes is grouped by module that emits them.
Re: Error codes
On 30 Nov 2011, at 9:21 PM, William A. Rowe Jr. wrote: I'm not suggesting changing the alpha prefix. Just block out ranges so that any listing of the codes is grouped by module that emits them. From my experience, any attempt at grouping some kind of numbering like this normally results a few years later in an attempt to undo the grouping to solve problems caused by the ranges being too small, or running out of numbers of a sensible size. Ideally it should be as simple as possible, run a script and a number will be chosen for you is a lot more convenient, and if a script could warn of duplicated numbers for fixing (think the result of cut-and-paste by someone unfamiliar with the script) that would be ideal too. Regards, Graham --
Re: Error codes
On Nov 30, 2011, at 3:23 AM, HyperHacker wrote: Any reason *not* to use 5 digits? The extra character, or using hex, seems worth the future flexibility. We want to be able to assign new codes, rather than reusing old ones, when error messages change in future versions. Allocating 50 messages to mod_foo might be fine for now, but in httpd version 4.8 we may have all new messages. Not sure we can adequately determine how many is enough to allocate. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: Error codes
On Wednesday 30 November 2011, Graham Leggett wrote: On 30 Nov 2011, at 9:21 PM, William A. Rowe Jr. wrote: I'm not suggesting changing the alpha prefix. Just block out ranges so that any listing of the codes is grouped by module that emits them. From my experience, any attempt at grouping some kind of numbering like this normally results a few years later in an attempt to undo the grouping to solve problems caused by the ranges being too small, or running out of numbers of a sensible size. I agree with Graham here. mod_ssl has 300 messages, so the range per module would likely need to be something like 1000, and with 100 modules, this would mean 6 digits in the number. And tracking one counter per module would make my script way more complex. Ideally it should be as simple as possible, run a script and a number will be chosen for you is a lot more convenient, and if a script could warn of duplicated numbers for fixing (think the result of cut-and-paste by someone unfamiliar with the script) that would be ideal too. The current state is here: http://people.apache.org/~sf/log-msg-numbers.diff http://people.apache.org/~sf/log-msg-numbers.list http://people.apache.org/~sf/log-msg-numbers.scripts.diff Changes to previous are - 5 digits instead of 4 - with APLOGNO() syntax (we really want that, just think of all the archives of the svn commit mailing list) - level debug and above instead of info - now after the s/r/c/p argument and not before the format; this makes the script a bit simpler and don't miss logging calls with multi-line format strings. But the number is now frequently on a different line than the format string. I have put the scripts there, too, but they need some cleaning up. Still todo are at least ap_log_cserror, ssl_log_error, dav_log_err, and everything that has a variable as level parameter. What to do about multi-line log messages that are split over several calls to ap_log...()? Grep prefork.c for 'almost certain server failure' for an example. Maybe just add a number to the first line? This is something that will need manual adjustment. I guess before we commit this to 2.4, all other pending backports should be done. Any more comments/thoughts?
Re: Error codes
On 01 Dec 2011, at 1:28 AM, Stefan Fritsch wrote: I guess before we commit this to 2.4, all other pending backports should be done. Speaking for myself, all my backports are done. Regards, Graham --
Re: Error codes
On Monday 28 November 2011, Rich Bowen wrote: On Nov 28, 2011, at 11:21 AM, Stefan Fritsch wrote: A question on procedure: Do you want to add all error codes at once and then fill in the descriptions or add the error codes as the documentation evolves? If the former, some scripting would probably save a lot of work, too. If it can be done all at once with a script, that would be great. The only concern from there would be the ease of applying that change to earlier versions. Presumably the trunk - 2.4 patch would work pretty well, but - 2.2 would take a lot of work. Not sure that it would be worth it, though. I'm in favor of making this a 2.4-only effort. I am not sure that every debug message needs a code, maybe one could at first only tag those of level info or higher? Or maybe even warning? Ah. Good point. Yes, we should probably skip stuff in Debug, unless it makes sense to add them on a case-by-case basis later on. (Not sure what would justify that, but perhaps some messages are more common than others? More important? More … something.) I would say warn and higher, but perhaps it merits further discussion. Adding them to info now might save hassle later on if we wanted to further document those, and costs us nothing now, except for 6 characters in the log message. What do folks think? Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. The script still misses all occurences where the format string is split into several parts (e.g. over several lines), where the loglevel is not constant but a variable, and possibly some others. Are other folks comfortable with going this way? Add it to 2.4?
Re: Error codes
On Nov 29, 2011, at 6:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. The script still misses all occurences where the format string is split into several parts (e.g. over several lines), where the loglevel is not constant but a variable, and possibly some others. Are other folks comfortable with going this way? Add it to 2.4? +1 -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: Error codes
On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion?
Re: Error codes
Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? another suggestion - perhaps add a 3rd char: AHC - core AHM - module then we would have for both core and modules the whole range of error codes ... Gün.
Re: Error codes
On 11/29/2011 8:58 PM, Guenter Knauf wrote: Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? another suggestion - perhaps add a 3rd char: AHC - core AHM - module then we would have for both core and modules the whole range of error codes ... But my point remains, that we allocate each module a block of some 50 codes, such that mod_aaa gets AHM-0049 and mod_aab gets 50-99, etc.
Re: Error codes
On 29.11.2011 23:30, William A. Rowe Jr. wrote: But my point remains, that we allocate each module a block of some 50 codes, such that mod_aaa gets AHM-0049 and mod_aab gets 50-99, etc. How will 3rd-party modules be getting their blocks? -mi
