<div>Hi,</div>
<div> </div>
<div>Can someone explain to me why the following "procedure" isn't sufficient?</div>
<div> </div>
<div>- compile your erlang sources normally, place the resulting .beam files in your code path (application-vsn/ebin)</div>
<div>- compile the same erlang sources with the +export_all flag, place the resulting .beam files outside of your code path (application-vsn/ebin-debug)</div>
<div>- run your application using the production beam files until the need arises to use unexported functions in the shell</div>
<div>- in the shell, change your code path to application-vsn/ebin-debug (code:replace_path/2)</div>
<div>- load the module(s) you want to use (l(module)). The loaded beam is now the one from ebin-debug/</div>
<div>- do whatever you need to do</div>
<div>- change the code path back to application-vsn/ebin</div>
<div>- load the production version of the modules you had to debug</div>
<div>- back to normal again</div>
<div> </div>
<div>I admit I haven't fully tested this, but I fail to see why it would not work (as long as your application supports code loading...)<br>Please enlighten me :)<br> </div>
<div>Regards,</div>
<div> </div>
<div>Olivier</div>
<div> </div>
<div><span class="gmail_quote">On 6/15/07, <b class="gmail_sendername">Thomas Lindgren</b> <<a href="mailto:thomasl_erlang@yahoo.com">thomasl_erlang@yahoo.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>--- Claes Wikström <<a href="mailto:klacke@hyber.org">klacke@hyber.org</a>> wrote:<br><br>> Kenneth Lundin wrote:
<br>> > Hi,<br>> ><br>> > I don't really understand why there is a big need<br>> for Luke to call<br>> > local functions<br>> > from the shell during debugging of a live system?<br>> >
<br>><br>> I sympathize with Luke here. Debugging live systems,<br>> being able<br>> to call non exported functions from the shell is<br>> often ... well<br>> necessary.<br><br>Fully agreed on the practicalities, and adding a
<br>'%preserved' or generating a module_info-like function<br>for the same functionality is straightforward, but<br>does it in practice fix anything substantial beyond<br>adding +export_all in the makefiles?<br><br>
As far as I can tell, it _does_ fix one minor thing,<br>apply can't directly call unexported functions, and it<br>also makes the module interface look tidier. I'm not<br>sure that's enough for me to become enthusiastic; I'd
<br>like more bang per buck. Am I missing something?<br><br>Best,<br>Thomas<br><br><br><br><br><br>____________________________________________________________________________________<br>Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.
<br><a href="http://answers.yahoo.com/dir/?link=list&sid=396545433">http://answers.yahoo.com/dir/?link=list&sid=396545433</a><br>_______________________________________________<br>erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote>
</div><br>