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
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
