Log file in LMMS

[NETMANSKY]

LMMS lacks log file to trap bugs. It will help devs to fix troubles.

[tresf]

Some context #3561 (comment) as to why this is so important, at least on Windows.

[gi0e5b06]

Logs make every thing slow.Logs never help with bugs.
Use qWarning/qDebug when coding/testing.
Use qFatal for runtime checks (during the development phase).
Keep those statements as comments once your code is stable.

Of course, stderr should be visible on every OS. If it is not on Windows, redirect the stream to a file.

[tresf]

Of course, stderr should be visible on every OS. If it is not on Windows, redirect the stream to a file.

No, it's simply not there at all. mconsole is needed. We may need to create an lmms-console.exe for debugging purposes. It's a shitty limitation of the OS unfortunately.

[tresf]

redirect the stream to a file.

For the record though, Wine has access to it without mconsole, so that's what I've used historically, but it's not the same environment, so it's a crapshoot.

[gi0e5b06]

@tresf Check this:
http://doc.qt.io/qt-5/qtglobal.html#qInstallMessageHandler

[tresf]

@tresf Check this: http://doc.qt.io/qt-5/qtglobal.html#qInstallMessageHandler

Context please?

What I'm stating is that the console is gone in a GUI app for Windows. You need to compile it as a console app if you want output and that console will appear until closed. It's a limitation of the OS. What are you suggesting?

[tresf]

@gi0e5b06 Check this:
https://stackoverflow.com/a/3370017/3196753

[gi0e5b06]

Good enough for Windows.

#ifdef LMMS_BUILD_WIN32
	stderr = ::fopen("lmms-err.txt","a");
	stdout = ::fopen("lmms-out.txt","a");
#endif

[tresf]

So logging is only a performance problem when it affects the system you use?

[gi0e5b06]

Writing to a file is faster than writing to the console.
Not really needed for Linux because every user knows 2>&1 1>/dev/null

[tresf]

Logs make every thing slow.Logs never help with bugs.
Writing to a file is faster than writing to the console.

Please explain or stop contradicting yourself. Logs are standard in large applications. If logs are needed for support, they're helpful, regardless of the system. If they drag down the software, they should do it to all platforms equally. Perhaps we disable them by default but these blanket statements are unnecessarily provocative. Please spend more time explaining and less time dropping conversation bombs.

every user knows 2>&1 1>/dev/null

Yet another bomb. Please don't be presumptuous. Making unnecessary and different support structures between end-users makes support more difficult. Also, differentiating behavior requires a larger barrier to entry for people helping. Despite what you THINK YOU KNOW, non-tech people use Linux and Mac and other non-Windows platforms. Your statements are baiting more off-topic banter. Let's do the project a favor and work towards what works, not make blanket statements around the last comment in the thread.

[gi0e5b06]

I write code, not books ;)
No contradiction: doing nothing is faster than writing to a file, which is faster than writing to the console.

I'm not aware of any large desktop application writing logs, and if there is, I don't know where these logs and I never ever looked at them. If anyone is using an other DAW, I would be interested to see what their logs look like.

[tresf]

