Videos on C++.

G.Law on GDB:

B.Stroustrup on C++ in general:


H.Sutter on C++ mostly in general:

 

S.Meyers on C++ move semantics and other topics.

P.S.: sharpening the saw.

Electron, Node.js and their friends.

Trying to put some changes into the KeeWeb app (I even forked it), I started the WebStorm editor and then recognized that I have almost started to shave another Yak, which is in this case an electron framework, node.js and so on in the direction of JavaScript.

But the enemy is recognized and defeated! Screw it.

Recalling the beautiful article from Jeff Atwood which is called "Sharpening the Saw", I think of renaming the blog to reflect the idea that every Yak Shaving can be or can be not sharpening the saw in the context of the aforementioned article.

Yak Shaving #0: Visual regexps on steroids.

Being fed up with crazy syntax of RegExes in Emacs, I have found a replacement for it. Or I'd rather say "enhancement". It is called visual-regexp-steroids and looks so cool on screenshots, just check it out.
Exactly what Emacs should've had from the beginning. And guess what? It does not work for whatever reason. Either it is Helm interfering with it or Python is not found as expected (but it is available in the system). I don't know, therefore I'm doomed to guess wildly. Emacs, I hate you. The more I look at you the more you look like a Yak. Wait a minute, isn't it what Stallman meant choosing the Emacs symbol (the wildebeest)?

And I'm shaving, shaving...

P.S.: My emacs configuration.
P.P.S.: Another beautiful online RegEx helper with astonishing amount of interactive help. 

Yak Shaving #-1: The good news, the bad news and the Yak Shaving.

The good news are: I have definitely decided that GTK is not worth fighting with it, facing a Qt as an alternative. The difficulties to find a documentation/explanations (and alive people who would have had the knowledge and were willing to help) were so big that I decided to cancel the complete topic altogether.
The bad news is the other side of the good one: I gave up on GTK and if I want to implement any GUI stuff, Qt is an option as it just has more clear future.
But the ugly news is the fact that there is no sense to do anything based on Qt for GIMP. Or at least it sounds a bit perversely. I am not sure I want to touch it even with a 10-meter stick.

Ah yes, and one more thing. I see no place for lisp there anymore.

Hopefully Yak Shaving is over.

For those who are interested, the original idea was to introduce the non-destructive editing into GIMP. After fighting with the GTK+ (and a little bit with Lisp world, too, because I cannot imagine any good reason for developing a graphics editor on plain C in 2015), and also after confirming that there are proprietary but inexpensive alternatives to Photoshop (like Bloom) with aforementioned non-destructive abilities, I decide to give up on this topic as on not interesting. In my opinion it has no or too less potential.

Balm for my wounds

Just in time I have discovered beautiful source of the information: planet lisp. Yes, I didn't see it before.

Anyway, there after digging into old archives, I have found this: Starting to Hack on SBCL.

It is exactly what I need now. The motivational article with a number of pragmatic guidelines and examples.

Just in time, just in time...

Rants on GTK+, Common Lisp, and Emacs

TL;DR: I think I'm going to give up trying Common Lisp for prototyping related to the GIMP development despite the topic still looks extremely attractive.

After looking at the GIMP source code I've got an idea to introduce the non-destructive editing feature to the GIMP editor. Unfortunately, the architecture of the GIMP is not that flexible in case I want to stay compatible to the previous version of the GIMP. So I was thinking of utilising the "parasites", which are some form of the "comment" field on some objects in the GIMP land. As this is still a subject to explore plus my ideas could have changed during the development, I concluded to give the Lisp a try as it seems to fit the requirements of the exploratory programming. The main reason to switch the language in the first place was enormous amount of the boilerplate code for GTK+ in C and the fact that the C language being kind of a cross-platform assembler, is good for some low-level tasks, but not for everything. I would put it in the way that C is good for final polishing and Lisp is good for initial rough strokes. My tasks seem to be pretty high-level and... rough.

Now let me explain the problems I have faced.

