It is a waste of intelligence to be confined to a single programming language. The computer is an awesome machine, and it provides so many different tools and patterns with which we can create programs. With this, we have implemented exactly the functionality we wanted in the beginning: a server that provides a simple Erlang function and produces the result of a calculation done in an external Fortran program. The force/2 function takes two integers, mass and acceleration, and will callback a handler that sends messages to the port and receives the response from the external program. The init/1 function runs as a callback, spawns the port, and stores the port Pid in the genserver state. We start the genserver with start_link/1 by providing the external program command as argument. mass ( X ) -> "mass " ++ integer_to_list ( X ) ++ " \n ". accel ( X ) -> "accel " ++ integer_to_list ( X ) ++ " \n ". Start_link ( Filename ) -> gen_server : start_link ( -> TrimmedData = string : trim ( Data ), list_to_integer ( TrimmedData ) after 500 -> nil end. Let's see how we create a port and send and receive messages. Luckily for us, our Fortran program is designed to expect very simple binary patterns. JSON) for the API, and implement encoding/decoding internally. They must instead resort to a common binary (string) protocol (e.g. For example, three services running Node, JVM, and Python cannot share objects native to their respective languages. This is very similar to what happens in the distributed architecture of microservices implemented in different programming languages. Everything we can do is send and receive binaries. atoms, tuples, records, maps), while the external program absolutely does not. One key difference of message passing from ports to the external program, compared with message passing between processes inside the Erlang runtime, is that internal processes understand Erlang terms (e.g. A port is a processes that sends and receives messages from other processes in the Erlang runtime, and sends and receives messages from the external program. Most things in the Erlang system are processes, and ports are no exception. When to use: Ports can be used for all kinds of interoperability situations where the Erlang program and the other program runs on the same machine. This means that the programmer might have to invent a suitable encoding and decoding scheme. When a port is created, Erlang can communicate with it by sending and receiving lists of bytes (not Erlang terms). The ports provide a byte-oriented interface to an external program. Ports provide the basic mechanism for communication with the external world, from Erlang's point of view. The appropriate way to do this in Erlang is using ports. Now, we need to write an Erlang program that is able to run it.Īs we said, we want to be able to call an Erlang function that produces the result from the Fortran program's execution. Great, we have successfully written a Fortran program that calculates the force using the Newtonian formula. Our objective is to call the genserver API in Erlang, have the function transparently execute in the Fortran program (that is, as if it had been called locally), and return the correct result.Įnter fullscreen mode Exit fullscreen mode Ports are Erlang processes that allow running external programs and interact with them in the same way we interact with processes in the Erlang machine, by sending and receiving messages. In order to interface with the Fortran program, we use a genserver process that manages an Erlang port. For this exercise, we will write a program that calculates the force according to Newton's 2nd law. Because our problem here is not how to write Fortran, but rather how to run the program from inside the Erlang runtime, a simple program will do just fine. We are going to write a Fortran program that receives input and does some calculations with the values provided by the user. The problem, however, is that he never told us how to run such a program from inside the Erlang machine.Ĭode for this article is available on my Github Those tasks, he said, would be best served by calling an external program written in Fortran. Joe Armstrong, creator of the Erlang programming language, said a couple of times that, though the Erlang system is the perfect tool for writing programs designed for concurrent execution, it is not the best tool for compute-intensive tasks, such as numerical calculations.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |