Re: [sage-devel] Re: Building binaries...

On Sunday, May 8, 2016 at 6:19:17 PM UTC+2, William wrote: > > > b) modifying a shared library in the destination /tmp/sage-dev/ has no > > effect until you relink the binary/cython extension that uses it. > > Can you elaborate on b slightly? I don't understand for sure. > Say, you go to the

Re: [sage-devel] Re: Building binaries...

On Sunday, May 8, 2016 at 6:54:38 AM UTC+2, William wrote: > > time rsync -axH /projects/sage/sage-dev/ sage-dev/ > Thats fine. The only caveat is that rpaths are still pointing to the source. Therefore a) the copy stops working if you delete /projects/sage/sage-dev/ b) modifying a shared

Re: [sage-devel] Re: Building binaries...

On Sunday, May 8, 2016 at 6:19:43 AM UTC+2, William wrote: > > which is 593M. > Sounds a bit too small, the buildbot binaries are always about twice that. instantly prints out massive screenfulls of information -- with no > warning, and no indicator that hitting control+c is a bad idea.

Re: [sage-devel] Re: Building binaries...

On Saturday, May 7, 2016 at 8:51:40 PM UTC+2, William wrote: > > My use case is building Sage on SageMathCloud (Ubuntu 15.10 right now) > for people to develop on SageMathCloud (on the exact same machine). Then just put sage in the same path for everyone (with a private union mount), thats

[sage-devel] Re: Building binaries...

On Saturday, May 7, 2016 at 5:46:20 PM UTC+2, William wrote: > > I read that github page, but I don't know what binary-pkg actually > does. It compiles Sage in a long directory path. > For context, I used to (1) build a copy of Sage, (2) possibly > customize it, then (3) type > >

[sage-devel] Re: sage vs jupyter notebooks

A %%cython cell magic for commandline and Jupyter notebook is now at http://trac.sagemath.org/ticket/20562 (needs review) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

[sage-devel] Re: sage vs jupyter notebooks

Some of your complaints are just how the commandline currently works... On Thursday, May 5, 2016 at 2:46:10 PM UTC+2, vdelecroix wrote: > > * tab completion with jokers not supported (i.e. "*prime") > There is wildcard search: sage: *le_prim*? [ENTER] next_probable_prime > * the

[sage-devel] Re: What to do with that deprecation warning?

Thats an upstream bug... On Thursday, May 5, 2016 at 1:20:41 PM UTC+2, Simon King wrote: > > Hi! > > Trying to resume working in Sage, I get (in 7.2.beta3) the following > deprecation warning when trying to display some instance of an extension > class: > >

Re: [sage-devel] Deprecate the use of properties in all public API

On Wednesday, May 4, 2016 at 3:13:21 PM UTC+2, Erik Bray wrote: > > I don't think it's just "syntactic sugar". If anything it's setter > and *especially* getter methods that are backwards, but unfortunately > necessary in languages like Java that don't have a natural way to > interpose in

Re: [sage-devel] Deprecate the use of properties in all public API

On Wednesday, May 4, 2016 at 5:26:03 PM UTC+2, mmarco wrote: > > Overall, I think that the problem with documentation is worse than the > gain with tab-completion, but it would be so nice if we could do something > like: > sage: n.transpose().[tab] > You can do that already: sage: n =

[sage-devel] Re: bot failures related to SAGE_ORIG_LD_LIBRARY_PATH

Seems like you have a shell that errors on unset variables (or any posix shell after running "set -u") We should just get rid of this vestige now that we don't use LD_LIBRARY_PATH any more... I made. http://trac.sagemath.org/ticket/20529 for that. On Sunday, May 1, 2016 at 6:12:59 PM UTC+2,

[sage-devel] Re: Optional doctest failure

The best solution would probably be if the patchbot config file had a way to exclude #optional stuff... On Sunday, May 1, 2016 at 6:18:24 AM UTC+2, vdelecroix wrote: > > Hello, > > The ticket #20182 (merged 7.2.beta6) introduced a different behavior for > `sage -t`. Namely it tests all

[sage-devel] Re: Tab completion on results of method calls

