As you might know we're currently fixing all kinds of bugs until the release and this time we even fix the unit tests under windows.
This hasn't been a high priority for us but taking the new cdash-server (thanks Alex!) for kdelibs Christian started to submit some first reports for it. I will follow tonight hopefully and I hope more people will follow, especially on the "other platforms" ;-).
Next I fixed some tests in Marble here on windows and now they run fine at least here. I think I can go over to writing more tests and improving marble even more.
One of the bad things that happened to me is a bug in either subversion or putty: I generated a new ssh key with puttygen and asked sysadmin@ to change it. But commandline subversion doesn't want to use this key now and I am not sure what I am doing wrong. The special problem is that both logging in with putty to svn.kde.org and checkout with TortoiseSVN (with the new key) work. The problem about the key seems to be an irregular length of 2047 vs. 2048 Bits. But probably the only way to solve this issue is to ask sysadmins to change the key again.
The last thing is that slowly but steadily amarok on windows comes back: Pau (pgquiles) is currently investing quite some efforts on it and I hope for the best and for neverending success!
Sunday, June 29, 2008
Friday, June 27, 2008
Python: subprocesses after all
Back in September 2007 I was sitting with dipesh until late in the night on a very interesting problem:
We wanted to implement a "tee"-like class in python which would work as the same command under unix: get input via one stream, double the input and give it out into a file and into a stream (like sys.stdout). This shouldn't be a big problem but when you try to give this class to subprocess.Popen as one of the streams you will find out that Popen doesn't use the write function but instead uses the fileno() function of the fileobject. But there would be a workaround for that:
We use subprocess.PIPE for the wanted input stream, then we check regularly for any stuff within the pipe - that this will not work on windows one could expect.
The problem is that all available read processes will block execution if not enough bytes can be read.
The solution is called pywin32 and is a python package for windows. Mark Hammond from starship has made them and they include a function called PeekNamedPipe which does exactly what we need: peek into the pipe without blocking it. I should leave the rest as a homework to the reader, but for those who don't want to invest any more research, I'll give a first solution from where you can start (look at the class Popen).
We wanted to implement a "tee"-like class in python which would work as the same command under unix: get input via one stream, double the input and give it out into a file and into a stream (like sys.stdout). This shouldn't be a big problem but when you try to give this class to subprocess.Popen as one of the streams you will find out that Popen doesn't use the write function but instead uses the fileno() function of the fileobject. But there would be a workaround for that:
We use subprocess.PIPE for the wanted input stream, then we check regularly for any stuff within the pipe - that this will not work on windows one could expect.
The problem is that all available read processes will block execution if not enough bytes can be read.
The solution is called pywin32 and is a python package for windows. Mark Hammond from starship has made them and they include a function called PeekNamedPipe which does exactly what we need: peek into the pipe without blocking it. I should leave the rest as a homework to the reader, but for those who don't want to invest any more research, I'll give a first solution from where you can start (look at the class Popen).
Subscribe to:
Posts (Atom)
Posts
