Re: Making new ports.

[Dale P. Smith]

Gary Houston wrote:
> Since the apache port type is presumably based on a file descriptor,
> it's likely that various facilities in Guile would not interact
> with it correctly: they are hard-coded for the FPORT type.
> 
> E.g., (fileno p) isn't going to work on the Apache port.
> 
> Likewise, the scsh-inspired primitives like fdes->ports and
> primitive-move->fdes won't work as intended once Apache ports are
> created.
> 
> This also applies to other types of ports that people may want to
> add, so it's a deficiency in the Guile port interfaces and not a
> problem which can be easily fixed in the Apache port type.

Yeah, (fileno p) won't work.  But other port types don't work either:

guile> (call-with-output-string (lambda (p) (fileno p)))

Backtrace:
0* [call-with-output-string #<procedure (p)>]
1* [#<procedure (p)> #<output: string 80c6528>]
2* [fileno #<output: string 80c6528>]

ERROR: In procedure fileno in expression (fileno p):
ERROR: Wrong type argument in position 1 (expecting OPFPORTP): #<output:
string 80c6528>
ABORT: (wrong-type-arg)

The same is true for void ports.

There should be some kind of interface for adding/managing buffers.  I
didn't think the apache port needed it because the ap_rwrite call and
friends are doing their own buffering, counting bytes and sending things
out in chunks (or something like that).  How often is there a need for a
new port type?  File/socket/string ports are probably all most people
need.  In fact, I was initially using with-output-to-string and then
sending the string with ap_rwrite.

-Dale
-- 
Dale P. Smith
Altus Technologies Corp.
address@hidden
400-746-9000 x309