IPython (and hence Sage) can do tab completion of function call results already, its just off by default (thankfully!) sage: %config IPCompleter.greedy=True sage: sin(x).[TAB] Display all 211 possibilities? (y or n) [...] -- You received this message because you are subscribed to the Google

Re: [sage-devel] Coming SageMathCell upgrade - please test!

sagecell.makeSagecell is already polling to see whether it is loaded; thats of course totally fugly but should work. You just have to make sure that it is defined. If its only defined once a requirejs module loads then you don't have control over when. Instead move the window.sagecell =

[sage-devel] Re: Rank of random dense matrices over GF(2)

On Sunday, April 24, 2016 at 1:01:39 AM UTC+2, Kiran Kedlaya wrote: > > This seems to be filling out each row using successive random 32-bit words > from gmp, lopping off the extra bits at the end. Is that a bad idea for > some reason? > Its only lopping off the excess bits at the last column

[sage-devel] Re: Rank of random dense matrices over GF(2)

On Sunday, April 24, 2016 at 12:36:28 AM UTC+2, Dima Pasechnik wrote: > > sage: random_matrix? > ... >Warning: Matrices generated are not uniformly distributed. For > unimodular matrices over finite field this function does not even > generate all of them: for example

[sage-devel] Re: Rank of random dense matrices over GF(2)

I'm guessing that its not a coincidence that Mersenne twister has a period of 2^19937 ;-) The relevant code is in sage.matrix.matrix_mod2_dense.Matrix_mod2_dense.randomize Not sure exactly whats wrong but taking rstate.c_random() % (number of columns) at the very least leads to modulo bias

[sage-devel] Re: Adding __future__ imports in all .py(x) files

+1 As others mentioned, there are at least 3 similar cases where future imports should be used: * The sage library (this thread) * The preparser * Doctest runner I'm in favor of either. A preparser change should probably coincide with a major version change. On Thursday, April 21, 2016 at

Re: [sage-devel] Delete old optional packages

On Wednesday, April 20, 2016 at 10:41:53 AM UTC+2, Dima Pasechnik wrote: > > database_jones_numfield-v4.spkg > There is a new-style package for that one. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop

Re: [sage-devel] Delete old optional packages

:53 AM UTC+1, Dima Pasechnik wrote: >>> >>> >>> >>> On Wednesday, April 20, 2016 at 9:31:25 AM UTC+1, Jeroen Demeyer wrote: >>>> >>>> On 2016-04-20 09:24, Volker Braun wrote: >>>> > I propose to delete them >>&g

[sage-devel] Re: Delete old optional packages

Congratulations, you are now in charge of contacting the maintainers ;-) On Wednesday, April 20, 2016 at 11:19:29 AM UTC+2, mmarco wrote: > > In theory, each od these packages should have a mantainer. I think we > should, at least, consult them before removing the packages. > If a package has

Re: [sage-devel] Re: failing doctests in patchbots

> up > in the patchbot in the round of pypi updates. > > François > > > On 20/04/2016, at 19:36, Volker Braun <vbrau...@gmail.com > > wrote: > > > > There is a numpy update coming up; The patchbots installed the updated > numpy, but then apparent

[sage-devel] Re: failing doctests in patchbots

There is a numpy update coming up; The patchbots installed the updated numpy, but then apparently didn't downgrade when testing the next ticket On Wednesday, April 20, 2016 at 9:24:59 AM UTC+2, Frédéric Chapoton wrote: > > Several patchbots (poseidon and sage4) meet the same failing

[sage-devel] Delete old optional packages

Since we once again had a thread about the pains of accidentally installing an old-style optional package, I propose to delete them except the following instead of opening a trac ticket for each one once something bad happened. If there is anything else you want to hit reply... See the list

[sage-devel] Re: Code vs codes

"Code" as in "source code" is a mass noun, it does not refer to a specific quantity and is never pluralized. In other contexts, "code" can be a count noun so you are rightfully confused; E.g. "different codes of ethics" On Tuesday, April 19, 2016 at 3:03:05 AM UTC+2, Kwankyu Lee wrote: > >

Re: [sage-devel] Re: Proposal: install all pip-installable components of Sage via pip, directly

