<div dir="ltr">Hi,<div><br></div><div>Just a thought that connects with the patterns discussion: linking to another process is usually permanent, that is we don't unlink from it. Process monitoring can be more dynamic. In any case, it is possible to have links/monitors that are dynamic and thus runtime properties. IMHO, one might want to handle these differently than the static ones. On the other hand, this might be an anti-pattern?</div>

<div><br></div><div>regards,</div><div>Vlad</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 5, 2014 at 10:59 AM, Torben Hoffmann <span dir="ltr"><<a href="mailto:torben.hoffmann@erlang-solutions.com" target="_blank">torben.hoffmann@erlang-solutions.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
Erik Søe Sørensen writes:<br>
<br>
> It looks good - and appears to incorporate appropriate Erlang idioms.<br>
> I will try it out at the next whiteboard design discussion :-)<br>
><br>
</div>Great - let me know how that works!<br>
<div class=""><br>
> There is one thing that bugs me, though: The representation of links as a<br>
> dual monitor (or, equivalently, of monitors as one-way links).<br>
> The notation has the nice property that to see which other processes are<br>
> affected when a given process dies, you simply look for circles around that<br>
> process. That's good.<br>
</div>Thanks - that was the intention.<br>
<div class="">> But there are several differences between monitors and links:<br>
> - the relation is asymmetric;<br>
> - link behaviour is affected by trap_exit, monitor behaviour isn't;<br>
> - links propagate exits, monitors don't;<br>
> - reason 'normal' is special to links (when not trap_exit'ed).<br>
> (And of course, the message format is different.)<br>
><br>
</div>You're right. I was unsure about how detailed this part should be, which was one of<br>
my reasons for seeking feedback sooner rather than later.<br>
<div class=""><br>
> All in all, I believe we might be better off with a slightly different<br>
> notation for monitors - say, a single-line-with-circle.<br>
><br>
> Am I making sufficient sense?<br>
><br>
</div>You are making a lot of sense.<br>
<br>
If I combine this with the request from Garrett, i.e., to make the notation more<br>
Google presentation friendly we could do this:<br>
* Use single line with open circle for monitors.<br>
* Use single line with filled circle for links.<br>
* Use single line with filled triangle style arrow head for spawn.<br>
* Use dashed lines with open triangle style arrow head for message passing.<br>
* Use dotted lines with open triangle style arrow head for exit signals.<br>
<br>
Still not sure if we need a special notation for dealing with exit signals that are<br>
being trapped. One could enforce that 'DOWN' has to be added to the message being<br>
passed when a process is trapping exits.<br>
<br>
Thoughts on all of this most welcome.<br>
<br>
Cheers,<br>
Torben<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> /Erik<br>
>  Den 02/05/2014 09.22 skrev "Torben Hoffmann" <<br>
> <a href="mailto:torben.hoffmann@erlang-solutions.com">torben.hoffmann@erlang-solutions.com</a>>:<br>
><br>
>> Hi,<br>
>><br>
>> As I have mentioned before I have been working on a visual notation for<br>
>> Erlang and<br>
>> although it is not complete yet I have received requests to release it<br>
>> anyway, so<br>
>> here goes...<br>
>><br>
>> <a href="https://github.com/esl/visual_erlang" target="_blank">https://github.com/esl/visual_erlang</a><br>
>><br>
>> One extra thing missing from the to-do list is state data for processes.<br>
>><br>
>> I would like some feedback on how you feel the abstraction level is.<br>
>> The purpose of Visual Erlang is not to be able to specify every little<br>
>> detail of what<br>
>> happens in an Erlang program, but to give a way to describe the<br>
>> architecture.<br>
>><br>
>> Once I have updated the Erlang Concurrency Patterns that Jesper and I have<br>
>> been<br>
>> working on to the new Visual Erlang notation we will release them as well.<br>
>><br>
>> The original plan for the patterns was to use Object-Process Methodology<br>
>> as the<br>
>> notation, but I was adviced (and thanks for that) to invent an Erlang<br>
>> specific<br>
>> notation since OPM has some corners that hurts for Erlang.<br>
>><br>
>> Right now the only way to draw Visual Erlang diagrams is by hand or use<br>
>> the LaTeX<br>
>> macros I have created, but since Visual Erlang has a 1:1 mapping between<br>
>> the visuals<br>
>> and a textual notation my hope is that we can create a tool that can<br>
>> create a diagram<br>
>> from the textual notation.<br>
>><br>
>> Going even further I dream of having a tool that extracts the Visual<br>
>> Erlang notation<br>
>> from the code in an interactive manner, where the user can guide what to<br>
>> abstract and<br>
>> what to just leave totally out.<br>
>><br>
>> Cheers,<br>
>> Torben<br>
>> --<br>
>> Torben Hoffmann<br>
>> CTO<br>
>> Erlang Solutions Ltd.<br>
>> Tel: +45 25 14 05 38<br>
>> <a href="http://www.erlang-solutions.com" target="_blank">http://www.erlang-solutions.com</a><br>
>> _______________________________________________<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" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>><br>
<br>
<br>
--<br>
Torben Hoffmann<br>
CTO<br>
Erlang Solutions Ltd.<br>
Tel: +45 25 14 05 38<br>
<a href="http://www.erlang-solutions.com" target="_blank">http://www.erlang-solutions.com</a><br>
_______________________________________________<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" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>