@boblet

Dec 09

[video]

Dec 02

[video]

Nov 06

“Any sufficiently advanced incompetence is indistinguishable from malice.” —

Clark’s Law

Via Adactio’s “Burge Pitch Torrent”.

Nov 04

“The craftman’s spirit, I think, imbues people with a sense of beauty, as in elaboration, delicacy, care, simplicity (words I often use).” —

Kenya Hara On Japanese Aesthetics

Kenya Hara, creative director of MUJI and professor at the Musashino Art University, talking about 職人気質 (taking pride in your work) felt by Japanese people. Translated by iA for a New York article “Beauty and the Bento Box”.

Oct 31

[video]

Oct 28

Troubleshooting MySQL installation on Snow Leopard

I installed MySQL 5.1.39 via Hivelogic’s “Compiling MySQL on Snow Leopard” and got the dreaded

$ mysql
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/tmp/mysql.sock’ (2)

I eventually tracked the problem down, but MySQL doesn’t make things easy. This error can be from a bunch of things, so here’s what helped

• Check Console.app—this was showing MySQL trying to start (and failing) every 10 seconds (ouch), but it gave me a pointer to the MySQL log file:
  

  10/27/09 10:51:24 PM	com.mysql.mysqld[5198]	091027 22:51:24 mysqld_safe Logging to '/usr/local/mysql/var/My_HD.local.err'.

• Check the MySQL error log—unfortunately this is inside a chowned folder so I needed to sudo tail -n100 /usr/local/mysql/var/My_HD.local.err
• Check your my.cnf—the log pointed to an error in my /etc/my.cnf file. I should have tried checking or removing the text I added earlier

After fixing the typo, I needed to make a link from the actual mysql.sock file (in /private/var/mysql/mysql.sock) to where mysql expects it (which is actually /private/tmp/mysql.sock, as /tmp and /var actually map to /private/tmp and /private/var respectively):

$ ln -s /private/var/mysql/mysql.sock /private/tmp/mysql.sock

Oct 23

Installing gibak on Snow Leopard

Gibak is an OCaml wrapper for Git to make it easier to use Git for backing up your hard disk, or parts thereof. I probably should just start paying for DropBox already, but I still feel a little worried about moving eg ~/Library/ into the Dropbox folder and symlinking it.

Unfortunately the original author Mauricio Fernandez hasn’t been maintaining it recently, but the wonders of Github mean it’s had several collaborative bug fixes. I’ve used a fork by Chris Johnsen.

However I had some trouble getting it to compile, with this error:

*** omake: reading OMakefiles
*** omake: finished reading OMakefiles (0.09 sec)
- build . find-git-repos.o
+ ocamlfind ocamlopt -package fileutils,unix -warn-error A -dtypes
-inline 10 -S -I . -c find-git-repos.ml
File "find-git-repos.ml", line 1, characters 0-1:
Warning X: bad source file name: "Find-git-repos" is not a valid module name.
File "find-git-repos.ml", line 1, characters 0-1:
Error: Error-enabled warnings (1 occurrences)
*** omake: 23/49 targets are up to date
*** omake: failed (0.22 sec, 0/3 scans, 1/7 rules, 1/83 digests)
*** omake: targets were not rebuilt because of errors:
  find-git-repos.cmi
     depends on: find-git-repos.ml
  find-git-repos.cmx
     depends on: find-git-repos.ml
  find-git-repos.o
     depends on: find-git-repos.ml

After getting completely stuck I asked Chris for help, and he very kindly figured out my problem. Due to a change in ocaml-fileutils-0.4.0 I needed to change line 8 of gibak oametastore.ml from open FileUtil.StrUtil to:

open FileUtil

I also needed to change the OMakeFile to include the path to ocaml-fileutils and suppress the module name error ocaml-3.11.0 generates:

INCLUDES += /opt/local/lib/ocaml/site-lib/fileutils
OCAMLFLAGS += -warn-error x

Chris is adding these changes to his gibak fork, so you should just clone that and take it from there (see the wiki for more info). Thanks again for your help Chris, and also to Jay Levitt!

Oct 22

