[erlang-questions] Erlang development workflow

[Frank Hunleth]

On Sat, Mar 3, 2012 at 7:19 PM, Tim Watson <watson.timothy@REDACTED> wrote:
> I suspect you have a few choices about how you might do this. In terms of getting the latest 'code' onto the ARM, you can either
>
> 1. synchronise the file systems
> 2. synchronise the loaded beam code on two emulators
>
> How do you get your code onto the ARM's local storage currently? There is a 'reloader' module floating around the internet (especially on github) which takes any recent file system changes and does a code purge and reload (hence the name) on updated modules. If you find a way to synchronise local file system changes so they're reflected on the ARM, the reloader module should do the rest. The way it works IIRC is that it tracks either the beam files (in ebin) or the source files (in src) - I can't remember which - and when something changes, it reloads.

Thanks for the pointer to the 'reloader' module. I'll take a look at it.

In answer to the question about how I get code onto ARM's local
storage now, I currently use scp to copy the beam files over and then
I switch over to the ARM console window and restart the VM. That's for
most development. When I feel good about a change, I run a build
script that bundles the Linux kernel, drivers, erlang vm, utilities
etc. into a big binary software image. Those would be the bits that
would be programmed to Flash during production. I then verify that the
software image still runs the same.

Building the whole software image takes on the order of 10-20 minutes
for a full build and maybe a minute for a small update. Writing the
image to Flash takes about a minute or two. I.e. long enough to get
out of the flow.

> You could also use common test to run your test suites on the ARM node using ct_master, although I have no idea how the file system requirements will work in this scenario.
>
> Another option that might suit you would be to keep a test 'server' running continuously on the ARM and control this from your PC using the ethernet connection. There are several mechanisms that could work well here, the simplest of which is to ship the code updates to the ARM over the ethernet connection (e.g., pass the updated beam code to code:load_binary using an rpc:call).

Lot's of options. Thank you very much. I'll take a look.

Frank