Windows Support

[steskalja]

Add windows support and maybe port this to c#

[tavianator]

Thanks for making this ticket. Native Windows support may be possible but it's not on the roadmap at this time. You can use TextWorld on Windows right now through WSL or Docker (and similar things).

[TheCrazyT]

To be honest ... porting to to c# will be too much work. I'm currently trying to create a python "wheel" for msys. So far appveyor compiles it (https://ci.appveyor.com/project/TheCrazyT/textworld/builds/23684995).

A test binary can be found here: https://github.com/TheCrazyT/TextWorld/releases

But still need to test it (was not able to test it yet because i need to update my msys wich might take some days - due to bad internet speed)

[MarcCote]

@TheCrazyT have you run the tests (maybe with appveyor)? I'm not sure the third-party dependencies (i.e. git-glulx and Inform7) will work (i.e. TextWorld will fail at runtime).

[TheCrazyT]

After upgrading my msys i sadly noticed that its incompatible. Current package is on appveyor *msys_2_11_1_x86_64.whl, while my msys is 2.11.2 . (of course i could simply rename the package to make it work but i doubt that you are supposed to do that) Will try to update msys on appveyor now.

Also will try to install the package during build and execute the tests there, but might take a while to fix all bugs and missing dependencies in my appveyor script.

Wish me luck.

[TheCrazyT]

Sadly most tests keep failing atm. "lapack_lite.cpython-37m.dll' (0x1000000) is already occupied"

"tw-play" seems to work randomly https://imgur.com/a/pJXMSTD sometimes i get that "lapack_lite"-error followed by a "Resource temporary unavailable".

Edit: Well guess it has to do with the hacky way i'm getting scipy. Wish i could find a valid precompiled binary for that for msys.

Edit again: Nope that problem wents away after "rebaseall -p". Guess its just a msys-problem with DLL's that obtain the same memory region.

Now i just need to figure out why it sometimes can't delete files on tests. I'm getting an error "Device or resource busy: 'auto.inf'" for example. nvm i can blaim mcafee-realtime-scan for blocking that file .. deactivating it on my machine resolved those problems.

Also can't figure out how to really run ALL tests. (atm it just runs 4 of them when using "python3.7.exe -m unittest -v") Using "nose" now seems to execute all 15 tests. The following tests are currenlty failing: test_check_generated_games.test_check_generated_game test_tw-make.test_making_challenge_game test_sample_quests.test_sample_quests test_check_generated_games.test_check_generated_game test_tw-make.test_making_challenge_game test_sample_quests.test_sample_quests (some missing Chrome/Chromium/FireFox Webdriver)

unshure about those CalledProcessError-errors, they do not give alot of info sadly. see bottom of : https://ci.appveyor.com/project/TheCrazyT/textworld/builds/23833032

[TheCrazyT]

Oh well ... figured out there are even more tests:

https://ci.appveyor.com/project/TheCrazyT/textworld/builds/23833466

Some are probably not easy to fix.

Edit: Forgot to copy Actions.i6t, now only 2 errors left: https://ci.appveyor.com/project/TheCrazyT/textworld Sadly its not just about installing chromedriver ...

Edit again: Version 1.1.1.77 should now be without errors on the tests. Just needed to fix paths for the rendering-functions.

[thunanguyen]

Any news on this issues guys? I'd love to use in window

[TheCrazyT]

for python3.7 you could test this: https://github.com/TheCrazyT/TextWorld/releases/tag/1.1.1.77 (just try "python -m pip install textworld-1.1.1-cp37-cp37m-msys_2_11_2_x86_64.whl" after download)

But I am not able to build a new version (that works for 3.8.1) for now, because i'm getting some weird ssl-errors on appveyor during build.

Edit: Sorry, but I guess that won't work anymore. I just forgot to mention that this only works for an old msys-version.

Makes me wonder if i could somehow build it msys independend ... Guess it would be better that way.

[TheCrazyT]

