It happened on the second day of use. The computer arrived yesterday in the afternoon and crashed for the first time about 24 hours later.
I was surfing the Internet using google chrome while listening to musing with pandora. Suddenly there was a load non-constant booming noise from the external speakers. I tried to lower the volume using the mouse but the cursor would not move. The noise was very loud and I was afraid of damage to the speakers so I turned the volume very low on the speakers.
After a couple of minutes of trying to do something I gave up and pressed the power switch. This seemed to do nothing so I held the power button down long enough to power off. Then I restarted.
After rebooting I adjusted the speaker volume to be fairly low at the maximum setting on the computer. Perhaps if this lock-up happens again it will be less scary. I hope it doesn't happen while I am sleeping...
I am adjusting my initial score for the Mac mini:
Ubuntu Linux 10
Mac mini 7
Windows 7
Having a computer lockup so soon is unexpected. Since the Mac is all stock equipment selected by Apple, I had expected very high reliability. I figured that Mac OS X would have huge uptimes like Linux. Now I suspect that I have bought a lemon. I did buy a reconditioned computer, but I figured that Apple could isolate problems and repair a computer quite well.
Wednesday, August 29, 2012
First Thoughts on the Mac Mini
Size
The Mac mini is my first Mac computer. I bought it so that I could get ebe working to support assembly development on OS X. The most obvious feature of the mini is its small size. It's roughly the size of a Wii, which is like a fairly thick book.
OS X
OS X Mountain Lion was installed and I had no problems getting it set up with a seyfarth account for first use. I also rapidly stumbled (or was led) into performing an update to 10.8.1.
I got somewhat used to the dock and the system bar at the top of the screen without a lot of grief. It felt like the system was not taking much advantage of the right mouse button.
Safari and everything else seems to scroll backwards with the mouse wheel. I haven't considered if one way has some inherent virtue, but I do find it annoying when I forget and scroll the wrong way.
Monday, August 06, 2012
xterm fonts
I needed to figure out how to cope with setting the font size for xterm. Historically I have used "xterm -fn 10x20", which gives a nice font. The "-fn" option specifies a font name. Now depending on what a person has installed on their Linux system there could be a large number of fonts. Running "xlsfonts" will print a list of fonts. On my computer I noticed "terminus-32" which gave a pretty large font.
This is needed as I start letting users configure ebe. One of the configurable items will be the font for xterm which is used for terminal I/O for the program being debugged. I can't figure out a good way to settle this issue inside ebe, so I will give the user a few suggestions for fonts on my computer and suggest experimenting with the names printed by xlsfonts.
Another option is to use TrueType fonts. A useful list can be obtained using
fc-list :scalable=true:spacing=mono: family
Then you can specify a font for xterm using -fa Courier (or whatever) and specify a size using -fs 14 (or some other number). This gives more options.
This is needed as I start letting users configure ebe. One of the configurable items will be the font for xterm which is used for terminal I/O for the program being debugged. I can't figure out a good way to settle this issue inside ebe, so I will give the user a few suggestions for fonts on my computer and suggest experimenting with the names printed by xlsfonts.
Another option is to use TrueType fonts. A useful list can be obtained using
fc-list :scalable=true:spacing=mono: family
Then you can specify a font for xterm using -fa Courier (or whatever) and specify a size using -fs 14 (or some other number). This gives more options.
Sunday, August 05, 2012
Problem with after_idle
I ran into a bug with ebe recently which occurred under Debian Squeeze. When ebe was started it "flashed" the menubar preventing it from working. The same source code worked well under Ubuntu so I started looking for the problem.
I installed virtualbox on my home computer and installed Squeeze and sure enough the problem was there in the virtual Squeeze. The likely problems seemed to be python, tkinter or pmw. After some effort I managed to configure apt to allow installing packages from the testing repository. I installed newer versions of python and pmw which were pretty much the same versions as I had on Ubuntu. Still the problem persisted.
Now I knew that I was writing the line and column number of the editing cursor in the menubar in ebe, so I figured there might be some chance that I had screwed up that code. I searched and located that all over the place in ebe I used after_idle to call a function which updated the line and column information on the menubar. It looked like the problem was corralled.
I reread the documentation about the Tkinter after_idle function. It claimed that after_idle would call a function once for a call to after_idle. It seemed to me that after_idle was continuing to call my function to show the location. This could happen if the location update code called after_idle or if after_idle was broken.
It turned out that after_idle was being called as a result of using my location update code. I didn't locate a place where it could have happened and the fact that the code worked on Ubuntu and Windows makes it seem that the best bet was a problem with after_idle. I realize that problems can occasionally make little sense and certainly studying the Tkinter code was beyond the call of duty, so I decided to solve the problem without figuring out exactly why the problem ever showed up.
The solution was pretty simple. I added an additional function, show_location1, which I interposed between show_location which calls after_idle and show_location2 which actually does the location updates. I am now using after_idle to call show_location1 and show_location1 calls after to trigger a call to show_location2 after 500 msecs. The problem still exists, but updating the location twice a second doesn't interfere with the normal operation of ebe.
My expectation is that this is not a problem with my code, but I am not certain. It makes me think that perhaps I would have been better off using QT with C++ rather than python. Who knows which would cause the least trouble?
I installed virtualbox on my home computer and installed Squeeze and sure enough the problem was there in the virtual Squeeze. The likely problems seemed to be python, tkinter or pmw. After some effort I managed to configure apt to allow installing packages from the testing repository. I installed newer versions of python and pmw which were pretty much the same versions as I had on Ubuntu. Still the problem persisted.
Now I knew that I was writing the line and column number of the editing cursor in the menubar in ebe, so I figured there might be some chance that I had screwed up that code. I searched and located that all over the place in ebe I used after_idle to call a function which updated the line and column information on the menubar. It looked like the problem was corralled.
I reread the documentation about the Tkinter after_idle function. It claimed that after_idle would call a function once for a call to after_idle. It seemed to me that after_idle was continuing to call my function to show the location. This could happen if the location update code called after_idle or if after_idle was broken.
It turned out that after_idle was being called as a result of using my location update code. I didn't locate a place where it could have happened and the fact that the code worked on Ubuntu and Windows makes it seem that the best bet was a problem with after_idle. I realize that problems can occasionally make little sense and certainly studying the Tkinter code was beyond the call of duty, so I decided to solve the problem without figuring out exactly why the problem ever showed up.
The solution was pretty simple. I added an additional function, show_location1, which I interposed between show_location which calls after_idle and show_location2 which actually does the location updates. I am now using after_idle to call show_location1 and show_location1 calls after to trigger a call to show_location2 after 500 msecs. The problem still exists, but updating the location twice a second doesn't interfere with the normal operation of ebe.
My expectation is that this is not a problem with my code, but I am not certain. It makes me think that perhaps I would have been better off using QT with C++ rather than python. Who knows which would cause the least trouble?
Subscribe to:
Posts (Atom)