[IPython-dev] Re: Re: Windows fixes, new prompts in CVS, testers?

[Fernando Perez]

Thorsten Kampe wrote:
> * Fernando Perez (2004-06-10 17:54 +0100)
> 
>>Thorsten Kampe wrote:
>>
>>>* Fernando Perez (2004-06-08 08:42 +0100)
>>>The coloured out prompt now works.
>>
>>Thanks for the confirmation.
>>
>>WINDOWS USERS: please note that I'm thinking about making Gary's readline 
>>(which in turn requires ctypes) REQUIREMENTS for ipython.  It makes ipyhton 
>>under windows provide most of the linux functionality, and it finally seems to 
>>work pretty well.
>>
>>If anyone objects, now is the time to say so.
> 
> 
> Gary Bishop's readline (which seems to me the best of the usable
> Windows readline clones) unfortunately makes typing for me on my
> Windows XP machine painfully slow (about one character per second)[1].
> 
> With his readline I can neither use IPython nor plain vanilla Python.

Well, someone objected :)

Ok, I won't make it a requirement then.  I'll try to add in code to enable 
coloring by default if possible, I think I now know how to auto-detect Gary's 
readline for those who have it.  This will only work at the time of creating 
the user's .ipython directory, so those who already have it will need to 
enable coloring manually.

If you ever pin down the origin of this weird keyboard behavior, let us know. 
  Others may have the same problem, and if it's likely to be common I can add 
it to the ipython manual.  Note that since you see the problem with vanilla 
python, at least I'm off the hook on this one :)

For the record, yesterday in my futile attempts at getting a good windows 
installer working, at least I could confirm that with ctypes+gary_readline, 
ipython indeed gives nice out-of-the-box coloring and tab completion for me. 
And I didn't get any of Thorsten's keyboard slugishness problems.

>>>But there is now a problem only with the Windows version (not the
>>>Cygwin):
>>>
>>>WARNING: Couldn't start log: [Errno 17] File exists
>>>Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)]
>>>
>>>This corresponds to these settings in ipythonrc:
>>>log 0
>>>logfile ~/.ipython/ipython.log backup
>>
>>Bummer.  I'll try to borrow again a windows computer to see if I can test 
>>this.  I suspect the problem is the expansion of '~' under Windows.  Please 
>>try to see if you can set this path explicitly, since I suspect that '~' 
>>doesn't expand to anything sensible under Windows.
> 
> 
> Sorry, I was too laconic. This only happens when
> IPYTHONDIR/ipython.log and IPYTHONDIR/ipython.log~ exist( I'm using
> the same directory for the Windows and Cygwin IPython). When I delete
> the files Windows IPython shows no errors and creates those files.
> When both exist IPython errors on the next IPython startup.

well, from Logger.py, here's the code that does this:

         if self.LOGMODE == 'backup':
             if os.path.isfile(self.logfname):
                 os.rename(self.logfname,self.logfname+'~')
             self.logfile = open(self.logfname,'w')

I wonder if os.rename and open() work with different semantics under Windows. 
  If open('foo','w') is called and 'foo' exists, under posix it gets 
overwritten.  It seems that under windows an exception is raised.  Can you 
confirm that?  The joys of writing portable code...

Never mind... From the docs:

rename(  	src, dst)
     Rename the file or directory src to dst. If dst is a directory, OSError 
will be raised. On Unix, if dst exists and is a file, it will be removed 
silently if the user has permission. The operation may fail on some Unix 
flavors if src and dst are on different filesystems. If successful, the 
renaming will be an atomic operation (this is a POSIX requirement). On 
Windows, if dst already exists, OSError will be raised even if it is a file; 
there may be no way to implement an atomic rename when dst names an existing file.

Ok, I'll just enable a workaround for windows. Stupid windows, stupid.

Best,

f