Re: [sage-devel] Sage on OS X: El Capitan

On Sunday, October 25, 2015 at 8:36:04 PM UTC+1, David Joyner wrote: > > On Sun, Oct 25, 2015 at 4:35 AM, Christian Nassau > <nas...@nullhomotopie.de > wrote: > > On 25.10.2015 01:03, Volker Braun wrote: > >> > >> I've used that ticket to build relocat

Re: [sage-devel] Sage on OS X: El Capitan

... On Saturday, October 24, 2015 at 12:35:44 PM UTC+2, Volker Braun wrote: > > This is now http://trac.sagemath.org/ticket/19467 > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving e

Re: [sage-devel] Sage on OS X: El Capitan

This is now http://trac.sagemath.org/ticket/19467 On Thursday, October 22, 2015 at 10:52:13 AM UTC+2, Volker Braun wrote: > > On Thursday, October 22, 2015 at 4:42:52 AM UTC+2, yomcat wrote: >> >> IMO, this solution will work, but is not the best one. An installer that

Re: [sage-devel] mutable rows of immutable matrix?

On Friday, October 23, 2015 at 3:52:18 PM UTC+2, Nathann Cohen wrote: > > Volker, please do not change the subject. I did not. > I did not say that complexity was a problem. So we agree that there is no performance problem, great. Then don't try to illustrate your problem with

Re: [sage-devel] mutable rows of immutable matrix?

On Friday, October 23, 2015 at 3:20:19 PM UTC+2, Nathann Cohen wrote: > > Depending on how matrices are implemented matrix.row(0) could very > well be a O(1) operation None of the examples you quoted would have a lower complexity with O(1) row references. If temporaries are a real problem

[sage-devel] Re: develop tag not updated ?

; > http://git.sagemath.org/sage.git/log/?h=develop > > Frederic > > Le mercredi 21 octobre 2015 20:48:06 UTC+2, Volker Braun a écrit : >> >> Thanks, fixed. >> >> On Wednesday, October 21, 2015 at 8:05:37 PM UTC+2, Frédéric Chapoton >> wrote: >>

Re: [sage-devel] Sage on OS X: El Capitan

On Thursday, October 22, 2015 at 4:42:52 AM UTC+2, yomcat wrote: > > IMO, this solution will work, but is not the best one. An installer that > allows the user to select the installation directory (which is then fixed) > is a better idea. > I don't really use OSX but afaik the preferred way is

Re: [sage-devel] Spurious error report from patchbot plugin doctest_continuation

Of course we could upgrade all old-style continuations and then remove the patchbot plugin... ;-) On Thursday, October 22, 2015 at 6:49:21 PM UTC+2, Frédéric Chapoton wrote: > > just ignore the patchbot advice when it is wrong.. There is no easy way to > enhance this plugin. > -- You

Re: [sage-devel] El Capitan SIGSEGV upon compiling sage 6.9

6.10.beta1 On Thursday, October 22, 2015 at 8:31:12 PM UTC+2, Christian Nassau wrote: > > You need at least 6.10.beta0 to compile on OSX10.11 - your issues seem > similar to those of #19370 where this was fixed. > -- You received this message because you are subscribed to the Google Groups

[sage-devel] Re: develop tag not updated ?

Thanks, fixed. On Wednesday, October 21, 2015 at 8:05:37 PM UTC+2, Frédéric Chapoton wrote: > > Hello, > > This page > > http://git.sagemath.org/sage.git/log/?h=develop > > is still pointing to 6.9 > > It is usually always pointing to the latest beta.. > > Frederic > -- You received this

Re: [sage-devel] I > 0 is true

Python2 defaults to defining ordering relations (by memory location), so I'd say its correct to say that "this happens in python". You can go out of your way and override it to throw a custom exception. Python3 defaults to throwing a TypeError: unorderable types. So thats one more place where

[sage-devel] Re: I > 0 is true

On Saturday, October 17, 2015 at 1:39:17 PM UTC+2, Simon King wrote: > > Would it be feasible to distinguish < and cmp at that point? That distinction is gone in Python 3, so we certainly shouldn't rely on that kind of hack. -- You received this message because you are subscribed to the

[sage-devel] Re: I > 0 is true

