Friday, June 02, 2006

Blog moved

This weblog has been moved. Its new home is:

Wednesday, April 26, 2006

Setup Rails

I always seem to miss a step when installing Rails on Fedora. Here are the steps:

Setup Rails (all steps as root)
Install optional Ruby packages:
- ruby-rdoc
- ruby-ri

Download and install Ruby Gems:
- wget
- Extract archive and change into directory
- ruby setup.rb

Install Rails:
- gem install rails --include-dependencies

Installing Postgres support:
- yum install postgresql-devel
- gem install postgres

Wednesday, April 19, 2006

Firefox View Source Trick

I might be the last one on the planet to discover this one, but I doubt it, so I thought I'd share.

I'm used to right-clicking on a page and selecting "View Page Source" from the context menu. This has some advantages over the same command in the View menu because it allows you to narrow down which frame you want to view.

Last night, however, I accidentally selected some text and right clicked. I noticed that the familiar "View Page Source" menu item had changed to a "View Selection Source". It seems that if an straight-forward subset of the document is spanned by the selection, the resulting view source window will only display that portion. If, however, the selection spans disjoint elements in the tree, the whole document will be displayed with the relevant pieces hilighted.

This in and of itself is really helpful for comprehending a complex HTML structure, but there is one more thing I noticed that is even better:

The output of the View Selection Source command seems to be the HTML representation of the current structure of the document as opposed to the raw text obtained at page load time. Put another way, the changes made via JavaScript to the HTML DOM are displayed by View Selection Source.

I know there is an extension that lets you view the live document structure but I've never installed it and this is an easy trick that seemingly produces the same result.

Friday, March 17, 2006

Getting dev tools working with XULRunner

I've recently had a revived interest in Mozilla XUL. Last month I saw a blog about the new XULRunner tool, so I downloaded it a few days ago for a closer look. The first thing that became pretty obvious was that the normal suite of tools that I'm used to working with in Firefox/Mozilla don't really fit into XULRunner out of the box. These include things like the Extension Developer Extension, the Venkman JavaScript Debugger, and the DOM Inspector.
There are a few places that mention that it should be possible to get these things going, but I couldn't find any solid instructions on how to do so. I haven't gotten the DOM Inspector going yet, but see below for a method for getting the first two working in your XULRunner app.

First of all, I did all of this work using a custom built XULRunner on Linux from the XULRunner source drop. I have not tried this on the stock binaries but I think it should work. In any case, here are the configure options I used:

The Extension Developer Extension was pretty easy to hack into an XULRunner app. I just extracted the extensiondev.jar from the xpi and created an extensiondev.manifest that reflected what was in the install.js. I dropped both of these files into my app's chrome directory and was then able to specify the FireFox overlay on my main window (chrome://extensiondev/content/firefoxOverlay.xul). It worked after creating a menupopup with the id "menu_ToolsPopup", which follows the FireFox naming convention.

