1. 25 Aug, 2019 1 commit
  2. 18 Aug, 2019 1 commit
  3. 16 Aug, 2019 4 commits
    • Release Manager's avatar
      Trac #18267: libgap for PermutationGroup · 8c985712
      Release Manager authored
      As remarked in [http://ask.sagemath.org/question/26590/add-generator-
      to-a-group-combine-generators-of-two-groups/ this question on
      ask.sagemath.org] a lot of time is spent with pexpect when playing with
      permutation groups.
      In this ticket:
       - we interface libgap permutation group so that the following works
      sage: p1=libgap.eval("(1,2,3)")
      sage: p2=libgap.eval("(3,4,5)")
      sage: p1.sage()
      sage: G=libgap.Group([p1,p2])
      sage: G.sage()
      Traceback (most recent call last):
      NotImplementedError: cannot construct equivalent Sage object
       - we check that interesting GAP functions such as `ClosureGroup`,
      `AllBlocks`, are available from libgap
       - we use them in `PermutationGroup` inplace of the current gap version
      URL: https://trac.sagemath.org/18267
      Reported by: vdelecroix
      Ticket author(s): Erik Bray
      Reviewer(s): Frédéric Chapoton, Vincent Delecroix, Travis Scrimshaw
    • Release Manager's avatar
      Trac #28354: pexpect GAP interface: Handle errors when subprocess isn't wait()-ed by ptyprocess · 5b698dd6
      Release Manager authored
      As mentioned in #20178, pexpect used to leave zombie processes around
      upon EOF.
      Now that appears to be fixed.  Unfortunately, if the EOF occurs because
      the process was killed and wait()-ed by a different process, and not by
      pexpect itself, rather than just ignore the situation and set the
      process as closed, pexpect (really ptyprocess in this case) ''raises an
      exception'' and does not mark the process as terminated.
      Therefore any subsequent attempt to restart the GAP process tries again
      to call `isalive()` and just gets the same exception again.
      We should instead catch this exception and just force the process to be
      marked as terminated.
      URL: https://trac.sagemath.org/28354
      Reported by: embray
      Ticket author(s): Erik Bray
      Reviewer(s): Volker Braun
    • Release Manager's avatar
      Trac #18312: Construction of a sparse matrix from sparse vectors does not exploit sparseness · 6fcbcf19
      Release Manager authored
      sage: n = 10^3
      sage: F = FreeModule(QQ, n, sparse=True)
      sage: v = F.an_element()
      sage: vectors = [v]*n
      sage: %time a = matrix(vectors, sparse=True)
      CPU times: user 2.01 s, sys: 38.4 ms, total: 2.05 s
      Wall time: 1.96 s
      Compare with the construction of the same matrix through an
      intermediate dictionary:
      sage: %time b = matrix(QQ, n, {(i,j): c for i,v in enumerate(vectors)
      for j,c in v.iteritems()}, sparse=True)
      CPU times: user 7.33 ms, sys: 124 µs, total: 7.46 ms
      Wall time: 6.06 ms
      sage: a == b
      Running `%prun` shows that the input vectors are converted to dense
      lists and back (gasp!), which gives a complexity of `n^2` instead of
      linear in the number of nonzero entries as would be expected.
      See also: #10312
      URL: https://trac.sagemath.org/18312
      Reported by: nthiery
      Ticket author(s): Travis Scrimshaw
      Reviewer(s): Vincent Delecroix
    • E. Madison Bray's avatar
      Trac #28354: Better handling of unhandled exceptions from pexpect when · 78f92f66
      E. Madison Bray authored
      process was already killed by a third party.
      pexpect's isalive() method now throws an ExceptionPexpect exception
      when the underlying process is dead and can no longer be found.  This
      is somewhat unmanageable unfortunately, so we add some extra wrappers
      around it to deal with the problem.
  4. 15 Aug, 2019 2 commits
    • Release Manager's avatar
      Trac #28338: wrong AC_LINK_IFELSE call in spkg-configure · d253db88
      Release Manager authored
      Arguments in AC_LINK_IFELSE there were totally mixed up.
      (Found by analogy of a similar error made on #28333, and caught
      by the reviewer.)
      It only worked by a "miracle".
      here is a fix.
      URL: https://trac.sagemath.org/28338
      Reported by: dimpase
      Ticket author(s): Dima Pasechnik
      Reviewer(s): Erik Bray
    • Release Manager's avatar
      Trac #27724: GAP Bernoulli function crashes on Cygwin with system GMP · 2ea8fa1d
      Release Manager authored
      It is crashing in various different (depending on the arguments I give)
      GMP functions for large integers, with segmentation faults in the
      assembly code.
      The situation is bad enough that it causes irrecoverable stack
      corruption and the process dies without Cygwin's exception handling even
      able to run.  I don't know that the problem is likely anything
      specifically to do with the `Bernoulli` function--that's just the
      context in which I've been able to reproduce the problem reliably.
      For the most part GAP otherwise works fine and most operations do not
      cause any problems at all, so it is likely a narrow case.  Also
      strangely, if I remove the `-m 64m` flag when running GAP (a default
      argument used when running `sage -gap`) the crash does not occur.
      Likewise if I provide a larger value like `-m 128m` it does not occur.
      I need to double-check exactly what the effect of this argument is.
      In the meantime, between this and #27721 it might be a good idea to
      disable use of the system GMP on Cygwin altogether until and unless I
      can get to the bottom of this.
      '''Upstream issue for GAP:''' https://github.com/gap-
      '''Upstream PR for GAP:''' https://github.com/gap-system/gap/pull/3435
      URL: https://trac.sagemath.org/27724
      Reported by: embray
      Ticket author(s): Erik Bray
      Reviewer(s): Samuel Lelièvre
  5. 14 Aug, 2019 32 commits