[erlang-in-lisp-devel] Hi, I'm here to help

[Faré]

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 at 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 at 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 at 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 at 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