From sionescu at common-lisp.net  Sun Feb  1 05:00:05 2009
From: sionescu at common-lisp.net (Stelian Ionescu)
Date: Sun, 01 Feb 2009 05:00:05 +0000
Subject: [iolib-devel] New patches: 31-Jan-2009
Message-ID: <E1LTURB-0005q6-Aq@common-lisp.net>


commit ce53965b9a3864c772d4423c013ed07b36997ea4
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Sun Feb 1 02:15:22 2009 +0100

    Add entries about the last bug fixes in the multiplexer.

 CHANGES |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

commit ae6922c24f0dc958087eca74020bceebeb208a05
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Sun Feb 1 02:07:36 2009 +0100

    Fix select() multiplexer: possible fd lossage in RECALC-FD-MASKS.

 src/multiplex/backend-select.lisp |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

commit e4c7ae934c06776386e23bd66a7cf29f26f9eb21
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Sat Jan 31 22:03:29 2009 +0100

    Fill poll timeout calculation in EVENT-DISPATCH, minor other fixes.

 src/iolib.multiplex.asd       |    9 ++++-----
 src/multiplex/event-loop.lisp |   26 ++++++++++++++++----------
 src/multiplex/scheduler.lisp  |    4 +++-
 src/multiplex/time.lisp       |   19 -------------------
 src/multiplex/timers.lisp     |   15 +++++++++++----
 src/multiplex/utils.lisp      |    6 ------
 6 files changed, 34 insertions(+), 45 deletions(-)


An updated tarball of IOLib's source can be downloaded here:
http://common-lisp.net/project/iolib/files/snapshots/iolib-20090131.tar.gz

Gitweb URL:
http://repo.or.cz/w/iolib.git



From luismbo at gmail.com  Mon Feb  2 01:20:15 2009
From: luismbo at gmail.com (Luis Oliveira)
Date: Mon, 02 Feb 2009 01:20:15 +0000
Subject: [iolib-devel] [RELEASE] Version 0.6.0
References: <1233171096.3210.27.camel@localhost.localdomain>
Message-ID: <87fxix63e8.fsf@li14-157.members.linode.com>

Stelian Ionescu <stelian.ionescu-zeus at poste.it> writes:

> 18 months after 0.5.4, I've released 0.6.0: a tarball and its GPG
> signature are available from

Cool. :-)


> My next goals are to finish the new stream library(Zeta-streams) and the
> pathname library.

Any chance we could share pathname goodness with osicat? :-)

Oh, by the way, any news on restoring windows support?

-- 
Lu?s Oliveira
http://student.dei.uc.pt/~lmoliv/




From sionescu at common-lisp.net  Mon Feb  2 05:00:08 2009
From: sionescu at common-lisp.net (Stelian Ionescu)
Date: Mon, 02 Feb 2009 05:00:08 +0000
Subject: [iolib-devel] New patches:  1-Feb-2009
Message-ID: <E1LTqum-0002Y4-B8@common-lisp.net>


commit 9bbf61ca9871228512ed488179fae1ec99eabbb4
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Sun Feb 1 16:49:09 2009 +0100

    %SYS-GETENV: return only the variable's value, not its length.

 src/syscalls/ffi-functions-unix.lisp |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

commit 16d6ee1495d8a02e64ea5b74cf3f352070c96305
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Sun Feb 1 16:08:35 2009 +0100

    Fix %SYS-SETENV.

 src/syscalls/ffi-functions-unix.lisp |   13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)


An updated tarball of IOLib's source can be downloaded here:
http://common-lisp.net/project/iolib/files/snapshots/iolib-20090201.tar.gz

Gitweb URL:
http://repo.or.cz/w/iolib.git



From js at alien8.de  Tue Feb  3 00:47:54 2009
From: js at alien8.de (Julian Stecklina)
Date: Tue, 03 Feb 2009 01:47:54 +0100
Subject: [iolib-devel] Abstract sockets
Message-ID: <87zlh4firp.fsf@tabernacle.localnet>

Hello,

the attached patch fixes abstract sockets for Linux. It least it tries
as it does not work:

strace output from dbus-monitor:
socket(PF_FILE, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_FILE, path=@"/tmp/dbus-RhgMDI9FXg"...}, 23) = 0

strace output from my app using iolib:
socket(PF_FILE, SOCK_STREAM, 0)         = 5
connect(5, {sa_family=AF_FILE, path=@"/tmp/dbus-RhgMDI9FXg"...}, 110) = -1 ECONNREFUSED (Connection refused)

It seems as if connect (and bind) have to be passed "exact" sizes as
addrlen parameter. But what is a good (i.e. portable) way to compute
these? Using (+ 3 (length address)) (counting the address family word,
the zero byte, and the string) would be quite a hack...

Regards,
-- 
Julian Stecklina

Well, take it from an old hand: the only reason it would be easier to
program in C is that you can't easily express complex problems in C,
so you don't. - Erik Naggum (in comp.lang.lisp)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abstract-sockets.patch
Type: text/x-patch
Size: 2473 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20090203/39c96adb/attachment.bin>

From stelian.ionescu-zeus at poste.it  Tue Feb  3 13:43:03 2009
From: stelian.ionescu-zeus at poste.it (Stelian Ionescu)
Date: Tue, 03 Feb 2009 14:43:03 +0100
Subject: [iolib-devel] [RELEASE] Version 0.6.0
In-Reply-To: <87fxix63e8.fsf@li14-157.members.linode.com>
References: <1233171096.3210.27.camel@localhost.localdomain>
	<87fxix63e8.fsf@li14-157.members.linode.com>
Message-ID: <1233668583.30891.3.camel@localhost.localdomain>

On Mon, 2009-02-02 at 01:20 +0000, Luis Oliveira wrote:
> Stelian Ionescu <stelian.ionescu-zeus at poste.it> writes:
> > My next goals are to finish the new stream library(Zeta-streams) and the
> > pathname library.
> 
> Any chance we could share pathname goodness with osicat? :-)

No. A circular dep osicat->iolib->osicat can be resolved in only two
ways: splitting iolib or merging osicat into iolib, which is what I've
done.

> Oh, by the way, any news on restoring windows support?

After this rewrite is done, adding windows support (back) will be very
easy. I might even do it myself.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20090203/60c1278c/attachment.sig>

From stelian.ionescu-zeus at poste.it  Tue Feb  3 14:40:16 2009
From: stelian.ionescu-zeus at poste.it (Stelian Ionescu)
Date: Tue, 03 Feb 2009 15:40:16 +0100
Subject: [iolib-devel] Abstract sockets
In-Reply-To: <87zlh4firp.fsf@tabernacle.localnet>
References: <87zlh4firp.fsf@tabernacle.localnet>
Message-ID: <1233672016.30891.13.camel@localhost.localdomain>

