From munro at ip9.org Wed Apr 4 21:33:04 2012 From: munro at ip9.org (Thomas Munro) Date: Wed, 4 Apr 2012 22:33:04 +0100 Subject: [Bordeaux-threads-devel] CONDITION-WAIT with timeout Message-ID: Hi Are there any plans to support a timeout for bordeaux-threads:condition-wait? The implementations I'm aware of support this threading primitive: * ABCL could presumably do it since Java Object.wait can take a timeout * SBCL supports it using sb-thread:condition-wait with keyword :timeout [1] * anything with POSIX threads underneath could use pthread_cond_timedwait The main variation seems to be between those implementations that use an absolute time and those that use a relative time (how long to wait in milliseconds for example). Since I think I need this feature I might try to write a patch to do this for ABCL and SBCL if there is nothing already in the works (unless there is some technical problem I'm not seeing?) Thanks Thomas Munro [1] http://random-state.net/log/3523852985.html From kamils80 at gmail.com Tue Apr 17 12:08:44 2012 From: kamils80 at gmail.com (Kamil Shakirov) Date: Tue, 17 Apr 2012 19:08:44 +0700 Subject: [Bordeaux-threads-devel] [patch] LispWorks 6.x MP updates + EOS Message-ID: Hello, The attached patches do not add or fix anything, just clean up the lispworks implementation a bit. ;-) 1) bordeaux-threads-0.8.1+lw6x.patch This patch updates lispworks implementation reflecting all recent changes in LispWorks 6.x MP API. Some MP calls are still available in 6.x but considered deprecated and removed from documentation. 1.1) current-thread() changes It is better to use mp:get-current-process() that was introduced in LispWorks 5.1 instead of mp:*current-process* that can be bound to another process. 1.2) threadp() changes MP provides its own predicates for processes. 1.3) acquire-recursive-lock() and release-recursive-lock() changes I am getting warnings when compiling bordeaux-threads, so why not 'declaim' these calls 'inline' instead (fixed in the patch) ;;;*** Warning in BORDEAUX-THREADS:ACQUIRE-RECURSIVE-LOCK: Inline expansion for BORDEAUX-THREADS:ACQUIRE-LOCK not found ;;;*** Warning in BORDEAUX-THREADS:ACQUIRE-RECURSIVE-LOCK: Inline expansion for BORDEAUX-THREADS:ACQUIRE-LOCK not found ; BORDEAUX-THREADS:ACQUIRE-RECURSIVE-LOCK ;;;*** Warning in BORDEAUX-THREADS:RELEASE-RECURSIVE-LOCK: Inline expansion for BORDEAUX-THREADS:RELEASE-LOCK not found ;;;*** Warning in BORDEAUX-THREADS:RELEASE-RECURSIVE-LOCK: Inline expansion for BORDEAUX-THREADS:RELEASE-LOCK not found 1.4) join-thread() changes LispWorks 6.0 introduces its own mp:process-join() function. 2) bordeaux-threads-0.8.1+eos.patch This patch replaces FiveAM with Eos. Eos has no dependencies and backward compatible with FIveAM API. I couldn't manage to load FiveAM in LW because of arnesi loading errors. All tests work fine with Eos (tested with recent Clozure CL, SBCL and LW 6.1). Thank you for your time. ;-) -- --ska -------------- next part -------------- A non-text attachment was scrubbed... Name: bordeaux-threads-0.8.1+lw6x.patch Type: application/octet-stream Size: 1660 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bordeaux-threads-0.8.1+eos.patch Type: application/octet-stream Size: 2136 bytes Desc: not available URL: From sionescu at cddr.org Tue Apr 17 14:10:37 2012 From: sionescu at cddr.org (Stelian Ionescu) Date: Tue, 17 Apr 2012 16:10:37 +0200 Subject: [Bordeaux-threads-devel] [patch] LispWorks 6.x MP updates + EOS In-Reply-To: References: Message-ID: <1334671837.15697.6.camel@cathai> On Tue, 2012-04-17 at 19:08 +0700, Kamil Shakirov wrote: > Hello, > > The attached patches do not add or fix anything, just clean up the > lispworks implementation a bit. ;-) > > 1) bordeaux-threads-0.8.1+lw6x.patch Thanks, I merged a slightly different patch > 2) bordeaux-threads-0.8.1+eos.patch > > This patch replaces FiveAM with Eos. Eos has no dependencies and > backward compatible with FIveAM API. Obviously not, because fixtures are missing. I'll see what I can do about it, but I won't merge the patch for the moment -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sionescu at cddr.org Tue Apr 17 14:11:37 2012 From: sionescu at cddr.org (Stelian Ionescu) Date: Tue, 17 Apr 2012 16:11:37 +0200 Subject: [Bordeaux-threads-devel] CONDITION-WAIT with timeout In-Reply-To: References: Message-ID: <1334671897.15697.7.camel@cathai> On Wed, 2012-04-04 at 22:33 +0100, Thomas Munro wrote: > Hi > > Are there any plans to support a timeout for > bordeaux-threads:condition-wait? The implementations I'm > aware of support this threading primitive: > > * ABCL could presumably do it since Java Object.wait can take a timeout > * SBCL supports it using sb-thread:condition-wait with keyword :timeout [1] > * anything with POSIX threads underneath could use pthread_cond_timedwait > > The main variation seems to be between those implementations that > use an absolute time and those that use a relative time (how long > to wait in milliseconds for example). > > Since I think I need this feature I might try to write a patch to > do this for ABCL and SBCL if there is nothing already in > the works (unless there is some technical problem I'm not seeing?) I'd like to, but what do we do for those implementations that don't support timeouts ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From kamils80 at gmail.com Tue Apr 17 14:43:24 2012 From: kamils80 at gmail.com (Kamil Shakirov) Date: Tue, 17 Apr 2012 21:43:24 +0700 Subject: [Bordeaux-threads-devel] [patch] LispWorks 6.x MP updates + EOS In-Reply-To: <1334671837.15697.6.camel@cathai> References: <1334671837.15697.6.camel@cathai> Message-ID: On Tuesday, April 17, 2012, Stelian Ionescu wrote: > On Tue, 2012-04-17 at 19:08 +0700, Kamil Shakirov wrote: > > Hello, > > > 2) bordeaux-threads-0.8.1+eos.patch > > > > This patch replaces FiveAM with Eos. Eos has no dependencies and > > backward compatible with FIveAM API. > > Obviously not, because fixtures are missing. I'll see what I can do > about it, but I won't merge the patch for the moment > > thanks :) Eos had had fixtures before but they were since removed according to the change logs. > > -- > Stelian Ionescu a.k.a. fe[nl]ix > Quidquid latine dictum sit, altum videtur. > http://common-lisp.net/project/iolib > > -- --ska -------------- next part -------------- An HTML attachment was scrubbed... URL: From sionescu at cddr.org Tue Apr 17 15:21:41 2012 From: sionescu at cddr.org (Stelian Ionescu) Date: Tue, 17 Apr 2012 17:21:41 +0200 Subject: [Bordeaux-threads-devel] Deprecating recursive locks Message-ID: <1334676101.15697.18.camel@cathai> They're an ugly hack, as described their inventor David Butenhof (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive lock, but it's not a posix recursive lock), so I was thinking of making a 1.0 release in which to remove them altogether. What do you think ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sionescu at cddr.org Tue Apr 17 15:29:39 2012 From: sionescu at cddr.org (Stelian Ionescu) Date: Tue, 17 Apr 2012 17:29:39 +0200 Subject: [Bordeaux-threads-devel] Upcoming release 0.8.2 Message-ID: <1334676579.15697.20.camel@cathai> I'm planning to make a new release, so if anybody has any request, please speak up -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From vsedach at gmail.com Tue Apr 17 15:54:50 2012 From: vsedach at gmail.com (Vladimir Sedach) Date: Tue, 17 Apr 2012 11:54:50 -0400 Subject: [Bordeaux-threads-devel] [patch] LispWorks 6.x MP updates + EOS In-Reply-To: <1334671837.15697.6.camel@cathai> References: <1334671837.15697.6.camel@cathai> Message-ID: Hi, The attached patch removes the def-fixture from the bordeaux-threads test suite, this also makes the code simpler incidentally. One reason I strongly urge moving from FiveAM to EOS is that FiveAM depends on the Arnesi library, which has a lot of very brittle implementation dependencies. Vladimir On Tue, Apr 17, 2012 at 10:10 AM, Stelian Ionescu wrote: > On Tue, 2012-04-17 at 19:08 +0700, Kamil Shakirov wrote: >> Hello, >> >> The attached patches do not add or fix anything, just clean up the >> lispworks implementation a bit. ;-) >> >> 1) bordeaux-threads-0.8.1+lw6x.patch > > Thanks, I merged a slightly different patch > > >> 2) bordeaux-threads-0.8.1+eos.patch >> >> This patch replaces FiveAM with Eos. Eos has no dependencies and >> backward compatible with FIveAM API. > > Obviously not, because fixtures are missing. I'll see what I can do > about it, but I won't merge the patch for the moment > > > -- > Stelian Ionescu a.k.a. fe[nl]ix > Quidquid latine dictum sit, altum videtur. > http://common-lisp.net/project/iolib > > > _______________________________________________ > Bordeaux-threads-devel mailing list > Bordeaux-threads-devel at common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Removed-fixtures-from-test-suite.patch Type: application/octet-stream Size: 1119 bytes Desc: not available URL: From vsedach at gmail.com Tue Apr 17 16:14:31 2012 From: vsedach at gmail.com (Vladimir Sedach) Date: Tue, 17 Apr 2012 12:14:31 -0400 Subject: [Bordeaux-threads-devel] Deprecating recursive locks In-Reply-To: <1334676101.15697.18.camel@cathai> References: <1334676101.15697.18.camel@cathai> Message-ID: I think it is a very good idea. When are you planning the 1.0 release? It would be nice to go through all the systems dependent on bordeaux-threads in Quicklisp and notify the maintainers of any that use recursive locks to fix their code. Vladimir On Tue, Apr 17, 2012 at 11:21 AM, Stelian Ionescu wrote: > They're an ugly hack, as described their inventor David Butenhof > (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by > all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive > lock, but it's not a posix recursive lock), so I was thinking of making > a 1.0 release in which to remove them altogether. > > What do you think ? > > -- > Stelian Ionescu a.k.a. fe[nl]ix > Quidquid latine dictum sit, altum videtur. > http://common-lisp.net/project/iolib > > > _______________________________________________ > Bordeaux-threads-devel mailing list > Bordeaux-threads-devel at common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel > From sionescu at cddr.org Tue Apr 17 16:17:30 2012 From: sionescu at cddr.org (Stelian Ionescu) Date: Tue, 17 Apr 2012 18:17:30 +0200 Subject: [Bordeaux-threads-devel] Deprecating recursive locks In-Reply-To: References: <1334676101.15697.18.camel@cathai> Message-ID: <1334679450.14606.0.camel@cathai> On Tue, 2012-04-17 at 12:14 -0400, Vladimir Sedach wrote: > I think it is a very good idea. > > When are you planning the 1.0 release? It would be nice to go through > all the systems dependent on bordeaux-threads in Quicklisp and notify > the maintainers of any that use recursive locks to fix their code. A month or two, perhaps. It depends on my spare time -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From avodonosov at yandex.ru Tue Apr 17 19:09:00 2012 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Tue, 17 Apr 2012 23:09:00 +0400 Subject: [Bordeaux-threads-devel] Deprecating recursive locks In-Reply-To: <1334676101.15697.18.camel@cathai> References: <1334676101.15697.18.camel@cathai> Message-ID: <92711334689741@web7e.yandex.ru> 17.04.2012, 19:21, "Stelian Ionescu" : > They're an ugly hack, as described their inventor David Butenhof > (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by > all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive > lock, but it's not a posix recursive lock), so I was thinking of making > a 1.0 release in which to remove them altogether. > > What do you think ? Does it mean that every time, when trying to lock an object, we will need to ensure it hasn't been locked already? If yes, it complicates writing synchronization code. But if it can not be reliably supported based on the features provided by all lisps, then removing them may probably be right. From avodonosov at yandex.ru Tue Apr 17 21:48:33 2012 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Wed, 18 Apr 2012 01:48:33 +0400 Subject: [Bordeaux-threads-devel] Deprecating recursive locks In-Reply-To: References: <1334676101.15697.18.camel@cathai> Message-ID: <4911334699313@web128.yandex.ru> 17.04.2012, 20:14, "Vladimir Sedach" : > I think it is a very good idea. > > When are you planning the 1.0 release? It would be nice to go through > all the systems dependent on bordeaux-threads in Quicklisp and notify > the maintainers of any that use recursive locks to fix their code. > If the public API is changed in a not-backward-compatible way, I would suggest to release new ASDF system (bordeaux-threads2), and leave the old version available in quicklisp forever. People who are ready to use new version, just add bordeaux-thread2 into their ASDF dependency. Others are able to use old version. This is a good practice. And it costs nothing. Some links on this subject: http://lispcaveats.tumblr.com/post/13259176455/ffi-linking-against-shared-libraries http://semver.org/ From munro at ip9.org Wed Apr 18 00:20:19 2012 From: munro at ip9.org (Thomas Munro) Date: Wed, 18 Apr 2012 01:20:19 +0100 Subject: [Bordeaux-threads-devel] CONDITION-WAIT with timeout In-Reply-To: <1334671897.15697.7.camel@cathai> References: <1334671897.15697.7.camel@cathai> Message-ID: On 17 April 2012 15:11, Stelian Ionescu wrote: > I'd like to, but what do we do for those implementations that don't > support timeouts ? I went through the existing implementations and googled for timeout variants of the mechanisms being used and found these: ABCL: (threads:object-wait condition timeout) Allegro: ? Clisp: (mt:exemption exemption mutex :timeout timeout) Clozure: (ccl:timed-wait-on-semaphore semaphore timeout) CMUCL: ? Corman: ? ECL: (mp:condition-variable-timedwait condition mutex timeout) LispWorks simulated: ? LispWorks 6: (mp:condition-variable-wait condition mutex :timeout timeout) MCL: ? SBCL: (sb-thread:condition-wait condition mutex :timeout timeout) SCL: (thread:cond-var-timedwait condition mutex timeout) I couldn't immediately grok those with question marks, but I suspect it's possible for most of them though. I hope someone who knows those systems can comment. I don't have any suggestion on what to do if there is no implementation apart from the obvious and unsatisfactory 'raise an error at runtime'. From attila.lendvai at gmail.com Wed Apr 18 04:15:14 2012 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Wed, 18 Apr 2012 10:15:14 +0600 Subject: [Bordeaux-threads-devel] Deprecating recursive locks In-Reply-To: <4911334699313@web128.yandex.ru> References: <1334676101.15697.18.camel@cathai> <4911334699313@web128.yandex.ru> Message-ID: > If the public API is changed in a not-backward-compatible way, I would > suggest to release new ASDF system (bordeaux-threads2), and > leave the old version available in quicklisp forever. > > People who are ready to use new version, just add bordeaux-thread2 > into their ASDF dependency. Others are able to use old version. > > This is a good practice. And it costs nothing. IMHO it's not a good practice and it does cost complexity/noise. you lose the clarity around the digital representation(s) of the identity of the library. there's only one b-t library, and the fact that it has changed in a way that made it incompatible with something else does not change its identity. but it's only the 0.02 of an outsider... -- ?attila Notice the erosion of your (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C ?963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06 From sionescu at cddr.org Wed Apr 18 09:56:42 2012 From: sionescu at cddr.org (Stelian Ionescu) Date: Wed, 18 Apr 2012 11:56:42 +0200 Subject: [Bordeaux-threads-devel] CONDITION-WAIT with timeout In-Reply-To: References: <1334671897.15697.7.camel@cathai> Message-ID: <1334743002.4066.2.camel@cathai> On Wed, 2012-04-18 at 01:20 +0100, Thomas Munro wrote: > On 17 April 2012 15:11, Stelian Ionescu wrote: > > I'd like to, but what do we do for those implementations that don't > > support timeouts ? > > I went through the existing implementations and googled for > timeout variants of the mechanisms being used and found these: > > ABCL: (threads:object-wait condition timeout) > Allegro: ? > Clisp: (mt:exemption exemption mutex :timeout timeout) > Clozure: (ccl:timed-wait-on-semaphore semaphore timeout) > CMUCL: ? > Corman: ? > ECL: (mp:condition-variable-timedwait condition mutex timeout) > LispWorks simulated: ? > LispWorks 6: (mp:condition-variable-wait condition mutex :timeout timeout) > MCL: ? > SBCL: (sb-thread:condition-wait condition mutex :timeout timeout) > SCL: (thread:cond-var-timedwait condition mutex timeout) > > I couldn't immediately grok those with question marks, but I > suspect it's possible for most of them though. I hope someone > who knows those systems can comment. > > I don't have any suggestion on what to do if there is no > implementation apart from the obvious and unsatisfactory 'raise > an error at runtime'. Then I'd be grateful if you could add timeout support and send us a patch :) -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From munro at ip9.org Thu Apr 19 07:28:12 2012 From: munro at ip9.org (Thomas Munro) Date: Thu, 19 Apr 2012 08:28:12 +0100 Subject: [Bordeaux-threads-devel] CONDITION-WAIT with timeout In-Reply-To: <1334743002.4066.2.camel@cathai> References: <1334671897.15697.7.camel@cathai> <1334743002.4066.2.camel@cathai> Message-ID: On 18 April 2012 10:56, Stelian Ionescu wrote: > Then I'd be grateful if you could add timeout support and send us a > patch :) Ok -- so I guess I need to write a patch that covers as many Lisps as I can get my hands on for testing, and a test that demonstrates that it works correctly. Before I go ahead and do that, below is an example showing what the ABCL proposed implementation would look like, for feedback. Some questions and notes: 1. I'm using an &optional argument which seems the tidiest to me. Would anyone prefer to have a separate function instead, say CONDITION-TIMED-WAIT, or a &key? 2. The ABCL implementation cannot tell you whether the wait returned because of timeout (although others can), so to help people write portable code the return value would have to remain undefined. 3. For those implementations which can't support it yet, it might be an option to simply not accept the &optional argument, so that programs that need it fail to compile rather than failing at runtime on implementations that lack it. Alternatively I could make those implementation raise an error if TIMEOUT is not NIL. I guess timeout support could be advertised in *FEATURES*. Thanks, Thomas diff --git a/src/impl-abcl.lisp b/src/impl-abcl.lisp index 3c08db4..5b79271 100644 --- a/src/impl-abcl.lisp +++ b/src/impl-abcl.lisp @@ -98,10 +98,12 @@ Distributed under the MIT license (see LICENSE file) (defstruct condition-variable (name "Anonymous condition variable")) -(defun condition-wait (condition lock) +(defun condition-wait (condition lock &optional timeout) (threads:synchronized-on condition (release-lock lock) - (threads:object-wait condition)) + (if timeout + (threads:object-wait condition timeout) + (threads:object-wait condition))) (acquire-lock lock)) (defun condition-notify (condition) From sionescu at cddr.org Sat Apr 21 21:41:54 2012 From: sionescu at cddr.org (Stelian Ionescu) Date: Sat, 21 Apr 2012 23:41:54 +0200 Subject: [Bordeaux-threads-devel] [patch] LispWorks 6.x MP updates + EOS In-Reply-To: References: <1334671837.15697.6.camel@cathai> Message-ID: <1335044514.3984.14.camel@cathai> On Tue, 2012-04-17 at 11:54 -0400, Vladimir Sedach wrote: > Hi, > > The attached patch removes the def-fixture from the bordeaux-threads > test suite, this also makes the code simpler incidentally. > > One reason I strongly urge moving from FiveAM to EOS is that FiveAM > depends on the Arnesi library, which has a lot of very brittle > implementation dependencies. I now maintain FiveAM(http://fenlix.dreamwidth.org/2255.html) and I removed the dependency on Arnesi, so you can expect to see it in the next release of Quicklisp. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sionescu at cddr.org Sun Apr 22 14:41:03 2012 From: sionescu at cddr.org (Stelian Ionescu) Date: Sun, 22 Apr 2012 16:41:03 +0200 Subject: [Bordeaux-threads-devel] Deprecating recursive locks In-Reply-To: <4911334699313@web128.yandex.ru> References: <1334676101.15697.18.camel@cathai> <4911334699313@web128.yandex.ru> Message-ID: <1335105663.9582.9.camel@cathai> On Wed, 2012-04-18 at 01:48 +0400, Anton Vodonosov wrote: > > 17.04.2012, 20:14, "Vladimir Sedach" : > > I think it is a very good idea. > > > > When are you planning the 1.0 release? It would be nice to go through > > all the systems dependent on bordeaux-threads in Quicklisp and notify > > the maintainers of any that use recursive locks to fix their code. > > > > If the public API is changed in a not-backward-compatible way, I would > suggest to release new ASDF system (bordeaux-threads2), and > leave the old version available in quicklisp forever. > > People who are ready to use new version, just add bordeaux-thread2 > into their ASDF dependency. Others are able to use old version. > > This is a good practice. And it costs nothing. > > Some links on this subject: > http://lispcaveats.tumblr.com/post/13259176455/ffi-linking-against-shared-libraries That post contains a good analysis of the problem, but then gives the worst possible advice to solve it > http://semver.org/ Point 5 says "Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable". So no problem there -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: