Main Contents
April 3, 2010
It has been more than one year now that I’m running my own mailing list software here at freehackers, and I think it is now time to release a first preview of it. Let me introduce Colibri 1.0 alpha1
Colibri is a free software (GPL), based on python and Django.
It’s not feature complete, but it actually forward mails. From the web interface, people can (un)subscribe and configure their accounts.
The webpage, with screenshots, download, bugtracker and some documentation is at http://labs.freehackers.org/projects/colibri/wiki
I use mercurial for source control, and the repository is available both for cloning and browsing at http://sources.freehackers.org/hg.cgi/Colibri/
Filed under: Admin, Django, Gentoo |
Comments (3)
January 10, 2010
You might know that there’s a new kid in the C++ compilers list ; clang. Llvm has been around for quite some time, but until recently the only way to make use of it was through the somehow cumbersome llvm-gcc which binds the gcc C/C++ frontend to the llvm backend. People (mostly Apple) have been working since 2005 on a frontend dedicated to llvm, clang. It is already used ‘in production’ by Apple for the C and objective-c languages.
The C++ part is still very alpha, but i still wanted to play with it. Among other things I wanted to try compiling some Qt projects using qmake. So i hacked this quick&dirty linux-clang mkspec. To use it, uncompress the tgz in your $(QTDIR)/mkspecs/ , edit the clang.conf file to suite your own paths, and do something like:
qmake -recursive -spec linux-clang
make
I’m using it with Qt-4.6, and it works for me (c). As a last advice, I highly recommend the svn trunk instead of the last release for clang. The website has clear information about how to do this.
* Download linux-clang.qt-4.6.mkspecs.tgz
Filed under: Gentoo, KDE |
Comments (5)
November 22, 2009
qmake (sort of) supports lex/yacc, but modern people prefer to use flex/bison. If you google, you can find some tricks like convincing qmake that yacc is spelled ‘bison’ and so on. Morever qmake supports for lex/yacc has several drawbacks, such as weird naming scheme, and (when using the tricks), dependencies are not building files in the right order.
Finally, I created my own *.pri files, and here they are:
% cat flex.pri
flex.name = Flex ${QMAKE_FILE_IN}
flex.input = FLEXSOURCES
flex.output = ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.lexer.cpp
flex.commands = flex -o ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.lexer.cpp ${QMAKE_FILE_IN}
flex.CONFIG += target_predeps
flex.variable_out = GENERATED_SOURCES
silent:flex.commands = @echo Lex ${QMAKE_FILE_IN} && $$flex.commands
QMAKE_EXTRA_COMPILERS += flex
% cat bison.pri
bison.name = Bison ${QMAKE_FILE_IN}
bison.input = BISONSOURCES
bison.output = ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.parser.cpp
bison.commands = bison -d -o ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.parser.cpp ${QMAKE_FILE_IN}
bison.CONFIG += target_predeps
bison.variable_out = GENERATED_SOURCES
silent:bison.commands = @echo Bison ${QMAKE_FILE_IN} && $$bison.commands
QMAKE_EXTRA_COMPILERS += bison
bison_header.input = BISONSOURCES
bison_header.output = ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.parser.hpp
bison_header.commands = bison -d -o ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.parser.cpp ${QMAKE_FILE_IN}
bison_header.CONFIG += target_predeps no_link
silent:bison_header.commands = @echo Bison ${QMAKE_FILE_IN} && $$bison.commands
QMAKE_EXTRA_COMPILERS += bison_header
Of course, the proper way to use those is to include them and then define FLEXSOURCES / BISONSOURCES as needed. Example:
include(flex.pri)
include(bison.pri)
FLEXSOURCES = myproject.l
BISONSOURCES = myproject.y
Filed under: Gentoo, KDE |
Comments (2)
November 10, 2009
Technologies going forward..
Twenty years ago, I was reading some books about Unix at the local library. By the time, it was really difficult for me to see, touch, or test an actual unix system and reading books was the closest I could get.
I remember that among the numerous very good ideas ™ in this system, one totally buzzed me : processes and memory protection. A piece of software was protected from other pieces. If one crahes, the other ones could still keep on doing their stuff. Amazing feature, isn’t it ??
Years later, and until very recently, I could proudly say to my friends: “I use linux, I don’t have such problems that you have in Windows and MacOS”. Well, of course, now at least MacOS is based on a serious kernel and the Windows kernel is far better in this regard. But still, unix has had it for very long, and among them, my favourite Unix : Linux.
… forward …
And then, people started to talk about plasma. It is cool, it is great, it is beautiful. One of the reasons I like KDE so much, is that I am very happy with the technology choices made by the project over the time (do you remember the drop of CORBA ?). I’m not into buzz and fancy desktop, so I did not pay much attention to plasma at the beginning. Later on, I started to try KDE trunk again. For months, it was about: compile, start, wait few seconds, plasma crashed, and the whole desktop/X session restarted.
Then, it got better : plasma crashing would not make the whole session crash, and plasma would handle its own crashes gracefully by restarting. Trust me, I really like KDE, but I could NOT resist to think “Hey, they now handle crashes as well as MS Word do!, great job!”. Well, of course, It was still pre-alpha times, you are not supposed to expect more at this time.
.. and backward
Still some months pass by, and came the beta time. I could finally get into KDE and plasma would not crash on startup. So I tried this new plasmoid thinguy. I added few plasmoids, played with them, even configured some. I tried to add a new one… and WLANG, suddently the whole thing crashed.
Do you see my point ? One of the plasmoids made the whole plasma thing crash. We are back 30 years ahead in time. End of process separation and memory protection. Back to the “don’t try to touch anything, it WORKS, don’t disturb it” and “I do not dare trying this new cool stuff because it could crash it all”.
Design
This sounded weird. Really, really weird. I wondered, and learned that indeed plasma was only one process. It seemed to me like a very bad design choice, but I do not know much about all of this, so I just kept my faith in KDE and did not worry too much. I don’t know anything about internals. I talked to a few people, on IRC, in real life… but nobody seems concerned. Nothing about that on the FAQ, not even on the (short) architecture documentation.
As time goes by, people put almost anything into plasma. I mean it : anything. Developers and users for once seem to agree, and everybody is happy. I still do not really understand the need to put a browser in a plasmoid, but if people enjoy that, I don’t have a problem with this. Free software is all about fun, isn’t it ?
After I updated to KDE 4.2.1, I’ve spent one hour to fix it, finally removing the plasma configuration files to get a usable system. I did not look further, but I guess I could have removed only one part of one file, or maybe even just remove a faulty plasmoid.
I don’t mind the hour I’ve spent… but I worry about the design of plasma. I do not dare asking plasma people, as it seems so.. deeply obvious. They MUST have thought about it, mustn’t they ?
A trend in KDE ?
Today I had to kill one of my konsole because one of the software I’m working on was eating all the memory. I used the great CTRL-ALT-ESCAPE kill feature and that saved my computer. Once recovered, I was really surprised to see that all my konsoles were dead. “ps” could confirm this. I usually have 4 or 5 konsoles with 5 or 6 tabs each. Lot of opened vi inside and so on. A doubt came to me and i started several new konsole, and then issued a “ps aux | grep konsole”. You’ve guessed it, only one was present. I rushed on konsole source code and konsole/src/main.cpp confirmed my fears : konsole uses only one process on purpose, through the use of KUniqueApplication.
I don’t understand and I’m sad about this.
Conclusion
Don’t get me wrong , I still think that a lot of things are still done right in plasma (and KDE in general): separation between data and views (nothing new, but still a great thing to do), packaging (though it’s not done yet, I like the ideas). And it looks darn good, that’s right, too.
I just feel very uncomfortable with this. This is the first time ever in more than 10 years that I am not happy with a KDE design choice, and a blog post looked like a great way to release this embarassment. As usual I’m afraid that people will read this post lightly, will feel insulted, and will answer with even more insults.
Filed under: Gentoo, KDE |
Comments (43)
July 27, 2009
One could think that this is as easy as
crossdev avr
but it is not, so i write here how I did it for future reference, and hopefully this will also be useful to other people.
The first problem is that it does not check compatibility between toolchain members (binutils, gcc, …). Understandably, this is somehow difficult, and i don’t blame crossdev. The second problem is that by default crossdev install headers, which are needed for libc, which is needed for gcc… and headers requires gcc… so you have a loop and if fails.
Finally, i needed the c++ part, and by default crossdev only go as far as stage 3 (plain C), so i’m asking him to go farther with ‘-s4′
Finally i did:
sudo crossdev --b 2.19.51.0.8 --g 4.4.1 --without-headers --target avr -s4
Filed under: Admin, Gentoo |
Comments (0)
June 15, 2009
Today i have added a feature to my hg activity extension. I have wanted to have this for long : the tags are now displayed on the graph. Here are two examples, one of the project itself, and another one on the mercurial repository, but only for the last months.
The first one was generated by:
hg activity --splitauthors --maxauthors 5 --width 1500 --height 900
And the second one by:
hg activity --datemin 2008-01-01 --splitauthors --maxauthors 5 --width 1500 --height 900
Filed under: Admin, Gentoo |
Comments (2)
May 18, 2009
This week-end we did the final conversion of the eigen2 source code repository. I shall describe here the few problems we had, as a feedback to the community.
Eigen original purpose was to help provide linear algebra for several KDE parts. As such, it was until now developed inside the KDE repository, which (still) uses subversion. Let it be clear that KDE did a wonderful job at hosting eigen repository, even though several accounts needed to be created for people who only contribute to eigen and not KDE as a whole. Eigen is getting big enough to live and release its own way , but eigen keeps very strong relationships with KDE.
Here is the script that was used for the conversion. The version of mercurial (and of the mercurial convert extension) was 1.2.1.
hg convert https://orzel@svn.kde.org/home/kde \
--authors eigen.authors \
--config convert.svn.tags=tags/eigen \
--config convert.svn.branches=branches/eigen \
--config convert.svn.trunk=trunk/kdesupport/eigen2\
eigen.hg
We faced several problems. Fortunately all but one could be resolved patching python code. That would have been a lot more difficult using, for example, git. Speaking of git, we have found no easy way to make such a conversion, mainly because KDE repository is so huge and it seems git needs to parse the whole history of the whole repository just to convert this part. Eigen is quite small. It took mercurial two hours to convert it, almost all of which was due to network latency between my computer and KDE repository.
Bad default branch name
In mercurial, the default branch name is ‘default’ (same as ‘trunk’ on svn). If you browse a mercurial repository (using the wonderful tck/tk frontend or the web browser), each changeset is tagged with the branch name (and with every tag name is there is any). There is an exception to this, if the branch is ‘default’, nothing is displayed, as a convenience for clarity. Which is great. Using the script I present here, the convert extension would create a branch according to the name of the branches/ subdirectory, which is fine. Though the name for the main branch, the one called ‘trunk’ in svn and usually called ‘default’ in mercurial, was named ‘eigen2′ here, probably because the main directory was named this way.
I have found no way to prevent this using command line arguments. I have tried to play with the –filemap option, but failed. The final solution I used was to locally patch my mercurial (yes, I know, this is ugly):
--- /usr/lib/python2.6/site-packages/hgext/convert/subversion.py
+++ hgext/convert/subversion.py
@@ -777,6 +777,8 @@
branch = self.module.split("/")[-1]
if branch == 'trunk':
branch = ''
+ if branch == 'eigen2':
+ branch = ''
except IndexError:
branch = None
Bad branch used to save the tags file
In mercurial, tags are created by updating a file called ‘.hgtags’ which maps changesets (identified by their md5 sum) to a string. At the end of the conversion process, ‘hg convert’ will create such a file and check it in the mercurial repository. Unfortunately in our case, the file was not created on the right branch neither, so I also had to patch mercurial for this :
--- /usr/lib/python2.6/site-packages/hgext/convert/hg.py
+++ hgext/convert/hg.py
@@ -178,7 +178,8 @@
self.ui.status(_("updating tags\n"))
date = "%s 0" % int(time.mktime(time.gmtime()))
- extra = {'branch': self.tagsbranch}
+# extra = {'branch': self.tagsbranch}
+ extra = {'branch': 'default'}
ctx = context.memctx(self.repo, (tagparent, None), "update tags",
[".hgtags"], getfilectx, "convert-repo", date,
extra)
Spurious file from old history
Once the conversion was done, we noticed a file called src/Core, which should not be here. A diff with a svn checkout would confirm that this is the only difference. I have traced back the problem to a bug in svn which would allow a ’svn copy’ to be done even if the destination name would already exist.
In our case, a directory called ‘Core’ was copied on top of the file ‘Core’. As such, the underlying file was never deleted, and mercurial kept it. Mercurial did quite well dealing with this actually.
See this wonderful commit
http://websvn.kde.org/?view=rev&revision=72256
And this is how the repository looked like just before this commit:
http://websvn.kde.org/branches/work/eigen2/src/?pathrev=72254
We could not manage to fix this problem, and we just removed the file after the conversion. Having this file would anyway not prevent using eigen2 in compilation.
It seems the bug is fixed in svn 1.6.2: I can not reproduce this on a small test svn repository. A bug was filled for mercurial with all details, but as we cannot reproduce this behaviour on a test svn repository, this will be very difficult to solve. We for sure can not use KDE repository to test, it is far too huge for this.
Conclusion
We now have eigen2 repository on https://bitbucket.org/eigen/eigen2/ and so far everything seems ok. The repository is worth 7.3 Mb, which is perfectly honest. We can now grant or revoke write access very quickly and easily without disturbing KDE admins. And of course we also have all the wonderful advantages of DVCS.
Filed under: Admin, KDE |
Comments (6)
May 7, 2009
Today I needed to use mercurial over IPv6 in order to share a repository which is on a computer behind an (ipv4) firewall, but that can be reached over ipv6.
The naive
- hg clone ssh://orzel@ipv6computername/hg/dir
- hg clone ssh://orzel@[ipv6::address]/hg/dir
miserably failed. But i was hinted on IRC (thanks ‘Ry4an’ !) on how to do this, and thought I should share this knowledge until mercurial get better ipv6 support.
First for the clone call, do
hg --config ui.ssh='ssh -6' clone ssh://orzel@ipv6computername
then you will not be able to push/pull until you add to the repository .hg/hgrc the lines:
[ui]
ssh=ssh -6
Enjoy mercurial on IPv6 
Filed under: Admin, Gentoo |
Comments (0)
May 2, 2009
I have the problem for my application Opale, which used to be KDE only and is now both Qt and KDE.
The first thing I’ve done is to switch from *.po (gettext) to *.ts (qt), because Qt can not (or can it ? tell me how !) handle gettext files. Then, I needed to use qApp->addTranslator() to load the Qt translation files (the *.qm generated from *.ts). So far it’s easy.
But then I had a problem : if I start the application, the strings from KDE are not translated. Especially the menu entries created using KStandardAction::*. The reason is that the application does not load any *.mo, and this is what triggers the loading of KDE messages.
The solution is to give “kdeinit4″ as second argument to KAboutData::KAboutData() instead of 0 as is usually done. Instead of trying to load your application translation, fail, and finally not load anything at all, it will load the ones for KDE directly. And you can still use qApp->addTranslator() , isn’t it great ?
Thanks a lot to tsdgeos and Chusslove on #kde-devel for their help, they are the ones who found out.
If you want an example of how to do, you can refer to Opale’ source, and most importantly to the following files:
Filed under: KDE |
Comments (11)
March 10, 2009
We are used to polished and great tools from the trolls, but qmake has always been the big exception to this: ugly documentation, lot of undocumented tricks, and missing features.
For me the biggest one was that it would not automatically create the rule to transform *.ts to *.qm in the generated Makefile. I have been trying for very long to fix this problem. This is especially a shame because this is Qt’s very own translation stuff, and qmake should really knows about it.
Today, thanks to ‘luks’ on #qt, I know have the solution, and I think it’s really worth a blog entry, for my own record, and to help all those having the same problem. : put this in a file updateqm.pri and include it from your *pro(s).
isEmpty(QMAKE_LRELEASE) {
win32:QMAKE_LRELEASE = $$[QT_INSTALL_BINS]\lrelease.exe
else:QMAKE_LRELEASE = $$[QT_INSTALL_BINS]/lrelease
}
updateqm.input = TRANSLATIONS
updateqm.output = ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.qm
updateqm.commands = $$QMAKE_LRELEASE ${QMAKE_FILE_IN} -qm ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.qm
updateqm.CONFIG += no_link
QMAKE_EXTRA_COMPILERS += updateqm
PRE_TARGETDEPS += compiler_updateqm_make_all
Filed under: Gentoo, KDE |
Comments (9)
