1. 13 Jan, 2014 1 commit
  2. 30 Sep, 2013 1 commit
  3. 10 Sep, 2013 1 commit
    • Jose A. Lopes's avatar
      Wrap 'Set' in 'ListSet' for the opcodes · 4651c69f
      Jose A. Lopes authored
      In what Haskell to Python opcodes are concerned, a Haskell 'Set' is
      translated into a Python 'list'.  In other words, currently, opcodes
      that handle sets of parameters are actually handling lists because
      this is how sets are currently encoded.  This patch introduces a new
      type called 'ListSet' that wraps a Haskell 'Set' and it is used to
      represent on the Haskell side a Python 'list' without duplicate
      elements.  This patch also updates the respective opcode parameters
      and updates the opcode tests.
      Signed-off-by: default avatarJose A. Lopes <jabolopes@google.com>
      Reviewed-by: default avatarKlaus Aehlig <aehlig@google.com>
  4. 08 Aug, 2013 1 commit
    • Jose A. Lopes's avatar
      Fix opcodes and parameters · 5cbf7832
      Jose A. Lopes authored
      * fix some return types in opcodes and some types and documentation in
      * fix serialization of the default value of the 'name' parameter in
        the opcodes related to tags when tag kind is 'cluster'
      * revert changes to 'pShutdownTimeout'' and its references because the
        master branch tried to fix this inconsistency but was unable to fix
        all the references to this parameter
      Signed-off-by: default avatarJose A. Lopes <jabolopes@google.com>
      Reviewed-by: default avatarThomas Thrainer <thomasth@google.com>
  5. 07 Aug, 2013 1 commit
  6. 01 Jul, 2013 2 commits
  7. 07 Jun, 2013 1 commit
  8. 03 Jun, 2013 2 commits
  9. 12 Mar, 2013 1 commit
    • Iustin Pop's avatar
      Add simple Ip4Address/Ip4Network types · 3a991f2d
      Iustin Pop authored
      This patch adds some very simple IPv4 address/network types, and uses
      them in the 'Network' config object.
      We need these in order to properly compute the reserved IP addresses,
      without depending on an external library (which I haven't found, by
      the way). Currently the only operation supported is 'get next IP
      address', which is enough for us.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarHelga Velroyen <helgav@google.com>
  10. 04 Mar, 2013 1 commit
  11. 07 Feb, 2013 1 commit
  12. 27 Dec, 2012 2 commits
  13. 19 Dec, 2012 1 commit
  14. 18 Dec, 2012 1 commit
  15. 17 Dec, 2012 1 commit
  16. 06 Dec, 2012 1 commit
  17. 03 Dec, 2012 1 commit
  18. 30 Nov, 2012 1 commit
  19. 21 Nov, 2012 1 commit
  20. 20 Nov, 2012 1 commit
  21. 16 Nov, 2012 1 commit
  22. 12 Nov, 2012 1 commit
  23. 22 Oct, 2012 2 commits
    • Iustin Pop's avatar
      Improve message for (==?) operator · 41eb900e
      Iustin Pop authored
      After seeing how nice HUnit formats the error message on failed
      'assertEqual', I think we can do better with ==?. Currently it says
      (on one line): "Expected equality, but 1 /= 2".
      This patch changes the code to format it similar to HUnit:
        Expected equality, but got mismatch
        expected: 1
         but got: 2
      (on three lines). This makes it more clear what is the expected and
      what is the wrong value.
      A few tests have been modified to ensure that the expected value is
      the second argument to ==?. This is different than HUnit, but makes
      more sense in the operator version (I think).
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarHelga Velroyen <helgav@google.com>
    • Helga Velroyen's avatar
      Annotated inequality operator for unit test properties · dddb2bc9
      Helga Velroyen authored
      This includes:
       * The operator (/=?), which checks for inequality and prints
         an error message if it encounters equality. (Basically the
         negation of the (==?) operator).
       * Application of this operator in the test property
      Signed-off-by: default avatarHelga Velroyen <helgav@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
  24. 17 Oct, 2012 1 commit
    • Iustin Pop's avatar
      Generalise the Result type · 93be1ced
      Iustin Pop authored
      Currently, our error monad—Result—has a plain string error type. This
      is not good, as we don't have structured errors, we can't pass back
      proper error information to Python code, etc.
      To solve this, we generalise this type as 'GenericResult a', and make
      Result an alias to 'GenericResult String' for compatibility with the
      old code. New error hierarchies will be introduced as different
      types. Furthermore, we generalise our helper functions too, so that
      they can work on any 'GeneralInstance a' type, not only Result.
      There are two small drawbacks to this generalisation. First, a Monad
      instance requires (at least for the way we use it) a 'fail :: String
      -> m a' instance, so we need to be able to build an 'a' value from a
      string; therefore, we can implement the Monad instance only for a
      newly-introduced typeclass, 'FromString', which requires the needed
      conversion function. Second, due to the fact that 'String' is a type
      alias (for [Char]) instead of an actual type, we need to enable the
      FlexibleInstances language pragma; as far as I know, this has no
      significant drawbacks.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
  25. 05 Sep, 2012 4 commits
    • Iustin Pop's avatar
      Further hlint fixes · 5b11f8db
      Iustin Pop authored
      Commit 2cdaf225, “Re-enable standard hlint warnings”, got it almost
      right. The only problem is that (confusingly) the default set of hints
      is not in HLint.Default, but in HLint.HLint (it includes Default and
      some built-ins).
      After changing the lint file to correctly include the defaults, we had
      another 128 suggestions:
        - Error: Eta reduce (2)
        - Error: Redundant bracket (4)
        - Error: Redundant do (17)
        - Error: Redundant lambda (7)
        - Error: Redundant return (1)
        - Warning: Avoid lambda (2)
        - Warning: Redundant $ (42)
        - Warning: Redundant bracket (35)
        - Warning: Use : (1)
        - Warning: Use String (4)
        - Warning: Use camelCase (10)
        - Warning: Use section (3)
      which are fixed by the current patch. Note that the 10 "Use camelCase"
      were all due to hlint not “knowing” the idiom of ‘case_’ (it does for
      ‘prop_’), for which I filled
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
    • Iustin Pop's avatar
      Add some unittests for node queries · b9bdc10e
      Iustin Pop authored
      These new tests check that:
      - no known fields return unknown
      - any unknown field returns unknown
      - the type of the fields is consistent between the getters and the
        field definition
      - the length of each result row corresponds with the number of fields
        queried, and the length of the field definitions returned
      - the length of the rows corresponds to the number of nodes
      - querying fields on empty fields returns all fields
      Finally this patch found a bug, in that the pinst_list/sinst_list
      fields were declared as QFTNumber (copy-paste error from
      pinst_cnt/sinst_cnt), yay!
      I also changed genEmptyCluster to ensure that it generates unique node
      names, so that the number of result rows is consistent with what we
      requested, and switched ResultEntry from a normal constructor to
      record syntax, so that we can extract the fields without having to use
      pattern matching.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
    • Iustin Pop's avatar
      Add a small 'passTest' helper · 2e0bb81d
      Iustin Pop authored
      This is symmetric to failTest, and allows us to use it in cases where
      we need to return a property.
      While replacing 'property True' with it, I saw a case where we can
      simplify the use and thus reworked that check.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
    • Iustin Pop's avatar
      Add a test helper for simple JSON serialisation testing · 63b068c1
      Iustin Pop authored
      While adding yet another JSON serialisation test, I realised that this
      can be trivially abstracted; hence this patch, replacing both simple
      versions (readJSON . showJSON == id) and the standard version (with
      different error messages) across the tests with a single function
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
  26. 04 Sep, 2012 4 commits