Posted by: Josh | April 27, 2010

Set Up Mercurial 1.5.1 on a Shared Host, Simplified

This procedure significantly removes the complexity of the set up detailed in a previous post.

  1. Download and extract this archive.
  2. Replace the ~/python/mercurial folder with an alternate build if necessary (this one is for x86_64/python2.4).
  3. Upload to your web host.
    * Note: The Mercurial CGI is designed to be run in a top-level domain or sub-domain.
  4. Ensure the following settings:
    ~/cgi-bin/hgwebdir.cgi has permissions 755 (rwxr-xr-x)
    ~/cgi-bin/hgweb.config has file paths changed relative to your server
    ~/.htaccess has AuthFile paths changed relative to your server
  5. Check to see if the site works.

To create a new repository, copy the example directory in the /cgi-bin folder to the same directory, fix it’s hgrc file in a text editor, and register this new project in hgweb.config. Configuration files:

  • hgweb.config – repository directory config
  • hgrc – per-project config

And that’s all. That was easy!

Posted by: Josh | April 26, 2010

Mercurial 1.5.1 Shared Server Upgrade Available

This release is a replacement to my previous distribution of pre-compiled Hg 1.3.1 scripts. Official Selenic Mercurial changelog here.

Mercurial 1.5.1 64-bit
Python 2.4 | Python 2.5

Mercurial 1.5.1 32-bit
Python 2.4 | Python 2.5

All packages contain these extensions.

*Picking the wrong version will lead to an error which should give you a hint to which is the correct version.

Upgrade Instructions

* Note: the following will momentarily disrupt service to your Mercurial server *

  1. Navigate to where your current Mercurial Python libraries reside. Mine is /home/jcarrier/python (from previous setup).
  2. Rename the python folder to python_1-3-1 (so it’s out of the way, but not deleted)
  3. Upload the python folder extracted from one of the above archives, making this the new python folder.
  4. Verify system is functional. Optionally delete python_1-3-1, or keep it around for nostalgic value. Done!

The .cgi script in your web directory doesn’t need to be replaced in this upgrade.

Installation Instructions

Follow my previous guide, but use this file in place of the one referenced.

I’ve recently gotten interested lately in “write once, run everywhere” apps for C++,  where we don’t have the luxury of a Java or similar virtual machine. The idea behind writing in C++ is to remove the dependency of my usual Java runtime environment, and instead use the wxWidgets project to build a C++ project which can be compiled for any architecture it supports (Windows/Linux/Mac). It may also offer performance benefits. In the following guide, I wanted the wxWidgets library statically compiled so that the compilation’s end result is one stand-alone executable which requires nothing else to run.wxwidgets

wxWidgets provides a large set of C++ libraries which will act as an intermediary between my code and operating system-specific calls, such as window handling, networking and disk access. Multi-platform support is then simply a matter of changing the wxWidgets library from one OS’s version to another.

Our ingredients:

Here’s my setup guide.

Read More…

Posted by: Josh | November 10, 2009

Setting up Mercurial on a shared server with FTP

Mercurial logo.png

This guide assumes you want to set up your own private Mercurial repositories, but want to do so on a server where:

  • you have no SSH or shell access, just an FTP connection/file manager 
  • it has Python 2.4 or greater already installed
  • is a Linux host (although a Windows host should work similarly with this procedure)

Previous guides I’ve come across on the web here and here require you to build Mercurial from source, which might not work depending on how strict your host is at giving you access to programs like the GCC compiler. Our solution here will be to package our own pre-compiled Mercurial binary.

A simpler installation technique is now available! Click here for details.
A new version of Mercurial has been released! Click here for details.


Read More…

Animated side-scrolling display and tray icon.

Animated side-scrolling display and tray icon.

The latest version of the ResNet Quota Monitor is still under works, but development is slow since I’m not staying on campus residence and thus allocate a lot less time to it than I used to. That being said, I’m considering to open this project up for others to contribute, so stay tuned…

This new version removes the “balloon” notification, in favour of a slidey toaster/growler that will have a standard look and feel across Windows, OS X and the various flavours of Java-compatible Linux. Here’s a sneak peak – with some icon work by Vince from .

Structually, the system is being re-done, with use of a more intuitive blackboard design pattern revolving around a built-in plug-in manager, for future plug-ins written by the community. It should be robust enough to be extrapolated for other colleges, or just as an application framework for any multi-component project.

And remember, if you ever have UBC ResNet, wireless, VPN, or even Campus Wide Login (CWL) problems, remember to visit the friendly staff at the UBC IT Help Desk.

Posted by: Josh | October 25, 2009

Sun Jersey and Google App Engine 1.2.6