Venkman was trickier. I tried the same approach, ending up with a venkman.manifest and venkman.jar in my chrome directory. I then tried to overlay Venkman onto my main window (chrome://venkman/content/venkman-overlay.xul). The first hurdle is that the function toOpenWindowByType does not exist in the default XULRunner overlays. I just reimplemented it with the following:

function toOpenWindowByType(inType, uri)
{, "_blank", "chrome,extrachrome,menubar,resizable,scrollbars,status,toolbar");

Then the problem became that it just didn't work. I was using the venkman.jar that I extracted from the XULRunner build that I was using. I finally switched to the patched version of Venkman for Firefox 1.5 available from here. It worked like a charm. The main thing you have to do is uncheck the menu option Debug/Exclude Browser Files. Note that if you open more than one debugger window, the app crashes with a nasty segfault. My toOpenWindowByType stub should keep this from happening, but I haven't gotten to adding any logic for that.

I packaged the glue for these things up into an xulrunnerdev.jar that also adds a menu item to open the JavaScript Console (in lieu of having to pass the -jsconsole command line). Here are the exact steps to get it working in your XULRunner app:
  • Download the file from below and extract it to your application chrome directory.
  • Add a line to your application chrome.manifest for each of your application windows you would like to overlay with the tools. For example:

overlay chrome://testapp/content/startPage.xul chrome://xulrunnerdev/content/devOverlay.xul

  • Add an appropriate menupopup to the windows you want overlayed. For example:

<toolbox flex="1">
<menu label="Dev Tools">
<menupopup id="menu_ToolsPopup">

I have included a test application that includes all of this stuff below as well. There are certainly multiple ways to get this stuff to work. Hopefully this work can hold us over until more official support of the dev tools is included in XULRunner.


Saturday, October 08, 2005

Dumping the phone company

So, I did it... I finally made the total and final switch to Voice Over IP. I have been trying to find a palatable way to do this for many months as I watch my Qwest bill inch higher and higher. There were three things that converged this month that finally made me jump ship:
  • My Qwest bill topped $120 for a single line of service, a featureless home DSL package, and a minimal amount of long distance. Several months ago when my bill was hovering around $105/month, I considered it offensive that I was paying the phone company this much money for such a basic level of service. I called them and worked with the rep for nearly a half hour to trim out the optional features from my plan. Somehow, though, with taxes and all, I still ended up paying $101/month. My goal of getting my payments to the phone company down to a two digit number seemed unattainable. Needless to say, a $120 bill just fueled my desire to break away.
  • I signed up some time ago for this Qwest long distance package that has no monthly fee and charges 5 cents a minute, with a cap of $20/month. I know an increasing number of people are using their cell phones for long distance because the cell companies now treat LD as a local call for billing purposes. For myself, though, when I'm at home talking to friends or family long distance, I like having the clarity that only a wired connection can bring. I gnash my teeth at the 5 cent per minute tax here, but as I said, it is a preference of mine and at least it will top out at $20 and I can't get hit by a massive long distance bill... Or so I thought. On one hand, an examination of my bill this month reveals that Qwest now charges a monthly service fee for this plan. I don't know how long they have been doing it, but I do know that when I signed up, I questioned them very closely and got no indication that there was any promotional period or other such tactic being employed. In addition, while working at home a few times over the past month, I inadvertently returned a couple of phone calls to Canada (which is actually far closer distance-wise than most of the long distance calls I make). The calls totaled 33 minutes and accounted for a $13 charge on my bill (which was not subject to my $20/month cap). When questioned, the rep (who was very nice, btw) informed me that I could activate some XYZ international rate plan, which had a monthly fee, and would allow me to make these calls to Canada for a mere 10 cents per minute (which is still highway robbery). This situation outlines my basic problem with long distance companies (and cell phone companies too, but that is for another day): Why do I have to opt in through some obscure process (and usually pay a fee) in order to avoid getting scammed into irreversibly paying exorbitant prices for deviating outside of my normal habits and performing a normal act that I had no idea I was going to do ahead of time. And really, HOW SHOULD I KNOW that placing a call across some line on a map (I didn't even have to dial a country code) without informing the phone company first and paying them an additional protection fee qualified me to be the fully-legal victim of a billing scam. Imagine if the criminal system took this approach. What would you do if you were told: "I'm sorry that you had your identity stolen, but since you didn't sign up on the National Anti-Identity Theft Registry before-hand and pay the required monthly dues, there is really nothing we can do." Anyway, the extra $13 charge certainly didn't break the bank. It just reminded me why I dislike the phone company so much (and long distance companies especially). If all of the long distance companies in this country went bankrupt tomorrow (or at least their consumer long distance divisions), the world would be a slightly better place.
  • Ok. I said there were three things, and the first two were rants. This one is simple: I opened an email advertisement for a local broadband company (with whom I had inquired about service in the past) that outlined the basics of a new VOIP plan that they are rolling out. For a number of reasons which I'll explain below, this is different than "traditional" residential VOIP. The price was pretty compelling, too.

Earlier this year I was responsible for overseeing the rollout of a new phone system to a small company with a couple of satellite offices. We went with Cisco's line of VOIP equipment and tied it all together with leased lines that had QoS running over them and a pair of ISDN PRI's to interface with the telco. This experience taught me a couple of things about VOIP:
  • VOIP is viable. It can produce very clear calls on par with good analog links.
  • If QoS is not running on the network (especially the WAN links), or if it is not configured properly, things fall apart pretty quickly.
Bolstered by this success and wanting to add a second line of service to my home, I chose to go with one of the consumer internet VOIP providers. My experience was less than encouraging. Most of the time it sounded like I was on a poor quality cell phone. Also, whenever I would upload or download anything of substance while on the phone, it would break up. I knew that these experiences were a combination of using a low-bitrate codec and the inherent problems with sending real-time voice traffic over a link without any kind of QoS. It seemed to be a no-win scenario. Changing to a full-bitrate codec increased the sound quality but the added bandwidth requirements made it more likely for my internet activity to interfere with the phone call. Some tweaking made the situation better, but it was still bad in my opinion.

