From bhayden at itasoftware.com  Fri Jul  6 14:44:58 2007
From: bhayden at itasoftware.com (Ben Hayden)
Date: Fri, 06 Jul 2007 10:44:58 -0400
Subject: [iolib-devel] bug report: The value :DEFAULT is not of type
	IO.ENCODINGS:EXTERNAL-FORMAT.
In-Reply-To: <468D8C73.2010206@itasoftware.com>
References: <468D8C73.2010206@itasoftware.com>
Message-ID: <468E556A.5050303@itasoftware.com>

Below is a traceback illustrating that the server entry point to 
philip-jose <http://www.cliki.net/philip-jose> fails with the latest 
version of iolib due to a type mismatch. The default external-format, 
:default, is invalid.

* (start-single-threaded-server)

debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" 
{F6266E1}>:
  The value :DEFAULT is not of type IO.ENCODINGS:EXTERNAL-FORMAT.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

((LAMBDA (SB-PCL::VALUE)) :DEFAULT)
source:
; file: /ita/devel/qres/lisp/libs/iolib-0.5.3/sockets/base-sockets.lisp
(SOCKET)
0] backtrace

0: ((LAMBDA (SB-PCL::VALUE)) :DEFAULT)
1: ((LAMBDA (SB-PCL::NEW-VALUE SB-KERNEL:INSTANCE))
    #<unavailable argument>
    #<unavailable argument>)
2: ((SB-PCL::FAST-METHOD SHARED-INITIALIZE
     (SB-PCL::SLOT-OBJECT "#<...>" . "#<...>")) #<error printing object>)
3: ((LAMBDA
        (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL.
         "#<...>" . "#<...>")) #<error printing object>)
4: ((SB-PCL::FAST-METHOD MAKE-INSTANCE (CLASS))
    #<unavailable argument>
    #<unavailable argument>
    #<STANDARD-CLASS NET.SOCKETS:SOCKET-STREAM-INTERNET-PASSIVE>)
5: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. "#<...>" . 
"#<...>"))
    #<unused argument>
    #<unused argument>
    #<STANDARD-CLASS NET.SOCKETS:SOCKET-STREAM-INTERNET-PASSIVE>
    359523896
    4)
6: (NET.SOCKETS:CREATE-SOCKET)
7: (NET.SOCKETS:MAKE-SOCKET)
8: (PHILIP-JOSE::MAKE-TCP-SERVER-SOCKET #<IPv4 address: 0.0.0.0> 6666)
9: (PHILIP-JOSE::MAKE-SERVER #<IPv4 address: 0.0.0.0> 6666)
10: (PHILIP-JOSE:START-SINGLE-THREADED-SERVER)
11: (SB-INT:SIMPLE-EVAL-IN-LEXENV
     (PHILIP-JOSE:START-SINGLE-THREADED-SERVER)
     #<NULL-LEXENV>)
12: (INTERACTIVE-EVAL (PHILIP-JOSE:START-SINGLE-THREADED-SERVER))
13: (SB-IMPL::REPL-FUN NIL)
14: (SB-IMPL::REPL-FUN NIL)
15: ((LAMBDA ()))
16: ((LAMBDA ()))
17: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {F651CC5}>)
18: (SB-IMPL::TOPLEVEL-REPL NIL)
19: (SB-IMPL::TOPLEVEL-INIT)
20: ((LABELS SB-IMPL::RESTART-LISP))





Francois-Rene Rideau wrote:

> can you send a bug report to iolib-devel ?
> And in the meantime, try to use :iso-8859-1 ?
>
> --#f
> A real person has two reasons for doing anything ... a good reason and
> the real reason.
>


From sionescu at common-lisp.net  Fri Jul  6 19:23:27 2007
From: sionescu at common-lisp.net (Stelian Ionescu)
Date: Fri, 6 Jul 2007 21:23:27 +0200
Subject: [iolib-devel] bug report: The value :DEFAULT is not of type
	IO.ENCODINGS:EXTERNAL-FORMAT.
In-Reply-To: <468E556A.5050303@itasoftware.com>
References: <468D8C73.2010206@itasoftware.com>
	<468E556A.5050303@itasoftware.com>
Message-ID: <20070706192327.GA42270@universe.org>

On Fri, Jul 06, 2007 at 10:44:58AM -0400, Ben Hayden wrote:
>Below is a traceback illustrating that the server entry point to 
>philip-jose <http://www.cliki.net/philip-jose> fails with the latest 
>version of iolib due to a type mismatch. The default external-format, 
>:default, is invalid.
this has been fixed in the darcs repo; I'll do a new release this
weekend, but if you're impatient you can download it from here:
http://common-lisp.net/project/iolib/darcs/iolib

btw, when I tried to load philip-jose sbcl HEAD(1.0.7.13) gave me this:

There is no class named PHILIP-JOSE::BINARY-HEAP.
  0: (SB-PCL::FIND-CLASS-FROM-CELL PHILIP-JOSE::BINARY-HEAP NIL T)
  1: ((SB-PCL::FAST-METHOD MAKE-INSTANCE (SYMBOL))
      #<unavailable argument>
      #<unavailable argument>
      PHILIP-JOSE::BINARY-HEAP)
  2: (SB-FASL::FOP-FUNCALL)
  3: (SB-FASL::LOAD-FASL-GROUP
      #<SB-SYS:FD-STREAM for "file /home/hechee/.sbcl/lib/sbcl/philip-jose/local-tasks.fasl" {ACE2C41}>)

perhaps a missing eval-when or an sbcl bug ?

-- 
(sign :name "Stelian Ionescu" :aka "fe[nl]ix"
      :quote "Quidquid latine dictum sit, altum videtur.")
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20070706/2d75dd5a/attachment.sig>

From sionescu at common-lisp.net  Fri Jul 27 23:34:28 2007
From: sionescu at common-lisp.net (Stelian Ionescu)
Date: Sat, 28 Jul 2007 01:34:28 +0200
Subject: [iolib-devel] On iolib-posix, OSICAT and FFI interfaces
Message-ID: <20070727233428.GA1575243@universe.org>

hi, I'd like to ask your advice concerning how to implement a good OS
interface. I and luis are working on the FFI interface to the OS which
is part of IOlib(iolib-posix) and we are a bit undecided over the
approach to take especially regarding how to handle IN/OUT or OUT struct
arguments:

1) return multiple arguments, the first one being the foreign function's
return value(if it's not "void"), the rest being the struct members
unpacked. this has the advantage of being mainly non-consing - except
maybe for large numbers of values - IIRC with stat() I get 14 multiple
values. If I'm not mistaken most implementation stack-allocate multiple
values(perhaps only up to a certain number ?)

2) copy each struct into a structure object or CLOS object(like
sb-posix). this has the disadvantage of consing one or more objects with
each call

3) make two packages: one with an interface very close to C, without
unpacking or consing objects, ie. STAT would need to be passed a foreign
pointer to a "struct stat" and the programmer would use directly CFFI
to retrieve desired data.
the second interface would be a high-level one, lispy in the sense of
having ENVIRONMENT-VARIABLE and (SETF ENVIRONMENT-VARIABLE) instead of
GETENV and SETENV. the function names would be quite different from the
OS names also because we could have something like (SETF FILE-STAT) as
"frontend" for several syscalls such as chown, chmod and utime (example
taken from http://clisp.cons.org/impnotes/syscalls.html).

in all 3 options I imply reporting errors via conditions

the choice I prefer is n? 3, because it allows me to have both a
(mostly) non-consing interface for when I really need speed and a lispy
interface that *most* people would want to use since dealing with a FFI
is most often obnoxious, and yes, I'm a bit obsessed by speed/efficiency :)

among existing libraries, OSICAT seems to be the one closer to what I
prefer and we(luis and I) have been thinking of continuing development
of OSICAT if you agree, abandoning iolib-posix on favour of
something like osicat-posix-ffi and osicat-windows-ffi - the low-level
side of it

suggestions ?

-- 
(sign :name "Stelian Ionescu" :aka "fe[nl]ix"
      :quote "Quidquid latine dictum sit, altum videtur.")
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20070728/967b0154/attachment.sig>

From nikodemus at random-state.net  Sat Jul 28 03:58:05 2007
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Sat, 28 Jul 2007 06:58:05 +0300
Subject: [iolib-devel] Re: On iolib-posix, OSICAT and FFI interfaces
In-Reply-To: <20070727233428.GA1575243@universe.org>
References: <20070727233428.GA1575243@universe.org>
Message-ID: <6bcc356f0707272058h19a218c8qe6c633bce3e79447@mail.gmail.com>

On 7/28/07, Stelian Ionescu <sionescu at common-lisp.net> wrote:

> 1) return multiple arguments, the first one being the foreign function's
> return value(if it's not "void"), the rest being the struct members
> unpacked. this has the advantage of being mainly non-consing - except
> maybe for large numbers of values - IIRC with stat() I get 14 multiple
> values. If I'm not mistaken most implementation stack-allocate multiple
> values(perhaps only up to a certain number ?)

This is good for some things with a sane number of values -- like pipe().
For others like stat() less so. Returning a "handfull" of values tends to
be very fast, yes.

> 2) copy each struct into a structure object or CLOS object(like
> sb-posix). this has the disadvantage of consing one or more objects with
> each call.

Yeah. You forget the possibility of using an optional argument to pass
in a pre-allocated object, though:

 (let ((stat (make-instance 'stat)))
   (loop for f in paths
         do (frob (stat path stat))))

> 3) make two packages: one with an interface very close to C, without
> unpacking or consing objects, ie. STAT would need to be passed a foreign
> pointer to a "struct stat" and the programmer would use directly CFFI
> to retrieve desired data.
> the second interface would be a high-level one, lispy in the sense of
> having ENVIRONMENT-VARIABLE and (SETF ENVIRONMENT-VARIABLE) instead of
> GETENV and SETENV. the function names would be quite different from the
> OS names also because we could have something like (SETF FILE-STAT) as
> "frontend" for several syscalls such as chown, chmod and utime (example
> taken from http://clisp.cons.org/impnotes/syscalls.html).
>
> in all 3 options I imply reporting errors via conditions
>
> the choice I prefer is n? 3, because it allows me to have both a
> (mostly) non-consing interface for when I really need speed and a lispy
> interface that *most* people would want to use since dealing with a FFI
> is most often obnoxious, and yes, I'm a bit obsessed by speed/efficiency :)
>
> among existing libraries, OSICAT seems to be the one closer to what I
> prefer and we(luis and I) have been thinking of continuing development
> of OSICAT if you agree, abandoning iolib-posix on favour of
> something like osicat-posix-ffi and osicat-windows-ffi - the low-level
> side of it

I havent' worked actively on Osicat for a while (which is not to say I've
abandoned it, but rather that I'm very happy to pass out commit bits...),
so my gut feelings are not too well trained here, but...

YES!

 OSICAT: something very much like now, including pathname functions
 like NATIVE-NAMESTRING and PARSE-NATIVE-NAMESTRING. Nice and lispy,
 portable across multiple platforms -- either using interfaces that
 are flexible enough, or staying clear of platform specific hair even
 when it means missing functionality.

 WIN32-SYS & POSIX-SYS: low-level APIs. Should be possible to use
 without thinking about "CFFI", or "Alien", or whatever the FFI layer is.
 As high-level as possible while remaining an accurate mapping and as low-level
 as it needs to be for the needs of accuracy and efficiency.

My 0.02EUR.

Cheers,

 -- Nikodemus