Entries Tagged 'Weekly Summary' ↓

For the start of this week I mostly worked on merging my branch with trunk.  I needed a day or so to get the themes working right and integrate nassar’s vlc changes.  Then it took another day to do the actual merge.  I definitely took too much time to do the merge having files move around in the source tree causes some really weird situations, not to mention running dos2unix.

This week I’ve been working on the aftermath of the merge.  There were a couple bugs, but nothing too serious.  I’ve also been working on finishing up refactoring the platform code.  Linux and portable is done, hopefully I can finish OS X and windows tomorrow.  Then I need to finish refactoring the portable code, hopefully that can be done by the end of the week.  It’s more complicated than the platform code, but at least I don’t have to work with 3 different OSes.

My other work has been thinking about the changes to the database.  Nassar and I talked about it a bunch on IRC today, which was pretty helpful for me.  I want to turn the discussion into a wiki page and write up a reply tomorrow.

This week I wanted to finish up the mac work to create the miro package, but I’ve been basically blocked the entire time. I thought my issues were fixed when I tried a nightly and it worked a while back, but now I realize what the real issue is. When I build the OS X package it breaks, when I run the nightly version it works.

I tried changing several system libraries to fix things, but to no avail. Now I’m doing a binary search of the revisions to see which one broke things for me. Hopefully I can get done with that tomorrow and we can figure out what’s going on.

In the meantime, I merged nassar’s changes in trunk to my branch. I can’t wait to sync these things together.

I also thought a little about the startup time issues and have a thought. What if we implemented a simplified version of the sqlite conversion I proposed a while ago? |I think we could do it the following way:

• We change the way objects are stored in sqlite so that each attribute is stored as a column in the table. However, if any attribute is tricky to convert, we just store it as a blob and pickle the data.
• We remove views one by one, by replacing them with code that offloads the work to sqlite. For almost every view we use, we just iterate through it. So it should be easy to replace those with an SQL query and possibly add an index. For the times we need callbacks, it’s more difficult, but we can probably use the signal code for a lot of them.  There’s very few places where we use callbacks.

The end result should be zero, or at least very few views to calculate on startup and it should help startup times greatly. If we get down to no views, then at that point we can stop holding the object database in memory and save a lot of RAM.

I like this way, because it’s just a bunch of baby steps, but the end result is a big different performance wise. I think at least, we should test how much of startup time calculating the views are, but my guess is it’s a huge chunk of it. And besides, I can’t see many other areas that we can optimize.

In Miro news, I spent the begining of the week fixing issues that have popped up with the new code.  They’re mostly all just little mistakes and are fixed in 10 minutes.  Thanks so much for plugging away and finding them Janet, it’s been awesome.  I fixed the first batch on Thursday, then I’ve been fixing them as they come in.  There’s been about 1-2 a day.

The other big project has been getting my Mac Mini to work, so that I can finish my miro package work on OS X and merge things back to trunk.  It was a very surreal experience visiting the Apple store to diagnose the problem.  Turns out that it was exactly what I expected, the hard drive failed.  I bought an external firewire drive, installed OS X and all the build dependancies and things have been working great.  Better than before actually, because the Mac Mini’s internal hard drive is sooo slow.

Today I started working on the OS X work.  I hope to finish it tomorrow.  My goal is to finish all of the refactoring stuff by next wednesday, I would love it if it works.

In non-Miro news, I’ve fallen in love with degreaser. It took like 10 pounds of gunk off my bike chain, brakes, everywhere.  Who would have guessed that it would help to get grease off of things?

This week’s summary is short and more-or-less sweet.  I worked on moving all the code into a miro package. It went very smoothly on linux, then when I got to windows I had some trouble with getting the installer to work. One way I made it simpler was moving all the platform specific code into a subpackage called miro.platform, which was something I wanted to do anyway.

There was quite a few more build problems on windows after that, but I think I have them all fixed now. I had to change the location of our DLL files, now they all are stored in the root windows directory, instead of some of them being in xulrunner/python.

OSX is going to be more of a challenge, not because the code is difficult but because my mac mini is not operational right now. I have a appointment at the apple store tomorrow, hopefully it can be fixed then.

This week started similarly to last week in that I was just spinning my wheels trying to get an OS X build to work. I tried various fixes to no avail. I was getting fairly depressed, so I decided to just start doing a binary search to see what revision number broke things. I got a little ways into it, then figured out that things got fixed somewhere between the revision I checked out and the current trunk.

After that I was able to get a bunch of work done on the frontend-backend separation project. It’s been forever since I’ve done anything with it. I’d like to merge my branch back into trunk pretty soon, let’s talk on the call about what a good strategy is for this. I’ve been merging from trunk periodically, so I think merging back should be pretty easy. I want to make sure I don’t mess with the work to merge trunk into the 1.0 branch though.

Also, tell me what you think about this refactoring idea I’ve been thinking about. One problem we’ve had for a while is that there are a bunch of circular module imports and if you import things in the wrong order it breaks. This is especially true with app.py. app depends on basically everything and everything depends on app. I’m trying to move a lot of frontend-specific code out of app and it’s been a real hassle.

After thinking a bunch about the problem, I came to the conclusion that the app module is handling 2 roles.  The obvious role is defining the Controller class and a couple other classes. However, it’s other role is to provide singleton objects to the rest of the code (app.db, app.controller, app.delegate, etc).

