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

Mihai Balea mihai@REDACTED
Mon Jun 3 09:33:59 CEST 2013


I have a slightly modified version of sync that attempts to work around this issue, you can find it here: https://github.com/sbalea/sync.git
It's not bulletproof, which is why I haven't yet submitted a PR for it, but it seems to work in the majority of my use cases.

Mihai

On Jun 2, 2013, at 5:15 AM, 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/20130603/4e76730e/attachment.htm>


More information about the erlang-questions mailing list