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

[Matt Bone]

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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-in-lisp-devel mailing list
>>> erlang-in-lisp-devel at 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 at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel
>