[sage-devel] Re: Error building Sage 8.5 on Manjaro 18.0

This is now https://trac.sagemath.org/ticket/26996 -- 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+unsubscr...@googlegroups.com. To post to this group,

[sage-devel] Re: error installing database-gap

On Tuesday, January 1, 2019 at 2:48:49 PM UTC+1, Simon King wrote: > > Can I conclude that the comment "merge conflict" without indicating > the conflicting ticket will only arise when the next release is > imminent, so that there is really no point in finding out what other > ticket has exactly

[sage-devel] Re: error installing database-gap

On Tuesday, January 1, 2019 at 1:32:22 PM UTC+1, Simon King wrote: > > When will that be? > Now ;-) -- 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+u

Re: [sage-devel] Re: error installing database-gap

Technically thats because the ticket is closed, so the (mutable) branch name has been replaced by the immutable) sha1 The by far easiest solution, both to getting the code and figuring out what the conflict is, is to wait until the next beta release. On Tuesday, January 1, 2019 at 12:57:46 PM

[sage-devel] Re: error installing database-gap

gap is standard, gap_packages is optional $ cat build/pkgs/gap/type standard $ cat build/pkgs/gap_packages/type optional On Tuesday, January 1, 2019 at 12:50:55 PM UTC+1, Simon King wrote: > > On 2019-01-01, Samuel Lelievre > > wrote: > > Ticket 26856 should fix that. > > > > https://trac.

[sage-devel] Re: error installing database-gap

If you write a script that automatically figures out where the merge conflict is coming from (ideally as PR to the git trac releasemanagement) then I'll be happy to use it... On Tuesday, January 1, 2019 at 12:38:00 PM UTC+1, Simon King wrote: > > But the next time, please provide a ticket number

[sage-devel] Re: error installing database-gap

database_gap has been removed (the functionality is now merged into gap/gap_packages) -- 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+unsubscr...@googl

[sage-devel] Re: sage-8.5 fails to build from source on MacBook Pro (15-inch, 2017) macOS Mojave version 10.14.2

On MacOS Mojave you have to manually install the system headers, either go to /Library/Developer/CommandLineTools/Packages and click on macOS_SDK_headers_for_macOS_10.14.pkg or run open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg in a terminal. On S

Re: [sage-devel] Sage 8.5 macOS app

Older versions are in the "old" subdirectory, e.g.http://files.sagemath.org/osx/intel/old/index.html On Saturday, December 29, 2018 at 12:56:40 AM UTC+1, Justin C. Walker wrote: > > Hi, David, > > > On Dec 28, 2018, at 15:19 , David Joyner > wrote: > > > > On Fri, Dec 28, 2018 at 4:27 PM 'J

Re: [sage-devel] hardcoding platform-dependent constants in cython

Just avoid premature optimization; Nobody cares if the one-time dlopen() takes a nanosecond longer or not... On Saturday, December 22, 2018 at 8:57:06 AM UTC+1, Dima Pasechnik wrote: > > The question came up here: > > https://trac.sagemath.org/ticket/26930 > > This is for handling of GAP kernel

[sage-devel] Re: Delaying 8.5 or fast-tracking 8.6?

I'm inclined to release 8.5 this weekend... -- 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+unsubscr...@googlegroups.com. To post to this group, send em

Re: [sage-devel] Re: Mystery of "GAP documented global functions"

/libs/gap/libgap.c:6229)() > 668 g = make_any_gap_element(self, gap_eval(name)) > 669 else: > --> 670 raise AttributeError(f'No such attribute: {name}.') > 671 > 672 self.__dict__[name] = g > > AttributeError: No s

[sage-devel] Re: Mystery of "GAP documented global functions"

This is basically the tab completion list in the Sage/libgap interface. As you found out, creating it on the fly is way too slow. Hence we cache a reasonable list of names. On Tuesday, December 11, 2018 at 9:52:53 AM UTC-5, E. Madison Bray wrote: > > In the sage.libs.gap package, in the assi

