On Apr 25, 4:43 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> Is it even possible to create a pseudo-tty interface to a cygwin program > from the MSVC compiled version of Python? The pexpect website > says: "Pexpect does not currently work on the standard Windows Python > (see the pty requirement); however, it seems to work fine using > Cygwin. It is possible to build something like a pty for Windows, but > it would have to use a different technique that I am still > investigating. I know it's possible because Libes' Expect was ported > to Windows. If you have any ideas or skills to contribute in this area > then I would really appreciate some tips on how to approach this > problem." Ok, this is a problem. But there is a module called altpty (see http://cheeseshop.python.org/pypi/altpty/1.0/ ) which might be useful if it is possible to use it as a "drop in replacement" for the pty interface used in pexpect. It should work under windows, but the build system is automake based. Still, it should be easy to write an nmake file for MSVC because we need to compile 4 C files. I am no expert on python, so feel free to correct me. Another possible tactic might be to compile a certain subset of external programs like mwrank with MSVC (provided that its dependencies can also be build with MSVC) and use that via cygwin's path, i.e. /cygdrive/c/sage-2.5.0/local/bin/mwrank.exe. There was something similar discussed a while ago when somebody had problems invoking Maple under cygwin. This is mostly spitballing at the moment, but one has to start somewhere and cygwin does have some rather unpleasant surprises - a while back on another project I ran into lots of problems with threads and sockets :(. > Such a user would likely get actually better overall performance with > VMware (which > supports 64-bit computing) and Linux running in it than with any sort > of native windows > solution. On performance I am rather sceptical. The current penalty for virtulisation with hardware VT is about 30-40%. That will become less of an issue in the future as the implementation will get more efficient. The MSVC 2005 compiler also produces code nearly on par with Intel's C & C++ for SPECXX, so it is certainly more efficient than gcc/g++. You will also be surprised how quick Microsoft's C++ compiler is compared to g++ and the Intel c++. Most people only remember VS 6, which was a real piece of shit (pardon my french). I am no Microsoft fanboy by any mean, but using MSVC 2005/g++/Intel C++/Sun Forte C++ and IBM's XL on a weekly basis (and some of them daily) for regression and build testing for CoCoALib I can only state: MSVC 2005 is quite pleasant to use and very close to the standard, compiles very quickly and produces fast executables. Development on Windows is just different compared to Linux/Unix and MacOSX. That MS Windows is not 100% POSIX compatible is a sad thing, I am getting OT here, so I will shut up now. VMWare and friends still leave the problem with networking and configuration in general and if you want to do the "heavy lifting" chances are you will be using non-Windows anyway :). But the fact that the "threadlist_ix -1" issues or the test failures with Maxima for sage 2.4.2 hasn't been reported until recently means that there are either few cygwin users of sage or that people don't complain about bugs. It would be nice to see how many sage users there are and which operations systems they use. > The other option for windows is to push much harder the idea of > a VMware "virtual machine" for SAGE, which fortunately isn't so bad of an idea > since at least vmware player is free. I agree. > And I think windows users can't complain > about running SAGE via a closed source virtualizer, given that they are > running > everything via a closed-source operating system. My impression though is > that > for certain types of work cygwin is best and for others vmware is, so one > should > support both. > Something else worth investigating ist SFU, i.e Services for Unix from Microsoft. It contains a gcc toolchain, gnu utils and some other bits and pieces needed to compile unixy code without changes. The problem is that last time I looked the redistribution of the needed runtime bits was unclear and it also requires a passport account to get. In addition it isn't exactly small, either. > William Cheers, Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
