Lab46 Wiki

A quick DATACOMM recap on the EEG project (sde0).

Matt has broken the program down into a series of byte checks for the initial data-check. If nothing fails or bottoms out because of a bad packet or check sum error,

[0001] chksum: 06 msglen: 0005 time_sec: d4 dtype: version   3
ERROR! Checksums do not match! [2b:fe]
Valid: 2        Invalid: 1      Total: 3

the program (read.c) will print out various packet metadata.

[0027] chksum: 06 msglen: 0005 time_sec: 19 dtype: version   3
[0028] chksum: 80 msglen: 0005 time_sec: 19 dtype:  Slice_End
         data: 00 12 d9 93
Valid: 29       Invalid: 0      Total: 29

Finally, I had modified the source to (as requested) print the data type as a string implemented with a series of switch statements.

switch (dtype){
	case 0x00:
	fprintf(stdout," Event");
	break;
 
	case 0x02:
	fprintf(stdout," Slice_End");
	break;
 
	case 0x03:
	fprintf(stdout," Version");
	break;
 
	case 0x80:
	fprintf(stdout," Wave_Form");
	break;
 
	case 0x83:
        fprintf(stdout," Frequincy_Bins");
	break;
 
	case 0x84:
	fprintf(stdout," Signal");
	break;
 
	case 0x8A:
	fprintf(stdout," Time_Stamp");
        break;
 
	case 0x97
        fprintf(stdout," Impedance");
	break;
 
	case 0x9C:
	fprintf(stdout," Bad_Signal");
	break;
 
	case 0x9D:
	fprintf(stdout," Sleep_Stage");
	break;
 
	default:
	fprintf(stdout, "%-9.2x ", dtype);
	break;

The switch statements use the [unsigned char] dtype as subject matter for the switch conditions. Each switch case accounts for all of the different data type values. If not the switch defaults to printing the HEX values as the previous version did.

Hello, Today I will be going over various HPC thoughts regarding the project I have decided to focus on. The lair's library!

First off, I would like to brainstorm or put pen to paper what has been my personal solutions, ideas, and understandings(via Matt's help).

Before I do so, I would like to iterate(for myself) what seems to be the general idea of implementation for this problem. Which in no way should reflect the final implementation/output of this project. Just racking my brain here.

• The library database will be a flat-file containing [book_id][book_title][book_auth][username][date][time]
• The library catalog program(done through shell scripting with whiptail) will be the primary user interface.
• Users will have no need to authenticate because they have already done so via ssh.
• The user will be able to search for books via the catalog and check out once ready.
• The database could indicate who has checked a book out along with time and date if applicable.

Various issues to keep in mind when coming up with a solution to this new lair feature.

• Preventing anomalies in the database from occurring like if two users try to checkout the same book.
• What happens if more then one user is accessing the database script?
• How will reminders be enforced?

Now, to follow up with a report regarding my current findings while trying to conjure up a solution. I have been experimenting with whiptail. I have found the menu option to be very enticing regarding traversing the catalog itself, but also being able to select a book from said menu. Experimenting with whiptail itself has been inspiring, but it's hard to want to lock into one idea as far as creating a user interface goes, because it is hard to turn back from such a decision. I think it may work very well though. I learned a neat things about whiptail's menu when figure out how to intercept a return value regarding the option that was selected in the menu. Whiptail's menu by default returns to stderr. So, for the first time ever I learned how to redirect that kind of output.

--menu "Welcome "$USER 25 50 16 0000 "UNIX SHELL PRGRAMMING"

--menu "Welcome "$USER 25 50 16 0000 "UNIX SHELL PRGRAMMING"2>output

Something just hit me! Why does output have to be a file? Could it be a variable $output.

My next step is attempting to populate that menu with the contents of the flat-file database with a loop, but I have yet to figure out the way to employ a loop that would create multiple parameters for a single call to whiptail. Parsing the information for this should be no issue.

Finally, to end on a optimistic note. Playing around with whiptail has dramatically quenched my thirst for playing with shell scripting. I almost forgot the pleasure of shell scripting, or just being in that powerful shell environment. Where our code can be tested immediately on the fly right on the command line itself. I love it. I'm dramatically shifting my focus to shell scripting, because I have been reminded of the power it holds. Using the shell for a quick solution to a problem is extremely productive. We have so many tools at our disposal it is all right at our finger tips. You may get a fraction of that kind of flexibility and power with a fancy application like an IDE glued to a GUI environment.

I just wanted to close on one more of my findings today. I found a putty alternative called KiTTY. I'm not even sure I can call it an alternative because it is essential the same thing. IT is a fork from putty version .65 which can be downloaded in a handy portable .exe version perfect for the flash drive. Which I find great, and sad at the same time. How is it that the official putty application is so sh*y in comparison to an offshoot. Yet, I presume the offshoot was that of the occurring sh*ty evolution. Then again movie sequels always had a similar reputation… KiTTY, highly recommended for windows users it does everything it is suppose to. I may be exploring other terminal emulators in the future.

Hello again, time seems to be advancing in a rate at which I can't get anything done (diving into a project etc.) Bummer. However, I have gotten the chance to play around with my Kindle, and grease my wheels with some shell scripting. I don't know how this happens, but it seems like I know more than I knew yesterday. Like all that HPC/UNIX stuff is starting to make sense, and the stars are aligning. XD

The Kindle. This is more for the HPC side of things. Brushing up various administrative/reconnaissance commands. Kindle specs! The boring.

uname -a

uname -mrs

Linux 2.6.31 with a armv71 processor.

df -h

Showing a lot of disk space information. Stuff I'm honestly having trouble mentally parsing. It shows a lot of what seems to be mounted filesystems. With a Google search on the specs, I know that the kindle can hold roughly 2Gs of memory.

ps aux

Took a peek at the processes running. Most of it goes over my head. Speaking of ps! I learned that the program had evolved to accept different flavors of UNIX systems flavors of issued arguments to make everyone happy.

• GNU's long arguments preceded with double dashes. - -
• UNIX's short arguments preceded with a single dash. -
• BSD's single stand alone argument. Like aux

So, my next mission with the kindle is installing my favorite packages. Possibly the man library if it's not ungodly huge, screen and much more. Maybe update the coreutils? The issue I'm having is figuring out how to write to the kindle remotely (specifically to root's mounted file-system that is set to read-only). I do have a root home directory, and it is writable. I have also successfully tested binaries that coexist in root's home/bin/ directory. The reason I pursue this is because I could benefit from editing aliases and setting environment variables at login. I did test a shell script (number guessing game) on the kindle, and it worked!I was delighted to have done this. Now I need more tools!

The guessing game!

echo "Guess a number!"
cmp=$((`date|cut -d ' ' -f 4|sed s/://g`%101))
for i in `seq 1 5`
do
read cho
if [ "$cho" -lt "$cmp" ]
then
echo "too low!"
elif [ "$cho" -gt "$cmp" ]
then
echo "too high!"
if [ "$i" -eq "5" -a "$cho" -ne "$cmp" ]
then
echo "game over, you loose!"
echo "I chose $cmp, haha."
fi
else
echo "corect, you win!"
exit 0
fi
done
exit 0

After doing a fair amount of C/C++ programming this year. I gotta say, I love the flexibility coupled with it's strict yet rich syntax. Very fun to write, and very fun to look for new and improved ways of accomplishing a task. With BASH scripting I'm always looking for those sick one liners that get the job done. Something that sums up what could be multiple lines of code in c. Very fun.

Regarding sde0, I decided to advert my eyes back to sde0 project. I am currently working on outputting the sleep stage type. After attempting this I noticed something.

[18410] chksum: a0 msglen: 0005 time_sec: 7c dtype:  Sleep_Stage
sleep: 00 00 00 03

If there are only five possible sleep stages why the need for a multi byte field? Is it for possible expansion? If so, how is it calculated being that we have to read it as little-endian? Is each byte a separate field, or a total(summing the bytes) points to the correct sleep stage. I'm not sure, but it has made me wonder. Should I ignore the other bytes, and only look at the most significant byte? Decisions… Decisions… I know, I'll just ask Matt!

The way I first noticed this is because I would get an output like this after creating a switch statement in the loop where the data block gets outputted.

[18410] chksum: a0 msglen: 0005 time_sec: 7c dtype:  Sleep_Stage
sleep: UndefinedUndefinedUndefinedLight

216 for(i=(msglen-2); i>=0; i--)
217                         {
218                             if (j == 15)
219                             {
220                                 fprintf(stdout, "\n\t       ");
221                                 j = 0;
222                             }
223                             else
224                             {
225                                 j++;
226                                 switch(dtype){
227
228                                 case 0x9D:
229                                     if( *(dblock+i) == 0x00){fprintf(stdout,"Undefined");}
230                                     if( *(dblock+i) == 0x01){fprintf(stdout,"Conscious");}
231                                     if( *(dblock+i) == 0x02){fprintf(stdout,"Rem");}
232                                     if( *(dblock+i) == 0x03){fprintf(stdout,"Light");}
233                                     if( *(dblock+i) == 0x04){fprintf(stdout,"Deep");}
234                                     break;
235
236                                 default:
237                                     fprintf(stdout, "%.2x ", (*(dblock+i)));
238                                 break;
239                                 }
240                             }
241                         }

Of course I first figured I must have inserted my code into the wrong part of the loop, but I wanted to make sure before I made any edits that I fully understood the situation. Hmmm, guess those programming classes at CCC are starting to pay off. :'D

Back to HPC related work! Went to work on the lair-brary.sh script I have been working on. I've decided not to stress over a complete finish product that would be actually implemented. Instead, I would try to tackle the project for better understanding. Which usually results in revisions, reiterations, and reconstruction.

Working with whiptail, I have worked my way around to of the problems I was having.

• Spanning multiple arguments for a single command.
• Returning whiptails error from STDERR to a variable.

However, they were not the solutions I was looking for, but they work. Pretty or not.

For instance, when trying to span multiple arguments for a single command. I wanted(if possible) to use a loop mid command that would iterate more arguments, but I'm starting to think this is not possible. Instead, I formatted a string that whiptail would take using quotes and spaces when appropriate. It worked, but I'm having trouble discarding certain characters without things breaking. So, now I have a moderately ugly output on the whiptail menu under the book title's name that is encased in quotes and underscores that serve as book title spaces. The first part not as annoying, but I'm not sure how my variable string is being interpreted. The second part makes absolutely no sense to me. The output of the variable has been tested many times on the command line to ensure whiptail is receiving the correct input. The problem is either the result of the shell(bad syntax on my part), or whiptail misinterpreting. My guess is the first one. :'D

When returning whiptails argument from STDERR to a variable. I found it easy enough to save to a file(even though I would have killed to get it straight to the variable instead), and then I would cat the file for it's value. After the value had been recorded I would remove the file as if nothing ever happened… But, I still wish there was a nicer way to do this. :)

As a by-product of these headaches. I have already started to rethink of things. Like, how the user can view the catalog and its data that exists on a flat-file! If a user is aloud/able to scroll through said data. Why not present the file to them as is? Save the work of inputing/checking out books, and other services for whiptail. Let the user view the read-only catalog as they wish to see what books are available, and who has checked them out.

I was reunited with sed, and regular expressions. How, I miss how much time one could spend on parsing/formatting data for their needs.

More to come!

This will be a quick update due to running short on time because I have been glued to the library project, and am enjoying every bit of it.

So, I happily made a revision that was a tribute to my previous post stressing how important revisions are. I think things are starting to look like an envisioned output. At least an output I'm happy with to convey my understanding, or application of this whole library checkout thing.

I ran into a few walls here and there, but I made a lot of progress. I now have a presentable user interface with tasteful windows that work (looping back to where they should and not locking user's in which happened me today :p). The main function I'm taking my sweet time with (non-intentional) is the Get A Book feature. Where a user will enter a correct book ID, if the book has not been checked out by another user, and the ID is valid. The user is successfully advanced to a confirmation screen that reminds them to return the book by the end of the semester. The username, and time/date of the checkout is recorded in the same row as the book in the flat-file catalogue. Otherwise, If the book has been checked out you are advanced to a screen that informs you who has the book along with what time/date it was checked out.

I decided it would work smoothly if the ID book field was a four digit hexadecimal value. Therefore this would leave room for roughly a nice 65,000 books, but also be a convenient small number to memorize. The user could search the catalogue maybe greping for a books name. Then all the user needs to do is snag the four digit book ID and punch it into the Get A Book screen.

Sorry this was a frantic and poor entry, but it was a rushed one. I will follow up with more soon.