I know several desktop applications that write logs and they usually live within the user's home directory (e.g. APPDATA on Windows, ~/Library/Application Support on MacOS and ~/.<folder> on Linux). Since none of these applications are DAWs, I'm not sure how relevant they are in a performance conversation (and I've never benchmarked).

In regards to how many DAWs use logs... I don't know any DAW that crashes as often as LMMS, so it may be a loaded question. Anyway... I decided to take a look at Ardour and they ask their users to download a debug build and run it through gdb on Windows. This may be a good compromise for our users, because as others have stated before, the logs usually don't help anyway.

[NETMANSKY]

Gentlemen!
Calm down. I've been watching this debate from the start, but did not interfere with technical specialists. Without a doubt, that the log output to a file is preferable and will make the easy access of users to tech support. Another question is how will logically structured information in the file. Here should seriously consider the format and semantics of the output of technical information that developers do not get confused in them. Controversy and debate are welcome here. But do not forget about the difference in perception between developers and exhausted by the instability of the program users. I read the description of the problem, but absolutely can not understand the problem with the log output to a file. QT really has no tools to output information to a file? Or it can greatly affect program performance? I will assume that users would like to send log to email than to describe the problem on the forum or GitHub. Users a priori do not have sufficient knowledge and developers need to simulate the situation to fix a bug. If a developer would log, so it will have full information about the problem. I'm sure the developers are well aware that LMMS has reached a new level that requires a more serious approach in gathering information. And recording and sharing logs is one of the most convenient ways.
Probably need a debug launch mod...
P.S.
The developers absolutely do not have to join with me in an argument to prove that the logging is difficult and may not be necessary. I respectfully try to help developers to realize that LMMS is already not a simple program for beginners. And gather information for the successful development needs more carefully. I sincerely wish success to LMMS!

[michaelgregorius]

Regarding that "logs make everything slow": if we decided to use logging we must make sure to never put it into any code that's potentially executed from the audio thread anyway. So it would likely only end up in glue code and GUI related code where a few nanoseconds shouldn't matter. However, with the current code base where the distinction between realtime and non-realtime code is not made implementing some logging might therefore lead to audio problems (crackles, dropouts, distortion).

I also disagree that "logs never help". Depending on the application they can be very helpful (I work with log files every day). So as @tresf has already noted we should stop using such blanket statements. Whenever I read such statements I definitively do not think that they are made by (professional) software developer but rather by people who refer to themselves as "coders" or "hackers". Software development / engineering is about much more than just writing code.

[gi0e5b06]

We should distinguish between operation log and error log. I'm OK with logging anything that should be fixed by the user or the developper. I quite disagree on logging qInfo stuff. If your app outputs more than a few lines during a session, there is a problem.
BTW, #3865 is a fine example of what could be logged during the development phase.

@NETMANSKY Qt has qDebug, qInfo, qWarning, qCritical, qFatal). Qt5 adds QMessageLogger. Qt5.6 adds support for syslog and journald.

@michaelgregorius We are talking about desktop application, especially DAWs. And let's not make it personnal (I actually have more experience than you). OTOH, I like several of your patches, including some unmerged ones than I plan to apply soon. So let's keep the good work.

[tresf]

let's not make it personnal (I actually have more experience than you)

The ad hominem isn't tolerated, this is the first warning. Let's keep this civil, please.

[gi0e5b06]

@tresf warning for who? Because I'm saying exactly the same thing than you. Anyway, back to the topic:

• what exactly do you guys want to log?
• why is the Qt logging macros/framework not enough?
• why is a gdb trace is not enough?
• would a core be usefull? (Qt can generate core files)

[tresf]

@tresf warning for who

For this statement: "I actually have more experience than you".

I'm saying exactly the same thing than you

Agreed, we're all saying the same thing objectively, so let's move on.

My thoughts...

From the feedback and points above, the logging doesn't really seem like it will help LMMS at this point. The main reasons are:

1. The software is very unstable. The logs generally do not provide useful information in event of a hard crash.
2. We don't log a lot of user-space information. What I mean is, we don't do a good job today of capturing steps taken by an end-user that would assist with the support-end. The logs aren't verbose enough currently to take advantage of this.

In regards to the other questions....

• "why is the Qt logging macros/framework not enough?" -- I don't think anyone said this.
• "why is a gdb trace is not enough?" -- I don't think anyone said this either. If the Ardour example is sufficient, this may be our best route. We'll need debug binaries.
• "would a core be usefull?" -- No idea. Apple creates core dumps but they're marginally useful. The backtrace is really the gold standard here, I think.

So I think we can close this once we have debug binaries available for download. I'm thinking we can shim this into our travis-ci logic and add some logic so that they show underneath the Beta downloads on our downloads page.

[PhysSong]

Consolidated into #5468.