⇤ ← Revision 1 as of 2008-04-17 09:36:50
1644
Comment:
|
1725
|
Deletions are marked like this. | Additions are marked like this. |
Line 6: | Line 6: |
02:25 < mabshoff> Well, I guess we should get the Cygwin port going again ASAP. |
pexpect?
We discussed this to death and came up with:
02:25 < mabshoff> Well, I guess we should get the Cygwin port going again ASAP. 02:25 < wstein> I think that's the best conclusion from this discussion. 02:25 < wstein> But the options are: 02:25 < gfurnish|away> +1 02:25 < wstein> (1) Steal code from Qt. 02:25 < wstein> (2) Hack printf's 02:26 < wstein> (3) Hack dll's 02:26 < wstein> (4) Cygwin+Python+pexpect acting as an xlmrpc server. 02:26 < wstein> (5) virtual machine -- VETO -- it is too big and requires a network :-( 02:27 < mabshoff> (5) can be used as a porting tool 02:27 < wstein> Anything else that I forgot? 02:27 < wstein> Yes. 02:27 < mabshoff> (6) expect? 02:27 < wstein> Yes. 02:27 < mabshoff> (7) SFU 02:27 < wstein> I like (4) a lot as an intermediae. 02:27 < mabshoff> (8) Vista POSIX subsystem 02:27 < wstein> Because what is behind 4 could easily change. 02:28 < mabshoff> on the other side of the XMLRPC? 02:28 < wstein> Yes. 02:28 < mabshoff> Sure 02:28 < wstein> It could be anything. 02:28 < wstein> It just has to provide a function to call a given subprocess with an input, and return 02:29 < wstein> the output. 02:29 < wstein> It could use pexpect+python for some, it could use (2) for some, it could use (1) for some, etc. 02:29 < mabshoff> sure 02:29 < wstein> And to do this would involve some rewriting of devel/sage/sage/interfaces/* 02:29 < wstein> Maybe. 02:29 < wstein> It might be good. 02:29 < mabshoff> yep 02:30 < wstein> The main thing is to not slow down anything we have right now (e.g., calculus). 02:30 < mabshoff> I think the pexpect situation is something we should concentrate on for the Windows portion of Dev1