Re: [boost] Boost.Logging: formal review
[mailto:boost-bounces@lists.boost.org]On Behalf Of John Torjo Gennadiy Rozental wrote:
BTW before I start, I recalled couple more issues I forgot to mention in original post:
1. Design: Lightweight interface Log library brings a lot of dependencies. In some case I do not want this if
Care to exemplify? What are the dependencies?
I need to use the library in header. IMO log needs to support/implement some lightweight debug abstract interface Something like:
struct DebugLog { virtual void log( string const& ) = 0; virtual void log( int ) = 0; };
struct Log : DebugLog { ... };
Now I could use DebugLog interface without need to know an implementation. It comes with the price of virtual call. I primarily use this for debug only logging.
Anybody else wants this?
Yes, for me that would be useful.
3. Design: hexdump I believe log library needs to provide support for dumping memory in hex format on log file. It could be an addon to core functionality.
I can add this, even though I'm not sure why you'd want this.
Yes, Yes, I use the log file for an error log. Being able to do a raw (hex) dump of the offending packet would be very useful for postmortem analysis - provided this functionality could still be available in the light-weight version :/
4. Design: logged assert I believe log library needs to provide support for custom assert. Such assert would log into log file and invoke system assert depends in assert level. It could be an addon to core functionality.
Well, I want to adapt SMART_ASSERT to allow for this functionality.
Kind of falls in line with what I said in #3. I want to log the recoverable errors but if it was a non-recoverable error then "log & die" would fit nicely. Kind regards, Matt Scanned by Fortigate {X3BTB534}
1. Design: Lightweight interface Log library brings a lot of dependencies. In some case I do
I need to use the library in header. IMO log needs to
support/implement some
lightweight debug abstract interface Something like:
struct DebugLog { virtual void log( string const& ) = 0; virtual void log( int ) = 0; };
struct Log : DebugLog { ... };
Anybody else wants this?
Yes, for me that would be useful.
Ok, so I understand you want both the normal interface, and the lightweight interface.
3. Design: hexdump I believe log library needs to provide support for dumping
memory in hex
format on log file. It could be an addon to core functionality.
I can add this, even though I'm not sure why you'd want this.
Yes, Yes, I use the log file for an error log. Being able to do a raw (hex) dump of the offending packet would be very useful for postmortem analysis - provided this functionality could still be available in the light-weight version :/
Ok, will do.
4. Design: logged assert I believe log library needs to provide support for custom
assert. Such
assert would log into log file and invoke system assert
depends in assert
level. It could be an addon to core functionality.
Well, I want to adapt SMART_ASSERT to allow for this functionality.
Kind of falls in line with what I said in #3. I want to log the recoverable errors but if it was a non-recoverable error then "log & die" would fit nicely.
Ok, will do. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
John Torjo wrote:
3. Design: hexdump I believe log library needs to provide support for dumping
memory in hex
format on log file. It could be an addon to core functionality.
I can add this, even though I'm not sure why you'd want this.
Yes, Yes, I use the log file for an error log. Being able to do a raw (hex) dump of the offending packet would be very useful for postmortem analysis - provided this functionality could still be available in the light-weight version :/
Ok, will do.
But note that will can bloat the library. Showing hex data is a much harder thing that it seems, just look at the amount of suggestions made by KDevelop users: http://lists.kde.org/?t=112549947100004&r=1&w=2 (BTW, some of the wanted hexdumps exactly for looking at network packets, just like Matt mentions in the previous email). I'd suggest supporting some very simple format, and resisting all user requests to extend it. A separate GUI tool might be better suited for showing hex dumps. - Volodya
"Vladimir Prus" <ghost@cs.msu.su> wrote in message news:dlc4gb$qlb$1@sea.gmane.org...
John Torjo wrote:
3. Design: hexdump I believe log library needs to provide support for dumping
memory in hex
format on log file. It could be an addon to core functionality.
I can add this, even though I'm not sure why you'd want this.
Yes, Yes, I use the log file for an error log. Being able to do a raw (hex) dump of the offending packet would be very useful for postmortem analysis - provided this functionality could still be available in the light-weight version :/
Ok, will do.
But note that will can bloat the library. Showing hex data is a much harder thing that it seems, just look at the amount of suggestions made by KDevelop users: http://lists.kde.org/?t=112549947100004&r=1&w=2
(BTW, some of the wanted hexdumps exactly for looking at network packets, just like Matt mentions in the previous email).
I'd suggest supporting some very simple format, and resisting all user requests to extend it. A separate GUI tool might be better suited for showing hex dumps.
- Volodya
My library prints something like: 00000000 74 65 73 74 | 5F 73 74 72 | 69 6E 67 test_string\n\n .... in total 50 lines of code.
Gennadiy Rozental wrote:
Ok, will do.
But note that will can bloat the library. Showing hex data is a much harder thing that it seems, just look at the amount of suggestions made by KDevelop users: http://lists.kde.org/?t=112549947100004&r=1&w=2
(BTW, some of the wanted hexdumps exactly for looking at network packets, just like Matt mentions in the previous email).
I'd suggest supporting some very simple format, and resisting all user requests to extend it. A separate GUI tool might be better suited for showing hex dumps.
- Volodya
My library prints something like:
00000000 74 65 73 74 | 5F 73 74 72 | 69 6E 67 test_string\n\n ....
in total 50 lines of code.
Well, to print the above text I'd need exactly two lines of code: std::cout << "00000000 74 65 73 74 | 5F 73 74 72 | 69 6E 67\n" << << "test_string\\n\\n\n"; ;-) Seriously, you comment above sounds more like asserting the quality of your implementation, then anything else. Maybe it's a language barrier issue. If 50 lines is enough and those lines are simple, that's fine. What I suggest to select one simple format and don't try to make it customizable at all. - Volodya
"Vladimir Prus" <ghost@cs.msu.su> wrote in message news:dlc9kv$aqn$1@sea.gmane.org...
Gennadiy Rozental wrote:
Ok, will do.
But note that will can bloat the library. Showing hex data is a much harder thing that it seems, just look at the amount of suggestions made by KDevelop users: http://lists.kde.org/?t=112549947100004&r=1&w=2
(BTW, some of the wanted hexdumps exactly for looking at network packets, just like Matt mentions in the previous email).
I'd suggest supporting some very simple format, and resisting all user requests to extend it. A separate GUI tool might be better suited for showing hex dumps.
- Volodya
My library prints something like:
00000000 74 65 73 74 | 5F 73 74 72 | 69 6E 67 test_string\n\n ....
in total 50 lines of code.
Well, to print the above text I'd need exactly two lines of code:
std::cout << "00000000 74 65 73 74 | 5F 73 74 72 | 69 6E 67\n" << << "test_string\\n\\n\n";
;-) Seriously, you comment above sounds more like asserting the quality of your implementation, then anything else. Maybe it's a language barrier issue.
If 50 lines is enough and those lines are simple, that's fine. What I suggest to select one simple format and don't try to make it customizable at all.
I agree. No need for customization. I just gave an example of format I am using: both hex and real data alongsize (they all actually in the same line above). Gennadiy
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Ok, will do.
But note that will can bloat the library. Showing hex data is a much harder
Hex data formatting (or any data formatting) shouldn't be part of the library. Or if it should, it probably means the lib shouldn't be dragging in all that std streams stuff that is supposed to be responsible for formatting...
A separate GUI tool might be better suited for showing hex dumps.
GUI, od, dumpasn1, whatever works for you. Not the library.
I agree. No need for customization. I just gave an example of format I am using: both hex and real data alongsize (they all actually in the same line above).
If the library did do formatted hex dumps chances are I wouldn't use it because it would either be not the format I wanted or so damned complicated it was easier to write the code to produce the format I wanted than to use it.
On 11/15/05, Darryl Green <darryl.green@unitab.com.au> wrote:
Ok, will do.
But note that will can bloat the library. Showing hex data is a much harder
Hex data formatting (or any data formatting) shouldn't be part of the library. Or if it should, it probably means the lib shouldn't be dragging in all that std streams stuff that is supposed to be responsible for formatting...
The proposed Boost.Log library already depends (rightly, IMHO) on iostreams for message formatting and buffering of partially-formatted messages. I can't see why or how this dependency could be reasonably eliminated without major sacrifices to the usefulness of the library. The necessary code to do hex dumps on an iostream should hardly be considered bloat. I agree with Gennadiy's assesment that 50 lines of code should be more than adequate to do it. These can be in a separate header file that is included only by the user. What possible harm could this be? -- Caleb Epstein caleb dot epstein at gmail dot com
On 11/15/05, Caleb Epstein <caleb.epstein@gmail.com> wrote:
On 11/15/05, Darryl Green <darryl.green@unitab.com.au> wrote:
> Ok, will do.
But note that will can bloat the library. Showing hex data is a much harder
Hex data formatting (or any data formatting) shouldn't be part of the library. Or if it should, it probably means the lib shouldn't be dragging in all that std streams stuff that is supposed to be responsible for formatting...
The proposed Boost.Log library already depends (rightly, IMHO) on iostreams for message formatting and buffering of partially-formatted messages. I can't see why or how this dependency could be reasonably eliminated without major sacrifices to the usefulness of the library.
The necessary code to do hex dumps on an iostream should hardly be considered bloat. I agree with Gennadiy's assesment that 50 lines of code should be more than adequate to do it. These can be in a separate header file that is included only by the user. What possible harm could this be?
It would not hard of course, but I think this code does not belong to the logging library. The simplest solution can be easily done by user (i.e. std::string hexDumb(const char* buff, size_t len)) but a flexible solution, as would be expected from boos library is much more complex. For example, in some cases I do not want to print non-ascii characters in hex dump, in others I do. The grouping depends on length of the data worlds I'm working with, and also should be configured, and so on. My point is that the simple solution is not even worth implementing, and general solution is definitely out of scope of logging library. -- Best regards, Zigmar
My point is that the simple solution is not even worth implementing, and general solution is definitely out of scope of logging library.
I do not agree with you on this. Hex dumping is quite frequently required. So it's kinda waste to require every user to reimplement this. Even simplest dump could suffice in many cases. Gennadiy
Gennadiy Rozental wrote:
My point is that the simple solution is not even worth implementing, and general solution is definitely out of scope of logging library.
I do not agree with you on this. Hex dumping is quite frequently required. So it's kinda waste to require every user to reimplement this. Even simplest dump could suffice in many cases.
Hex dump is useful, absolutely, but so is a database access library, but we don't wish it would be a part of the log library, do we? This may be a rough analogy, but as several stated, text formatting of data structures is something that a log *uses*, not *implements*. Sorry for butting in like this, but I strongly feel that hex dump is out of scope for a logging library, and would waste John's precious time, while he could spend it on something that belongs to logging. Yuval
On 11/19/05, Yuval Ronen <ronen_yuval@yahoo.com> wrote:
Hex dump is useful, absolutely, but so is a database access library, but we don't wish it would be a part of the log library, do we? This may be a rough analogy, but as several stated, text formatting of data structures is something that a log *uses*, not *implements*. Sorry for butting in like this, but I strongly feel that hex dump is out of scope for a logging library, and would waste John's precious time, while he could spend it on something that belongs to logging.
Then, maybe, it would be interesting to have one formatting layer in the logging library. Like archives, that is a very nice solution to formatting in the serialization library. What is your opinion?
Yuval
-- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
Felipe Magno de Almeida wrote:
On 11/19/05, Yuval Ronen <ronen_yuval@yahoo.com> wrote:
Hex dump is useful, absolutely, but so is a database access library, but we don't wish it would be a part of the log library, do we? This may be a rough analogy, but as several stated, text formatting of data structures is something that a log *uses*, not *implements*. Sorry for butting in like this, but I strongly feel that hex dump is out of scope for a logging library, and would waste John's precious time, while he could spend it on something that belongs to logging.
Then, maybe, it would be interesting to have one formatting layer in the logging library. Like archives, that is a very nice solution to formatting in the serialization library. What is your opinion?
I don't really know the serialization library, so I can't comment about it. If I understand correctly (and I'm certainly not sure of it), the serialization layer you mentioned is about converting a data structure to an XML representation, and back. That is very different from the log library. The XML representation is used solely for serialization purposes and so it's logical that the serialization library will supply this layer. The log library, on the other hand, uses the general iostream textual representation, so I don't really see what such a formatting layer would do, and what its benefits would be. Yuval
On 11/21/05, Yuval Ronen <ronen_yuval@yahoo.com> wrote:
Felipe Magno de Almeida wrote: I don't really know the serialization library, so I can't comment about it. If I understand correctly (and I'm certainly not sure of it), the serialization layer you mentioned is about converting a data structure to an XML representation, and back. That is very different from the log library. The XML representation is used solely for serialization purposes and so it's logical that the serialization library will supply this layer. The log library, on the other hand, uses the general iostream textual representation, so I don't really see what such a formatting layer would do, and what its benefits would be.
That formatting layer allows the serialization library to have more formatting options(serialization uses iostream, too) in a transparent way. That way we could have two formatting options: hex and textual. It may be too overkill for our problem. But is a possible solution...
Yuval
best regards, -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
Caleb Epstein <caleb.epstein <at> gmail.com> writes:
On 11/15/05, Darryl Green <darryl.green <at> unitab.com.au> wrote:
Hex data formatting (or any data formatting) shouldn't be part of the library. Or if it should, it probably means the lib shouldn't be dragging in all that std streams stuff that is supposed to be responsible for formatting...
The proposed Boost.Log library already depends (rightly, IMHO) on iostreams
My point was just that - the hex formatter is surely something that works on iostreams, not on "logs". Only if the libary didn't rely on iostreams for formatting it would need its own formatting framework. I can see that providing some custom formatters that work with streams is tempting but:
The necessary code to do hex dumps on an iostream should hardly be considered bloat. I agree with Gennadiy's assesment that 50 lines of code should be more than adequate to do it. These can be in a separate header file that is included only by the user. What possible harm could this be?
Scope creep/focus, thats all. I'd really like a solid logging library framework with a stable interface - hanging formatting off it is less critical. I would like to see a bunch of contributed logging lib tools/extensions grow (I'll contribute some) - but adding them to Johns todo list won't help get the library into a state where it can pass review more quickly (imho).
Scope creep/focus, thats all. I'd really like a solid logging library framework with a stable interface - hanging formatting off it is less critical.
I would like to see a bunch of contributed logging lib tools/extensions grow (I'll contribute some) - but adding them to Johns todo list won't help get the library into a state where it can pass review more quickly (imho).
Yes, once I get the (new version of the) library in a useable form, anyone can constribute with such helpers. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
...
Scope creep/focus, thats all. I'd really like a solid logging library framework with a stable interface - hanging formatting off it is less critical.
I would like to see a bunch of contributed logging lib tools/extensions grow (I'll contribute some) - but adding them to Johns todo list won't help get the library into a state where it can pass review more quickly (imho).
+1 -- Alec Ross
participants (10)
-
Alec Ross -
Caleb Epstein -
Darryl Green -
Felipe Magno de Almeida -
Gennadiy Rozental -
John Torjo -
Matt Doyle -
Pavel Antokolsky aka Zigmar -
Vladimir Prus -
Yuval Ronen