05 October, 2011

ImageMagick -- Send Directly To Display

'til recently I've always manipulated images, stored them to a temporary file, then displayed them to confirm the desired results.

I've recently found that this is an unnecessary step, as the output of any command can be sent directly to the display using the 'win:' command directive.

E.g.

$ convert main/trunk/Media/Photos/Cats/Dempsey/DSCF0002.JPG -resize "100x100^" -gravity center -crop 100x100 win:


Cheers.

23 August, 2011

Making Use Of Idle Workstation

Have you ever given thought to the amount of computational horsepower your machine packs and how much of it is wasted when not in use? I thought it would be useful to write a script that could interrogate the current state of a Linux workstation to determine if it was available to run some background activities, similar to SETI desktop behavior.

Seems determining if the screensaver is active is a pretty good indicator of whether a user is currently using the system. Bundle that with evaluation of the system load and you can get a pretty good indication of an idle system.

Following is a Tcl-script that determines if the system screen saver is active. One could imaging bundling this will suspending/resuming a process or virtual machine to make use of the idle time.

Let me know what you think and usages you may think of.



#!/usr/bin/tclsh

proc isScreenSaverRunning { } {
set response [exec gnome-screensaver-command -q]
# puts $response
foreach e [split $response \n] {
switch -glob -- $e {
"* inactive"
{
set running 0
}
"* active"
{
set running 1
}
default
{
}
}
}
return $running
}

proc check { } {
set running [isScreenSaverRunning]
if { $running } {
puts "screen saver running"
exit
}
after 1000 [list check]
}

#-----main------
after 1000 [list check]
vwait forever

15 August, 2011

C++ Trace Logging

In my last post I made mention of a Gnu interface for retrieving backtrace info at run-time. I also suggested that I thought it would be useful for logging. In this post I'll expand on the concept and offer a mechanism for introducing trace logging with appropriate indentation calculated from the backtrace.

Let me start by saying, I rarely use macros. While effective they are often referred to as a 6' chainsaw, useful when necessary but dangerous more often. I sometimes make an exception when I used them for tracelogging because I want to postpone the evaluation of __FILE__ and the __LINE__ preprocessor directives.

I sometimes define a macro as follows:


#define LOG(S) { std::ostringstream s; s<< S; printf("(%s:%d) %s\n",__FILE__,__LINE__,s.str().c_str()); }


This macro allows us a pretty flexible logging mechanism that includes the file and line number as part of the log entry. A couple simple uses include:


{
LOG("Class01::Method01() entry");
.
.
.
LOG("Class01::Method01() exit");
}




for(int i=0; i<10; ++i)
{
LOG("iteration " << i);
}



Back to the backtrace, a pretty simple implementation follows:


#include <execinfo.h>
int stackDepth()
{
static const int Deep = 1024;
void *array[Deep];
const size_t size = backtrace (array, Deep);
return (size-4);
}


The above function will return the depth of the stack, capp'ed at a depth of 1024. The stack depth can be useful in defining an indentation mechanism to add to our logging:


std::string indent()
{
const int n = stackDepth();
std::string in=std::string(n,' ')+std::string(n,' ');
return in;
}


Revisiting our macro and adding our trace log indentation function gives us a nice logging mechanism that is easier to trace through.




#define LOG(S) { std::ostringstream s; s<< S; printf("%s(%s:%d) %s\n",indent().c_str(),__FILE__,__LINE__,s.str().c_str()); }


That's it, hope you find it useful.

Cheers.

01 July, 2011

Gcc Run-time Stack Trace

Came across this reference that outlines a means to grab a thread stack-trace as part of run-time. Thought it might be useful in the future for logging error handling info.

Example should be compiled with -rdynamic flag;
e.g.
 g++ -rdynamic main.cpp


Cheers.

24 June, 2011

On a number of occasions I found it necessary to locate a list of files by extension (e.g. header/source files) and found that if I needed to locate files of multiple extensions I took the 'cowards way out', executing two 'find' commands and appending the results to a temporary output file, then using the output file as input to the next command in the pipeline (e.g. grep).

I took the time to find the more appropriate method this morning, the ability to execute a find with multiple regular expressions.


find . -type f \( -name "*.c*" -o -name "*.h*" \) -exec grep -l SetEvent {} \;


The above command will locate all header and implementation files (e.g. *.h, *.hpp, *.c, *.cpp...) and return a list of files that contain the SetEvent expression within them. Note the parenthesis are significant to ensure the or'd list is piped to the exec command, otherwise only the second extension list with run through the exec command.

Cheers.

04 February, 2011

Android SDK Upgrade

Well, I've been lagging behind the Android SDK primarily because I didn't want to interrupt my completing my first Android app. I unsuccessfuly attempted to update from v7 to v8 but found that v8 didn't work for Debian at the time and I didn't want to spend the effort resolving.

Fast-forward to today, I updated to v9 and attempted to build my application developed with v7 and immediately was faced with the following error while attempting a build;

user@River:~/AndroidDev/SpinTheBottle$ make clean
ant clean
Buildfile: /home/user/AndroidDev/SpinTheBottle/build.xml

BUILD FAILED
/home/user/AndroidDev/SpinTheBottle/build.xml:46: taskdef class com.android.ant.SetupTask cannot be found
using the classloader AntClassLoader[]

Total time: 0 seconds
make: *** [clean] Error 1


Google advised me that I only needed to update my project by executing the following command;

$ android update project --path ~/AndroidDev/SpinTheBottle


Re-building was then successful.

Cheers.

Simulating Mouse Events

I've been struggling to find a suitable testing method to test the Android applications I'm developing. As I'm relatively new to testing UI's I didn't have much to fall back on.

I first began looking at LDTP, but found that the raw mouse events were limited to click and double-clicking left and right buttons. I needed something more flexible to support swiping the Android Emulator.

What I found was 'xdotool' which seems to hit all the marks; activating a window, depressing either mouse button, moving the mouse, and releasing the button(s). Introducting a delay between mouse down and up allows for long press events.

e.g.

$ xdotool windowactivate `exec xdotool search --title 5554:myAvd`
$ xdotool mouse move 100 100
$ xdotool mousedown 1
$ xdotool mouse move 200 200
$ xdotool mouseup 1

Cheers.