I am a user, developer, and advocate of GNU Octave. I started using Octave around May 2007 while working on my MSEE. I started submitting bugs and patches against Octave in February 2012, mainly to fix some compilation problems I had with the latest release on an older Red Hat Enterprise 5 system I used at work. One thing led to another and I am now a co-maintainer of the Octave project, frequent contributor to both development and discussion, bug triager, tester, etc.
My main areas of interest within the Octave project are
- developing Octave's nascent Python interface
- maintaining the signal processing and communications packages
- maintaining and improving Octave's build system
- aiming for stability and consistency of user experience, portability, particularly to different versions of GNU/Linux and Unix
- encouraging new contributors, mentoring, and helping to build community around Octave
My primary development environment is Debian GNU/Linux, but I occasionally build and test Octave on other distributions and Unices.
I have been a mentor for two very successful projects under the Google Summer of Code program.
I can be found on #octave as mtmx.
My editor of choice is Vim.
Octave Project Ideas
I always have more ideas for projects I would like to work on than I have time for. Please feel free to contact me about any of these ideas, borrow them, work on them, copy them to the projects page, but let me know as a courtesy and in case I have any other thoughts or partial work that might be useful.
- Update the default oct-file template in edit.m to reflect current best practices and recommended coding style.
- Create a complete Vim environment with User:Rik's syntax highlighting rules, indenting, if-end keyword matching, function block jumping, etc.
- Update pygments syntax highlighting for Octave if needed.
- Apply User:Oheim's custom css for the interval package to the communications package manual, or to the Octave core manual.
- Make a static m-file format/style analyzer, a la pep8, that can help users teach themselves GNU Octave style conventions.
- Adapt Debian packaging to operate on a clean hg clone, add build-deps (bison, flex, gperf), build package from any hg revision
- Can this be used to run an automatic build of a "nightly" package on Launchpad?
- Should any of this be applied to the official Debian packaging?
- Query the terminal size directly from the terminal instead of readline as a fallback. Also allow COLUMNS and LINES to override terminal size.
I work under the following profiles on these development sites. These are all related to work I've done with Octave to some degree.