On Tue, 2009-02-03 at 01:47 +0100, Julian Stecklina wrote:
> Hello,
> 
> the attached patch fixes abstract sockets for Linux. It least it tries
> as it does not work:
> 
> strace output from dbus-monitor:
> socket(PF_FILE, SOCK_STREAM, 0)         = 3
> connect(3, {sa_family=AF_FILE, path=@"/tmp/dbus-RhgMDI9FXg"...}, 23) = 0
> 
> strace output from my app using iolib:
> socket(PF_FILE, SOCK_STREAM, 0)         = 5
> connect(5, {sa_family=AF_FILE, path=@"/tmp/dbus-RhgMDI9FXg"...}, 110) = -1 ECONNREFUSED (Connection refused)
> 
> It seems as if connect (and bind) have to be passed "exact" sizes as
> addrlen parameter. But what is a good (i.e. portable) way to compute
> these? Using (+ 3 (length address)) (counting the address family word,
> the zero byte, and the string) would be quite a hack...

the correct way is to sum the offset of sun_path into struct
sockaddr_un(which is not always 2 because BSDs have an additional slot
named sun_len) to the length of the path(counting the initial 
#\Null but not the terminating #\Null), which is what the new function
actual-size-of-sockaddr-un does.

Test:

SOCKETS> (make-socket :address-family :local :remote-filename
(ensure-address "/tmp/dbus-ZIBJH6keOx" :family :local :abstract t))
#<active local stream socket connected to
"/tmp/dbus-ZIBJH6keOx" {D458259}>

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20090203/935a91cd/attachment.sig>

From js at alien8.de  Tue Feb  3 15:03:17 2009
From: js at alien8.de (Julian Stecklina)
Date: Tue, 03 Feb 2009 16:03:17 +0100
Subject: [iolib-devel] Abstract sockets
References: <87zlh4firp.fsf@tabernacle.localnet>
	<1233672016.30891.13.camel@localhost.localdomain>
Message-ID: <87myd3woju.fsf@tabernacle.localnet>

Stelian Ionescu <stelian.ionescu-zeus at poste.it> writes:

> SOCKETS> (make-socket :address-family :local :remote-filename
> (ensure-address "/tmp/dbus-ZIBJH6keOx" :family :local :abstract t))
> #<active local stream socket connected to
> "/tmp/dbus-ZIBJH6keOx" {D458259}>

Thanks!

Regards,
-- 
Julian Stecklina

Well, take it from an old hand: the only reason it would be easier to
program in C is that you can't easily express complex problems in C,
so you don't. - Erik Naggum (in comp.lang.lisp)




From sionescu at common-lisp.net  Wed Feb  4 05:00:04 2009
From: sionescu at common-lisp.net (Stelian Ionescu)
Date: Wed, 04 Feb 2009 05:00:04 +0000
Subject: [iolib-devel] New patches:  3-Feb-2009
Message-ID: <E1LUZro-0005SY-2t@common-lisp.net>


commit 247b5cada28cd6ba3981e686228823c0d25b2983
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Tue Feb 3 15:50:53 2009 +0100

    Add credits.

 CHANGES |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

commit af10342dbf42f9bda025252c94a062e79e97b620
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Tue Feb 3 15:48:27 2009 +0100

    UNIX addresses are now printed as strings. Abstract addresses have a leading #\@

 CHANGES                  |    1 +
 src/sockets/address.lisp |    7 ++++---
 2 files changed, 5 insertions(+), 3 deletions(-)

commit fa2da45427d045f59697cee021b8ae588369a476
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Tue Feb 3 15:38:47 2009 +0100

    Add support for abstract UNIX socket addresses.

 CHANGES                         |    2 ++
 src/sockets/common.lisp         |   32 +++++++++++++++++++++++++-------
 src/sockets/socket-methods.lisp |    8 ++++----
 3 files changed, 31 insertions(+), 11 deletions(-)


An updated tarball of IOLib's source can be downloaded here:
http://common-lisp.net/project/iolib/files/snapshots/iolib-20090203.tar.gz

Gitweb URL:
http://repo.or.cz/w/iolib.git



From mm_lists at pulsar-zone.net  Fri Feb  6 02:31:13 2009
From: mm_lists at pulsar-zone.net (Matthew Mondor)
Date: Thu, 5 Feb 2009 21:31:13 -0500
Subject: [iolib-devel] io.multiplex::timer
Message-ID: <20090205213113.72c49276@hal.xisop>

Probably that the timer type should be exported as well in pkgdcl.lisp
considering that to use exported remove-timer objects of type timer
have to be provided...  Thus, it's useful to define a struct or class
holding an object of type (or timer null) to remove-timer if t later on
(if set to a timer returned by add-timer)?

Also, is there, or was there recently a known bug that prevents
remove-timer from actually disabling a timer?  I have a timer in repeat
mode which appears to be triggered even after it was removed...

Thanks,
-- 
Matt



From mm_lists at pulsar-zone.net  Fri Feb  6 18:09:32 2009
From: mm_lists at pulsar-zone.net (Matthew Mondor)
Date: Fri, 6 Feb 2009 13:09:32 -0500
Subject: [iolib-devel] io.multiplex::timer
In-Reply-To: <20090205213113.72c49276@hal.xisop>
References: <20090205213113.72c49276@hal.xisop>
Message-ID: <20090206130932.2b2c5d4d@hal.xisop>

On Thu, 5 Feb 2009 21:31:13 -0500
Matthew Mondor <mm_lists at pulsar-zone.net> wrote:

> Also, is there, or was there recently a known bug that prevents
> remove-timer from actually disabling a timer?  I have a timer in repeat
> mode which appears to be triggered even after it was removed...

Further testing reveals that timers appear to no longer be triggered
anymore after they have been removed when I switched the code to use
lambda closures to dispatch to CLOS method instead of calling a
function doing said CLOS method dispatch.

Thanks,
-- 
Matt



From luismbo at gmail.com  Fri Feb  6 21:18:12 2009
From: luismbo at gmail.com (Luis Oliveira)
Date: Fri, 06 Feb 2009 21:18:12 +0000
Subject: [iolib-devel] [RELEASE] Version 0.6.0
References: <1233171096.3210.27.camel@localhost.localdomain>
	<87fxix63e8.fsf@li14-157.members.linode.com>
	<1233668583.30891.3.camel@localhost.localdomain>
Message-ID: <87bptf5kob.fsf@li14-157.members.linode.com>

Stelian Ionescu <stelian.ionescu-zeus at poste.it> writes:

>> Any chance we could share pathname goodness with osicat? :-)
>
> No. A circular dep osicat->iolib->osicat can be resolved in only two
> ways: splitting iolib or merging osicat into iolib, which is what I've
> done.

Hmm, in what way does osicat depend on iolib?


-- 
Lu?s Oliveira
http://student.dei.uc.pt/~lmoliv/




From stelian.ionescu-zeus at poste.it  Fri Feb  6 21:23:34 2009
From: stelian.ionescu-zeus at poste.it (Stelian Ionescu)
Date: Fri, 06 Feb 2009 22:23:34 +0100
Subject: [iolib-devel] [RELEASE] Version 0.6.0
In-Reply-To: <87bptf5kob.fsf@li14-157.members.linode.com>
References: <1233171096.3210.27.camel@localhost.localdomain>
	<87fxix63e8.fsf@li14-157.members.linode.com>
	<1233668583.30891.3.camel@localhost.localdomain>
	<87bptf5kob.fsf@li14-157.members.linode.com>
