<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Ah yes, dependencies! I see your problem now. <br>
<br>
We're using gen_statem for a test framework written in elixir for telecoms. The FSM has been the least of our problems.<br>
<br>
I'm always amazed at the range of Erlang versions still in use. I keep forgetting that.<br>
<br>
Oliver <br>
<br><br><div class="gmail_quote">On May 4, 2018 8:25:35 AM EDT, "Heinz N. Gies" <heinz@licenser.net> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Oliver,<div class="">I am not advocating to forbid migrating code to gen_statem when the maintainer feels it is an improvement for their code. I’m advocating for not forcing maintainers doing so for no reason.</div><div class=""><br class=""></div><div class="">Karolis brought up another very good point I didn’t even think about. Code written with gen_statem will not be able to run on older erlang releases. While that’s probably not a issue on your own code where you control the releases completely it’s a nightmare for open source and libraries.</div><div class=""> <br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 4. May 2018, at 14:12, Oliver Korpilla <<a href="mailto:Oliver.Korpilla@gmx.de" class="">Oliver.Korpilla@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Except for the init bug in 19.0 (which our infrastructure was fixed on for a long time) we found migrating to gen_statem a painless experience with decent improvements. But maybe we simply use a different or limited feature set? <br class="">
<br class="">
Oliver<br class=""><br class=""><div class="gmail_quote">On May 4, 2018 8:03:11 AM EDT, "Heinz N. Gies" <<a href="mailto:heinz@licenser.net" class="">heinz@licenser.net</a>> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I have thought of that but I don’t think that’s a real option. Deprication warnings are important, this would turn all of them off which doesn’t help code quality. I want to know if something is deprecated and fix it in most cases. But as Karolis pointed out, it’s easy for a function or two but for a whole behaviour it’s nearly impossible.<div class=""><br class=""></div><div class="">It basically creates two erlang worlds, pre-statem and post-statem.</div><div class=""><br class=""></div><div class="">The stack trace is not great but it’s not as bad, it’s somewhat possible to just wrap the whole function calling it into a ifdef and call it a day. Not great it still is a decent amount of code duplication but it’s possible. <a href="https://github.com/Kyorai/clique/commit/b0e89de3cbb56396b59a1023903c7259ec2ef145#diff-7a19efbe2afedfb64aa7ec6690e9a13e" class="">https://github.com/Kyorai/clique/commit/b0e89de3cbb56396b59a1023903c7259ec2ef145#diff-7a19efbe2afedfb64aa7ec6690e9a13e</a> would be an example. It’s more annoying then other changes but not nearly as bad as the gen_fsm</div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 4. May 2018, at 13:58, Roger Lipscombe <<a href="mailto:roger@differentpla.net" class="">roger@differentpla.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On 4 May 2018 at 12:07, Karolis Petrauskas <span dir="ltr" class=""><<a href="mailto:k.petrauskas@gmail.com" target="_blank" class="">k.petrauskas@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class=""><div class="">I agree with Heinz. The deprecation of gen_fsm forced me to stuck on OTP 19 and I dont see any reasonable path to upgrade.<br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">We upgraded successfully to OTP 20 (and compiled against OTP 21) by simply adding the following to the top of our gen_fsm modules:</div><div class=""><br class=""></div><div class="">-compile([nowarn_deprecated_function]). % gen_fsm is deprecated; use gen_statem</div><div class=""><br class=""></div><div class="">It'll be a problem when gen_fsm is *removed*, but until then, we'll stick with this.</div></div></div></div>
</div></blockquote></div><br class=""></div></blockquote></div><br class="">
-- <br class="">
Sent from my Android device with K-9 Mail. Please excuse my brevity.</div></div></blockquote></div><br class=""></div></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>