[plt-dev] MzScheme port on Windows x86_64: a report.

Here are the results on a machine with internet connection (to prevent 
the previous error):

Section(basic)
Section(unicode)
Section(rx)
Section(reading)
Section(readtable)
Section(macro)
Section(syntax)
Section(procs)
Section(stx)
Section(module)
Section(numbers)
Section(unsafe)
Section(object)
Section(struct)
Section(unit)
Section(unit/sig)
Section(threads)
Section(logger)
Section(synchronization)
Section(deep)
Section(continuation-marks)
Section(prompt)
Section(wills)
Section(namespaces)


Performed 66975 expression tests (59047 value expressions, 7928 exn 
expressions) and 17898 exception field tests.

Errors were:
(Section (got expected (call)))
((namespaces) (#f #t (names #f)))
(Other messages report successful tests of error-handling behavior.)

Section(modprot)
ERROR: UNKNOWN::291: read (compiled): ill-formed code 
[..\..\mzscheme\src\read.c:5522]

=> This is good, but something seems to be problematic with reading 
compiled code. Is it because the JIT is deactivated?


Gabriel Cuvillier a écrit :
> 
> 
> Here are the result output of the tests for MzScheme win64 with quiet.ss:
> 
> Section(basic)
> Section(unicode)
> Section(rx)
> Section(reading)
> Section(readtable)
> Section(macro)
> Section(syntax)
> Section(procs)
> Section(stx)
> Section(module)
> Section(numbers)
> Section(unsafe)
> Section(object)
> Section(struct)
> Section(unit)
> ERROR: tcp-addresses: could not get local address (Unknown error; 
> errno=10014)
> 
> But the problem is the same with the 32 bits version, so it is not a 
> porting problem. I'm running Windows Vista x64, without internet access 
> (only local network).
> 
> Anyway I have run the 'all.ss for both 32 and 64 bits. A quick view on 
> the files shows that the results seems good so far...
> 
> Gabriel Cuvillier a écrit :
>> Ok thanks, I will run the test tomorrow to see if everything is ok.
>>
>> Since I'm new in contributing to open source projects, I'm not quite 
>> sure about how to send my modifications: shall I use 'diff tools and 
>> send the '.patch by mail, right?
>>
>> Matthew Flatt wrote:
>>> I'm impressed that you got it working, and I'd appreciate patches for
>>> what you have so far.
>>>
>>> To test, run
>>>
>>>   plt/collects/tests/mzscheme/quiet.ss
>>>
>>>
>>> Yes, the JIT problem is surely LP64 vs. LLP64; the JIT generates 64-bit
>>> operations for data structures that contain `long's. I think we'll
>>> eventually have to change most `long's in the MzScheme code to some new
>>> type that maps to `__int64' under Windows and `long' elsewhere.
>>>
>>> The plan for MrEd is still to get rid of the current C++ code and
>>> replace it with a new set of bindings that are implemented through the
>>> FFI. The new bindings are implemented in a way that avoids the setjmp
>>> problem. I hope to have that mostly working by March or so, but it's
>>> difficult to predict.
>>>
>>>
>>> At Mon, 11 Jan 2010 17:27:14 +0100, Gabriel Cuvillier wrote:
>>>  
>>>> Hi everyone!
>>>>
>>>> I managed to port MzScheme (CGC variant) to x86_64 on Win64 using 
>>>> Visual Studio 2005.
>>>>
>>>> I have done this port because I want to embed a Scheme 
>>>> implementation into a large C++ 32/64 bits app on windows, and 
>>>> MzScheme seems to be the ONLY implementation which is both 
>>>> MSVC-compilable and SWIG-available! (No, I don't want to use Python :)
>>>>
>>>> It is in "alpha" version, but it compiles and runs successfully on 
>>>> my machine. The major restriction is that there is no JIT.. I wasn't 
>>>> able to figure out why the JIT is crashing, but I suspect 
>>>> compatibility problems with the LLP64 architecture of MSVC compilers 
>>>> (instead of LP64 used with GCC compilers).
>>>>
>>>> The main modifications are:
>>>>
>>>> -> sconfig.h: new target for WIN64 (MSC & _WIN64). Same as WIN32 but:
>>>>     Disable the JIT
>>>>     Disable the INT64_AS_LONG_LONG
>>>>     Disable USE_MZ_SETJMP (and remove contents in the mzsj86.c). 
>>>> Apparently it could cause problems with MrEd in the future, but 
>>>> seems to be ok for MzScheme.
>>>>
>>>> -> Update libffi to the latest version. The main problem is with the 
>>>> libffi version used which is not supporting win64. The latest one 
>>>> does, and it seems to work for other projects (I think the JRuby 
>>>> team use it). After a few headaches with the Microsoft Assembler, as 
>>>> well as obscure defines, I finally managed to make it work.
>>>>
>>>> -> Plus a minor hacks around...
>>>>
>>>> With these actions, MzScheme compiles and runs. I still need to make 
>>>> a lot more tests (is there any unit tests available?). There is more 
>>>> work remaining to be done:
>>>>
>>>> -> Lots of warning because of conversion between "size_t" to "long" 
>>>> (LLP64 vs LP64). Should not cause too much problems for now since 
>>>> sizes are not easily above 2GB...
>>>> -> Some warning because of conversion between "__int64" to "long" 
>>>> (LLP64 vs LP64 as always). They are more dangerous I think.
>>>> -> Make the JIT working.
>>>>
>>>> After that, it should be possible to continue the port with MrEd 
>>>> (and wxWidgets)...
>>>>
>>>> If someone have some hints about the JIT stuff, or general infos 
>>>> about the best way to handle LLP64 vs LP64 (should I pass everything 
>>>> from "long" to "long long"?), help is welcome...
>>>>
>>>> PS: apologies for my english spelling.
>>>>     
>>>
>>>
>>>   
>>
>>
> 
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>