1. 01 Apr, 2012 3 commits
  2. 31 Mar, 2012 1 commit
  3. 28 Mar, 2012 5 commits
  4. 22 Mar, 2012 3 commits
  5. 21 Mar, 2012 1 commit
  6. 18 Mar, 2012 3 commits
  7. 04 Mar, 2012 1 commit
  8. 29 Feb, 2012 3 commits
  9. 27 Feb, 2012 2 commits
  10. 24 Feb, 2012 4 commits
  11. 23 Feb, 2012 1 commit
  12. 22 Feb, 2012 2 commits
  13. 13 Feb, 2012 1 commit
  14. 11 Feb, 2012 3 commits
    • rschlatte@1c010e3e-69d0-11dd-93a8-456734b0d56f's avatar
    • rschlatte@1c010e3e-69d0-11dd-93a8-456734b0d56f's avatar
      Add FuncallableStandardClass.java · 79880a29
      ... make classes generic-function and standard-generic-function
          instances of funcallable-standard-class, per AMOP.
    • mevenson@1c010e3e-69d0-11dd-93a8-456734b0d56f's avatar
      See #196: further patch for STABLE-SORT from Jorge Tavares. · 29fd164f
      easye: still seeing the ANSI failures, but this is a much more
      plausible "final" implementation with the appropiate optimizations
      which should be easier to fix modulo the possible hairy macro
      debugging part.  But that's why they call it trunk, right?
      I send in attach a patch with further improvements to sort and
      stable-sort for sequences other than lists.  In short, the patch
      includes a merge sort for vectors. To allow different types I've
      written the algorithm using macros and these generate the appropriate
      code according to the vector type. This way the algorithm is in a
      single place avoiding duplication of code. The macros also take care
      of the situation of when no key is present, avoiding the use of
      unnecessary funcalls. The quicksort algorithm was also refactored in
      the same way.
      I've tested the algorithms and they seem to be working correct. Stable
      sort is now considerably faster since the fix before converted the
      sequences to a list and used the sort-list function. I've made some
      benchmarking to verify how fast is sort and stable-sort. The tables
      with the results are also in a file sent in attach [1]. For
      stable-sort I've compare the current trunk version with the patched
      one while for sort I've compared 1.0.1, the trunk and with the
      patch. For unsorted vectors sort has a speed up of 7.5 from 1.0.1 and
      this considers only vectors of size 8 to 8192 (1.0.1 hits the
      worst-case quite fast). For stable-sort the speed up is around 90.2
      from vectors of size 8 to 32768. The sort functions become even faster
      for the nearly sorted vectors. I think the tables clearly show t he
      Naturally these benchmarks cannot be used to draw definite conclusions
      since they lack rigorous testing but I think they can provide some
      indications. With this patch, I think ABCL gets good performant
      sorting functions, especially for large vectors. As for lists, I
      haven't looked at them so probably they can also be improved (but I
      really don't know).
      [1] The tables result from the generation of simple-vectors of sizes 8
      to 524288 (powers of 2 from 3 to 19) with distinct integer: unsorted,
      nearly sorted (distances 0, 4 and 16), sorted and reversed sorted. The
      nearly sorted vectors were constructed by selecting pairs where they
      would swap with a neighbor at a certain distance. I did 100 runs and
      timed only the sorting operation. The tables contain the averages of
      the 100 runs. They were performed in an iMac (2.5GHz i5, 4GB) with Mac
      OS X 10.7.3.
      [1]: http://article.gmane.org/gmane.lisp.armedbear.devel/2220
  15. 09 Feb, 2012 1 commit
  16. 08 Feb, 2012 2 commits
  17. 07 Feb, 2012 3 commits
  18. 06 Feb, 2012 1 commit