Forums » Suggestions
Request for a lua only logging function
It would be helpful if we (plug in coders) had a simple logging function availible
perhaps in the form LuaLog(text)
Function would be write only to a separate log in the main vendetta directory (Lua.log ?)
Output can be limited to strings only with no formatting
Function should automatically append a newline after each string.
Currently I am using this but in the long run a more universal function would be better.
function Dbg.Log(message)
table.insert(Dbg.ErrorLog , (message .. "\n"))
local RoidNotes = spickle(Dbg.ErrorLog )
SaveSystemNotes(RoidNotes, 411411411411 )
end
perhaps in the form LuaLog(text)
Function would be write only to a separate log in the main vendetta directory (Lua.log ?)
Output can be limited to strings only with no formatting
Function should automatically append a newline after each string.
Currently I am using this but in the long run a more universal function would be better.
function Dbg.Log(message)
table.insert(Dbg.ErrorLog , (message .. "\n"))
local RoidNotes = spickle(Dbg.ErrorLog )
SaveSystemNotes(RoidNotes, 411411411411 )
end
Insofar as a "log" is concerned, what are you trying to accomplish that errors.log can't already do?
If you're wanting to be able to pull out only your plugin specific messages, you could always preface them with some characters to identify your plugin lines and then later grep for lines that begin with that.
Also, using SaveSystemNotes() so frequently is a huge cycle hog, especially as the data being written grows. And an alternative to spickle() which might be faster (I haven't benchmarked this) would be to use table.concat(RoidNotes, "\n")
If you're using this to watch debugging messages during testing, my preferred approach (on Linux) is to open a separate terminal that runs "tail -f errors.log" so I can watch the logs in real-time.
If you're wanting to be able to pull out only your plugin specific messages, you could always preface them with some characters to identify your plugin lines and then later grep for lines that begin with that.
Also, using SaveSystemNotes() so frequently is a huge cycle hog, especially as the data being written grows. And an alternative to spickle() which might be faster (I haven't benchmarked this) would be to use table.concat(RoidNotes, "\n")
If you're using this to watch debugging messages during testing, my preferred approach (on Linux) is to open a separate terminal that runs "tail -f errors.log" so I can watch the logs in real-time.
The errors log has all the comm channel traffic which makes reading rather a pain.
I agree on the system notes issue - The function would avoid the whole situation which is the point of it.
I haven't tried using any of the Linux debugging stuff -- Sadly That part of my experience has been on windows. Is that a gdb command or something from an IDE?
I agree on the system notes issue - The function would avoid the whole situation which is the point of it.
I haven't tried using any of the Linux debugging stuff -- Sadly That part of my experience has been on windows. Is that a gdb command or something from an IDE?
LOL pakettle
Learn some linux. Even a 5 year old on linux knows what "tail" is. It's literally the basics of the linux OS itself.
http://man7.org/linux/man-pages/man1/tail.1.html
Learn some linux. Even a 5 year old on linux knows what "tail" is. It's literally the basics of the linux OS itself.
http://man7.org/linux/man-pages/man1/tail.1.html
https://stackify.com/13-ways-to-tail-a-log-file-on-windows-unix
Take notes of the methods that let you filter on the fly.
Take notes of the methods that let you filter on the fly.
All of those ways on Windows is giving me a headache. Just install cygwin and run tail from cli as if it's linux.
That would be another way, a perhaps even a useful suggestion.
But do not assume that every one else suffers your same set of limitations.
But do not assume that every one else suffers your same set of limitations.
lol the author of that article is also the developer and CEO of Stackify. No wonder he's aggressively pushing it to the front. He has dollar signs in his eyes.
PaKettle, If you want, since you are using windows, I could just make something that combs through errors.log for you and seperates the plugin log from the noise, provided some kind of way to identify it as your plugin's is available.
Luxen, such a program already exists. It's called 'grep' and there is a Windows version.
Uh sorry guys I dont have time to keep up with every little new linux function that comes along.
(Tail is circa 2016).
Hell I havent had time or reason to dig thru gdb yet and I actually use to do assembler work. Use to being the operative....
The code I listed is simply what I am using currently as a substitute.
If the Devs add the function they actually dont need to store the output strings - they simply need pass them on to the OS and append the strings directly on to the end of the file with a newline attached.
I use to be like you - Had the time and talent to rip thru thousands to tech memos and always on top of the latest and greatest. I hope time is far kinder to you then it has been to me....
(Tail is circa 2016).
Hell I havent had time or reason to dig thru gdb yet and I actually use to do assembler work. Use to being the operative....
The code I listed is simply what I am using currently as a substitute.
If the Devs add the function they actually dont need to store the output strings - they simply need pass them on to the OS and append the strings directly on to the end of the file with a newline attached.
I use to be like you - Had the time and talent to rip thru thousands to tech memos and always on top of the latest and greatest. I hope time is far kinder to you then it has been to me....
Uh sorry guys I dont have time to keep up with every little new linux function that comes along.
(Tail is circa 2016).
Circa 2016? WRONG.
It first appeared in PWB/UNIX, and when was that? 1977. Hell that's long before I was born and probably before you even started programming.
That said, I find it silly (and I am sure the future you would agree too) that you're tip-toeing around tail as if it's some kind of hippie modern stuff that only the millennial generation would understand.
Here is exactly how you use it. Assuming that you have a terminal open in linux:
$ tail -f <path to errors.log>
THAT'S IT. No installation needed, since it's a core part of the OS since 1977.
(Tail is circa 2016).
Circa 2016? WRONG.
It first appeared in PWB/UNIX, and when was that? 1977. Hell that's long before I was born and probably before you even started programming.
That said, I find it silly (and I am sure the future you would agree too) that you're tip-toeing around tail as if it's some kind of hippie modern stuff that only the millennial generation would understand.
Here is exactly how you use it. Assuming that you have a terminal open in linux:
$ tail -f <path to errors.log>
THAT'S IT. No installation needed, since it's a core part of the OS since 1977.
No - But I will stomp right over your argument right now and say the matter is not relevant.
I am asking for a separate log so player coders dont have to wade through a mile of VO output to get the data we want. How I choose to view it is not the issue
I am asking for a separate log so player coders dont have to wade through a mile of VO output to get the data we want. How I choose to view it is not the issue
As draugath already patiently explained, grep is how you get the data you want from errors.log without wading through a mile long output.
We cannot help you if you are too arrogant and slothful to learn how to use the simple proven tools already available to you since 1977.
We cannot help you if you are too arrogant and slothful to learn how to use the simple proven tools already available to you since 1977.
+1
1) I am not opposed to more file access options for vo, for logs and otherwise. I think that persistent storage options are very limited for plugins.
2) but, I think your use case is a weak argument for this feature.
3) you could program vo to limit extraneous output to errors.log,
4) use common, standard, utilities, to filter and display errors.log
5) make a program from scratch, in either a common language (javascript) or your preferred language (Lua, running local, external to vo).
1) I am not opposed to more file access options for vo, for logs and otherwise. I think that persistent storage options are very limited for plugins.
2) but, I think your use case is a weak argument for this feature.
3) you could program vo to limit extraneous output to errors.log,
4) use common, standard, utilities, to filter and display errors.log
5) make a program from scratch, in either a common language (javascript) or your preferred language (Lua, running local, external to vo).
I am in support of giving plugins the ability to write arbitrary data to plugin-specific files, so that we can stop using system notes as a workaround for that. That would make this suggestion obsolete, since you could then make a log that way if you really wanted one.
I'm not in support of wasting dev time on specifically creating a per-plugin log file. The tools for dealing with this problem already exist. I'm only familiar with the Linux stuff (since I'm a sane person) but I'd be very surprised if there isn't already Windows GUI software that can monitor a file in real-time and filter the output based on pattern matching. Maybe you can find one by googling "windows logfile monitor" or so. Or just use the Windows versions of tail and grep.
I'm not in support of wasting dev time on specifically creating a per-plugin log file. The tools for dealing with this problem already exist. I'm only familiar with the Linux stuff (since I'm a sane person) but I'd be very surprised if there isn't already Windows GUI software that can monitor a file in real-time and filter the output based on pattern matching. Maybe you can find one by googling "windows logfile monitor" or so. Or just use the Windows versions of tail and grep.
Having a per plug in io file would be great and your right it would render this pointless but the Devs don't seem to be so inclined. It may be the potential for abuse or simply a time issue...haven't heard.
This would effectively be a copy of the console_print function with a new name and a different output destination. Barring a severe outbreak of OCD it should not be that big a job but as Incarnate has pointed out no one ever really knows for sure until the job actually starts...
Joker - Grep is a great tool when your looking for specific stuff.... But still irrelevant. Please take your wounded pride and go sit somewhere quietly....You obviously never spent much time looking for bugs.
This would effectively be a copy of the console_print function with a new name and a different output destination. Barring a severe outbreak of OCD it should not be that big a job but as Incarnate has pointed out no one ever really knows for sure until the job actually starts...
Joker - Grep is a great tool when your looking for specific stuff.... But still irrelevant. Please take your wounded pride and go sit somewhere quietly....You obviously never spent much time looking for bugs.
PaKettle, you are understandably miserable and bitter because of certain life circumstances, but that doesn't mean you should be throwing hissy fits at people who are genuinely trying to help you and accusing them of unbecoming things.
You seem utterly oblivious on how to use tail and grep together effectively in this scenario, so I'll give you another big hint on a silver platter.
Append an unique string to your debugging messages, something like
"(pakettle_debug): " + debug message
And then after piping the result from tail, you grep for "(pakettle_debug): ". BAM the only visible lines are your debug messsages that got printed.
Yes, all of this is very much relevant, because we do NOT want the devs to waste their precious time getting sidetracked implementing something if there are already effective ways to do it without their involvement.
You seem utterly oblivious on how to use tail and grep together effectively in this scenario, so I'll give you another big hint on a silver platter.
Append an unique string to your debugging messages, something like
"(pakettle_debug): " + debug message
And then after piping the result from tail, you grep for "(pakettle_debug): ". BAM the only visible lines are your debug messsages that got printed.
Yes, all of this is very much relevant, because we do NOT want the devs to waste their precious time getting sidetracked implementing something if there are already effective ways to do it without their involvement.
Yeah, the complete command would be something like this:
tail -f errors.log | grep 'pakettle_debug'
And according to the link Roda posted, you can do something very similar with PowerShell:
Get-Content errors.log -wait | where { $_ -match “pakettle_debug” }
tail -f errors.log | grep 'pakettle_debug'
And according to the link Roda posted, you can do something very similar with PowerShell:
Get-Content errors.log -wait | where { $_ -match “pakettle_debug” }