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

[Alexander Repenning]

Hi Gary,

this is exciting news. In our case we really would like the Mac32/64 +  
Win32/64 Lisps but our tire kicking activity would be to try to get  
OpenGL and QuickTime to work on Windows. Sounds like the win32 version  
may be still to shaky for this kind of stress test? Is there a plan to  
have SLIME work with win32 and will there be a precompiled .exe  
version of ccl/win32? Is there already or will there be a mechanism  
similar to the trap mechanism on Mac for OS X calls to parse header  
files to turn them automagically into defcallbacks (or whatever they  
will be called)?

Alex


On Oct 8, 2008, at 8:28 PM, Gary Byers 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
>

Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20081009/4843d5ea/attachment.htm>