You most likely have come across the following “warning” level log entry in your Google App Engine logs if you’ve been using Sun’s jersey-core 1.0.x jar and the Google App Engine 1.2.6 SDK:

com.sun.jersey.core.spi.component.ProviderFactory __getComponentProvider: The provider class, class com.sun.jersey.core.impl.provider.entity.XMLListElementProvider$App, could not be instantiated. Processing will continue but the class will not be utilized
java.lang.SecurityException: Unable to get members for class com.sun.jersey.core.impl.provider.entity.XMLListElementProvider$App
at java.lang.Class.getMethods(
at com.sun.jersey.core.reflection.MethodList.<init>(
at com.sun.jersey.core.spi.component.ComponentConstructor.getPostConstructMethod(
at com.sun.jersey.core.spi.component.ComponentConstructor.<init>(
at com.sun.jersey.core.spi.component.ProviderFactory.__getComponentProvider(
at com.sun.jersey.core.spi.component.ProviderFactory.getComponentProvider(
at com.sun.jersey.core.spi.component.ProviderServices.getComponent(
at com.sun.jersey.core.spi.component.ProviderServices.getProvidersAndServices(
at com.sun.jersey.core.spi.factory.MessageBodyFactory.getProviderMap(
at com.sun.jersey.core.spi.factory.MessageBodyFactory.initReaders(
at com.sun.jersey.core.spi.factory.MessageBodyFactory.init(
at com.sun.jersey.api.client.Client.<init>(
at com.sun.jersey.api.client.Client.<init>(
at com.sun.jersey.api.client.Client.create(
at com.socialjava.TinyFBClient.<init>(
at com.socialjava.TinyFBClient.<init>(
at com.socialjava.TinyFBClient.<init>(
Pictured: a broken jar.

A broken jar.

… and so on, for a lot longer.

In my case, this was due to the Jersey implementation that goes along side Social Java’s Tiny Facebook Client. The App engine admin panel reports that these exceptions are using up a lot of cpu time per request, which is never a good thing. Here’s how to silence them.



Read More…

Posted by: Josh | October 17, 2009

Mojarra JSF 2.0 RC2 and Google App Engine SDK 1.2.6

So a recent update to the Google App Engine SDK broke my JSF 2.0 web application. I received this message on local server start-up:

WARNING: Error starting handlersGoogle_App_Engine_logo_wtxt
Throwable occurred: java.lang.NoClassDefFoundError:
javax.naming.InitialContext is a restricted class. Please see the Google
App Engine developer’s guide for more details.

Apparently this was due to how JSF checks if it can use InitialContext first  (bug report)- by invoking it. Unfortunately, this sends GAE into a panic, since javax.naming.InitialContext is not one of the whitelisted JRE classes.

**Edit 3: for your convenience, I have pre-packaged this solution into its own .jar file. See bottom of post for further details.

Read More…

Posted by: Josh | September 29, 2009

Microsoft Info Session UBC

msft promo 2009If any UBC students are on campus October 1st, Microsoft would like to invite you to join them at a “Meet the Company” info session in the Forest Sciences centre.


More information:

Location: FSC 1005,n,n,n,n,y&bldg2Search=n&locat1=353

Posted by: Josh | April 19, 2009

Updates soon…

Well I told myself I’d regularly keep a log of what’s going on in my tech life – and clearly that hasn’t been happening. Basically due to the school term and a web prototype called GISH-N (Georeference Information System for Horticulture and Nature (a good use of acronyms)) which finally had given me a cause to try out CodeIgniter.

As I close up my books for the beginnings of summer, I plan to open up my laptop and bring you:

  • Team Development and CodeIgniter – 6 people, four months, and countless hours of code
  • ResNet Quota Monitor for UBC, v2 – meaner, cleaner, and slicker than before – will be available for Windows/Mac/Linux!
  • Distributed Computing Framework – working on a system to easily make your Java App rise into the clouds
  • Source Version Control – could  Mercurial be replacing SVN in my future?
    Can’t wait to learn about it? See the Google Tech Talk here:
    Props to Nathaniel for bringing this up

See you in the near future!

Posted by: Josh | December 12, 2008

The top 3 worst types of snow

Now usually I don’t mind snow, but there are certain types you’ll surely recognize that are just plain annoying. The following is my top three.

3. Slush: these little heaps of snow end up mixing with mud and other flavors of crud. You might consider to go outside, but prepare to get wet.

2. Ice: you’ll be taking baby steps as you strategically get from point A to B. You might as well be traversing a minefield, but you’ll get to where you want to go eventually.

Read More…

« Newer Posts - Older Posts »