Hi Fred, <div>1- How do you start the ct_slave nodes?</div><div><div>(ct@omarmb)1> ct_slave:start(omarmb, testnode,[]).</div><div>{ok,testnode@omarmb}</div><div>(ct@omarmb)2> rpc:call('testnode@omarmb', application, which_applications,[]).</div>
<div>[{stdlib,"ERTS  CXC 138 10","1.17.5"},</div><div> {kernel,"ERTS  CXC 138 10","2.14.5"}]</div><div><br></div><div>2- You can use erl_flags to specify more options to your slave node, e.g: </div>
<div><div>(ct@omarmb)3> ct_slave:start(omarmb, testnode1,[{erl_flags, "-s mnesia"}]).</div><div>{ok,testnode1@omarmb}</div><div>(ct@omarmb)4> rpc:call('testnode1@omarmb', application, which_applications,[]).</div>
<div>[{mnesia,"MNESIA  CXC 138 12","4.5"},</div><div> {stdlib,"ERTS  CXC 138 10","1.17.5"},</div><div> {kernel,"ERTS  CXC 138 10","2.14.5"}]</div></div><br><div class="gmail_quote">
On Sun, Feb 12, 2012 at 6:22 AM, Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@gmail.com">mononcqc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I should specify this problem is something I noticed when using distributed tests based on ct_slave; I would suspect that local tests being run from a shell started manually do not suffer from this.<div class="HOEnZb"><div class="h5">
<br><br><div class="gmail_quote">

On Sun, Feb 12, 2012 at 12:19 AM, Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@gmail.com" target="_blank">mononcqc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>I've recently discovered that Common Test appears to not be starting basic applications such as kernel and stdlib, but it still starts things like application controllers and whatnot.<br></div><div><br></div><div>



This gives me a few problems because it breaks a few behaviours such as application:which_applications(), being able to start a few applications (they depend on stdlib and kernel. Sstdlib depends on kernel, and manually starting kernel fails because  a bunch of processes already have that name). </div>



<div><br></div><div>It will also play negatively with things like manually calling application:set_env/3 before starting an application to configure it (after loading it) as just starting it will overwrite all values, etc. </div>



<div> </div><div>This causes me a few problems because it forces me to test everything below the application level, and I can't automate testing of things like distributed applications and their failover/takeover mechanisms.</div>



<div><br></div><div>Is there any workaround for these problems?</div>
</blockquote></div><br>
</div></div><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>
<br></blockquote></div><br></div>