" /> Status for Andrew DeFaria: September 9, 2007 - September 15, 2007 Archives

« September 2, 2007 - September 8, 2007 | Main | September 16, 2007 - September 22, 2007 »

September 14, 2007

ucmwb 1.2.3 release/Perl'isms

  • Released ucmwb 1.2.3

FindBin, Getopt::Long and Display.pm

Here's how I typically use FindBin:

use FindBin;
...
use lib "$FindBin::Bin/../lib";
...
sub Usage ($) {
  my ($msg) = @_;

  display "ERROR: $msg\n" if defined $msg;
  display <<END;
Usage: $FindBin::Script [-usage] [-verbose] [-debug] [-exec]
		-from_view <view> -label <label_name>
...
END

Also I tend to use Getopt::Long. It is extremely flexible. Options can be specified in the GNU long method as in --debug or just -debug. Additionally you can abbreviate as in -d IFF there is no other option that starts with "d". Options can have parameters (-file myfile.txt or -file=myfile.txt), set boolean (-verbose can set say $verbose), automatic negation (-verbose or -noverbose), even call subroutines directly!k Here's an example.

use GetOpt::Long;
...
my $execute	= 0;
my $from_view;	# e.g. p6258c_RAN_FDD_Doc_Bld1_int
my $branch;	# e.g. ran_fdd_release_build2_integration
my $label;	# e.g. RAN_FDD_RELEASE_BUILD1

GetOptions (
  "usage"	=> sub { Usage "" },
  "verbose"	=> sub { set_verbose },
  "debug"	=> sub { set_debug },
  "exec!"	=> \$execute,
  "from_view=s"	=> \$from_view,
  "branch=s"	=> \$branch,
  "label=s"	=> \$label,
) || Usage "Unknown parameter";

Some notes about the above:

  • Usage is a subroutine (most people have one) that takes one parameter for an extra message to display first.
  • Eat your own dog food! I use my Display module which has display routines for verbose and debug, etc. It also has $verbose and $debug variables and exports the set_verbose and set_debug methods.
  • The "exec!" is a negation. So -exec and -noexec apply and set $execute accordingly
  • All of "from_view", "branch" and "label" are simple name/value type parameters so -branch <branchname> sets $branch to <branchname>.

A word on Display.pm:

I find that often people do the following:

print "In myspecial_subroutine: File = $file\n" if $debug;

for debugging. To me it's always been a hassle to have to remember to include the "\b" and the "if $debug", etc. Granted that's not a lot. But how can I make it better?

My thought was to name the procedure debug and include the "\n" by default. People oughta quickly discern that:

debug "In myspecial_subroutine: File = $file";

probably only happens when debugging.

Additionally I support routines like verbose, debug, error, warning (from Display.pm).

September 13, 2007

UCMWB su bug

  • Fixed an issue with ucmwb running after su'ed to another user
  • Addressed some issues about PC running CC in the RAN network

Stupid coding

It never ceases to amaze me what some programmers do that when I look at it seem to be just foolish things. Here's today's example:

In ucmwb a bug was discovered when a user first su's to some other user then runs ucmwb (in this case the user is su'ing to ccadm). The while the main window dutifully displays the list of WORs for the su'ed user, the view browser does not. Instead it displays the list of views for the original user. Turns out that there was specific code for Solaris to call cuserid instead of getenv("USER"). So Linux was working but Solaris failed. Why the difference?

But along with that I noticed the following code:

    QSting homePath = QDir::homePath();

    if (homePath.isEmpty()) {
      qDebug() << "homePath is empty!";
      // Note the following is a Unix'ism and non portable!
      homePath = QString("/home/") + appUsername;
    }

    qDebug() << "homePath = " << homePath;
    QString settingsFilename = QDir::homePath() + QString("/.ucmwbrc");
    QString settingsDirname  = QDir::homePath() + QString("/.ucmwb.d");
    QString filterFilename   = settingsDirname + QString("/filters");

