Carandraug

Somehow I got involved with GNU octave even though I don't actually need it for work anymore. I used it for 6 months during my PhD to write the FRAPINATOR.

GSoC 2013 application

A: An introduction

• Please describe yourself in three sentences, one of them regarding your current studies.

I'm a PhD student in Biochemistry and Bioinformatics.

• Which languages do you speak?

Portuguese (native), english (fluent), and spanish (basic).

• What's your overall background?

Molecular biology.

• Why do you want to participate in the Google Summer of Code? What do you hope to gain by doing so?

• Why are you choosing Octave?

I have been using Octave for 3 years so it's relevant for my studies.

C: Contact

• Please state the (unique and identical where possible) nick you use on IRC and any other communication channel related to Octave.

My registered nick on I'm a frequent user of IRC, with the nick carandraug.

• Which time zone do you live in? Will that change over GSoC duration?

I live on GMT which is very unlikely to change during the summer.

• Please state the timeframe (in UTC+0) when you feel most comfortable working during GSoC. Where are your time buffers?

I usually work between 12:00 to 20:00 and 23:00 to 03:00.

E: Coding experience

This part is one of the more important ones in your application. You are allowed to be as verbose as you want, as long as you stay on topic ;-)

• Please describe your experience with C++, Octave or Matlab m-scripts, OpenGL and Qt.
• Please describe your experience with other programming languages.
• Please describe your experience with being in a development team. Do you have experience working with open source or free projects?
• Please describe the biggest project you have written code for and what you learned by doing so. Also describe your role in that project over time.
• Please state the commits and patches you already contributed to Octave. This question (one of the most important parts by the way) is the only part of your application our wiki admins will edit for you even after the application deadline. Code sometimes speaks louder than many words do.

F: Feeling fine

• Please describe (in short) your experience with the following tools: We only use this question to determine where you need guidance, not for rating! We by no means expect you to be familiar with all of these and you'll won't necessarily need them while working with us.
  • IRC and mailing lists
  • Mercurial or other source code management systems
  • Mediawiki or other wiki software
  • make, gcc, gdb or other development tools
• What will make you actively stay in our community after this GSoC is over? You can also tell us after applications close and we'll happily try to fulfill :-)

O: Only out of interest

• Did you ever hear about Octave before?
  • If so, when and where? How far have you been involved already?
  • If not, where would you expect or advise us to do advertising?
• What was the first question concerning Octave you could not find an answer to rather quickly? Of course more than one question can be stated. We try to improve based on this each year! Includes learning how to use it, code, website, GSoC application, …

P: Prerequisites

• Please state the operating system you work with.
  • If you have access to more than one, please state them and the conditions under which you are granted this access.
• Please estimate an average time per day you will be able to (if separated) access
  • an internet connection
  • a computer
  • a computer with your progressing work on
• Please describe the degree up to which you can install new software on computers you have access to.

S: Self-assessment

• Please describe how useful criticism looks from your point of view as committing student.
• How autonomous are you when developing? If you answer both subquestions with "Yes, definitely", we are a tad confused. ;-)
  • Do you like to discuss changes intensively and not start coding until you know what you want to do?
  • Do you like to code a proof of concept to 'see how it turns out', modifying that and taking the risk of having work thrown away if it doesn't match what the project or original proponent had in mind?

Y: Your task

• Did you select a task from our list of proposals and ideas?
  • If yes, what task did you choose? Please describe what part of it you especially want to focus on if you can already provide this information. Please also wiki-link the page for your elaborated proposal here.
  • If you apply for a task you have added yourself instead, please describe this task, its scope and people you already talked to concerning it. What field of tasks did you miss on the list?
• Please provide a rough estimated timeline for your work on the task. This should include the GSoC midterms and personal commitments like exams or vacation ("non-coding time"). Optionally include two or three milestones you expect.

Octave to do list

You can add stuff to my todo list (I may however move it back to your todo list on your userpage). Don't forget to sign each item with ~~~~

octave code to write =

• make unimplemented check for packages as well
• rewrite inputParser using classdef
  • implement Template:Codeline:@inputParser/StructExpand property on general package
• implement nlinfit as wrapper to leasqr (using inputParser)
• make test and demo deal with tests and demos in .cc packages

I don't like the first option. It's ugly and further pollutes the user namespace. And even if we have some Makefile that copies the .cc file at pkg install time, users won't know they have to make the call to test and demo differently. I guess demo and test functions would have to be modifed for that. I say just place the demos and tests on the .cc file. Later we can change pkg to copy the .cc file, and then change demo and test to look for those files if the function is .oct file. Tests are mainly used in development so users won't need them. Demos... well in the case of ellipj, it has not been working for a very long time so my guess is that people haven't been using it that much. What do you think?

• replacement for morphology toolbox
• port omero toolbox
• use post_install to move oct into private directory?

• import to octave from octave-forge
  • exifread <-- readexif (image) but should probably be implemented in C++ using GraphicsMagick. Actually maybe we shouldn't even bother. Matlab is deprecating it in favour of imfinfo.

octave-forge to do =

• finish iptcheckinput
• get an octave-forge logo (falar com o Duarte)
• finish zenity package
  • for scale see https://savannah.gnu.org/bugs/?33330
• get hough transform function in image package compatible
• look into [SIP] and [sivp]
• from Perl
  • File::Temp
  • check for revision numbers
  • Getopt::Long
• port ReadImageJROI
• make compatible normxcorr2: [Jordi metioned this paper] and
• fix on optim package
  • move test scripts into function test blocks
  • move example scripts into demo blocks

other octave related todo =

• update gtksourceview octave lang file
• make gtksourceview highlight octave help text as texinfo
• make gtksourceview highlight test and demo as octave and not comment