MooTools setOptions() nullifies object references

I bumped up into a problem where the object references where resolved as object copies when I passed them to class instances. That might sound easy to resolve, but unfortunately I was already deep in code and it was difficult to see this. Therefore, here’s a little explanation for those who are facing the same frustrating issue.

Say, you have variable ‘a’ and you want to pass it to a MooTools class B instance during creation. In the easiest case you’d use new B({ myReference: a}) and trust on MooTools’ Class.setOptions() to minify the need of code lines. This is what you should do… well at least that’s what I did and in this case it was a mistake.

It turns out that Class.setOptions() merges it’s arguments to this.options and then takes copy of them via $merge(). That means that any variable references you pass to setOptions() will get copied to this.options and.. well, that’s it. See lines 1170-1173 in uncompressed version of MooTools 1.2:

var Options = new Class({
    setOptions: function(){
        this.options = $merge.run([this.options].extend(arguments));

That effectively nullifies the benefits of Class.setOptions() if you want to pass in variable references..

Here’s a longer example to clarify (use Firebug):

  // The most basic MooTools class that implements options
  // ref is a variable meant for pointing at given object
  // (won't do that, however)
  var B = new Class({
    Implements: Options,
    options: {
      ref: null
    },
    initialize: function(options) {
      this.setOptions(options);
    }
  });

  // Ok let's create an instance that we can pass to B
  // It's similar with all sorts of variables
  var A = new Class({
    initialize: function() {
      this.somevar = 'untouched';
    }
  });
  var a = new A();

  // Create an instance of B and give it somevar as reference
  var b = new B({ ref: a });

  // prints out "untouched" as should
  console.log(b.options.ref.somevar);

  // Let's change the variable (direct access, bad)
  a.somevar = "changed";

  // b's reference should still point to a, right?
  // In that case the following should print "changed",
  // but because our reference object was copied instead
  // of retaining reference to it, we just get "untouched"
  console.log(b.options.ref.somevar);

I don’t know why MooTools wants to make a copy of arguments in setOptions() – propably for performance reasons.

Wrong swap UUID after hibernation in Feisty

I’ve been using uswsusp for suspending/hibernating my Ubuntu Feisty laptop but suddenly it failed to resume from disk hibernation (blank screen with blinking cursor). I booted up in restoration mode and Ubuntu reported that it couldn’t restore the snapshot. After pressing enter to continue, the system booted up just fine, skipping the snapshot restoration as supposed. The startup problem vanished, but it brought up a new one when trying to hibernate:

>>> sudo s2disk
Could not use the resume device (try swapon -a)

Of course, swapon also gives a problem:

>>> sudo swapon -a
swapon: cannot stat
/dev/disk/by-uuid/4a815ae8-fa5b-4265-826c-d777a723e87b:
No such file or directory

It seems that the UUID reference for swap is broken. Or is it the swap? At this point I did some Google research and it turned out the behaviour was because of an Ubuntu Feisty bug, which causes the swap UUID change occasionally. It is closely related to hibernation, yet the cause remains unclear. To fix it, let’s do:

>>> free -m | grep -i swap
Swap:            0          0          0

Which indicates that the system doesn’t find swap at all (because of wrong UUID). To find correct one:

>>> sudo fdisk -l | grep swap
/dev/sda6      10669   10917  2000061 82  Linux swap / Solaris

Find your swap there and go for:

>>> sudo vol_id /dev/sda6
ID_FS_UUID=083d41f0-de57-48d4-92eb-aefde8fd6ec9

Then you’ll just have to edit it in /etc/fstab and hibernation should work again. You could also try restoring the original snapshot by editing:

>>> sudo nano /etc/initramfs-tools/conf.d/resume

and correcting the reference there also. I didn’t test this myself, however.

That should do it, but don’t get too excited: some report that the UUID keeps changing even after the fix, and it has to be manually changed over and over again. Luckily, I haven’t experienced such behaviour (yet!) and it’s quick to fix (though you might lose ability to hibernate, which is a really bad thing).