It should be fixed in distlib which is vendored into pip... On Monday, April 18, 2016 at 12:59:36 PM UTC+2, Erik Bray wrote: > > On Sat, Apr 16, 2016 at 2:13 PM, Jeroen Demeyer > wrote: > > Great... that still doesn't work. > > I agree that should be fixed. It's like

[sage-devel] Re: Calculus bug in the latest 7.2.beta: sin(pi*x) returns 0 whenever x > 0

It seems that the assumption (wrongly) thinks that x is integer: sage: assume(x>0) sage: sin(pi*x) 0 sage: cos(pi*x) (-1)^x On Sunday, April 17, 2016 at 5:58:07 PM UTC+2, Eric Gourgoulhon wrote: > > Hi, > > In Sage 7.2.beta4: > > sage: assume(x>0) > sage: sin(pi*x) > 0 > > As far as I can

Re: [sage-devel] Re: Proposal: install all pip-installable components of Sage via pip, directly

lopen, URLError, HTTPError, ImportError: cannot import name HTTPSHandler On Saturday, April 16, 2016 at 2:06:53 PM UTC+2, Jeroen Demeyer wrote: > > On 2016-04-16 12:15, Volker Braun wrote: > > IMHO we should always use pip, but pip > > depends on openssl. > > Not for l

[sage-devel] Re: Proposal: install all pip-installable components of Sage via pip, directly

I think there are two different tasks: 1) Use pip to install python packages, regardless of where the package is. Maybe we bundle the tarball, maybe its on PyPI, maybe its on github. Pip can install either just fine. IMHO we should always use pip, but pip depends on openssl. We'll save us much

Re: [sage-devel] Re: Proposal: move SageNB back to Sage

On Saturday, April 16, 2016 at 5:57:32 AM UTC+2, Jeroen Demeyer wrote: > > Isn't that exactly the current situation? As long as Sage and SageNB are > in a separate git repo, we still need somebody to accept pull requests > and make releases. > Yes, but I'm proposing that anybody on the SageNB

Re: [sage-devel] Re: Proposal: move SageNB back to Sage

On Saturday, April 16, 2016 at 12:32:44 AM UTC+2, Dima Pasechnik wrote: > > What I dislike about #14840 is that it creates 14 new standard packages > (not needed for anything except sagenb), instead of just running 'sage > --pip'. We already install stuff by 'sage --pip', e.g. the ssl support >

Re: [sage-devel] Re: Proposal: move SageNB back to Sage

Is there really going to be much activity on SageNB in the future? I appreciate that you fixed the packaging and dependency nightmare, but it seems that we are now (i.e. after #14840) at the point where we are likely to just wait and eventually remove SageNB. I always found it frustrating to

[sage-devel] Re: Using custom Singular lib

The singular code should go to src/ext/singular which is then installed to SAGE_LOCAL/share/sage/ext. The latter path is available as sage.env.SAGE_EXTCODE On Friday, April 15, 2016 at 10:53:40 AM UTC+2, Kwankyu Lee wrote: > > I want to write a Sage module, say "function_field.py", that uses

[sage-devel] Re: how we develop sage

On Thursday, April 14, 2016 at 8:35:29 PM UTC+2, William wrote: > > apply normal software development practices!! You mean like in the Linux kernel? A project which, by the way, is a) extremely anal about having a stable API (=posix) and b) very clear about what is not going to be stable.

