setting up erlang enviorment posted by Francisco Pinochet @ Tue, 02 Dec 2008 02:48:07 -0000

Francisco Pinochet — Tue, 02 Dec 2008 02:48:07 -0000

I figured it out.

download Emacs for osx and install

go to your terminal type in vi ~/.emacs

Enter the following

;Erlang Mode
(setq load-path (cons ”/opt/erlang/lib/erlang/lib/tools-2.6.2/emacs/” load-path))
(setq erlang-root-dir ”/opt/erlang”)
(setq exec-path (cons ”/opt/erlang/bin/” exec-path))
(require ‘erlang-start)

Load up Emacs and you will see it works. It also worked on for Aquamacs

setting up erlang enviorment posted by Francisco Pinochet @ Mon, 01 Dec 2008 21:59:02 -0000

Francisco Pinochet — Mon, 01 Dec 2008 21:59:02 -0000

I run OSX 10.5 and I installed Aquamacs a version of emacs. I setup the way Kevin did it in his blog and it is not working. At the moment I am programing in Eclipse with a erlang plug in. When it comes to node testing I cannot test this in eclipse because I cannot open more than one console window. I even did a video tutorial how to set this up aquamacs. Is there any other tutorials?

global:send vs global:send_message posted by Francisco Pinochet @ Mon, 01 Dec 2008 21:55:20 -0000

Francisco Pinochet — Mon, 01 Dec 2008 21:55:20 -0000

I did not get any errors on episode 3. so is this code better?

encryption posted by Francisco Pinochet @ Mon, 01 Dec 2008 15:59:47 -0000

Francisco Pinochet — Mon, 01 Dec 2008 15:59:47 -0000

I found something.. http://diginux.blogspot.com/2006/10/adding-aes-encryption-to-erlang-chat.html

encryption posted by Francisco Pinochet @ Thu, 27 Nov 2008 21:25:30 -0000

Francisco Pinochet — Thu, 27 Nov 2008 21:25:30 -0000

How would I add encryption?

Episode 1 - exit() posted by Chris Bernard @ Fri, 21 Nov 2008 14:47:25 -0000

Chris Bernard — Fri, 21 Nov 2008 14:47:25 -0000

Well, almost. To directly put the hurtin’ on a process and take it down immediately, no questions asked, what you need is:

exit(P1, kill).

If you use the ‘normal’ flag for exit/2, erlang will ask the question, “Is this process trapping exits? (process_flag=trap_exit) If so, erlang will add this signal to the process’ inbox; if not, erlang will do absolutely nothing at all.

general notes posted by Justin Lolofie @ Thu, 13 Nov 2008 04:32:45 -0000

Justin Lolofie — Thu, 13 Nov 2008 04:32:45 -0000

Here are a few suggestions from a complete Erlang beginner watching the Erlang in Practice screencasts.

You are compiling in your editor. A beginner will have to notice the c(...) stuff in your buffer; it might be worth a quick mention initially.

Move cursor away from the text I’m supposed to be reading when not specifically pointing at something- it is distracting.

Give a few more seconds to important points (e.g. ?SERVER e2-15:15, anon
fun e2-19:55)

Switch to a diagram when describing abstract concepts (e.g. single assignment variables in functional languages).

Light text on white background is hard to see (e.g. light grey for double quoted text)

Be more verbose- Sometimes I’m looking away from the screencast for 1-2 seconds; I know, maybe this isnt ideal, but it works for me- 98% of the time. It doesnt work when the author notices a syntax error and fixes it without saying anything at the precise 1-2 seconds I’m looking at my own terminal. Not only do I miss the correction, but I dont know I missed something until the next time we compile.

Just adding in a “oh, I need to change that semicolon to a coma” would help. I know, it sounds a little exaggerated to say things that you are clearly doing- but the more cues people have the more likely they are to understand.

Anyway, I’ve enjoyed them so far- keep up the good work! :>

trap_exit in episode 7 posted by Kevin Smith @ Mon, 03 Nov 2008 00:24:52 -0000

Kevin Smith — Mon, 03 Nov 2008 00:24:52 -0000

Yep. You are exactly correct.

I probably should’ve highlighted that fact a bit more in the screencasts. Sorry if it was confusing.

trap_exit in episode 7 posted by Dave Peticolas @ Sun, 02 Nov 2008 20:02:13 -0000

Dave Peticolas — Sun, 02 Nov 2008 20:02:13 -0000