alright created a new version for newest msys (3.0.7, with python 3.7): The "wheel" for pip can be downloaded here: https://github.com/TheCrazyT/TextWorld/releases/tag/1.1.1.127

Took me some time to figure out working versions of numpy,scipy,etc.

The reason i choosed msys was probably because of file access/pipes/symlinks used by the project itself, but i can't remember. Guess i thought it would be the best way to reduce the amount of rewriting of existing code.

Need to figure out a way to build it automatically when a new version of msys is released. (although i think its not possible since you cannot create events for github repositories that do not belong to you)

[thunanguyen]

alright created a new version for newest msys (3.0.7, with python 3.7): The "wheel" for pip can be downloaded here: https://github.com/TheCrazyT/TextWorld/releases/tag/1.1.1.127

Took me some time to figure out working versions of numpy,scipy,etc.

The reason i choosed msys was probably because of file access/pipes/symlinks used by the project itself, but i can't remember. Guess i thought it would be the best way to reduce the amount of rewriting of existing code.

Need to figure out a way to build it automatically when a new version of msys is released. (although i think its not possible since you cannot create events for github repositories that do not belong to you)

Hm, is building with cygwin possible ? I see cygwin in the setup file

[TheCrazyT]

Sadly I'm not able to test. Was using cygwin long time ago ... not shure how up to date it is atm. I prefer msys (well actually msys2 because of 64-bit applications). "MSYS2 is a project started by Alexey Pavlov of the mingw-builds team (who are the official packagers for MinGW-w64 toolchains) as a recent fork of Cygwin which tracks the latest Cygwin closely so that it doesn't end up out of date. Alexey forward ported the old MSYS patches and added some of his own." According to a stackoverflow comment.

So chances are high that you could build it for cygwin.

Edit:

Just noticed that I'm using "pacman" alot of times in my repository. Cygwin won't know that command, so i guess it won't work without modifications. (cygwin has no package manager out of the box, only a gui package manager if i remember well.)

[TheCrazyT]

Just created a version for cygwin("textworld-1.1.1-cp37-cp37m-cygwin_3_1_2_x86_64.whl"), let me know if it works:

https://github.com/TheCrazyT/TextWorld/releases/tag/1.1.1.192

[MarcCote]

Thanks @TheCrazyT for doing this. That's really great.

I just want to highlight that the current version of TextWorld is 1.2, and 1.3 will be released soon (coming weeks).

[TheCrazyT]

@MarcCote looks like jericho would need better windows support on newest version,too. Currently TextWorld 1.2 would be buildable ... but the tests fail at "CDLL(None).dlclose" (you already wrote inside the jericho.py that this won't work on windows). Another problem would be "libfrotz.so" i guess.

My try to build, but with tests failing: https://ci.appveyor.com/project/TheCrazyT/textworld/build/job/1o3wkblx03tl8auj

[thunanguyen]

@MarcCote looks like jericho would need better windows support on newest version,too. Currently TextWorld 1.2 would be buildable ... but the tests fail at "CDLL(None).dlclose" (you already wrote inside the jericho.py that this won't work on windows). Another problem would be "libfrotz.so" i guess.

My try to build, but with tests failing: https://ci.appveyor.com/project/TheCrazyT/textworld/build/job/1o3wkblx03tl8auj

best workaround for me is folowing:

frotz_handle = self.frotz_lib._handle
del self.frotz_lib
ctypes.windll.kernel32.FreeLibrary(frotz_handle)

get it from this link : https://stackoverflow.com/questions/359498/how-can-i-unload-a-dll-using-ctypes-in-python

works for some test, some test it spills out tons of memory issues, can you try and tell what happens

[MarcCote]

@TheCrazyT good point about Jericho not supporting Windows. In theory, you don't have to use Jericho with TextWorld (only git-glulx is fine). I have to look at how to do it, but there might be a way to make some of the tests optional, i.e. if OS == windows, skip the test.

@thunanguyen thanks for finding this, that might be a quick fix to have Jericho better support Windows.

EDIT: https://docs.python.org/3/library/unittest.html#skipping-tests-and-expected-failures