Fl_Highlight_Editor 0.2

I've pushed new, 0.2 release of Fl_Highlight_Editor widget. This release is actually a set of changes collected after 0.1, which happened almost a year ago (huh).

Quick changelog:

• Added fluid-mode, html-mode and make-mode; modes for editing named file types.
• Extended language so user is able to change cursor shapes and FLTK font faces (not to be confused with Fl_Highlight_Editor faces).
• Added support for named and HTML colors; in previous iteration only FLTK colors were allowed (e.g. FL_WHITE), now you can use e.g. #a4a3a3 or aqua.
• Manual update, a bunch of small fixes and more...

Let me know if you find some issues.

Ono, a small and friendly Offlineimap frontend

After a bit longish hiatus, here is the new project I managed to hack in the last two days. Nothing big and nothing fancy, but usable for me and, hopefully, for others.

I've been struggling with mail clients for, let say, last 2-3 years. The first client I started seriously to use was Mutt, some 9 years ago. At that time, when I first read Mutt famous catchphrase:

All mail clients suck. This one just sucks less

I had no clue why this guy was so full of himself. After all, I used MS Outlook for business mailing so transition to Mutt was like moving from nice Mercedes to 100 year old broken bycicle. BUT...

You know, good tools gets under your skin (in positive context) and you notice that when you attempt to switch to alternative. As someone once said, good tool is invisible.

Anyway, to make this story short, after all these years, various Thunderibirds (btw. the last iteration looks awful; for God sake guys, what are you doing!!), Gmails, Gnus-es and not-sure-what-else, I still can't find viable alternative to Mutt. Sure, Mutt isn't perfect: multiple mail accounts handling sucks badly, IMAP/SMTP can be much better, configuration; oh boy, it is like Sendmail.

But the speed, shortcuts and everything-can-be-configured approach: unmatchable!

So, to bring Mutt in 2010 (not a typo :P), where we operate under desktops, have system trays, notifications and good IMAP libraries, I created a small project called Ono. Ono isn't Mutt specific; actually, I created it to make Offlineimap usage easier. As a matter of fact, with Ono, you can use any mail client, as long as Offlineimap is used for mail syncing.

OK, I lie; you don't have to use Offlineimap either. Thanks to builtin scripting language, you can use Ono to place in your system tray whatever you like: terminal programs, GUI programs without tray support, name it.

You can download 0.1 version and play with it. Be warned: documentation needs some love as there are couple of hidden gems I didn't mentioned in README file and, I can't promise it will not crash :)

Fl_Highlight_Editor, editing widget for FLTK

Last couple of days (and months) I was secretly working on a new widget for text editing under FLTK, Fl_Highlight_Editor.

FLTK is missing a good editing widget with code highlighting capabilities, so I gave it a shot adding some new concepts; not revolutionary, but how many text widgets comes with a scripting language? ;)

Having extensible editing facility, where you can easily add new language support without digging in C/C++ code isn't common. My favorite, Scintilla isn't ready for FLTK (actually there is no available port for FLTK) and all syntax highlighting capabilities are added by subclassing C++ classes. Means, you have to recompile your binary if you want to add or modify something.

So, I tried to find inspiration in editor of all editors, Emacs. Sure, that >50 MB monster isn't model for embedding, but some concepts like small core and everything else written in extensible language sounds quite interesting. By using similar design, widget user can easily remove parts it doesn't like or only add one he/she likes. For example, editing and highlighting support only for language X, where scripts could be embedded in binary (or not).

Scripting language I used is Scheme; better say TinyScheme, which is still the only awesome interpreter I could find, bundled inside 4 files, that doesn't suck. Extensible language (the language which you can extend without digging inside interpreter) where code is data, is a great deal: you can easily experiment with the syntax, have so called configuration files without external libraries or additional code and the best of all, have fun using it.

Initial Fl_Highlight_Editor version comes with modes for C/C++, Python, Scheme and Markdown; not advanced as Emacs modes, but capable enough to highlight known patterns and setup TAB width depending on language. Sure, there is a lot of work, but ultimate goal is to keep the whole package simple, but flexible enough for adding new features.

Happy usage :)

Building shared libraries with Jam

Jam is one of those tools I really admire: it is small, lean, fast and you don't have to be a rocket scientist to hack it. The best of all, it is so ahead of make you will wonder why you didn't use it before.

Ok, above paragraph very biased, but adding Jam to EDE solved a lot of portability problems we had before and introduced some new, which is story for itself. What matters most, with Jam you can write true build library that you will reuse between projects.

Sure, writing reusable build library with make is possible too; you need autotools and you write a little bit autoconf, then a little bit automake and everything you pack in a nice M4 script. Don't forget to use appropriate shell syntax or odd things will happen between platforms.

No more ranting... One of the most desired feature I find people are looking for Jam is how to build shared library. This isn't packed with stock Jam since shared library making is highly platform/OS specific (that is why we have libtool), but in the recent years things are settled up a bit: odd platforms died, wild compilers vanished and there is good chance you will find gcc (or gcc compatible compiler, like clang) on your target platform.

So, here is rule called SharedLibrary you can use with gcc and compatible compilers:

SUFSHARED ?= ".so" ;

rule SharedLibrary {
  local objs = $(>:S=$(SUFOBJ)) ;
  local lib = $(<:S=$(SUFSHARED)) ;

  # compile it
  ObjectCcFlags $(>) : -fPIC ;
  ObjectC++Flags $(>) : -fPIC ;
  Objects $(>) ;

  # link it
  LINKFLAGS on $(lib) = 
     -Wl,-soname,$(lib) -shared [ on $(lib) return $(LINKFLAGS) ] ;
  
  Link $(lib) : $(objs) ;
  Depends all : $(lib) ;
  Clean clean : $(lib) ;
}

Now, calling it with:

SharedLibrary libfoo : file1.c file2.c file3.c file4.cpp ;

will create libfoo.so ready for consumption. In case you are running Windows or other platform where .so extension is not suitable, setting SUFSHARED variable will fix that. The best of all, we completed it in a couple of seconds... ;)

Mozilla's new language?

Looks like, these days, is quite popular every company/organization to start own language.

I just noticed on LU how Mozilla is developing own language, called Rust. How does it look like? Well, if you know C and bit of Python, you already know Rust.

Boring...

Distributing programs correctly

One of the things I like in Chicken scheme is one of the cleanest distribution model I ever seen. For some it will look, at first, very ordinary or they will not notice it at all (at best) but... shouldn't The Right Way be the program installation without noticing that procedure at all?

I never was a fond of distributing own binaries (except a distro specific packages) on Linux; you never know what the person who downloads it has. Does it have correct glibc or stdc++ or whatever libraries you are using? Just bump the source archive and let configure do the magic.

But in Chicken case, things are different. You simply download the binary and extract it in / directory.

Later, you find out you are missing the big integer support (not enabled by default), simply telling "chicken-setup numbers" in command line and "(use numbers)" at the beggining of the program will brings them.

And at the end, you want to compile your code, "csc yourfile.scm" will do it.

Now, can things be more simple than that? You should not be worried will Chicken's binary works on your Linux distro nor what are the eggs, nor how "chicken-setup" resolves egg dependencies, finds and downloads them and at the end, compiles and installs them. Nor how "csc" calls gcc at the background to perform final translation of generated C code to the binary.

Everything works.

Now, when the big names or the big programs will have the similar thing with the same (or at least similar) easiness?

Rusty on CeePljusPljus

Rusty Russell have some message for C++ (l)users and here it is. Short and sweet :P

-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 of
emountd.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