Recently I have been having a very strange issue with my desktop box. After I log in (sometimes immediately, sometimes after just a few minutes), menus stop appearing. This includes the Gnome-panel menus as well as the menus in any program I may be running or the right-click context menu in Nautilus. When I click a menu, its color changes to indicate that it has been clicked like it normally would, but I don't see the menu.
If I am running any program such as Nautilus or Totem when the problem occurs, I can keep using it normally (as long as I don't need to access a menu or right-click anything), but the only way I have found to resolve the issue is by restarting X (after having installed dontzap and re-enabling the ctrl+alt+backspace shortcut).
Also-- I use Gnome-Do's Docky interface. I noticed that if I click an icon in Docky while this problem is going on, the icon grows like normal then nothing happens: the program does not launch and the icon doesn't shrink back to its normal size either.
So, this seems to be some weird problem with my desktop not refreshing or something. I do not recall making any changes recently, other than installing a few updates when prompted (sorry, I don't recall which ones, but this came up about 2-3 weeks ago).
Over the weekend I installed a host of updates (including some kernel updates and the problem seemed to go away. Unfortunately, that proved not to be the case: I'm still having the problem, although I have some more information about what seems to be going on.
It all seems to be related to an episode I had a few months ago after I inadvertently allowed my $HOME partition to fill up. I wrote about it in all its painful glory here.
Since that time everything has seemed fine, except weird issues I've been having in Banshee. I noticed after I addressed the issues caused by the full partition that whenever I launched Banshee, it would never remember my view settings (it did before the problems I had). For example, one view pane would always be reduced to about 5% of the viewable screen instead of the 60/40 split I would always use. Every time I launch Banshee the first thing I do is resize the view panes to the way I like them, but it never remembers the preference (again, it used to remember).
The display issue I wrote about in my first post seems to have started coming up after Banshee locked up when I paused a movie I was watching. I killed the program with the Force Quit applet. I think that this is when the display issues started.
As I mentioned above, the problems seemed to stop when I installed some updates (including a Kernel update). Tonight I re-installed the latest kernel through Synaptic and the issue seemed to stop again.
I'm going to play around with Banshee and see if I can cause this to happen again. What I'm wondering is whether what I'm describing about Banshee and the other issues ringing any bells to anyone. Am I touching on something here? If I am able to cause this to happen by causing a Banshee lockup again, I guess I could try to back up my banshee.db then completely remove/ reinstall the program and see if it performs normally again.
Thursday, October 8, 2009
Thursday, September 24, 2009
Following Up on that Big Game
Well, everybody knows what happened in the Horseshoe on September 12. It was, for the most part, what I expected aside from the outstanding performance of the OSU D (except for that last drive, of course). I won't bother with a full breakdown of the game but suffice to say, smartfootball.com's Chris Brown said it far better than I could.
RIP Tresselball. Let's just hope that The Senator is aware.
RIP Tresselball. Let's just hope that The Senator is aware.
Friday, September 11, 2009
Showdown in the 'Shoe
Twenty four hours from now, the Ohio State University football Buckeyes will be battling the USC Trojans on their home turf. The men in the Scarlet and Gray will be fighting not only to avenge last year's demoralizing defeat, but also to redeem their deflated national reputation (not to mention that of the Big Ten). Ostensibly much bigger underdogs in this year's game than in last year's, the Bucks will have their hands full on both sides of the ball in this game.
The good news for the Bucks, on a high level, is twofold: the Trojans run a pro-style offense, which OSU is much better at defending than say, a triple option or spread-option offense. Also, Ohio State played this same offense (with a few different players as compared to this year) last year. The same can't be said for USC: OSU's offense last year was also largely a pro-style offense, crafted for the now-departed Todd Boeckman. This year things will be much, much different with Terrelle Pryor at the helm. This will be a new offense with new looks run by a different style QB. One could even say that Pryor is Boeckman's antithesis.
Keys to the Game
Ohio State and USC match up fairly well when it comes to their skill players. True that USC has more depth and their starters are largely more experienced, but OSU's pool of starting talent--raw talent-- is fairly similar to USC's. The difference, moreso than any other area, will be how well the Bucks fight the battle in the trenches. That's right, the keys to this game are all about line play. It is no secret that OSU's line play-- that of the O line in particular-- has been subpar, even terrible at times. Last year's game, which I blogged about beforehand here, against the Men of Troy was a prime example. Todd Boeckman, a decent quarterback in most regards, lost his job after the USC game due mostly to the fact that the O line couldn't protect him-- and let's face it: when the protection wore down, the guy was slower than molasses in January on his feet. If the offensive line had performed on par with, say, USC's, things would have been much different that game and indeed, the remainder of the season. Had that been the case, right now I'd be speculating on how well Terrelle Pryor would be handling "his" offense in a big game for the first time.
USC D line vs OSU O line
USC's D line knows all too well about OSU's underachieving O line and will do their best to capitalize on it. True, Pryor does a good job of evading defenders when things break down, but he can't be relied upon to lead the offense to a win unless broken plays are more the exception than the rule-- and that will most likely not be the case. Look for Pryor to spend a lot of time scrambling. Thankfully, he's good at this. Against Navy last week, it was apparent that he's in much more of a pass-first rather than run-first mentality than last year. Rather than running for whatever yardage he can get, he will be trying to evade defenders long enough to complete the pass. In other words, Pryor wants to be Troy Smith rather than Vince Young. And that is a very good thing.
OSU D line against USC O line
The matchup that will be more favorable to the Buckeyes will be their D line against USC's O line. USC still has the upper hand here, but things will not be as lopsided as USC's D line against OSU's O line. OSU's D line has the best chance of keeping the momentum from swinging too far in USC's favor. USC generally uses a pass-first mentality: set up the pass early to establish the running game, then use the run to take pressure off the QB and the passing game. It will be absolutely necessary for OSU's D to prevent this from happening and keep USC's offense from getting into a rhythm. The best way to do this, in my opinion, will be to pressure Barkley: bring the DE's in and ring his bell or at least force him to make decisions he doesn't want to make. The results of this will be either incompletions or, hopefully, turnovers. Don't let him get comfortable in the pocket. Shut down the passing game and force USC to the run. The problem here is that while OSU's D line is good, they will be facing the same O line that dominated them one year ago.
OSU Offense
OSU under Jim Tressell has historically been of an offensive mindset opposite USC under Carroll: establish the run to set up the pass. Run-run-pass. Tressellball and all that. I will not be surprised if OSU steps away from this approach tomorrow. This will take away the predictability that USC will be prepared for and will also not rely on OSU's ground game, which is currently less than stellar (primarily due to the play of the O line). Herron and Saine are good running backs, but they aren't bruisers that can run between the tackles and bowl defenders over like Beanie Wells was. These guys need good blocking and a bit of space in order to shine, and the offensive unit has not been reliable in providing this.
This may very well be Duron Carter's coming out party. I have been excited about the kid since I saw him in practice and then against Navy. He is a true freshman starting in his 2nd game, but the kid has got talent. He is already showing flashes-- he has good hands and, more evidently, he's got moves. Although he hasn't seen much playing time yet, I believe he's the real deal. He won't be seeing much play time behind Small, Posey, and Sanzenbacher, but look for something special when he is on the field.
USC Defense
I don't need to tell you that USC's D is the real deal. Although they have replaced three future NFL stars at LB, they will likely not miss a beat. USC is a team that reloads like nobody's business on both sides of the ball. Last year, I rightly predicted that Rey Maualuga would be the standout defender. This year, the man to watch will be SS Taylor Mays. Mays is famous for being both very fast and a hard hitter. He has also let it be known that he will be looking for Pryor. Mays is at his most dangerous when he is in the open field: reading the quarterback's eyes or closing on a defender. Perhaps his only "weakness" is his ability to cover. Running receivers straight at him may be the only way to keep him at bay.
Prediction Time
This will be a huge battle for momentum. Both teams will come out swinging hard. The Bucks know that USC is a team that cannot be allowed to settle into a rhythm. Once that happens, they are almost unstoppable--unless they can be outscored, which isn't likely. Ohio State will look to set up the passing game using short, quick passes. Get the ball out of Pryor's hands quickly so that the O line won't be so heavily relied upon early in the game. Build up confidence in that way. The pistol formation will be instrumental in this. Once the USC D is forced to back off a bit and focus more on covering the Buckeye receivers downfield, that will allow for the ground game to open up. Pryor will no doubt do his share of the running, but designed running plays will probably not come up right away-- at least not until the offense has scored a couple of first downs, if not later.
USC will also take the field and start by hitting Ohio State in the mouth. They will not hesitate to do some aggressive things to get that all-important momentum. The element that will probably not be present until the offense gets into a rhythm will be the deep passing game. Barkley, for as talented as he is, hasn't proven that he can throw the deep ball yet and Carroll probably won't ask him to do so until he has gained a bit of confidence. Once that time comes, OSU's newly-rearranged secondary will be tested.
Bottom line: he who wins in the trenches likely wins the game. I say likely because Pryor, as I said, can at least make something from nothing when protection breaks down. If the Bucks can at least keep a 40-60 balance at the line of scrimmage against USC, they will be OK.
Ohio State may put up a quick score or two early. But unfortunately, I think USC is just too talented, experienced, and confident coming into the game. Look for them to gain that all-important momentum in the 2nd quarter. Once that happens, the air will be taken out of the Horseshoe and the 12th man will evaporate. Tressell will make few, if any, changes at the half and the 2nd half of the game will be all USC-- excepting a too-little-too-late OSU rally late in the game. OSU will rally and either have too little time left or lose momentum back to USC. Carroll is not the kind of guy who will call off the dogs when his team has the game in hand. His teams play every game like they have something to prove.
USC 38, OSU24.
I hope that in approximately 26 hours' time, I will be eating my words. Go Bucks!
The good news for the Bucks, on a high level, is twofold: the Trojans run a pro-style offense, which OSU is much better at defending than say, a triple option or spread-option offense. Also, Ohio State played this same offense (with a few different players as compared to this year) last year. The same can't be said for USC: OSU's offense last year was also largely a pro-style offense, crafted for the now-departed Todd Boeckman. This year things will be much, much different with Terrelle Pryor at the helm. This will be a new offense with new looks run by a different style QB. One could even say that Pryor is Boeckman's antithesis.
Keys to the Game
Ohio State and USC match up fairly well when it comes to their skill players. True that USC has more depth and their starters are largely more experienced, but OSU's pool of starting talent--raw talent-- is fairly similar to USC's. The difference, moreso than any other area, will be how well the Bucks fight the battle in the trenches. That's right, the keys to this game are all about line play. It is no secret that OSU's line play-- that of the O line in particular-- has been subpar, even terrible at times. Last year's game, which I blogged about beforehand here, against the Men of Troy was a prime example. Todd Boeckman, a decent quarterback in most regards, lost his job after the USC game due mostly to the fact that the O line couldn't protect him-- and let's face it: when the protection wore down, the guy was slower than molasses in January on his feet. If the offensive line had performed on par with, say, USC's, things would have been much different that game and indeed, the remainder of the season. Had that been the case, right now I'd be speculating on how well Terrelle Pryor would be handling "his" offense in a big game for the first time.
USC D line vs OSU O line
USC's D line knows all too well about OSU's underachieving O line and will do their best to capitalize on it. True, Pryor does a good job of evading defenders when things break down, but he can't be relied upon to lead the offense to a win unless broken plays are more the exception than the rule-- and that will most likely not be the case. Look for Pryor to spend a lot of time scrambling. Thankfully, he's good at this. Against Navy last week, it was apparent that he's in much more of a pass-first rather than run-first mentality than last year. Rather than running for whatever yardage he can get, he will be trying to evade defenders long enough to complete the pass. In other words, Pryor wants to be Troy Smith rather than Vince Young. And that is a very good thing.
OSU D line against USC O line
The matchup that will be more favorable to the Buckeyes will be their D line against USC's O line. USC still has the upper hand here, but things will not be as lopsided as USC's D line against OSU's O line. OSU's D line has the best chance of keeping the momentum from swinging too far in USC's favor. USC generally uses a pass-first mentality: set up the pass early to establish the running game, then use the run to take pressure off the QB and the passing game. It will be absolutely necessary for OSU's D to prevent this from happening and keep USC's offense from getting into a rhythm. The best way to do this, in my opinion, will be to pressure Barkley: bring the DE's in and ring his bell or at least force him to make decisions he doesn't want to make. The results of this will be either incompletions or, hopefully, turnovers. Don't let him get comfortable in the pocket. Shut down the passing game and force USC to the run. The problem here is that while OSU's D line is good, they will be facing the same O line that dominated them one year ago.
OSU Offense
OSU under Jim Tressell has historically been of an offensive mindset opposite USC under Carroll: establish the run to set up the pass. Run-run-pass. Tressellball and all that. I will not be surprised if OSU steps away from this approach tomorrow. This will take away the predictability that USC will be prepared for and will also not rely on OSU's ground game, which is currently less than stellar (primarily due to the play of the O line). Herron and Saine are good running backs, but they aren't bruisers that can run between the tackles and bowl defenders over like Beanie Wells was. These guys need good blocking and a bit of space in order to shine, and the offensive unit has not been reliable in providing this.
This may very well be Duron Carter's coming out party. I have been excited about the kid since I saw him in practice and then against Navy. He is a true freshman starting in his 2nd game, but the kid has got talent. He is already showing flashes-- he has good hands and, more evidently, he's got moves. Although he hasn't seen much playing time yet, I believe he's the real deal. He won't be seeing much play time behind Small, Posey, and Sanzenbacher, but look for something special when he is on the field.
USC Defense
I don't need to tell you that USC's D is the real deal. Although they have replaced three future NFL stars at LB, they will likely not miss a beat. USC is a team that reloads like nobody's business on both sides of the ball. Last year, I rightly predicted that Rey Maualuga would be the standout defender. This year, the man to watch will be SS Taylor Mays. Mays is famous for being both very fast and a hard hitter. He has also let it be known that he will be looking for Pryor. Mays is at his most dangerous when he is in the open field: reading the quarterback's eyes or closing on a defender. Perhaps his only "weakness" is his ability to cover. Running receivers straight at him may be the only way to keep him at bay.
Prediction Time
This will be a huge battle for momentum. Both teams will come out swinging hard. The Bucks know that USC is a team that cannot be allowed to settle into a rhythm. Once that happens, they are almost unstoppable--unless they can be outscored, which isn't likely. Ohio State will look to set up the passing game using short, quick passes. Get the ball out of Pryor's hands quickly so that the O line won't be so heavily relied upon early in the game. Build up confidence in that way. The pistol formation will be instrumental in this. Once the USC D is forced to back off a bit and focus more on covering the Buckeye receivers downfield, that will allow for the ground game to open up. Pryor will no doubt do his share of the running, but designed running plays will probably not come up right away-- at least not until the offense has scored a couple of first downs, if not later.
USC will also take the field and start by hitting Ohio State in the mouth. They will not hesitate to do some aggressive things to get that all-important momentum. The element that will probably not be present until the offense gets into a rhythm will be the deep passing game. Barkley, for as talented as he is, hasn't proven that he can throw the deep ball yet and Carroll probably won't ask him to do so until he has gained a bit of confidence. Once that time comes, OSU's newly-rearranged secondary will be tested.
Bottom line: he who wins in the trenches likely wins the game. I say likely because Pryor, as I said, can at least make something from nothing when protection breaks down. If the Bucks can at least keep a 40-60 balance at the line of scrimmage against USC, they will be OK.
Ohio State may put up a quick score or two early. But unfortunately, I think USC is just too talented, experienced, and confident coming into the game. Look for them to gain that all-important momentum in the 2nd quarter. Once that happens, the air will be taken out of the Horseshoe and the 12th man will evaporate. Tressell will make few, if any, changes at the half and the 2nd half of the game will be all USC-- excepting a too-little-too-late OSU rally late in the game. OSU will rally and either have too little time left or lose momentum back to USC. Carroll is not the kind of guy who will call off the dogs when his team has the game in hand. His teams play every game like they have something to prove.
USC 38, OSU24.
I hope that in approximately 26 hours' time, I will be eating my words. Go Bucks!
Sunday, July 19, 2009
Penumbra
This weekend I picked up a copy of the Penumbra Collection. The three-part game is on sale this weekend and, since the developers were good enough to produce a native Linux version, I was eager to support them by making the purchase.
I paid for and downloaded the game, ran the installer, and launched it. This is when I ran into an issue. As soon as I launched the game, my monitor (actually the TV in the living room) went dark and gave me a message about the signal being unsupported. I had audio and heard the game intro playing, but I couldn't escape the window. My only option was to reset the computer. Great, I thought, what's wrong now? Driver issue? Do I need to tweak xorg.conf? I set about digging for an answer.
The first thing I did was install and enable dontzap so that I could at least restart X without resetting the whole computer, which did help as I ended up launching the game a few times as I tried to troubleshoot.
As an alternative to restarting X the good old fashioned way, I also did the following: when the game started and I was left with no display, I dropped into a virtual terminal (ctrl+alt+F1), ran the top command, found the PID for the game, and killed it (sudo kill -9 [PID]). However for whatever reason, I was still unable to get back to my graphical terminal after doing this and had to restart X anyway by running sudo /etc/init.d/gdm restart. So, a simple ctrl+alt+backspace was still the way to go.
Anyway, on to the information hunt. A few google searches as well as a look through the devs' Linux support forum turned up a few related or similar problems, but nobody seemed to be running into the exact problem that I was. The ones that were similar were all running Intel or ATI graphics cards (I have NVIDIA).
Normally, my first trick in troubleshooting this kind of thing is to run the program from the command line and see what errors it throws. However since I was running into a situation where I had to restart X or take the entire system down, anything displayed in Terminal would obviously be lost. So, I decided to dump any Terminal output into a log file by running:
/home/rick/PenumbraCollection/Overture/penumbra > ~/Desktop/penumbra.log
The log file contained only this:
Penumbra: Overture exited unexpectedly, please check
/home/rick/.frictionalgames/Penumbra/Overture/hpl.log
for any error messages
Also try running
ulimit -c unlimited
And re-running Penumbra and try and recreate the error
then submit the generated core file or stack trace
This output was generated only when I killed the process. I wondered to myself how there could not be any errors thrown when I launched the game. Then it hit me: there were no errors thrown because the game was running just fine! The problem was with my monitor-- the signal was unsupported, but it was receiving something. I looked in ~/PenumbraCollection/Overture/config/default_settings.cfg and found what I expected in the form of the following line:
Screen Width="800" Height="600" FullScreen="true" Vsync="false"
Cripes, I thought. It was simple all along! The 1080 TV I'm using doesn't support 800x600! Insta-facepalm. I edited the line, replacing 800 and 600 with 1920 and 1080 and viola! I had picture when I launched the game again. The problem was far more simple than I had imagined. Now I know what I'll be doing for the afternoon...
I paid for and downloaded the game, ran the installer, and launched it. This is when I ran into an issue. As soon as I launched the game, my monitor (actually the TV in the living room) went dark and gave me a message about the signal being unsupported. I had audio and heard the game intro playing, but I couldn't escape the window. My only option was to reset the computer. Great, I thought, what's wrong now? Driver issue? Do I need to tweak xorg.conf? I set about digging for an answer.
The first thing I did was install and enable dontzap so that I could at least restart X without resetting the whole computer, which did help as I ended up launching the game a few times as I tried to troubleshoot.
As an alternative to restarting X the good old fashioned way, I also did the following: when the game started and I was left with no display, I dropped into a virtual terminal (ctrl+alt+F1), ran the top command, found the PID for the game, and killed it (sudo kill -9 [PID]). However for whatever reason, I was still unable to get back to my graphical terminal after doing this and had to restart X anyway by running sudo /etc/init.d/gdm restart. So, a simple ctrl+alt+backspace was still the way to go.
Anyway, on to the information hunt. A few google searches as well as a look through the devs' Linux support forum turned up a few related or similar problems, but nobody seemed to be running into the exact problem that I was. The ones that were similar were all running Intel or ATI graphics cards (I have NVIDIA).
Normally, my first trick in troubleshooting this kind of thing is to run the program from the command line and see what errors it throws. However since I was running into a situation where I had to restart X or take the entire system down, anything displayed in Terminal would obviously be lost. So, I decided to dump any Terminal output into a log file by running:
/home/rick/PenumbraCollection/Overture/penumbra > ~/Desktop/penumbra.log
The log file contained only this:
Penumbra: Overture exited unexpectedly, please check
/home/rick/.frictionalgames/Penumbra/Overture/hpl.log
for any error messages
Also try running
ulimit -c unlimited
And re-running Penumbra and try and recreate the error
then submit the generated core file or stack trace
This output was generated only when I killed the process. I wondered to myself how there could not be any errors thrown when I launched the game. Then it hit me: there were no errors thrown because the game was running just fine! The problem was with my monitor-- the signal was unsupported, but it was receiving something. I looked in ~/PenumbraCollection/Overture/config/default_settings.cfg and found what I expected in the form of the following line:
Sunday, July 12, 2009
Upgrading to VirtualBox 3.0
Today, as sometimes happens, I ran into a situation where I needed to run a Windows-only app. Having recently moved over to a new laptop, I didn't have an existing virtual machine to use. What I did have was an old installation of VirtualBox 2.1
Having recently read about the release of version 3.0 of the venerable VM host, I figured now was as good of a time as any to upgrade. After modifying sources.list and importing the apt-secure key, I initiated the download:
sudo apt-get install virtualbox-3.0
I checked back a few minutes later and much to my shagrin, I was greeted with an error message about the kernel module failing to compile due to the kernel headers not being present.
This, I realized, was the first snag I had run into due to upgrading to the upstream 2.6.30 kernel to fix issues I had been having with poor 2D acceleration in Jaunty (reference).
Not prepared to give up, I headed over to the Ubuntu kernel repository where, thankfully, the 2.6.30 kernel headers were available. I grabbed and installed the appropriate deb, and ran the familiar:
sudo /etc/init.d/vboxdrv setup
And was greeted with another error:
* Stopping VirtualBox kernel module
* done.
* Recompiling VirtualBox kernel module
* Look at /var/log/vbox-install.log to find out what went wrong
The log gave me this:
Error! Your kernel source for kernel 2.6.30-020630-generic cannot be found at
/lib/modules/2.6.30-020630-generic/build or /lib/modules/2.6.30-020630-generic/source.
Silly mistake on my part this time. I had downloaded the kernel headers, but not the kernel source. I grabbed and installed the kernel source deb, and this time the kernel module compiled without a hitch.
I am installing a WinXP guest machine now.
Having recently read about the release of version 3.0 of the venerable VM host, I figured now was as good of a time as any to upgrade. After modifying sources.list and importing the apt-secure key, I initiated the download:
sudo apt-get install virtualbox-3.0
I checked back a few minutes later and much to my shagrin, I was greeted with an error message about the kernel module failing to compile due to the kernel headers not being present.
This, I realized, was the first snag I had run into due to upgrading to the upstream 2.6.30 kernel to fix issues I had been having with poor 2D acceleration in Jaunty (reference).
Not prepared to give up, I headed over to the Ubuntu kernel repository where, thankfully, the 2.6.30 kernel headers were available. I grabbed and installed the appropriate deb, and ran the familiar:
sudo /etc/init.d/vboxdrv setup
And was greeted with another error:
* Stopping VirtualBox kernel module
* done.
* Recompiling VirtualBox kernel module
* Look at /var/log/vbox-install.log to find out what went wrong
The log gave me this:
Error! Your kernel source for kernel 2.6.30-020630-generic cannot be found at
/lib/modules/2.6.30-020630-generic/build or /lib/modules/2.6.30-020630-generic/source.
Silly mistake on my part this time. I had downloaded the kernel headers, but not the kernel source. I grabbed and installed the kernel source deb, and this time the kernel module compiled without a hitch.
I am installing a WinXP guest machine now.
Saturday, July 11, 2009
Fallout
Recently I blogged about my misadventures with a full partition that contained my $HOME folder. I noticed not long after that episode that I still had some strange behavior, such as various program preferences not being saved and issues copying some files during a data backup.
After doing a bit of sleuthing, I concluded that in addition to the issues I wrote about at the time, my $HOME permissions had been altered. I did a bit of digging and from a few different forum threads, I plucked out a few commands that helped me to restore things back to their normal order. What I had to run was the following:
sudo umount ~/.gvfs --> unmount the GNOME Virtual File System config so that I can...
rm -r ~/.gvfs --> ...delete it, to allow...
sudo chown -R rick /home/rick --> ...everything to properly be chown-ed by me.
And finally:
chmod 755 ~ --> Set proper permissions for ~ (Read/Write/Execute for me, Read/Execute for everyone else).
Yes, some of these things can be done through Nautilus, but that method is not recommended. The reason being that Nautilus does not always handle permissions as gracefully as the trusty command line.
So there you have it, a two-part post on what how to remedy a broken system. Again, the upshot is not to let this happen to begin with!
After doing a bit of sleuthing, I concluded that in addition to the issues I wrote about at the time, my $HOME permissions had been altered. I did a bit of digging and from a few different forum threads, I plucked out a few commands that helped me to restore things back to their normal order. What I had to run was the following:
sudo umount ~/.gvfs --> unmount the GNOME Virtual File System config so that I can...
rm -r ~/.gvfs --> ...delete it, to allow...
sudo chown -R rick /home/rick --> ...everything to properly be chown-ed by me.
And finally:
chmod 755 ~ --> Set proper permissions for ~ (Read/Write/Execute for me, Read/Execute for everyone else).
Yes, some of these things can be done through Nautilus, but that method is not recommended. The reason being that Nautilus does not always handle permissions as gracefully as the trusty command line.
So there you have it, a two-part post on what how to remedy a broken system. Again, the upshot is not to let this happen to begin with!
Sunday, June 14, 2009
Diving into SQLite Using Python
...Or, The Trouble With Tuples.
(Sorry, the pun had to be made).
For the past 3-ish months, I've been teaching myself Python. I started off with Wesley Chun's Live Lessons video tutorials, and later moved on to his book Core Python, 2nd ed. It has been a satisfying ride so far. Not without tribulations of course, but things are coming along nicely.
Once I had learned enough of the basics, I jumped into writing some programs. Simple things at first of course such as number guessing games and the like-- at first taken from textbook exercises, but later also incorporating various other amateur programming challenges I found on the web.
My most recent project is a database manager application. Originally it was a response to a programming challenge posted on the Ubuntu Forums, but slowly developed into a larger and more powerful app as I decided to add more and more features not called for in the assignment.
Development of the app moved along at a steady pace until I implemented record deletion. I could successfully search the DB using a parameter entered by the user and edit the record, but when I tried to delete it I was met with the error:
ValueError: parameters are of unsupported type
This was something I had not previously encountered. After exhausting my available resources, I decided to ask for help on the Ubu-forums. I started a thread (full details about the program and the solution can be found therein) and got my answer in short notice. Essentially it was this:
I had already successfully implemented DB record editing with the statement
cursor.execute('UPDATE main SET FName=?, LName=?, age=? WHERE id=?', (dataFName, dataLName, dataAge, record))
This part of things worked without a hitch. But when, in the same function, I ran
cursor.execute('DELETE FROM main WHERE id=?', (record))
I would get the "unsupported type" error.
The problem, I learned, was with the variable "(record)" that I was passing to the SQLite statement. The data passed needs to be of type Tuple and I was not providing one. I was providing a mutable string!
I was puzzled by the fact that the edit statement worked and the delete statement did not. It dawned on me that I was inadvertently creating a Tuple in the edit statement-- this was completely a by-product of me passing multiple variables across. It just happened to be creating the tuple I needed without me realizing it. With that in mind, what I had to do was make a very small change to the delete statement in order to create a tuple. I added a comma after record so that the statement read:
cursor.execute('DELETE FROM main WHERE id=?', (record,))
And that was all it took! Lesson learned. Things are moving along nicely with this hurdle out of the way and I hope to soon be finished with the app.
(Sorry, the pun had to be made).
For the past 3-ish months, I've been teaching myself Python. I started off with Wesley Chun's Live Lessons video tutorials, and later moved on to his book Core Python, 2nd ed. It has been a satisfying ride so far. Not without tribulations of course, but things are coming along nicely.
Once I had learned enough of the basics, I jumped into writing some programs. Simple things at first of course such as number guessing games and the like-- at first taken from textbook exercises, but later also incorporating various other amateur programming challenges I found on the web.
My most recent project is a database manager application. Originally it was a response to a programming challenge posted on the Ubuntu Forums, but slowly developed into a larger and more powerful app as I decided to add more and more features not called for in the assignment.
Development of the app moved along at a steady pace until I implemented record deletion. I could successfully search the DB using a parameter entered by the user and edit the record, but when I tried to delete it I was met with the error:
ValueError: parameters are of unsupported type
This was something I had not previously encountered. After exhausting my available resources, I decided to ask for help on the Ubu-forums. I started a thread (full details about the program and the solution can be found therein) and got my answer in short notice. Essentially it was this:
I had already successfully implemented DB record editing with the statement
cursor.execute('UPDATE main SET FName=?, LName=?, age=? WHERE id=?', (dataFName, dataLName, dataAge, record))
This part of things worked without a hitch. But when, in the same function, I ran
cursor.execute('DELETE FROM main WHERE id=?', (record))
I would get the "unsupported type" error.
The problem, I learned, was with the variable "(record)" that I was passing to the SQLite statement. The data passed needs to be of type Tuple and I was not providing one. I was providing a mutable string!
I was puzzled by the fact that the edit statement worked and the delete statement did not. It dawned on me that I was inadvertently creating a Tuple in the edit statement-- this was completely a by-product of me passing multiple variables across. It just happened to be creating the tuple I needed without me realizing it. With that in mind, what I had to do was make a very small change to the delete statement in order to create a tuple. I added a comma after record so that the statement read:
cursor.execute('DELETE FROM main WHERE id=?', (record,))
And that was all it took! Lesson learned. Things are moving along nicely with this hurdle out of the way and I hope to soon be finished with the app.
Subscribe to:
Posts (Atom)