So here’s the idea: we remove all the code from app.py and put it into a module called “controller” or something. However, we keep app.py around and it’s role becomes holding all our singleton objects. This way, any module can access app.controller, app.db, app.delegate, etc. without having to worry about import dependencies. The singletons would be created early on in the startup code. frontend code could also add objects if it wanted.

There’s still the issue of circular dependencies when creating the objects. For example, if the Controller class gets created after the Database class, it won’t be able to access app.db from it’s __init__ method. But this way, at least the order will be explicitly spelled out in the code and we only have to worry during the constructors.

It feels good to be writing code again, thank you mistery coder who fixed by OS X build!

It’s been pretty frustrating trying to get things working on the OS X side.  I found out that my problem was that I have OS X 10.4.11, which is one version too high.  Apparently the only way to fix things is to find an install CD and reinstall the OS from scratch, but the CD for that mac mini is lost in PCF’s closet.  NPR purchased an apple developer connection account, but I haven’t been able to find an image from that site either.  Very frustrating.

Today I decided to give up waiting and I went on with my frontend-backend work.  I’m a little worried that OS X is going to be left behind, but I’m pretty much hitting a brick wall there.  Hopefully we can figure out a solution to this problem soon, maybe on the call?

This week I started by finishing up the startup refactoring on windows.  It went quite smooth now that I’ve given up doing things the “right” way and just did them the way we did them before.  Then I went over to OS X and banged my head against a wall trying to get Miro to build for me.

While I was waiting for that to get working I moved back to windows and did some libtorrent stuff in trunk.  I fixed a stupid bug that was preventing any torrent stuff from working, then I added the new prefs to the preference panels.  I got into talking with npr about the text on our preference windows and translations and we updated a bunch of it.

This week my first priority is to get things building again, both for me on OS X and for others on windows.  Seems like build problems are blocking a lot of people from getting work done.

This week was basically a U-Turn from me. We decided to push for a quick 1.0 release, so I moved away from doing post 1.0 stuff to fixing bugs. The biggest change was handling deleting files. Now there’s code that retries the deletes if the first one had a permissions error, very similar to how we do the moves. This handles the case when you try to delete a file that VLC has open, which was fairly common. The worst thing about the behavior before was that we would then scan the movies directory and mark it as a new file, so the user would have to delete twice.

The other main bug I fixed was with the movie data utility. I needed to mess with the install scripts to get it to work.

Today I switched back to post 1.0 stuff. I got linux working with my new startup code and went to windows. Our build situation on windows is kind of a mess right now because of libtorrent. I’d like to get this figured out as soon as possible, let’s talk about it on the call.

Oh yeah, we released a little thing called one-point-oh today. That’s pretty awesome. It didn’t feel all that special to me, compared to how much effort has gone into it. I’m mostly just happy to be free from small bug fixing mode. I did eat a bagel to celebrate, but it was no bagel-time bagel — just a crappy supermarket thing. So dissapointing.

(okay, I guess if I’m going to be a blogger I need to whip up some funny titles that have little to do with the actual article.  Today is the new start.  Really, I wish ever one was titled “I like burritios”.)

I started this week mostly working on frontend-backend stuff.  I think it’s going fairly well, although I did run into the unfortunate problem with the missing movies directory that I talked about on the list.  It doesn’t seem to be that big of a deal, although it means that we have to think a little about things if we want a backend that’s completely independent of any frontends.  Other than that I created a branch to work on updating the startup code, but I never got to check anything in.

I would have probably had linux finished today, but I got side tracked by 2 issues.  The first issue was talking with nassar about GTK widget details.  It got into a bigger discussion about how we want to deal with native widgets, when so much of our interface is custom widgets (we have link 5 different buttons right now).  Maybe we should talk about this on the call, since it seems like a pretty important discussion.

The other one is that we’re pushing for a 1.0 release, so I need to get working on my pile of bugs.  I fixed one pretty annoying one today, how to stop the movie data utility from causing crash reports.  I checked around a bunch and found out that windows has support for handling segfaults by using a _try, _except block.  I wrapped the movie data utility in that and it seems to prevent them.

This means that the movie data utility is pretty weird conglomeration of wrappers now.  In order to implement the _try, _except block I needed to make a C program that called our old python module.  Of course that old python module uses ctypes to call into the C interface for VLC so we come full circle again.  I looked into making the implementation straight C, but I figured it’s not really worth my time figuring out linker details and just did the double wrap.

I still have a bunch of other bugs on my plate.  Theres a bunch like #9099 that are just random segfaults in python.  I think we’re going to have to give up on tracking them down for 1.0, but maybe I’ll have some success with them in the next few days.

I’m pretty excited this week because I finally got started on the frontend-backend stuff (you might have guess by my spam on the devel list). It’s been going as well as can be expected. I created a frontends.html
package and have been moving code in there piece by piece. So far I’ve moved the logging code, shutdown code, context menus, and started on the auto-update code.

I’m not exactly following the plan that I put on the wiki, because I often start trying to refactor one thing and realize that it depends on another. But things seem to be chugging along. There is probably more things that need to be moved than I expected, but each task has been easier than I planned for.

I spent a bunch of time with last minute 0.9.9.9.9.9.9 bugs. Those took a good chunk of my time, probably half or so. Hopefully next week will be 100% refactoring.

In my spare time I’ve been doing some web work and I really want to release the sqlhelper code I wrote for the channel guide, since I’m using it in this other project. That brings up the topic of releasing the channel
guide code too. If we have time can we discuss these things on the dev cal? It’s definitely lower priority than 0.9.9.9 stuff though.