Hi, Matt, Wesley.

Matt: congratulations for your work so far. I think that we should really have a weekly or bi-weekly discussion by phone/instant messenger followed by a progress report.

Matt: what do you think is the next step?

As for me, next steps to do would include: * (hard, important) integration with the iolib event loop -- this involves teaching the event loop about the many (one to start with) input (and output) ports that may be open, but also signals and process-termination events (if available) so that these things may be monitored in the event loop. * (hard, important) add some mechanism to handle process links * (not too hard, not urgent) a portable run-program implementation that shares E-i-L's process management facility, and could be used to spawn remote processes, etc. * (easy, not urgent) better data-structures for pid's (say, a hash-table to begin with) -- Wesley, maybe you can do that as a starter?

Matt: as for the spawning, I'm thinking of a syntax more like (spawn-process function &key name arguments link initial-bindings ...) allowing for keyword arguments make it easier to add new features in a compatible way. Here for instance, link would specify whether we use the equivalent of Erlang's spawn or spawn_link, and initial-bindings would be used in a progv in the child process. Be sure to signal an error if an unimplemented feature is used!

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Laziness is mother of Intelligence. Father unknown. [Rumor has it it's Greed.] -- Faré

2008/6/10 Matt Bone thatmattbone@gmail.com:

Oops, I forgot to copy the list...

Welcome Wesley! If you know how things work at a macro-level, you should be good to go in common lisp (that was a pun). It'd probably be too tedious to just work on testing and documentation (but if you want to, by all means). I think some larger examples exercising what we already have could be useful. Maybe even a hand-coded port of a simple but cool erlang app? Or a portion of one? I'm working on getting distribution to work at the moment and hoping to write some test cases myself. Other than that, I'm open to whatever you'd like to do. Fortunately we can paint with a pretty wide brush with git; if you want to do something drastic, just branch and we can worry about merging later. Otherwise just push to the master branch and we can always fix or roll back if things go awry.

I just put together an attempt at a manual that could be useful in checking out the code, etc: http://common-lisp.net/project/erlang-in-lisp/manual/manual.html

As far as implementation, I've been using using sbcl, but I pushed some changes last night for clisp and everything seems to work. One thing I've noticed is that when you fork a new lisp process from inside of emacs (whether that be sbcl or clisp or whatever else you're using) things behave differently: in clisp stdout from forked processes is sent to the REPL as you might expect, but in SBCL this output is not sent to the REPL (I haven't cared enough to look, but I assume this is due to how swank/slime is implemented differently for each).

--matt

On Mon, Jun 9, 2008 at 7:33 PM, Wesley Bitomski wjbitomski@yahoo.com wrote:

...

I'm Wesley and I have experience writing code. Although my style may not be refined, I'm tenacious. I've read what's going on, so on a macro-level I understand what you're aiming to accomplish. Since I'm new to your project, I'm hesitant to start acting on my own.

Is there anything specific that you want me to start working on? Test cases? Documentation? Beating up on a frustrating problem?

Also: What implementation are each of you running? I have a machine that runs emacs slime with clisp. Does this matter, or should I be using something else?

Thanks for having me, I found out about the project through Facebook, and was asked to join this group by Mr. Rideau to start participating.

~Wesley

---

erlang-in-lisp-devel mailing list erlang-in-lisp-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel

---

erlang-in-lisp-devel mailing list erlang-in-lisp-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel

Dear Matt,

yes, the event loop is important whenever you need to do I/O with more than one source of data. Any time you have a process that needs to listen to both local Erlang messages and anything else (be it remote Erlang messages via TCP/IP, HTTP clients, an audio stream, a compression/decompression process, signals of processes going up or down, etc.) Spawning one subprocess per data source that converts everything into Erlang messages is certainly possible, but quite expensive. Sooner or later, we'll need some generic mechanism to generate language-level events (messages being queued/processed) from many sources - if only indeed so as to manage trees of linked processes. The event loop will also become essential when we implement a green thread model of execution. It needs not be the next step. But certainly something to do before the end of the summer.

Wesley: are you a taker for putting processes in a hash-table? For hacking on run-program?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The competitor to be feared is one who never bothers about you at all, but goes on making his own business better all the time. -- Henry Ford

2008/6/11 Matt Bone thatmattbone@gmail.com:

I think working on links would be a good next step. It's probably one of the more important parts of having others take the project seriously.

As far as the event loop, I'm having some trouble understanding where it fits in. At the moment, when a process is forked it just creates a passive port and on a receive does a blocking accept() until a message shows up. I don't really see the need for the event loop here since there is only one thread of execution through each process. Am I missing something? Or is the event loop less about receiving messages and more about handling other events like the death of linked processes?

I can see the importance of the event loop when we write our equivalent of the epmd to get distributed processes working.

--matt

On Wed, Jun 11, 2008 at 7:15 AM, Faré fahree@gmail.com wrote:

...

Hi, Matt, Wesley.

Matt: congratulations for your work so far. I think that we should really have a weekly or bi-weekly discussion by phone/instant messenger followed by a progress report.

Matt: what do you think is the next step?

As for me, next steps to do would include:

• (hard, important) integration with the iolib event loop -- this

involves teaching the event loop about the many (one to start with) input (and output) ports that may be open, but also signals and process-termination events (if available) so that these things may be monitored in the event loop.

• (hard, important) add some mechanism to handle process links
• (not too hard, not urgent) a portable run-program implementation

that shares E-i-L's process management facility, and could be used to spawn remote processes, etc.

• (easy, not urgent) better data-structures for pid's (say, a

hash-table to begin with) -- Wesley, maybe you can do that as a starter?

