Estimated read time: 1 minutes
Estimated read time: 1 minutes
One item in Python's magic word is that you don't have to really care about memory management. I already know if i want to "strdup" a list, then i need foo[:], but I did not notice that in case I iterate over a list _and_ modify it, then I need such a trick as well.
Example
l = ['a', 'b'] for i in l: l.remove(i) print l
So we remove each item from the list (an expensive version of "l = []").
However, the result will be "['b']". Now if you use "for i in l[:]:", everything will be fine, because you can iterate over the original list.
It's a shame that I do python for more than 2 years, and I did not know such a basic stuff. :(
Estimated read time: 3 minutes
I spent some time today to prepare some rpm packages for an RHEL4 box, it was an interesting experience. To preface to this story is that first I had to do the followings on Frugalware:
- Patch mysql 5.0.37 to add support for the sphinx search engine
- Make sure about sphinx itself works fine with this (though sadly I haven't had time yet to package sphinx as well).
We have a newer (but compatible, since we still ship 5.0.x) mysql, but a simple git checkout gave me the old buildscript and then the patch applied perfectly.
Then the plan changed, I needed to do this on an RHEL4 box as well.
Steps:
- Fix broken up2date config, it seems nobody installed any security update on the box for a long time.
- Notice that RHEL4 has mysql 4.x, so I had to upgrade it to 5.0.x which was not trivial.
- After adding the patch to the spec file, I saw that there are a bunch of manual autoconf/automake/autoheader/autowhatever calls, so I did not add a call to mysql's own autogen script. It turned out later that this was a fault, the default autofoo calls did not regenerate all the necessary files, basically they just took a lot of time, but did not really do anything useful. Sigh.
- Once build was done, I had to rebuild perl's mysql driver and the whole php package because of the major mysql upgrade. Did I say I hate to touch php?
- And finally the worst was to package sphinx. I used some opensuse spec file, but it turned out to be badly broken on RHEL4. Fixing it was not so problematic, but took a lot of time, because debugging a specfile under RH is a PITA.
- Let me show a few examples. The equivalent of Fdestdir (the directory which will be tared up after the build is done) is not rm -rf'd before the build starts. So if you have some crap there, your final package will have it.
- OTOH, Fsrcdir (the directory where the build takes place) is deleted, which means you can't do an incremental build.
- If you break your pre-uninstall script, you can't easily uninstall a package, even with rpm -e --force --nodeps (you need some magic --no-preun switch, which is not implied by --force).
- If you say rpm -Uvh foo-2.0.rpm, then sometimes it bails out with an error about it has a file conflict because /bar/baz.so is provided by foo-1.0. What? Doesn't -U stand for upgrade?
Okay, this was enough. I finally finished the task, but I again just can make a "this is so much more efficient with Frugalware" note. ;-)
And no, I don't like to write about why foo sucks, but both this packaging system (or at least the default settings) a docbook sometimes really sucks.
Estimated read time: 1 minutes
It seems the method we used to have a custom date format (ie.: not the default mmddyy, but the yymmdd one) is no longer supported. I spent about an hour trying to figure out what's wrong with it, but it seems the solution is not so trivial and it just does not worth the effort. So it's dropped for now, sigh.
And if I'm at blaming docbook, then here it is: The git manpages still have a ".ft C" / ".ft" string pair around code blocks (or whatever they are called, think of the html <pre> tag), probably due to some broken custom asciidoc.conf.
I like docbook (since generating man/html/pdf is easy from it), but I really hate the fact that they break something with each release. ;-/
Estimated read time: 1 minutes
Estimated read time: 1 minutes
I just got some time to upgrade GHC to 6.10.whatever in Frugalware-current, and it seems they managed to create some screwed up bootstrap binaries, linked to lineedit. This is some BSD version of GNU readline, we did not even had it packaged and the docu says it's outdated in most distros. :-P
However, we still want to bootstrap using upstream binaries, so now we use it. At least I was able to get rid of the ugly LD_LIBRARY_PATH hack, caused by the old readline library they linked the binaries in the previous series.
Estimated read time: 1 minutes
I just found this test, it's an old one, almost 20 years old. It's funny to see what questions became outdated and which didn't.
Some of my favorite questions:
- Do you complain when a "feature" you use gets fixed?
- Ever mask an NMI?
- Do you own more than 16 floppy disks?
Of course the last one is because I still do have more than that - though I no longer have such a reader at home - would have to go to work to read them. ;-)
Estimated read time: 1 minutes
Mailed Christian Couder to cleanup up the Janitor page on the wiki a bit, since for example all the git_config_string refactoring is already done.
It's nice I did not really have to explain I do not want to destroy his work, it's just no longer necessary - he understood it just fine.
Estimated read time: 1 minutes
I just sent out a patch to add support for generating the pdf version of the git user manual. I (and some of the guys at the uni - just discussed recently) prefer reading long docs in pdf, rather than in the memory leaker firefox.
We'll see how it'll be accepted.
Estimated read time: 2 minutes
This was getting more and more annoying. So my problem was that whenever I searched for something in Firefox, I typed it to the search bar and the query was left visible there. This is just totally idiotic for (at least) two reasons.
First, those search queries show what you are thinking about. It's normal that you don't always speak about what you are thinking about, so why would it be logical to always show what are you searching for. This is just uncomfortable for other people, they come to your box (somebody from the family, etc), want to search for something and they see what you were searching for, and they will think about "why did he search for this" - not that they care about it, they just don't want to see this info.
Second, I regularly work in a library and such places where the contents of a query may be just sensitive info and/or NSFW.
OK, so as the result of the previous problems, I saw myself just hitting enter in the search box to get the normal search form and search there so the original search box remained empty. This was abnormal.
Today I spent some time searching for a proper solution for this and sort-of found it: the Searchbar Autosizer extension. Actually it's stupid as it re-sizes your search box (so make sure you remember the size of it before you install this extension), but you can make it a fixed value again and in the second dialog of the preference wizard you have the option to clear the search box right after you hit enter. Excellent, that's what I was looking for. :)