Archive for Programming

A look at Emacs

It’s amazing what work can bring your way in terms of technology. For me, (GNU) Emacs Has proved to be such a thing recently. It may have been around since 1975, long before my adventures in computing ever started in fact, but I am asking myself why I never really have used it much. There are vague recollections of my being aware of its existence in the early days of my using UNIX over a decade ago. Was it a shortcut card with loads of seemingly esoteric keyboard shortcuts and commands that put me off it back then? The truth may have been that I got bedazzled with the world of Microsoft Windows instead and so began a distraction that lingered until very recently. As unlikely as it looks now, Word and Office would have been part of the allure of what some consider as the dark side these days. O how OpenOffice.org and their ilk have changed that state of affairs…

The unfortunate part of the Emacs story might be that its innovations were never taken up as conventions by mainstream computing. If its counterparts elsewhere used the same keyboard shortcuts, it would feel like learning such an unfamiliar tool. Still, it’s not as if there isn’t logic behind it because it will work both in a terminal session (where I may have met it for the first time) and a desktop application GUI. The latter is the easier to learn and the menus list equivalent keyboard shortcuts for many of their entries too. For a fuller experience though, I can recommend the online manual and you can buy it in paper form too if you prefer.

One thing that I discovered recently is that external factors can sour the impressions of a piece of software.For instance, I was using a UNIX session where the keyboard mapping weren’t optimal. There’s nothing like unfamiliar behaviour for throwing you off track because you felt your usual habits were being obstructed. For instance, finding that a Backspace key is behaving like a Delete one is such an obstruction. It wasn’t the fault of Emacs and I have found that using Ctrl+K (C-k in the documentation) to delete whole lines is invaluable.

Apart from keyboard mapping niggles, Emacs has to be respected as a powerful piece of software in its own right. It may not have the syntax highlighting capabilities of some, like gedit or NEdit for instance, but I have a hunch that a spot of Lisp programming would address that need. What you get instead is support for version control systems like RCS or CVS along with integration with GDB for debugging programs written in a number of languages. Then, there are features like file management, email handling, newsgroup browsing, a calendar and calculator that make you wonder if they tried to turn a text editor into something like an operating system. With Google trying to use Chrome as the basis of one, it almost feels as is Emacs was ahead of its time though that may have been more due to its needing work within a UNIX shell in those far-off pre-GUI days. It really is saying something that it has stood the test of time when so much has fallen by the wayside. Like Vi, it looks as if the esteemable piece of software is showing no signs of going away just yet. Maybe it was well designed in the beginning and the thing certainly seems more than a text editor with its extras. Well, it has offer a good reason for making its way into Linux too…

ERROR 22-322: Syntax error, expecting one of the following: a name, *.

This is one of the classic SAS errors that you can get from PROC SQL and it can be thrown by a number of things. Missing out a comma in a list of variables on a SELECT statement is one situation that will do it, as will having an extraneous one. As I discovered recently, an ill-defined SAS function nesting like LEFT(TRIM(PERIOD,BEST.)) will have the same effect; notice the missing PUT function in the example. The latter surprised me because I might have expected something more descriptive for this as would be the case in data step code. In the event, it took some looking before the problem hit me because it’s amazing how blind you can become to things that are staring you in the face. Familiarity really can make you pay less attention.

ERROR: Invalid value for width specified – width out of range

This could be the beginning of a series on error messages from PROC SQL that may appear unclear to a programmer more familiar with Data Step. The cause of my getting the message that heads this posting is that there was a numeric variable with a length less that the default of 8, not the best of situations. Sadly, the message doesn’t pin point the affected variable so it took some commenting out of pieces of code before I found the cause of the problem. That’s never to say that PROC SQL does not have debugging functionality in the form of FEEDBACK, NOEXEC, _METHOD and _TREE options on the PROC SQL line itself or the validation statement but neither of these seemed to help in this instance. Still, they’re worth keeping in mind for the future as is SAS Institute’s own page on SQL query debugging. Of course, now that I know what might be the cause, a simple PROC SQL report using the dictionary tables should help. The following code should do the needful:

proc sql;
select memname, name, type, length from dictionary.columns where libname=”DATA” and type=”num” and length ne 8;
quit;

Reading data into SAS using the EXCEL and PCFILES library engines

Recently, I had the opportunity to have a look at the Excel library engine again because I need to read Excel data into SAS. You need SAS Access for PC Files licensed for it to but it does simplify the process of getting data from spreadsheets into SAS. It all revolves around setting up a library pointing at the Excel file using the Excel engine. The result is that every worksheet in the file is treated like a SAS dataset even if there names contain characters that SAS considers invalid for dataset names. The way around that is to enclose the worksheet name in single quotes with the letter n straight after the closing quote, much in the same way as you’d read in text strings as SAS date values (’04MAR2010′d, for example). In order to make all of this more, I have added some example code below.

