1. 26 Mar, 2015 1 commit
  2. 12 Sep, 2014 1 commit
  3. 06 Feb, 2014 3 commits
  4. 11 Dec, 2013 1 commit
  5. 26 Nov, 2013 1 commit
  6. 16 Oct, 2013 1 commit
  7. 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>
      4651c69f
  8. 17 Jun, 2013 2 commits
  9. 24 Dec, 2012 1 commit
  10. 30 Nov, 2012 1 commit
    • Iustin Pop's avatar
      Remove read instances from our Haskell code · 139c0683
      Iustin Pop authored
      
      
      It turns out that optimising 'read' derived instances (via -O) for
      complex data types (like OpCode, or the various objects) can be slow
      to very slow. Disabling such instances results in (time make
      $all_our_haskell_binaries) large compile-time savings and also smaller
      (unstripped) binaries (by a significant amount):
      
      ghc 6.12:        time  htools sz  hconfd sz
        with read:    4m50s 12,244,694 14,927,928
        no read:      3m30s 10,234,305 12,536,745
      ghc 7.6:
        with read:   14m45s 13,694,761 15,741,755
        no read:      3m40s 11,631,373 13,245,134
      
      So let's remove these instances, since we never use read in production
      for our custom types, and even when debugging in GHCI, we can simply
      use the 'show' representation to create the types, without needing to
      actually parse from strings.
      
      Note: for the very slow ghc 7.6 compilation time, I filled a ticket
      (ghc #7450), since it is surprising(ly slow).
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichele Tartara <mtartara@google.com>
      139c0683
  11. 12 Nov, 2012 1 commit
  12. 19 Oct, 2012 1 commit
  13. 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>
      93be1ced
  14. 28 Sep, 2012 1 commit
  15. 26 Sep, 2012 1 commit
  16. 04 Sep, 2012 1 commit
  17. 28 Aug, 2012 1 commit
  18. 19 Jul, 2012 1 commit
    • Iustin Pop's avatar
      Reorganise the lookup functions · 2fc5653f
      Iustin Pop authored
      
      
      Currently, the LookupResult, MatchPriority and related functions are
      locate in Loader.hs, since (so far) only hbal needs them in the
      selection of instances. However, with the new functionality on confd
      side, we need these functions there too, but we don't want to import
      Loader.hs (which pulls in lots of balancing-related code). So we move
      all these function to BasicTypes.hs, since that module is a leaf one,
      with no other dependencies.
      
      Unittests are slightly adjusted (but they are still tested under the
      'Loader' group).
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarAgata Murawska <agatamurawska@google.com>
      2fc5653f
  19. 22 Mar, 2012 1 commit
    • Iustin Pop's avatar
      Rework exit model · 88a10df5
      Iustin Pop authored
      
      
      While updating the confd code, I realised that we have _lots_ of
      duplication in the exit model for the various programs.
      
      So this patch attempts to abstract all the exits via a couple of new
      functions; sorry for the somewhat big patch, but I hope the payoff is
      worth the change: the actual exit conditions are much clearer.
      
      Note that the patch (also) moves the exitIfBad function to Utils.hs,
      since that is more logical.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      88a10df5
  20. 20 Mar, 2012 1 commit
  21. 13 Jan, 2012 2 commits