iolib-devel

iolib-devel@common-lisp.net

246 discussions

[iolib-devel] Some docs available
by Stelian Ionescu 14 Apr '08

14 Apr '08

I've uploaded some preliminary docs at http://common-lisp.net/project/iolib/manual. It's not much for the moment, basically only the docstrings extracted to texinfo, but I'll be adding more this week. Anybody needs something specific ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.

1 0

[iolib-devel] cffi-grovel:grovel-file
by elliott 07 Apr '08

07 Apr '08

Hello. Just checking out the library and trying to load on sbcl 1.0.15.36. I noticed that the net.socket.asd file calls CFFI-GROVEL:GROVEL-FILE, which is undefined by the cffi-grovel system provided by the cffi-net darcs repo. Is cffi-net the correct source of iolib's cffi-grovel dependency? elliott

3 4

[iolib-devel] Passing FDs over UNIX sockets
by Stelian Ionescu 06 Apr '08

06 Apr '08

I've recently added a few new functions to net.sockets: MAKE-SOCKET-FROM-FD, MAKE-SOCKET-PAIR and the pair SEND-FILE-DESCRIPTOR/RECEIVE-FILE-DESCRIPTOR for passing FDs over UNIX sockets. I've done a few tests and while OSX can pass FDs either over stream sockets or datagram sockets, on Linux only datagram sockets seem to work. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.

1 0

[iolib-devel] make-instance on non-constants
by Attila Lendvai 01 Mar '08

01 Mar '08

hi, while reading through the code i've seen several uses of MAKE-INSTANCE that is not called on a constant class. this is much slower on sbcl than the other way. (just like apply #'make-instance) make-foo generics with specializations on the types and/or some case statements make instantiation a lot faster. -- attila

1 0

[iolib-devel] Status of IOLib
by Kai Oliver Kaminski 03 Dec '07

03 Dec '07

Hi, I'm interested in using IOLib for network programming and was wondering what its status is. It doesn't currently work on my system (Ubuntu 7.10, SBCL 1.0.12, 64bit) for a variety of reasons. I could probably fix some of these things but first I'd like to know wheter IOLib is still alive, what the current plans are and which version of it is supposed to work. I tried the current darcs stuff with the development version of CFFI. I'd also like to understand the relationship to osicat, which was mentioned on the mailing list. Cheers, Kai

2 1

[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

[iolib-devel] test
by Stelian Ionescu 12 Jun '07

12 Jun '07

test -- (sign :name "Stelian Ionescu" :aka "fe[nl]ix" :quote "Quidquid latine dictum sit, altum videtur.")

1 0

[iolib-devel] #+lispworks missing in iolib/io.streams/pkgdcl.lisp
by binghe.lisp＠gmail.com 09 Jun '07

09 Jun '07

Hi, IOLib The line 31 of iolib/io.streams/pkgdcl.lisp miss a "lispworks" feature. This caused io.streams package cannot import symbols from lispworks' stream package, and cause a error when I use net.smtp-client: Error: The class #<STANDARD-CLASS IO.STREAMS:DUAL-CHANNEL-GRAY-STREAM 40D0347A5B> cannot be finalized because the following superclass is not defined: #<FORWARD-REFERENCED-CLASS IO.STREAMS:FUNDAMENTAL-BINARY-INPUT-STREAM 40D03479CB>. 1 (abort) Return to level 0. 2 Return to top loop level 0. Type :b for backtrace, :c <option number> to proceed, or :? for other options A trivial patch may fix this. --8<---------------cut here---------------start------------->8--- --- pkgdcl.lisp.orig 2007-06-08 02:12:43.910573918 +0800 +++ pkgdcl.lisp 2007-06-08 02:01:45.817445668 +0800 @@ -28,7 +28,7 @@ `(defpackage :io.streams (:use #:common-lisp #:cffi #:iolib-utils #:io.encodings) - #+(or sbcl cmu openmcl clisp allegro) + #+(or sbcl cmu openmcl clisp allegro lispworks) (:import-from #+sbcl #:sb-gray #+cmu #:ext #+openmcl #:ccl --8<---------------cut here---------------end--------------->8--- -- '()

2 4

[iolib-devel] (gcc-cpu-flags) in asdf-additions/unix-dso.lisp
by Chun Tian 07 Jun '07

07 Jun '07

Hi, iolib developers I'm not sure why need a (gcc-cpu-flags) function to detect a gcc compile flag (-m32/-m64) and use this to compile C files. First, use (cffi:foreign-type-size :int) to guess is wrong at least on amd64 Linux: (cffi:foreign-type-size :int) return 4 on amd64 Linux, so you guess wrong to 32-bit. Second, if you guess wrong, a 64-bit Lisp process will can not load a 32-bit library. If I disable this (gcc-cpu-flags), gcc with no -m32/-m64 can always do the right thing on both 32 and 64-bit platform, and the Lisp process can load this library. (I'm just doing this on Debian GNU/Linux amd64 and LispWorks 5.0.2 Enterprise Edition for AMD64 Linux.) Am I right? Thanks. Chun Tian (binghe)

4 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

iolib-devel