Sorry for this being a little late, but Paul Eggert came and spoke to the UCLA LUG and interested parties this past Wednesday.
Eggert spoke about several things, including how he became involved with free software, his take on the free software community, how to get involved in free software, and projects he thinks would be great to have done.
Eggert mostly became involved with free software as a result of what he calls laziness. Essentially, he got tired of re-patching emacs to work on his (unusual) architecture, so he started submitting patches to Stallman. From there, he just continued submitting patches.
Similarly, Eggert thinks that the best way to get involved in free software is to just start contributing. In order to get noticed, he recommends that people pick “medium-sized” patches; not something small enough that another person could do in 15 minutes, but also not large enough that it makes any major changes. An example of a “medium-sized” project would be patching to take advantage of multi-core systems. Since most programs currently are designed with a single-core architecture in mind, some significant improvements in speed could be obtained by moving it to multi-core. Doing something like this would help to build one’s reputation in the meritocracy of the free software community.
In terms of the future, Eggert thinks that we need new languages to properly take advantage of multi-core. In particular, he mentioned projects like Hadoop are steps in the right direction. Additionally, he thinks that the current shell is too complicated for non-trivial tasks.
Anyway, happy halloween!
The below information is from the UCLA Linux Users Group.
All Engineering students — particularly those in CS — are invited to hear
Professor Paul Eggert speak on Open Source software, how he got involved over
his career, how he has contributed. The GNU Core Utilities project includes
such all-important programs as “ls”, “cp”, “sort”, “echo”, “cat”, and many more.
Wednesday, October 28, 2009
6 PM
Boelter Hall 4760
Details: http://linux.ucla.edu/sean/eggertflyer.pdf
Paul Eggert is a lecturer in the Computer Science department here at UCLA. He
teaches operating systems, programming languages, software development, and
more.
So, I’ve recently converted to using VIm. Textedit irritates me to no end, and I don’t want to pay money for Textmate. I decided I would post my .vimrc file up here and talk about it a little bit. For those who just want to read the file, it’s attached at the bottom of the post. Snippets of code follow, however.
All you VIm users out there know how to search for text – this enables me to search with the space bar, which feels more natural and quicker than having to type a special character.
set nocompatible
set number
set columns=80
set ruler
set background=light
set wrap!
syntax enable
This turns off emulation of bugs from Vi, enables line numbers, restricts my window to 80 columns, displays some basic information about where I am on a line, tells VIm to use fonts optimized for a light background (corresponds with my terminal colors), turns off word wrap, and turns on syntax highlighting. These options are all configured for programming.
set showmatch
set ignorecase
set hlsearch
set incsearch
This is extremely useful for searching in a file. The first line highlights matching braces, which is very nice for nested statements and complex conditionals. It also makes searching case-insensitive, highlights search matches, and starts searching with the first letter that you type. If you pay close attention when searching you only ever have to type the minimum amount of letters to find what you want. I find this greatly speeds up moving through a document.
set autoindent
set smartindent
set tabstop=4
set shiftwidth=4
set expandtab
These settings tell VIm what to do with tabs and indents. The first two lines tell the program to format indents according to the file type. As long as you’re using a C type language, this works extremely well. The second two lines tell VIm to use 4 spaces when the tab key is pressed, and the final line expands all tabs into spaces. This helps remove compatibility problems between tabs and spaces.
This just turns off those pesky beeps when you enter an invalid command. Instead, the screen flashes for an instant. Much nicer in my opinion.
set gfn=BitStream\ Vera\ Sans\ Mono:h14
This sets the default font for the editor – Monaco Size 10. My current favorite programming font on OS X. Anyway, that’s a bit of a discussion about my .vimrc. The full file is below for anyone who wants to read the whole thing or copy/paste it for their own use.
".vimrc
"Author: Eric Hertz
"Date: 10.14.2009
"
"This is a configuration file for VIm, the terminal text editor. Feel free
"to use this however you wish.
"Key mappings
map <space> /
"Interface settings
set nocompatible
set number
set columns=80
set ruler
set background=light
set wrap!
syntax enable
"Search settings
set showmatch
set ignorecase
set hlsearch
set incsearch
"Indent settings
set autoindent
set smartindent
set tabstop=4
set shiftwidth=4
set expandtab
"Audio settings
set vb t_vb=
"Font settings
set gfn=BitStream\ Vera\ Sans\ Mono:h14
Hey all,
My name is Eric, and I’ll be one of your regular authors here on int main(). You’ve probably already read a little bit about me from the post that my friend Sam put up earlier, but I’ll start with a quick introduction and background 
. I’m a second year Computer Science student at the University of California, Los Angeles. I consider myself well-versed in C, C++, and Java, primarily. I also enjoy (if that’s the word) working with assembly on occasion (I’ll post a discussion of some assembly topics later on). Anyway. That’s a little bit about myself. I’d also like to state here that if any of our readers have side projects that they are working on and would like an extra set of eyes or hands, feel free to email. Now that I’ve dispensed with the introductory remarks, let’s dive right into today’s topic.
I feel that as a reader, I would be hesitant to read and trust someone’s opinion on things unless I knew that they actually had some experience with the things that they write about. To that end, I’d like to start this blog by talking about a program that I was a developer on – AudioGuardian. This begs a bit of background information, I’m sure. This project started as part of a competition back in February 2009. I participated in SS12 put on by ProjectPossibility, an organization aiming to make technology more accessible to the disabled community. AudioGuardian was originally named MobileSoundNotifier, and its purpose was to alert hearing-impaired users of hazards in their environment. I will append links to the project’s webpage, the project wiki, and the SVN if any of our readers would like to see some of my “production” code. I quote that because it’s definitely hacked code – this project was completed over the span of approximately 30 hours. From scratch. With that said, here’s the links to the project information:
Project Webpage
Project Wiki
The SVN is linked from the webpage in the bottom right hand corner, if any of you enterprising developers would like to take the project and work on it yourself. It is licensed under the GPL, so keep that in mind. .
I guess you can’t really fork this project without knowing a bit about how we actually designed and developed the program. Coupled with the fact that this is a CS blog and not a self-promotion blog, I will now move into a technical discussion of the program. I’m going to keep this as high-level as possible so it will appeal to all audiences. Let’s get to it.
This application is built using J2ME, which is the Java 2 Mobile Edition. It has most of the capabilities of the full Java language, but it’s missing some key features. It does not support the Swing environment, so we used the built-in J2ME graphics library to build a primitive GUI. The programming paradigm is event-driven, like the majority of Java programs. A control loop listens for commands and acts appropriately. The basic application logic should be simple to follow. But that’s all academic and really not what you’re here for. Let’s get into the problems with working with audio.
The heart of this program is an audio analyzer. It listens to the surrounding environment and throws alerts when it detects sounds deemed dangerous by either us (the programmers) or the user. Those of you with a physics background may have heard of a discrete Fourier transform before. If so, you will know that this is a complex wave analysis algorithm used to translate a signal from the time domain to the frequency domain. This was important for our application because we cannot use the time domain to perform sound matching. The only correlating factors between sound waves are amplitude and frequency, which we have to use a DFT to extract from the data stream. Sounds simple, right? Without looking at any code (you can download the code yourself and look at it, it’s too long to post here), let’s discuss the issues here.
All microphones are not created equal. Every mic has a different sensitivity and different DC offset applied to the raw data stream. This was a problem for us, since we were doing development across different laptops with different microphones. To that end, we decided to build a calibration function that listens to the ambient environment and basically filters the offset and all the outside noise. This also had the unintended side effect of increasing the accuracy of the matching function. It also built cross-compatibility, so our application will work with any microphone out there. The program also had some problems processing data streams in byte array form. The Recorder class in J2ME had a nice little habit of including the file header when it passed the data to a byte array. This then caused garbage to be passed to the graphing function, which caused some serious inaccuracy and lag time in sound recognition. To fix this, we had to strip the file header ourselves. I’ll leave it to the reader to read the code and see exactly what we did.
Other problems we encountered:
The DFT itself was not easy to write. It didn’t help that J2ME was very poorly documented and as such we could not find a standard library. We ended up borrowing an implementation of quicksort from an outside source. It was optimized for use on pairs of data, which was what we were using for matching. Writing this alone took us almost an entire day of work, and then the rest of the time was spent building a GUI and other small features into the program.
One final problem was the issue of data persistence. We wanted to be able to store settings and data across instances of the program. Sounds simple, right? Write the data to a file and restore it when you open the program? Easy enough….until you look at how mobile phones and the J2ME stores data. We ended up using something called a RecordStore, which is actually an object in Java. It has to be opened before it can be used. It is indexed in a very counterintuitive manner – not like a normal array or vector of objects. We essentially ended up taking this RecordStore object and building our own suite of methods to store and access data, because the built-in functionality was not doing what we needed it to do. This took a large amount of time as well, and took brains away from cracking the DFT. All in all, however, we managed to get everything working.
Well, that was long. Hopefully I gave you all a bit of insight into that project, and a bit of perspective on what goes on in developing a mobile phone application when you’ve never done it before. If any of you have questions or would like me to cover something more in-depth, please post a comment or drop us an email. We also appreciate email if there is any topic you’d like us to talk about in general . See you next time.
This isn’t really related directly to anything of importance in terms of CS, but it does relate a fundamental difference in those who program versus those who do not. My suitemate and I are both taking Physics 4AL this quarter, a lab which requires a large amount of calculation. However, it is the same calculation with different masses over and over. Last night, I was fed up with putting it in my calculator over and over again, so I wrote a little program. Presented below is this little program, which calculates the error σ = √( ((mg/(M+m)²)²*&sigma²) + ((M/(M+m)²)²*σ²) ).
:Prompt M
:Prompt W
:0.0001→S
:9.8→G
:√((((W*G)/(M+W)
²)²*S²)+(((((M+W
)*G)-(W*G))/(M+W
)²)²*S²))→X
:Disp "SIGMA",X