Re: [sage-devel] Re: Weak references in the coercion model

Right, automatic clearing of circular references is only in Python 3... On Wednesday, December 5, 2018 at 9:06:39 AM UTC-5, E. Madison Bray wrote: > > On Wed, Dec 5, 2018 at 2:57 PM Simon King > wrote: > > > > > > > > Am Mittwoch, 5. Dezember 2018 13

[sage-devel] Re: Weak references in the coercion model

On Wednesday, December 5, 2018 at 6:52:55 AM UTC-5, Simon King wrote: > > - If there is a reference cycle involving one instance with a __del__ > method, then Python would not apply garbage collection to that cycle. > Python will garbage collect the cycle by not calling __del__ on some of the

[sage-devel] Re: Accidentally merged and pushed other tickets branch

I think the git reset way is conceptually the easiest, just combine it with cherrypick if needed: git reset --hard [last-good-sha1]# go back in history git cherry-pick [sha1-of-commit-to-add]# apply commit that you want to preserve ... repeat as needed ... git push --force# overwrite

[sage-devel] OSX 10.14 / cannot build with clang?

I just upgraded the buildbot to the new OSX version and I can't build Sage any more. I've read the thread about the Mojave dumpster fire and installed command line tools and /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg, so /usr/include is populated. Latest

Re: [sage-devel] Error compiling 8.5.beta3 - gsl-2.5

Do you have a ticket number? Is it the same bug as this: Copying package files from temporary location /Users/buildslave-sage/slave/sage_git/build/local/var/tmp/sage/build/ncurses-6.0.p0/inst to /Users/buildslave-sage/slave/sage_git/build/local cp: cannot overwrite directory /Users/buildslave

Re: [sage-devel] Re: openssl licensing

On Friday, November 9, 2018 at 1:50:45 PM UTC+1, Dima Pasechnik wrote: > > Apple switched to their own SSL implementation. > They were shipping OpenSSL's headers in some obscure places, shifting > from one release to another, > in their Xcode, for porting purposes. Not sure whether they are st

[sage-devel] Re: Discrepancies when counting triangulations

ber 3, 2018 at 11:40:07 AM UTC+1, Volker Braun wrote: > > Are you running each of the three computation in the same session, or in 3 > different processes? They should do the same computation, so the only thing > I can think of is that there is something cached that shouldn't

[sage-devel] Re: Discrepancies when counting triangulations

Are you running each of the three computation in the same session, or in 3 different processes? They should do the same computation, so the only thing I can think of is that there is something cached that shouldn't be. On Friday, November 2, 2018 at 6:43:23 PM UTC+1, Jonathan Carifio wrote: >

Re: [sage-devel] Re: refresh the banner

On Wednesday, October 31, 2018 at 2:39:35 PM UTC+1, Dima Pasechnik wrote: > > But is it even possible to start it without re-starting python? > With ipython/jupyter you can't run the notebook in the current Python session, but you can just launch a completely new process. -- You received th

[sage-devel] Re: python3 status report

Wonderful news! I can add a python 3 build to the buildbot, but without running tests its probably not going to be super useful. What would be great is if there were a way to run the known-good doctests on python3, e.g. "make ptestlong" could just have a blacklist of those 414 files that are kn

[sage-devel] Re: number field: exactness of result of abs

On Wednesday, October 24, 2018 at 4:08:05 PM UTC+2, Daniel Krenn wrote: > > What is the reason, why this returns an inexact result and not something > in an exact ring like QQbar? Well abs() is real and positive, so QQbar might not be the first choice. Small orders are apparently special cased

[sage-devel] Re: git fetch fails

Try "git remote prune origin" or "git remote update origin --prune" On Sunday, October 21, 2018 at 11:13:18 AM UTC+2, Jeroen Demeyer wrote: > > Any ideas? > > error: cannot lock ref > 'refs/remotes/trac/u/embray/python3/sage-rings-polynomial-polydict/misc': > 'refs/remotes/trac/u/embray/pytho