When I saw the advertisement for the local Denver company SBBOne, I jumped on it pretty quickly. They offer a full-stack VOIP/internet solution, becoming the ISP for your DSL link and riding the VOIP traffic wholly over their network. This allows them to provide end-to-end Quality of Service guarantees, which means that the VOIP traffic can always get the real-time priority that it needs. As added bonuses, they also do the following:
  • Don't charge long distance for the lower 48 states.
  • Charge international rates that are competitive (2 cents/minute to Canada for example)
  • Wire the voice service back through your existing house wiring, which allows you to plug a normal phone into any existing phone jack without even thinking about the VOIP router.
  • Provide the full calling features that we have come to expect from VOIP providers (and which will usually cost you in excess of $30/months to get from the phone company) such as 3-way calling, caller id, call waiting, voicemail to email options, web access, forwarding and more.
  • Local number portability: You get to keep your phone number.
  • They are a reseller for Qwest DSL which means that they deal with Qwest for the physical link so I don't have to.
  • 911 support
  • Static, public IP
The cost for all of this is $65/month and includes equipment rental. I added another line of service for an extra $20/month, bringing the cost to $85/month. I have to say that the results are impressive. The sound quality is perfect, even when using both phone lines and the internet heavily, and as-advertised, all of the existing phones and fax machine in my house "just work".

The price-tag for this may seem high for those of you using normal Internet based VOIP services. For these services you are probably paying $20-25/month. You have to remember that the SBBOne price tag includes DSL access. If I were to get a standalone DSL line from Qwest, the base cost would start at about $35 and increase to $40/month if I rented equipment from them.

Doing the math, you see that rolling your own stand-alone VOIP service from someone like Vonage or Broadvoice will cost you the same as going with the SBBOne solution. And with SBBOne, you get the local number portability (and caller id displays actually show your name instead of "VONAGE HOLDINGS"), service on your normal house lines and the ability to make and receive crystal clear calls.

This bundled approach really is the next generation in residential VOIP service. I would expect to see this type of arrangement popping up everywhere in the coming months. I know that Speakeasy is providing something similar, but their price for the same service offering (1.5M/768k DSL + Phone service) appears to be about $45/month more than what I am paying SBBOne (not to mention the inevitable contracts when you deal with Speakeasy). At this rate, you are probably not seeing a price-break when compared with traditional DSL + wired service, but it is available nationwide. I have also heard that Qwest is gearing up to provide a similar service. I really don't think that I would ever really choose to opt in to a Qwest offering. The price would have to pretty compelling. As it is, I have just found a viable and cheap way to opt-out of Qwest services. I don't anticipate going back anytime soon.

It really is too bad. Qwest was a good company before they realized their dream of becoming a local phone provider by buying USWest. Then they got locked up into the 50 years of lock-step tradition that is the little bells. Why they would pay to get into that position is beyond me. Of course, being in the heart of the old USWest territory that Qwest now serves probably renders my vision a bit myopic. After all, everyone hates their local telephone company. Their other lines of business outside of this territory are probably still ok.

Thursday, September 29, 2005

Gas mileage

With soaring gas prices, I set out on an experiment over the last month to see how much better gas mileage I could get by simply changing my driving patterns. For some background, I drive a Ford F150 extended cab pickup truck. I'm really not part of the SUV craze that seems to have swept the nation. I like my truck because it lets me do things that I couldn't do otherwise (and trust my I have tried) such as buying building supplies, clearing out yard trash or getting landscaping equipment from point a to point b. The four wheel drive and high clearance has also been invaluable in more than a couple blizzards.

What I don't like is the gas mileage. The truck has a 25 gallon tank and generally gets just under 14.5 miles per gallon if I do a fair amount of highway driving. At today's prices, this really hurts the wallet, to say nothing about contributing to the global oil problem.

So, on the last tank of gas, I went totally against my nature and changed all of my driving habits to be just about as conservative as I could manage. I accelerated slowly from every stop, coasted as much as possible, and kept my speed under 60 mph on the highway (which is a big deal -- the speed limit on the highway I have to drive to get anywhere is 75). The first thing I noticed was just how little the big V8 had to work in order to maintain a 55 mph cruising speed on the highway. With any downhill grade at all, I wouldn't even have to push the accelerator. Most of the time, I applied just about as little pressure as I could manage. I have to say as well, that it really didn't add a lot of time to my travels and I just felt so much more tranquil as a result of the slower speeds and easy acceleration. In addition to all of this, September is a beautiful month in Colorado and I kept the air conditioner off.

