-
Notifications
You must be signed in to change notification settings - Fork 263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log Fixes and Improvements #118
Comments
For (2) and (3), I'm not sure it's a great idea for macros to be able to write to files, even a log file, as it could easily degenerate into a denial of service if a macro filled up a partition with data. One solution would be to to use rotating files: when the current file hits a certain size, close it, rename it, create a new one; then, limit the number of rotated files to a half-dozen or so. For (1), I think the issue will be mostly on Windows, since the UNIX shell is pretty consistent in how it handles spaces and quotes. (The rules Bash and Korn uses are arcane, but consistent. :)) |
In regards to preventing macro overrun of the filesystem, why not just use a quota? Before every write operation, just do a FileUtils.sizeOfDirectory() and return error if over ? Of course, give a macro to erase the file(s) as well... Could default the limit to 10 mb with a preference setting the user can change. |
Well, sizeOfDirectory() is a bad choice as it recursively scans the given directory and all subdirectories. That's a bit of overkill. More likely would be single-file constraints since only a single call would be needed. I don't think we want an error returned, though. The macro language doesn't have good error handling and it could be quite disruptive to error out because a log file filled up... |
Well my thought was that we would restrict where the files are saved, like, .maptool/extract or something. The subdir would only be for files MT creates via macro so size of directory should be ok. That and, the one request is for "logging" but other output files would be useful. For instance, I output XP logs for my players every time the XP macro is ran. It's a csv file and written to my google drive and picked up in a Google Sheet for reference. So it's a "log" but I have other files and wouldn't want or need to parse them individually and they are not "rolling"... |
I guess I'm a power user. :) I create symbolic links so directories are where I want them, and I tuck directories and files under application directories to keep things organized (such as putting copies of config files under logs/.copies). I suppose most people don't do that, but if we make such a check on every write, it'll get slow... |
Well, I would do the same (symbolic link from .maptool to google drive location but right now it's my own code/build so I just write to where ever i want :) (I've had this logic in my build for 2 years now lol) The fileutils check is pretty fast, it's not like we're logging web server traffic. IF you are logging that much, then either you'll need to room to store the data (so no or high quota limits) or you'll roll off anything you may need... Maybe it's two macro: PS oh and a util.read because, yea, why not. only allow reads from files in /user/files |
So who is doing the logging? Is it every client? Does that mean every client gets log files even if they don't want them? Is the configuration function (your Overall, I think the idea of logging is good as it has plenty of uses, not the least of which is help in debugging MTscript. But since MTscript is going away, I'm not sure how useful this becomes when MTscript gets replaced. Will there be similar logging available in JS? Most likely, the JS code will use Or maybe MT should have both a |
We use the log files extensively as a record of what happened in the game session. It's our archive. For that, the background of the macros and the code behind them isn't important, but the HTML as rendered in the chat window is vital. |
Yes, we all agree on that. What Jamz is referring to is a separate form of logging that script writers can add to their macro code for "behind the scenes"-type logging. |
@rkathey See #433 if it satisfies this issue? New functions added to log any text at standard log levels to the log file/console. Log files are also now rolling 14 day logs so plenty of time to capture/save archived logs as needed after games. Console is no longer used so item 1 is not an issue now as well. |
@JamzTheMan I'll try it after the RC build for 1.5.2 |
You can technically log to the maptool log via log functions so? Done for now? :) |
Great. Considered Done and part of 1.5.2. |
The text was updated successfully, but these errors were encountered: