-added workaround to clrmod.c for mono error: "Symbol not found: _environ" (a fix has been added to Mono SVN, according to Geoff Norton at Novell.)
-changed ordering of mono_config_parse(NULL) call in pynetinit.c, to handle latest changes to mono embedding interface (a fix has been added to Mono SVN, according to Geoff Norton.)
-fixed TypeManager static constructor to properly handle .NET exceptions (thanks to Geoff Norton.)
-added to pynetinit.c to make clr.so search the site-packages folder of the currently running python to find the Python.Runtime.dll, instead of just the cwd (thanks to Peter Shinners and Wei Qiao at Blizzard Entertainment.)
-updated one of the Python.Runtime.dll.config to map to .dylib instead of .so (thanks to Wei Qiao.) This should be looked at further, as there are a few of these files floating around...
-changed the Makefile to be self-contained and create the clr.so (thanks to Wei Qiao.) This should be looked at further, as running setup.py currently builds the clr.so, but gives an error afterwards.
-updated README.txt a bit more.
foo = bar.GetValue[str](int arg1, int arg2, str arg3)
...but I did NOT implement a fix for using the __overloads__ syntax. It is still broken (I'm not quite clear on when it is ever even necessary.)
2. Added unit tests for the above.
3. Added some text to the monoclr README.txt to describe how to compile the clr.so that is needed for MacOS X -- I still haven't been able to get everything working myself, so I'm not 100% on it, but the file was blank before, so I figure something is better that nothing.)
clrmodule.il:
- Rewrote entirely to be more human readable/writable. Heavily commented with C# equivalents. Added #ifdef'd debug prints.
- Supports loading out of PYTHONPATH (based on idea by Maksim Kozyarchuk). Default behavior is the same, and only falls back to PYTHONPATH if Python.Runtime can't be found. Note that the ".assembly extern Python.Runtime" block is removed now, as we're no longer binding to it at compile time.
- If/when Python.Runtime.dll gets a solid version and/or strong name, clrmodule can be set to bind more closely with that build by using the USE_PYTHON_RUNTIME_VERSION and USE_PYTHON_RUNTIME_PUBLIC_KEY_TOKEN defines. See comments for details.
- Updated mscorlib reference to 2.0 (required for 64-bit compat).
- Removed ".corflags 0x00000002" (Not compatible with 64 bit version, and no longer needed for 32 bit version when using ilasm v2).
Other files:
- And added "runtime\x86\clrmodule-platform.il" and "runtime\x64\clrmodule-platform.il" subdirectories. 32/64 bit specific IL code is in there, and included into "runtime\clrmodule.il". Clunky, but since ilasm doesn't support command-line #defines, I think this is the best to be done to get the machine-specific stuff out of clrmodule.il.
- Deleted oldmodule.il (seems to be left over drit that was basically the same as clrmodule.il anyway, casing notwithstanding).
- Added an x64 platform target for the solution and Python.Runtime project. The platform is passed into the newly added buildclrmodule.bat, which builds the appropriate clr.pyd.
- Removed Console.csproj.user, and put its Debug build StartArguments into Console.csproj, so it's no longer necessary to keep the .user file around in source control.
- All projects are responsible for copying only their specific output (i.e. console no longer delets/builds/copies clr.pyd). Project dependencies should make sure things work still.
Added code for Python 2.3 (not officially supported)
Changed clr.preload to clr.setPreload() and clr.getPreload(). I know that setters and getters are old school but even Python doesn't support module properties :(
Some fixes and enhancements for the Makefile under Windows and for make dist
Fixed PyObject_TYPE for Py_DEBUG builds
Fixed an issue with implicit calls of generic methods
Renamed solution file to pythonnet.sln. It's not Python 2.5 specific
Enhanced make dist. It builds a signed assemblies for 2.4 and 2.5 for both UCS 2 and 4 with GPG keys, md5 and sha256 sum