Installing omake-0.9.8.5, ocaml-fileutils-0.4.0 on Snow Leopard

For omake I was getting the error:

Undefined symbols:
  "_caml_sync", referenced from:
      _camlOmake_exec__28 in[==================================================================================== exec.a(omake_exec.o)01161
ld: symbol(s) not found
collect2: ld returned 1 exit status
File "caml_startup", line 1, characters 0-1:
Error: Error during linking

I commented out the reference to caml_sync in omake_exec.ml:

(* external sync : unit -> unit = "caml_sync" *)

Next, I was getting this error for ocaml-fileutlis (which isn’t in MacPorts yet):

/usr/bin/install: illegal option -- t
make: *** [install] Error 64

The makefile contained:

/usr/bin/install -c -d /usr/local/share/doc/ocaml-fileutils/api
/usr/bin/install -c -m 644 -t /usr/local/share/doc/ocaml-fileutils/api \

It seems that -t (which is used for denoting the destination directory) isn’t an option in MacOS X’s /usr/bin/install, so I edited the makefile from:

	$(INSTALL) -d $(htmldir)/api
	$(INSTALL_DATA) -t $(htmldir)/api \
	  $(wildcard $(BUILDDIR)/fileutils.docdir/*)

to:

	$(INSTALL_DATA) $(wildcard $(BUILDDIR)/fileutils.docdir/*) \
	$(htmldir)/api

Seems to have worked…

Oct 16

[video]

Sep 04

Block-level links, HTML5 and Firefox

Update: Unfortunately this doesn’t seem to be a magic bullet, and there are still problems with the dreaded packet boundary bug. See the Mozilla bug report for more info.

Recently I’ve been experimenting with wrapping block-level elements in <a> (so-called block-level links), as you can see in this page’s header. This has several benefits:

• several elements can of course be linked at once, such as an image and it’s caption—historically we’d need to link both the image and caption text individually
• Internet Explorer 6 doesn’t allow CSS :hover etc effects on anything other than <a>
• making block-level elements into links increases the clickable area

Changing <a> from an inline element to something like <del> that can appear pretty much anywhere is fine in the spec, but what about browser support? Luckily, this behaviour is already unofficially supported in current browsers. However I recently discovered a bug in Firefox; if the block-level link contains any of the new HTML5 semantic elements bizarre stuff happens (Bugzilla: #514122, test case):

Code sample

<div>
  <a href="/">
  <hgroup>
    <h1>Title</h1>
    <h2>Subtitle</h2>
  </hgroup>
  </a>
</div>

In Firefox (DOM asplode)

<div>
  <a href="/">
  <hgroup>
    </hgroup></a><h1><a _moz-rs-heading="" href="/">Title</a></h1>
<a href="/">    <h2>Subtitle</h2>
  
  </a>
</div>

While the contained content is still linked, the HTML5 element is prematurely closed, the link becomes inline for the first element following the HTML5 element, and everything after that is wrapped in a new link. Kind of defeats the purpose huh. This is especially important for <hgroup>, a new HTML5 element that’s going to be block-linked a lot.

Luckily, there is an easy solution; add a <div> wrapper

Code sample with wrapper <div>

<div>
  <a href="/">
    <div>
      <hgroup>
        <h1>Title</h1>
        <h2>Subtitle</h2>
      </hgroup>
    </div>
  </a>
</div>

In Firefox (all is right in the DOM)

<div>
  <a href="/">
    <div>
      <hgroup>
        <h1>Title</h1>
        <h2>Subtitle</h2>
      </hgroup>
    </div>
  </a>
</div>

Wow that was easy! Lucky it wasn’t an IE bug huh ;-) There are some other things to watch out for too. Link styles don’t inherit to block-level elements, so you need to explicitly declare them on the contained elements, or use eg {background: inherit;}. This also includes the browser default {text-decoration: underline;} (in Safari browser link styles are applied, but user link styles also need to be declared). Finally, Firefox handles tag mismatch errors in block-level links … poorly. When in doubt, validate.

So in conclusion, if your block-level links contain HTML5 structural elements, add a wrapper <div>. If you have any questions, feedback, or have found a mistake, please let me know via Twitter (@boblet)…