First off, if you are a so-called mainstream developer, the chances are high that you are accustomed to  some tools and approaches like use of particular IDE, toolchains, frameworks and so on. With CL (Common Lisp) it seems to be completely different world which needs to be explored and understood. Usually this problem is referred to as the "steep learning curve" of the Lisp. But I would like to get rid of the general words and to present the exact problems. So, in detail it looks as follows:

1. First off, one needs to learn the language itself, I mean the syntax, the concepts and so on. The power of the CL language is enormous and cannot be underestimated. I've got a feeling that for the programmer this power serves as a carrot in front of the donkey. It is very strong motivation and rightfully so.
2. Coming back to the earth, one has to set up the working environment. And here almost everything related to CL is bad, because you cannot use the "general purpose" IDE like Eclipse or similar. You have to use either Emacs+SLIME, or solutions from Allegro. For other possibilities I can say nothing as the aforementioned two are most popular. Looking at these two it is clear that choosing Allegro means choosing not only the IDE, but also the set of the libraries, which is not acceptable in my case. So I had really only one choice: Emacs+SLIME. Well, long story short I've dealt with this task more or less successfully. But it took both time and motivation.
3. Anyway, now with IDE it seems we can see the CL it its shiny glory, right? Right? Well, not really. You know, the language itself is almost nothing without the necessary libraries unless we are talking about some very specific tasks of extremely low-level hacking. So, what about the libraries? Looking at the specification of the CL I had a hope that it can be perfectly integrated with C code as both languages have well-defined ABI and FFI. After all, we have a CFFI in CL, which is exactly the means to integrate with C code. It works well for simple examples. But I need the support of the GTK+ in my research. Moreover, the latest GTK3 version. And GTK+ is all but the simple thing. I mean, the ideas behind are simple, but the implementation is unpleasantly complex. I have to admit that it is not over engineered in terms of the run time, but still it is complex, it even has an internal garbage collector. It is really strange thing: OOP with GC implemented in plain C.
   Now, the main problem with CL+GTK is that it does not work. Even worse, it works, but sometimes crashes. So you run the code, it works. You try run it again, it does nothing. You run it for the third time, it hangs and after all should be killed by the OS. Now, you restart the lisp system(!) as it disconnected from the Emacs, and the code cannot be compiled because of some strange error. Then you kill all Emacs buffers and restart the lisp from the scratch and you are again on the first step of this sequence.
4. Now, one can say that the problem is not in the CL, but in the developer. I can accept that taking into account that there are successful CL programmers in the wild. But if one wants to learn something which is done by other people, he should get the information from somewhere. Normally from books or their equivalents like blogs and so on. And here CL is really in bad condition. Maybe it is because the community is small, I don't know. But the fact is that there are no practical sources of information for the topics I am interested in. In case you are not interested in graphics or in low-level stuff, there is "Practical Common Lisp" by Peter Seibel. I've also read the "Artificial Intelligence Programming" by Peter Norvig and "OOP in CL" by Sonya E. Keene, and "SICP" and others I could find. There are not so many in fact. Maybe I am annoyed with the fact that I cannot get the environment with "batteries included". I have a feeling that batteries are discharged, disassembled and buried. And yes, I have forgotten to mention that there are many libraries for the very same things so in case one wants a solution for something, you will have some moments of the analysis paralysis trying to compare all the available libraries for the same stuff. In case someone says I could have taken Allegro it has "batteries included", I can comment that it is possible of course. But it is very difficult for me to accept the fact that in case I have to switch from Allegro, I have to rewrite the code again to use different libraries. Plus, why the heck did I invest so much time into learning the Emacs then? Isn't it ironic?
5. Now, all described problems are just preliminary tasks before the integration of CL and GIMP, which itself is complex. To be fair, I even did not touch this problem at all, despite this is the goal and initially looking at some inspiring videos by Zach Beane and by Marco Baringer. I have a feeling that in CL I can use a top-down development approach moving down from the final target to the final implementation using its interactive capabilities to implement the necessary functionality step-by-step. Even more, people like Zach demonstrate this. I would really like to know how he got to that point. I am not sure he knew everything from the very beginning. It is really important to know how to learn this. Alas, this information is not available. In the past (199x-200x) when I faced the problems like this with other languages/technologies, I could always ask the community. Usually I could do it in real world, not online, which is very important for efficiency at least. Even if people did not know the answer, which was very often, they anyway provided some information which I could analyse and as a result, I knew more and more. With CL, even if we ignore the "real world", the community is somehow not that much helping.

