Friday, August 29, 2008
Rusty on CeePljusPljus
Rusty Russell have some message for C++ (l)users and here it is. Short and sweet :P
Monday, August 25, 2008
No more sound
edelib will not play sounds any more. I just removed sound code from it which was pretty buggy, especially asynchronous playing. Actually, the only asynchronous part was buggy, mostly due quick threading support addition.
Alternatives? Two possible options that I'm thinking currently: use Audiere (maybe fork it), a very good sound library or develop own. Or maybe use both ideas; Audiere have very cool API and it can be inspiration for EDE sound library design.
Why Audiere fork? Besides cool API, there are few things I would like to change and remove; also the last update on the web is dating on 2006 and repository code gets updates from time to time (like recent native ALSA support addition).
Looks like EDE 2.0 alphas/betas will not have sound support; probably even official 2.0 will not have it. But I' m hoping it will not last too long for it's addition.
Alternatives? Two possible options that I'm thinking currently: use Audiere (maybe fork it), a very good sound library or develop own. Or maybe use both ideas; Audiere have very cool API and it can be inspiration for EDE sound library design.
Why Audiere fork? Besides cool API, there are few things I would like to change and remove; also the last update on the web is dating on 2006 and repository code gets updates from time to time (like recent native ALSA support addition).
Looks like EDE 2.0 alphas/betas will not have sound support; probably even official 2.0 will not have it. But I' m hoping it will not last too long for it's addition.
Saturday, August 23, 2008
-pedantic anyone?
Everyone talks how C++ plays nicely with C? Of course it plays, until you engage somehow stricter validator in that compiler. After that, you are on your own...
During my recent emountd cooking (new EDE mount/unmount HAL-lified notify daemon) I was surprised that you will not be able to compile program that uses libhal with -pedantic flag: syntax error! Not to be expected for a product from people knowing their business...
I got this:
...found 95 target(s)...
...updating 2 target(s)...
C++ emountd.o
/usr/include/hal/libhal-storage.h:283: error: comma at end of enumerator
list
cc -c -o emountd.o -Wno-long-long -Wall -pedantic -g3 -D_DEBUG -I..
-I/opt/ede/include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I. emountd.cpp
...failed
C++ emountd.o ...
...skipped emountd for lack ofemountd.o...
...failed updating 1 target(s)...
...skipped 1
target(s)...
Hm, at first I was thinking compiler went nuts after 5 hour compile/recompile torture; you know, I get used to errors like this in my code, but in code residing in /usr/XXX... that is completely different thing.
So, quick peek in that libhal-storage.h, revealed this:
typedef enum {
// formatting mess so list is reduced
// ...
LIBHAL_VOLUME_DISC_TYPE_HDDVDRW = 0x0f,
LIBHAL_VOLUME_DISC_TYPE_MO =
0x10,
} LibHalVolumeDiscType;
See last LIBHAL_VOLUME_DISC_TYPE_MO and comma at the end? Well, both C and C++ standards said "no no" to that, and -pedantic is here to reminds you on that. Not only for these syntax changes, but for C/C++ difference too; at least those that C++ didn't adopted. The main example is long long type: not yet supported by C++ standard.
Not problem a much, except now you will not be able to compile D-BUS code with g++ and -pedantic! And long long is very much used in it.
Besides emountd, this problem I had in edelib too, at least in D-BUS binding code.
Possible solutions for this mess is to either forget on -pedantic or to add -Wno-long-long, where warnings/errors about non standard long long will be inhibited. Since I like -pedantic, you know what I went for.
Btw. just checked: that issue with libhal is fixed, so I'll have to think how to remove -pedantic in 0.5.9 version (not sure about previous/later). Ah, yes, we have autoconf for that :P
Friday, August 15, 2008
EDE Documentation System
...or: how writing docs can be fun (hopefully).
I'm aware that documentation in EDE 1.x sucked a lot. We had a few html pages with less content than official docs have (yes, I'm also aware how that web documentation sucks too). It contained something like: "Get EDE from", "Very quick install", "Join EDE...". Nothing fancy. But not good either.
Those html pages was quickly assembled with Mozilla Composer and Composer is not known for generating a nice html pages editable with ordinary text editor. At the end, no one had enough inspiration to update it, yielding a situation where some very cool things remained unknown.
You know, developers hate to write docs. It is true. Is it due laziness or because after 5-6 hours of coding you don't want to touch editor any more or, maybe, documentation tools are simply bad, I'm not sure. There could be an influence of each of them.
But, on other hand, zero documentation is not good either (or you will not be able to say: "RTFM!").
Today, when you say "documentation", you will hear instant reply: "DocBook". It is standard, well defined system with a lot of tools to convert it to almost any known documentation format. And is also a good system to inspire you for no writing it at all.
Without a good howto you will not be able to write anything and even after that, keeping reference book under your pillow is a good way to save you from errors and... to speed up writing. You don't want to spend the whole day on only one page, aren't you?
So to save my typing hours on something better and to have a good excuse to reject any program without documentation (or patches without docs updates) :), the only solution was some generator with sane markup. Or markup that most people already knows. And it should produce at least docbook files or something like that, so docbook can be generated.
A good candidate for this was Doxygen. Markup syntax is very easy to pick up and almost all distros already comes with it. Besides html output, doxygen can produce xml output too; theoretically, we could use some xslt processor and produce docbook files from these xml files (that is why xslt exists).
Since I'm not good with xslt (and don't plan to be), I tried to find something already done, or at least "almost done". Unfortunately there is no such a script (or xslt code; call it whatever), or I wasn't able to find it. Something very similar I found as part of Boost libraries and it was generating some intermediate format (named as boostbook or like that) which is then converted to docbook.
How is done, it still remains the mystery to me: they complicates everything, even a build system!
I tried a few more tools (really can't remember now), until I found it: AsciiDoc. It is a python script (a single file!) without external dependencies and does not mandate installation to be used (which is important too, so we can distribute asciidoc without thinking if user has it installed or not, which version and so on).
The first thing that appealed me is simple markup syntax it uses; almost like you are writing an ordinary text file (well, you are writing a text file ;)).
Here is the sample:
and so on. The best example is asciidoc user guide generated from this file.
Next is a number of outputs it supports: besides docbook (out of the box, man!) it can produce a html, xhtml and man files; plus everything else that docbook can spit out (for example to create pdf output, it will create docbook files first then will convert them to pdf via docbook toolchain). Almost perfect tool :)
The only thing left to be done was integration with our build system. I decided for straight html without docbook as intermediate format: asciidoc creates very nice html pages and (most important) docbook toolchain is often not installed (at least I don't install it ;)).
Due jam's flexibility, asciidoc jumped in fine; the only thing you should put in your Jamfile is this rule:
That is it. When jam or jam doc is run in console, jam will, via asciidoc, convert given files, move them in the special directory assembling EDE Manual and installs it in appropriate directory, when jam install is given. Couldn't it be more simple ;)?
On other hand, documentation quality is story for itself...
I'm aware that documentation in EDE 1.x sucked a lot. We had a few html pages with less content than official docs have (yes, I'm also aware how that web documentation sucks too). It contained something like: "Get EDE from", "Very quick install", "Join EDE...". Nothing fancy. But not good either.
Those html pages was quickly assembled with Mozilla Composer and Composer is not known for generating a nice html pages editable with ordinary text editor. At the end, no one had enough inspiration to update it, yielding a situation where some very cool things remained unknown.
You know, developers hate to write docs. It is true. Is it due laziness or because after 5-6 hours of coding you don't want to touch editor any more or, maybe, documentation tools are simply bad, I'm not sure. There could be an influence of each of them.
But, on other hand, zero documentation is not good either (or you will not be able to say: "RTFM!").
Today, when you say "documentation", you will hear instant reply: "DocBook". It is standard, well defined system with a lot of tools to convert it to almost any known documentation format. And is also a good system to inspire you for no writing it at all.
Without a good howto you will not be able to write anything and even after that, keeping reference book under your pillow is a good way to save you from errors and... to speed up writing. You don't want to spend the whole day on only one page, aren't you?
So to save my typing hours on something better and to have a good excuse to reject any program without documentation (or patches without docs updates) :), the only solution was some generator with sane markup. Or markup that most people already knows. And it should produce at least docbook files or something like that, so docbook can be generated.
A good candidate for this was Doxygen. Markup syntax is very easy to pick up and almost all distros already comes with it. Besides html output, doxygen can produce xml output too; theoretically, we could use some xslt processor and produce docbook files from these xml files (that is why xslt exists).
Since I'm not good with xslt (and don't plan to be), I tried to find something already done, or at least "almost done". Unfortunately there is no such a script (or xslt code; call it whatever), or I wasn't able to find it. Something very similar I found as part of Boost libraries and it was generating some intermediate format (named as boostbook or like that) which is then converted to docbook.
How is done, it still remains the mystery to me: they complicates everything, even a build system!
I tried a few more tools (really can't remember now), until I found it: AsciiDoc. It is a python script (a single file!) without external dependencies and does not mandate installation to be used (which is important too, so we can distribute asciidoc without thinking if user has it installed or not, which version and so on).
The first thing that appealed me is simple markup syntax it uses; almost like you are writing an ordinary text file (well, you are writing a text file ;)).
Here is the sample:
Some title
=======
Bla bla bla
Subtitle
--------
Bla bla bla
and so on. The best example is asciidoc user guide generated from this file.
Next is a number of outputs it supports: besides docbook (out of the box, man!) it can produce a html, xhtml and man files; plus everything else that docbook can spit out (for example to create pdf output, it will create docbook files first then will convert them to pdf via docbook toolchain). Almost perfect tool :)
The only thing left to be done was integration with our build system. I decided for straight html without docbook as intermediate format: asciidoc creates very nice html pages and (most important) docbook toolchain is often not installed (at least I don't install it ;)).
Due jam's flexibility, asciidoc jumped in fine; the only thing you should put in your Jamfile is this rule:
EdeManual foo.txt ;
That is it. When jam or jam doc is run in console, jam will, via asciidoc, convert given files, move them in the special directory assembling EDE Manual and installs it in appropriate directory, when jam install is given. Couldn't it be more simple ;)?
On other hand, documentation quality is story for itself...
Wednesday, August 13, 2008
Post #2 (part II)
...continuing...
If you are going to ask where to find that Jam, below I was talking about, I will mention that is already on our repository. This should ensure two tings:
If you are going to ask where to find that Jam, below I was talking about, I will mention that is already on our repository. This should ensure two tings:
- easier finding and download
- ability to hack it if I find something I don't like
You will notice that out there are few Jam derivatives, notable FTJam, BoostJam and maybe less known HaikuJam. We are using HaikuJam (due few useful ablilities) and it is pretty compatible with original jam (a.k.a. "Classic Jam") and ftjam. BoostJam is sad story for itself and it should be avoided for EDE.
What about rest of DE? From the "big three": edewm (window manager), eworkpanel (panel) and eiconman (background with the icons) only eiconman is very much refreshed. Refreshed in a sense that was rewritten from scratch (three times!!!) and is near completition.
This looks like a slow progress, but I'm not thinking like that. There are many small utilities and programs that are added, revised or removed, notably a very good file manager (efiler) that is Vedran working on.
And besides, I'm still following a plan to ship a first alpha without finishing window manager and panel (and partialy eiconman). They will eat up too much time and also I would like to try some new ideas I have with them. In the mean time, edewm and eworkpanel from 1.x should be a temporary replacements.
Ending with this "quick view", I realized I said almost nothing about new things; probably seeing that each of them will require it's own post. Which is planned in the near future (hopefully) :)
Tuesday, August 12, 2008
Post #2
Wow, I'm actually writing something here; already at the second post :)
I feel obligated to put a quick view of EDE we are working on now. That view is about differences with old, efltk powered version, architectural changes and so.
I sumarized some things before. Some of them changed, some not (so there is no need to write about latter). The biggest change (from EDE 1.x) is that famous switch to FLTK 1.x and integrating freedesktop.org standards. This maybe sounds "no too much", but these short sentences are often proved to be opposite. And it is.
EDE 1.x was so tied to eFLTK (which extended FLTK just for EDE needs) that doing simple "compile on FLTK" was simply impossible (since eFLTK was based on first versions of FLTK 2.0, API-s between 1.x and that 2.0 was very much the same, but under the hood, mostly layouting code was totaly different; later FLTK 2.0 API went crazy which is story for itself). Now you see why I put "impossible".
That was clear indication that we should either dig into eFLTK and remove GUI parts (because you know, we would use FLTK 1.x that already provides it) or to start things from scratch, learning from eFLTK what we need and what not. As you guess, we went to latter; now you should have a clue what is edelib module on repository.
Basically, edelib is what FLTK does not provides (which is good or it would be too boring) and what we don't like in it. Plus things we would like to have. And plus freedesktop.org specific things. Enough said.
Here is the one curiosity: EDE had a library named edelib once, which had also needed things for EDE; later it evolved into eFLTK. I'm not sure why; probably due FLTK 2.0 "never-released" curse or else, since I was not part of the project then. Original edelib code was lost when I did a major CVS cleanup which had a tons of started but never finished programs. Probably I made a mistake; probably I should moved everything in a separate module for history reasons, but I can't recall why I didn't. The only thing I know is I had it on my hard drive, which died long time ago.
But, believe me or not, name of the current edelib wasn't choosen due history; it simply popped up, probably inspired by kdelibs for KDE (Vedran when joined to EDE did some work for KDE so you know where inspiration could came from).
So, due those history reasons (and to follow EDE versioning), current edelib is tagged at 2.0.0 version. Just in case you starts to ask when we released edelib 1.0 :)
Second major chaged (or third, lost in counting) is that we are using Jam. I never liked automake; in EDE 1.x we had our own build system, much more like FLTK have and was very limited. You couldn't say "give only to foo.cpp -D_BLA_ flag" nor "link edewm with libdemo_debug.so but the rest with libdemo.so" without writing make code, which is a good chance to yield unportable code between implementations even in the simplest form.
Ah yes, our build system used "recursive make feature", mostly because is very easy to write it without complicating the matter. So, we managed to learn how this was bad when obvious changes in the source files wasn't registered and rebuilded (see Recursive Make Considered Harmful for more info).
Jam does not have these problems; hey, it even allows you to write own, sane "build library" (example is autojam) and to overwrite builtin functions (in jam vocabulary it is a "rule"). Not everything is very bright: jam introduce it's own way of managing dependencies, which is pretty alien to "make commers"; documentation badly sucks giving incomplete information about latter (which is very, very bad since your project will not be built)...
But, small source size (binary too), easily hackable code (I think so), speed (did I mention how it is fast!), damnit good per target (file, target, pseudo target, soon-to-be-generated-file, just name it) options (set per target variables, call functions, etc.) are good arguments to forget flaws. And you don't have to run "makedepend" since it will scan every header in given build files automatically.
I'm lacking of inspiration; remained stuff I will try to finish next time.
I feel obligated to put a quick view of EDE we are working on now. That view is about differences with old, efltk powered version, architectural changes and so.
I sumarized some things before. Some of them changed, some not (so there is no need to write about latter). The biggest change (from EDE 1.x) is that famous switch to FLTK 1.x and integrating freedesktop.org standards. This maybe sounds "no too much", but these short sentences are often proved to be opposite. And it is.
EDE 1.x was so tied to eFLTK (which extended FLTK just for EDE needs) that doing simple "compile on FLTK" was simply impossible (since eFLTK was based on first versions of FLTK 2.0, API-s between 1.x and that 2.0 was very much the same, but under the hood, mostly layouting code was totaly different; later FLTK 2.0 API went crazy which is story for itself). Now you see why I put "impossible".
That was clear indication that we should either dig into eFLTK and remove GUI parts (because you know, we would use FLTK 1.x that already provides it) or to start things from scratch, learning from eFLTK what we need and what not. As you guess, we went to latter; now you should have a clue what is edelib module on repository.
Basically, edelib is what FLTK does not provides (which is good or it would be too boring) and what we don't like in it. Plus things we would like to have. And plus freedesktop.org specific things. Enough said.
Here is the one curiosity: EDE had a library named edelib once, which had also needed things for EDE; later it evolved into eFLTK. I'm not sure why; probably due FLTK 2.0 "never-released" curse or else, since I was not part of the project then. Original edelib code was lost when I did a major CVS cleanup which had a tons of started but never finished programs. Probably I made a mistake; probably I should moved everything in a separate module for history reasons, but I can't recall why I didn't. The only thing I know is I had it on my hard drive, which died long time ago.
But, believe me or not, name of the current edelib wasn't choosen due history; it simply popped up, probably inspired by kdelibs for KDE (Vedran when joined to EDE did some work for KDE so you know where inspiration could came from).
So, due those history reasons (and to follow EDE versioning), current edelib is tagged at 2.0.0 version. Just in case you starts to ask when we released edelib 1.0 :)
Second major chaged (or third, lost in counting) is that we are using Jam. I never liked automake; in EDE 1.x we had our own build system, much more like FLTK have and was very limited. You couldn't say "give only to foo.cpp -D_BLA_ flag" nor "link edewm with libdemo_debug.so but the rest with libdemo.so" without writing make code, which is a good chance to yield unportable code between implementations even in the simplest form.
Ah yes, our build system used "recursive make feature", mostly because is very easy to write it without complicating the matter. So, we managed to learn how this was bad when obvious changes in the source files wasn't registered and rebuilded (see Recursive Make Considered Harmful for more info).
Jam does not have these problems; hey, it even allows you to write own, sane "build library" (example is autojam) and to overwrite builtin functions (in jam vocabulary it is a "rule"). Not everything is very bright: jam introduce it's own way of managing dependencies, which is pretty alien to "make commers"; documentation badly sucks giving incomplete information about latter (which is very, very bad since your project will not be built)...
But, small source size (binary too), easily hackable code (I think so), speed (did I mention how it is fast!), damnit good per target (file, target, pseudo target, soon-to-be-generated-file, just name it) options (set per target variables, call functions, etc.) are good arguments to forget flaws. And you don't have to run "makedepend" since it will scan every header in given build files automatically.
I'm lacking of inspiration; remained stuff I will try to finish next time.
Sunday, August 10, 2008
Intro
Huh... here it is, my second attempt to create and use blog (second attempt in a sense of "I had it few years ago and was too lazy to update it" not "I couldn't create blog account here" :)).
I know you got it; I'm just trying to get used to typing here ;)
So, why I'm doing this again (implying if I'm lazy to write blog)? Well, that "few years ago" was when blogs was hot stuff and the time when projects started to adapt it. Also, in the same time, Vedran (my co-developer on EDE) was accepted in the first Google Summer of Code as part of some Ubuntu project (lightweight desktop, if I can recall). Of course, EDE was part of it too :)
Ubuntu mentors requested students brings their blogs online so they can track their progress(pretty much the same GSOC mentors do today); Vedran assembled WordPress (was pretty complicated those days; was that WordPress or was something else?) on our LUG server and started to scribe. I joined too; not as part of GSOC, but to give insight of other development side too, wrote few posts and find out that blogging wasn't for me.
Things changed in last two/three years a lot; today there are more projects with blogs than opposite and users likes that. Users expects to see a progress, nicely worded things what is going on and not to track developer lists with developer talk nor (for God sake) to track repository changes and read commit logs.
And my habits changed too! Today I'm first checking (for project I'm interested) blog writings then mailing lists and release dates. Often release days or high volume mailing lists means nothing; releases can have minor changes or changes I'm not interested in, mailing lists talk can be (and often is) about weather or movies. Not to mention how hard is to get some useful information. Mailing developers? Sure, just how long they will need to respond and what quality of response will be (bad quality does not mean they trying to be rude, just lack of time).
Blogs are, today, part of development tools, like bug trackers, wikis and mailing list (implying blogs about software development).
Just my view :P. Now to something useful...
People often mails me about EDE progress, what is going on, when will be release and so. Few fellows mentioned online that development stalled or slow progress is going on. Yes, the latest release was almost a year ago.
I was often replying on this via "We are alive, just too busy with EDE 2.0" and "Something soon will pop up" and similar. Yes, I know this is not enough; reading few times that "...we are working hard..." without anything useful is a good chance to drop my interests in that projects, seeking for alternative.
But, there is some truth :P. We are working indeed and there is a lot of changes out there; to summarise everyting in one document or mail would be very ungratefull. So I'm hoping these posting here will try to inform you little better about progress and things under the hood.
On other hand, if I get bored or tired with this blogging stuff, I will probably return to good old mails :)
Anyway, enough for the first intro post. Hoping to came with something better next time.
I know you got it; I'm just trying to get used to typing here ;)
So, why I'm doing this again (implying if I'm lazy to write blog)? Well, that "few years ago" was when blogs was hot stuff and the time when projects started to adapt it. Also, in the same time, Vedran (my co-developer on EDE) was accepted in the first Google Summer of Code as part of some Ubuntu project (lightweight desktop, if I can recall). Of course, EDE was part of it too :)
Ubuntu mentors requested students brings their blogs online so they can track their progress(pretty much the same GSOC mentors do today); Vedran assembled WordPress (was pretty complicated those days; was that WordPress or was something else?) on our LUG server and started to scribe. I joined too; not as part of GSOC, but to give insight of other development side too, wrote few posts and find out that blogging wasn't for me.
Things changed in last two/three years a lot; today there are more projects with blogs than opposite and users likes that. Users expects to see a progress, nicely worded things what is going on and not to track developer lists with developer talk nor (for God sake) to track repository changes and read commit logs.
And my habits changed too! Today I'm first checking (for project I'm interested) blog writings then mailing lists and release dates. Often release days or high volume mailing lists means nothing; releases can have minor changes or changes I'm not interested in, mailing lists talk can be (and often is) about weather or movies. Not to mention how hard is to get some useful information. Mailing developers? Sure, just how long they will need to respond and what quality of response will be (bad quality does not mean they trying to be rude, just lack of time).
Blogs are, today, part of development tools, like bug trackers, wikis and mailing list (implying blogs about software development).
Just my view :P. Now to something useful...
People often mails me about EDE progress, what is going on, when will be release and so. Few fellows mentioned online that development stalled or slow progress is going on. Yes, the latest release was almost a year ago.
I was often replying on this via "We are alive, just too busy with EDE 2.0" and "Something soon will pop up" and similar. Yes, I know this is not enough; reading few times that "...we are working hard..." without anything useful is a good chance to drop my interests in that projects, seeking for alternative.
But, there is some truth :P. We are working indeed and there is a lot of changes out there; to summarise everyting in one document or mail would be very ungratefull. So I'm hoping these posting here will try to inform you little better about progress and things under the hood.
On other hand, if I get bored or tired with this blogging stuff, I will probably return to good old mails :)
Anyway, enough for the first intro post. Hoping to came with something better next time.
Subscribe to:
Posts (Atom)