[erlang-questions] wierd "function not used" problem - code included

deepblue_other cktgatb@REDACTED
Mon Oct 6 17:21:56 CEST 2008

Edwin Fine wrote:
> deepblue_other wrote:
>> so when I want to use spawn_link() with a named function that function
>> has to be exported?
>> same stands for regular spawn()?
> Yes, if you use a spawn that takes Module, Function, Args, like spawn/3,
> spawn/4, spawn_link/3, spawn_link/4,.... Or apply/3. And so on.
> In general if you provide a so-called "MFA" (Module, Func, Args) to a
> function, the Func has to be exported from Module, even if the Func is
> only for internal use within Module.
> It's important to know that the shell is your friend. It's critical to try
> out little pieces of code in the shell to see if they work the way you
> expect. For example, if you wanted to see if spawn could see your
> data_process function, you could have tried it in the shell (I'm passing
> the atom 'junk' instead of a real socket because I know the call will fail
> because it's not exported, so the socket is not needed):
> 1> c(tcp_manager).
> ./tcp_manager.erl:33: Warning: function data_process/2 is unused
> {ok,tcp_manager}
> 2> spawn(tcp_manager, data_process, [junk, []]).
> <0.40.0>
> 3> 
> =ERROR REPORT==== 5-Oct-2008::20:49:23 ===
> Error in process <0.40.0> with exit value:
> {undef,[{tcp_manager,data_process,[junk,[]]}]}
> deepblue_other wrote:
>> just a side question:
>> once a certain "receive" configuration is set for a process it can never
>> be changed to another "receive" configuration? it just popped in my head
>> here when you said that i can inline the error "receive". 
> I perhaps did not make myself clear. What I meant by saying you could
> inline it is that I didn't see the value of writing
> Fun = fun() -> do_something(),  do_something_else() end,
> Fun().
> That's the same as writing
> do_something(), 
> do_something_else()
no I understood what you wanted to say, I just had a case in my mind where
for example a "receive configuration" is active for a process, and a message
that matches comes in, and the clause starts executing its expressions and
one of the expressions calls another function that within it contains
another "receive configuration" - the new configuration would now be active,
and the old one would stop?

also the expressions listed bellow a "receive configuration" are executed
even though the "receive" essentially blocks the process in waiting state?

as you can tell Im slightly confused as to how the "receive" affects the
present/future activity of a process

Edwin Fine wrote:
> It is better in this case to put the code into a separate function.
> Better, because you can hot-swap the code and change that function.
> There's an excellent article about hot code swapping 
> http://http://spawnlink.com/articles/rules-of-hot-code-swapping/ here .
I will read this through now

Edwin Fine wrote:
>>    %-----------------------------------------------
>>    Listen_for_errors =
>>    fun() ->
>>            io:format("listening started~n"),
>>            receive
>>                {'EXIT', Pid, Why} ->
>>                    io:format("~p exited because:~p", [Pid,Why]);
>>                Other                 ->
>>                    io:format("Other:~p~n", [Other])
>>            end
>>    end,
>>    Listen_for_errors(),
>>     %-----------------------------------------------
> Finally, I'm not sure what Listen_for_errors() is supposed to do. It's
> just going to sit there forever in the receive, waiting for the first
> message that is sent (or en exit signal), and print it out (thus throwing
> it away), and return. What did you want it to do?
Listen_for_errors() was meant to catch the errors that were produced because
I didnt export the function I used in spawn_link() :) and just to see if the
data was coming in from the client. 

thanks Edwin
View this message in context: http://www.nabble.com/wierd-%22function-not-used%22-problem---code-included-tp19826465p19840082.html
Sent from the Erlang Questions mailing list archive at Nabble.com.

More information about the erlang-questions mailing list