text: Picking apart some cool code to draw pretty pictures with code that fits into 3 tweets:
  This comes from a codegolf question here: Tweetable Mathematical Art.
  Slides: Tweetable Art Code.
  Picking apart some cool code to draw pretty pictures with code that fits into 3 tweets:
  This comes from a codegolf question here: Tweetable Mathematical Art.
  Slides: Tweetable Art Code.
  As it stands, lxpanel’s taskbar plugin (part of the LXDE desktop you get with Lubuntu) does not show urgent (flashing) windows if they are on a different virtual desktop from the one you are looking at.
  This seems wrong to me (I logged Bug 682), and the fix is a little one-liner:
  --- lxpanel.orig/src/plugins/taskbar.c 2013-08-27 23:57:55.000000000 +0100 +++ lxpanel/src/plugins/taskbar.c 2014-09-26 00:48:25.026855589 +0100 @@ -202,10 +202,10 @@ tk->flash_timeout = g_timeout_add(interval, (GSourceFunc) flash_window_timeout, tk); } -/* Determine if a task is visible considering only its desktop placement. */ +/* Determine if a task is visible considering only its desktop placement and urgency. */ static gboolean task_is_visible_on_current_desktop(TaskbarPlugin * tb, Task * tk) { - return ((tk->desktop == ALL_WORKSPACES) || (tk->desktop == tb->current_desktop) || (tb->show_all_desks)); + return ((tk->desktop == ALL_WORKSPACES) || (tk->desktop == tb->current_desktop) || (tb->show_all_desks) || tk->urgency); } /* Recompute the visible task for a class when the class membership changes.
  To install this patch into Lubuntu, do something like this:
  sudo apt-get install build-essential fakeroot dpkg-dev sudo apt-get build-dep lxpanel mkdir lxpanel cd lxpanel apt-get source lxpanel cd lxpanel-* wget patch -p1 < show-urgent-windows-on-all-desktops.patch dpkg-buildpackage -rfakeroot -b cd .. sudo dpkg -i lxpanel_*.deb killall lxpanel lxpanel --profile Lubuntu
  A quine is a program that prints out its own source code. I will describe five examples:
  Slides: Five Quines
  Arguably the greatest program ever written:
  More info on quines:
  Posts in this series: Syntax, Deployment, Metaprogramming, Ownership
  There is often a trade-off between programming language features and how fast (and predictably) the programs run. From web sites that serve millions of visitors to programs running on small devices we need to be able to make our programs run quickly.
  One trade-off that is made in many modern programming languages (including Python, Ruby, C#, Java and JVM-based languages) is that the system owns all the memory. This avoids the need for the programmer to think about how long pieces of memory need to live, but it means a lot of memory can hang around a lot longer than it really needs to. In addition, it can mean the CPU has to jump around to lots of different memory locations to find pieces of dynamically-allocated memory in different locations. Where this jumping around causes caches to be invalidated that can really slow things down.
  While these garbage collection-based languages have been evolving, C++ has been developing along a different track. C++ allows the programmer to allocate and free up memory manually (as in C), but over time the community of C++ programmers has been developing a new way of thinking about memory, and developing tools in the C++ language to make it easier to work in this way.
  Modern C++ code rarely or never uses “delete” or “free” to deallocate memory, but instead defines clearly which object owns each other object. When the owning object is no longer needed, everything it owns can be deleted, immediately freeing their memory. The top-level objects are owned by the current scope, so when the function or block of code we are in ends, the system knows these objects and the ones they own can be deleted. Objects that last for the whole life of the program are owned by the scope of the main function or equivalent.
  One advantage of explicit ownership is that the right thing happens automatically when something unexpected happens (e.g. an exception is thrown, or we return early from a function). Because the objects are owned by a scope, as soon as we exit that scope they are automatically deleted, and no memory is “leaked”.
  Because ownership is explicit, we can often group owned objects in memory immediately next to the objects that own them. This means we jump around to different memory locations less often, and we have to do less work to find and delete regions of memory. This makes our programs faster.
  Here are some things I like:
  In my experience, the most frequent performance problems I have had to solve have really been memory problems. Explicit ownership can reduce unnecessary memory management overhead by taking back the work from the system (the garbage collector) and allowing programmers to be explicit about who owns what..