Message-ID: <1233955414.3438.23.camel@localhost.localdomain>

On Fri, 2009-02-06 at 21:18 +0000, Luis Oliveira wrote:
> Stelian Ionescu <stelian.ionescu-zeus at poste.it> writes:
> 
> >> Any chance we could share pathname goodness with osicat? :-)
> >
> > No. A circular dep osicat->iolib->osicat can be resolved in only two
> > ways: splitting iolib or merging osicat into iolib, which is what I've
> > done.
> 
> Hmm, in what way does osicat depend on iolib?

the pathname goodness would be a dep on iolib

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20090206/ef5c5d4c/attachment.sig>

From mail at chaitanyagupta.com  Sat Feb  7 19:18:10 2009
From: mail at chaitanyagupta.com (Chaitanya Gupta)
Date: Sun, 08 Feb 2009 00:48:10 +0530
Subject: [iolib-devel] Bug when using READ-LINE on non-blocking fds
Message-ID: <498DDE72.7030701@chaitanyagupta.com>

Hi,

Iolib behaves in the following way when using READ-LINE with a 
non-blocking fd:

;; *client-stream is the stream associated with a client connected to 
our server

IRCD> *client-stream
#<active IPv6 stream socket connected to ::ffff:127.0.0.1/41460 
{1004D5D451}>

IRCD> (fd-non-blocking *)
T

;; client sends the string "foo" down the socket, no newline is sent

IRCD> (ignore-errors (read-line *client-stream))
NIL
#<System-Error EWOULDBLOCK(11) "Resource temporarily unavailable">

;; client sends the string "bar", followed by a newline

IRCD> (ignore-errors (read-line *client-stream))
"bar"
NIL

So, essentially, the string "foo" is lost. Shouldn't the correct 
behaviour be to wait till a newline arrives on the socket?

Chaitanya



From stelian.ionescu-zeus at poste.it  Sat Feb  7 19:49:36 2009
From: stelian.ionescu-zeus at poste.it (Stelian Ionescu)
Date: Sat, 07 Feb 2009 20:49:36 +0100
Subject: [iolib-devel] Bug when using READ-LINE on non-blocking fds
In-Reply-To: <498DDE72.7030701@chaitanyagupta.com>
References: <498DDE72.7030701@chaitanyagupta.com>
Message-ID: <1234036176.21106.1.camel@localhost.localdomain>

On Sun, 2009-02-08 at 00:48 +0530, Chaitanya Gupta wrote:
> Hi,
> 
> Iolib behaves in the following way when using READ-LINE with a 
> non-blocking fd:
> 
> ;; *client-stream is the stream associated with a client connected to 
> our server
> 
> IRCD> *client-stream
> #<active IPv6 stream socket connected to ::ffff:127.0.0.1/41460 
> {1004D5D451}>
> 
> IRCD> (fd-non-blocking *)
> T
> 
> ;; client sends the string "foo" down the socket, no newline is sent
> 
> IRCD> (ignore-errors (read-line *client-stream))
> NIL
> #<System-Error EWOULDBLOCK(11) "Resource temporarily unavailable">
> 
> ;; client sends the string "bar", followed by a newline
> 
> IRCD> (ignore-errors (read-line *client-stream))
> "bar"
> NIL
> 
> So, essentially, the string "foo" is lost. Shouldn't the correct 
> behaviour be to wait till a newline arrives on the socket?

That's correct. Thanks for the notice, I've just pushed a fix ;)

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20090207/d5b0780c/attachment.sig>

From mail at chaitanyagupta.com  Sat Feb  7 20:29:56 2009
From: mail at chaitanyagupta.com (Chaitanya Gupta)
Date: Sun, 08 Feb 2009 01:59:56 +0530
Subject: [iolib-devel] Bug when using READ-LINE on non-blocking fds
In-Reply-To: <1234036176.21106.1.camel@localhost.localdomain>
References: <498DDE72.7030701@chaitanyagupta.com>
	<1234036176.21106.1.camel@localhost.localdomain>
Message-ID: <498DEF44.2020301@chaitanyagupta.com>

Stelian Ionescu wrote:
> That's correct. Thanks for the notice, I've just pushed a fix ;)
>
>   

Cool! Thanks for the quick fix. I wanted to point out that even 
READ-SEQUENCE had similar problems, but that too seems to have been 
fixed i.e. READ-SEQUENCE now correctly waits till the required amount of 
data has been sent by the client.

On that note, does iolib provide any function to read a chunk of data 
without blocking i.e. something like READ-CHAR-NO-HANG for sequences? 
(or, something akin to what read(2) provides when O_NONBLOCK is set).

Chaitanya




From stelian.ionescu-zeus at poste.it  Sat Feb  7 20:36:32 2009
From: stelian.ionescu-zeus at poste.it (Stelian Ionescu)
Date: Sat, 07 Feb 2009 21:36:32 +0100
Subject: [iolib-devel] Bug when using READ-LINE on non-blocking fds
In-Reply-To: <498DEF44.2020301@chaitanyagupta.com>
References: <498DDE72.7030701@chaitanyagupta.com>
	<1234036176.21106.1.camel@localhost.localdomain>
	<498DEF44.2020301@chaitanyagupta.com>
Message-ID: <1234038992.21106.5.camel@localhost.localdomain>

On Sun, 2009-02-08 at 01:59 +0530, Chaitanya Gupta wrote:
> Stelian Ionescu wrote:
> > That's correct. Thanks for the notice, I've just pushed a fix ;)
> >
> >   
> 
> Cool! Thanks for the quick fix. I wanted to point out that even 
> READ-SEQUENCE had similar problems, but that too seems to have been 
> fixed i.e. READ-SEQUENCE now correctly waits till the required amount of 
> data has been sent by the client.
> 
> On that note, does iolib provide any function to read a chunk of data 
> without blocking i.e. something like READ-CHAR-NO-HANG for sequences? 
> (or, something akin to what read(2) provides when O_NONBLOCK is set).

No. The current iolib streams are gray-streams therefore are
blocking(because CL streams are designed that way). The other stream
layer I'm working on(zeta-streams) should provide that, but it's not
finished yet.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20090207/3ce85013/attachment.sig>

From sionescu at common-lisp.net  Sun Feb  8 05:00:06 2009
From: sionescu at common-lisp.net (Stelian Ionescu)
Date: Sun, 08 Feb 2009 05:00:06 +0000
Subject: [iolib-devel] New patches:  7-Feb-2009
Message-ID: <E1LW1m2-0000a3-5e@common-lisp.net>


commit 6eb6bf1b65a376a9242e7380a18f76c5c542973c
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Sat Feb 7 21:49:39 2009 +0100

    Handle EINTR in %WRITE-OCTETS-FROM-FOREIGN-MEMORY.

 src/streams/gray/gray-stream-methods.lisp |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

commit 5e4d96947ac12c5ea3c6515e591db2e4972ff78e
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Sat Feb 7 21:22:45 2009 +0100

    Style change in %FILL-IBUF.

 src/streams/gray/gray-stream-methods.lisp |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