OK so first ask yourself what do you see wrong here.....?

Pencils down!

Here's my questions:

  1. Why go through the effort of getting the user's homePath, check to see if it's empty and then compose one with "/home" + appUsername only then to totally ignore all that work and get it again for settingsFilename?
  2. Why then do this operation of obtaining homePath yet again to set settingsDirname?
  3. If homePath were determined to be empty, aren't you ignoring what you set it to?

Naturally I fixed this to be:

    QSting homePath = QDir::homePath();

    if (homePath.isEmpty()) {
      // Note the following is a Unix'ism and non portable!
      homePath = QString("/home/") + appUsername;
    }

    QString settingsFilename = homePath + QString("/.ucmwbrc");
    QString settingsDirname  = homePath + QString("/.ucmwb.d");
    QString filterFilename   = settingsDirname + QString("/filters");

September 12, 2007

UCMWB/Document Visibility

  • Fixed a few problems with UCMWB's help facility. Previously help didn't work at all on Linux. Now it works and About identifies the proper version numbers and which architecture.
  • Created baselines for the documentation visibility WORs

September 11, 2007

Import.pl

  • Performed merge for build 1-> build 2 and build 2 -> build 3
  • Resolved RoseRT issue
  • Code reviewed Tom's changes to createView.pl

RANCQ00013181: MUOS document Project Views Are not Showing All Needed Documents

Process was written to perform this importation. The process takes 3 parameters: a from_view, a branch and a label. The process is designed to run in the to_view context. It proceeds to search the from_view for elements that do not exist in the to_view and upon finding them it merges the parent directory and then the element in question is "imported".

Both a branch and a label is used because the merge procedure used on directory elements first tries to merge with the LATEST on the specified branch. If the branch does not exist (because the element was never branched) then the label is used to locate the source directory for the merge.

File elements aren't merged - they are imported (i.e. copied from the from_view to the to_view)

There are a few errors and/or warnings that can result in such a process that this script cannot hueristically determine the correct action to take. The problems arise from the renaming or removing of elements in the to_view. It is not possible for this script to determine what the user intended. An example will better explain this.

For build 1 there was a directory named:

/vobs/gdrandocs/development/proj/ran/fdd/RNC_Initialization_Configuration

This was on the ran_fdd_doc_bld1_integration branch version 2 which was labled RAN_FDD_RELEASE_BUILD1. At version 17 RNC_Intitialization_Configuration was renamed to RBS_RNC_Intitialization_Configuration. By version 28 the RAN_FDD_RELEASE_BUILD2 label was applied.

Since this directory was renamed there is no way to guess what it was renamed to. Sure it's easy for a human to look at it and make a loose association based on the fact that most of the directory name is the same, this sort of AI is very difficult to program. The script marks these as an error. It's an error because somebody should verify if a directory was simply renamed or if it was removed (rmname'd). Also it's not known what to do at this point. Shall we assume that the newly named directory contains all it needs? Or does further merging/importing need to take place?

Additionally, since a directory is renamed, the elements contained in the directory went along with it. So in the script, the from_view keeps producing paths with RNC_Intitialization_Configuration in them not RBS_RNC_Intitialization_Configuration. Such elements then appear to have disappeared and the script issues a warning for these. At this point we really cannot tell if the file element was simply removed (where we would assume that the act was deliberate and that we should not be importing the element back in) or if it's a result of a directory renaming of the parent directory (or some parent of the parent) thus falling into the error described in the preceeding paragraph.

September 10, 2007

Building Qt/UCMWB officially

  • Got the license key for Qt, 4.2.3 this time, so I'm building it again, officially
  • Rebuilding ucmwb with debug turned off
  • Fixed problem with backspace not working in vim

Backspace and vim

Annoyingly backspace continues to be a problem, especially with Sun. Here's the fix for vim (put in ~/.vimrc):

set t_kb=^h
fixdel

Note: That's a Control-V [backspace] to produce ^h.