Ok, so strictly speaking, the servers here don’t really need to set trap_exit, right? I didn’t set them
when I was following along and the supervisors all seemed to restart crashed processes just fine. As I
understand it, setting the flag in a gen_server’s init would set the flag for the gen_server process,
not the supervisor process, so it wouldn’t really affect the supervisor’s ability to detect the
gen_server crashing.

trap_exit in episode 7 posted by Kevin Smith @ Sun, 02 Nov 2008 19:39:11 -0000

Kevin Smith — Sun, 02 Nov 2008 19:39:11 -0000

The man page on the ‘erlang’ module gives a clue:

“When trap_exit is set to true, exit signals arriving to a process are converted to {‘EXIT’, From, Reason} messages, which can be received as ordinary messages.”

The transformation of an process exit event to an Erlang message is one way supervisors can do their jobs—monitoring and restarting processes. In “real” code you’d use trap_exit judiciously since there scenarios where you really want processes to exit and propagate their exit signals up the tree.

Another reason for trapping exits is the informative traces OTP provides when the process dies. Many times I’ll enable trap_exit when I’m prototyping or debugging code. Once I have the code working as I want I’ll go back and remove all but a few of the trap_exit flags.

trap_exit in episode 7 posted by Dave Peticolas @ Fri, 31 Oct 2008 02:52:00 -0000

Dave Peticolas — Fri, 31 Oct 2008 02:52:00 -0000

Hi, I have a question about the setting of the trap_exit flag in episode 7. I’m unclear
on why that is needed. How does setting the flag on the gen_server process affect whether
the supervisor will get notified when the gen_server dies?

Question about chat server functionality posted by Kevin Smith @ Sun, 12 Oct 2008 17:32:04 -0000

Kevin Smith — Sun, 12 Oct 2008 17:32:04 -0000

Hmmm. I went thru the steps you described using the code included in the source bundle and I get the error message after Joe is unregistered and I try to send him a message.

Episode 1 - exit() posted by Kevin Smith @ Sun, 12 Oct 2008 17:22:51 -0000

Kevin Smith — Sun, 12 Oct 2008 17:22:51 -0000

Meh. This is a mistake on my part :( I called exit/1 when exit/2 should’ve been used like so:

exit(P1, normal).

You can verify the processes are indeed dead by calling erlang:is_process_alive/1 with the process’ pid. Sorry about the confusion on that.

Design question posted by Kevin Smith @ Sun, 12 Oct 2008 17:03:01 -0000

Kevin Smith — Sun, 12 Oct 2008 17:03:01 -0000

I think it does :)

One of the goals when I did the screencasts was to start with something simple which a) didn’t require a lot of Erlang knowledge and b) would fit into a 30-40 min screencast. Sometimes, like with this client process example, I had to break things up over a couple of episodes to satisfy these criteria.

Design question posted by Peter Whitfield @ Sun, 12 Oct 2008 10:10:10 -0000

Peter Whitfield — Sun, 12 Oct 2008 10:10:10 -0000

Thanks Kevin,

Having gone on to listen to the third screencast, I realise that I was assuming there was already a Client process you could send a message to – this clearly was not the case in episode 2.

Your refactoring in the start of Ep 3 effectively does what I was expecting by creating a separate process for each client and having the router send the appropriate process a message.

Hopefully this means I’m starting to get my head around the concepts :-)

Cheers,

Pete

Episode 1 - exit() posted by Kevin Smith @ Sat, 11 Oct 2008 21:34:34 -0000

Kevin Smith — Sat, 11 Oct 2008 21:34:34 -0000

I’ve gotten a bit behind on my replies—apologies for taking so long to reply. I’m not at my laptop right now so I can’t review the code. I’ll take a look later today and see what’s going on.

Design question posted by Kevin Smith @ Sat, 11 Oct 2008 21:29:28 -0000

Kevin Smith — Sat, 11 Oct 2008 21:29:28 -0000

I’ve gotten behind on replying to posts—sorry for the delay. One thing to keep in mind is I wrote some of the code to illustrate a point which means it might be a little different than if you were writing the code “for real”. I’ll take a look at the code later today and come up with a more definitive reply.

Design question posted by Peter Whitfield @ Sat, 11 Oct 2008 20:45:50 -0000

Peter Whitfield — Sat, 11 Oct 2008 20:45:50 -0000

Perhaps to elaborate a little, I would have thought that it would be more appropriate to send a deliver_message message to the appropriate client process.

I’m hoping that someone can help explain why the function passing approach would be preferable over sending a message.

Thanks again,

Pete

Design question posted by Peter Whitfield @ Sat, 11 Oct 2008 12:11:49 -0000

Peter Whitfield — Sat, 11 Oct 2008 12:11:49 -0000

Hi All,

