An error occurred fetching the project authors.
  1. 15 Dec, 2017 1 commit
  2. 24 May, 2016 1 commit
  3. 23 May, 2016 3 commits
  4. 26 Apr, 2016 1 commit
    • Julien Muchembled's avatar
      amount_generator: speed up property initialization of generated amounts · 2b2db5cb
      Julien Muchembled authored
      By default, Base._edit first tests each property with getProperty, not to
      modify the object when values don't change. Here, getProperty costs a lot
      (in particular for categories) and rarely/never avoids the use of setters.
      
      So here, the main gain is to do something like _edit(force_update=1).
      As an additional small optimization, we directly use _setProperty instead of
      _edit. We also stop copying int_index from the Amount Generator Line because
      it's not useful enough:
      - float_index may be used instead
      - or dependency-based sorting is enough
      - as a last resort, properties can be fetched directly from the causality
        value, or dynamically with asPredicate and mapped_value_property_list
      2b2db5cb
  5. 12 Jan, 2016 2 commits
  6. 16 Oct, 2014 1 commit
  7. 03 Oct, 2014 1 commit
  8. 20 May, 2014 1 commit
  9. 15 May, 2014 1 commit
  10. 14 May, 2014 2 commits
    • Julien Muchembled's avatar
      Amount Generator: automatic sort based on application/contribution dependencies [2/2] · 73b325c5
      Julien Muchembled authored
      This implements dependency resolution to sort amount generator lines
      so that a base_amount is never contributed after it was applied.
      
      Before, it was required to sort manually using int_index or float_index, which
      can be difficult for a human when there are many lines spreaded over different
      containers (which are merged by composition). Another problematic case is when
      a set of lines is configured by a user (like discounts & fees) and must all be
      applied before other lines (taxes) that are installed elsewhere by the
      developer: how to reliably make sure the latter have index values that are
      already greater than those entered by the user ?
      
      Setting int_index or float_index is now only useful for lines:
      - with same reference: only the maching one with lowest index is taken
        into account (commit 68ec6bda)
      - applying to intermediate values of some base_amount
        (commit 10be013b)
      
      The difficult part to solve dependencies is that the calculation for a
      given base_amount may trigger the application of other base_amount, and so on
      recursively. In order to support this case, amount generator lines are first
      applied on a dummy amount, and getGeneratedAmountQuantity must be call
      unconditionally for all dependent base_amount. So optimizing like
      
        return 3 <= delivery_amount.getGeneratedAmountQuantity('base_amount/1') \
            or 1 <= delivery_amount.getGeneratedAmountQuantity('base_amount/2')
      
      is wrong except if 'base_amount/2' is only contributed by the movement or if
      you sort manually with indices.
      
      Dependency resolution has precedence over indices. But since the sort is stable,
      lines will remain sorted by index if it respects dependencies.
      73b325c5
    • Julien Muchembled's avatar
      Amount Generator: automatic sort based on application/contribution dependencies [1/2] · dd10a334
      Julien Muchembled authored
      Preliminary commit only to indent a big section of code.
      dd10a334
  11. 13 May, 2014 5 commits
  12. 10 Apr, 2014 2 commits
  13. 12 Dec, 2011 1 commit
  14. 25 Nov, 2011 1 commit
  15. 16 Nov, 2011 1 commit
  16. 15 Nov, 2011 1 commit
  17. 06 Sep, 2011 1 commit
  18. 31 Aug, 2011 1 commit
  19. 22 Feb, 2011 1 commit
  20. 26 Jan, 2011 3 commits
  21. 12 Jan, 2011 1 commit
  22. 07 Jan, 2011 1 commit
  23. 03 Nov, 2010 1 commit
  24. 25 Oct, 2010 1 commit
  25. 18 Oct, 2010 1 commit
  26. 15 Oct, 2010 2 commits
  27. 14 Oct, 2010 1 commit
  28. 13 Oct, 2010 1 commit