topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Sunday April 18, 2021, 4:51 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Reldas [ switch to compact view ]

Pages: [1]
1
Highly recommended.

http://www.torjo.com/logview/

Logging is part of our life. Every non-toy program has some sort of logging, so that if something goes wrong, you'll at least have some idea why.

But soon you discover that too much information is cluttered in your log, and you need to dig deep in order to find what you're interested in. This is where Easy LogView comes in. It helps you filter the information, showing you only what you need.

Wait, there's more! Easy LogView monitors log files real-time (while applications are writing to them). As soon as some application has written some information on the log you're monitoring, if it matches your filter, you'll see it.

While you're monitoring, you can easily change/add/copy/delete filters on-they-fly. Once you've changed a filter, your view updates instantly.

At any given time you can have multiple filters, depending on the information you're monitoring. For example, imagine that you're developing a server application dealing with a database. You can monitor the usual activity +debug messages (one filter), logged on users (another filter), commands received from clients + answers sent back to them (another filter), database sql commands (another filter), debug + error messages (another filter), and who knows what else, sky's the limit!

2
Programmer Libs / Re: JrDebug::WriteToFilename
« on: October 19, 2006, 04:12 PM »
I wasn't very clear was I.

'WriteToFilename' : is not a member of 'JrDebug'.

So I searched the entire installation and found only one reference to WriteToFilename and that was in one of the examples. It seems that it doesn't exist in the currently available version.

3
Programmer Libs / JrDebug::WriteToFilename
« on: October 18, 2006, 05:41 PM »
Does JrDebug::WriteToFilename still exist in the latest release?

Thank you.

4
Programmer Libs / Re: JrDebugLogger - Viewer Speed
« on: May 18, 2006, 03:55 PM »
Thank you. I'll look forward to it. Could you address my zero-overhead post too please.

5
Programmer Libs / Re: JrDebugLogger - Viewer Speed
« on: May 18, 2006, 03:44 PM »
Any news on this matter?

6
Programmer Libs / Zero Overhead
« on: March 09, 2006, 05:13 PM »
The following item is mentioned in the ToDo list:

  • test all code to make sure there is 0 overhead when debugging compiled out

Is this still an outstanding item? I'd be a lot happier knowing this had been thoroughly checked.

Thank you.

7
Programmer Libs / Re: JrDebugLogger - Viewer Speed
« on: March 02, 2006, 01:34 AM »
That would be very welcome. I'm happy to test any changes if necessary.

8
Programmer Libs / JrDebugLogger - Viewer Speed
« on: March 01, 2006, 05:15 PM »
I have noticed that DebugMonitorViewer really hogs the CPU when messages are output in quick succession. This is quite a common occurrence in my application and it is severely affecting performance. On these occasions Task Manager shows that the DebugMonitorViewer process uses 99% of the CPU leaving nothing left for the parent application. It seems that inserting the log rows into the viewer's internal database is just too slow. Even after I exit my application I can see log rows still being added to the viewer as it catches up with the requests.

I believe that there are two issues here. One is the basic speed of adding a row. There seems to be a lot of small memory allocations as rows are added. It would help if larger blocks of memory were allocated less frequently; perhaps that could be an option if you're concerned about reserving too much memory. The second issue is the priority of the viewer process. I think it should be as low as possible by default.

Speed aside, the usefulness of the viewer constantly surprises me and I sometimes wonder how I managed without it.

Thank you.

9
Programmer Libs / JrDebugLogger - Viewer Starts Off Screen
« on: March 01, 2006, 04:29 PM »
A very small bug.

The "Left" attribute in the JrDebugMonitorSettings1.ini file defaults to -1507 which causes the viewer to start off screen with no way of pulling it back. Changing the value to zero solves the problem.

Pages: [1]