We could let comparison raise and include sort key functions of interest, e.g. sage: sorted([CC(0,1), CC(1,0)], key=CC.key.lexicographic) On Saturday, October 17, 2015 at 2:00:39 PM UTC+2, Simon King wrote: > > >>> L = [complex(0,1), complex(1,0),0] > >>> L.sort() > Traceback (most

Re: [sage-devel] Re: Methods for polyhedron are ring dependant?

On Wednesday, October 14, 2015 at 8:27:44 AM UTC+2, jplab wrote: > > -it would be a good idea to warn the user if some results may be wrong due > to the used ring. Perhaps this deserves a ticket on its own. > I think thats a bit silly; really it is just a special case of "any result in RDF

Re: [sage-devel] Re: Methods for polyhedron are ring dependant?

BTW the 1e-6 fuzzy zero is because that is used in cdd, the backend for RDF polyhedra. You can't really distinguish positive from non-negative in the nonexact case, so I'm fine with just providing it "as is". On Tuesday, October 13, 2015 at 3:30:24 PM UTC+2, Jan Keitel wrote: > > Hi

Re: [sage-devel] First Joint GAP-​Sage Days (St Andrews, January 2016)

On Monday, October 12, 2015 at 3:46:29 PM UTC+2, Snark wrote: > > Does that mean that the libgap in sagemath will get part of upstream GAP? > A better interop between Sage and GAP is definitely desirable. I don't think anybody has a clear plan at this point but I'll be at the meeting ;-) --

Re: [sage-devel] Re: nauty in Sage (was: Code generating finite posets of given size (fwd))

On Friday, October 9, 2015 at 7:08:19 PM UTC+2, William wrote: > > the copyright notice above very explicitly states that "all > rights reserved" As you said, thats a no-op: http://www.iusmentis.com/copyright/allrightsreserved/ The modified nauty-h.in does give permission to everything except

[sage-devel] Re: nauty in Sage (was: Code generating finite posets of given size (fwd))

Looks great; The two restrictions * * You must not remove this section of the text, containing author * * attribution, copyright notice, and legal disclaimer. * * * You must clearly mark modified versions of this software * * as differing

[sage-devel] Re: How to declare dependencies of new-style packages?

Its makefile syntax since its really just a script that glues everything together into one makefile. The ones after the pipe are order only dependencies. On Sunday, October 4, 2015 at 7:27:48 PM UTC+2, Simon King wrote: > > Hi! > > Meanwhile I try to change my group cohomology spkg into a new

[sage-devel] Re: Please please revert the recent changes to the docbuilder!

See https://groups.google.com/forum/#!msg/sage-release/MGkb_-y-moM/j0qABCAKBAAJ What version was OK for you? On Sunday, October 4, 2015 at 11:22:06 PM UTC+2, Simon King wrote: > > Hi! > > Since a couple of weeks, building Sage becomes really annoying. "make > start" is fine. But as soon as I

[sage-devel] Re: Error installing package ncurses-5.9.20131221

Since this is presumably fixed, can you try the latest beta/rc candidate? You can get the latest beta version from the "develop" git branch. Alternatively, the self-contained source tarball is at http://www.sagemath.org/download-latest.html On Saturday, October 3, 2015 at 10:35:58 AM UTC+2,

Re: [sage-devel] Sage in Mac OSX 11.11 (El Capitan)

On Saturday, October 3, 2015 at 10:49:03 AM UTC+2, kcrisman wrote: > Is that a sustainable solution for everyone? No its not, we can't go around telling people to disable Apple's system integrity protection. -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] Element.__hash__ stopgap

In the real world "needing more time" is a perfectly normal reason to downgrade blockers. Look at any big project, e.g. http://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting On Friday, October 2, 2015 at 10:50:52 AM UTC+2, Nathann Cohen wrote: > > > That was exactly William's proposition,

Re: [sage-devel] Element.__hash__ stopgap

On Friday, October 2, 2015 at 8:48:03 AM UTC+2, Nathann Cohen wrote: > > version soon? Couldn't we see with Volker if we cannot have a couple of > betas again and then release the next stable version next month or so? > That was exactly William's proposition, except that it will be called

[sage-devel] Re: Sources of funding - perhaps computer manufacturers?

