So it looks like i finally on the heels of some success, except now I'm running into some issues with threading. It's very frustrating to actually see a UI and seeing most of the stuff being populated but still not close enough. Additionally, I seem to have some regression on searching for unique entries based on location. No doubt due to the fact that I probably have triggered it while fooling around with sqlite commands in the code.
At the moment, performance is pretty bad. I will have to switch to transactions to actually get some speed ups. Once i do that I had some good advice from a firefox developer about how best to tune sqlite. The experiment was pretty good idea, it's quite more complicated than it seems. Especially when dealing with the database itself. I will continue to make this into a good patch that i can submit to bugzilla. i will try to convince people to try it out and help at least get better tuning.
Monday, August 11, 2008
Sunday, July 27, 2008
Progress..
It's the end of the week and it's time to report on my progress so far. Been very distracted with OSCON and other events so I haven't been hacking the late night oil like I usually do. Hacking seems to be a night time activity for me and I'm having sleep issues with it seems to really put a damper on things. Any hoo, enough of the whining.
I have the hard parts of the project done, that is the searching and adding songs to the database. It's not bullet proof and I suspect I have a lot of memory leaks but I was able to successfully had a song to the database and emit an add signal to the ui which is a pretty good milestone. Adding the rest of the interface is going to be pretty trivial since it essentially uses the query and insert systems that I have already implemented.
There are some issues that I will have to correct including the aforementioned memory leaks, but there is also a notion of what kind of entry is being added to the database so that it can be used for not only songs, but radio streams and what not.
sri
I have the hard parts of the project done, that is the searching and adding songs to the database. It's not bullet proof and I suspect I have a lot of memory leaks but I was able to successfully had a song to the database and emit an add signal to the ui which is a pretty good milestone. Adding the rest of the interface is going to be pretty trivial since it essentially uses the query and insert systems that I have already implemented.
There are some issues that I will have to correct including the aforementioned memory leaks, but there is also a notion of what kind of entry is being added to the database so that it can be used for not only songs, but radio streams and what not.
sri
Wednesday, July 9, 2008
Milestones and the like.
I have spent a better part of the week and last week trying to understand GObject and the Glib type system which GTK+ and GNOME programs are based on. A bit challenging to understand since it involves some strong C fu to understand.
So what I've done so far is to create the constructor to making the new database, and then I will continue to start implementing the rest of the interfaces as defined by the application as what it expects from the database backend. There will be a lot of learning along the way.
I have talked with rhythmbox folks and while they aren't enthusiastic about the backend (they don't believe it will solve the speed problem). Both backends are "text" based since sqlite stores it's backend as a comma delineated file and the other one is xml based. There is nothing wrong with the current backend. Moving to an sqlite database gives you some small level of scalability, thread safety, and it simplifies the backend a lot since you're not implementing a database. Plus the pool of knowledge around sqlite is certainly going to be greater than the sum of knowledge for the rhythmdb xml database and thus adding extensions will prove easier due to good documentation on sqlite3. I don't expect the backend to be default or a patch to be expected. I'm doing it to learn and really that's all that is important.
However, one good thing is that rhythmbox will at least get some unit tests as in order to test the backend I need to be able to write something that only uses the rhythmdb object and implement simple tests to make sure things are working. That will probably be the first milestone since I can't really test the constructor or anything else until I have gotten this part working.
Milestone 1: implement the constructor and be able to load the database. Create a unit test program to test the constructor and the loading to make sure it is getting populated.
Milestone 2: implement the deleting the database, and the deconstructor and then update the unit test program to test the deconstructor. Additionally, start implementing the query interfaces. The query interface will probably the hardest part of the whole project.
Milestone 3: start hooking the parts to the main application and then see how things go from there. Hopefully things will start working. There will be issues with making sure that we can cancel operations or interrupt operations when we get to this stage. I would call it done at this point if we can get most of this working.
Milestone 4: If I have time, I will start adding the tagging feature to the database and then start working on hooking that up with a plausible GUI. Which will be awhile.
So what I've done so far is to create the constructor to making the new database, and then I will continue to start implementing the rest of the interfaces as defined by the application as what it expects from the database backend. There will be a lot of learning along the way.
I have talked with rhythmbox folks and while they aren't enthusiastic about the backend (they don't believe it will solve the speed problem). Both backends are "text" based since sqlite stores it's backend as a comma delineated file and the other one is xml based. There is nothing wrong with the current backend. Moving to an sqlite database gives you some small level of scalability, thread safety, and it simplifies the backend a lot since you're not implementing a database. Plus the pool of knowledge around sqlite is certainly going to be greater than the sum of knowledge for the rhythmdb xml database and thus adding extensions will prove easier due to good documentation on sqlite3. I don't expect the backend to be default or a patch to be expected. I'm doing it to learn and really that's all that is important.
However, one good thing is that rhythmbox will at least get some unit tests as in order to test the backend I need to be able to write something that only uses the rhythmdb object and implement simple tests to make sure things are working. That will probably be the first milestone since I can't really test the constructor or anything else until I have gotten this part working.
Milestone 1: implement the constructor and be able to load the database. Create a unit test program to test the constructor and the loading to make sure it is getting populated.
Milestone 2: implement the deleting the database, and the deconstructor and then update the unit test program to test the deconstructor. Additionally, start implementing the query interfaces. The query interface will probably the hardest part of the whole project.
Milestone 3: start hooking the parts to the main application and then see how things go from there. Hopefully things will start working. There will be issues with making sure that we can cancel operations or interrupt operations when we get to this stage. I would call it done at this point if we can get most of this working.
Milestone 4: If I have time, I will start adding the tagging feature to the database and then start working on hooking that up with a plausible GUI. Which will be awhile.
Wednesday, July 2, 2008
Some progress being made.. but god autoconf sucks..
Well, I've made some progress on my rhythmbox-sqlite (rhythmbox with a sqlite backend). Mostly, I've made sure that the database abstraction is still pristine that there isn't any dependencies which requires the internal database explicitly. That would make things complicated. It should be fairly straight forward. The way it works is that we have a database "object" gobject rather that has a set of interfaces. I just have to code the interfaces and whatever helper functions required to do it.
Moving to sqlite should help rhythmbox become a lot more scalable as the database gets larger. Currently it uses a xml database with various tags. I've already figured out what the database parts are and have created a sample database although what might be a good idea is to code up somethign quick that converts from what database to another. Or just work on getting the import part of the database working properly.
So far, I've put in stub code for all the interfaces, and I have spent a couple of hours today trying to understand automake/autoconf and getting the new backend as a configure option. Autconf isn't perfect it definitely has some issues, but overall I found it easier to understand than say CMake which really freaking sucks. I tried to use that at work as way of distributing a turnkey software solution. The documentation left me cold, it's just really hard to understand it and there just isn't a lot of documentation out on the Net unlike auto* tools. KDE also seems to have had problems and nobody really has anything good to say about it. GNOME is still trying to figure out what it wants out of a build system. They've been thinking of using WAF but the maintainer hasn't been particularly cooperative. Perhaps with some modification it might be good. I'm not planning on using WAF as of yet. Maybe in another project at work.
Anyways, I'm hoping that I can at least start getting import finished by the end of the week. I need to define some milestones which I wlil do in the next blog entry. Import is definitely at the top of the list and getting a little more familiar with the backend database. The main goal is to finish the sqlite database backend. If I have time I will start adding tags and then comes the really really fun part, the UI.
sri
Moving to sqlite should help rhythmbox become a lot more scalable as the database gets larger. Currently it uses a xml database with various tags. I've already figured out what the database parts are and have created a sample database although what might be a good idea is to code up somethign quick that converts from what database to another. Or just work on getting the import part of the database working properly.
So far, I've put in stub code for all the interfaces, and I have spent a couple of hours today trying to understand automake/autoconf and getting the new backend as a configure option. Autconf isn't perfect it definitely has some issues, but overall I found it easier to understand than say CMake which really freaking sucks. I tried to use that at work as way of distributing a turnkey software solution. The documentation left me cold, it's just really hard to understand it and there just isn't a lot of documentation out on the Net unlike auto* tools. KDE also seems to have had problems and nobody really has anything good to say about it. GNOME is still trying to figure out what it wants out of a build system. They've been thinking of using WAF but the maintainer hasn't been particularly cooperative. Perhaps with some modification it might be good. I'm not planning on using WAF as of yet. Maybe in another project at work.
Anyways, I'm hoping that I can at least start getting import finished by the end of the week. I need to define some milestones which I wlil do in the next blog entry. Import is definitely at the top of the list and getting a little more familiar with the backend database. The main goal is to finish the sqlite database backend. If I have time I will start adding tags and then comes the really really fun part, the UI.
sri
Monday, June 23, 2008
First post..
Greetings. This is the first post in my new blog. This is primarily a personal one and I'm also using it for a class. I have another blog at here as well.
sri
sri
Subscribe to:
Posts (Atom)