commit 9a23208f09d15b8fa9f3288048404700bee89fba
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Sat Feb 7 20:47:26 2009 +0100

    Reading from socket streams with non-blocking FDs now works (bug reported by Chaitanya Gupta)

 CHANGES                                   |    2 ++
 src/streams/gray/gray-stream-methods.lisp |   19 +++++++++++++------
 2 files changed, 15 insertions(+), 6 deletions(-)

commit 3af2a2a83195509c3e8d8b5504a436270220a061
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Sat Feb 7 16:24:23 2009 +0100

    Update the README with info about generating docs.

 README |   13 ++++++++++++-
 1 files changed, 12 insertions(+), 1 deletions(-)


An updated tarball of IOLib's source can be downloaded here:
http://common-lisp.net/project/iolib/files/snapshots/iolib-20090207.tar.gz

Gitweb URL:
http://repo.or.cz/w/iolib.git



From mm_lists at pulsar-zone.net  Sun Feb  8 07:16:28 2009
From: mm_lists at pulsar-zone.net (Matthew Mondor)
Date: Sun, 8 Feb 2009 02:16:28 -0500
Subject: [iolib-devel] Bug when using READ-LINE on non-blocking fds
In-Reply-To: <498DEF44.2020301@chaitanyagupta.com>
References: <498DDE72.7030701@chaitanyagupta.com>
	<1234036176.21106.1.camel@localhost.localdomain>
	<498DEF44.2020301@chaitanyagupta.com>
Message-ID: <20090208021628.7927076f@hal.xisop>

On Sun, 08 Feb 2009 01:59:56 +0530
Chaitanya Gupta <mail at chaitanyagupta.com> wrote:

> On that note, does iolib provide any function to read a chunk of data 
> without blocking i.e. something like READ-CHAR-NO-HANG for sequences? 
> (or, something akin to what read(2) provides when O_NONBLOCK is set).

It is possible to use RECEIVE-FROM which would signal
IOLIB.SYSCALLS:EWOULDBLOCK if the socket is non-blocking and no
remaining data is ready to read, or IOLIB.SYSCALLS:EINTR on reception
of a signal, but I'm not sure if this could work with buffering, or if
it would conflict with stream operations (i.e. in C you wouldn't use
stdio fread()/fgets() and read() concurrently).

I've used RECEIVE-FROM without issues when creating sockets with 0
bytes receive and send buffers and using custom buffers.
An example may be found at
http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/mmondor/mmsoftware/cl/lib/rw-queue.lisp?rev=1.5;content-type=text%2Fplain
(Note that READ-LINE-FROM-QUEUE and WRITE-STRING-TO-QUEUE are
SBCL-specific as they use SB-EXT to convert between UTF-8 strings and
8-bit bytes representations).

-- 
Matt



From stelian.ionescu-zeus at poste.it  Sun Feb  8 13:09:08 2009
From: stelian.ionescu-zeus at poste.it (Stelian Ionescu)
Date: Sun, 08 Feb 2009 14:09:08 +0100
Subject: [iolib-devel] Bug when using READ-LINE on non-blocking fds
In-Reply-To: <20090208021628.7927076f@hal.xisop>
References: <498DDE72.7030701@chaitanyagupta.com>
	<1234036176.21106.1.camel@localhost.localdomain>
	<498DEF44.2020301@chaitanyagupta.com>
	<20090208021628.7927076f@hal.xisop>
Message-ID: <1234098548.6196.12.camel@localhost.localdomain>

On Sun, 2009-02-08 at 02:16 -0500, Matthew Mondor wrote:
> On Sun, 08 Feb 2009 01:59:56 +0530
> Chaitanya Gupta <mail at chaitanyagupta.com> wrote:
> 
> > On that note, does iolib provide any function to read a chunk of data 
> > without blocking i.e. something like READ-CHAR-NO-HANG for sequences? 
> > (or, something akin to what read(2) provides when O_NONBLOCK is set).
> 
> It is possible to use RECEIVE-FROM which would signal
> IOLIB.SYSCALLS:EWOULDBLOCK if the socket is non-blocking and no
> remaining data is ready to read, or IOLIB.SYSCALLS:EINTR on reception
> of a signal, but I'm not sure if this could work with buffering, or if
> it would conflict with stream operations (i.e. in C you wouldn't use
> stdio fread()/fgets() and read() concurrently).

It's possible: you can use drain-input-buffer to copy data from the
buffers(it returns two values: the offset of the first element of the
sequence that wasn't overwritten, and the number of octets remaining in
the buffer or NIL if there aren't any left). After that you can use
receive-from. Technically, you can use it at any moment, but since there
may be data left in the stream buffer, you lose ordering of the stream
data)

> I've used RECEIVE-FROM without issues when creating sockets with 0
> bytes receive and send buffers and using custom buffers.

About receive-from, I should probably make it clearer in the
documentation that you must either specify (buffer,start,end) or size:
if you specify size and not buffer, a new array is consed and the data
is copied there.

> An example may be found at
> http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/mmondor/mmsoftware/cl/lib/rw-queue.lisp?rev=1.5;content-type=text%2Fplain
> (Note that READ-LINE-FROM-QUEUE and WRITE-STRING-TO-QUEUE are
> SBCL-specific as they use SB-EXT to convert between UTF-8 strings and
> 8-bit bytes representations).

Since you use iolib, you might as well use babel's o-t-s and s-t-o
functions.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20090208/b58a7eb3/attachment.sig>

From mm_lists at pulsar-zone.net  Sun Feb  8 18:40:17 2009
From: mm_lists at pulsar-zone.net (Matthew Mondor)
Date: Sun, 8 Feb 2009 13:40:17 -0500
Subject: [iolib-devel] Bug when using READ-LINE on non-blocking fds
In-Reply-To: <1234098548.6196.12.camel@localhost.localdomain>
References: <498DDE72.7030701@chaitanyagupta.com>
	<1234036176.21106.1.camel@localhost.localdomain>
	<498DEF44.2020301@chaitanyagupta.com>
	<20090208021628.7927076f@hal.xisop>
	<1234098548.6196.12.camel@localhost.localdomain>
Message-ID: <20090208134017.1d46ab8b@hal.xisop>

On Sun, 08 Feb 2009 14:09:08 +0100
Stelian Ionescu <stelian.ionescu-zeus at poste.it> wrote:

> It's possible: you can use drain-input-buffer to copy data from the
> buffers(it returns two values: the offset of the first element of the
> sequence that wasn't overwritten, and the number of octets remaining in
> the buffer or NIL if there aren't any left). After that you can use
> receive-from. Technically, you can use it at any moment, but since there
> may be data left in the stream buffer, you lose ordering of the stream
> data)

Indeed

> Since you use iolib, you might as well use babel's o-t-s and s-t-o
> functions.

Thanks for the suggestion, I tried it and verified if performance was
affected but it doesn't seem to be (at least not noticeably).
-- 
Matt



From sionescu at common-lisp.net  Mon Feb  9 05:00:07 2009
From: sionescu at common-lisp.net (Stelian Ionescu)
Date: Mon, 09 Feb 2009 05:00:07 +0000
Subject: [iolib-devel] New patches:  8-Feb-2009
Message-ID: <E1LWOFb-0000JC-OD@common-lisp.net>