[sage-devel] Re: Remove sagenb documentation from the reference manual?

+1 to unconditional removal. Really its just sending confusing messages to users looking for help. If you are new to Sage in 2018 you should never start sagenb. On Wednesday, October 10, 2018 at 7:27:59 AM UTC+2, John H Palmieri wrote: > > At https://trac.sagemath.org/ticket/25382, it is being

[sage-devel] Re: Corrupt system

Sunday, 23 September 2018 13:41:50 UTC+1, Volker Braun wrote: >> >> This is 26298 >> >> You need to go <= 8.4.beta4 for the initial bootstrap (which you only >> need to do once), ie: >> >> git checkout 8.4.beta4 >> make build >> git checkout

[sage-devel] Re: Corrupt system

This is 26298 You need to go <= 8.4.beta4 for the initial bootstrap (which you only need to do once), ie: git checkout 8.4.beta4 make build git checkout develop # or whichever branch you want to work on On Sunday, September 23, 2018 at 1:53:52 PM UTC+2, Bruce Westbury wrote: > > > I am curr

Re: [sage-devel] Can't pull from develop branch.

Try "git remote prune origin" or "git remote update origin --prune" Explanation: You only have a stale remote reference reference, this is slightly different from Dima's problem who had the branch locally checked out. The "git branch -d" only deletes local branches. You need to prune the cached

Re: [sage-devel] sage foundation ???

Afair the Sage foundation is a US non-profit with the necessary accounting busywork graciously provided by UW; So I'm sure there is similar reporting thats either published or available to the public. Though I've never read the Oberwolfach financial report ;-) On Friday, September 21, 2018 at

Re: [sage-devel] check dependencies

On Friday, September 21, 2018 at 2:43:32 PM UTC+2, Thierry (sage-googlesucks@xxx) wrote: > > Agreed. But how should we deal with testing networkx ? Print a warning that nose is required and skip -- You received this message because you are subscribed to the Google Groups "sage-devel" group.

[sage-devel] Re: libgap is not using the available memory

Is your computer running more than one gap process at a time? There are more states for swap space than free and used, it can also be exclusively reseved (but not necessarily used). This is what gap is doing and probably not reflected in your output. On Tuesday, September 18, 2018 at 9:38:04

[sage-devel] Re: Change (bug or feature?) in 3d plots illustrating the reference manual

I don't think there was a deliberate change. Rendering the jmol version requires java, which is an external dependency. There was also a bug in detecting java 10+ which is only fixed in Sage 8.4.beta4. The expected behavior is: If java is not installed or not properly found then the docs fall b

Re: [sage-devel] Tools to compute Hilbert Poincaré series

FWIW I once wrote a monomial ideal implementation in Sage/Cython, probably for some related reason though I forget exactly why I couldn't use Singular. Its presumably similar to the code you wrote already. It doesn't do weights but does implement the refined HS. A reasonably fast implementation

Re: [sage-devel] python3 report (end of august 2018)

