<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 16 Aug 2019 at 10:43, Raimo Niskanen <<a href="mailto:raimo%2Berlang-questions@erlang.org">raimo+erlang-questions@erlang.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Thu, Aug 15, 2019 at 06:44:43PM +0200, Torben Hoffmann wrote:<br>
> Hi Micael,<br>
> <br>
> I'm very biassed here, but apart from my creator fondness many of my<br>
> colleagues are very happy about the approach that my Chronos library takes<br>
> when it comes to timers.<br>
> <br>
> <a href="https://github.com/lehoff/chronos" rel="noreferrer" target="_blank">https://github.com/lehoff/chronos</a><br>
<br>
I notice that in that README.md you compare Chronos with the timeout feature<br>
in gen_server and gen_fsm.  The timers in gen_statem were specifically<br>
designed to remedy most of their shortcomings.<br>
<br>
So, from a usability point of view, can you elaborate what Cronos<br>
can do better than gen_statem timers?<br>
<br></blockquote><div>I have a todo to update the README.md to cover gen_statem as well - thanks for reminding me!</div><div><br></div><div>I have worked a lot with gen_statem - absolutely a very good component and easy to work with.</div><div>But the problem of mocking still remains the same.</div><div>When testing I prefer to mock time so that I don't have to wait for the timeout to occur.</div><div>Furthermore, I'm so heavily influenced by my ten years at Motorola that I want the timers to stand out as in all the nice SDL diagrams in the standards shows.</div><div>That means that I want an easy way to check that a timer has been started (mock the call to chronos:start_timer()) and then an easy way to induce the expiry of said timer without having to wait for whatever the delay is.</div><div>When you have timers in the minutes range you just don't want your automated tests to wait it out.</div><div><br></div><div>If there is a way to avoid this with gen_statem I'd be most interested!</div><div><br></div><div>Cheers,</div><div>Torben</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> <br>
> Basically, don't use the internal timers, but do read the full README from<br>
> Chronos.<br>
> <br>
> Very happy to assist you and improve anything in Chronos, if you find it<br>
> confusing.<br>
> <br>
> Cheers,<br>
> Torben<br>
> <br>
> On Thu, 15 Aug 2019 at 13:35, Micael Nussbaumer <<a href="mailto:micaelnussbaumer@gmail.com" target="_blank">micaelnussbaumer@gmail.com</a>><br>
> wrote:<br>
> <br>
> > Hi, first time poster (but I've read many threads in here).<br>
> ><br>
> > How does one usually test gen_statem internal timer events?<br>
> > Usually you test the effects of the behaviour somehow, and I can test<br>
> > that. But in this particular case I had a situation where timers with uniq<br>
> > references are created, later on they usually get removed and all is fine -<br>
> > they're created for each extra worker started and at some point the worker<br>
> > is removed by the timer event that trigger checking some conditions.<br>
> ><br>
> > I noticed after that, the way I had written it, if an extra worker was<br>
> > started then died for some other reason than the timer event taking it out,<br>
> > I could theoretically accumulate timers that wouldn't be removed, I've<br>
> > since then corrected that but still I have no tests ensuring me that it<br>
> > actually works.<br>
> > So my question is if there's any even way to test it (even if with<br>
> > tracing)?<br>
> > Thanks<br>
> ><br>
> > *M*icael *N*ussbaumer<br>
> > artistic portfolio <<a href="http://cargocollective.com/micaelnussbaumer" rel="noreferrer" target="_blank">http://cargocollective.com/micaelnussbaumer</a>><br>
> ><br>
> <br>
> <br>
> -- <br>
> <a href="http://www.linkedin.com/in/torbenhoffmann" rel="noreferrer" target="_blank">http://www.linkedin.com/in/torbenhoffmann</a><br>
> @LeHoff<br>
<br>
<br>
-- <br>
<br>
/ Raimo Niskanen, Erlang/OTP, Ericsson AB<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><a href="http://www.linkedin.com/in/torbenhoffmann" target="_blank">http://www.linkedin.com/in/torbenhoffmann</a><br></div>@LeHoff<br></div></div></div>