From dsb at prairienet.org Sun Jun 1 15:13:52 2008 From: dsb at prairienet.org (Dan Bensen) Date: Sun, 01 Jun 2008 10:13:52 -0500 Subject: [erlang-in-lisp-devel] fare-match question In-Reply-To: References: Message-ID: <4842BCB0.5080502@prairienet.org> Matt Bone wrote: > are our pattern matching requirements so minimal that > a) it does not matter and b) we could even roll our own > ala some of the Norvig examples? According to one of the tutorials[*], Erlang patterns support variable repetition. I think Fare mentioned using existing Erlang test code, so that might be an issue. --Dan [*] http://www.erlang.org/course/sequential_programming.html#patterns ------------------------------------------------ Dan Bensen http://www.prairienet.org/~dsb/ cl-match: expressive pattern matching in Lisp http://common-lisp.net/project/cl-match/ From rvirding at gmail.com Sun Jun 1 15:36:21 2008 From: rvirding at gmail.com (Robert Virding) Date: Sun, 1 Jun 2008 17:36:21 +0200 Subject: [erlang-in-lisp-devel] fare-match question In-Reply-To: <4842BCB0.5080502@prairienet.org> References: <4842BCB0.5080502@prairienet.org> Message-ID: <3dbc6d1c0806010836u7cd58ffcq2502c559bbf467d1@mail.gmail.com> 2008/6/1 Dan Bensen : > Matt Bone wrote: > >> are our pattern matching requirements so minimal that a) it does not >> matter and b) we could even roll our own >> ala some of the Norvig examples? >> > > According to one of the tutorials[*], Erlang patterns support variable > repetition. I think Fare mentioned using existing Erlang test code, > so that might be an issue. > Excuse my ignorance here but what exactly are you planning to use the pattern matching for? If it is for use in the code to which you compile Erlang then I would seriously think through how you are compiling Erlang. Yes, Erlang supports variable repetition (with implicit checking of values) and also non-lexical scoping so using and already bound variable in a pattern also means an implicit comparison of values. I would not directly compile the Erlang code to lisp but would use the first few passes of the Erlang compiler. This would ensure compatibility with existing Erlang for many features (records, list/binary comprehensions) and be much easier as the internal languages are much simpler. I would suggest using Core Erlang or even kernel Erlang. Core is a very simple functional language which has lexical scoping and simplified pattern matching. Kernel erlang has been fully lambda lifted and is completely "flat" and pattern matching has been compiled and optimised to basic tests. In a follow up to this mail I will send a copy of a presentation of LFE (Lisp Flavoured Erlang) I gave which I think would be interesting in 2 respects: - the LFE core forms are *very* close to Core Erlang (almost 1-to-1) - there is a *short* description of the compiler at the end, only 3 slides but it at least presents the passes and some of the internal languages. It's 87 kB Powerpoint document so I apologise for sending big message. Unfortunately I can't convert it to PDF, if anyone can help with this I would appreciate it. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvirding at gmail.com Mon Jun 2 21:37:54 2008 From: rvirding at gmail.com (Robert Virding) Date: Mon, 2 Jun 2008 23:37:54 +0200 Subject: [erlang-in-lisp-devel] fare-match question In-Reply-To: <3dbc6d1c0806010837k6e2782deje46f3d9b863fa6b0@mail.gmail.com> References: <4842BCB0.5080502@prairienet.org> <3dbc6d1c0806010837k6e2782deje46f3d9b863fa6b0@mail.gmail.com> Message-ID: <3dbc6d1c0806021437o718e2d33qa9f67868b0ecf7bb@mail.gmail.com> Hello all, The presentation is delayed as it is so big it needs approval by the list master. Sorry about that. Robert 2008/6/1 Robert Virding : > The LFE presentation. > > Robert > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fahree at gmail.com Mon Jun 2 22:23:07 2008 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Mon, 2 Jun 2008 18:23:07 -0400 Subject: [erlang-in-lisp-devel] fare-match question In-Reply-To: <3dbc6d1c0806021437o718e2d33qa9f67868b0ecf7bb@mail.gmail.com> References: <4842BCB0.5080502@prairienet.org> <3dbc6d1c0806010837k6e2782deje46f3d9b863fa6b0@mail.gmail.com> <3dbc6d1c0806021437o718e2d33qa9f67868b0ecf7bb@mail.gmail.com> Message-ID: <653bea160806021523o4090358fi7797dd5786782e@mail.gmail.com> Is there a permanent link to it? That might be easier and better than trying to fit it into the list. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] There is no such thing as philosophy-free science; there is only science whose philosophical baggage is taken on board without examination. -- Daniel Dennett, Darwin's Dangerous Idea 2008/6/2 Robert Virding : > Hello all, > > The presentation is delayed as it is so big it needs approval by the list > master. Sorry about that. > > Robert > > 2008/6/1 Robert Virding : >> >> The LFE presentation. >> >> Robert >> > > > _______________________________________________ > 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 From rvirding at gmail.com Mon Jun 2 22:46:20 2008 From: rvirding at gmail.com (Robert Virding) Date: Tue, 3 Jun 2008 00:46:20 +0200 Subject: [erlang-in-lisp-devel] fare-match question In-Reply-To: <653bea160806021523o4090358fi7797dd5786782e@mail.gmail.com> References: <4842BCB0.5080502@prairienet.org> <3dbc6d1c0806010837k6e2782deje46f3d9b863fa6b0@mail.gmail.com> <3dbc6d1c0806021437o718e2d33qa9f67868b0ecf7bb@mail.gmail.com> <653bea160806021523o4090358fi7797dd5786782e@mail.gmail.com> Message-ID: <3dbc6d1c0806021546n5865f3a7y521e48c2723b7f08@mail.gmail.com> OK, there is one now: http://forum.trapexit.org/viewtopic.php?p=43941#43941 2008/6/3 Far? : > Is there a permanent link to it? That might be easier and better than > trying to fit it into the list. > > [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | > http://fare.tunes.org ] > There is no such thing as philosophy-free science; there is only science > whose philosophical baggage is taken on board without examination. > -- Daniel Dennett, Darwin's Dangerous Idea > > > 2008/6/2 Robert Virding : > > Hello all, > > > > The presentation is delayed as it is so big it needs approval by the list > > master. Sorry about that. > > > > Robert > > > > 2008/6/1 Robert Virding : > >> > >> The LFE presentation. > >> > >> Robert > >> > > > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvirding at gmail.com Mon Jun 2 22:58:17 2008 From: rvirding at gmail.com (Robert Virding) Date: Tue, 3 Jun 2008 00:58:17 +0200 Subject: [erlang-in-lisp-devel] A good name for an operator Message-ID: <3dbc6d1c0806021558x27316a8fgfe51973a9305b283@mail.gmail.com> This list is probably a good place to ask for help with this: In LFE (Lisp Flavoured Erlang) I have extended cond with a matching test. Today you can do (cond ((match ) ...) ...) You evaluate the expression and if the result matches the pattern then the test succeeds and all the variables in the pattern are bound and can be used in that body. This is easy to implement and suits a pattern matching style of programming. The question is what to call the operator? I think using 'match', while descriptive, is way too general and can easily be expanded by a macro. I had thought of '=?' which builds on Erlang assignment '=' and a test '?', but maybe it is too Erlangy. Any suggestions welcome. Just an small observation: now that I am directly working with lisp and erlang at the same time is that have pattern matching really affects your style or programming. I know it is obvious but it still hits you when you see it. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From fahree at gmail.com Wed Jun 4 02:09:57 2008 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Tue, 3 Jun 2008 22:09:57 -0400 Subject: [erlang-in-lisp-devel] fare-match question In-Reply-To: <3dbc6d1c0806021546n5865f3a7y521e48c2723b7f08@mail.gmail.com> References: <4842BCB0.5080502@prairienet.org> <3dbc6d1c0806010837k6e2782deje46f3d9b863fa6b0@mail.gmail.com> <3dbc6d1c0806021437o718e2d33qa9f67868b0ecf7bb@mail.gmail.com> <653bea160806021523o4090358fi7797dd5786782e@mail.gmail.com> <3dbc6d1c0806021546n5865f3a7y521e48c2723b7f08@mail.gmail.com> Message-ID: <653bea160806031909p6482fbf1j7059a67f0fd1fc04@mail.gmail.com> Nice presentation. Thanks a lot! Silly remarks: * in CL, bitvectors\ are like that: #*01110111 http://arti.vub.ac.be/docs/HyperSpec/Body/02_dhd.htm I don't know whether they correspond to Erlang binary constants, but if they do, you may keep the same syntax (or not since CL ones are actually writeable). * instead of fletrec you might or not want to use labels. Now your lisp dialect will by definition be incompatible with any other dialect, so it probably doesn't matter too much. * for gensyms that work across upgrade of distributed code, if you're afraid of collisions, you might consider prepending the gensym'ed symbol name with the crypto hash of the module code being compiled. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Dost thou love life? Then do not squander time, for that's the stuff life is made of. -- Benjamin Franklin 2008/6/2 Robert Virding : > OK, there is one now: > > http://forum.trapexit.org/viewtopic.php?p=43941#43941 > > 2008/6/3 Far? : >> >> Is there a permanent link to it? That might be easier and better than >> trying to fit it into the list. >> >> [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | >> http://fare.tunes.org ] >> There is no such thing as philosophy-free science; there is only science >> whose philosophical baggage is taken on board without examination. >> -- Daniel Dennett, Darwin's Dangerous Idea >> >> >> 2008/6/2 Robert Virding : >> > Hello all, >> > >> > The presentation is delayed as it is so big it needs approval by the >> > list >> > master. Sorry about that. >> > >> > Robert >> > >> > 2008/6/1 Robert Virding : >> >> >> >> The LFE presentation. >> >> >> >> Robert >> >> >> > >> > >> > _______________________________________________ >> > 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 From rvirding at gmail.com Sat Jun 7 22:18:46 2008 From: rvirding at gmail.com (Robert Virding) Date: Sun, 8 Jun 2008 00:18:46 +0200 Subject: [erlang-in-lisp-devel] fare-match question In-Reply-To: <653bea160806031909p6482fbf1j7059a67f0fd1fc04@mail.gmail.com> References: <4842BCB0.5080502@prairienet.org> <3dbc6d1c0806010837k6e2782deje46f3d9b863fa6b0@mail.gmail.com> <3dbc6d1c0806021437o718e2d33qa9f67868b0ecf7bb@mail.gmail.com> <653bea160806021523o4090358fi7797dd5786782e@mail.gmail.com> <3dbc6d1c0806021546n5865f3a7y521e48c2723b7f08@mail.gmail.com> <653bea160806031909p6482fbf1j7059a67f0fd1fc04@mail.gmail.com> Message-ID: <3dbc6d1c0806071518p2ea8165egacbbf34d04738bf5@mail.gmail.com> 2008/6/4 Far? : > Nice presentation. Thanks a lot! Thank you, thank you. > Silly remarks: > * in CL, bitvectors\ are like that: #*01110111 > http://arti.vub.ac.be/docs/HyperSpec/Body/02_dhd.htm > I don't know whether they correspond to Erlang binary constants, but > if they do, you may keep the same syntax (or not since CL ones are > actually writeable). In a sense I think they are the same. The main problem with using the CL bitvector syntax is that binaries are usually much bigger, sometimes mega-bytes. > * instead of fletrec you might or not want to use labels. Now your > lisp dialect will by definition be incompatible with any other > dialect, so it probably doesn't matter too much. I don't like the labels name and I am free to do as I want. :-) At least until we are more people working on LFE, if that ever occurs. > * for gensyms that work across upgrade of distributed code, if you're > afraid of collisions, you might consider prepending the gensym'ed > symbol name with the crypto hash of the module code being compiled. That would work, but I don't really know how worried I am about the problem. It was more a comment on that neither Scheme's hygiene and gensym are really safe unless you use them as intended. We'll see what the users need. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjbitomski at yahoo.com Tue Jun 10 00:33:49 2008 From: wjbitomski at yahoo.com (Wesley Bitomski) Date: Mon, 9 Jun 2008 17:33:49 -0700 (PDT) Subject: [erlang-in-lisp-devel] Hi, I'm here to help Message-ID: <54401.42069.qm@web30903.mail.mud.yahoo.com> 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 From thatmattbone at gmail.com Wed Jun 11 00:27:34 2008 From: thatmattbone at gmail.com (Matt Bone) Date: Tue, 10 Jun 2008 19:27:34 -0500 Subject: [erlang-in-lisp-devel] Hi, I'm here to help In-Reply-To: <54401.42069.qm@web30903.mail.mud.yahoo.com> References: <54401.42069.qm@web30903.mail.mud.yahoo.com> Message-ID: 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 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 > From fahree at gmail.com Wed Jun 11 12:15:40 2008 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Wed, 11 Jun 2008 08:15:40 -0400 Subject: [erlang-in-lisp-devel] Hi, I'm here to help In-Reply-To: References: <54401.42069.qm@web30903.mail.mud.yahoo.com> Message-ID: <653bea160806110515y47a338by39971525b81fea01@mail.gmail.com> 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 : > 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 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 From thatmattbone at gmail.com Wed Jun 11 17:10:48 2008 From: thatmattbone at gmail.com (Matt Bone) Date: Wed, 11 Jun 2008 12:10:48 -0500 Subject: [erlang-in-lisp-devel] Hi, I'm here to help In-Reply-To: <653bea160806110515y47a338by39971525b81fea01@mail.gmail.com> References: <54401.42069.qm@web30903.mail.mud.yahoo.com> <653bea160806110515y47a338by39971525b81fea01@mail.gmail.com> Message-ID: 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? 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 : >> 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 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 > From fahree at gmail.com Wed Jun 11 23:07:26 2008 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Wed, 11 Jun 2008 19:07:26 -0400 Subject: [erlang-in-lisp-devel] Hi, I'm here to help In-Reply-To: References: <54401.42069.qm@web30903.mail.mud.yahoo.com> <653bea160806110515y47a338by39971525b81fea01@mail.gmail.com> Message-ID: <653bea160806111607s10289db4s5ab42fc38dc2a068@mail.gmail.com> 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 : > 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? 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 : >>> 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 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