This document provides an overview of the summer projects I have available for Grinnell students and the expectations I have of my summer students.
This page may be found online at
http://www.cs.grinnell.edu/~rebelsky/Department/samr-summer-2011.html
The application guidelines can be found online at
http://www.cs.grinnell.edu/~rebelsky/Department/glimmer-app-2011.pdf.
Contents
In this project, we are exploring scripting, particularly
scripting for the arts. What do we mean by
scripting
? There are clearly many ways in which computer
scientists and computer programmers use the term, such as (1) writing
small programs that handle administrative tasks (the original goal of
Perl); (2) writing programs in PHP that build Web pages or in ECMAScript
to (a.k.a. JavaScript) to make pages interactive; and (3) Visual Basic
scripts used in Microsoft applications. We are focusing on something
similar to the last interpretation, but in a more interactive context.
In particular, we are considering how to support the kinds of small
programs that novices might write in the context of working with a
graphics application.
This project has evolved from some investigations of the applicability of the Scheme programming language (and, more generally, the functional programming paradigm) to a variety of image-based computations that I began in summer 2006. In summer 2007, we began to look at ways to bridge this project with various open-source applications, particularly the GIMP and InkScape, and to support better scripting of these applications in Scheme.
In the 2008-2009 academic year, to deal with deficiencies in the scripting
console in the GIMP, Soren Berg and I built a new user interface for
interactively scripting the GIMP. We've ended up generalizing most of
what we were doing, making the interface support multiple applications
and multiple scripting languages. Hence, the direction of the project
has moved from describing images functionally to investigating how best
to support and encourage interactive scripting of applications.
By interactive
, we mean that the environment should support and
encourage non-programmers to intermingle scripting with their regular
use of the application. (We call the interactive-scripting approach
IAScript and the media-focused version MediaScript.) Many of you have
used this in CSC 151.
There are three directions in which I plan to expand MediaScript this summer. First, and most importantly, I would like to support an idea called self disclosure. Second, I would like to add MediaScript-based scripting to Inkscape, which has changed significantly since 2007. Finally, if the College is able to support enough students, I would like to add support for Python to the GIMP-based MediaScript. I'd also like to build a suite of illustrative examples, based on the homework and projects from CSC 151.
Self-disclosure is a feature of applications in which they disclose
(print out, e.g., to a window) the commands one would use to replicate
an activity intiated by a GUI feature. For example, in GIMP, if I used
the mouse to select a rectangle that ranged from (10,11) to (32,20),
the self-disclosure module might print out
(image-select 1 REPLACE 10 11 22, 9)
A previous set of summer students suggested that self-disclosure in
the GIMP/MediaScheme hybrid would better support novice programmers
and would encourage others to program, since they could record
a series of actions and then make them a procedure. I agree with
them.
Hence, one priority for this summer is building a self-disclosure system. Doing so will require us to delve deeply into the source code of GIMP.
As you may have noted from the poster outside my office, a few years ago, some of my research students added a simple scripting console to Inkscape, an open source vector graphics application. They found that vector graphics provided different, but equally powerful examples for the power of scripting. Unfortunately, the architecture of Inkscape has changed significantly in the past few years. As importantly, they embedded a very simple scripting console and I'd like to see MediaScript's console be added. Hence, I'd like a group to build an Inkscape/MediaScript combination and develop a new set of motivating examples.
While I love Scheme and think it provides an ideal language for scripting, I realize that others prefer other scripting languages. I would like us to explore whether Python might be a reasonable addition for the GIMP/MediaScript combination. (There is a Python interperter in GIMP, but it makes some bad decisions and provides a minimal scripting console.) Students working on this project would also be able to compare the strengths and weaknesses of the functional and object-oriented models for image computing.
One student will build illustrative examples that focus on the original application domains we have been exploring for scripting (raster graphics and vector graphics) and on the Scheme programming language. The other students will provide occasional support for this task.
I expect that the first examples this student will work on will be extensions of our current examples:
This student will consider the core GIMP procedural operations and
consider appropriate ways to wrap
those operations to make them
more usable by novice programmers.
The student will also explore tutorial guides for the GIMP and for InkScape, finding natural ways to turn long sequences of manual actions into scripting commands.
The student will also work on the design of an online repository of illustrative examples. That is, the student will consider ways to present, to tag, and otherwise to provide convenient access to the examples.
Summer students are typically expected to provide some service to a project in addition to their main research. The summer 2011 students will be asked to build three easily-installable ports of MediaScheme, one for Mac OS X (an extension of the version currently used), one for Microsoft Windows, and one for Ubuntu Linux.
Students should expect to do a significant amount of C programming, as IAScript and many open source applications (particularly the GIMP) are implemented in C. In most cases, I will expect MAP applicants to be familiar with C and memory management in C.
IAScript relies on the GTK+2.0 user interface toolkit. It also uses
the GObject objects in C
library. I will not expect students to
be familiar with these libraries, but they will need to learn them.
Scheme remains the core IAScript language. I expect all applicants to
be comfortable with Scheme and with basic higher-order concepts, such
as map.
We use autoconf and automake to manage compilation. I do not expect that students will know these tools before they begin, but they will need to learn them quickly.
We use SVN to manage our code repository, although I may migrate this repository to git. Once again, I do not expect that students will know how to use SVN, but I do expect them to learn quickly.
There will, of course, be other technologies that we use. Particular technologies are likely to depend on the project.
Note that any usable software written in this project will be distributed under an open source model. IAScript and MediaScript have a two-paragraph BSD license, and I expect to continue to use this form.
The spring portion of this schedule mimics the schedule officially approved by the division. However, I will certainly understand if students accept a position with me and then later choose to take a position elsewhere. In that case, I will notify students on my waiting list.
The particular ten weeks we use for summer research are currently under discussion. I would like to start on May 24, but other issues may make that impossible. Hence, the schedule may move back a week.
I have very high expectations of my summer research students. Among other
things, I expect my students to begin their summer
research during
spring semester and continue their summer
research into fall
semester (and sometimes beyond). By applying for summer research you
are agreeing to meet these expectations if I take you on as a research
student. You are unlikely to receive explicit credit or compensation
for work in the spring and fall.
As some students from the past may have reported, I expect my students to be self-reliant. While I do my best to be around, I expect you to be able to do many things on your own or with a small group.
During the summer, you are expected to work full-time on the project (40-50 hours per week for ten weeks). Most of the work will be done in my research laboratory, during normal hours (8/9 to 4/5). The work will include scheduled daily group meetings.
the state of the artin whatever project you've decided to undertake. You should prepare a short survey paper. On the first day of the second week, you will give a public presentation of your work.
I realize that some students may be unavailable in the fall, due to a study-abroad program or similar opportunity. Those students will do what they can of this work (e.g., they might present work in the spring, rather than in the fall).
There are, unfortunately, a number of conflicting issues I must consider
as I choose who to accept for summer research. While one goal is
certainly to enhance my research, summer research also helps students,
the department, and the institution. My approximate MAP priorities are as
follows, although I will certainly take some students from lower
categories before taking every student from a higher
category.
Because women and domestic students of color are under-represented in computer science, I will strive for some equity in the mix of students I select. I hope this will encourage more members of these groups at Grinnell to participate in computer science and, as they go on to successful careers, that they will further encourage others.
In many years, I have imitated the early research experience program in Physics and will reserve a few slots for first-year women and students of color who have expressed an interest in and aptitude for computer science. It is likely that these will be the only first-year students I take for paid positions.
Applicants must meet with me for a fifteen minute interview.
Applicants must prepare responses to
the Glimmer application form, available at
http://www.cs.grinnell.edu/~rebelsky/Department/glimmer-app-2011.pdf.
Applicants must fill out the divisional summer research application,
available at http://www.grinnell.edu/academic/divisions/science/sci-sumres-form. If you feel uncomfortable with the Mollom privacy policy, you
can discuss other options with Doug Peterson in the Science Division Office (
Science 1232).
I am likely to distribute the essays (project description for upper-division students, essay questions for first-year students) from your applications anonymously to a group of trusted advisors. We will each evaluate each person's essay or essays on a 1-4 scale.
After evaluating the various parts of the application, I will score each applicant using something like the sum of the following:
I may discuss applicants with colleagues before and after the interview. While the interview and those discussions are not directly incorporated in the score, they provide additional information.
In the end, I will use both rankings and other information as advisory rather than as absolute determiners of students. For example, a poor interview may disqualify you, no matter how good your overall score is, and I may bump up a person with an excellent interview or who past experience suggests will fit well in my research team. I may also prioritize students with certain skill sets.