Re: [sage-devel] Docstring-wide "# optional" markup (#20427)

On Tuesday, April 12, 2016 at 1:48:17 PM UTC+2, Dima Pasechnik wrote: > perhaps a meaningful compromise would be test-wise #optional tags, per > test/example or per test/example block > Or just call the block OPTIONAL, so that EXAMPLES:: sage: bar() # optional - foo sage: baz() #

Re: [sage-devel] Re: how we develop sage

On Tuesday, April 12, 2016 at 9:59:40 PM UTC+2, William wrote: > > We might also be able to make it available > outside Sage, and it could suddenly be of huge value to the Python > world. In other words: If we change our mission to "the most useful collection of libraries" then we should

[sage-devel] Re: Docstring-wide "# optional" markup (#20427)

IMHO thats terrible; When you copy an example it should either work or say very clear why it is optional. Just having some magic marker somewhere in the documentation, long before the example starts, is potentially much more confusing than the visual clutter of repeated magic comments could

Re: [sage-devel] Re: how we develop sage

Excluding accessing sage.* or the module import cache directly There are various language-lawyering ways of expressing this; I appreciate your contribution to find a bulletproof formulating but I think its intuitively clear what is meant. On Monday, April 11, 2016 at 11:11:04 PM UTC+2,

Re: [sage-devel] Re: how we develop sage

On Monday, April 11, 2016 at 8:29:06 PM UTC+2, Nils Bruin wrote: > > Are you proposing to define the public API as just the functions that are > available on the command line by default? > And all the (non-underscored) methods on objects that you can construct starting from globals, of course.

Re: [sage-devel] Re: how we develop sage

On Monday, April 11, 2016 at 2:57:16 PM UTC+2, Erik Bray wrote: > > Sage, unfortunately, hasn't made many pacts in this regard Sage does have a very clear way of making symbols available on the commandline, namely via accompanying all.py files. We can either use that to define our public api

Re: [sage-devel] Re: how we develop sage

On Monday, April 11, 2016 at 3:00:12 PM UTC+2, Erik Bray wrote: > > It's no doubt very time consuming to check every merged pull request Thats a great idea and scales really well when the project merges 5 branches a day. It will also ensure that there are always enough volunteers to serve as

[sage-devel] Re: Intel MKL

Best, > Ahmed > > On Tuesday, March 19, 2013 at 2:43:44 AM UTC-4, Dima Pasechnik wrote: >> >> On 2013-03-19, Volker Braun <vbrau...@gmail.com> wrote: >> > --=_Part_1140_29982224.1363660802496 >> > Content-Type: text/plain; charset=ISO-8859-1 >>

Re: [sage-devel] Re: LaurentPolynomialRing and PolynomialRing behave inconsistently -- Request For Comments

UTC+2, vdelecroix wrote: > > On 09/04/16 05:15, Volker Braun wrote: > > Let me try to summarize the expected behavior: If there is a coercion of > > the base rings, then there should be a coercion to the (laurent) > polynomial > > ring with additional variables. The

[sage-devel] Re: LaurentPolynomialRing and PolynomialRing behave inconsistently -- Request For Comments

Let me try to summarize the expected behavior: If there is a coercion of the base rings, then there should be a coercion to the (laurent) polynomial ring with additional variables. The variables in the different rings are identified using their name (and not index in gens() or any other rule).

[sage-devel] Re: how we develop sage

On Friday, April 8, 2016 at 8:40:02 PM UTC+2, William wrote: > > Why does nobody ever ask? > I'd like to think thats because there is simply no need for obscure imports when using Sage; We have public constructors for basic mathematical objects, and computations are then done using methods of

[sage-devel] Re: Automated Downloading of Most Recent Version of Sage

The easiest way is probably to poll one of https://raw.githubusercontent.com/sagemath/sage/master/src/sage/version.py https://raw.githubusercontent.com/sagemath/sage/master/src/bin/sage-version.sh On Friday, April 8, 2016 at 11:27:33 PM UTC+2, Chris Swierczewski wrote: > > I have written an

Re: [sage-devel] Re: how we develop sage

On Friday, April 8, 2016 at 6:43:46 PM UTC+2, William wrote: > > this "one other problem of Sage is that it does not define > clearly what's the public API and what's internal. IMHO thats just not true; What you get on the commandline (i.e. from sage.all import *) is public and the rest is

Re: [sage-devel] Re: how we develop sage

On Friday, April 8, 2016 at 6:50:19 PM UTC+2, William wrote: > > > But then there is nothing to do on the Sage side, this already works and > is > > totally standard. Just because > it is technically possible to do something and documented how to do so > online, doesn't mean there is nothing

Re: [sage-devel] failed install of pyopenssl

Seems like the libffi header directory is versioned, that sounds like a bug to me. In centos-7 it is not (/usr/include/ffi.h) Try: CFLAGS=-I/usr/include/libffi-3.0.5 make openssl -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe

[sage-devel] Re: make ptestlong

On Thursday, April 7, 2016 at 5:03:44 PM UTC+2, kcrisman wrote: > > Yes, though again this is a loaner so very little was preinstalled. But > where is Sage invoking Java (as a command) during non-optional tests in the > first place? Running doctests shouldn't be using jmol - or do some of

[sage-devel] Re: how we develop sage

On Friday, April 8, 2016 at 2:36:23 AM UTC+2, William wrote: > > Whats wrong with the obvious solution: make it a Python package (basically >> add setup.py) and then "sage -pip install >> https://github.com/vbraun/awesomepackage.git;. Clearly we could have >> more documentation for how to write

[sage-devel] Re: What to do with the documentation of an optional spkg

IMHO your package should never alter Sage sources, thats just confusing. Documentation should be built when your package is installed, and installed in the standard SAGE_LOCAL/share/doc/mypackage. Similarly, your code should be installed into SAGE_LOCAL and never into the Sage source tree.

[sage-devel] Re: how we develop sage

Correction: "sage -pip install git+https://github.com/vbraun/awesomepackage.git; -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to

[sage-devel] Re: how we develop sage

On Friday, April 8, 2016 at 1:26:07 AM UTC+2, William wrote: > > This thread is first and foremost about reducing the friction involved in > making code that depends on the Sage distribution available to the world. > Whats wrong with the obvious solution: make it a Python package (basically add

Re: [sage-devel] Re: how we develop sage

On Friday, April 8, 2016 at 12:19:57 AM UTC+2, William wrote: > > > You mean like in the Linux kernel, which uses a single monolithic git > > repository? > I think you are being sarcastic. I'm only partially kidding. Why is the kernel not a collection of packages? Because nobody wants half a

[sage-devel] Re: make ptestlong

Its not that "make ptestlong" does anything special to build Sage, it just launches our own (parallel) doctester after building the dependencies which happen to include Sage. Makefile parallelism is some version of MAKE='make -j8' make You can't really enable makefile parallelism from

[sage-devel] Re: how we develop sage

On Tuesday, April 5, 2016 at 8:44:45 PM UTC+2, William wrote: > > [...] toward standard open source practices. You mean like in the Linux kernel, which uses a single monolithic git repository? Really, modularization is not a useful goal in of itself. And it comes with its own sets of issues,

[sage-devel] Re: openssl gone?

Those are 4 concatenated git build logs. I don't know which one is relevant. On Tuesday, April 5, 2016 at 8:23:53 PM UTC+2, Simon King wrote: > > Hi Volker, > > Am Dienstag, 5. April 2016 17:30:15 UTC+2 schrieb Volker Braun: >> >> Should work, whats the git build log and

[sage-devel] Re: openssl gone?

Should work, whats the git build log and what does the git binary link to? On Tuesday, April 5, 2016 at 5:03:08 PM UTC+2, Simon King wrote: > > - Is the git spkg installed by default (I don't recall to have installed > it manually)? If so, why? > $ cat build/pkgs/git/type standard > -

[sage-devel] Re: openssl gone?

Fixed, the tarball had the wrong name On Tuesday, April 5, 2016 at 4:35:07 PM UTC+2, Simon King wrote: > > Hi! > > I just tried to install openssl. "sage -i openssl" did not work, as it > couldn't download openssl-1.0.2g.tar.gz from any mirror. What went wrong > here? > > Best regards, >

[sage-devel] Re: Git message while pushing a patch

Pruning is about unreachable objects (commits not referenced by a branch, e.g. because you deleted the branch). It is safe to do unless you accidentally deleted a branch and want it back ;-) A better command to clean up temporary files is "git gc" which includes pruning On Tuesday, April

Re: [sage-devel] citing Sage: the SageMath version

Brought to you by the Department of Redundancy Dept. On Monday, April 4, 2016 at 10:25:35 PM UTC+2, Ursula Whitcher wrote: > > Would SageMath Software be better? Isn't SageMath Mathematics Software > a little redundant? > > -- You received this message because you are subscribed to the

Re: [sage-devel] Re: Error while building Sage 7.1

On Sunday, April 3, 2016 at 9:30:41 PM UTC+2, Erik Bray wrote: > > On the contrary, I believe requiring someone to build an entirely > separate compiler toolchain is more burdensome and both user- and > developer-hostile compared to fixing the issue with that compiler I.e. getting some older

[sage-devel] Re: Error while building Sage 7.1

Pretty clear that its a dual abi issue, libfplll discovers your system libqd and decides to link against it. But your system is new enough to use the new cxx11 abi, whereas the Sage-built gcc is not. Hence linking fails with undefined std::__cxx11 symbols, as expected. This is probably going

[sage-devel] Re: Error while building Sage 7.1

can you post the entire log? On Saturday, April 2, 2016 at 2:24:06 AM UTC+2, cozzy wrote: > > Hi I've encountered this error while building Sage from sources obtained > from git -clone. I'm running Manjaro Linux 4.3.3-3-ARCH. Any ideas? > > Thanks > John > > /lib/../lib64/libqd.so: undefined

Re: [sage-devel] Pythonics

On Friday, April 1, 2016 at 4:19:08 PM UTC+2, Erik Bray wrote: > > One of my top wishlist items for Python 4 is some kind of __hasattr__ > special method for classes and/or an equivalent for descriptors that > merely guarantees* that accessing the attribute of that name will not > result in an

Re: [sage-devel] Why set([1]) is printed nicely while set([]) is not?

Just to expand on that answer: Plain python prints the empty dictionary as {} so it has the potential to be confusing to people that know Python: >>> set() set([]) >>> set([1]) set([1]) >>> dict() {} >>> dict(a=1) {'a': 1} On Friday, April 1, 2016 at 11:07:48 AM UTC+2, Viviane Pons wrote: > >

Re: [sage-devel] Re: Linux on Windows

On Thursday, March 31, 2016 at 9:23:56 AM UTC+2, bluescarni wrote: > > On the theme of hell freezing over, this also happened: > > https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/ > Though that is less surprising since they released Linux remote debugging (gdb

Re: [sage-devel] Re: Linux on Windows

On Wednesday, March 30, 2016 at 8:15:06 PM UTC+2, William wrote: > > "the POSIX subsystem was essentially a checkbox feature to meet some > government contracting requirements. [...]" > Thought that refers to the ancient "posix subsystem", not the more recent "windows services for unix" which

[sage-devel] Re: Linux on Windows

Sounds like the devil is ice-skating to work today ;-) Of course MS had a posix layer since about forever, they just never did anything with it or really made it available for others to use... On Wednesday, March 30, 2016 at 6:51:50 PM UTC+2, Mike Hansen wrote: > > It's looking like Windows is

[sage-devel] Re: [sage-release] Sage 7.2.beta1 released

I take it you haev CPLEX installed... On Monday, March 28, 2016 at 11:20:01 PM UTC+2, vdelecroix wrote: > > Hello, > > I got problems building the doc for "knots" (see attached log obtained > without parallel build). I am alone in that case? > > Vincent >

Re: [sage-devel] Re: Huge virtual memory usage

On Monday, March 28, 2016 at 8:16:36 PM UTC+2, William wrote: > > Another very common thing to ulimit is the number of processes. > e.g., the default I think on Ubuntu is maybe 1000. > Yes, and 1000 * RLIMIT_AS is almost always enough to make things very slw... I'm really sad to see that

[sage-devel] Re: Huge virtual memory usage

On Monday, March 28, 2016 at 5:54:34 PM UTC+2, Nils Bruin wrote: > > It's a simple one to set, though, and in many contexts it protects > against silly memory errors (e.g., on a multi-user machine > But it doesn't help when you have multiple processes, as its per-process limit only. >

[sage-devel] Re: Huge virtual memory usage

Presumably this is due to #19883 There isn't really any problem here, though. If you implement your own version of malloc then, in some implementations, you'll need about as much virtual memory as ram to do the accounting. It just uses your 128TB of virtual memory space. On a related note,

Re: [sage-devel] Sage 7.1 installation fails

th/ is the folder into which I unpacked it. > (the double SageMath is due to an error of mine) > > Am Samstag, 26. März 2016 12:59:26 UTC+1 schrieb Volker Braun: >> >> Workaround at http://trac.sagemath.org/ticket/20299 (needs review) >> >> >> >&g

Re: [sage-devel] Sage 7.1 installation fails

Workaround at http://trac.sagemath.org/ticket/20299 (needs review) On Saturday, March 26, 2016 at 12:01:17 PM UTC+1, radikale...@gmail.com wrote: > > Dynamic section at offset 0x1dd2f8 contains 30 entries: > TagType Name/Value > 0x0001 (NEEDED)

[sage-devel] Re: Sage 7.1 installation fails

What exactly are you trying to install? You aren't running "make" in a binary tarball, are you? On Saturday, March 26, 2016 at 1:16:14 AM UTC+1, radikale...@gmail.com wrote: > > I have tried to install Sage 7.1 on my Ubuntu 15.10, it does not work. > Here is the tail of the log when I enter

Re: [sage-devel] Re: SageMath for Windows installer

Hyper-V is not, and has historically not been, an option for distribution software because its not part of all Windows versions. From https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_compatibility The Hyper-V role can be enabled on these versions of

Re: [sage-devel] Re: Sage 7.1 build fails on patch

BTW we do have build/tox.ini to automatically test our build-time scripts against multiple Python versions. But only if you add testcases to build/test/. On Tuesday, March 22, 2016 at 11:49:44 PM UTC+1, John H Palmieri wrote: > > > > On Tuesday, March 22, 2016 at 3:24:13 PM UTC-7, David Roe

Re: [sage-devel] Relocating Sage

On Monday, March 21, 2016 at 12:53:54 AM UTC+1, William wrote: > > I did *NOT* say that SMC does not using cgroups.The are several > distinct concepts here: > >- cgroups >- docker containers >- lxc >- chroot > > Please don't conflate them. > Well until not so long ago

Re: [sage-devel] Relocating Sage

On Sunday, March 20, 2016 at 10:40:56 PM UTC+1, William wrote: > > That doesn't work since SMC uses normal Linux users, not lxc or docker > containers, so they do not have a virtual chroot'd filesystem. > Well that explains why massive parallel compilation can grind everything to a halt;

Re: [sage-devel] Relocating Sage

On Friday, March 18, 2016 at 6:39:33 PM UTC+1, William wrote: > > 3. More generally, for SMC, it's useful, for the sake of Sage > development, to have a way to setup a sage dev environment as quickly > as possible for user experience reasons, and as efficiently as > possible to better make use

Re: [sage-devel] Re: Relocating Sage

On Friday, March 18, 2016 at 8:58:30 AM UTC+1, Daniel Krenn wrote: > > .and recompile all Cython files and rebuild all the documentation on > each of these new installations; this is not very convenient for > developing (see thread [1]). IMHO thats a minor inconvenience compared to

Re: [sage-devel] Relocating Sage

I've had people at workshops trying to compile Sage (never mind using binaries) and they were SOL because their system bash was linked against the wrong version of some library. If you can't compile it you surely can't use it 6 times. Also, your use case is a bit weird; Parallel installations

Re: [sage-devel] Re: Relocating Sage

On Friday, March 18, 2016 at 11:25:36 AM UTC+1, Dima Pasechnik wrote: > > The question is what precisely triggers the rebuild of cython files (== > rebuild of all python extensions, I presume?) > file timestamps -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] Relocating Sage

18, 2016 at 11:14 AM, William Stein <wst...@gmail.com > > wrote: > >> On Fri, Mar 18, 2016 at 8:11 AM, Volker Braun <vbrau...@gmail.com >> > wrote: >> > On Friday, March 18, 2016 at 4:06:04 PM UTC+1, William wrote: >> >> >> >> >

Re: [sage-devel] Relocating Sage

On Friday, March 18, 2016 at 1:04:57 PM UTC+1, William wrote: > > Yes definitely. It worked very well for precisely this use case for a > decade. > It might have worked for you but it certainly didn't work for all users, there was a constant influx of random unfixable segfaults that you just

Re: [sage-devel] Sage "and" Anaconda

On Tuesday, March 15, 2016 at 10:47:42 AM UTC+1, Erik Bray wrote: > > I was under the impression from the few minutes of research I did that > you could in principle set a prefix to /home/user/ and > install into that. As I said, gentoo prefix / lmona.de can do that in principle. In practice

Re: [sage-devel] NTL 9.7.0

Surely we can compile singular with different cflags than NTL? Or is it a linking problem? On Sunday, March 13, 2016 at 2:17:15 AM UTC+1, François wrote: > > Thanks for adding a way to make binaries without avx/fma. > > The threading unfortunately requires C++11 (unless it changed). > In

Re: [sage-devel] Sage "and" Anaconda

I use hashdist outside of Sage on a daily basis, and its promise of "never compile anything twice" really works. It does bulletproof incremental builds, and the dependency tracking works very well in practice. If it weren't for distributing binary builds of Sage we should be using hashdist

[sage-devel] Re: Trac detected an internal error

I deleted some temp files... On Friday, March 11, 2016 at 2:24:15 PM UTC+1, vdelecroix wrote: > > Hello > > /tmp/ looks like full again on the trac server... > > """ > Trac detected an internal error: > > OSError: [Errno 2] No such file or directory: '/tmp/tmpu9nAd8' > """ > > Vincent >

Re: [sage-devel] Sage "and" Anaconda

On Thursday, March 10, 2016 at 6:23:51 PM UTC+1, William wrote: > > One thing it is not right now is: "setup a virtualenv with just the > Sage library" and go at it.I very much wish this was supported, > since a lot of people use SageMathCloud and want to do sage dev, but > it's way too

Re: [sage-devel] zero division

On Thursday, March 10, 2016 at 4:51:10 PM UTC+1, Jori Mäntysalo wrote: > > Years ago Borland Delphi had an option to throw exception for zero > division. And now GCC seems to have option -mfp-exceptions. > -mfp-exceptions is enabled by default, and probably not what you think it is You can

Re: [sage-devel] Sage "and" Anaconda

On Thursday, March 10, 2016 at 5:19:39 PM UTC+1, Jeroen Demeyer wrote: > Never having used conda, some quick questions in case you know the answer: > 1) Does conda support the same operating systems as Sage? > I'd say yes, plus Windows (though not all conda packages support windows, or can

Re: [sage-devel] zero division

On Thursday, March 10, 2016 at 3:25:00 PM UTC+1, kcrisman wrote: > > I agree on IEEE, but I am curious why Python floats don't conform? > IEEE doesn't raise errors because most common CPUs have no special support for that. Neither does C have a good way of dealing with exceptions. The only

Re: [sage-devel] zero division

On Thursday, March 10, 2016 at 8:17:47 AM UTC+1, Jeroen Demeyer wrote: > > RR represents the real numbers IMHO we should be very careful to never ever say that. RR is floating point arithmetic which is a useful approximation to reals. But if you are not aware of the differences then you very

[sage-devel] Re: Special markup to influence the doctesting

You want the magic comment # optional - latex On Tuesday, March 8, 2016 at 1:42:27 AM UTC+1, Kwankyu Lee wrote: > > The "Special markup to influence (doc)tests" section of the developer's > guide claims that it is comprehensive. But I could not find any explanation > on the use of ellipsis

[sage-devel] Re: configure error

There are no incremental updates from 6.x to 7.x. Erase all artifacts, "make distclean" or git clean On Sunday, March 6, 2016 at 11:24:23 AM UTC+1, John Cremona wrote: > > I was upgrading Sage on my quite old laptop (running ubuntu 14.04), > from 6.10 to 7.0. (One reason for doing thst is

[sage-devel] Re: gap interface bug

See also http://trac.sagemath.org/ticket/13178 http://trac.sagemath.org/ticket/19607 On Thursday, March 3, 2016 at 6:08:07 PM UTC+1, William wrote: > > Doing this produces no output: > > %gap > # for loop > for i in [1..10] do > if IsPrime(i) then > Print(i," prime\n"); > else >

Re: [sage-devel] GSOC 2016-Regression test framework

On Monday, February 29, 2016 at 2:08:29 PM UTC+1, Jeroen Demeyer wrote: > > significantly slow down tests are flagged. Ideally, with very little > false positives (I think that the test for startup time in the patchbot > has too many false positives). > I'm pretty sure that they are actual

<    1   2   3   4   5   6   7   8   9   10   >