[Sbcl-devel] Before I submit patches

[<fa...@gm...>]

Hello, I have a patch to sb-bsd-sockets almost ready (it needs more testing=
)
to support UDP, and several other pet things I want to change in SBCL.
I suppose I should send patches on this list. However, not being familiar
with SBCL development, there are a few things I'd like to clarify:

* To allow for some degree of efficiency, I've replaced the very inefficien=
t
 "loop to copy the buffer element by element, converting each element betwe=
en
 whatever type and (unsigned-byte 8)" by a (hopefully) much more efficient
 "use a (simple-array (unsigned-byte 8) (*)) directly as a buffer inside
 with-pinned-objects, do no conversion unless necessary, and use replace
 for other integer arrays". That code, which is much like CFFI proposes
 should be standardized, obviously doesn't belong to
     sb-bsd-sockets/sockets.lisp
 Can you tell me where it belongs to?

* Oh, and what do you think of the interface?
 (deftype iobuffer () '(simple-array (unsigned-byte 8) (*))
   "buffer for direct I/O")
 (defun iobufferp (x) "check if X is a proper iobuffer" ...)
 (defun iobuffer-to-data (buffer data &optional length)
   "copy contents of iobuffer to data array" ...)
 (defun data-to-iobuffer (data buffer &optional length)
   "copy contents of data array to iobuffer" ...)
 (defun ensure-iobuffer-from-data (data &optional length)
   "if data is not an iobuffer already, create a new one with similar conte=
nts"
   ...)
 (defun prepare-iobuffer-for-data (data &optional length)
   "if data is not an iobuffer already, create a new one with same length"
   ...)
 (defun commit-iobuffer-to-data (buffer data &optional length)
   "if data is not an iobuffer already, replace its contents with
those of given buffer" ...)
 (defmacro with-iobuffer ((buffer data &key (direction :input) length)
&body body)
   "bind buffer with an iobuffer suitable for I/O of given direction,
to be committed to/from the contents of data array data" ...)
 Should I add a :start argument for the data?
 Have :start and :end instead of :start and :length?

* Speaking of asynchronous signals, with-pinned-object better be unaffected
 by them, or else we are in big trouble.

* I have minor gripes against the interfaces of SB-BSD-SOCKETS.
 For instance, I feel flags handling is too high-level already,
 when we instead need a low-level wrapper library.

* Speaking of making slight incompatible changes to SB-BSD-SOCKETS,
 what about making it use CFFI and becoming CL-BSD-SOCKETS,
 or even a part of something CL-POSIX, together with a lot of SB-POSIX?
 We could externalize a lot of maintenance this way, although there would
 remain a slight problem of source synchronization between various provider=
s.
 Actually, if we do things right, we could share a lot of code with other
 free software CLs by making it depend on CL-POSIX, and just focusing on
 the compiler technology itself.

* One problem that SBCL has is that it tries to do all filesystem operation=
s
 with BASE-STRING, which is only 7-bit when SB-UNICODE is defined.
 This sucks big stinky ass. I really think SBCL should provide 8-bit chars
 and 8-bit strings, be they BASE-CHAR or another CHAR type, unless it sever=
ely
 rehowls its filesystem code.
=09touch "Far=E9" ; sbcl --eval '(write (directory "Far*")) (terpri)'
 It would also be mighty cool to have some magic to magically convert betwe=
en
 (simple-array (unsigned-byte 8) (*)) and (simple-array 8bit-char (*)).

* And, whoa, look how even a seemingly simple OPEN will do call directory,
 which itself will call truename! That's heavyweight stuff for a simple
 operation. And it makes my previous bug report about the brokenness of
 truename all the more pressing.

* I'm willing to fix the probe-file/truename problem, if no one else cares.
 It involves doing a proper directory-truename before to do any path
 simplifications. Directory-truename itself requires a getcwd for a relativ=
e
 path, and assessing that each step of an absolute path is symlink-resolved
 (which is painful). And it should throw an exception if too many symlinks
 are followed (if possible with the same limit as the kernel -- but is this
 limit exported anywhere? portably?)

* For the #P"" problem, I propose we copy whatever rtoy is doing for CMUCL.

* Finally, while hacking sbcl, I was bitten several times by the fact that
 SBCL begins writing a FASL immediately, and doesn't cleanup if it has to
 abort while detecting an error in the file. What it should do instead is
 writing any fasl data to a temporary file .fasl-tmp, and atomically mv'ing
 the temporary file to the new file when successful only. Should a compilat=
ion
 with warnings be considered successful? You tell me. What to do if the
 temporary file already exists? Issue a continuable error, where compilatio=
n
 might be aborted (some other process is trying to compile the file already=
),
 or continued (said other process died long ago). Detection of the other
 process might be found automatically from the fasl data, but that won't
 work if the process is on another machine, and that's subject to race
 condition. Atomic file operations are a headache in any unix system.
 What do you propose? Oh, and such a mechanism should be available to
 everyone, not just to the file compiler. WITH-ATOMIC-FILE-CREATION ?

Enough ranting, back to coding.

[ Fran=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.tu=
nes.org ]
The college idealists who fill the ranks of the environmental movement seem
willing to do absolutely anything to save the biosphere, except take scienc=
e
courses and learn something about it. -- P.J. O'Rourke