libname testxl excel ‘c:\test.xls’;

data test;
set testxl.’sheet1$’n;
run;

All of the above does apply to SAS on Windows (I have used it successfully in 9.1.3 and 9.2) but there seems to be a way of using the same type of thing on UNIX too. Again, SAS Access for PC Files is needed as well as a SAS PC Files server on an available Windows machine and it is the PCFILES engine that is specified. While I cannot say that I have had the chance to see it working in practice but seeing it described in SAS Online Documentation corrected my previous misimpressions about the UNIX variant of SAS and its ability to read in Excel or Access data. Well, you learn something new every day.

A few more SAS functions to know

There are whole pile of SAS functions for testing text strings that hadn’t come to my attention until this week. Until then, I’d have gone about using functions like INDEX and PRXMATCH functions for the same sort of ends but it’s never any load to have a few different ways of doing things and to use the right one for the job. Here’s a quick list of my recent discoveries:

ANYALNUM: First position of any alphanumeric character, returns 0 if absent

ANYALPHA: First position of any alphabetic character (letter of the alphabet), returns 0 if absent

ANYCNTRL: First position of any control character, returns 0 if absent

ANYDIGIT: First position of any numeric character, returns 0 if absent

ANYFIRST: First position of any character that can be used as the start of a SAS variable name when VALIDVARNAME is set to V7, returns 0 if absent

ANYGRAPH: First position of any printable character that isn’t white space, returns 0 if absent

ANYLOWER: First position of any lowercase letter, returns 0 if absent

ANYNAME: First position of any character that can be used in a SAS variable name when VALIDVARNAME is set to V7, returns 0 if absent

ANYPRINT: First position of any printable character, returns 0 if absent

ANYPUNCT: First position of any punctuation character, returns 0 if absent

ANYSPACE: First position of any whitespace character (tabs, carriage returns and the like), returns 0 if absent

ANYUPPER: First position of any uppercase letter, returns 0 if absent

ANYXDIGIT: First position of any hexadecimal character, returns 0 if absent

NOTALNUM: First position of any non-alphanumeric character, returns 0 if absent

NOTALPHA: First position of any non-alphabetic character, returns 0 if absent

NOTCNTRL: First position of anything that isn’t a control character, returns 0 if absent

NOTDIGIT: First position of any non-numeric character, returns 0 if absent

NOTFIRST: First position of any character that cannot be used as the start of a SAS variable name when VALIDVARNAME is set to V7, returns 0 if absent

NOTGRAPH: First position of anything that isn’t a printable character that isn’t white space, returns 0 if absent

NOTLOWER: First position of anything that isn’t a lowercase letter, returns 0 if absent

NOTNAME: First position of any character that cannot be used in a SAS variable name when VALIDVARNAME is set to V7, returns 0 if absent

NOTPRINT: First position of any non-printable character, returns 0 if absent

NOTPUNCT: First position of anything that isn’t a punctuation character, returns 0 if absent

NOTSPACE: First position of anything that isn’t a whitespace character, returns 0 if absent

NOTUPPER: First position of anything that isn’t an uppercase letter, returns 0 if absent

NOTXDIGIT: First position of anything that isn’t a hexadecimal character, returns 0 if absent

Apart from simpler cases where other techniques would work well with the a similar amount of effort, there are others that would need some investigation if you were program them without using one of the above functions. For that reason, I’ll be keeping them in mind for when I might meet one of those more complex scenarios.

%sysfunc and missing spaces

Recently, I was trying something like this and noted some odd behaviour:

data _null_;
file fileref;
put “text %sysfunc(pathname(work)) more text”;
run;

This is the kind of thing that I was getting:

text c:\sasworkmore text

In other words, the space after %sysfunc was being ignored and, since I was creating and executing a Windows batch file using SAS 8.2, the command line action wasn’t doing what was expected. The fix was simple but I reckoned that I’d share what I saw anyway, in case it helped anyone else:

data _null_;
file fileref;
x=”text %sysfunc(pathname(work))”||” more text”;
put x;
run;

  • As is commonly the case with places like these, all the views that you find expressed on here in postings and articles are mine alone and not those of any organisation with which I have any association, through work or otherwise. With regards to any comments left on the site, I reserve the right to reject any that are inappropriate. Otherwise, whatever is said is the sole responsibility of whoever is leaving the comment.