commit 750592b6449b6b9f887d0cd215300f4317c46cbd
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Sun Feb 8 13:47:44 2009 +0100

    Better subtype IOLIB-ERROR.

 CHANGES                         |    1 +
 src/sockets/dns/conditions.lisp |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

commit 00b9598b8826d17515d65bd2793c75b9423f5e20
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Sun Feb 8 13:40:29 2009 +0100

    Make RESOLVER-ERROR a subtype of ERROR.

 src/sockets/dns/conditions.lisp |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


An updated tarball of IOLib's source can be downloaded here:
http://common-lisp.net/project/iolib/files/snapshots/iolib-20090208.tar.gz

Gitweb URL:
http://repo.or.cz/w/iolib.git



From mm_lists at pulsar-zone.net  Mon Feb 16 23:47:45 2009
From: mm_lists at pulsar-zone.net (Matthew Mondor)
Date: Mon, 16 Feb 2009 18:47:45 -0500
Subject: [iolib-devel] iolib 0.6.0/netbsd/sbcl build failure
Message-ID: <20090216184745.321beefe@hal.xisop>

I decided to upgrade from 20090124 snapshot to 0.6.0 release today, and
noticed the netbsd fixes I proposed were checked in, so tried using it,
yet there would be a "NO-OP" build error of some kind, which wouldn't
occur if I re-evaluated the require form at repl, but then an assertion
failure would occur in SB-C about a SIGNED-32 type.

I looked again at the source and noticed the fix for netbsd wasn't
applied the same as I had applied it on my tree.  I had kept :pointer
for the udata kevent structure rather than :intptr_t.  I thus tried the
same on 0.6.0 and it works fine.

I propose the attached diff.
Thanks,
-- 
Matt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20090216/ace8c500/attachment.txt>

From stelian.ionescu-zeus at poste.it  Tue Feb 17 01:25:31 2009
From: stelian.ionescu-zeus at poste.it (Stelian Ionescu)
Date: Tue, 17 Feb 2009 02:25:31 +0100
Subject: [iolib-devel] iolib 0.6.0/netbsd/sbcl build failure
In-Reply-To: <20090216184745.321beefe@hal.xisop>
References: <20090216184745.321beefe@hal.xisop>
Message-ID: <1234833931.32644.5.camel@localhost.localdomain>

On Mon, 2009-02-16 at 18:47 -0500, Matthew Mondor wrote:
> I decided to upgrade from 20090124 snapshot to 0.6.0 release today, and
> noticed the netbsd fixes I proposed were checked in, so tried using it,
> yet there would be a "NO-OP" build error of some kind, which wouldn't
> occur if I re-evaluated the require form at repl, but then an assertion
> failure would occur in SB-C about a SIGNED-32 type.
> 
> I looked again at the source and noticed the fix for netbsd wasn't
> applied the same as I had applied it on my tree.  I had kept :pointer
> for the udata kevent structure rather than :intptr_t.  I thus tried the
> same on 0.6.0 and it works fine.

Ok, I changed this back. Could you post a backtrace, btw ?

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20090217/a2adde23/attachment.sig>

From sionescu at common-lisp.net  Tue Feb 17 05:00:04 2009
From: sionescu at common-lisp.net (Stelian Ionescu)
Date: Tue, 17 Feb 2009 05:00:04 +0000
Subject: [iolib-devel] New patches: 16-Feb-2009
Message-ID: <E1LZI3w-0005TB-8d@common-lisp.net>


commit 3766d9186c7a444f5fcdb1e4c2039303c0953608
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Tue Feb 17 02:22:36 2009 +0100

    Fix struct kevent groveling on NetBSD.

 src/syscalls/ffi-types-unix.lisp |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)


An updated tarball of IOLib's source can be downloaded here:
http://common-lisp.net/project/iolib/files/snapshots/iolib-20090216.tar.gz

Gitweb URL:
http://repo.or.cz/w/iolib.git



From mm_lists at pulsar-zone.net  Tue Feb 17 06:03:42 2009
From: mm_lists at pulsar-zone.net (Matthew Mondor)
Date: Tue, 17 Feb 2009 01:03:42 -0500
Subject: [iolib-devel] iolib 0.6.0/netbsd/sbcl build failure
In-Reply-To: <20090216184745.321beefe@hal.xisop>
References: <20090216184745.321beefe@hal.xisop>
Message-ID: <20090217010342.67d1e8ac@hal.xisop>

On Mon, 16 Feb 2009 18:47:45 -0500
Matthew Mondor <mm_lists at pulsar-zone.net> wrote:

I also suggest the following diff, since ADD-TIMER returns this type
and it's necessary to store it if we're going to use also exported
REMOVE-TIMER, to which it has to be supplied (attached diff)
-- 
Matt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20090217/478e2695/attachment.txt>

From mm_lists at pulsar-zone.net  Tue Feb 17 06:08:37 2009
From: mm_lists at pulsar-zone.net (Matthew Mondor)
Date: Tue, 17 Feb 2009 01:08:37 -0500
Subject: [iolib-devel] iolib 0.6.0/netbsd/sbcl build failure
In-Reply-To: <20090217010342.67d1e8ac@hal.xisop>
References: <20090216184745.321beefe@hal.xisop>
	<20090217010342.67d1e8ac@hal.xisop>
Message-ID: <20090217010837.43c3fd0a@hal.xisop>

On Tue, 17 Feb 2009 01:03:42 -0500
Matthew Mondor <mm_lists at pulsar-zone.net> wrote:

> I also suggest the following diff, since ADD-TIMER returns this type
> and it's necessary to store it if we're going to use also exported
> REMOVE-TIMER, to which it has to be supplied (attached diff)

Oh, I forgot to diff from the root tree for convenience;  This belongs
into the multiplexer's directory, btw :)
-- 
Matt



From mm_lists at pulsar-zone.net  Tue Feb 17 06:38:31 2009
From: mm_lists at pulsar-zone.net (Matthew Mondor)
Date: Tue, 17 Feb 2009 01:38:31 -0500
Subject: [iolib-devel] iolib 0.6.0/netbsd/sbcl build failure
In-Reply-To: <1234833931.32644.5.camel@localhost.localdomain>
References: <20090216184745.321beefe@hal.xisop>
	<1234833931.32644.5.camel@localhost.localdomain>
Message-ID: <20090217013831.39cae398@hal.xisop>

On Tue, 17 Feb 2009 02:25:31 +0100
Stelian Ionescu <stelian.ionescu-zeus at poste.it> wrote:

> Ok, I changed this back. Could you post a backtrace, btw ?

The problem was fixed by using :pointer, yet here still are backtraces:

First (require 'iolib) (compilation time)

erred while invoking #<COMPILE-OP NIL {61FEAB21}> on                                                                                                                         
#<CL-SOURCE-FILE "backend-kqueue" {6182C771}>
   [Condition of type ASDF:COMPILE-FAILED]

Restarts:
 0: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL {61FEAB21}> on #<ASDF:CL-SOURCE-FILE "backend-kqueue" {6182C771}>.
 1: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {61FEAB21}> on #<ASDF:CL-SOURCE-FILE "backend-kqueue" {6182C771}> as having been successful.
 2: [RETRY] Retry SLIME REPL evaluation request.
 3: [ABORT] Return to SLIME's top level.
 4: [ABORT] Exit debugger, returning to top level.

Backtrace:
  0: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) ..)
      Locals:
        SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-2 = #<ASDF:COMPILE-OP NIL {61FEAB21}>
        SB-DEBUG::ARG-3 = #<ASDF:CL-SOURCE-FILE "backend-kqueue" {6182C771}>
  1: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) ..)
      Locals:
        SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-2 = #<ASDF:COMPILE-OP NIL {61FEAB21}>
        SB-DEBUG::ARG-3 = #<ASDF:CL-SOURCE-FILE "backend-kqueue" {6182C771}>
  2: ((LAMBDA ()))
      [No Locals]
  3: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK))
      [No Locals]
  4: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA #) {61986D5D}>)[:EXTERNAL]
      Locals:
        SB-DEBUG::ARG-0 = 1
        SB-DEBUG::ARG-1 = #<CLOSURE (LAMBDA ()) {61986D5D}>
  5: (ASDF:OPERATE ASDF:LOAD-OP IOLIB)[:EXTERNAL]
      Locals:
        SB-DEBUG::ARG-0 = 2
        SB-DEBUG::ARG-1 = ASDF:LOAD-OP
        SB-DEBUG::ARG-2 = IOLIB
  6: (ASDF::MODULE-PROVIDE-ASDF IOLIB)
      Locals:
        SB-DEBUG::ARG-0 = IOLIB
  7: ((LAMBDA (#:G[REQUIRE]18)) ASDF::MODULE-PROVIDE-ASDF)
      Locals:
        SB-DEBUG::ARG-0 = ASDF::MODULE-PROVIDE-ASDF
  8: (SB-IMPL::%MAP-FOR-EFFECT-ARITY-1 #<CLOSURE (LAMBDA #) {61BF9E65}> (ASDF::MODULE-PROVIDE-ASDF SB-IMPL::MODULE-PROVIDE-CONTRIB))
      Locals:
        SB-DEBUG::ARG-0 = #<CLOSURE (LAMBDA (#:G[REQUIRE]18)) {61BF9E65}>
        SB-DEBUG::ARG-1 = (ASDF::MODULE-PROVIDE-ASDF SB-IMPL::MODULE-PROVIDE-CONTRIB)
  9: (REQUIRE IOLIB NIL)
      Locals:
        SB-IMPL::MODULE-NAME = IOLIB
        SB-IMPL::PATHNAMES = NIL
 10: (SB-INT:SIMPLE-EVAL-IN-LEXENV (REQUIRE 'IOLIB) #<NULL-LEXENV>)
      Locals:
        SB-DEBUG::ARG-0 = (REQUIRE 'IOLIB)
        SB-DEBUG::ARG-1 = #<NULL-LEXENV>
 --more--

Selecting 0 from there will obviously keep failing, but let's say I use
2, it compiles again without error.  Then if trying to use the kqueue
backend:

The value #.(SB-SYS:INT-SAP #X00000000)                                                                                                                                      
is not of type                                                                                                                                                               
  (SIGNED-BYTE 32).
   [Condition of type TYPE-ERROR]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [ABORT] Return to SLIME's top level.
 2: [ABORT] Exit debugger, returning to top level.

Backtrace:
  0: (SB-C::%COMPILE-TIME-TYPE-ERROR (#.(SB-SYS:INT-SAP #X00000000)) (SIGNED-BYTE 32) #<unavailable argument>)
      Locals:
        SB-DEBUG::ARG-0 = (#.(SB-SYS:INT-SAP #X00000000))
        SB-DEBUG::ARG-1 = (SIGNED-BYTE 32)
        SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
  1: (SB-C::%COMPILE-TIME-TYPE-ERROR (#.(SB-SYS:INT-SAP #X00000000)) (SIGNED-BYTE 32) #<unavailable argument>)[:EXTERNAL]
      Locals:
        SB-DEBUG::ARG-0 = 3
        SB-DEBUG::ARG-1 = (#.(SB-SYS:INT-SAP #X00000000))
        SB-DEBUG::ARG-2 = (SIGNED-BYTE 32)
        SB-DEBUG::ARG-3 = :<NOT-AVAILABLE>
  2: (IO.MULTIPLEX::DO-KQUEUE-EVENT-REQUEST ..)
      Locals:
        SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-1 = #S(IO.MULTIPLEX::FD-ENTRY ..)
        SB-DEBUG::ARG-2 = 0
        SB-DEBUG::ARG-3 = 1
  3: ((SB-PCL::FAST-METHOD IO.MULTIPLEX::MONITOR-FD (IO.MULTIPLEX:KQUEUE-MULTIPLEXER T)) ..)
      Locals:
        SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-2 = #<kqueue(2) multiplexer>
        SB-DEBUG::ARG-3 = #S(IO.MULTIPLEX::FD-ENTRY ..)
  4: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) ..)
      Locals:
        SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-2 = #<kqueue(2) multiplexer>
        SB-DEBUG::ARG-3 = #S(IO.MULTIPLEX::FD-ENTRY ..)
  5: ((SB-PCL::FAST-METHOD IO.MULTIPLEX:SET-IO-HANDLER (IO.MULTIPLEX:EVENT-BASE T T T)) ..)[:EXTERNAL]
      Locals:
        SB-DEBUG::ARG-0 = 6
        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-3 = #<event base, 1 FDs monitored, using: #<kqueue(2) multiplexer> {61851919}>
        SB-DEBUG::ARG-4 = 6
        SB-DEBUG::ARG-5 = :READ
        SB-DEBUG::ARG-6 = #<CLOSURE (LAMBDA (MM-SERVER::FD MM-SERVER::EVENT ERROR)) {61D682B5}>
  6: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.ARG2. SB-PCL::.ARG3. SB-INT:&MORE SB-PCL::.DFUN-MORE-CONTEXT. SB-PCL::.DFUN-MO$
      Locals:
        SB-PCL::.ARG0. = #<event base, 1 FDs monitored, using: #<kqueue(2) multiplexer> {61851919}>
        SB-PCL::.ARG1. = 6
        SB-PCL::.ARG2. = :READ
        SB-PCL::.ARG3. = #<CLOSURE (LAMBDA (MM-SERVER::FD MM-SERVER::EVENT ERROR)) {61D682B5}>
        SB-PCL::.DFUN-MORE-CONTEXT. = -288429853
        SB-PCL::.DFUN-MORE-COUNT. = 0
  7: (MM-SERVER::BASE-ADD-LISTENER #<passive IPv6 stream socket waiting @ ::/7777 {61C21D41}>)
  8: (MM-SERVER:SERVER-INIT #<MM-HTTPD::HTTP-CONFIGURATION {617C21F9}>)
  9: (MM-HTTPD:HTTPD-INIT #<MM-HTTPD::HTTP-CONFIGURATION {617C21F9}>)
 10: (MM-HTTPD::HTTPD-TEST-INIT)
-- 
Matt



From sionescu at common-lisp.net  Wed Feb 18 05:00:07 2009
From: sionescu at common-lisp.net (Stelian Ionescu)
Date: Wed, 18 Feb 2009 05:00:07 +0000
Subject: [iolib-devel] New patches: 17-Feb-2009
Message-ID: <E1LZeXX-0008I0-8n@common-lisp.net>


commit 61d0e7cfefa2a688e6c28039cc10303835fdd130
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Tue Feb 17 08:42:36 2009 +0100

    Export TIMER from the MULTIPLEXER package.

 src/multiplex/pkgdcl.lisp |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


An updated tarball of IOLib's source can be downloaded here:
http://common-lisp.net/project/iolib/files/snapshots/iolib-20090217.tar.gz

Gitweb URL:
http://repo.or.cz/w/iolib.git



From mm_lists at pulsar-zone.net  Wed Feb 18 08:16:19 2009
From: mm_lists at pulsar-zone.net (Matthew Mondor)
Date: Wed, 18 Feb 2009 03:16:19 -0500
Subject: [iolib-devel] asd files move to src/
Message-ID: <20090218031619.4b2cdfd6@hal.xisop>

Hi again and thanks for commiting the diffs,

Will official releases still have the asd files at the top level like
other asdf packages?  If not, would it make sense to move those at the
first level but to keep the code under src?

A script adding all the first level package directories to
asdf:*central-registry* can no longer work with iolib >0.6.0 unless it
also locates asd files or unless I "mv src/* ." for instance.

Although this isn't a major problem, I've been wondering as all other
packages I've used have asd files at the first level.  In case it was
your intention to move the asd files only back to the package's root,
here is attached a diff (tested against 20090217's tarball snapshot,
and applied after "mv src/*.asd ." to avoid the diff -N mess for such
minor changes).

Thanks,
-- 
Matt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20090218/0be53561/attachment.txt>

From attila.lendvai at gmail.com  Wed Feb 18 21:06:17 2009
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Wed, 18 Feb 2009 22:06:17 +0100
Subject: [iolib-devel] asd files move to src/
In-Reply-To: <20090218031619.4b2cdfd6@hal.xisop>
References: <20090218031619.4b2cdfd6@hal.xisop>
Message-ID: <b54b34af0902181306m462d4e22pd08202e7a16b4e82@mail.gmail.com>

> Although this isn't a major problem, I've been wondering as all other
> packages I've used have asd files at the first level.  In case it was

that's a me, too here, although this isn't a major problem...

-- 
 attila



From stelian.ionescu-zeus at poste.it  Wed Feb 18 21:38:14 2009
From: stelian.ionescu-zeus at poste.it (Stelian Ionescu)
Date: Wed, 18 Feb 2009 22:38:14 +0100
Subject: [iolib-devel] asd files move to src/
In-Reply-To: <20090218031619.4b2cdfd6@hal.xisop>
References: <20090218031619.4b2cdfd6@hal.xisop>
Message-ID: <1234993094.3826.5.camel@localhost.localdomain>

On Wed, 2009-02-18 at 03:16 -0500, Matthew Mondor wrote:
> Hi again and thanks for commiting the diffs,
> 
> Will official releases still have the asd files at the top level like
> other asdf packages?

Yes - for personal ?esthetic reasons: I want the top directory do be
uncluttered

> A script adding all the first level package directories to
> asdf:*central-registry* can no longer work with iolib >0.6.0 unless it
> also locates asd files or unless I "mv src/* ." for instance.

I don't like very much the use of a script to automatically add
directories to asdf:*central-registry* . In case of your development
machine you're much better off with using a single directory + symlinks,
and in case of automatic deployment I think that keeping an explicit
MANIFEST file containing the path of all enabled .asd files is much
better.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20090218/07e59765/attachment.sig>

From mm_lists at pulsar-zone.net  Wed Feb 18 21:48:28 2009
From: mm_lists at pulsar-zone.net (Matthew Mondor)
Date: Wed, 18 Feb 2009 16:48:28 -0500
Subject: [iolib-devel] the remove-timer issue & redundant multiplexer code
Message-ID: <20090218164828.5ebe8db0@hal.xisop>

The REMOVE-TIMER issue:

People here might remember a previous post of mine suspecting a problem
with timers of the multiplexer.  Well lately with more testing, I've
noticed the issue again, and that this only occurs on restartable
timers which I want to conditionally disable.

After looking at the source, I discovered the obvious reason:  my test
case used REMOVE-TIMER as part of its timeout handler code, while the
time scheduler reschedules/restarts non-:one-shot timers after the
handler callback returns.  It would be possible to modify the scheduler
so that REMOVE-TIMER be callback-safe, but it probably isn't a
requirement, considering that for such cases :one-shot can easily be
used and as wanted the user code could restart the timer anyway if
wanted later on.

Thus it is probably best to simply document this in the API, I simply
made wrong assumptions about the timer scheduler mechanism.



Redundant multiplexer code:

This currently only is at the stage of a pipe-dream (not yet a project)
but I've sometimes been thinking about rewriting the multiplexer so the
main code be more tailored to kqueue, so that redundant sanity checking
code and timer scheduler wouldn't have to be used with that backend, and
other backends could share a library based on the current code for the
scheduler and all the sanity checking.

To explain better about the redundancy overhead:
- Kqueue drops any registered events for an fd at fd close time.
  Thus only timers would have to be unregistered (which can be made via
  a single syscall, or can pend in an array to pass to the next natural
  single syscall of the main scheduler loop).
- Kqueue also allows to use a per-event user-data pointer which can be
  used to efficiently map to internal user objects, eliminating the
  need for custom fd->object (or timerid->object) indexing tables.
  This udata is returned by the framework at both event reception and
  errors (which are simply provided as events).
- Event registration, cancellation and polling are all done in a single
  call to kevent, and kevent can report if an filter was already
  registered or not, precisely, removing the need for userland code
  to maintain redundant tables and related sanity checks.
- kqueue also supports timers (one-shot and restarting ones).
  Restartable timers are atomically restarted so userland doesn't have
  to care.  A timeout callback could use REMOVE-TIMER which would
  simply add an element to the kevent array which'd be passed to the
  next syscall in the main loop.
  Of course if REMOVE-TIMER was declared callback-safe, the userland
  scheduler for less powerful backends would probably also be fixed
  to flag timers in a way for them not to be rescheduled.
  Moving timers to backends which support it would be more efficient
  than the user rolled timer scheduler code.

But then again, I'll use the current iolib multiplexer for now, as long
as it works :)
-- 
Matt



From stelian.ionescu-zeus at poste.it  Thu Feb 19 12:59:28 2009
From: stelian.ionescu-zeus at poste.it (Stelian Ionescu)
Date: Thu, 19 Feb 2009 13:59:28 +0100
Subject: [iolib-devel] OHLOH
Message-ID: <1235048368.3383.3.camel@localhost.localdomain>

I've added IOLib to ohloh.net: https://www.ohloh.net/p/CL-IOLib/

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20090219/240c5281/attachment.sig>

From sionescu at common-lisp.net  Fri Feb 20 05:00:07 2009
From: sionescu at common-lisp.net (Stelian Ionescu)
Date: Fri, 20 Feb 2009 05:00:07 +0000
Subject: [iolib-devel] New patches: 19-Feb-2009
Message-ID: <E1LaNUd-0003KJ-CB@common-lisp.net>


commit 4b74ac7cbc8f7ab0b22514eb74da5ed2aa395f39
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Thu Feb 19 16:56:06 2009 +0100

    Fix use of MAKE-SOCKADDR-UN in SOCKADDR->SOCKADDR-STORAGE.

 src/sockets/address.lisp |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


An updated tarball of IOLib's source can be downloaded here:
http://common-lisp.net/project/iolib/files/snapshots/iolib-20090219.tar.gz

Gitweb URL:
http://repo.or.cz/w/iolib.git



From sionescu at common-lisp.net  Sat Feb 28 05:00:07 2009
From: sionescu at common-lisp.net (Stelian Ionescu)
Date: Sat, 28 Feb 2009 05:00:07 +0000
Subject: [iolib-devel] New patches: 27-Feb-2009
Message-ID: <E1LdHJ1-0006z0-Nm@common-lisp.net>


commit 5d19d0d03863df65460bae54f1c13ed061f7238a
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Fri Feb 27 11:14:45 2009 +0100

    Fix printing of paths.

 src/pathnames/file-path-unix.lisp |   38 +++++++++++++++++-------------------
 src/pathnames/file-path.lisp      |   11 +++++----
 2 files changed, 24 insertions(+), 25 deletions(-)

commit 810caf4f1d56761575774fbb2f4ae7e9015da078
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Fri Feb 27 11:14:18 2009 +0100

    Remove PARSE-FILE-PATH-TYPE.

 src/pathnames/file-path-unix.lisp |    8 +++-----
 src/pathnames/file-path.lisp      |   20 ++++----------------
 2 files changed, 7 insertions(+), 21 deletions(-)

commit cb722bb7a493c14de932b021b6013cc60a269d11
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Fri Feb 27 11:10:27 2009 +0100

    Export FILE-PATH methods and classes.

 src/pathnames/pkgdcl.lisp |   29 ++++++++++++++++++++++++++++-
 1 files changed, 28 insertions(+), 1 deletions(-)

commit e4d402e4b8cdeb5381059710c38102bf0a4c253a
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Fri Feb 27 11:04:03 2009 +0100

    IOLIB.SOCKETS:CONNECT : keyword arg TIMEOUT has been coalesced into WAIT

 CHANGES                         |    1 +
 src/sockets/base-sockets.lisp   |    4 +-
 src/sockets/socket-methods.lisp |   46 ++++++++++++++++++++------------------
 3 files changed, 27 insertions(+), 24 deletions(-)

commit 2f061d87c34ed6a664195d4505c729530eabc53c
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Fri Feb 27 11:02:50 2009 +0100

    IOLIB.SOCKETS:ACCEPT-CONNECTION : keyword arg TIMEOUT has been coalesced into WAIT

 CHANGES                         |    2 ++
 src/sockets/base-sockets.lisp   |    9 +++++----
 src/sockets/socket-methods.lisp |   12 ++++++------
 3 files changed, 13 insertions(+), 10 deletions(-)

commit f6aa4c38911bb78ed9ca1157562bbb40415fc6cc
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Fri Feb 27 10:42:06 2009 +0100

    Add WAIT->TIMEOUT helper.

 src/sockets/common.lisp |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

commit 321f8ec33735e06db2e839c230bede079b516f22
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Fri Feb 27 10:34:33 2009 +0100

    Add types TIMEOUT-DESIGNATOR and POSITIVE-TIMEOUT-DESIGNATOR.

 src/base/pkgdcl.lisp |    1 +
 src/base/time.lisp   |    6 ++++++
 2 files changed, 7 insertions(+), 0 deletions(-)

commit 8adc21d876584aae74b32e2236a2da790c0973dd
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Fri Feb 27 10:33:37 2009 +0100

    Add file-path tests.

 tests/file-paths-unix.lisp |  129 ++++++++++++++++++++++++++++++++++++++++++++
 tests/iolib-tests.asd      |    4 +-
 tests/pkgdcl.lisp          |    2 +-
 3 files changed, 133 insertions(+), 2 deletions(-)

commit 1d7ddd6f1a85ca29b7806dcc4c3d313fd34a7f31
Author: Stelian Ionescu <sionescu at common-lisp.net>
Date:   Fri Feb 27 10:31:50 2009 +0100

    Fix indentation.

 tests/sockets.lisp |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


An updated tarball of IOLib's source can be downloaded here:
http://common-lisp.net/project/iolib/files/snapshots/iolib-20090227.tar.gz

Gitweb URL:
http://repo.or.cz/w/iolib.git



From attila.lendvai at gmail.com  Sat Feb 28 15:13:36 2009
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Sat, 28 Feb 2009 16:13:36 +0100
Subject: [iolib-devel] stuck sockets
Message-ID: <b54b34af0902280713j664d734es6734058fbf66162a@mail.gmail.com>

Stelian, i need your help.

our server went non-responsive and my investigation results in this:

all worker threads were waiting here:

 15: (IOLIB.STREAMS::%FILL-IBUF IOLIB.SOCKETS::SOCKET-READ-FN 15
#S(IOLIB.STREAMS::IOBUF :DATA #.(SB-SYS:INT-SAP #X00658620) :SIZE 4096
:START 0 :END 0))
 16: ((SB-GRAY:STREAM-READ-BYTE
(IOLIB.STREAMS:DUAL-CHANNEL-GRAY-STREAM)) #<active IPv6 stream socket
connected to ::ffff:81.183.137.134/1237 {100F6EEF71}>)

looking at netstat shows that there are exactly as many of these as
stuck threads:

tcp6       0      0 192.168.101.105:8080    81.183.137.134:1249
ESTABLISHED 1004       736341      -
tcp6       0      0 192.168.101.105:8080    81.183.137.134:1265
ESTABLISHED 1004       736356      -
tcp6       0      0 192.168.101.105:8080    81.183.137.134:1261
ESTABLISHED 1004       736352      -
tcp6       0      0 192.168.101.105:8080    81.183.137.134:1237
ESTABLISHED 1004       736329      -
tcp6       0      0 192.168.101.105:8080    81.183.137.134:1281
ESTABLISHED 1004       736999      -
tcp6       0      0 192.168.101.105:8080    81.183.137.134:1257
ESTABLISHED 1004       736348      -
tcp6       0      0 192.168.101.105:8080    81.183.137.134:1273
ESTABLISHED 1004       736363      -
tcp6       0      0 192.168.101.105:8080    81.183.137.134:1242
ESTABLISHED 1004       736336      -
tcp6       0      0 192.168.101.105:8080    81.183.137.134:1253
ESTABLISHED 1004       736344      -
tcp6       0      0 192.168.101.105:8080    81.183.137.134:1269
ESTABLISHED 1004       736360      -

do you think that this remote host is really keeping the connection open?

if so, do you think that it will help if i do this on the socket
returned by accept:

(setf (iolib:socket-option stream-socket :receive-timeout) 5)

thanks in advance,

-- 
 attila