[Openmcl-devel] Windows versions of CCL available for smoke-testing

Thu Oct 9 10:46:38 PDT 2008

So.  It runs for you, then ... Backtrace works!  Errors are signaled !
Something's broken in SET-SOCKET-FD-BLOCKING!

Well, 2 out of 3 are good ...

On Thu, 9 Oct 2008, Barry Perryman wrote:

> Great news.
>
> I briefly tried sockets on XP Pro SP3 at work trying to connect to my local
> web server and got the following:
>
> C:\>wx86cl
> Welcome to Clozure Common Lisp Version 1.2-r11005M  (WindowsX8632)!
> ? (make-socket :remote-host "localhost" :remote-port 80)
>> Error: value 2147772030 is not of the expected type (SIGNED-BYTE 32).
>> While executing: CCL::SET-SOCKET-FD-BLOCKING, in process listener(1).
>> Type :POP to abort, :R for a list of available restarts.
>> Type :? for other options.
> 1 > :b
> *(BC0BA0) : 0 (SET-SOCKET-FD-BLOCKING 3 NIL) 549
> (BC0BD8) : 1 (C_CONNECT 3 #<A Foreign Pointer [stack-allocated] (:* #)
> #xAAFF38
>> 16 [...]) 183
> (BC0C0C) : 2 (%SOCKET-CONNECT 3 #<A Foreign Pointer [stack-allocated] (:*
> #) #x
> AAFF38> 16 [...]) 87
> (BC0C24) : 3 (INET-CONNECT 3 16777343 20480 [...]) 439
> (BC0C44) : 4 (MAKE-TCP-STREAM-SOCKET 3 [...]) 415
> (BC0C78) : 5 (MAKE-TCP-SOCKET [...]) 503
> (BC0CAC) : 6 (MAKE-SOCKET [...]) 695
> (BC0DA0) : 7 (CALL-CHECK-REGS 'MAKE-SOCKET [...]) 247
> (BC0DBC) : 8 (TOPLEVEL-EVAL '(MAKE-SOCKET :REMOTE-HOST "localhost"
> :REMOTE-PORT
> 80) [...]) 759
> (BC0DFC) : 9 (READ-LOOP [...]) 1567
> (BC0F00) : 10 (TOPLEVEL-LOOP) 79
> (BC0F08) : 11 (FUNCALL #'#<(:INTERNAL (TOPLEVEL-FUNCTION
> (CCL::LISP-DEVELOPMENT
> -SYSTEM T)))>) 87
> (BC0F14) : 12 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER-PROCESS)>) 575
> (BC0F60) : 13 (RUN-PROCESS-INITIAL-FORM #<TTY-LISTENER listener(1) [Active]
> #x8
> 8FED06> '(#)) 671
> (BC0FA4) : 14 (FUNCALL #'#<(:INTERNAL CCL::%PROCESS-PRESET-INTERNAL)>
> #<TTY-LIS
> TENER listener(1) [Active] #x88FED06> '(#)) 335
> (BC0FCC) : 15 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION)>)
> 279
> 1 > :q
>> Error: value 2147772030 is not of the expected type (SIGNED-BYTE 32).
>> While executing: CCL::SET-SOCKET-FD-BLOCKING, in process listener(1).
>> Type :POP to abort, :R for a list of available restarts.
>> Type :? for other options.
> 1 > :b
> *(BC0BA8) : 0 (SET-SOCKET-FD-BLOCKING 3 T) 549
> (BC0BE0) : 1 (C_CONNECT 3 #<A Foreign Pointer [stack-allocated] (:* #)
> #xAAFF38
>> 16 [...]) 135
> (BC0C0C) : 2 (%SOCKET-CONNECT 3 #<A Foreign Pointer [stack-allocated] (:*
> #) #x
> AAFF38> 16 [...]) 87
> (BC0C24) : 3 (INET-CONNECT 3 16777343 20480 [...]) 439
> (BC0C44) : 4 (MAKE-TCP-STREAM-SOCKET 3 [...]) 415
> (BC0C78) : 5 (MAKE-TCP-SOCKET [...]) 503
> (BC0CAC) : 6 (MAKE-SOCKET [...]) 695
> (BC0DA0) : 7 (CALL-CHECK-REGS 'MAKE-SOCKET [...]) 247
> (BC0DBC) : 8 (TOPLEVEL-EVAL '(MAKE-SOCKET :REMOTE-HOST "localhost"
> :REMOTE-PORT
> 80) [...]) 759
> (BC0DFC) : 9 (READ-LOOP [...]) 1567
> (BC0F00) : 10 (TOPLEVEL-LOOP) 79
> (BC0F08) : 11 (FUNCALL #'#<(:INTERNAL (TOPLEVEL-FUNCTION
> (CCL::LISP-DEVELOPMENT
> -SYSTEM T)))>) 87
> (BC0F14) : 12 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER-PROCESS)>) 575
> (BC0F60) : 13 (RUN-PROCESS-INITIAL-FORM #<TTY-LISTENER listener(1) [Active]
> #x8
> 8FED06> '(#)) 671
> (BC0FA4) : 14 (FUNCALL #'#<(:INTERNAL CCL::%PROCESS-PRESET-INTERNAL)>
> #<TTY-LIS
> TENER listener(1) [Active] #x88FED06> '(#)) 335
> (BC0FCC) : 15 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION)>)
> 279
> 1 > :q
> ?
>
> Barry
>
> On Thu, Oct 9, 2008 at 3:28 AM, Gary Byers <gb at clozure.com> wrote:
>
>> 32- and 64-bit versions of Clozure CL for Windows are now available in svn:
>>
>> <http://svn.clozure.com/publicsvn/openmcl/trunk/windows>
>>
>> The 64-bit version's been available for a while; the 32-bit version's
>> brand new (and still contains some known runtime bugs, along with all
>> of the unknown ones.)  We only have a few (real or virtual) Windows
>> boxes available, so it'd be helpful if people with (a) interest (b)
>> some time and (c) access to real or virtual Windows boxes could
>> take this for a ride around the block, kick the tires, etc.
>>
>> As of yesterday, the win32 version could compile itself successfully
>> 3 times out of 4 and crashed the 4th time.  The win64 version hasn't
>> had a random unexpected crash in a few months, but AFAIK I've been
>> the only person using it much.  As much as anything, it'd be interesting
>> to see if this general impression (the win32 port is at the outer bounds
>> if usability, the win64 port is generally a lot closer) is confirmed or
>> refuted by other people's experience.
>>
>> Both version should run under XP or Vista (but almost certainly not under
>> anything older than XP.)  XP is several years old now, and XP with a
>> recent "service pack" is somewhat different from earlier version.  Most
>> of the Win32 development's been done under a fairly recent (SP3) version
>> of XP; it'd be interesting to know whether it works on eariler versions.
>>
>> The 64-bit version requires a 64-bit version of Windows (XP64, Vista 64.
>> maybe some server OS versions.)  It's currently the case that the 32-bit
>> version of CCL doesn't run under 64-bit OS releases.  We understand why
>> it doesn't, and hope to remove this restriction ASAP.
>>
>> I don't use SLIME; I honestly don't know whether or not there are socket
>> or other issues that'd prevent SLIME from working.  (If there are, please
>> let us know and we'll try to give priority to fixing them.)
>>
>> Some things that we do know:
>>
>> - Windows has a very different model of file permissions and sharing
>>   than Unix systems do.  On Unix, it's well-defined, meaningful, and
>>   useful to (for instance) delete a file that you have open; Windows
>>   generally doesn't allow that sort of thing.  (One consequence of this
>>   is that calling REBUILD-CCL with any options that'd cause the kernel
>>   to be rebuilt can't work the way things are currently implemented,
>>   since the lisp kernel has been opened by the OS.)  There are other
>>   consequences, some of which can be addressed and improved and some
>>   of which can't: this is a very different OS.
>>
>> - Most Windows functions and utilities that deal with pathnames can
>>   accept either forward or backward slashes as directory separators.
>>   CCL pathname/namestring functions don't (yet) deal with backslashes
>>   or with some other Windows namestring conventions.  (When a Windows
>>   function returns a namestring, any backslashes in that namestring
>>   are converted to forward slashes before lisp pathanme code sees it.)
>>
>> - The lisp kernel is built with the Cygwin tools (www.cygwin.com), though
>>   we don't use any Cygwin libraries.  To build the 32-bit kernel, you'd
>>   need (at least) the 'make', 'gcc', 'm4', 'mingw" and "w32api" packages
>>   and their dependencies; the 64-bit kernel also needs a 64-bit toolchain
>>   available from the mingw-w64 project:
>>
>>   <http://sourceforge.net/projects/mingw-w64/>
>>
>> - We haven't done any work yet on Windows GUI programming (examples,
>>   bridges, ...).  On Win32, there's at least on low-level FFI change
>>   that'll be needed to support this (Win32 functions follow a "pascal-like"
>>   calling sequence, in which the callee pops its arguments off of the
>>   stack before returning.  The way that we do foreign function calls, I
>>   don't think that we care about this, but I'm pretty sure that we
>>   need to extend DEFCALLBACK to meet the caller's expectations.  (Perhaps
>>   we should call that extension DEFPASCAL ...)
>>
>> Andreas Bogk did a lot of early work on the Win64 port, and the Win32
>> version has gotten as far as it has as quickly as it has largely because
>> Matt Emerson's ia32 compiler backend and runtime are as good as they are.
>>
>> Again and especially in the case of the 32-bit port, "as far as it's
>> gotten" is "somewhere around the outer bounds of usability."  You'll
>> likely find that it crashes in mysterious and non-repeatable ways (it's
>> likely still on the wrong side of those outer bounds ...), and at this
>> point the most interesting questions are "does it run at all?" and "if
>> not, what OS version are you using ?".
>>
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>