Well, even before filling up the tank in order to check the math, I knew something was different. Under normal circumstances, my gas light comes on somewhere between 280 and 320 miles. This time, though, at 350 miles, I still had about a quarter of a tank of gas. It turns out that the gas light didn't come on until 412 miles and I didn't fill up until 450. A calculation showed that I had used fuel at a rate of 19.3 mpg. This may not seem like good gas mileage to people driving cars, but it represents something like a 34% improvement over what I have gotten historically. I was able to go 1/3 further on a tank of gas just by slowing down, not running the AC, and not taking off from every stop light like I'm in a race.

My wife was not able to duplicate my successes in her car. I suspect that larger vehicles with big engines and poor aerodynamics have the most to gain from this regime. Still, I was not expecting anything like a 34% improvement.

Friday, August 19, 2005

Building libgcj.dll for MinGW with GCC 4.1

Here's some notes from my experience building libgcj.dll for MinGW using the GCC 4.1 (May 15, 2005 snapshot). This required a good deal of effort for me to figure out since quite a few things have diverged since the last reported sighting I could find of a working libgcj.dll.

Note that this entire process was done using a cross compiler hosted on Linux.

First, it should be noted that I upgraded libtool prior to building the DLL. When I get some time, I'll rebuild it with pristine sources and make sure it works without this step. The basic process to upgrading libtool is:
  • Copy libtool.m4 from a newer libtool distro to the root gcc source directory
  • Run autoconf (version 2.59) followed by automake (version 1.9.3) in the subdirectories that will be built. Do not regenerate the config on the root directory unless if you make special arrangements to regenerate it with autoconf version 2.13.
  • In the libjava target, you will manually have to patch the generated libtool after it gets created. You will need to change the "compiler_c_o" property in the GCJ section to "yes". This is line 7278 of the version of libtool I used. Not doing this will cause problems when the Makefile tries to compile resources. There has got to be a better way to make this work, but I am not terribly familiar with libtool and didn't look into it.
My primary motivation for upgrading libtool was to see if it would just automagically generate the dll for me. Sadly, this didn't work but I think it tried. With that being the case, it is probably ok to skip the libtool upgrade altogether.

I also ran into a problem with the sequence of the build. During the first pass build, the gnu-java-beans.lo file is generated prior to the most of its classfiles being compiled. Because of this, it only contains a handful of classes, which causes a lot of undefined references when building the dll later. I think this is a general problem that just doesn't manifest very often because the java.beans.* API is very rarely used in practice. A work-around is simple enough. After you build it once, just delete the generated gnu-java-beans.lo and rerun make. Since all of the class files are present the output file will be created as expected. You should see that the backing .o file(s) are much larger the second time around.

The next step is to create the actual dll. You should be aware that this is an extremely memory intensive operation. The memory usage of ld tops off at about 630MB on my machine. If you don't have at least this much physical memory available to ld, your machine could thrash for hours.

I used the following script to create the dll:


mkdir libgcjobjs
cd libgcjobjs
ar x ../$LIBGCJ_A
cd ..

find libgcjobjs -name '*.o' > libgcjobjs.list

i686-pc-mingw32-ld --shared -Bdynamic -e _DllMainCRTStartup@12 -o libgcj.dll --out-implib libgcj.a /.1/home/tlaurenzo/gcc_cross/bin/../lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/lib/dllcrt2.o -L~/gcc_native/i686-pc-mingw32/lib -L/.1/home/tlaurenzo/gcc_cross/bin/../lib/gcc/i686-pc-mingw32/4.1.0 -L/.1/home/tlaurenzo/gcc_cross/bin/../lib/gcc -L/home/tlaurenzo/gcc_cross/lib/gcc/i686-pc-mingw32/4.1.0 -L/.1/home/tlaurenzo/gcc_cross/bin/../lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/lib -L/home/tlaurenzo/gcc_cross/lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/lib --export-all-symbols --enable-runtime-pseudo-reloc --allow-multiple-definition `cat libgcjobjs.list` -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lm -lgdi32 -lws2_32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt

(This script is just for demonstration purposes. You will obviously need to update all of the paths appropriately)

To build programs that link to the dll, you will need to use some extra switches:

i686-pc-mingw32-gcj --main=Test -L. -o test.exe -Wl,--enable-runtime-pseudo-reloc

If trying to duplicate this work, note that I am not working on pristine sources. In particular the changes described in the mailing list thread entitled "Linker name conflicts due to optimization in gjavah" are critical for this to work.