Recent changes to feature-requests

#15 Follow Cygwin and MinGW naming convention and build import libraries

2012-12-18T17:13:03Z

Here comes a seemingly working patch.
One concern may be that the command producing cygecl.dll also produces the import library libecl.dll.a.
Moreover it does not copy cygecl.dll in lib but only in bin.
And you have to run autoconf in src directory to update configure.

I've not changed the MinGW SHAREPREFIX to lib in aclocal.m4 as the links given above would suggest, but that might be a nive thing to do.

Follow Cygwin and MinGW naming convention and build import libraries

2012-12-03T22:25:36Z

Following Cygwin and MinGW convention would have some nice consequences: - people used to them would find the libraries more easily, - they would now what the liner will pick up first by default. On cygwin this means having: - the shared library as cygecl-.dll in bin dir, - the static library as libecl.a in bin dir See http://cygwin.com/cygwin-ug-net/dll.html#dll-build If libtool is used it also generate a libecl.la file in lib dir. On MinGW its the same except the shared library has prefix lib as well. Building import library could be useful if someone wants to link with a different linker. (This file is not needed to link from Cygwin to a dll created by Cygwin, same for MinGW.) For the Sage project it would also have the nice effect of ensuring that the import library (and so the shared one) is picked up by default before the static one. There are two possibilities for doing so: - modify the main compilation command line but that would create two files by one command which can be unexcpected, - create it after the shared library has been with dlltool but that's a little more overkill. RedHat has very nice and complete about this stuff as well: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html

#14 Improve the error hierarchy for C errors in ECL (or supply errno)

2012-11-28T14:47:53Z

- Description has changed: Diff: ~~~~ --- old +++ new @@ -1,3 +1,5 @@ +From here: http://permalink.gmane.org/gmane.lisp.ecl.general/9466 + This reminded me of another similar case that puzzled me some time ago when I began using ECL, and that one was handled in the line reader. LINE-READ still had a case to remap a simple-error to an @@ -23,3 +25,5 @@ system will have to export errno. There's always libIO+CFFI, and perhaps eventually my ressuciated ecl-unix on top of mmffi (no time-line on that though, it's only a hobby :) + +Matthew Mondor ~~~~

Improve the error hierarchy for C errors in ECL (or supply errno)

2012-11-28T14:37:04Z

This reminded me of another similar case that puzzled me some time ago when I began using ECL, and that one was handled in the line reader. LINE-READ still had a case to remap a simple-error to an sb-bsd-sockets:operation-timeout-error. This condition happens when an input timeout is set via setsockopt(2) and the input timeout elapses (read(2) then errors with EAGAIN). This is another case where I now see SI::SIMPLE-STREAM-ERRORs reported instead (the catch for SIMPLE-ERROR (a parent/superclass I assume) still matches, but I just changed it to catch STREAM-ERROR instead as well). Unfortunately there's still no way to differenciate a timeout error (EAGAIN) from a broken pipe one (EPIPE) when using STREAM-ERROR. However, because of the design of the system (in HTTP we first read a request then answer, so it's not highly bidirectional, and blocking mode is used with threads in this case to allow CPU-bound applications, so EAGAIN/EWOULDBLOCK will not occur for output). As a result, EPIPE will only occur for output (treated like end-of-file) and EAGAIN for input (treated like input timeout), so in this case the problem is solved for now. If I need advanced unblocking I/O and polling in the future, I'm unlikely to rely on the native sb-compatible sockets support, and that system will have to export errno. There's always libIO+CFFI, and perhaps eventually my ressuciated ecl-unix on top of mmffi (no time-line on that though, it's only a hobby :)

Improve the error hierarchy for C errors in ECL (or supply errno)

2012-11-28T14:37:04Z

Ticket 14 has been modified: Improve the error hierarchy for C errors in ECL (or supply errno) Edited By: Juan Jose Garcia Ripoll (jjgarcia) Description updated: --- description-old +++ description-new @@ -1,3 +1,5 @@ +From here: http://permalink.gmane.org/gmane.lisp.ecl.general/9466 + This reminded me of another similar case that puzzled me some time ago when I began using ECL, and that one was handled in the line reader. LINE-READ still had a case to remap a simple-error to an @@ -23,4 +25,5 @@ system will have to export errno. There's always libIO+CFFI, and perhaps eventually my ressuciated ecl-unix on top of mmffi (no time-line on that though, it's only a hobby :) - + +Matthew Mondor

#13 EXT:RUN-PROGRAM with input/output strings

2012-08-24T22:28:57Z

It seems that it also affects to ECL integration with Slime. E.g.: CL-USER> (ext:run-program "cat" '("/proc/interrupts")) It fails showing this error: :ERROR argument to RUN-PROGRAM does not have a file handle: # [Condition of type SIMPLE-ERROR]

2012-08-24T12:14:31Z

2012-07-25T18:43:16Z