Matt: as for the spawning, I'm thinking of a syntax more like (spawn-process function &key name arguments link initial-bindings ...) allowing for keyword arguments make it easier to add new features in a compatible way. Here for instance, link would specify whether we use the equivalent of Erlang's spawn or spawn_link, and initial-bindings would be used in a progv in the child process. Be sure to signal an error if an unimplemented feature is used!

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Laziness is mother of Intelligence. Father unknown. [Rumor has it it's Greed.] -- Faré

2008/6/10 Matt Bone thatmattbone@gmail.com:

...

Oops, I forgot to copy the list...

Welcome Wesley! If you know how things work at a macro-level, you should be good to go in common lisp (that was a pun). It'd probably be too tedious to just work on testing and documentation (but if you want to, by all means). I think some larger examples exercising what we already have could be useful. Maybe even a hand-coded port of a simple but cool erlang app? Or a portion of one? I'm working on getting distribution to work at the moment and hoping to write some test cases myself. Other than that, I'm open to whatever you'd like to do. Fortunately we can paint with a pretty wide brush with git; if you want to do something drastic, just branch and we can worry about merging later. Otherwise just push to the master branch and we can always fix or roll back if things go awry.

I just put together an attempt at a manual that could be useful in checking out the code, etc: http://common-lisp.net/project/erlang-in-lisp/manual/manual.html

As far as implementation, I've been using using sbcl, but I pushed some changes last night for clisp and everything seems to work. One thing I've noticed is that when you fork a new lisp process from inside of emacs (whether that be sbcl or clisp or whatever else you're using) things behave differently: in clisp stdout from forked processes is sent to the REPL as you might expect, but in SBCL this output is not sent to the REPL (I haven't cared enough to look, but I assume this is due to how swank/slime is implemented differently for each).

--matt

On Mon, Jun 9, 2008 at 7:33 PM, Wesley Bitomski wjbitomski@yahoo.com wrote:

...

I'm Wesley and I have experience writing code. Although my style may not be refined, I'm tenacious. I've read what's going on, so on a macro-level I understand what you're aiming to accomplish. Since I'm new to your project, I'm hesitant to start acting on my own.

Is there anything specific that you want me to start working on? Test cases? Documentation? Beating up on a frustrating problem?

Also: What implementation are each of you running? I have a machine that runs emacs slime with clisp. Does this matter, or should I be using something else?

Thanks for having me, I found out about the project through Facebook, and was asked to join this group by Mr. Rideau to start participating.

~Wesley