|
Thanks, I'll grab them now.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Last company, we logged everything; enter any method, its name and parameters logged.
I prefer mini-dumps.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
charlieg wrote: I'd like to hear from others what they just know they need to log.
I've always found a stack trace and minidump to be very useful. Combining it with a log only helps to find what the user was doing when the exception occured which might not be of interest.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: Combining it with a log only helps to find what the user was doing when the exception occured which might not be of interest.
This. I'm so glad you wrote this because it so succinctly describes what logging is for - tracking the user's movements through the app, rather than what the app is doing.
Now in my code on my jtagless embeddeds i have to log what the app is doing too, because i don't have a debugger, but generally - i'd say in most cases, you're right to bring this up.
If you're logging things other than the user's movement through the app you just might be using the wrong tool for the job.
Real programmers use butterflies
|
|
|
|
|
Yeah,
Situational awareness via telemetry is also important though. It helps developers learn what features are being used in your application (or operating system). By tracking the user movements through your application (or operating system) you can easily identify which features are not being used.
In the old days developers would add/design features and have no clue that absolutely nobody used it.
|
|
|
|
|
I'm going to remain hopelessly old fashioned in that regard and it has to do with something I wrote to someone earlier.
I won't take part in writing software that surveils users without their continuous and ongoing consent.
Now, gathering telemetry data doesn't necessarily *always* violate that. Figuring out if a feature is being used is kind of benign, but it all depends i guess on the level of gathering of information (are you trying to pick out their relative's birthdays from their contacts?_ and also what are you trying to do with that information? - telemetry is a muddy area for me and one where I'm wary.
At the end of the day, would I be okay with a neighbor looking at me the way the software is? I guess maybe that's a rule of thumb for me, but I just came up with it and i haven't really put it to the test.
But I will not write software that abuses or harms the people that use it, or makes it easier for other people to harm others, where I can help it. For me that covers a lot of ground, and surveilling without their continuous and ongoing consent comes under abusing others - for me.
I'm making moral arguments here, but I am not a believer in an objective morality - only that there's things I can live with and things I can't.
I haven't said any of this in judgment of others. I personally care elephant-all where other devs draw the line, but for me I have a vicious and fickle conscience and I cross it at my peril.
Real programmers use butterflies
|
|
|
|
|
Randor wrote: In the old days developers would add/design features and have no clue that absolutely nobody used it.
True story from the early 1970s: When I first visited the team that wrote the assembler for the machines we built, I asked about some of the more arcane pseudo-ops. Things like controlling listing width.
Turns out they were "sacrificial". There were features the devs wanted but management didn't grok, and the devs knew there would be pressure to trim the feature list. So they threw in a bunch of useless ones, so they could be noble later and trim the list at management's request (keeping their goodies, of course). The trimming wasn't perfect...
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I take a little bit different approach to logging. I work on automation systems and I have multiple levels of logging going on simultaneously. I'll mention just a couple. One is the trace buffer. It's always going and is essentially major events of note. The next one is what I call debug messages. These work like traces but have a mask associated with them that can be changed at run-time. The masks are bit-oriented and each bit is associated with a given functional aspect of the system. There are about two dozen of them defined now and there can be up to 63 because the zero bit is always set on. I wrote a special facility for this that uses shared memory to buffer up a whole bunch of messages and access is controlled by a mutex so multiple processes can use the same buffer. As it turns out, this is really, really fast which was my primary goal. I have measured the overhead for each message to be less than one microsecond on my old laptop. The same test was performed using printf calls to a console and the overhead was measured to be greater than 12uS. Writing directly to a text file is unacceptable for a variety of reasons. I tried that a few decades ago and abandoned it entirely. My systems involve multiple processes, each with multiple threads, and I worked for a long time to come up with a mechanism that solves all the problems and I'm pretty happy with this one. There's a lot more to it but I'll stop there.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
This is similar to what I do. I avoid mutex overhead by using a std::atomic_uint32_t as an index into a circular trace buffer, with each of its entries simply being a pointer to whatever holds the captured information.
|
|
|
|
|
Perhaps "time travel/reverse" debugging would be useful
|
|
|
|
|
That's very useful for debugging but out of the question on a live system. I can't count the number of times I've stepped over a function call, assuming the problem had to be further down, only to discover that I should have stepped into that function, and now the entire scenario has to be rerun from the beginning. 
|
|
|
|
|
Perhaps I do not understand time travel debuggers as I have yet to utilize one. Please permit me to inquire further re your response. Would not a time travel debugger permit stepping backward and entering the function you refer to after having discovering there is where the problem lies without having to restart? Thank You Kindly - Cheerio
|
|
|
|
|
I haven't used one either, but I think your characterization is accurate. My point was intended to mean that I wish I had been using one on many occasions.
|
|
|
|
|
May I please inquire what is meant by a "live" system. Is it that which is in the hands of final users? If so is not the logging performed by a time travel debugger in such a situation equivalent to any logging which might otherwise occur? Best Wishes - Cheerios
|
|
|
|
|
Yes, by "live system", I meant one in the hands of an end user. There's no way anything like a time travel debugger will be running on such a system. For one thing, it would cause it to run way too slow. Even if it didn't, how many users would let you connect to their system to do debugging? Their system would have to sit there, halted at a breakpoint that you were previously allowed to set, until you could do your debugging. And then you'd be dealing with a release build, and they're a total buttpain to debug because of compiler optimizations, no symbol tables, and so forth.
|
|
|
|
|
ah, yes, another religious discussion!!
printf, nothing else than printf.
I'd rather be phishing!
|
|
|
|
|
logging *is* religious which is fine. it's why I asked the question. I'm going to grab all these comments and see how I can fold the ideas into something useful.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Greetings and Kind Regards May I please inquire how you spend your time while your project is building? As for myself I twiddle my thumbs or watch a portion of a Star Trek episode or stream music or merely surf Cheerios
|
|
|
|
|
Well, I work on three other projects, defrag my hard drive, brush my teeth... 
Depending on how big the system is, most of us scratch ourselves. Anyone want to back me up? 
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
What's your build time?
As a C# developer working with Visual Studio it's pretty much instant, so I guess I let out a sigh of relief that I didn't get any build errors 
It takes a little longer on the build server, but I'm not really interested in waiting for that so I just continue to work as usual.
It's not like I'm out of work after every commit I make to my build server 
|
|
|
|
|
It is time you to move on to some serious project...
To check a simple feature the build is instant, but a full version build is almost 15 minutes - fortunately it is done on a build machine so I have time to do other things on my computer...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
I don't think I want to work on those kinds of projects 
I have 5 minute builds, but only on the build server, those are still instant on my machine.
Most of those five minutes are downloading NuGet packages anyway.
I've worked with longer builds in the past, but those were mostly badly designed applications or multiple services in a single repository.
For one project I had a really long local build, like 30 seconds, and I don't think I've ever figured out what the problem was
|
|
|
|
|
I absolutely agree. I have several programs ERP, Production (this one interacts with AutoCAD), Maintenance, Human Resources, a MySQL - MariaDB query browser,... and when working on one of them compiling time never takes more than 10 secs (ERP or Production). These two have close to 700,000 lines of code each.
I have a Core I7 8 core 9th generation processor, 32 GB RAM, 6 GB graphic card (useless for compiling). When I am using my home laptop for the same task, its about one and a half minutes.
So I think the time required for long compiling times are several things. The power of the developing machine; the number of lines to be compiled; the number of external DLL, .h,... to be linked, etc. But definitely, the machine is a VERY IMPORTANT one.
My 2 cents.
Work hard and honestly and you will be rewarded by your own satisfaction.
|
|
|
|
|
The question is: Have you made yourself dependent on the results of that 15 minute build to go on with your next task?
If you deliver a submodule that is syntactically correct, passes basic (read: fast) module tests, and honors all external interfaces, chances are that the best you can do is to go on to the next bug fix or functional extension, without waiting for the system build to tell you that everything is OK.
|
|
|
|
|
trønderen wrote: Have you made yourself dependent on the results of that 15 minute build to go on with your next task?
Absolutly not... That would be a disaster... The big build initiated when someone aprove a pull request an it blocks noone and nothing...
I can move to the next task or even more take a break 
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
