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

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.
>>>     
>>
>>
>>   
> 
>