• Increase font size
  • Default font size
  • Decrease font size

Don't forget \n

Print PDF

Ever used a simple printf statement to debug a C program without a proper debugger? If so you may have noticed some strange behavior if you forgot to include a carriage return (\n) in that statement.

While debugging a Segmentation fault I pasted following statement in a few places in the program, to see where the violation occurred:


To my surprise I saw no "kkkkk" not either one, even though I made sure I included one of it as control all the way up the program. It turns out I needed to modify that line into


that is, adding a "\n".

The reason for this is that C does not flush to stdout (i.e. does not display printf and other messages) until a carriage return is encountered. By not adding it in the statement we incurred in the Segmentation fault and the program terminated before messages could print out.

Of course there are ways to force flushing without adding a newline.


Make your keyboard child-proof

Print PDF

At times my baby daughter sits on my lap and "watches" me working. I've learned to switch to reading tasks or casual surfing during these times, as I cannot really type anything in this situation. Still it doesn't take long until she reaches for the keyboard.

So I was looking for a way to temporarily disable said keyboard (not permanently by disabling the driver as some guides suggest, i.e. when trying to permanently disable a built-in laptop keyboard).

I found this tool does the job in Windows (to lock Ctrl+Alt+L, to unlock type "unlock").

Will have to look for a Linux way...


Why reinvent the wheel?

Print PDF

It's a paradigma that has been gaining momentum recently, the Reduce-Reuse-Recycle can well apply to coding too. The more code we reuse the more efficient our application usually gets (in terms of "functions/hour"). It's no secret that most software on the market, be it commercial or not, is made up of building blocks (libraries, subprograms, ...) which considerably speed up the coding process. Why reinvent the wheel? Reusing existing code lets us focus on the functionality that matters, the features that are unique to our program. Often we reuse our own code from other projects, other times we take code from other developers, distributed under some sort of license (e.g. GPL for open-source software).

LabVIEW is no exception to this and provides through SubVI what other programming languages do with functions. These are (literally in the case of a graphical language like LabVIEW) the building blocks of complex applications. As manageability quickly decreases when a LabVIEW block diagram spans for more than one screen it is a must that other-than-trivial applications are broken down into SubVIs. Whenever we make a SubVI we should "think forward" and make it as general as possible, so that it can be reused in our next application... and then next one.

A few tricks to achieve this:

  • The name matters! Just like properly naming a function, a SubVI should also be named in a way that makes it easy to recognize at a glance what its functionality is. Better yet, the name should comply with a naming convention, at least within the same company/organization. For example arraySplit and arrayJoin or split_array and join_array, not at mix of the two.
  • The icon matters! Being LabVIEW a graphical language it is a must, that also the icon be used to convey the functionality, ideally before even reading the SubVI name. There is nothing worse than having the default LabVIEW VI icon for a series of SubVIs that do completely different tasks. A drawing convention is here a good thing too, for example we could use purple for VI that work with strings and orange for those who work with double values.
  • Whenever possible use only native datatypes, rather than custom types. There is nothing wrong with defining application-specific datatypes, it is indeed good practice. When it comes to making a SubVI we should however ask ourselves whether we really need to pass a custom datatype, or rather whether we could do that through a "wrapper SubVI", so that we can make the basic SubVI as application-independent as possible. Having said that, we can safely use clusters to pass data in and out of the SubVI, provided that these are well documented, if not self-explaining.
  • A good version control should also be in place, so that we always use the latest version of the SubVI in new applications (we may for example find and fix a bug or extend the functionality while using the SubVI).
  • Backward compatibility is in most cases of vital importance when making changes, as we do not want to break previous applications that are using the same SubVI. Alternatively we can create a new version of the SubVI and clearly label it.
  • For increased productivity we can create LLB (LabVIEW libraries) with VIs performing similar tasks. These can then be integrated into LabVIEW palette when working on the block diagram.

You will find a selection of ready-to-use VIs in our VIs section.

Last Updated on Thursday, 09 October 2014 00:43

Add screen resolution in Ubuntu 14.04

Print PDF

I have an external LCD monitor, actually an old TV panel, whose available resolutions are not properly detected by Ubuntu (nor by Windows, there I was able to force the correct resolution in the "Advanced" tab). So I needed a way to tell Ubuntu that a certain resolution (in my case 1440x900) is available and should be used for this monitor.

A quick search led to xrandr, a tool that can add and assign resolutions. I created a add-display-resolution.sh script (and saved it in /usr/bin):

sudo nano /usr/bin/add-display-resolution.sh


xrandr --newmode  "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync +vsync
xrandr --addmode VGA1 1440x900_60.00

The values above are to be found with following command:

cvt 1440 900

The name VGA1 was the identifier for said monitor.

To set the resolution we could now use:

xrandr --output VGA1 --mode 1440x900_60.00

Alternatively we can choose the resolution in the "Displays" system application (search for "Displays" in the search box).

All this works great until we restart the system. Here comes an error as Unity (Ubuntu desktop manager) cannot find the correct mode. So we need a way to make this change permanent.

As it turns out there have been changes in Ubuntu 14.04 and older methods (e.g. editing xorg.conf), while they might work, are no longer the "correct" approach. More importantly they could be overwritten when the systems installs updates.

In search of a long-term solutions I found this page, which does a very good analysis of what is going on. I followed that approach and merged in one of the comments. We need to edit the following configuration file:

sudo nano /etc/lightdm/lightdm.conf

Adding the following line:


After restarting the system and logging in, Unity will know that said resolution is available and add it to the displays tab. Here we can select it and the change will be permanent, as with any other "official" resolution.

Displays system application

Last Updated on Wednesday, 15 October 2014 18:14

repair table jos_session

Print PDF

And we're back... that tiny line of code was all it took to fix the problem that was preventing this website from loading. Instead of seeing the home page following warning was shown on a blank page (the nice graphics come from phpMyAdmin):

After a quick research I logged in into my CPanel (from the webhosting provider's site), opened a phpMyAdmin session and selected the MySQL tab, where I could execute the rescuing query:

According to the Joomla forum this happened because the server crashed or went temporarily offline while a cookie was being written to the jos_session table. A solution to this would be writing a script that detects when a table needs to be repaired and attempts it automatically.

Last Updated on Saturday, 26 October 2013 16:41
  • «
  •  Start 
  •  Prev 
  •  1 
  •  2 
  •  3 
  •  4 
  •  5 
  •  Next 
  •  End 
  • »

Page 1 of 5