The default wiki for SourceForge projects is called Wikispaces. The CSS stylesheet configuration on the SourceForge Wikispaces is such that list items (HTML "li") are smaller than normal, and shrink as they are nested. Top level list items are smaller than I would care for, and by three or four levels of nesting they are unreadable. This has bugged me for a while, but today I was trying to create a page which had up to five or so levels of nesting (to represent a directory tree) and decided to see if I could fix this.

Using the wonderful Web Developer extension for Firefox I was able to pinpoint the source of this shrinkage, this line of http://static.sourceforge.net/css/sfx.php?secure=0&20080417-1657:

#frame li, #fadbtm li { font-size: 82.3%; }

Wikispaces uses about five CSS stylesheets including sfx.php, and they allow you to edit one of the other CSS stylesheets under Manage Space -> Look and Feel -> Edit your wiki stylesheet.

When editing that stylesheet Wikispaces restricts you to applying styles to the "wiki" class. Your wiki content is placed in an HTML div of class "wiki" and id "content_view". So I tried to add a line to the stylesheet which sets the font size for list items in class "wiki":

.wiki li { font-size: 100% }

However, there is a higher level div with id "frame" which the Wikispaces-provided CSS line applies to. Per the CSS specification styles applied to a specific id (#frame) take precedence over styles applied to a class (.wiki). As such the style for the id "frame" overrides my style for the "wiki" class.

Another read through the CSS spec reveals the important flag to override the normal priorities. And that did the trick, adding the following line eliminates the shrinking list items:

.wiki li { font-size: 100% ! important }

With the Oracle client 10.2.0.1.0 installer if you are automating the install with a response file, set UNIX_GROUP_NAME to something like say 'dba', then run the install but you are not in the dba group the install will fail with:

SEVERE:S_OWNER_SYSTEM_EPERM

I found nothing useful via a search for that error so I thought I'd post something. It would seem that you need to set UNIX_GROUP_NAME to a group you are in. Oddly none of the files that are written out end up owned by that group, so it doesn't seem like the installer really needs those privileges.

I'm trying to package the Oracle client for our internal packaging system, I'm not a DBA and wouldn't normally be a member of the dba group.

I was working on building the mysql ruby gem. My mysql install is in a non-standard location. I could get the gem to build with syntax like:

gem install mysql -- --with-mysql-config=/path/to/bin/mysql_config

However, I noticed that the resulting library did not embed the path to the mysql library, ldd on the mysql.so indicated:

libmysqlclient.so.16 => not found

I did not want to have to fiddle with setting an LD_LIBRARY_PATH at runtime. The way to address this is to pass -R or -rpath to the linker at compile time to embed the path to the library. The mysql gem uses the standard extconf.rb to build a Makefile to build the library. extconf.rb uses the standard Ruby mkmf library to do the heavy lifting. Thanks to the woeful lack of documentation for mkmf it took me several hours to figure out how to convince mkmf to include the proper option in the compiler flags. The answer is:

gem install mysql -- --with-mysql-config=/path/to/bin/mysql_config --with-dldflags="-Wl,-rpath,/path/to/lib/mysql"

--with-dldflags appends anything you specify to the DLDFLAGS variable in the generated Makefile. FYI, --with-ldflags overwrites DLDFLAGS with what you specify, possibly wiping out other linker flags you want to keep. Also FYI, the -Wl,-rpath,etc. syntax is required to pass the linker option through the compiler.

ldd now shows that the path is embeded in the resulting mysql.so:

libmysqlclient.so.16 => /path/to/lib/mysql/libmysqlclient.so.16 (0x00002ad5e81d1000)

Speaking of Perl, Ruby and sorting, sort in both Perl and Ruby allow you to specify a code block to implement your own arbitrary sorting routine. Perl's documentation shows you how you can define this as a subroutine and just reference the subroutine when you call sort. This is handy both for re-use and when your sort routine is complex and doesn't easily fit on one line. Ruby's sort documentation? Eh, no mention of such a thing.

In fact it is possible, but delves into a whole area of Ruby that is somewhat under-documented. The trick is that sort wants a code block, but code blocks are not first class entities. You can't name and reference a code block. However, Ruby has a couple of similar entities, Proc and lambda, that can be converted to/from code blocks and can be named and referenced. The unary ampersand operator will convert a Proc or lambda to a code block. The syntax works like this:

names = [
  {:fname => 'John', :lname => 'Smith'},
  {:fname => 'Jane', :lname => 'Smith'} ]

sorter = lambda do |a,b|
  [a[:lname], a[:fname]] <=> [b[:lname], b[:fname]]
end

names.sort(&sorter)

When sorting complex structures in Perl is is common to use syntax like:

sort { $lname{$a} <=> $lname{$b} || $fname{$a} <=> $fname{$b} } @names

The Perl sort documentation lists examples with this syntax. True to form the Ruby sort documentation doesn't show examples of anything that complex. Best I can tell anything like this doesn't work in Ruby:

a <=> b || c <=> d

Any way I write that I get back the result of the first comparison, even if the result is zero (which should trigger a fall-through to the second comparison).

Since Ruby's Array implements <=> you can achieve the desired result with:

[a, c] <=> [b, d]

A couple of MacPorts errors I just encountered:

Error: Unable to execute port: can't read "frameworks_dir": no such variable

I had version 1.6 and it seems the recommendation to fix this is to update to 1.7 (via port selfupdate). I started port in interactive mode, ran selfupdate, then tried my install again and got:

Error: Unable to open port: can't read "porturl": no such variable

I wasn't sure if it was necessary, so I ran 'sync' at this point. The install then failed with:

Error: Unable to execute port: can't read "PortInfo(name)": no such element in array

Couldn't find any info about that online, so on a lark I exited port and restarted it, after which the install proceeded.

It's a mystery to me why the FreeBSD folks don't publish this better (for example, a mention on http://www.freebsd.org/security/ doesn't seem unreasonable), but FreeBSD has an easy to use system for updating the base system:

# freebsd-update fetch

Review the changes to be applied, then

# freebsd-update install

If there's a new kernel in there then you should reboot. That's it. Not quite sure when this was fully integrated into the base OS, I'm only an occasional FreeBSD user, you used to have to install a few ports to get this working.

Even their official security advisories don't mention this, instead referring to PITA methods of patching and building from source. I installed the OS via pre-built binaries, why would I then update by patching the source? Sigh.