Closed acarioni closed 1 year ago
Since no well established/maintained logging framework or facade for Haxe exists, we are just using the trace
method to output some infos. If you want to suppress these messages you will need to override the trace method and discard them.
Something like this (untested):
final realTrace = haxe.Log.trace;
haxe.Log.trace = function(v:Dynamic, ?pos: haxe.PosInfos ):Void {
if (pos.className.indexOf("hx.concurrent") == -1) realTrace(v, pos);
}
IMHO a library should not assume that printing to the standard output is safe: partly because diagnostic logs are just annoying who is not interested in and partly because a console environment may not be available (see this issue for example, where the error is indirectly caused by haxe-concurrent trying to call trace in the virtual console of Spyder IDE).
On the other hand tweaking haxe.Log just for a single library is a little awkward. Further if haxe-concurrent is not used by an application but by another library (as in my case), there isn’t a unique entry-point where one can redefine haxe.Log safely.
It would be better if haxe-concurrent wraps the calls to trace in a #if HX_CONCURRENT_LOG
block. So only the users who are interested can compile the library with the log enabled.
You are mixing up usage of trace
vs Sys.stdout.write
. We are not printing directly to stdout, we use the trace function from the class haxe.Log
(which actually is for logging). Since the trace function receives all required context information via the pos
argument for you to decide which messages to filter out, the approach I laid out is perfectly valid. Rebinding the trace function is even described in the official Haxe docs https://api.haxe.org/haxe/Log.html
If you are not interested in any traces at all you can use the --no-traces
compiler option as described here https://haxe.org/manual/debugging-trace-log.html#removing-traces
I’m not entirely convinced that using trace as a log surrogate is good idea, but anyway the compiler flag --no-traces can be enough to resolve this specific issue. Thanks for the hint.
haxe-concurrent prints some logs when it starts up (e.g. hx/concurrent/Service.hx:56: [hx.concurrent.executor.TimerExecutor#1] instantiated). Since I include haxe-concurrent in a library of mine, which I then give to customers, they get worried when they see some unexpected messages on the console. Is it possible to avoid these logs?