vegardit / haxe-concurrent

A haxelib for basic platform-agnostic concurrency support
https://vegardit.github.io/haxe-concurrent/
Apache License 2.0
82 stars 14 forks source link

logs on startup #24

Closed acarioni closed 1 year ago

acarioni commented 1 year ago

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?

sebthom commented 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);
}
acarioni commented 1 year ago

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.

sebthom commented 1 year ago

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

acarioni commented 1 year ago

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.