Takeru Ohta

It seems interesting to support `futures`. But currently, `rustracing_jaeger` (and `rustracing`) heavily depends on `std::sync::mpsc`, so it is difficalt to integrated with `futures` smoothly. If your are not annoying to...

@andrewbanchich I think that it's somewhat dangerous to depend on `tokio` heavily because some users (including me) may want to use this crate outside of the asynchronous world (e.g., with...

> Instead of switching the channel implementation to tokio based one, IMO, it seems good to extend Tracer and SpanReceiver to allow arbitrary channel type as a type parameter I...

@andrewbanchich No problem! Thank you for letteing me know that.

Sorry for the too late reply. > baggage items are simply prefixed with something like `baggage-` and then when extracted the prefix is removed. Since this is a convention of...

Thank you for your question. Since I'm busy on weekdays, I'll respond weekend.

> The condition on `insert` makes it such that if you have `"abc"` and insert `"dabc"` you get `"dabc" - sibling -> "abc"` It's not true. Since `self.label() == "abc"`...

(BTW, looking back the code I think that I might be able to use `

In batch sampling mode, solvers would receive multiple `ask` requests before receiving the corresponding evaluation results (`tell`) as follows (assumes the batch size is 3): 1. ask 2. ask (samplers...

FYI: I just created https://github.com/optuna/kurobako/pull/48 to fix CI (lint) failure.