[erlang-questions] Erlang newbie questions

Tim Watson watson.timothy@REDACTED
Wed Oct 19 13:11:58 CEST 2011


On 18 October 2011 21:11, Gerry Weaver <gerryw@REDACTED> wrote:

> 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
> 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...
>
>
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.

If you do choose an existing IDE, the eclipse based erlide is probably the
most mature right now.


> 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.
>
>
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:

1. have your native (IDE) application start a C node and use that to
dispatch tasks to the external worker node(s)
2. start the emulator embedded from within your native application
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)

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.

You could spawn all sorts of tasks in the external vm, such as

- collecting meta-data on applications, modules, types, functions, etc
- doing the compile steps
- integrating with build tools like rebar and sinan
- running external tools like dialyzer, typer, conqueror

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.

Lots of possibilities - HTH.

Cheers

Thanks,
> -G
>
>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111019/1a016ce8/attachment.htm>


More information about the erlang-questions mailing list