Upgrading Fedora

Imagine you have computer running Fedora 19 and you use it for daily tasks. Imagine you are happy with it, especially when you do run yum update (sic). Now imagine you decided to upgrade your bellowed, happily running system to the next major version.

Sure, you head directly to FedUp site, assuring you are running the latest version (because they messed up previous versions which could render your system unbootable), and with the fingers crossed, you fired it up.

Now imagine, after a half an hour, you get this message:

WARNING: problems were encountered during transaction test:
  broken dependencies
    libvpx-devel-1.2.0-2.fc20.i686 requires libvpx-devel-1.2.0-2.fc20.i686
Continue with the upgrade at your own risk.

More than fifty years of computing and research in IT field, with all sorts of methods, algorithms, object oriented, dynamic, functional and what else languages, and resolver figured THAT out?

Autumn cleanup

It's been a while since I put anything here (whoaa, 5 months!) mainly because of personal issues I had during that time, which required my absence from the project and usual things.

So, I'm slowly getting back. Unfortunately, this absence period delayed planned EDE release and a bunch of stuff I planned to do in the mean time, and, for warming up practice, here comes small autumn project cleanup.

emountd, a small HAL abstraction routing daemon was removed. The main intent was to provide manageable way to receive events from various devices, without linking every program with libhal and required libraries. As usually, we got something worse as replacement; not even sure what exactly is today, systemd or some *Kit crap.

Because of that, planned mount listener (where you would get an icon on desktop when you mount some device) will be left for the future. Things are hairy now for anything normal and portable.

The second cleanup thing is documentation moving, better to say, overhaul. EDE 2.0 shipped with asciidoc, used to build application specific documentation and combine everything in EDE Manual. I modified it a bit to make it easier to automate from build process, but it requried a serious update: official asciidoc already progressed a bit, some python 2.x idioms were deprecated and more and more distributions are shipping python 3.x by default (asciidoc was written in python).

Thanks to awesome kraileth, EDE Wiki is much better now so why not to move documentation there? Everyone could edit it without repository access, which is the main point of one big fat manual: more eyes, better content.

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 :)