Forums Feature Suggestions /debug -h, ON DEBUG, $debug(N).prop

Checked the board and didnt see this suggested yet. How about adding a -h switch to /debug so it can write directly to a specified hash table(s). If the hash table doesnt exist, it is created. Otherwise, it is appended to. Normal /hash commands could then be used to manipulate the data written to the hash tables.

...actually, how about an on DEBUG event as well. I realize that you can specify the -i switch with /debug, but that calls an identifier you specify before logging happens and its return value is used as the debug line. ON DEBUG would work exactly like this, but a return result isnt required. $1- would be the line that triggered ON DEBUG, and wildcard/regex can also be used, much like ON TEXT/ACTION, even halting the event output, which would prevent debug from writing to whatever data source. Since current /debug calls are server independant, extend the $debug identifier to $debug($cid). This could have an .event property (just like $event, by parsing the incoming/outgoing debug line internally). By combining ON DEBUG, with $debug(N).event you could simulate event triggers by checking $debug().event and firing off a signal.

Ok, I think Im good. Thanks!

I dont really see a logic to saving debug info to hashtable , what would the ITEMNAME's be?

Anyway everything you suggested can be done already by simply using the /DEBUG -i option, excluding the ON DEBUG event, which would be able to be caught by muiltiple handlers, but really how many scripts handle debug info anyway.

1) The -i option requires an identifier and its return value is used as the debug line being logged. What if I dont want to return anything? Return null maybe, but will that work?

2) Using multiple handlers is fine, but, can you write to the debug log yourself? I couldnt. Using a @window would work for manipulation, but it just seems that if /debug offers multiple output methods by utilizing whats already internally built in, hash tables could also be utilized.

3) The item names, got me there, but what about using the servername + date/timestamp via $encode() perhaps.

Debug might not be widely used. But perhaps it might be if it was extended to allow more control/flexibility. /debug just seems to feel like when you do try to utilize the data it provides, you usually end up having to script more than feels necessary to use it effectively. I think an event for just this reason would be perfect.

1) prety sure if u dont return anything it doesnt log a line (or logs a blank line)

2) I have had no trouble writing to any/all debug files, hash tables could be utilized i never said they couldnt I just ddint see the point, the data is linial (sp?) in nature so suits a window rather than a hashtable

3) Since you would need to have a finer resolution tan seconds, you would need [servername + date + time + index] to cover each second debug comes in , this in turn would require you to do a lot of $hfind's or use a lot of $hget().item's to read the data back for any purpose. again the data is far more suited to a linial storage.