I’ve started uploading my changes to Subversion repository on Sourceforge (https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/branches/ippei/). You can browse with the web interface. Any comment appreciated anytime. If you spotted a mistake, you can point it out for me. If it’s obvious and small one, you could even just fix it on the svn repository (though it doesn’t make sense till later date when I actually start making code work, and you need to be one of hugin project developers in order to commit something anyway).
I told my mentors that I made a lot changes to the directory structure. They let me just through the new structure in, even though it would break all the continuity in files histories etc. I think I’ll have to come back to that step later and reproduce all the file moving with svn command when before merging the changes. It’s gonna be a bit of headache, but it shouldn’t take too long (say, a day or two) once I get used to subversion.
I’m cleaning up the code at the moment. It’s quite hard to clean things up keeping the related code as same as possible. If I change the name of method, it’s likely to affect the entire library. I have to be careful not to break the current code, but still have to do so when necessary. The functions/methods shouldn’t be there if it shouldn’t be there. I’ll see how I can keep the internal dependancy so I need minimum changes to accomplish the clean API. (As oppose to the foundation internal code, the current hugin GUI code can easily adapt the change with some wrapper code with the help of namespace distinction I will make.)
Finally I’ve sorted the Subversion trouble I was having. I just don’t know why, but it got the old proxy setting in subversion’s config and that was stopping svn from working at home. It’s just stupid ’cause I’ve never applied proxy to https for 2 years now. The system setting says apply university proxy to http only when connected with VPN, but that’s it. It’s optional proxy and I don’t apply it for https, but svn must’ve picked it up somehow.
Before start coding, I thought I want to get new directory structure roughly sorted, so that I know where to put what I write. That would help me navigate the headers too. So here they are:
Hugin1/* : Current code base. I’m moving many of implementations to HuginBase keeping the compatibility and legacy APIs (becomes a wrapper in the end).
Foreign/* : copy of codes maintained elsewhere. Vigra, LEVMAR, etc.
- algorithms/ : anything that processes the data
- appbase/ : general application framework like Command and Document
- common/ : utilities, platforms etc.
- huginapp/ : any hugin implementations that are not GUI dependent, like ImageCache and PanoCommands etc.
- jhead/ : extended jhead files for EXIF access
- lensdb/ : PTLensDB interface
- math/ : mathematical functions and classes
- panodata/ : panorama data representation
- panotools/ : PanoTools wrappers (ones currently in PTools namespace)
- vigra_ext/ : image processing extended from Vigra
That leave a few files I haven’t found a place to put:
Anyway, I think I’m going to just start coding now. My way of working on a big project like this is to start with an unorganised way and narrow down the development after going over the rough draft for all components. Probably not recommended in terms of project management, but I found this approach easier when working on a project alone. When I write codes, I’d rather want to forget about debugging and just code. I’d say I’ll finish all the fiddling around with the code by the end of next week, and start debugging after that.
Having had friends coming over on Thursday and didn’t make much progress yesterday, I’d probably better work hard today to catch up. Oops that reminds me of Linguistics course choice and honours project readings planned to do this weekend. I hate having multiple tasks at the same time. I often end up not finishing any…
Last night, I had a long meeting with my mentors over Skype. The first one month of my work is decided to be on the foundation of the application for which I have made the presentation last week. After that will be some 2 weeks to build some sample app that uses this foundation for demo/mockup purpose, and that will be the mid-term evaluation criteria.
Some points were corrected and thus the work got a bit easier. Roughly my work in June will be on:
– Document architecture (3 days)
– Panorama class interfaces (1 day)
– Class interface clean-ups (1 day)
– Command Architecture clean-up and migration (1 day)
– Algorithms clean-up, migration, and capsulation (5 days)
– ImageCache framework migration (1 day)
That’s 12 working days, and + testing and documenting + administration and spare + weekends = 1 month.
Anyway, I started with setting up Subversion on my Mac. Simply it did not work, but somehow works through the university network via VPN (I don’t want to reconnect everytime I need it…). I’m contacting my ISP (Virgin Media). I’m suspecting they’ve put invisible proxy server or something that prevents non-trivial use of https protocol.
Meanwhile I’ve started working on reorganising the directory structure. I’ll work on my project by creating the new interface and copying implementations in the new directory and modifying the relevant old files accordingly to make them merely a wrapper of those new Foundation. I think I’m ready to start coding tomorrow (except that I don’t know how to build stuff; never mind, I have to start with designing anyway, and I can compile simple codes for testing without any build system).
In the evening, I went to the Japanese class with Shoko as she’s going home tomorrow after her exchange program, and I’m taking over the next class (but just a week though, as we are substitute teachers after all).
さて、先週はGoogle Summer of Codeの仕事をはじめて、コード読んだりDesign Patternsと言う有名な本を読んだりいろいろ勉強していました。んで、土曜日にプレゼン。今はちょっと小康状態ですが、また今日これからミーティングでタスクを決めて…と言う感じ。がんばります。
後は昨日に続いてwxMac 2.8のバグ特定をしてました。相変わらずwxMacは人手不足なんでしょうなあ。バグがレポートしても直りません。huginなければそっちでSummer of Codeしても良かったなあ、とも思う。
Well, I worked hard last weekend, so I should deserve a bit of rest. I lazied half day, and went grocery shopping, then took a look at wxMac 2.8.4 just released few weeks ago in the evening.
My mentors have planned a meeting tomorrow evening to discuss the development steps based on the presentation I’ve uploaded on Saturday. That means I’ll get busy. Very, busy.
At the same time, I have contacted my supervisor for next year’s Honours Project (dissertation equivalent), and got some readings based on which I can start thinking about my project in more details (yes, I have submitted a rather vague project proposal trying not to limit the possibilities). I don’t know why it’s available public, but it eventually is, so you can take a look: An Implementation of Grammar-aware Machine Translation Model (or whole list of our projects).
That reminds me that I have to choose next year’s Linguistics modules in two weeks. I have already satisfied the requirements, so any 2 courses would do. Probably ones from Corpus Linguistics, Simulating Language, and Optimality Theory. I wish they are 10 point courses; I want to take more linguistics courses than Informatics ones. Why do Informatics courses sound so boring?
Anyway, back to hugin: I have already been testing wxWidgets 2.8 with hugin 0.6.1 code since 2.8rc1. They have completely switched the wxMac’s graphic engine from now-deprecated QuickDraw to CoreGraphics in 2.8. Whatever the reason for the transition in last minute, this caused a lot of bugs many still haven’t been fixed especially when compiled against 10.3.9 SDK. The 2.8.4 release got certainly better than the previous, but still not ready for releasing hugin with it.
I’ve filed some new bug reports mainly renewing the old ones:
The experimental build is available here:HuginOSX-v061_wx284.zip
I have already made some minor improvements to 0.6.1 code. I’m just waiting for wxMac to get better, then I can release the new build of hugin 0.6.1. Unfortunately no one took the Mac related tasks on wxWidgets project for Google Summer of Code. That means another long wait…
I’ve been making a report on the foundational architecture to-be of new GUI program this week.
It wasn’t terribly good; lazy during the week, worked overnight on Friday, had to give up at 4am on Satuday, completed taking whole afternoon on Saturday. Well, I’ve at least had a chance to go swimming with friends twice this week:)
Anyway, the format of report is a 30-slide presentation, completed with 45 minutes of audio (I have to say it became a very dull presentation…). If you are interested, get a cup of tea, sit back, and have it on. It’s so boring that you should probably take notes on the printed slides in order to keep yourself awake.
Anyway, here it is:
Just a note on workflow of recording presentation:
Keynote – ProfCast – Garageband ~ m4a ~ Quicktime Player ~ mp4
Don’t ask me why Garageband can’t output the movie file like this straight… Oh, m4a file for iPod is available on request as a consequence.