Hi List I crafted a tiny logging tool consisting of one function and some globals. I'm new to picolisp (and its my first lisp), so feedback and advices are greatly appreciated.
The thing is mainly meant for debugging or logging in server apps. Code: http://beneroth.ch/pil/log.l Features: - turn logging on and off (globally or locally) - different logging levels (debug, info, warning, error) - output goes to stdout or files (configurable for each log level individually) - hook to dynamically change output channel/file - flavour output with timestamp and/or PID ToTest: - not sure if parallel writting to same file could be a problem. I would assume with each call of (out "+file") the file gets opened, written, and closed, so first come first served. Didn't test yet. Other ideas: - not sure how my function is in spirit with the standard picolisp - not sure how this is combatible to the builtin logging functions like (err) and (trace) - it would be nice if (err) output could be redirected to another function, but I think its not possible. maybe if logging would be done in another process, and stdout from the (debugged) process redirect to the logging process? All in all, I was very surprised how short this code turned out. In other languages this would be much larger, or not even possible easily, e.g. to reconfigure settings for some local parts of code. cheers, Andreas > > Hi List, > > sometimes I start putting a lot of (maybe too many) 'msg calls in my > code for debugging purposes, what then triggers memories of logging > frameworks for Java I once read about. > > Would it make sense to add such a logging framework to the language as a > kind of third debugging tool (besides trace and debug)? I was thinking > about something along the line of > > - a new global variable *Log > - two new functions 'log and 'unlog > - an equivalent to ! as debugging breakpoint (e.g. § or whatever as > logging point) > > *Log would then be NIL or one of several logging levels > (e.g. 1,2,3). (log func) would then put § before all expressions of a > function, (unlog func) remove them. Depending on the logging level, § > would do nothing or, e.g., print the expression and the results of > what (e) and (d) do during debugging, and maybe all variables with > their actual values in that expression. > > What do you think? > > -- > cheers, > Thorsten > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