I am not giving up completely now as the carrot in front of me looks extremely tasty, but I am really annoyed with amount of slowing me down unnecessary difficulties which I get on my way.

I remember the ease of use of the first Delphi back in nineties, it was so easy, so intuitive. I had to think only about the programming only about the real task, and IDE delivered the concentrated joy letting me not to think about GUI. Delphi took away the difficulty of programming the GUI, it just made all that stuff move off my way. Again, the Delphi was the moment of "quantum leap" as I have got rid of a lot of the headache in one step, not more, not less.

I recalled the Delphi simply because the current situation seems to be perfectly opposite: every possible and impossible difficulty comes between me and the final goal. Actually these memories are exactly the reason I learned the Emacs, as I was promised so many times that Emacs is a silver bullet for programming / text editing. Recalling the silver bullet from the past (the Delphi) I could imagine the ease of use of the tool and therefore invested the time into learning it. Now I know the Emacs to the level I think I can teach it. But you know, if I compare it to say Sublime, in reality it is on par. Yes, it is programmable and so on, but Sublime is also not that bad.

To summarise, the complexity still grows and the chosen tools (Common Lisp plus friends) are not helping to decrease it yet. Moreover, they add their own complexity. But the hope remains. I hope that at some moment I will be able to automate all the tasks so that I will be able to concentrate only on the interesting topic.

Spacemacs

Looking for C/C++ emacs integration, found another emacs tutorial which led me to Spacemacs (vim+emacs, but the clean one). Looks promising mostly because the community seems to be very active.
UPDATE: gave up on the topic, as this flavor of Emacs needs a set of skills I don't have. I mean the vim background.

Considering different languages.

Possible candidates are:

• Vala
• Nim

At first glance Nim looks very good, I am considering using it for the implementation. The reason is the set of articles I've read plus the fact that I have a background fitting to this language (Pascal, Delphi, Lisp, C, C++).

Heck, I liked Swift a bit, mostly for its syntactic sugar (like chaining of the optionals and type inference). Then I liked Vala for its simplicity and integration with GTK. Now I like Nim...

Looks definitely like the analysis paralysis.

Is GIMP worth spending time on it?

Now after reading a lot about the GIMP, I see that it has some critical problems.

Here are the links I have read (ones I have recorded):

• https://www.mail-archive.com/gegl-developer@lists.xcf.berkeley.edu/msg00612.html
• http://www.rileybrandt.com/2014/03/09/photoshop-to-gimp/
• https://mail.gnome.org/archives/gimp-developer-list/2015-February/msg00055.html
• http://www.thebloomapp.com/features/
• https://pixls.us/articles/freaky-details-calvin-hollywood/
• https://wiki.gnome.org/Design/
• http://www.gimpusers.com/forums/gimp-user/15297-how-to-design-new-gimp-themes-from-scratch
• http://www.maketecheasier.com/flat-gimp-icon-theme/
• http://blenderartists.org/forum/showthread.php?313266-New-Gimp-PS-CS6-Theme-with-icons
• http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.7715&rep=rep1&type=pdf
• http://gimp-tutorials.net/

Currently I see the following problems with GIMP development (if I am going to dive into it):

1. The software architecture. It is neither documented, nor obvious from reading the Object-oriented C code.
2. The architecture seems to be too monolithic to allow deep changes like the ones I am interested to introduce.
3. Lack of organization: what I see in bugtracker and wiki is very far from optimistic picture.
4. Strange choice of tools - as for 2015 - like plain C with "manual" OOP. I see no reason why they don't use at least Vala. I have a feeling that the language, despite being absolutely fine for OS kernel, is slowing the development down.

