I've begun re-reading the book Accelerando by Charles Stross. The first half is pretty mind-boggling and fascinating and definitely worth a read if you're into software development, sci-fi and wonder where humanity is going. The latter half falters a bit as the story is trying to wrap itself up, but if you only manage the first part I hope you'll still found it worthwhile.
It resonates well with Ray Kurzweil's talk on TED.com, which I've just watched. Even though the video is old news (being from 2005 and released in 2006) I feel it needs to be spread a bit more. I guess we're not at the point where everyone knows everything new within a few weeks, but I wager that the time for spreading news is shrinking in the same way as everything else. :)
If you haven't heard about universal exponential growth or the singularity: watch the talk and, if you fell intrigued, read the book. Period.
Tuesday, December 16, 2008
Sunday, December 14, 2008
Mercurial and python 2.6! :)
This is a follow up on my previous post 'Distributed Version Control Systems on Windows' where I just want to note that I've made some progress with Mercurial by using Python 2.6 instead of 2.5.2.
The good thing is that Python 2.6 uses MSVS 2008, which I do have available. So with that, I can use setuptools to compile python libs. Including Mercurial!
Compiling and install Mercurial into my Python 2.6 64-bit installation was dead easy, by the books all the way! Yay!
That will probably help with running buildbot/mercurial/trac on a pure windows-based server (as in no cygwin). But I'm considering using a linux box for this anyway, since it's smoother and more easy to add misc minor stuff to. (Not disregarding setting up ssh-accounts for mercurial users, which is what I've done currently.)
I'm currently using it to try to assist the Mercurial situation on BuildBot, which is lacking a bit, especially when it comes to in-repo branches. There are patches on the buildbot trac, but they haven't been applied and the crucial one won't be added until it gets a proper test-case.
So, I'm working on that. There's some issue with line-endings preventing try-patches to apply cleanly in the tests. (It works in real life, as I did use the try-functionality at my last job. Never got it ready for every developer though...)
The good thing is that Python 2.6 uses MSVS 2008, which I do have available. So with that, I can use setuptools to compile python libs. Including Mercurial!
Compiling and install Mercurial into my Python 2.6 64-bit installation was dead easy, by the books all the way! Yay!
That will probably help with running buildbot/mercurial/trac on a pure windows-based server (as in no cygwin). But I'm considering using a linux box for this anyway, since it's smoother and more easy to add misc minor stuff to. (Not disregarding setting up ssh-accounts for mercurial users, which is what I've done currently.)
I'm currently using it to try to assist the Mercurial situation on BuildBot, which is lacking a bit, especially when it comes to in-repo branches. There are patches on the buildbot trac, but they haven't been applied and the crucial one won't be added until it gets a proper test-case.
So, I'm working on that. There's some issue with line-endings preventing try-patches to apply cleanly in the tests. (It works in real life, as I did use the try-functionality at my last job. Never got it ready for every developer though...)
Saturday, December 13, 2008
patch.exe on vista - part 2
I've updated my previous post on getting patch.exe to work on Vista with UAC.
Short version: msysgit has a patch.exe that convinces Vista it doens't need to be omnipotent.
Updated 2010-11-26: There is also a comment on my SourceForge bug regarding unxutils's patch.exe. The suggested fix works well.
Short version: msysgit has a patch.exe that convinces Vista it doens't need to be omnipotent.
Updated 2010-11-26: There is also a comment on my SourceForge bug regarding unxutils's patch.exe. The suggested fix works well.
Thursday, November 27, 2008
Monday, November 24, 2008
Python - list clearing?!!
Today's trick question: How do you clear a list in python?
Not by .clear(), as you do with other python containers set or dicts (or _any_ in C++/Java/whatnot).
Nonono, you assign the entire slice of the list to the empty list, or delete the whole slice!
mylist[:] = []
del mylist[:]
.. .. .. .. Arrghh!!!!
Why do I have to learn the slice syntax, and the fact that there is a slice of the whole pie, and that I can assign a list to a slice, just to clear the list?!
Appending, concatenating and clearing are simple & common ops, that should be represented clearly and simply. Slicing is advanced, and when I want to do slicing, I read up on it, but I should need it for that. It's like requiring someone to learn discrete integration just to do addition; valid but only correct in the very bad technically-correct kind of way.
(And no, just assigning the empty list to it does not work, as that rebinds the name, it does not change the original list. I have no issue with that, as it's all pointers/references everywhere.)
Apparently, they haven't fixed this in Py3k either.
Looking through forums where this appear every month since Python was first created, the sentiment seems to be that since you can do it with slicing, there's no need for another way to do it!
I began to understand why people feel that the python community is regarded as a bit 'frosty' and cold.
I still like python a lot, but ... Bah!
Not by .clear(), as you do with other python containers set or dicts (or _any_ in C++/Java/whatnot).
Nonono, you assign the entire slice of the list to the empty list, or delete the whole slice!
mylist[:] = []
del mylist[:]
.. .. .. .. Arrghh!!!!
Why do I have to learn the slice syntax, and the fact that there is a slice of the whole pie, and that I can assign a list to a slice, just to clear the list?!
Appending, concatenating and clearing are simple & common ops, that should be represented clearly and simply. Slicing is advanced, and when I want to do slicing, I read up on it, but I should need it for that. It's like requiring someone to learn discrete integration just to do addition; valid but only correct in the very bad technically-correct kind of way.
(And no, just assigning the empty list to it does not work, as that rebinds the name, it does not change the original list. I have no issue with that, as it's all pointers/references everywhere.)
Apparently, they haven't fixed this in Py3k either.
Looking through forums where this appear every month since Python was first created, the sentiment seems to be that since you can do it with slicing, there's no need for another way to do it!
I began to understand why people feel that the python community is regarded as a bit 'frosty' and cold.
I still like python a lot, but ... Bah!
patch.exe on vista - the workaround
Vista apparently thinks that any exe with 'patch' in it's name needs to be run with admin priviliges, probably to make a slew of pre-UAC install wizard patches work properly.
But this applies to good old unix:y 'patch' (which I have in windows-form) too!
Argh!
Update 2008-12-13: The patch.exe in the git-for-windows distribution (msysgit) seems to have the correct magic bits set to allow it to run without UAC getting in the way. So, try replacing your gnuwin32-patch (or whatever you're using) with that.
If that's not an option, here's how to do a workaround:
The trick is to rename patch.exe to pootch.exe (or whatever fancies you) and create a batch file call patch.cmd, with this content:
@"%~dp0\pootch" %*
That makes it work.
(I learn this when running the unit tests of buildbot, a pretty nice tool for distributing automated tests across compilers, computers & os:es!)
But this applies to good old unix:y 'patch' (which I have in windows-form) too!
Argh!
Update 2008-12-13: The patch.exe in the git-for-windows distribution (msysgit) seems to have the correct magic bits set to allow it to run without UAC getting in the way. So, try replacing your gnuwin32-patch (or whatever you're using) with that.
If that's not an option, here's how to do a workaround:
The trick is to rename patch.exe to pootch.exe (or whatever fancies you) and create a batch file call patch.cmd, with this content:
@"%~dp0\pootch" %*
That makes it work.
(I learn this when running the unit tests of buildbot, a pretty nice tool for distributing automated tests across compilers, computers & os:es!)
Monday, November 17, 2008
No Clutter For You
.. at least not with Python bindings. They use autoconf/automake, and didn't compile well on cygwin either, so I've given up.
QT has some animation options. Maybe those will do instead. :)
QT has some animation options. Maybe those will do instead. :)
Subscribe to:
Posts
(
Atom
)