On Thursday, October 1, 2015 at 8:13:05 AM UTC+2, Dima Pasechnik wrote: > > call these jobs WIMI (that's the right German abbreviation for a research > fellow, IIRC), and not engineer. > "Wissenschaftlicher Mitarbeiter" Still, one year is not enough to do the work, publish, and use that for the

[sage-devel] Element.__hash__ stopgap

Just as a PSA you better get used to this warning: sage: G = FreeGroup(2) sage: x,y = G.gens() sage: H = G / [x**2, y**2] /opt/sage/src/bin/sage-ipython:1: The __hash__ method of Element is broken. Beware of any

[sage-devel] Re: Sources of funding - perhaps computer manufacturers?

On Wednesday, September 30, 2015 at 4:55:29 PM UTC+2, Bill Hart wrote: > > We have the money. We know what needs to be done. But we have zero > applicants. There is a lack of talent, not a lack of money in some areas. > You are looking for an expert in compilers / optimization who happens to

[sage-devel] Re: Sources of funding - perhaps computer manufacturers?

On Wednesday, September 30, 2015 at 8:34:06 PM UTC+2, Bill Hart wrote: > > I think $100k annual is more realistically the market rate. > http://www.glassdoor.com/Salary/Google-Salaries-E9079.htm And I don't think that the average software engineer can write a superoptimizer that beats gmp/mpir

Re: [sage-devel] SSL

When the buildslave compiled Python it didn't have openssl-devel, so the Python ssl module was not built. On Wednesday, September 30, 2015 at 9:25:02 AM UTC+2, Jan Groenewald wrote: > > Hi > > I cannot figure out why the buildslave binary cannot import ssl when > Thierry's binary and

[sage-devel] Re: Sources of funding - perhaps computer manufacturers?

On Wednesday, September 30, 2015 at 9:28:14 PM UTC+2, Bill Hart wrote: > > http://www.glassdoor.com/Salary/Google-Salaries-E9079.htm >> > 64,000 Euros, 103,000 Euros, 88,000 Euros. Those are the salaries Google > is offering. > You followed the redirect to the German page. As I said, salaries

[sage-devel] Re: Docbuild memory usage

The relevant number is RSS, not virtual memory (really: addressing space). Virtual memory includes mmaps that don't actually use ram. Docbuild effectively uses about 2GB RSS. On Monday, September 28, 2015 at 1:02:11 PM UTC+2, Jeroen Demeyer wrote: > > I did a little experiment to see how much

[sage-devel] Re: Docbuild memory usage

PS: Plot of RSS for single-thread doc build. Its higher than the minimal per-process "ulimit -v" since it adds up the RSS of all processes in the process group. PPS: We are getting close to

Re: [sage-devel] Sage in Mac OSX 11.11 (El Capitan)

Post the Sage_crash_report.txt On Saturday, September 26, 2015 at 11:50:15 AM UTC+2, Juan Luis Varona wrote: > > Unfortunately, the compiling process of sage 6.9rc0 with xcode 7 under > macosx 10.11 has finished with errors: > > — > >

Re: [sage-devel] Re: About abbreviation in function names

On Friday, September 25, 2015 at 5:36:01 AM UTC+2, Dima Pasechnik wrote: > > Google for "LLL" and its in the first 10 hits >> > Google is irrelevant here; e.g. google GL and it will not be helpful. Or > for QR Its one test that lets you assume that it is a widely known abbreviation, I never

Re: [sage-devel] How to force recompilation of a package after adding a patch

any trailing .p* found in package-version.txt is simply stripped off when looking for the tarball On Friday, September 25, 2015 at 9:34:11 AM UTC+2, Clemens Heuberger wrote: > > Am 2015-09-25 um 09:11 schrieb Francois Bissey: > > The trivial answer is the only way. But you don’t have to rename

Re: [sage-devel] Re: About abbreviation in function names

On Thursday, September 24, 2015 at 11:18:58 PM UTC+2, Dima Pasechnik wrote: > > IMHO abbreviations are OK when they are known to basically every >> mathematician, e.g. ZZ. Which translates to about undergrad level. Just ask >> a undergraduate student what a T2starGQ graph is and you'll have your

Re: [sage-devel] Re: About abbreviation in function names

On Friday, September 25, 2015 at 12:36:20 AM UTC+2, Dima Pasechnik wrote: > > FYI, Mathscinet finds 8 papers with abbreviation ... >> > That is utterly irrelevant, MathSciNet only indexes research papers. So its obviously biased towards cutting-edge research. If anything, a large number of hits

Re: [sage-devel] Re: About abbreviation in function names

On Thursday, September 24, 2015 at 8:08:36 PM UTC+2, Dima Pasechnik wrote: > > We have dozens of examples in Sage where well-established abbreviations > are used, without aliases. > E.g. matrices have LU() and LLL() methods, or e.g. groups.matrix.GL > groups.matrix.GO groups.matrix.GU > IMHO

Re: [sage-devel] Re: About abbreviation in function names

On Friday, September 25, 2015 at 1:51:04 AM UTC+2, Dima Pasechnik wrote: > > Just as LLL, and probably even BKZ, are. And I wonder why Sage has LLL and > BKZ just fine, but cannot take one more relatively common abbreviation. > Google for "LLL" and its in the first 10 hits. I define that as

Re: [sage-devel] SPKG Maintainers??

On Tuesday, September 22, 2015 at 8:12:26 PM UTC+2, Dima Pasechnik wrote: > > One way or another, there are Copyright notices with names in many files, > Copyright notices are an entirely different topic from this thread. No / unclear copyright means: No right for Sage to distribute. So they are

[sage-devel] Re: git trac frustration...

at is happening where there is a potentially cached version > of the head somewhere and so the conflict is causing us not to be able to > download the branch even though it's been deleted? (BTW my git version is > 1.9.1) > > > On Monday, April 6, 2015 at 10:49:37 AM UT

[sage-devel] Re: What can we assume about our C compiler

Afaik we already require C++11 support to compile Pynac (https://groups.google.com/d/msg/sage-devel/DeT2E8IzTGs/Z_GDKbh06X8J). If not then we *should* require C++11 because its much better than without... On Monday, September 21, 2015 at 1:47:17 PM UTC+2, Nathann Cohen wrote: > > Hello

Re: [sage-devel] Default precision for floats

Yes, a more complete regex can be found easily with google or by using the one from src/sage/repl/preparse.py On Sunday, September 20, 2015 at 6:11:25 PM UTC+2, vdelecroix wrote: > Would not work with 'x=.8' (can be fixed with replacing the first \+ with a \*) nor 'x=2e3' (this is more

Re: [sage-devel] Default precision for floats

Why change the default? Global state is always a liability; Just don't do it. Make the field a parameter to your code: def frobnicate(x,y, field=None) if field is None: from sage.structure.element import get_coercion_model field = get_coercion_model().common_parent(x, y)

Re: [sage-devel] Default precision for floats

On Sunday, September 20, 2015 at 5:02:12 PM UTC+2, tdumont wrote: > > Without changing the default precision, and using your solution, we > revert to something where we must "declare" the float values: > x=field(137.8) > in place of > x=137.8 > There is an app for that! $ echo 'x=137.8' |

[sage-devel] Re: GAP issue tracker

Done! On Friday, September 18, 2015 at 10:49:42 AM UTC+2, Alexander Konovalov wrote: > > Hello, > > Could someone please update GAP entry in "Upstream bug trackers" at > http://trac.sagemath.org/ > - the GAP issue tracker is now https://github.com/gap-system/gap/issues > > Thanks >

Re: [sage-devel] Re: Re: SPKG Maintainers??

Most people don't write AUTHORS blocks, and don't update them if they change anything. And why? Because its an annoying manual duplication of what git does automatically, of course. On the other hand, it can be an incentive for somebody to start contributing. Its still unfair and

[sage-devel] Re: download

Thats RHEL 5.2. You might want to apply some of the security fixes that came out since 2008. You should be able to compile from source but there is no pre-built binary. On Friday, September 18, 2015 at 4:51:58 PM UTC+2, Olivier Orciere wrote: > > Hello > > I want to install sagemath under

[sage-devel] Re: SPKG Maintainers??

On Friday, September 18, 2015 at 5:42:23 PM UTC+2, Simon King wrote: > > Sure, git blame is able ignore whitespace. But still it would not be > able to determine if you did a substantial change in code or if you just > mechanically changed, say, function names from the API of an old third >

Re: [sage-devel] Coercion between finite fields

Two comments: A) There is no such thing as "different finite fields of the same size with the same generator name" sage: GF(4, 'a') is GF(4, 'a') True sage: GF(4, 'a') is GF(4, 'b') False There is no way to cast finite field elements to other finite field elements apart from the prime

[sage-devel] Re: Huge packages

http://files.sagemath.org/spkg/huge/ On Tuesday, September 15, 2015 at 1:42:26 AM UTC+2, Andrey Novoseltsev wrote: > > Hello, > > While old packages are being treated/converted: what has happened to > "huge" ones? One was > > polytopes_db_4d-1.0.spkg > > which does not seem to be listed

[sage-devel] Re: How to create a Cython wrapper for an optional C-library?

On Monday, September 14, 2015 at 10:57:25 AM UTC+2, Simon King wrote: > > BTW, can one tell the doctester that all of a module's doctests are > "# optional: meataxe", or is it needed to do this separately for each > individual test? > For each test (otherwise it wouldn't be documented

[sage-devel] Re: ### detaching file code.sage because it does not exist (deleted?) ###

On Monday, September 14, 2015 at 11:46:45 AM UTC+2, Sébastien Labbé wrote: > > Did you try :set backupcopy=yes in vim? >> > Thank you! You save my life! > Well, you'd still be better off using emacs ;-) -- You received this message because you are subscribed to the Google Groups "sage-devel"

Re: [sage-devel] Sage and independent C++ code

On Monday, September 14, 2015 at 7:56:58 PM UTC+2, Nils Bruin wrote: > > I don't quite see how this is a practical strategy in general. > There should of course be a central 'sage-core'. E.g. category setup, integers, ... But many peripheral modules could easily be split off, e.g. various

[sage-devel] Re: Versions mishandled while installing packages

On Monday, September 14, 2015 at 10:05:45 PM UTC+2, Andrey Novoseltsev wrote: > > PKG_BASE=`echo "$PKG_NAME" | sed 's/-.*//'` > Does this sound like a good idea? Should work as long as we do not allow > dashes in package names... > Why not? Who is validating the naming convention? Also

[sage-devel] Re: sage -n jupyter

will be in the next beta On Monday, September 14, 2015 at 9:42:32 PM UTC+2, Samuel Lelievre wrote: > > Hello all... Will > > sage -n jupyter > > work with Sage 6.9? So far we have > > sage -n ipython > > but "The Big Split" has happened and > the Jupyter notebook is now an independent >

[sage-devel] Re: *.math.washington.edu hardware resources

I went to a talk by the TravisCI CEO a while ago and one advice that struck a chord was: If you have to log into your server you are doing it wrong. Its of course OK for a one-off machine to debug / play around with, but it just makes administration a time sink. Its better to just erase an

Re: [sage-devel] Should we still support old-style packages?

And a maintainable way to *not* install outdated packages. I.e. not one that relies on adding additional makefile rules for each package that shouldn't be installed... On Monday, September 14, 2015 at 10:24:44 AM UTC+2, Jeroen Demeyer wrote: > > On 2015-09-14 00:06, William Stein wrote: >

[sage-devel] Re: ### detaching file code.sage because it does not exist (deleted?) ###

Did you try :set backupcopy=yes in vim? On Monday, September 14, 2015 at 10:52:24 AM UTC+2, Sébastien Labbé wrote: > > Dear sage-devel, > > I love the attach command, but since more than a year, the attach command > detaches my file almost each time I save it. I am using vim. Do emacs > people

[sage-devel] Re: Versions mishandled while installing packages

I'm guessing this is because the version starts with a letter, breaking some regex. The package name is threejs and not threejs-r70. As a note for script authors: The only way to translate between package and tarball name is $ sage --package tarball threejs threejs-r70.tar.gz $ sage

[sage-devel] Re: How to indicate the location of upstream sources?

On Saturday, September 12, 2015 at 5:18:38 PM UTC+2, Simon King wrote: > > Shall I indicate on Trac where to find the > upstream sources, and the reviewer downloads them manually, and once the > ticket gets a positive review, the sources will be put on a Sage server, > where they would then

[sage-devel] Re: How to create a Cython wrapper for an optional C-library?

See the usage of OptionalExtension in src/module_list.py On Saturday, September 12, 2015 at 9:48:34 PM UTC+2, Simon King wrote: > > Is it possible to have Cython files in src/sage/... that are only > compiled if a certain optional package is installed? That's not the same > as a dependency: A

[sage-devel] Re: Should we still support old-style packages?

On Saturday, September 12, 2015 at 9:48:38 AM UTC+2, Simon King wrote: > > For the record: I think ANY backward incompatible internal change that > *can* > be covered by a deprecation warning (thus, changed import locations, > changed function names or argspecs, etc) *has* to be covered by a >

[sage-devel] Re: is python a prereq for Sage?

Python >= 2.6 is required On Friday, September 11, 2015 at 6:12:14 PM UTC+2, kcrisman wrote: > > I just tried to build Sage from scratch on a (nearly) obsolete platform... > having already made some appropriate changes. What surprises me is that I > have trouble with the first package,

[sage-devel] Re: is python a prereq for Sage?

On Friday, September 11, 2015 at 7:14:55 PM UTC+2, kcrisman wrote: > > At the very least our documentation for installation/whatever should be > changed. (!) > http://trac.sagemath.org/ticket/19189 -- You received this message because you are subscribed to the Google Groups "sage-devel"

Re: [sage-devel] Sage in Mac OSX 11.11 (El Capitan)

Looks like Apple kept the new behavior of DYLD_* environment variables and they are not passed down to launched interpreters. Hence sooner or later we crash with symbol not found as libraries can't be located. Really we should have switched to rpaths years ago, this would have saved so much

[sage-devel] Re: is python a prereq for Sage?

On Friday, September 11, 2015 at 7:50:08 PM UTC+2, kcrisman wrote: > > Also, we do still build our own Python, else the whole python2 vs. >>> python3 issue would be moot, I guess? I hope I'm not *that* far out of >>> touch ;-) >>> >> Python 2.3 was released July 29, 2003 and well predates Sage

Re: [sage-devel] Should we still support old-style packages?

Jeroen gave the thread a misleading name (always pose loaded questions). The real subject is: Should the old-style packages be searched for. Only applies to old-style packages that are hosted on files.sagemath.org. On Friday, September 11, 2015 at 2:07:01 PM UTC+2, Sébastien Labbé wrote: > > >

Re: [sage-devel] Should we still support old-style packages?

No its a compliment --- I would do the same thing ;-) On Friday, September 11, 2015 at 2:20:32 PM UTC+2, Jeroen Demeyer wrote: > > On 2015-09-11 14:16, Volker Braun wrote: > > always pose loaded questions. > I hope that's not an accusation. > -- You received this m

[sage-devel] Re: Cannot start sage notebook with Ipython interface

You need the system-wide ssl development package, e.g. openssl-devel on redhat. Then recompile all of sage (make distclean && make) On Thursday, September 10, 2015 at 9:12:04 PM UTC+2, Sarfo wrote: > > Hi, > > I am unable to start sage notebook with the ipython interface. After > issuing

Re: [sage-devel] "faking" install of a package

you can always install the git package if your system git version is too old On Thursday, September 10, 2015 at 5:53:53 PM UTC+2, kcrisman wrote: > > In what seems to me to be relevant, I tried using sage -sdist in an older > (but not super-old) computer and got > > git: 'repack' is not a git

[sage-devel] Re: Should we still support old-style packages?

IMHO showing a warning that you are about to do something stupid but then proceeding to do so is a terrible user interface. Also, I don't like command line utilities that ask stupid questions (a.k.a. the windows UI style). Really, I still don't know a use case where you actually want to search

Re: [sage-devel] Re: Should we still support old-style packages?

On Wednesday, September 9, 2015 at 11:56:28 AM UTC+2, Jeroen Demeyer wrote: > > But even if there is just a single old-style package > which works and is useful > I disagree with that rationale. We want to maximize value for the scientific community. If that means inconveniencing a single user

Re: [sage-devel] Re: Should we still support old-style packages?

On Wednesday, September 9, 2015 at 12:13:39 PM UTC+2, Jeroen Demeyer wrote: > How does option (D) make "Sage accessible to 100 other users" compared > with options (B) or (C)? > Because not even 1 out of 100 will figure out that "python" actually tries to install the old and unsupported

Re: [sage-devel] Re: Should we still support old-style packages?

On Wednesday, September 9, 2015 at 2:14:23 PM UTC+2, Jeroen Demeyer wrote: > > There are other solutions to that problem, any of the following will do: > * a proper implementation of (B) to make them figure it out > * the proposed #19105 > * removing the old python spkg from the server > None

Re: [sage-devel] Re: Should we still support old-style packages?

On Wednesday, September 9, 2015 at 2:47:20 PM UTC+2, Jeroen Demeyer wrote: > > But by reverting #19004 (which is essentially what #19158 does), it is > also possible to install them using "sage -i ". It is possible to try, and almost always fail miserably, to install them. -- You received

Re: [sage-devel] Re: Should we still support old-style packages?

On Wednesday, September 9, 2015 at 4:43:47 PM UTC+2, kcrisman wrote: > > TOPCOM vs. topcom seems very unlikely to cause a Sage installation to > self-destruct to me > It doesn't cause data loss but it is confusing enough that even experienced developers can't tell which one to use (see

[sage-devel] Re: Should we still support old-style packages?

On Wednesday, September 9, 2015 at 5:30:54 PM UTC+2, Simon King wrote: > > For the record: A deprecation warning does *not* mean that the user is > about to do something stupid, but that (s)he is doing something that used > to be supported but soon will not be. > Exactly, which is why a

[sage-devel] Re: Should we still support old-style packages?

On Wednesday, September 9, 2015 at 5:45:14 PM UTC+2, Simon King wrote: > > However, I believe that "sage -i " should > still be supported. Agree, and this is not what this thread is about. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

Re: [sage-devel] Re: Should we still support old-style packages?

On Wednesday, September 9, 2015 at 9:39:49 PM UTC+2, Jeroen Demeyer wrote: > > But this argument completely fails when backwards compatibility is > involved. Actively removing a feature (even if broken 99% of the time) > without deprecation is a very exceptional move which should require >

[sage-devel] Re: Should we still support old-style packages?

On Wednesday, September 9, 2015 at 6:00:22 PM UTC+2, Simon King wrote: > > Are you saying that the fact that something *works* > If FEATURE gives you 1 case that works and 99 that fail then it is not a good feature. Just working rarely is not good enough. -- You received this message because

[sage-devel] Re: python egg security error showing up in 6.8 ubuntu linux binary install...

You can just delete .python-eggs, it'll then be recreated with correct permissions On Thursday, August 27, 2015 at 10:35:58 PM UTC+2, Jonathan wrote: > > Dear all, > > It appears there is a permissions error in the linux version of sage > 6.8. When running a worksheet in the notebook and

Re: [sage-devel] Tarball uploads

PS: I'm working on a patch for sage to fall back to downwload by sha1 after the mirrors were checked, this is http://trac.sagemath.org/ticket/19102 On Monday, September 7, 2015 at 6:25:26 PM UTC+2, Volker Braun wrote: > > Yes, thats intentional. Filenames might be wrong (requiring some f

Re: [sage-devel] Tarball uploads

Yes, thats intentional. Filenames might be wrong (requiring some further UI to change it) but the sha1 is tautologically correct. On Monday, September 7, 2015 at 10:17:53 AM UTC+2, Jeroen Demeyer wrote: > > On 2015-08-08 21:22, Volker Braun wrote: > > In order to streamline up

Re: [sage-devel] Tarball uploads

On Monday, September 7, 2015 at 7:29:54 PM UTC+2, Jeroen Demeyer wrote: > > So, can you remind us what exactly is the use case for this server? > The goal is no manual steps when handling third-party tarballs -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] Tarball uploads

PS: The SAGE_ROOT/upstream content can of course be programatically generated from the git repo + downloading files by sha1 On Monday, September 7, 2015 at 7:29:54 PM UTC+2, Jeroen Demeyer wrote: > > On 2015-09-07 18:25, Volker Braun wrote: > > Yes, thats intentional. Filenames mi

Re: [sage-devel] Tarball uploads

Right now you can try it out and check that you can upload tarballs. Its only truly useful with #19102 On Monday, September 7, 2015 at 8:18:28 PM UTC+2, Jeroen Demeyer wrote: > > On 2015-09-07 19:38, Volker Braun wrote: > > On Monday, September 7, 2015 at 7:29:54 PM UTC+2, Je

Re: [sage-devel] What is the expected output of .version()?

There is a canonical "version without patchlevel" provided by the sage_bootstrap library, nobody should re-implement "chopping off chars". E.g. (note the edge case): In [1]: import sys In [2]: sys.path.append('build') In [3]: from sage_bootstrap.package import Package In [4]:

Re: [sage-devel] Re: TAB, the patchbot and trac

Let me know if you need any pointers... My hint would be to load it into an IPython session so you can make interactive trac queries. Then the rest is easy. On Sunday, September 6, 2015 at 10:34:08 PM UTC+2, Frédéric Chapoton wrote: > > using the XMLRPC query protocol > -- You received this

Re: [sage-devel] Re: TAB, the patchbot and trac

I'm pretty sure you can get the info from the trac xmlrpc interface. The data is xml-encoded so there is no problem with tabs. You can find example code in the "git trac" command. On Sunday, September 6, 2015 at 9:00:46 PM UTC+2, Frédéric Chapoton wrote: > > No, there is nothing like that, no

Re: [sage-devel] Generate Python classes from C++ headers?

On Saturday, September 5, 2015 at 9:27:50 PM UTC+2, bluescarni wrote: > > With Boost Python you also get the original C++ class as a Python class. > Of course the downside is that you have to write your wrapper in C++. Which is an awesomely capable language and can capture pretty much the

Re: [sage-devel] Tarball uploads

Port 8080 seems firewalled now, I moved it to the standard port: http://fileserver.sagemath.org On Friday, September 4, 2015 at 10:08:48 AM UTC+2, Jeroen Demeyer wrote: > > On 2015-08-08 21:22, Volker Braun wrote: > > http://fileserver.sagemath.org:8080/ > > Seems d

Re: [sage-devel] Does python pass its test suite on any platform?

gdb has its own embedded python, so it often fails if you force sage's libpython via LD_LIBRARY_PATH On Friday, September 4, 2015 at 12:21:21 AM UTC+2, François wrote: > > After opening the firewall only test_gdb was left failing. > > Francois > -- You received this message because you are

Re: [sage-devel] random doctest failure in modular/modform/ambient.py

Arguably its a bug in how we use linbox; It uses random primes and we test examples where there is a sizeable chance that it runs ouf of primes. There are simply computations that you can't do with just machine integers, so a) we shouldn't work with examples that are close to the limit and b)

