1. 12 Mar, 2013 9 commits
  2. 11 Mar, 2013 12 commits
  3. 08 Mar, 2013 2 commits
  4. 06 Mar, 2013 5 commits
  5. 05 Mar, 2013 7 commits
  6. 04 Mar, 2013 5 commits
    • Iustin Pop's avatar
      Switch Attoparsec parser from double to rational · d58d44f3
      Iustin Pop authored
      According to the documentation, “This function is almost ten times
      faster than rational, but is slightly less accurate. For 94.2% of
      numbers, this function and rational give identical results, but for
      the remaining 5.8%, this function loses precision around the 15th
      decimal place. For 0.001% of numbers, this function will lose
      precision at the 13th or 14th decimal place.”. What happens is that
      for our tests, it can happen that “Attoparsec.double (show a_double)”
      is quite different from “a_double”, such that we have much more than
      1e-12 absolute difference.
      Since our xm lists should not be too big, I think switching to
      rational is better. Next patch also changes the way we compare
      doubles, so maybe this patch is not really needed…
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichele Tartara <mtartara@google.com>
    • Iustin Pop's avatar
      Make the XmParser config test runtime more consistent · 1fe0e999
      Iustin Pop authored
      Currently, the test uses a frequency of 5 string/5 double/1 list for
      generating Arbitrary instances of ListConfig. However, the list case
      has simply a "choose (1, 20)" `vectorOf` arbitrary, which means it
      could recurse forever.
      Manually running only this test gives runtime as such:
      - ~100-200ms: very often
      - ~1-2s: often
      - ~5s: rare
      - ~20s: very rare (but I hit this when running < 30 times the test,
      On average, this makes this test one of the slowest ones, which is
      By changing to a sized generator, we can control the depth of the
      recursion, ensuring that we have a consistent runtime: out of 100
      runs, one is 229ms, one is 164ms, the other are 80-120ms.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
    • Iustin Pop's avatar
      Improve output of the XmParser config test · a7e76dc3
      Iustin Pop authored
      Currently, this tests and its helper function 'isAlmostEqual' uses
      plain booleans to signify failures, which means you can't really debug
      a failed test. The patch changes the call chain to use annotated
      properties all through, which results in messages like:
        Failing almost equal check
        Delta 3.725290298461914e-9 not smaller than 1e-12
        expected: 2.147785408767952e7
         but got: 2.1477854087679517e7
      which (IMHO) it's much more readable.
      The patch also replaces a 'fail' with 'failTest' in another test.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
    • Iustin Pop's avatar
      Fix node partial name matching in Haskell code · 91c1a265
      Iustin Pop authored
      This implements QffHostname and fixes the node listing (as well as
      export listing when filtering on node name).
      This bug was hidden by the fact that node listing with "gnt-node list
      aa" works if you don't have live queries (as it was originally), as
      the choosing of wanted nodes out of the config based on short names
      works. What didn't work was later post-filtering based on such short
      names (kind of duplicate, but that's how the code path is).
      By implementing QffHostname, we can have custom equality checks, like
      in the Python code. What I don't like is how convoluted the testing on
      various left/right combinations is, but I didn't find an easier way.
      The included unittest tests the partial filtering behaviour, and fails
      if the node name flag is not set to QffHostname.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
    • Iustin Pop's avatar
      Fix bug in group queries related to node/instance fields · e7124835
      Iustin Pop authored
      Since we use the primitive string type for group UUIDs, the group
      fields have a bug where we pass the group name as filter for node
      tests, whereas the nodes themselves use the group UUID. This results
      in zero node count, empty node list, and no instances being reported
      as assigned to groups.
      The patch fixes this and adds a test for the node count. It does some
      test generation improvement, and also cleans up whitespace issues in
      Test/G/Q/Query.hs (the functions case_queryNode_allfields,
      prop_queryGroup_noUnknown and case_queryGroup_allfields are unchanged
      but simply have indentation fixed).
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>