I'm amazed people are still finding out about valgrind. Some of these things spread so slowly. Why ?
Another one that seems to be taking a long time to seep into the group conciousness is that the new POSIX standard is available online for free.
Or am I just an unintentional troll ?
Addendum: I wonder if bugs like this (which might have important security considerations) will be on the increase as more "web technology" is used
1. It is not C++. There is no emit keyword in C++. pre-moc code is written in some layer above C++, which is why I called it pseudo-C++
2. It does not take advantage of the standard library. Whilst this made sense some time ago, due to poor compilers, things are improving all the time, and such code is becoming more and more anachronistic.
I think you mis-understood my point somewhat. I'm not arguing against Qt including XML facilities. I'm not arguing against it having useful utility classes. I am arguing that when you write in a particular language, you should actually write in that language, not some warped version of it.
The single biggest disadvantage of Qt re-inventing the wheel (std::ostream vs. QTextOStream etc.) is that it's another API to learn. An experienced C++ developer will not be pleased to have to re-learn all the basic APIs, especially their differences (QString::isNull() being a very good example).
(btw, I wasn't criticising automake, I don't know where you got that from).
Sigh. Both sides seem to be making some pretty dumb points.
First off, Murray comes over all smug ("is sanity a design decision", really !) about Qt's API, smirking about a "non-standard String class", when he knows very well that gtk-- has done the exact same thing, except they resemble std::string more.
Then Guillaume volleys back, with a collection of dubious assertions. If he's really programmed with Qt for two years, how come he hasn't yet noticed that moc doesn't know that "const char *" and "char const *" are the same ? How can he not have dealt with the awful automake build issues of using moc ? How can he claim the horrible define hacks are not a problem, when I've run into problems again and again using Qt in a mixed environment ?
In particular Qt's qevent.h is particularly smug about their "clean headers", and then they have this :
#define emit // emit signal(Yes. Really.)
I think this quote says it all: " Yes, you lose type checking at compile-time, ... but"
Qt is an excellent toolkit, but it's written in pseudo-C++, and that's just horrible. Unfortunately this will never change. Even so, Guillaume is doing Qt no favours with this badly thought-out response.
(Hey, nobody uses something - it must suck, right ? Right ?)
Before I write it myself, I don't suppose somebody has a script (similar to changelog.pl) for adding ChangeLog entries based on a diff -u file ?
Ideally it would handle per-directory ChangeLogs too :)
> Like it or not patents owned and controlled by the free
> software community are a neccessary thing in the short term.
> remember the GPL on 'no additional restrictions'
I'm a little disappointed someone as clued in as Alan Cox has confused the GPL with the free software community.
In better news, LyX 1.2.0 is finally out
Just found out anybody can add a release notification to your freshmeat entries, whether you own the record or not. Not so great.
Update: unless you turn the option off. D'oh.
I'm glad advogato is getting CSSified - the more the better.
I recently made oprofile.sf.net CSSified -
it has a rather nice pinned menu. All versions of IE make
a total hash of it, but seeing as the site displays nicely
in Konqueror, Mozilla, Galeon, lynx, w3m, links, etc. and is
in Opera, I can't say that I care much. It'd be a pity
to miss the shrink-to-fit coloured boxes of advogato though.
XHTML and DocBook
Part of the above-mentioned site is auto-generated from DocBook. Originally the source file was DocBook SGML, but there was simply no DSSSL style that could produce valid XHTML.
So I switched to DocBook XML in the hope this would help. After much hassle (there are literally about 5 different sets of packages for this sort of thing, each containing 5-10 different individual packages - and all have different bugs), I managed to get compliant XHTML for the all-in-one XSL style. However I still needed to remove the xmlns attribute which appeared on every tag, because validator.w3.org didn't like it.
Furthermore, I have yet to find a "chunked" style file that has reasonable file names and actually includes a doc type etc. It looks like I will have to fritz around with this stuff some more ...
It's clear to me this area is still pretty immature - as a document author, I most definitely do not want to be pissing around with the stylesheets unless I want to fiddle with the output style. Why can't the tools provide simple, compliant translation ? I would have preferred to know zero about XSL etc. and just be able to write my document.
The release of 1.2, after much heartache, is close to hand. The GUI independence effort is almost reaching its first complete iteration - my Qt 2/3 port is probably 80% or so complete already. I can't wait to not have to use that xforms stuff again !
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!