Using pygr in Windows (XP or VISTA)

[GoogleCodeExporter]

(2) path joining problem: all path joining by '/' should be replaced with 
os.path.join function.

(3) my.cnf and my.ini: Linux uses my.cnf but windows uses my.ini for 
default MySQL connection (actually not default because we have to give 
that path in MySQLdb.connect). But, MySQLdb module may not work correctly 
because it does not recognize spaces in Windows Path! You may need to save 
the my.ini in C:\ or other directory without spaces in Path. e.g. Don't 
save that file in C:\Document and Settings\myaccount\ or something.

(4) Port opening: It is easy to open port in linux, but windows may think 
that is an illegal attempt for hacking. Thus, windows does not allow any 
port opening. You may have to do something in your firewall settings. I 
tried several ways but every time I did, cmd shell just crashed.

(5) 32-bit, 64-bit: we may need to build several binaries for each 
platforms.

(6) FAT32 vs. NTFS: FAT32 does not support large files. We have to use 
NTFS for building/accessing NLMSAs if it is large. Oh! my USB drives... it 
uses FAT32...

(7) Windows memory: Usually, windows machines do not have larger memory 
than linux. We have to reduce memory requirement if you want to build 
NLMSAs. There are two parameters you need to change. Check forum site for 
more details. Remember that windows does not control user priority like 
linux, 1-99, it just has 6 levels (Windows VISTA) or 3 levels (Windows XP 
or earler). Windows may use up all your CPU resources (like frozen) when 
you are building NLMSAs.

(8) Python versions: There would be no universal binaries (.pyd) for 
windows. We may have to make several windows binary distribution files 
depending on python versions. Now, we have twice many combinations due to 
32-bit and 64-bit.

(9) Windows version. It looks like windows library changed. XP vs. VISTA.

Original issue reported on code.google.com by deepr...@gmail.com on 13 May 2008 at 11:36

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

more comments from istvan:

2) easy to fix
3) can't comment because I don't run mysql locally but sounds like a
configuration issue
4) no fix needed, comes from firewall settings
5) and 8) yes, multiple binaries will be needed, I guess we should
build what we can
6) and 7) these are not issues but observations relative to Windows

There are still a few failures due to file handlers not being closed
(and thus remain non-removable in Windows). The rmtree calls maybe
should print warnings rather than raising exceptions for now, until we
track down why each happens.

re # 4, another comment:

4) I think we need to test whether Windows correctly open and close a
specific port. Mac closes a port if there are too many requests on that
specific port. And response time is slower than linux. IMO, assuming that
Windows has a *extremely* huge kernel to make a unified framework for all
platform, there would be some devices which could affect accessing ports. I
haven't tested that in Windows.

Original comment by the.good...@gmail.com on 22 Aug 2008 at 1:05

[GoogleCodeExporter]

should be part of 0.8's improved platform support.

Original comment by cjlee...@gmail.com on 11 Sep 2008 at 4:13

• Added labels: Milestone-Release0.8

[GoogleCodeExporter]

Original comment by the.good...@gmail.com on 17 Dec 2008 at 2:15

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Istvan has found issues with running the test suite under Windows, see this 
thread 
on pygr-dev: http://groups.google.com/group/pygr-dev/t/855a0087d00fbabe . He's 
working on addressing them right now and expects to be done by the end of the 
week, 
will add an exact list of remaining problems (if any) afterwards.

Original comment by mare...@gmail.com on 7 Jan 2009 at 8:18

[GoogleCodeExporter]

Original comment by mare...@gmail.com on 19 Feb 2009 at 1:59

• Changed state: Accepted

[GoogleCodeExporter]

Some of the Windows related issues are addressed in

http://code.google.com/p/pygr/issues/detail?id=2 (Verified)
http://code.google.com/p/pygr/issues/detail?id=60 (Verified)
http://code.google.com/p/pygr/issues/detail?id=67 (Ongoing)

Original comment by istvan.a...@gmail.com on 19 Feb 2009 at 2:06

[GoogleCodeExporter]

Original comment by mare...@gmail.com on 21 Feb 2009 at 1:28

• Changed state: Assigned

[GoogleCodeExporter]

There are a few paths specified in setup.py which contain hardcoded slashes as 
separators, thus causing build errors, at least with MinGW32 (haven't tried 
with 
Visual Studio), under Windows without Cygwin. Attached you will find a patch 
which 
makes these paths use os.path.join() instead.

Original comment by mare...@gmail.com on 7 Apr 2009 at 9:36

Attachments:

• 0001-Use-os.path.join-in-paths-passed-to-the-compiler-t.patch

[GoogleCodeExporter]

In general we seem to be done here, with Pygr tests succeeding under both 
native 
Windows environment and (problems with passing Unix-style paths to Win32 
binaries of 
BLAST aside, which aren't an issue with Pygr itself) Cygwin. However, in order 
to 
have this comprehensively reviewed we need Windows buildbots.

Original comment by mare...@gmail.com on 5 Jun 2009 at 1:11

• Changed state: FixedNeedsReview

[GoogleCodeExporter]

Windows buildbots have been taking their sweet time so Chris and I have decided 
to 
remove the block and simply confirm others can run all tests successfully under 
Windows. Chintan was supposed to do this but he hasn't managed to get MySQL to 
install correctly under Vista yet, so I had Qi (Chris's former Ph.D. student) 
test 
this for us instead. The result - no tests failed and no tests skipped under 
both 
32- and 64-bit Windows XP.

Closing the issue.

Original comment by mare...@gmail.com on 13 Jul 2009 at 5:41

• Changed state: Closed
• Added labels: reviewby-marecki