I’ve just finished watching the first screencast and started on the second and I’m a little confused about the design of the message_router. It seems strange to me that the router is at all concerned with the display of the message – surely it should simply pass the message on to the intended client and let it worry about how to display the message.

Based on this thought, I don’t really understand why it’s a good idea to pass the message printing function from the client into the router.

Can anyone help me to understand this design decision?

Thanks!

Peter

Episode 1 - exit() posted by Stefan Arentz @ Thu, 09 Oct 2008 01:26:11 -0000

Stefan Arentz — Thu, 09 Oct 2008 01:26:11 -0000

Around timestamp 17:45, the exit() call is used to stop two message router processes. I get the same output as Joe:

56> exit(P1).
** exception exit: <0.778.0>
57> exit(P2).
** exception exit: <0.798.0>

(I named my processes slightly different)

But I noticed that these processes are actually still running. For example, this still works:

59> chat_client:send_message(P1, P2, "Hello").
Received: "Hello" 
{send_chat_msg,<0.798.0>,"Hello"}

What is going on here. Does exit() actually work? Or was it not used in the right way?

Episode 4: badarg posted by John Sutherland @ Wed, 24 Sep 2008 22:20:39 -0000

John Sutherland — Wed, 24 Sep 2008 22:20:39 -0000

So much great info. Thanks again!

Episode 4: badarg posted by Kevin Smith @ Wed, 24 Sep 2008 18:20:12 -0000

Kevin Smith — Wed, 24 Sep 2008 18:20:12 -0000

This trips a lot of people up. Erlang nodes do not discover each other on a network. You have to point them at each other using net_adm:ping/1. Until you do that things like global name replication, mnesia replication, and distributed messages (among others) won’t work.

This might seem like a pain but in practice its not so bad. When you have multiple nodes in a single cluster ~~- all nodes sharing the same Erlang cookie -~~ a new node only has to ping one of them to know about all of them. The new node will receive a “brain dump” of cluster information from the node it pinged.

There is the nodefinder:http://code.google.com/p/nodefinder project which can automate this process entirely using several different discovery mechanisms.

Episode 4: badarg posted by John Sutherland @ Wed, 24 Sep 2008 17:44:10 -0000

John Sutherland — Wed, 24 Sep 2008 17:44:10 -0000

Thanks for your prompt reply Kevin, it seems to be working now.

I haven’t changed the code, but if I don’t ping foo from bar, global:registered_names/0 is empty, but after pinging contains what I would expect. Any insight on why that is?

Thanks again,
John.

Episode 4: badarg posted by Kevin Smith @ Tue, 23 Sep 2008 20:56:01 -0000

Kevin Smith — Tue, 23 Sep 2008 20:56:01 -0000

Based on the error message, it looks like “bar” doesn’t see message_router as a globally registered name. According to the docs for the global module:

"If Name is not a globally registered name, the calling function
will exit with reason {badarg, {Name, Msg}}."

This looks suspiciously like your error. The only way I’m able to recreate the error if I don’t ping foo from bar before calling chat_client:register_nickname/1. I can suggest a couple of things to try:

1) Verify the output of global:registered_names/0 contains message_router in the list of global names before calling register_nick.

2) Verify both nodes are using the same code path. An easy way to do this is to start the nodes with the -pz option: “erl -sname foo -setcookie erlang -pz ./ebin”

If you’ve done both of those, you can try sending a message directly to message_router via the global module: global:send(message_router, ignore_this) and see what happens. If you see the same error something is going wrong with global name replication between the two nodes.

Episode 4: badarg posted by John Sutherland @ Tue, 23 Sep 2008 19:59:41 -0000

John Sutherland — Tue, 23 Sep 2008 19:59:41 -0000

Hi Kevin,

I’ve been following along with your excellent screen-casts, but have come across a stumbling block.

I’ve got pretty much everything working up to the end of Episode 4, bar one thing: chat_client:register_nickname/1 doesn’t work from any other node (although it did work at the end of Ep3). The nodes can ping each other and global:registered_names returns what I would expect.

I thought this might be a problem with my code, but it also occurs with the downloaded code samples.

(foo@Anberlin)5> chat_client:start_router().
yes
(foo@Anberlin)6> chat_client:register_nickname("John").
<0.65.0>

(bar@Anberlin)3> chat_client:register_nickname("John").
** exception exit: {badarg,{message_router,{register_nick,"John",<0.43.0>}}}
     in function  global:send/2

Any thoughts?

Cheers,
John.

PS. I’m running Erlang 5.6.2 on OS X.

Recent Posts in Erlang in Practice | Pragmatic Forums