Another easy diagnostic: look at /proc/$PID/fd/* and see which file(-descriptors) are open. On Monday, August 27, 2018 at 7:21:45 AM UTC+2, Snark wrote: > > That probably means the doctesting framework is leaking file > descriptors, ie: it opens each and every file but never closes them. > > I

[sage-devel] Re: Failed installation of sage on CentOS 7 VPS

Try MAKE="make -j1" make to not build stuff in parallel. On Sunday, August 12, 2018 at 2:42:14 PM UTC+2, Will Sinclair wrote: > > Ok, so I have installed the gfortran manually. And I have re-run the make > command. Now, it is the fplll that is giving me problems. (see log > attached) I am no

Re: [sage-devel] Re: talk

There is a jupyter extension for that, though I haven't tried it... https://github.com/ipython-contrib/jupyter_contrib_nbextensions/tree/master/src/jupyter_contrib_nbextensions/nbextensions/skip-traceback On Monday, July 30, 2018 at 8:46:35 PM UTC+2, William wrote: > > In sagenb it would show on

Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)

On Thursday, July 19, 2018 at 10:16:46 AM UTC+2, Erik Bray wrote: > > If there's a fix for a known issue there's no reason to exclude it > from a release. > Look at it this way, we are delaying hundreds of tickets by a week to fix your pet bug 3 months earlier. Of course you can forever argue a

Re: [sage-devel] Release schedule survey

On Thursday, July 19, 2018 at 8:50:12 AM UTC+2, Jeroen Demeyer wrote: > > C) Don't keep a strict time table, but announce at some point during the > beta releases when you plan to cut off the merge window. > Thats a bit of a cop out, what do you mean by "at some point"? This time I wrote in the

Re: [sage-devel] Release schedule survey

No, I'm fine with either way. Personally, I think more flexibility is going to be an advantage most of the time. Though I also see how strict rules appeal to mathematicians. The same people that wish for a rigid schedule now will complain later that they missed the merge window by a day ;-) Both

[sage-devel] Release schedule survey

Since Erik is clamoring for a more calendar-driven release schedule, here is a quick A/B test: A) Keep the current process of releasing approximately every 3 months, longer if people insist on having their own pet tickets merged at the last minute. B) Keep a strict time table: Merge window is

Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)

On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote: > > As I wrote previously, I made this fix back in April, > but tabled getting the fix directly into Sage since I thought it would > be no big deal to make a Cysignals release and update Sage's > dependency on it By definition,

Re: [sage-devel] Re: Sage buildbot master configuration?

There is nothing particularly newsworthy about the buildbot setup, at the end of the day it essentially just calls "make start" and "sage -t --all". I don't think having more detail is going to be of any help in setting up a buildbot worker. But I'll PM you the entire config if you want to see f

Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)

On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote: > > All that said, your claim that this is a "high-risk" upgrade is also > highly specious. This is upgrading Cysignals from 1.7.1 to 1.7.2 [1] > which contains a couple bug fixes, the most significant of which (in > terms of pat

[sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2

On Wednesday, July 18, 2018 at 5:46:35 AM UTC+2, Travis Scrimshaw wrote: > > unless you (Volker) can guarantee that the next full release will be fully > ready by Monday morning Eastern US time. However, that is only because it > would be more prudent for the SageDays. > Thats likely if we don't

[sage-devel] Please review #25379

https://trac.sagemath.org/ticket/25379 Purportetly fixes this randomly occuring bug: sage -t --long src/sage/coding/code_constructions.py ** File "src/sage/coding/code_constructions.py", line 624, in sage.coding.code_constructi

[sage-devel] Re: Sage buildbot master configuration?

The buildbot master config isn't public since it includes the worker passwords. Though I think the worst case means somebody can submit incorrect build results. Still, there wasn't much need to make the config public. If you want to have it I'm happy to send you an archive. More interesting are

[sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2

I do appreciate your hard work in making Cygwin work. But IMHO thats a rather high-risk upgrade with little reward. Nobody stops you from merging that ticket when building cygwin binaries. And realistically we don't have anyone developing on Cygwin only at this point. [ ] I want to delay all

[sage-devel] Re: Trac branch trouble?

The commit SHA1 is immutable, but the branch can evolve over time. On Sunday, July 8, 2018 at 8:41:56 PM UTC+2, Dima Pasechnik wrote: > > maybe this should be fixed - is there a pressing need to replace the > corresponding metadata on the ticket? -- You received this message because you are sub

[sage-devel] Re: Trac branch trouble?

The problem is of course that the branch is replaced by the merged commit sha1, so trac doesn't know any more which branch that was. On Saturday, July 7, 2018 at 10:14:32 AM UTC+2, Simon King wrote: > > Hi! > > I just tried to check out the branch from #18514 on a new > laptop, but "git trac

[sage-devel] Re: unable to compile sage-8.2

This is the MAP_ANONYMOUS issue that makes cysignals fail on EOL'ed macs. Might be fixed in the latest Sage beta version, I'd suggest to try that. But in general we can't really promise to support macs that don't get updates from Apple any more... On Sunday, July 8, 2018 at 11:10:01 AM UTC+2

[sage-devel] Re: Allowing correct upstream acknowledgement by default ?

The attribution mechanism works by running the session in a profiler in order to trace the execution. Since profiling incurrs a significant runtime overhead it must be off by default. On Friday, July 6, 2018 at 9:28:10 AM UTC+2, Simon King wrote: > > Hi Thierry, > > could it be that you misunde

[sage-devel] Re: adding cython/C code in top level of sagelib

See src/module_list.py: OptionalExtension('sage.libs.homfly', sources = ["sage/libs/homfly.pyx"], libraries = ["homfly", "gc"], package="libhomfly"), On Wednesday, July 4, 2018 at 2:00:09 PM UTC+2, Dima Pasechnik wrote: > > Or

[sage-devel] Re: Deleting old upstream branches

I'm fine with auto-deleting merged branches, but IMHO thats just doctoring around the symptoms. Listing all branches is just a fundamentally useless view of the repo, akin to listing all your files alphabetically. Even if we auto-delete merged branches there will always be crud because some bran

Re: [sage-devel] Re: Strange errors while running doctests

the error is preventing us to run any > of the doctests. We could of course comment out some of the graphs every > time we want to run the tests, but that seems hardly a sustainable way of > proceeding. > > Cheers > Nico > > 2018-06-21 19:33 GMT+02:00 Volker Braun > &

[sage-devel] Re: Strange errors while running doctests

Yes, some limits are tightened for doctests. If you want code to be in Sage make sure that doctests use only small amounts of memory and run basically instantaneous (or < 1s for # long time) Doctests are test that are being run by every develop every time they work on a ticket, not for showing

Re: [sage-devel] divisions

On Monday, June 11, 2018 at 8:04:56 PM UTC+2, Nils Bruin wrote: > > You are introducing some non-commutativity into the coercion graph that > way, though. > I think that settles it: The parent of a / b must only depend on the parents of a and b, since that is cached by the coercion system. Other

Re: [sage-devel] Re: divisions

On Saturday, June 9, 2018 at 4:44:45 PM UTC+2, William wrote: > > (also, it's called "floor division"!) > And ^ is called bitwise xor... Arguably we are just switching // to be something else than floor division since that doesn't make a whole lot of sense in a math system that comes with many

Re: [sage-devel] Re: divisions

On Saturday, June 9, 2018 at 9:54:03 AM UTC+2, Jeroen Demeyer wrote: > > It should stay in the same ring, but what should the result be? I > personally would expect (1 // x) == 0 for Laurent polynomials because > that extends the // operation (Euclidean division) of ordinary > polynomials. Bu

Re: [sage-devel] Re: Matrix groups are not uniquely represented, why?

On Sunday, June 3, 2018 at 12:26:46 PM UTC+2, vdelecroix wrote: > > Note also that it is perfectly fine for "==" to raise an error such as > NotImplementedError. If some algorithm is not able to decide whether > H1 and H2 are equal it can just give up. The problem isn't that the computer will

[sage-devel] Re: Can't login to trac

Nevermind, looks like I had an old password in my browser autocomplete On Monday, May 28, 2018 at 1:19:48 AM UTC+2, Volker Braun wrote: > > Says Invalid username or password, pretty sure nothing changed on my end > ;-) > > -- You received this message because you are subscribe

[sage-devel] Can't login to trac

Says Invalid username or password, pretty sure nothing changed on my end ;-) -- 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+unsubscr...@googlegroups.co

[sage-devel] Re: Error building the doc sage-8.1

So what do you get if you start Sage and run sage: import sage.combinat.cluster_complex On Monday, May 21, 2018 at 3:50:50 PM UTC+2, Paul Mercat wrote: > > [dochtml] [combinat ] WARNING: > /Users/mercatp/sage-8.1/src/doc/en/reference/combinat/sage/combinat/cluster_complex.rst:11: > > (WARNI

[sage-devel] Re: Missing Sage 8.2 binaries

Binaries take a couple of days to build. On the way to the mirrors now... On Tuesday, May 8, 2018 at 8:54:42 PM UTC+2, Mark Bell wrote: > > The main sagemath.org page lists Sage 8.2 as the latest version to > download and the source and git links appear to be tagged as sage-8.2 as of > three d

[sage-devel] Re: Update README and doc on the mirrors for the format *.tar.bz2

No, same. Our docs should just say "tar xf". On Friday, May 4, 2018 at 6:28:00 PM UTC+2, John H Palmieri wrote: > > With the BSD version of tar included with OS X, you can just do 'tar xf > ...' and it will automatically detect the type of compression. GNU/linux > tar doesn't do this? >> >> --

[sage-devel] Re: Improving code with AI?

First we should add one of the plain old rule-based linters to our testsuite, imho that would go a long way of maintaining a consistent code style (and avoid trivial review friction). On Sunday, April 29, 2018 at 3:43:23 PM UTC+2, Peter Luschny wrote: > > Hi, > > does such a thing make sense

Re: [sage-devel] 8.2.rc2 on OSX: compile gcc 7.2 after git pull

On Thursday, April 12, 2018 at 10:13:50 AM UTC+2, François Bissey wrote: > > In the last 24hours Dima found the problem and we have a fix so there may > still be a chance > of 8.2 using clang out of the box. IMHO the safe bet is to use gcc in 8.2 (as it was in 8.1) instead of last-minute expe

[sage-devel] Re: Newest Xcode is causing doctest failures

I've opened a blocker ticket #25113 -- 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+unsubscr...@googlegroups.com. To post to this group, send email to

[sage-devel] Re: Newest Xcode is causing doctest failures

Aaaand Apple force-pushed the borked Xcode out as a practical April Fool's joke, so now everyone has it. Including our buildbot. On Saturday, March 31, 2018 at 9:46:41 PM UTC+2, John H Palmieri wrote: > > On an OS X machine, I just did a minor upgrade on the operating system (to > 10.13.4) and

[sage-devel] Re: Newest Xcode is causing doctest failures

On Sunday, April 1, 2018 at 9:01:17 AM UTC+2, Dima Pasechnik wrote: > > - when I do an incremental upgrade, I do not see these failures. > - when I do 'make distclean; make ptestlong', I see them (with > 8.2.beta8 or later; I haven't checked earlier versions). Is it the other way round? Surel

[sage-devel] Re: openssl licensing

https://www.openssl.org/blog/blog/2018/03/01/last-license/ They want to change the license in the next release, which is currently in Alpha, and tentatively set for May. On Saturday, March 31, 2018 at 11:44:58 AM UTC+2, Thierry (sage-googlesucks@xxx) wrote: > > Hi, > > not sure whether ther

Re: [sage-devel] Re: How much do we support the casual user

On Friday, March 30, 2018 at 6:35:12 PM UTC+2, John Cremona wrote: > > I don't think this will satisfy Ralf's casual user who will see 100 > warnings output from their loop and not find any of the primes they were > hoping for. > By default, the warning is only shown once in said loop. If the wa

[sage-devel] Re: How much do we support the casual user

The obvious answer: Show a warning if you test field elements for primality * easy to implement using standard Python machinery * does not introduce backward-incompatibile changes * is mathematically correct * informative to casual users * unlikely to give spurious warnings in existing code -- Yo

Re: [sage-devel] How much do we support optional packages.

On Sunday, March 25, 2018 at 2:51:46 PM UTC+2, Dima Pasechnik wrote: > > one can install autotools on archlinux systemwide > Also, autotools aren't even required to build Sage. Whats the point of delaying a release for weeks/months to fix an optional package? Presumably you agree that broken st

Re: [sage-devel] Re: OS X (or BSD) testers needed

Fun fact: in Apple's Swift language an array out of bounds access also terminates with SIGILL On Thursday, February 22, 2018 at 8:54:18 PM UTC+1, Jeroen Demeyer wrote: > > On 2018-02-22 17:32, Dima Pasechnik wrote: > > $ clang forksigaltstack.c -o forksigaltstack && ./forksigaltstack > > got s

Re: [sage-devel] Re: Whitespace patchbombs

+1 for lint; adding a suitable set of linting rules to the testsuite would have a much greater impact on code quality than enforcing a trailing whitespace policy will ever have. On Wednesday, February 21, 2018 at 1:21:36 PM UTC+1, John Cremona wrote: > > A simpler, similar example is with the l

Re: [sage-devel] Whitespace patchbombs

I'm against a workflow that involves bots for a nothing-burger like trailing whitespace. Either auto-cleanup on commit and have the server check on push that it was cleaned up. Or nothing at all. But waiting a day and then have a bot come back with trailing whitespace nonsense is just an unnece

[sage-devel] Re: Whitespace patchbombs

IMHO the evils of trailing whitespace are greatly exagerrated. The eaisest solution is to just fix your editor to not introduce changes that you did not make yourself. If you think fighting the windmills of trailing whitespace is a worthwhile use of your time, be my guest. But I want a workflow

[sage-devel] Re: How should ordering of constants be defined?

Comparing two named real constants by float value sounds good to me. In general, when comparing general symbolic expressions, there are some numerical tests with increcasing accuracy iirc... On Friday, February 16, 2018 at 5:04:30 PM UTC+1, Erik Bray wrote: > > Hi, > > In working on the Py

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On Wednesday, February 7, 2018 at 10:31:43 AM UTC+1, Jeroen Demeyer wrote: > > But what is the "desired implementation"? > Again, surely its "Sage integers" for users of Sage. Anything else is just dumping a giant turd on your users just because its the lazy thing to do. There are surely ways

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On Wednesday, February 7, 2018 at 9:49:29 AM UTC+1, vdelecroix wrote: > > what if library A needs library B with return type "X" > but the user wants it with return type "Y" So we solve the problem by making it impossible for the user to get the return type he wants (namely Sage intergers by yo

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

But implementation details can surely be worked out. A totally basic idea: put the specifics of the integer type and integer wrap/unwrapping in an cython include file. At build time, copy the include file with the desired implementation. -- You received this message because you are subscribed

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On Tuesday, February 6, 2018 at 2:25:58 PM UTC+1, Erik Bray wrote: > > "What's in it for Sage users?" -- Eventually, anyways, being able to > drop code from Sage in favor of other, better-supported code that > provides the same thing, so that Sage developers can work on other > things. > Well

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On Monday, February 5, 2018 at 11:58:27 PM UTC+1, vdelecroix wrote: > > How complicated? It would help with another example that is not about > factoring 10. Its a simplified example but not all that synthetic; The output of integral polyhedral computations is often about counting something, a

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On Monday, February 5, 2018 at 8:14:12 PM UTC+1, vdelecroix wrote: > > And without having gmpy2 it is hard to set pplpy a standalone > package. Obviously thats the only real argument here; The question is, whats in it for Sage users? None of your arguments are particularly convincing. And

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

Isn't having yet another integer type in Sage a huge liability without advantage? Anybody care to explain why we'd want two different gmp/mpir wrappers in Sage? Also, confusion factor for users... This introduces various breaking changes, for example right now I can do sage: from sage.libs.ppl

[sage-devel] Re: sodium.h not found when compiling zeromq on macOS

zeromq found a libsodium (which doesn't come with OSX), probably some third-party package manager remnant... get rid of it or install the headers from whereever you got the library. On Friday, February 2, 2018 at 4:34:45 PM UTC+1, David Corbin wrote: > > sodium.h not found while compiling zero

[sage-devel] Re: Internet access during package tests

Packages must work without internet access; We poison cache environment variables to prevent accidental internet access. On Sunday, January 14, 2018 at 12:13:21 AM UTC+1, Simon King wrote: > > Hi! > > In my group cohomology package, I have a couple of tests that require > internet access (name

[sage-devel] Re: Singular quotient rings in doctests

; > On 2018-01-13, Volker Braun > wrote: > > Just to point out the obvious: If qringNF isn't enabled explicitly then > it > > must be set by some singular package that is being imported in a test. > > Sure. But I wonder if someone on the list knows what Singular

[sage-devel] Re: Singular quotient rings in doctests

Just to point out the obvious: If qringNF isn't enabled explicitly then it must be set by some singular package that is being imported in a test. On Saturday, January 13, 2018 at 1:29:00 PM UTC+1, Simon King wrote: > > On 2018-01-13, Simon King > wrote: > > I wonder: Is the doctest framework a

Re: [sage-devel] Re: Merge fails of positive ticket HOWTO

IMHO it shouldn't be easy to find. Certainly nobody should base their work on it. If its under the official sagmath org then that is just asking for trouble. On Tuesday, January 2, 2018 at 5:11:21 PM UTC+1, Erik Bray wrote: > > On Sat, Dec 9, 2017 at 1:27 PM, Volker Braun > w

[sage-devel] Re: latest version of notedown package not on the mirrors

Thanks, fixed! On Saturday, December 23, 2017 at 12:31:50 PM UTC+1, Thierry (sage-googlesucks@xxx) wrote: > > Hi, > > i make a separate thread to be visible: the package notedown which has > just been upgraded to version 1.5.1 is not on the mirrors, see > https://trac.sagemath.org/ticket/24376

[sage-devel] Re: Error downloading gmpy2-2.1.0a1.tar.gz

thanks, fixed! On Thursday, December 14, 2017 at 8:34:06 AM UTC+1, vdelecroix wrote: > > Hello, > > The tarball for gmpy2 has not been updated on the mirrors. > > Vincent > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from th

Re: [sage-devel] Re: Why doesn't #23931 get merged?

First of all, what sets us apart from most open source projects is that the time required for a CI (buildbot) run is about a day. And we produce more more tickets than one per day. So unless we massively throw hardware at this, we have to collect a couple of tickets for each buildbot run and the

Re: [sage-devel] Why doesn't #23931 get merged?

I understand that everybody wants to see their tickets merged first, thats ok. But please realise that you aren't the only one here. The way I see it, the choice was between * Having another potential breakage leading to another rc-version, essentially delaying the release by a week. * You bei

[sage-devel] Re: Merge fails of positive ticket HOWTO

The easy solution: Just wait for the next beta If you absolutely positively can't wait you can get the current branch from my github page; If you merge with that you'll find the conflict. But don't ever publish that merge as it is bound to be rewritten before the next beta is released. On Satu

[sage-devel] Re: Why doesn't #23931 get merged?

I'm currently preparing 8.1 which was held up for a while because of some last-minute fixes. When that is out we'll be back to the usual pace. On Thursday, December 7, 2017 at 3:39:07 PM UTC+1, Friedrich Wiemer wrote: > > The ticket #23931 has a positive >

[sage-devel] Amazon SageMaker

AWS just launched a hosted Jupyter notebook with ML stuff attached... afaik it doesn't come with SageMath preinstalled, though ;-) -- 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,

[sage-devel] Re: Getting rid of the pickle jar

Thats still only addressing that objects can be unpickled; You'd also have to run the entire testsuite with the unpickled objets if you want to have any reasonable guarantee that they are actually working. Put differently, how likely do you think it is that some old pickle unpickles and passes

Re: [sage-devel] Sagemath mirrors security issues

Pretty much anybody can host a download mirror by sending Harald an email, so requiring https to download files doesn't mean much. On Wednesday, October 25, 2017 at 6:32:26 PM UTC+2, William wrote: > > > On Wed, Oct 25, 2017 at 9:12 AM Emmanuel Charpentier < > emanuel.c...@gmail.com > wrote: >

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