[erlang-questions] speeding the development process for OTP nodes

[Jeremy Ong]

I believe you said it yourself. Don't use reltool in your development
cycle. Reltool is for generating releases and going through the
whole rigamarole for small iterations is overkill. Write a simple shell
script to launch erl with all your code paths and start rustyio/sync for
development. Before you release or perform a code upgrade, loop in rebar
generate at that point.


On Sat, Jun 1, 2013 at 7:15 PM, Felix Gallo <felixgallo@REDACTED> wrote:

> I'm developing a medium-sized erlang node comprised of several interacting
> applications.  In doing so, I'm finding myself staring at the output of
>
> ./rebar compile && ./rebar generate && ./rel/bin/mynode/bin/mynode console
>
> quite a bit more than is perhaps wanted.
>
> I thought that https://github.com/rustyio/sync might be the answer to all
> of my problems, as it advertises hot code reloading on file changes.
>  However, I haven't yet coaxed it into working inside the
> ./rel/bin/mynode/bin/mynode console environment; I suspect it's detecting
> the code changes, and recompiling the code, but it's not redeploying into
> the release, so doesn't reload the beams.
>
> So then I thought that maybe it's dumb to include the reltool build in the
> development cycle, maybe the pro erlang way is to just run erl by hand like
> our forefathers did before us.  But when I give that a shot, as an OTP
> neophyte, I have this lurking feeling that I am aiming a gun at my foot.
>
> For those of us who don't believe in emacs, what's the one true optimal
> way to tighten up the development loop here?
>
> F.
>
> _______________________________________________
> 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/20130601/e678c154/attachment.htm>