Friday, November 15, 2013

Using DeltaWalker with Mercurial for diffs

I bought a bundle of apps with a deal, and got DeltaWalker as part of the bundle. It's a reasonably decent diff tool, with the ability to do folder merging as well (rsync anybody ;) ). In terms of interface it's not bad, nice layout, colours, etc. I haven't used it much because most of my diff work is handled by my JetBrains tools as I'm developing.

For my current project I'm doing a reasonably complicated merge between two feature branches to bring them into alignment. I'm not a fan of Feature Branches as they impede Continuous Integration (FeatureToggles are a better approach), and the fact that my merge is complicated is living proof as to why they should be avoided. However due to particular circumstances a Feature Branch was unavoidable.

With part of the codebase there's not a 1-1 mapping of files. For example a class that was an inner class in Branch A is now in it's own Java file in Branch B. So it turned out to be easier to see what changed in Branch A in a file and port the concepts/semantics of the changes across to Branch B instead of just relying on a syntactical/textual merge. This worked really well because even though the implementation had diverged quite significantly, the interfaces were reasonably unchanged so my Branch A Tests changes merged to Branch B very easily, which would help inform me if I stuffed up the merge of a file. Another win for TDD.

Mercurial's diff commands were powerful enough to show me the changes for a file between the last merge point from Branch A to Branch B to the head of Branch A. However since I like my graphical diff tools, I wanted to try out DeltaWalker to see how good it was.

DELTAWALKER DOCUMENTATION SUCKS - It doesn't actually tell you HOW to integrate with your SCM tools. This is the WORST form of marketing and almost made me toss the tool. Fortunately I was able to figure it out.

When you select Hg in the DeltaWalker and point it to your Hgrc file it updates the file for you. Would be nice if it explains that it does that! I found out about it because I version control my Hg config (with Mercurial of course), and running a diff on the file, for another update I made caused me to see the changes.

cmd.dw = /Applications/

dw.executable = /Applications/
dw.args = $local $other $base -merged=$output
So one can then use Hg's extdiff functionality to load up the diffs.
$ hg dw -r $lastmerge:$branch_head file
It actually works well, but they guys behind the product need to update their docs!!

Finding the last merge point between branches in Mercurial

When merging between my development and release branches, I like to know what the last merge point was between the two so that I can do tasks like compile Release Notes or see if some code needs to be merged (based on tags).

I developed a little Hg alias that finds the last merge node between two branches.

lastmerge = !hg log -r "children(ancestor($1, $2)) and merge() and ::$2"

$ hg lastmerge BRANCH_1 BRANCH_2
In the example above, BRANCH_1 and BRANCH_2 are bookmarks. The alias makes use of Hg Revsets to find the latest merge node from BRANCH_1 into BRANCH_2

Wednesday, September 4, 2013

Getting Symfony2 form names working with AngularJS expressions

The default form field names generated by Symfony2's FormBuilder appear to not work work with AngularJS' form validation and directives like ng-show, unless one is proficient in Javascript, to deduce other syntatical options. The reason is that all the documentation examples for AngularJS expressions use Javascript's dot object notation, which can be confusing about what's really going on. A skilled JS reader might guess the answer to this issue before the end of this post. Judging by the amount of trouble people have had with this issue on various forums, the answer might not be so obvious. It had me stumped for a while.

So the conventional way to generate a HTML form via Symfony2 is:

In a Symfony Controller, generate the form:

    class MyController extends Controller {
       * @Route("/")
       * @Method("GET")
       * @Template
      public function indexAction() {
        $myEntity = new MyEntity();
        $form = $this->createForm(new MyEntityType(), $myEntity);
        return array("form" => $form->createView());
Using the following entity (Doctrine) class:
    class MyEntity {
       * @var string
       * @Assert\NotBlank(message="Please provide a contact name")
       * @ORM\Column(name="contactName", type="string", length=50)
      private $contactName;
Using the following type for form building:
    class MyEntityType extends AbstractType {
      public function getName() {
        return 'myEntityType';
Using the variable in a template (ie: <form name="{{ }}">) we get something like this (yes I'm using Twitter Bootstrap in my project):
    <div class="controls controls-row">
        <input id="myEntityType_contactName" class="ng-pristine ng-invalid ng-invalid-required" type="text"
            ng-model="myEntity.contactName" maxlength="50" required="required" name="myEntityType[contactName]">
      <span ng-show="myEntityType.myEntityType[contactName].$error.required" style="display: none;">
I wrote some Twig code to add the ng directives to the generated HTML. Those blocks use the form values generated by the builder. For example, Symfony renders the name attribute on the <input> tag and my extension code uses the same name string as part of the ng-show generation.

If one enters/deletes text the <span> is not shown/hidden.

Doing some research, I found some StackOverflow posts Symfony2 Form Component - creating fields without the forms name in the name attribute and Symfony2.1 using form with method GET. If we follow their advice and change MyEntityType to have getName() return an empty string, the resulting HTML is:

    <div class="controls controls-row">
        <input id="contactName" class="ng-pristine ng-invalid ng-invalid-required" type="text" ng-model="myEntity.contactName"
            maxlength="50" required="required" name="contactName">
      <span ng-show="formName.contactName.$error.required" style="">
Of course I had to manually give the form a name in the template ie: <form name="formName">

As pointed out in the first StackOverflow post above; it's the formatting of the name in Symfony/Component/Form/Extension/Core/Type/FieldType.php (or Symfony/Component/Form/Extension/Core/Type/BaseType.php if you're on Symfony 2.3) that's causing the problem.

I did not like those suggestions for a solution, but it did help me narrow down what was going on. I did not like the idea clobbering how Symfony generates forms, because we were having to adapt our server code (by altering the getName() method to deal with a client side technology issue. To me that seems wrong.

The reason that the field name was causing problems, is that AngularJS evaulates the string contents of the ng-show attribute as an expression, and in ng expressions, you can use square brackets to create arrays/objects. Consquently the square brackets that Symfony uses in the field name causes expession evaulation issues in AngularJS.

The solution is to use Javascript's property style accessors for objects (square brackets) over the dot object notation.. Thus we can have the square brackets in a string and there is no evalation issue.

    <div class="controls controls-row">
        <input id="myEntityType_contactName" class="ng-pristine ng-invalid ng-invalid-required" type="text"
            ng-model="myEntity.contactName" maxlength="50" required="required" name="myEntityType[contactName]">
      <span ng-show="myEntityType['myEntityType[contactName]'].$error.required" style="display: none;">
It all works. Just had to update my Twig code to generate the correct JS notation.

Alas, I can't take credit for the correct solution as someone else reported it as an issue against AngularJS. I guess that we think about, and write our code in one particular style for so long, that we forget about alternatives. However this post helps pull together a variety of threads about this topic, so hopefully the next person who has the problem just has to read this blog post.

Sunday, February 3, 2013

Remapping RaspBMC Remote Keybindings

I've updated my HTPC to be a Raspberry Pi that uses RaspBMC as the OS. The really hard part was integrating my existing RAID with the device (over USB) to serve up my media; that's a subject for another post.

Something that didn't quite work out of the RaspBMC box (and to be fair A LOT did work) was the Context Menu for XBMC. I like to call it the "right click" option if I was using a mouse. This was because my remote didn't have the default button that XBMC was expecting. As mentioned in a previous post I have a generic RC6 IR receiver that I had used the mceusb2 kernel driver. Looking at the remote config file for XBMC (/opt/xbmc-bcm/xbmc-bin/share/xbmc/system/keymaps/remote.xml) the ContextMenu is mapped to the <title> key. Looking in the LIRC config file for XBMC (/opt/xbmc-bcm/xbmc-bin/share/xbmc/system/Lircmap.xml) for a mceusb remote the "title" is mapped to the "Guide" key. Looking on my trusty remote diagram there was a Guide button, but why didn't it bring up the context menu?

Turns out that RaspBMC was using a different remote config in Lircmap.xml Using irw to see the remote codes I get:

16d 0 KEY_EPG devinput
16d 0 KEY_EPG_UP devinput
Searching Lircmap.xml for devinput I got a different <remote> profile, with no mapping for <title> So I added:
and the Context Menu is displayed.

Handy little util irw for figuring out remote config.