[sage-devel] Re: Missing igraph package on the mirrors?

OK I've updated the packages. This is precisely why we need a self-service solution to managing tarballs, which is what I've been working on. I for one don't have time to read 5 paragraphs of prose describing how to download and rename upstream tarballs like in the linked ticket. And the

[sage-devel] Re: Missing igraph package on the mirrors?

On Tuesday, September 1, 2015 at 10:42:20 AM UTC-4, Nathann Cohen wrote: > > Some time ago you sent a link toward a new webpage interface to upload > tarballs. Is it what we should be using now? Should we update the > developer's manual in any way? > Not yet, I'll post again when its finished.

[sage-devel] Re: Access to my cohomology spkgdocumentation is blocked

I'd recommend bitbucket/github/... Presumably you are using some kind of version control for your files already. Github pages is an easy way to host your documentation, too. On Friday, August 28, 2015 at 5:15:11 AM UTC-4, Simon King wrote: Hi! It was pointed out on sage-support that

[sage-devel] Re: Access to my cohomology spkgdocumentation is blocked

of file hosting or long-term storage. On Friday, August 28, 2015 at 10:18:15 AM UTC-4, Simon King wrote: Hi Volker, On 2015-08-28, Volker Braun vbrau...@gmail.com javascript: wrote: I'd recommend bitbucket/github/... Presumably you are using some kind of version control for your files already

Re: [sage-devel] Re: Tarball uploads

On Thursday, August 27, 2015 at 10:22:23 AM UTC-4, John Cremona wrote: How would I know that it had finished? After selecting the file it goes back to the choose file page with no apparant change and nothing happening. You can upload multiple files, so its by design that you can choose

[sage-devel] Re: Tarball uploads

-4, Dan Drake wrote: On Saturday, August 8, 2015 at 12:22:18 PM UTC-7, Volker Braun wrote: In order to streamline updating third-party tarballs I've written a small web app where you can directly upload them. That way you don't need to host files yourself. Plus, the files can be retrieved

<    4   5   6   7   8   9   10   11   12   13   >