iolib-devel July 2007

iolib-devel@common-lisp.net

3 participants
2 discussions

[iolib-devel] On iolib-posix, OSICAT and FFI interfaces
by Stelian Ionescu 10 Aug '07

10 Aug '07

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.")

4 8

[iolib-devel] bug report: The value :DEFAULT is not of type IO.ENCODINGS:EXTERNAL-FORMAT.
by Ben Hayden 06 Jul '07

06 Jul '07

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. >

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

iolib-devel July 2007