<div dir="ltr">I will take it up to discussion within the OTP team and come back with an answer as soon as possible.<div>The idea with the small_int solution is that we wanted an immediate data here to avoid dynamic memory allocation. But I think it would be possible to allow a bigger</div><div>value which still is of fixed size (big int is dynamic).</div><div><br></div><div>I think it would be very good if seqtrace could support use cases like this.</div><div><br></div><div>/Kenneth, Erlang/OTP team at Ericsson</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 23, 2018 at 6:12 PM, Tristan Sloughter <span dir="ltr"><<a href="mailto:t@crashfast.com" target="_blank">t@crashfast.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Ideally we'd have a solution where the individual applications would not<br>
> have to be modified/recompiled but the whole node could be configured to<br>
> send trace data out to a trace collector.<br>
<br>
Mostly. You'd still need to include the app that is capable of receiving the seq_trace messages and formatting spans to be reported from them, but you'd be able to trace any message path without code modifications.<br>
<br>
But yea, I don't know either if it is as simple as letting it use bigints, or what the consequences of doing so would be.<br>
<br>
Hopefully someone on the OTP team sees this and can answer :)<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>