From rudi at constantly.at Tue Jul 4 12:23:21 2006 From: rudi at constantly.at (Rudi Schlatte) Date: Tue, 4 Jul 2006 14:23:21 +0200 Subject: [cl-muproc-devel] [Patch] openmcl support Message-ID: <93AEE80B-520F-4730-90DD-3B0C4901265D@constantly.at> Greetings, Here's a patch that lets cl-muproc run on openmcl, with no failing test cases. Not tested exhaustively on Lispworks; Klaus, can you check that everything still runs? Thanks! Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: openmcl.diff Type: application/octet-stream Size: 38169 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From klaus at mu.dk Wed Jul 5 08:28:04 2006 From: klaus at mu.dk (Klaus Harbo) Date: Wed, 05 Jul 2006 10:28:04 +0200 Subject: [Fwd: Re: [cl-muproc-devel] [Patch] openmcl support] Message-ID: <44AB7814.6080606@mu.dk> Oops - forgot to copy the list (see below). -K. -------- Original Message -------- Subject: Re: [cl-muproc-devel] [Patch] openmcl support Date: Wed, 05 Jul 2006 10:27:14 +0200 From: Klaus Harbo To: Rudi Schlatte References: <93AEE80B-520F-4730-90DD-3B0C4901265D at constantly.at> Rudi Schlatte wrote: > Here's a patch that lets cl-muproc run on openmcl, with no failing test > cases. Not tested exhaustively on Lispworks; Klaus, can you check that > everything still runs? Thanks! > > Cheers, > > Rudi Hi Rudi -- This is excellent! I will try to integrate your patch later this week and report back. I'm curious as to your porting experience? Was it hard? Is there anything I/we could learn from the exercise? I hope that we'll be able to add support for the most popular implementations, so any porting insights are welcome! best regards, -Klaus. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3368 bytes Desc: S/MIME Cryptographic Signature URL: From rudi at constantly.at Wed Jul 5 17:51:45 2006 From: rudi at constantly.at (Rudi Schlatte) Date: Wed, 5 Jul 2006 19:51:45 +0200 Subject: [cl-muproc-devel] [Patch] openmcl support In-Reply-To: <44AB7814.6080606@mu.dk> References: <44AB7814.6080606@mu.dk> Message-ID: <57AA1F2F-FCC8-49C9-9B4F-236C5794F340@constantly.at> On 5. Jul 2006, at 10:28, Klaus Harbo wrote: > This is excellent! I will try to integrate your patch later this week > and report back. I'm curious as to your porting experience? Was it > hard? Is there anything I/we could learn from the exercise? I hope > that we'll be able to add support for the most popular > implementations, > so any porting insights are welcome! Well, the only real hurdle was removing without-scheduling in muproc- spawn, the rest was straightforward. The port was basically finished over a month ago, but I found the fencepost error in consume-input only on tuesday. I think the next ports will happen faster now that we know that indeed only muproc-compat functionality is needed to get cl-muproc running. Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From klaus at mu.dk Thu Jul 6 06:53:57 2006 From: klaus at mu.dk (Klaus Harbo) Date: Thu, 06 Jul 2006 08:53:57 +0200 Subject: [cl-muproc-devel] [Patch] openmcl support In-Reply-To: <57AA1F2F-FCC8-49C9-9B4F-236C5794F340@constantly.at> References: <44AB7814.6080606@mu.dk> <57AA1F2F-FCC8-49C9-9B4F-236C5794F340@constantly.at> Message-ID: <44ACB385.2020703@mu.dk> Rudi Schlatte wrote: > > On 5. Jul 2006, at 10:28, Klaus Harbo wrote: > >> This is excellent! I will try to integrate your patch later this week >> and report back. I'm curious as to your porting experience? Was it >> hard? Is there anything I/we could learn from the exercise? I hope >> that we'll be able to add support for the most popular implementations, >> so any porting insights are welcome! > > Well, the only real hurdle was removing without-scheduling in > muproc-spawn, the rest was straightforward. The port was basically > finished over a month ago, but I found the fencepost error in > consume-input only on tuesday. I think the next ports will happen > faster now that we know that indeed only muproc-compat functionality is > needed to get cl-muproc running. > > Cheers, > > Rudi > Hi Rudi -- I just installed your patch. It looks very good indeed: Everything seems to works as intended -- the tests all pass and the system we're building also seems to be doing just fine. Excellent! I have reviewed all your changes, and have only a single comment: You introduce *muproc-spawn-lock* to serialize access to muproc-spawn. I think perhaps it would be preferable to simply use %with-exclusive-access%. In fact, thinking about this it occurred to me that (the previously existing) *giant-lock* probably be ought to be placed in the implementation specific files (muproc-{lispworks,openmcl}.lisp) because, strictly speaking, it is an artifact of the implementation of %with-exclusive-access% and not part of the implementation independent part of muproc. So I propose that the new serialized muproc-spawn uses the generic %with-exclusive-access%, that *giant-lock* is moved to both implementation-specific files, and that *muproc-spawn-lock* is eliminated. Let me know what you (which is plural 'you' btw, feel free to jump all you lurkers!) think... Nice work, Rudi! -Klaus. PS. In case anyone is wondering: I have not released a new version yet. I will post a notice when that happens. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3368 bytes Desc: S/MIME Cryptographic Signature URL: From svg at surnet.ru Thu Jul 6 09:56:10 2006 From: svg at surnet.ru (Vladimir Sekissov) Date: Thu, 06 Jul 2006 15:56:10 +0600 (YEKST) Subject: [cl-muproc-devel] [Patch] openmcl support In-Reply-To: <44ACB385.2020703@mu.dk> References: <44AB7814.6080606@mu.dk> <57AA1F2F-FCC8-49C9-9B4F-236C5794F340@constantly.at> <44ACB385.2020703@mu.dk> Message-ID: <20060706.155610.91318070.svg@surnet.ru> Good day, Klaus, Could you send me current version of CL-MUPROC code with OpenMCL patch? I've written port of CL-MUPROC to SBCL/CMUCL and it would be better if I merge my changes with actual code. Best Regards, Vladimir Sekissov From klaus at mu.dk Thu Jul 6 14:12:17 2006 From: klaus at mu.dk (Klaus Harbo) Date: Thu, 06 Jul 2006 16:12:17 +0200 Subject: [cl-muproc-devel] [Patch] openmcl support In-Reply-To: <20060706.155610.91318070.svg@surnet.ru> References: <44AB7814.6080606@mu.dk> <57AA1F2F-FCC8-49C9-9B4F-236C5794F340@constantly.at> <44ACB385.2020703@mu.dk> <20060706.155610.91318070.svg@surnet.ru> Message-ID: <44AD1A41.9030303@mu.dk> Vladimir Sekissov wrote: > Good day, Klaus, > > Could you send me current version of CL-MUPROC code with OpenMCL > patch? > > I've written port of CL-MUPROC to SBCL/CMUCL and it would be better if > I merge my changes with actual code. > > Best Regards, > Vladimir Sekissov > Sounds great! It seems that Rudi is busy today, and since my questions/suggestions did not concern critical issues, I have released a new version of cl-muproc including support for openmcl. It is available at the usual place, http://www.mu.dk/cl-muproc. I look forward to seeing your port! -Klaus. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3368 bytes Desc: S/MIME Cryptographic Signature URL: From anton.belyaev at gmail.com Thu Jul 6 18:19:19 2006 From: anton.belyaev at gmail.com (Anton V. Belyaev) Date: Thu, 06 Jul 2006 22:19:19 +0400 Subject: [cl-muproc-devel] threads nature and CVS access In-Reply-To: <44AD1A41.9030303@mu.dk> References: <44AB7814.6080606@mu.dk> <57AA1F2F-FCC8-49C9-9B4F-236C5794F340@constantly.at> <44ACB385.2020703@mu.dk> <20060706.155610.91318070.svg@surnet.ru> <44AD1A41.9030303@mu.dk> Message-ID: <44AD5427.90108@gmail.com> Hi guys! I have a couple of quick questions: 1) Does project have CVS? 2) What is the nature of threads? Erlang "threads" are not mapped one-to-one to system threads. Is it true for cl-muproc? From klaus at mu.dk Thu Jul 6 19:16:58 2006 From: klaus at mu.dk (Klaus Harbo) Date: Thu, 06 Jul 2006 21:16:58 +0200 Subject: [cl-muproc-devel] threads nature and CVS access In-Reply-To: <44AD5427.90108@gmail.com> References: <44AB7814.6080606@mu.dk> <57AA1F2F-FCC8-49C9-9B4F-236C5794F340@constantly.at> <44ACB385.2020703@mu.dk> <20060706.155610.91318070.svg@surnet.ru> <44AD1A41.9030303@mu.dk> <44AD5427.90108@gmail.com> Message-ID: <44AD61AA.6080308@mu.dk> Anton V. Belyaev wrote: > Hi guys! > > I have a couple of quick questions: > > 1) Does project have CVS? > > 2) What is the nature of threads? Erlang "threads" are not mapped > one-to-one to system threads. Is it true for cl-muproc? > _______________________________________________ > cl-muproc-devel mailing list > cl-muproc-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cl-muproc-devel Re CVS: We use darcs for version control. There is no publically accessible repository at this time; if there is strong demand for this, I believe we could add that some time (I am not entirely sure what that would entail). Re threads: cl-muproc relies on the implementation's process implementation for muprocs. In current (v4) Lispworks this means 'green' (non-OS) threads, whereas in SBCL and the upcoming v5 of Lispworks, for example, it means native threads. cl-muproc does not explicitly specify the implementation/representation of muprocs -- both can work. I do not think anything in cl-muprocs precludes developing alternative muproc implementations which could be more efficient under some circumstances. Erlang processes are extremely efficient, LW's processes much less so. It could be an interesting project to see if similar efficiencies could be achieved in some CL implementation by 'hand-coding' a muproc implementation in Lisp (I have not given this any serious thought, perhaps that is not a realistic proposition). The efficiency of muprocs is quite important, I think, since it ultimately impacts your system design -- can you scale by spawning additional muprocs, or do you have to use some other means? A few hundred muprocs (which is what LW and Allegro can realistically support at this time) does not offer sufficient scalability, if we just want to scale by spawning new muprocs. In the system we're working on at Mu, we use state machines inside muprocs to enable a single muproc to keep track of many processes; it works and performs quite well but the downside is the added complexity of coding state machines. Ultimately, I believe we will scale by distributing the load across several Lisp images running on multiple hosts. HTH, -Klaus. From rudi at constantly.at Thu Jul 6 22:39:46 2006 From: rudi at constantly.at (Rudi Schlatte) Date: Fri, 7 Jul 2006 00:39:46 +0200 Subject: [cl-muproc-devel] [Patch] openmcl support In-Reply-To: <44ACB385.2020703@mu.dk> References: <44AB7814.6080606@mu.dk> <57AA1F2F-FCC8-49C9-9B4F-236C5794F340@constantly.at> <44ACB385.2020703@mu.dk> Message-ID: On 6. Jul 2006, at 08:53, Klaus Harbo wrote: > I just installed your patch. It looks very good indeed: > Everything seems to works as intended -- the tests all pass and the > system we're building also seems to be doing just fine. Excellent! Good to hear that, thanks! > I have reviewed all your changes, and have only a single comment: > You introduce *muproc-spawn-lock* to serialize access to muproc- > spawn. I think perhaps it would be preferable to simply use %with- > exclusive-access%. In fact, thinking about this it occurred to me > that (the previously existing) *giant-lock* probably be ought to be > placed in the implementation specific files (muproc- > {lispworks,openmcl}.lisp) because, strictly speaking, it is an > artifact of the implementation of %with-exclusive-access% and not > part of the implementation independent part of muproc. I agree re *giant-lock*. If I recall correctly, I introduced a second lock so as not to have to think about nested %with-exclusive- access% forms. In that case, the locks must be recursive or %with- exclusive-access% must be a bit smarter. I coded the simplest thing and then never revisited the decision. > So I propose that the new serialized muproc-spawn uses the generic % > with-exclusive-access%, that *giant-lock* is moved to both > implementation-specific files, and that *muproc-spawn-lock* is > eliminated. Sounds good. I also forgot to remove %without-scheduling% from the muproc-compat package; that symbol is not used any more, so can be eliminated. Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From rudi at constantly.at Thu Jul 6 22:46:38 2006 From: rudi at constantly.at (Rudi Schlatte) Date: Fri, 7 Jul 2006 00:46:38 +0200 Subject: [cl-muproc-devel] threads nature and CVS access In-Reply-To: <44AD61AA.6080308@mu.dk> References: <44AB7814.6080606@mu.dk> <57AA1F2F-FCC8-49C9-9B4F-236C5794F340@constantly.at> <44ACB385.2020703@mu.dk> <20060706.155610.91318070.svg@surnet.ru> <44AD1A41.9030303@mu.dk> <44AD5427.90108@gmail.com> <44AD61AA.6080308@mu.dk> Message-ID: <1BFB7B70-BD26-4BE3-95CC-8456E9D0713B@constantly.at> On 6. Jul 2006, at 21:16, Klaus Harbo wrote: > We use darcs for version control. There is no publically > accessible repository at this time; if there is strong demand for > this, I believe we could add that some time (I am not entirely sure > what that would entail). Just rsync the source tree to somewhere that is accessible via http. We can then do "darcs get http://www.mu.dk/sources/cl-muproc/". I use darcs locally to develop cl-muproc as well, and this would simplify my workflow a bit. It's not a great deal though as long as new releases don't happen daily. :-) > Re threads: [...] > Ultimately, I believe we will scale by distributing the load across > several Lisp images running on multiple hosts. I thought a bit about sending mumsgs between muprocs not running in the same Lisp image. Arthur Lemmens has, in the context of rucksack, developed a serialization protocol for arbitrary Lisp objects that could be hijacked. I talked briefly to him at the Lisp workshop of ecoop06; he has no interest in factoring out that code himself, but thinks it might be a viable method for sending Lisp objects between machines. Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From klaus at mu.dk Fri Jul 7 11:26:52 2006 From: klaus at mu.dk (Klaus Harbo) Date: Fri, 07 Jul 2006 13:26:52 +0200 Subject: [cl-muproc-devel] [Patch] openmcl support In-Reply-To: References: <44AB7814.6080606@mu.dk> <57AA1F2F-FCC8-49C9-9B4F-236C5794F340@constantly.at> <44ACB385.2020703@mu.dk> Message-ID: <44AE44FC.7030101@mu.dk> Rudi Schlatte wrote: > > On 6. Jul 2006, at 08:53, Klaus Harbo wrote: > >> I just installed your patch. It looks very good indeed: Everything >> seems to works as intended -- the tests all pass and the system we're >> building also seems to be doing just fine. Excellent! > > Good to hear that, thanks! > >> I have reviewed all your changes, and have only a single comment: You >> introduce *muproc-spawn-lock* to serialize access to muproc-spawn. I >> think perhaps it would be preferable to simply use >> %with-exclusive-access%. In fact, thinking about this it occurred to >> me that (the previously existing) *giant-lock* probably be ought to be >> placed in the implementation specific files >> (muproc-{lispworks,openmcl}.lisp) because, strictly speaking, it is an >> artifact of the implementation of %with-exclusive-access% and not part >> of the implementation independent part of muproc. > > I agree re *giant-lock*. If I recall correctly, I introduced a second > lock so as not to have to think about nested %with-exclusive-access% > forms. In that case, the locks must be recursive or > %with-exclusive-access% must be a bit smarter. I coded the simplest > thing and then never revisited the decision. > >> So I propose that the new serialized muproc-spawn uses the generic >> %with-exclusive-access%, that *giant-lock* is moved to both >> implementation-specific files, and that *muproc-spawn-lock* is >> eliminated. > > Sounds good. I also forgot to remove %without-scheduling% from the > muproc-compat package; that symbol is not used any more, so can be > eliminated. > > Cheers, > > Rudi > I have made the changes as suggested above -- moved *giant-lock* to implementation specific files and eliminated %without-scheduling% entirely. It seems to work on LW. Also, I have made a copy of the DARCS repository publically available, at http://www.mu.dk/cl-muproc/src; you should be able to retrieve from there. Rudi, I have made changes to both the LW and OpenMCL implementations, but since I don't have OpenMCL, I haven't tested that part. Could you please retrieve from the repository and see if compiles w/o errors and warnings and passes the tests? If you need to make any changes, I'd prefer a darcs patch over a diff file! :-) -Klaus. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3368 bytes Desc: S/MIME Cryptographic Signature URL: From svg at surnet.ru Fri Jul 7 11:20:36 2006 From: svg at surnet.ru (Vladimir Sekissov) Date: Fri, 07 Jul 2006 17:20:36 +0600 (YEKST) Subject: [cl-muproc-devel] [Patch] openmcl support In-Reply-To: <44AD1A41.9030303@mu.dk> References: <44ACB385.2020703@mu.dk> <20060706.155610.91318070.svg@surnet.ru> <44AD1A41.9030303@mu.dk> Message-ID: <20060707.172036.102615041.svg@surnet.ru> Good day, Klaus, klaus> Sounds great! It seems that Rudi is busy today, and since my klaus> questions/suggestions did not concern critical issues, I have released a klaus> new version of cl-muproc including support for openmcl. It is available klaus> at the usual place, http://www.mu.dk/cl-muproc. klaus> klaus> I look forward to seeing your port! Code is in the attachment. It was tested under SBCL-0.9.13 and CMUCL-19c and passed all tests without errors. My porting strategy was slightly different. To avoid redundant code I first ported TIMER package of Zach Beane() to BORDEAUX-THREADS. It was modelled after and use the same interface as LispWorks timers. It is in the same archive. Then I used BORDEAUX-THREADS and TIMER where possible. So actually it is mostly the port to BORDEAUX-THREADS. I also made some changes in main muproc code to avoid the need in recursive locks and fixed some mistypings. Best Regards, Vladimir Sekissov -------------- next part -------------- A non-text attachment was scrubbed... Name: cl-muproc.tar.gz Type: application/octet-stream Size: 69806 bytes Desc: not available URL: From klaus at mu.dk Fri Jul 7 11:42:16 2006 From: klaus at mu.dk (Klaus Harbo) Date: Fri, 07 Jul 2006 13:42:16 +0200 Subject: [cl-muproc-devel] [Patch] openmcl support In-Reply-To: <20060707.172036.102615041.svg@surnet.ru> References: <44ACB385.2020703@mu.dk> <20060706.155610.91318070.svg@surnet.ru> <44AD1A41.9030303@mu.dk> <20060707.172036.102615041.svg@surnet.ru> Message-ID: <44AE4898.4070805@mu.dk> Vladimir Sekissov wrote: > Good day, Klaus, > > klaus> Sounds great! It seems that Rudi is busy today, and since my > klaus> questions/suggestions did not concern critical issues, I have released a > klaus> new version of cl-muproc including support for openmcl. It is available > klaus> at the usual place, http://www.mu.dk/cl-muproc. > klaus> > klaus> I look forward to seeing your port! > > Code is in the attachment. It was tested under SBCL-0.9.13 and > CMUCL-19c and passed all tests without errors. > > My porting strategy was slightly different. > > To avoid redundant code I first ported TIMER package of > Zach Beane() to BORDEAUX-THREADS. It was modelled after > and use the same interface as LispWorks timers. It is in the same > archive. > > Then I used BORDEAUX-THREADS and TIMER where possible. > > So actually it is mostly the port to BORDEAUX-THREADS. > > I also made some changes in main muproc code to avoid the need in > recursive locks and fixed some mistypings. > > Best Regards, > Vladimir Sekissov > > Great! Things are really moving! We'll need to integrate your changes with the changes applied in the last few days... I will be off-line for a couple of days, so I won't be able to look into that until I get back (Monday). -Klaus. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3368 bytes Desc: S/MIME Cryptographic Signature URL: From svg at surnet.ru Fri Jul 7 15:41:54 2006 From: svg at surnet.ru (Vladimir Sekissov) Date: Fri, 07 Jul 2006 21:41:54 +0600 (YEKST) Subject: [cl-muproc-devel] [Patch] openmcl support In-Reply-To: <44AE4898.4070805@mu.dk> References: <44AD1A41.9030303@mu.dk> <20060707.172036.102615041.svg@surnet.ru> <44AE4898.4070805@mu.dk> Message-ID: <20060707.214154.58442388.svg@surnet.ru> Good day, klaus> Great! Things are really moving! We'll need to integrate your changes klaus> with the changes applied in the last few days... I will be off-line for klaus> a couple of days, so I won't be able to look into that until I get back klaus> (Monday). I'd corrected code according to your recent changes. All tests were passed. Here is a diff in darcs format against public repository. I removed %WITH-EXCLUSIVE-ACCESS% from MUPROC-SPAWN because it is useless now. Exclusive access to shared resorces by locks in appropriate places and right order of MUPROC initialization already warrant against system damage. Only we can else do here - wrap init phase with WITHOUT-INTERRUPTS. Best Regards, Vladimir Sekissov -------------- next part -------------- A non-text attachment was scrubbed... Name: CHANGESET.gz Type: application/octet-stream Size: 4724 bytes Desc: not available URL: From albertosantini at gmail.com Fri Jul 7 22:47:53 2006 From: albertosantini at gmail.com (Alberto Santini) Date: Sat, 8 Jul 2006 00:47:53 +0200 Subject: [cl-muproc-devel] Openmcl 1.1 20060623... Message-ID: <6a066ca20607071547x4db182d6n3544abee96250e89@mail.gmail.com> Hello. Rudi, thanks for the openmcl porting. I tested cl-muproc with openmcl beta release (1.1 060623), downloading it from darcs repository just a few minutes ago, and the tests work fine. Only a note: I deleted the ":license" in cl-muproc.asd. It seems the asdf version (1.16) contained in openmcl doesn't support ":license". Regards, Alberto Santini From rudi at constantly.at Sat Jul 8 13:12:53 2006 From: rudi at constantly.at (Rudi Schlatte) Date: Sat, 8 Jul 2006 15:12:53 +0200 Subject: [cl-muproc-devel] [Patch] openmcl support In-Reply-To: <44AE44FC.7030101@mu.dk> References: <44AB7814.6080606@mu.dk> <57AA1F2F-FCC8-49C9-9B4F-236C5794F340@constantly.at> <44ACB385.2020703@mu.dk> <44AE44FC.7030101@mu.dk> Message-ID: On 7. Jul 2006, at 13:26, Klaus Harbo wrote: > Also, I have made a copy of the DARCS repository publically > available, at http://www.mu.dk/cl-muproc/src; you should be able to > retrieve from there. Worked fine, thanks! I 'darcs send'ed a patch that hasn't yet arrived, so here it is again. Just some compilation fixes for openmcl. openmcl ships with an older asdf version that doesn't yet know the :license initarg ... Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: openmcl-fixes.patch Type: application/octet-stream Size: 1168 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From klaus at mu.dk Mon Jul 10 09:41:43 2006 From: klaus at mu.dk (Klaus Harbo) Date: Mon, 10 Jul 2006 11:41:43 +0200 Subject: [cl-muproc-devel] Integration of OpenMCL and SBCL/CMUCL patches in darcs repo -- testing requested Message-ID: <44B220D7.6080300@mu.dk> I have now integrated the latest patches from Rudi and Vladimir. Tests pass on Lispworks, and I have made no real changes to any files in implementation-specific layer (well, I had to reintroduce %with-lock% in muproc-lispworks.lisp, but that should be relatively safe!). Vladimir has made some changes to muproc.lisp which are not related to porting per se, the most significant of which I believe is the introduction of a separate lock for *muproc-errorstream* and use of a muproc-specific lock for things which are not genuinely global (for which %with-exclusive-access% is still necessary, of course). I have accepted all these changes, which I believe to be sound. I do think, that perhaps we should abstract the muproc-specific locking further and possibly eliminate the use of the process plist; i.e. wouldn't an explicit data structure protected by this lock be better than using process plist? I think so. The data could be introduced in the progv form in muproc-spawn and be protected by the lock already introduced by Vladimir. That way we're safe from updates performed by other part of the Lisp image (anyone can use the process plist). I have not created a new release yet, as I would really like Rudi and Vladimir (or anyone, actually) to test that the CMUCL, SBCL and OpenMCL support works after my changes. If you have time, please do! The latest version is available from the public repository (http://www.mu.dk/cl-muproc/src). Rudi Schlatte wrote: > I thought a bit about sending mumsgs between muprocs not running in the > same Lisp image. Arthur Lemmens has, in the context of rucksack, > developed a serialization protocol for arbitrary Lisp objects that could > be hijacked. I talked briefly to him at the Lisp workshop of ecoop06; > he has no interest in factoring out that code himself, but thinks it > might be a viable method for sending Lisp objects between machines. I neglected to reply to this part of Rudi's email of Friday: I looked at Arthur's code earlier this year, and as far as I can remember it should be relatively straightforward to use his serializer in muproc -- the code is very clean; I don't think it depends on too much other stuff (haven't checked though). There is, however, quite a bit of other work that needs doing before muproc is distributed... ;-) -Klaus. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3368 bytes Desc: S/MIME Cryptographic Signature URL: From klaus at mu.dk Mon Jul 10 10:07:23 2006 From: klaus at mu.dk (Klaus Harbo) Date: Mon, 10 Jul 2006 12:07:23 +0200 Subject: [cl-muproc-devel] Darcs changesets by email? Message-ID: <44B226DB.9010802@mu.dk> Vladimir -- A practical question: I'm just learning to use email for transporting darcs patches. The CHANGESET file you sent worked perfectly; I would appreciate if you could enlighten me as to how you created/sent it? best regards, -Klaus. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3368 bytes Desc: S/MIME Cryptographic Signature URL: From rudi at constantly.at Mon Jul 10 10:15:41 2006 From: rudi at constantly.at (Rudi Schlatte) Date: Mon, 10 Jul 2006 12:15:41 +0200 Subject: [cl-muproc-devel] Integration of OpenMCL and SBCL/CMUCL patches in darcs repo -- testing requested In-Reply-To: <44B220D7.6080300@mu.dk> References: <44B220D7.6080300@mu.dk> Message-ID: On 10. Jul 2006, at 11:41, Klaus Harbo wrote: > I have not created a new release yet, as I would really like Rudi > and Vladimir (or anyone, actually) to test that the CMUCL, SBCL and > OpenMCL support works after my changes. If you have time, please do! No failing test cases with openmcl-pre1.1 and current darcs version. Thanks for the good work! Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From peter at mu.dk Tue Jul 11 05:51:16 2006 From: peter at mu.dk (Peter Mechlenborg=) Date: Tue, 11 Jul 2006 07:51:16 +0200 Subject: [cl-muproc-devel] Integration of OpenMCL and SBCL/CMUCL patches in darcs repo -- testing requested In-Reply-To: <44B220D7.6080300@mu.dk> References: <44B220D7.6080300@mu.dk> Message-ID: <44B33C54.2000202@mu.dk> Klaus Harbo wrote: > I have not created a new release yet, as I would really like Rudi and > Vladimir (or anyone, actually) to test that the CMUCL, SBCL and > OpenMCL support works after my changes. If you have time, please do! I have successfully compiled and tested the latest darcs version using SBCL-0.9.13 (x86 linux). Have fun, -- Peter From klaus at mu.dk Tue Jul 11 07:31:31 2006 From: klaus at mu.dk (Klaus Harbo) Date: Tue, 11 Jul 2006 09:31:31 +0200 Subject: [cl-muproc-devel] New release of cl-muproc with support for Lispworks, OpenMCL, SBCL, and CMUCL Message-ID: <44B353D3.1040307@mu.dk> I am pleased to announce the availability of a new version of cl-muproc including the recent patches adding support for OpenMCL, SBCL, and CMUCL to the previously existing support for Lispworks. It is available the usual place, http://www.mu.dk/cl-muproc. Great work, guys! -Klaus. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3368 bytes Desc: S/MIME Cryptographic Signature URL: From svg at surnet.ru Tue Jul 11 07:53:21 2006 From: svg at surnet.ru (Vladimir Sekissov) Date: Tue, 11 Jul 2006 13:53:21 +0600 (YEKST) Subject: [cl-muproc-devel] Integration of OpenMCL and SBCL/CMUCL patches in darcs repo -- testing requested In-Reply-To: <44B220D7.6080300@mu.dk> References: <44B220D7.6080300@mu.dk> Message-ID: <20060711.135321.98715750.svg@surnet.ru> Good day, klaus> I have not created a new release yet, as I would really like klaus> Rudi and Vladimir klaus> (or anyone, actually) to test that the CMUCL, SBCL and OpenMCL klaus> support works klaus> after my changes. If you have time, please do! Tested under SBCL/CMUCL. All tests were passed. Best Regards, Vladimir Sekissov From svg at surnet.ru Tue Jul 11 08:00:13 2006 From: svg at surnet.ru (Vladimir Sekissov) Date: Tue, 11 Jul 2006 14:00:13 +0600 (YEKST) Subject: [cl-muproc-devel] Re: Darcs changesets by email? In-Reply-To: <44B226DB.9010802@mu.dk> References: <44B226DB.9010802@mu.dk> Message-ID: <20060711.140013.169825310.svg@surnet.ru> Good day, Klaus, klaus> A practical question: I'm just learning to use email for klaus>transporting darcs klaus> patches. The CHANGESET file you sent worked perfectly; I would klaus>appreciate if klaus> you could enlighten me as to how you created/sent it? Usually I do: $ darcs send -o CHANGESET ... Choosing patches interactively... $ gzip CHANGESET Best Regards, Vladimir Sekissov From svg at surnet.ru Tue Jul 11 17:23:10 2006 From: svg at surnet.ru (Vladimir Sekissov) Date: Tue, 11 Jul 2006 23:23:10 +0600 (YEKST) Subject: [cl-muproc-devel] [PATCH] Adding Erlang-style timeout to MUMSG-RECEIVE In-Reply-To: <20060711.135321.98715750.svg@surnet.ru> References: <44B220D7.6080300@mu.dk> <20060711.135321.98715750.svg@surnet.ru> Message-ID: <20060711.232310.130855229.svg@surnet.ru> Good day, The patch in the attachment is adding Erlang-style timeout clause to MUMSG-RECEIVE. TIMEOUT is active only on packet-matching phase opposite to WITH-TIMEOUT which can break in the middle of message processing clause body. Semantic is the same as of TIMEOUT in Erlang RECEIVE statement. Syntax: (TIMEOUT TIMEOUT-VALUE &body TIMEOUT-BODY) When TIMEOUT-VALUE is evaluated to: NIL or 0 -- non-blocking receiving. TIMEOUT-BODY is evaluated immediately if there is no pending input or all packet-matcing clauses are failed; NUMBER -- wait NUMBER seconds in packet-matching phase; T (generic boolean) -- the same as Erlang INFINITY, wait before matching input. Example: (mumsg-receive (from) ((request) t (push request acc)) .... (timeout 0 (push :receiver-timed-out acc) (%enqueue% mbox (nreverse acc)))) Tested with SBCL/CMUCL. For CMUCL you need bug-fixed TIMER package and bug-fixing patch for BORDEAUX-THREADS. Both are in the attachments. There is possible conflict in simultaneous use of TIMEOUT in RECEIVE and WITH-TIMEOUT if implementation-dependent timers don't care about recursion (one timer can catch a signal from another). I fixed this for SBCL/CMUCL but haven't access to LispWorks and OpenMCL. Best Regards, Vladimir Sekissov -------------- next part -------------- A non-text attachment was scrubbed... Name: CHANGESET.gz Type: application/octet-stream Size: 3520 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BORDEAUX-CHANGESET.gz Type: application/octet-stream Size: 1048 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: timer.tar.gz Type: application/octet-stream Size: 7293 bytes Desc: not available URL: From luismbo at gmail.com Tue Jul 11 23:30:35 2006 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Wed, 12 Jul 2006 00:30:35 +0100 Subject: [cl-muproc-devel] Allegro CL port Message-ID: <8708D3F1-C862-4400-BDBF-AF5881083F76@gmail.com> Hello. Attached is the following patch that adds an Allegro CL port to cl- muproc. Feel free to ignore the unrelated changes to cl-muproc.asd. Wed Jul 12 00:24:56 WEST 2006 Luis Oliveira * Allegro CL port. Passes all tests under Allegro CL 8.0 Express Edition on Mac OS 10.4.7. (Also, simplified cl-muproc.asd.) -------------- next part -------------- A non-text attachment was scrubbed... Name: muproc-allegro.patch Type: application/octet-stream Size: 8774 bytes Desc: not available URL: -------------- next part -------------- -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From klaus at mu.dk Wed Jul 12 21:40:03 2006 From: klaus at mu.dk (Klaus Harbo) Date: Wed, 12 Jul 2006 23:40:03 +0200 Subject: [cl-muproc-devel] Allegro CL port In-Reply-To: <8708D3F1-C862-4400-BDBF-AF5881083F76@gmail.com> References: <8708D3F1-C862-4400-BDBF-AF5881083F76@gmail.com> Message-ID: <44B56C33.7000001@mu.dk> Lu?s Oliveira wrote: > Hello. > > Attached is the following patch that adds an Allegro CL port to > cl-muproc. Feel free to ignore the unrelated changes to cl-muproc.asd. > > > Wed Jul 12 00:24:56 WEST 2006 Luis Oliveira > * Allegro CL port. > > Passes all tests under Allegro CL 8.0 Express Edition on Mac OS 10.4.7. > (Also, simplified cl-muproc.asd.) > Great Luis! cl-muproc with support for Allegro is available in the repository as well as in a new release. Wow, support for 4 new platforms in less than a week --- I'm impressed, guys! ;-) Much faster than I had ever hoped. AFAICT, cl-muproc is now available to the vast majority of Common Lisp users. -Klaus. From klaus at mu.dk Thu Jul 13 07:17:41 2006 From: klaus at mu.dk (Klaus Harbo) Date: Thu, 13 Jul 2006 09:17:41 +0200 Subject: [cl-muproc-devel] Re: [PATCH] Adding Erlang-style timeout to MUMSG-RECEIVE In-Reply-To: <20060711.232310.130855229.svg@surnet.ru> References: <44B220D7.6080300@mu.dk> <20060711.135321.98715750.svg@surnet.ru> <20060711.232310.130855229.svg@surnet.ru> Message-ID: <44B5F395.5050607@mu.dk> Hi Vladimir -- Vladimir Sekissov wrote: > Good day, > > The patch in the attachment is adding Erlang-style timeout clause to > MUMSG-RECEIVE. TIMEOUT is active only on packet-matching phase > opposite to WITH-TIMEOUT which can break in the middle of message > processing clause body. > > Semantic is the same as of TIMEOUT in Erlang RECEIVE statement. > > Syntax: > > (TIMEOUT TIMEOUT-VALUE &body TIMEOUT-BODY) > > When TIMEOUT-VALUE is evaluated to: > > NIL or 0 -- non-blocking receiving. TIMEOUT-BODY is evaluated > immediately if there is no pending input or all packet-matcing clauses > are failed; > > NUMBER -- wait NUMBER seconds in packet-matching phase; > > T (generic boolean) -- the same as Erlang INFINITY, wait before > matching input. > > Example: > > (mumsg-receive (from) > ((request) t > (push request acc)) > .... > (timeout 0 > (push :receiver-timed-out acc) > (%enqueue% mbox (nreverse acc)))) Until now, I have gotten by using (muproc-with-timeout (...) (mumsg-receive (...) ...)) but I believe this is a definite improvement: It allows you to scan the input queue for specific content without blocking or waiting at least some period of time. I think that is valuable. (There are probably other things as well.) Also, I have tried it on Lispworks, and seems to work as advertised. > Tested with SBCL/CMUCL. > > For CMUCL you need bug-fixed TIMER package and bug-fixing patch for > BORDEAUX-THREADS. > > Both are in the attachments. This concerns me somewhat. I admit I don't know much about BORDEAUX or the timer library you include, but you mention that they are bug-fixed -- does that mean that they'll need to be included in the cl-muproc distribution? Does the bug-fixing mean that we've effectively branched these libraries and that we'll need to maintain them separately from now on? I'd appreciate if you could enlighten us a bit here... > There is possible conflict in simultaneous use of TIMEOUT in RECEIVE > and WITH-TIMEOUT if implementation-dependent timers don't care about > recursion (one timer can catch a signal from another). > > I fixed this for SBCL/CMUCL but haven't access to LispWorks and OpenMCL. I'm pretty sure that this works correctly on Lispworks, don't know about OpenMCL. > > Best Regards, > Vladimir Sekissov > -Klaus. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3368 bytes Desc: S/MIME Cryptographic Signature URL: From albertosantini at gmail.com Thu Jul 13 21:25:10 2006 From: albertosantini at gmail.com (Alberto Santini) Date: Thu, 13 Jul 2006 23:25:10 +0200 Subject: [cl-muproc-devel] Re: [PATCH] Adding Erlang-style timeout to MUMSG-RECEIVE In-Reply-To: <44B5F395.5050607@mu.dk> References: <44B220D7.6080300@mu.dk> <20060711.135321.98715750.svg@surnet.ru> <20060711.232310.130855229.svg@surnet.ru> <44B5F395.5050607@mu.dk> Message-ID: <6a066ca20607131425n55f98c11qb2f9ccf356cf3ff5@mail.gmail.com> Hello. No problem with OpenMCL 1.1-pre-060705 on Mac OS X 10.4.7. Regards, Alberto. On 7/13/06, Klaus Harbo wrote: [cutted] > > > > I fixed this for SBCL/CMUCL but haven't access to LispWorks and OpenMCL. > > I'm pretty sure that this works correctly on Lispworks, don't know about OpenMCL. > > > > > Best Regards, > > Vladimir Sekissov > > > > -Klaus. > > > _______________________________________________ > cl-muproc-devel mailing list > cl-muproc-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cl-muproc-devel > > > >