Mudlet - Forum

Mudlet could really use help the following tasks;

Have scripts keep their scrollbar position (C++)
If you save a script, it's scrollbar position will be reset to the top. Annoying if you're working with large scripts! bug #660936.

Mudlet ↔ Lua unicode support (Lua, C++)
Mudlet supports unicode internally, but to have full support for it through the client and scripting, the last piece needs to be done: support of it in Lua. What needs to be done is a bridge that will transcode all text passed to and from Lua functions to Mudlet. If you'd like to work on it, discuss with Heiko on the implementation details. See also: LuaUnicode.

MUSHclient → Mudlet XML & Lua converter
Many users aren't starting with Mudlet from scratch but are coming over from other clients. MUSHclient is one of them, and with great Lua support, porting scripts over from it is relatively easy but still a task. An automatic converter for this would make peoples lives a lot easier!


If anyone can help us out on any of these, it would be very much appreciated! Should you like to start on a task, please post about the intentions in the thread (or in a separate one) such that we don't have duplicate efforts & people can help out with the knowledge they have.

I'm gonna tackle the database frontend.

And I'm giving the logging framework a shot.

EDIT: I only saw right now that hempa already volunteered for that. If (s)he wants to take it, that's fine by me too of course.

I already have my own logging scripts, and I'd be willing to provide them. It doesn't do timestamps and a few other things yet (html logging, etc.), but I'd be happy to work such things in. Or any other requested features.

Some question to consider:
- File names. Should they be automatically generated (e.g.: os.date('%Y-%m-%d')..".txt"), or should they be given to a startlog() function as an argument, or something else? (Paths are probably best given via an argument to this function.)
- log rotation: Personally, I have mine just set up to create a file containing the date when I started the log, and everything I log then until I close the log will be logged to that file. Is it preferable if at midnight the log is closed and a new one is started?
- Preferred format of timestamps?
- How to determine when logs are to be opened and closed. The easiest option is of course to just leave it to the user, and give two functions (startlog, stoplog, or something) to do that. When you want to log everything, triggering the startlog is generally easy. The stoplog is a bit trickier, since you can't trigger it off any message from the MUD, we don't have an "ondisconnect" event yet, and triggering it off a quitting alias (such as "qq") has its problems too, such when the quitting process is aborted by something, or when you are disconnected without actively quitting. Personally, I'm also using a custom "isconnected()" function for this, which is run 15 seconds after I type "qq" (return os.execute("netstat | grep achaea") == 0), but that's a rather messy approach and -very- slow.


P.S.
Here, my three still very basic logging functions: startlog() opens the log file and enables my logging trigger. writelog() is called by said logging trigger and writes the current line. closelog() closes the log file.

Hey Iocun
If you feel like expanding your log framework, feel free. You already have some functions set up, so it would be unpractical for me to reinvent the wheel don't you think? If you're on the IRC, poke me (I'm Regi) and we can discuss thoughts around this.

We want to give the user the freedom to choose. If they don't want to specify a log file name, it should be automatic from the current date. We also want to give them the chance to log the whole thing as html so they can save colors, but that's a bit more complicated, not sure we want to do that (how slow would that be?). A log rotation is needed, in my opinion. Either we use log rotation per session, so each new session starts a new log, or we use a log rotation at midnight. It should also be a possibility for the user to save to a file that does not rotate or do anything, but instead have timestamps for each line.. Lots of options here!

As for your mention of checking if you're connected, that only works if you're on a *nix box. I'm all in favour of a ondisconnect event.

Okay, my db wrapper is available at

http://bazaar.launchpad.net/~mudlet-cru ... e/db/files

You can download it individually or just bzr branch lp:~mudlet-crucible-drivers/mudlet-crucible/db

This should be considered experimental. The branch contains both the code (600-ish lines, just copy/paste into a mudlet profile and save), and documentation.

Let me know if you run into any problems or if there's stuff you want that it can't do (it can't do JOIN's as of yet and won't until I do some other stuff, namely date-time support). Feedback on syntax is welcome too, but note: I -wanted- to do lua expressions and convert them into SQL, but that's not feasible with how Lua implements operator overloading.

--ix

I'm sort of wanting something more... comprehensive, from a logging framework.

I want to, for example, put on the top of any script of mine:
Then throughout my code, I can call:
With log:info, log:warn, log:error, log:critical, too.

Now, probably by default? All of this stuff just goes into a bucket and disappears.

But, if someone goes and does: logging:start_logging() it'll start writing the stuff to a file. But by default, only stuff which is 'warn' or worse.

It'd probably have a default date-based filename, but you could overwrite that. But more importantly, there's a 'tree' of loggers.

root->crucible->autosipper.

And you can start_logging() at any of those levels, with their own filename. So if I'm doing crucible debugging, I might do:
Or something like that. My db code would have a "mudlet.db" logger, and would write out all the queries and various things to it-- but normally it'd just go to oblivion right away.

What I'd -really- like in such a situation is to attach to the 'root' of the logger tree something which doesn't write to any file, but -- by default -- writes to the debug window for warn+ events.

Oh, the purpose of that metadata, is I'd want like you to define what it looks like this way:

log:set_format("${timestamp} [${levelname:8}]: ${message}")

Each level in the tree can have its own format. In the db code, I might have ${database_name} and such.

But, I'm not sure if what I'm looking for / interested in is what others are

As for the database library-- its "done", and provided no one finds any nasty bugs, should be in 1.0.6. The previous version had a couple things missing (notably, timestamps and plus Vadi found me a couple bugs)

You can download the latest at http://bazaar.launchpad.net/~mudlet-cru ... e/db/files

And the latest docs are in Vadi's dev-version of the next manual at http://dl.dropbox.com/u/84880/mudlet_do ... on.html#db

@ixokai: I think that your proposal for a logging framework would be very good.

I'm probably insane, but I'm gonna try my hand at unicode support.