<div class="gmail_quote">On 18 October 2011 21:11, Gerry Weaver <span dir="ltr"><<a href="mailto:gerryw@compvia.com">gerryw@compvia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I have been doing quite a bit of experimentation with Erlang and OTP. I find myself at a point where I definitely want the Erlang tool in my toolbox. I can see several instances on both past and future projects where Erlang could have been, or would be, a pretty interesting choice. Having said this, I want to come up with a good project that would afford me the opportunity to dig in a lot deeper. One thing that I think is missing from the big Erlang picture, is a good development environment (IDE). I know that there are a few attempts at this, but they are not really what I'm looking for. I think the best way to describe what I want, is something like QtCreator/C++ Builder. I originally didn't think much of these tools, but I have found the productivity boost they provide very useful. When I think about the things that would need to be done to make such a tool for Erlang, I believe it<br>

could give me insight into several things I would like to know a lot more about. I think it could be a good driver to push me into learning those things. When I consider some of the Erlang specific things like C nodes, Toolbar, etc., I imagine a very interesting project. I realize this may be somewhat ambitious, but regardless of the ultimate outcome, I really don't see the downside of trying. So... to that end...<br>

<br></blockquote><div><br></div><div>Interestingly, a lot of people on this list have decried the idea of having an IDE for Erlang. I think in part this is because both the language and platform is simple enough for an IDE not to be a necessity. You can get along fine without one, because the standard libraries and platform are small enough and so on. This is not to say however, that an IDE would not be beneficial.</div>
<div><br></div><div>If you do choose an existing IDE, the eclipse based erlide is probably the most mature right now. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
What would be the best/recommended way, in Erlang specific terms, to integrate with the Erlang VM. I would think that the ability to reset the VM to a fresh state, start and stop processes, Monitor processes, etc. etc. would be important beyond the normal compile/run functions. I guess what I'm really asking here is just some general advice about what a tool like this would look like in Erlang terms. I intend to use Qt as the gui toolkit. It would allow me to cover all of the most import platforms. I am very interested in any thoughts y'all have about this. I intend to start laying the foundation for this straight away. Another big motivating factor is the fact that I would like very much to have a tool like this for my own use. The code editor, Erlang shell, Toolbar combination is usable, but it would be nice to pull all of these things together in one interface. <br>

<br></blockquote><div><br></div><div>I can see a few different ways to integrate with the emulator. I think a good rule of thumb is probably to run most things in another emulator instance (i.e., node) running in a separate OS process and to rpc task requests over to it and receive the results in your own (embedded) instance. There are several ways to do this:</div>
<div><br></div><div>1. have your native (IDE) application start a C node and use that to dispatch tasks to the external worker node(s)</div><div>2. start the emulator embedded from within your native application</div><div>
3. fork an OS command to start erl in another node and talk over pipes and/or socket I/O using some binary protocol (like protocol buffers, BERT or Piqi)</div><div> </div><div>I would expect (2) to carry the highest risk and complexity, as you'd be embedding a complex VM in a multi-threaded GUI application. I'm not 100% sure what (1) looks like in terms of the threading model on the receiving end, but it is relatively low complexity and you have the erl_interface (ei) libraries to help with marshalling/un-marshalling data in the external term format (which is what the distribution protocol uses). Obviously (3) carries additional complexity in terms of designing a protocol, but gives a nice clean separation between your application and the VM.</div>
<div><br></div><div>You could spawn all sorts of tasks in the external vm, such as</div><div><br></div><div>- collecting meta-data on applications, modules, types, functions, etc</div><div>- doing the compile steps</div><div>
- integrating with build tools like rebar and sinan</div><div>- running external tools like dialyzer, typer, conqueror</div><div><br></div><div>And having the mechanism in place to talk to external nodes means the user can spawn a node with some code running and you can instrument and profile that node, using the trace/dbg features to have the instrumentation stats sent as messages back to your embedded c-node or whatever.</div>
<div><br></div><div>Lots of possibilities - HTH.</div><div><br></div><div>Cheers</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thanks,<br>
<font color="#888888">-G<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
<br>
<br>
<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>