Here is what I see the most critical current problems of GIMP:

• Lack of non-destructive editing. Most flagrant is lack of affine transformation and color control.
• Awful UX design. I know that some people can disagree with me, but here is my opinion: there is an industry standard. Instead of fighting with it, GIMP interface could live with it. Why some professional artist who uses Photoshop on a daily basis should learn new habits? What for?
  I have read somewhere beautiful explanation: the tool (GIMP in this case) is an obstacle that stays between artist and his/her goal. The tool should prevent artist to do the job as little as possible. Therefore responsiveness and predictability matters. Therefore it is important to follow the industry UX standards. It is important, because people already have some habits (including me btw.) and these habits are a scarce: they are in fact an experience. And to be fair, for me my habits are more valuable than the tool.

All in all I have a feeling that the development of the GIMP is artificially slowed down.
Some ideas under the hood are brilliant (like GEGL abstraction), but some are horrible (like OOP implemented using plain C).

Thus I am seriously considering diving into Krita despite I don't like the KDE.

Docker for GIMP: task is on hold

After fighting with dependencies necessary to compile GIMP (yes, now I can do it professionally) I've got another idea: what if I put necessary parts into the docker container? Any newcomer could benefit from having such a preconfigured development environment. The need for the container is simple: it is difficult-to-impossible to automate one step in the build as the necessary libraries are:

• lcms2 
• gdk-pixbuf

...where lcms2 cannot be downloaded automatically (or at least I did not find how to do this) and gdk-pixbuf is placed on the ftp in the way so that I cannot link to the latest version without some sophisticated script. But I could create the docker container. Well, theoretically I can do it as I never did it before.
I thought about two different flavors of the containers: the smallest necessary one which would have only these two mentioned libraries and the complete, huge one which would have everything up to the ubuntu into it.

Anyway, as the solution seems to be only a half-measure because it would break in case any of three participants (gimp itself, lcms2 and gdk-pixbuf) would change in some incompatible way, I put this task on hold.

Alas.

Tools to understand larger amount of C code

To understand the structure of the GIMP project I try to use as much of modern tools as possible. I believe that accumulated experience in the field of analysis worth something. So I bet on them. Of course, reading the source code is still an option, but the last resort, so to say.
Here I put the links on the tools I considered so far.

• Wikipedia article to the software that creates the call graph based on the source C code 
• NCC compiler (never heard of it before, but the description sounds promising)
• kcachegrind (the one I use currently)

---

 Now, the current topic is GLib main loop. Links:

• Official documentation of the main event loop 
• GLib: GMainContext

Also helpful:

• "Delivering Signals for Fun and Profit" - Michal Zalewski 
• man 2 poll
• man 2 select

The very old document on GIMP architecture

It is good to have Google...

Looking for GIMP architecture in internet I've found the paper "The Software Architecture of the GIMP" (2006). Yes, it is old, but it's all we have. I wonder if anyone has anything better.
The funny thing about the document is that it is not available directly using the site (citeseerx.ist.psu.edu), but Google gives you the direct link to it.

Installing and configuring software is the ultimate form of Yak Shaving.

Fighting the GIMP, I spent enormous amount of time setting the development environment.
On the last iteration I've found this beautiful article related to the Docker.
The "Yak shaving" metaphor describes my process so precisely that I could not resist to store it here.
If I would have found this article earlier, I could have saved much much much time. On the other hand, how could I know, how much time would it save? It is so ironic...

Creeping features

I don't like the pantheon terminal outlook on the Elementary OS. It is better than others including the one in OSX (I tried only the default one though). But why the heck does it have all these bells and whistles like header, tabs and so on? Just asked a question at stackexchange and got a hint how to do it. So, long story short, I tried to strip all the decorations with some simple hacks, without diving deep into the GTK+/Glade and so on. But the problem has to be solved fundamentally, with some settings. Anyway, I put my thoughts there, in the initial question.
And yes, it is just another spin-off from the main topic of hacking the GIMP. Just a spin-off...