Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

[Julien Puydt]

Hi,

Le vendredi 24 septembre 2021 à 12:23 +0100, Dima Pasechnik a écrit :
> 
> On Fri, 24 Sep 2021, 02:12 Matthias Koeppe,
>  wrote:
> > I repeat my strong objections to the proposed change -- which does
> > not solve any problems and only creates new ones.
> > 
> > 1. When you refer to the "huge time sink", I think you are
> > referring to painful memories from some distant past. But we have
> > no current or recent problem with either the gcc or gfortran
> > package. I fixed the last problems with the gfortran package in
> > early 2020; there have not been any problems since.
> 
> I am referring to the time sink caused by the mere presence of
> gcc/gfortran spkg in Sage. Namely,
> 
> - support of outdated systems nobody uses (many tickets supporting
> past EOL systems recently)
> 
> - support of modern, but broken, systems (e.g. we just should not
> care that a particular Fedora version broke its gcc, it's not out
> problem, let us not try to bite more than we can chew)
> 
> - users who attempt to build gfortran as they don't have it installed
> - many fail, but I guess many more succeed,
> and rebuild it for each new release
> 
> - our Linux and  macOS binary builds are increasingly useless, and a
> timesink for everyone involved, potential users too.
> 
> > 

I made the point years ago that sagemath should be broken in two:

- sagemath-the-software ;

- sagemath-the-distribution.

This thread is an illustration of why that would simplify matters:

- sagemath developpers could focus on making the sofware work (both
increasing its scope/efficiency and solving real issues) ;

- the various distribution packagers would handle their specific
problems, and only complain upstream when there's an actual problem.

Cheers,

J.Puydt

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/701d2621e3dd450517b1cb4d572ab5f2df2587ac.camel%40gmail.com.

Re: [sage-devel] Flint-2.6.0 alpha release (testing requested)

[Julien Puydt]

Le jeudi 14 mai 2020 à 18:51 +0200, 'Bill Hart' via sage-devel a
écrit :

> The (latest) commit c6319d1d36248f2fc699e833ab2f6fa70d21e906 in the
> official Flint repository [1] is flint-2.6.0-alpha1.

You could tag it : that would be clearer.

Something like "git tag 2.6.0-alpha1" then "git push --tags" is enough.
That way the repository will document which tag is that alpha1, and
github will make tarballs automatically.

Cheers,

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8f107ad5fbdf0b8e37937d83aa75b7fd5144819c.camel%40gmail.com.

Re: [sage-devel] Packaging Sage?

[Julien Puydt]

Le dimanche 10 mai 2020 à 15:02 +0200, Thierry Thomas a écrit :
> 
> TL;TR: Packagers, how do you deal with Sage to package it for your
> Linux distribution (or *BSD system)?


For Debian, we use our packages as much as possible ; the repository
can be seen here:

https://salsa.debian.org/science-team/sagemath

in particular :
- debian/rules is the script handling the building and it's calling a
pruner.py which makes sagemath use system packages ;
- debian/patches/ has a list of patches to sagemath, to make it
compatible with Debian's packages and file paths.

I hope that helps,

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e572d55b8bbeb54147748cb5624006743b447fe7.camel%40gmail.com.

Re: [sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

[Julien Puydt]

Hi,

Le samedi 02 mai 2020 à 14:03 +0100, Dima Pasechnik a écrit :
> 
> you can recreate  a patch from 
> https://github.com/mkoeppe/pynac/releases
> 

indeed :

https://github.com/pynac/pynac/compare/pynac-0.7.26...mkoeppe:pynac-0.7.26.sage-2020-04-03

and it shows :
- cygwin patches ;
- modifications for Python detection ;

all of which shouldn't make the pynac in Debian insuitable for sagemath
use.

Thanks!

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/df120b572b4a3cc2aea15101596cdddab092850e.camel%40gmail.com.

[sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

[Julien Puydt]

Hi,

I'm maintaining pynac in Debian, with the goal of keeping sagemath
packaged in Debian.

According to :
https://git.sagemath.org/sage.git/tree/build/pkgs/pynac/package-version.txt?h=develop

the version in sage is now 0.7.26.sage-2020-04-03, while upstream is
0.7.26.

Is there some patch I could add to the Debian packaging? Did it go
through upstream for approval? I had a look around and didn't find the
information...

Cheers,

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4dda6e5fc43971bcbf7349263c01c52de90b7034.camel%40gmail.com.

Re: [sage-devel] Re: Database of number fields

['Julien Puydt' via sage-devel]

Le samedi 22 février 2020 à 18:36 -0800, Nils Bruin a écrit :
> On Saturday, February 22, 2020 at 12:54:47 PM UTC-8, Snark wrote:
> > If I understand well, there's a series of build steps : 
> >   pari code -> data files -> sobj 
> > and the last step is jones.py. 
> > 
> 
> As far as you, the software packager, are concerned, the only
> relevant step just data files -> sobj. "jones.py" actually gives you
> the means of doing that conversion. It's indeed a little vague from
> which data files the current "sobj" was constructed. That probably
> means you get to pick!.

Not really : as the software packager in Debian, I'm supposed to use
sources, so I am supposed to start from the initial computing scripts,
turn them into data files and then into sobj.

Being vague about what the sources are when the package is under GPL is
a concept I'm a bit uncomfortable with.

> Constructing the original data files earned the authors a scientific
> publication. Replicability is nice, but I don't think it's required
> to be explicitly performed every time software is packaged/installed
> (and indeed, it may have cost significant CPU cycles, even if the gp
> program used for it is tiny).

If the initial computing scripts take very long, then as an exception,
I'll ship the data files and build from them. But I'll still ship the
initial computing scripts so anyone with enough computing power
can replicate! [The Debian build hosts stop compilations after 150min
of log-inactivity, for example.]

The size of gp doesn't matter : my package would just build-depend, but
not depend on it.

> I don't think there's going to be any versioning. Once you've
> tabulated all the quintic number fields unramified outside {2,3,5,7},
> there's very little that's going change anymore about it (although
> people could discover errors in your tabulation ...).

Well, I'll version on the day I got the data files then. Or the
computing scripts.

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/28c78e125ced6ff43b54ee265c6141f3fd540ed9.camel%40laposte.net.

Re: [sage-devel] Re: Database of number fields

['Julien Puydt' via sage-devel]

Hi,


Le samedi 22 février 2020 à 09:33 -0800, Nils Bruin a écrit :
> Sorry, code to produce the sobj is already included in the package.
> From jones.py:

> def _init(self, path):
> """
> Create the database from scratch from the PARI files on John
> Jones's
> web page, downloaded (e.g., via wget) to a local directory,
> which
> is specified as path above.
> 
> INPUT:
> 
> 
> -  ``path`` - (default works on William Stein install.)
>path must be the path to Jones's Number_Fields directory
>http://hobbes.la.asu.edu/Number_Fields These files should
> have
>been downloaded using wget.
> 
> 
> EXAMPLES: This is how to create the database from scratch,
> assuming
> that the number fields are in the default directory above:
> From a
> cold start of Sage::
> 
> sage: J = JonesDatabase()
> sage: J._init()   # not tested
> ...
> 
> This takes about 5 seconds.
> """
> from sage.misc.misc import sage_makedirs
> x = PolynomialRing(RationalField(), 'x').gen()
> self.root = {}
> self.root[tuple([])] = [x - 1]
> if not os.path.exists(path):
> raise IOError("Path %s does not exist." % path)
> for X in os.listdir(path):
> if X[-4:] == "solo":
> Z = path + "/" + X
> print(X)
> for Y in os.listdir(Z):
> if Y[-3:] == ".gp":
> self._load(Z, Y)
> sage_makedirs(JONESDATA)
> save(self.root, JONESDATA + "/jones.sobj")
> 
> Modulo collecting the text source that aren't included (but readily
> available on a web site), the code to compile the database is already
> there! You might want to check with the author if he/she is OK with
> you downloading and distributing the text files separately, but for
> robustness I think you'd be doing the community a favour by wrapping
> the data in a "source distribution" too.

If I understand well, there's a series of build steps :
  pari code -> data files -> sobj
and the last step is jones.py.

But then what I want is the pari code, as that's the source.

(Unless computing the data files is incredibly long, in which case I'll
ship both the pari code and the data files, with a nice notice to
explain that I ship pre-build for a good reason.)

It's not clear which data files have been used to generate the current
sagemath package : https://hobbes.la.asu.edu/Number_Fields/ points to
several pages (including a 404), and on each of these pages, there's a
link to .gp files which must be the ones getting used, if I understand
well.

And how is versioning managed?

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f36e52ce492d702904f9817f6c227da4e0ff546b.camel%40laposte.net.

[sage-devel] Database of number fields

['Julien Puydt' via sage-devel]

Hi,

I wanted to package sagemath's optional package
"database_jones_numfield" for Debian, but it appears to be merely a
binary object.

For Debian, I need sources : where is the generation script I can use
to re-generate the .sobj?

Thanks,

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/77bac9a3e88478d2567400867a739535f3dc27c0.camel%40laposte.net.

Re: [sage-devel] Python 2->3 incompatibility in unpickling

['Julien Puydt' via sage-devel]

Le mercredi 22 janvier 2020 à 21:35 +, Simon King a écrit :
> Consequently, when unpickling my old data with Python-3, I want the
> Python-2 str to be interpreted as bytes. However, Python-3 insists on
> misinterpreting it as str, and I have trouble to turn that str into
> an appropriate bytes.

Did you try forcing the pickling "protocol" parameter ?

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3bc5a1f8b524d8315c124f498b8497fd93550862.camel%40laposte.net.

Re: [sage-devel] Re: Unpickling problem (backwards incompatibility) in Python 3

['Julien Puydt' via sage-devel]

Hi,
Le 02/09/2019 à 22:43, Simon King a écrit :
> AFAIK, what I need to unpickle my old data is a way to tell Python-3
> that it shall (at least temporarily) unpickle all strings as bytes, in
> the sense that the pickled string  '\x80\x1f' should be understood as
> b'\x80\x1f'. Is there a way?

I tried to run the following two small scripts, and it didn't complain:


#!/usr/bin/python2

import pickle

s='\x80\x1f'
with open('/tmp/data.pickle', 'w') as handle:
pickle.dump(s, handle, protocol=2)





#!/usr/bin/python3

import pickle

with open('/tmp/data.pickle', 'rb') as handle:
s = pickle.load(handle, encoding='bytes')



I hope that helps,

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4347937a-bd99-b854-cf90-6bc0bb394358%40laposte.net.

Re: [sage-devel] Cremona's database of elliptic curves over rationals : compilation?

['Julien Puydt' via sage-devel]

Hi,

Le 21/08/2019 à 13:43, John Cremona a écrit :
> I suggest that you ship the whole thing so that a debian (or derivative)
> user who installs the package gets everything they could also get by
> either git-cloning the ecdata repository (but without the git history)
> or the tarball from github.

Well, my source package has files, but the binary only has the .db file,
so I don't have much motivation to ship a complete source...

There's also the fact that I only need good copyright+license
assignments on files in the source package - so cutting down on it is
interesting.

> It would be quite possible for the Sage interface to extract more of the
> data than it does.  Since William and I first set up this spkg in about
> 2006 the extent of the data stored in ecdata has grown -- not only the
> number for curves, also more date with each curve.   For example:  the
> integral points on each curve.  I do not plan to do this myself, partly
> because we are working on a Sage-LMFDB interface which would allow this
> additional data (and more) to be downloaded directly from the LMFDB,
> making this spkg redundant except for those need offline access to the
> database.

The motivation for the packaging is sagemath ; if it gets to use more of
ecdata, then it will still be time to complete my source package.

Cheers,

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ae1b55d5-c34c-5857-6001-8d523afec29d%40laposte.net.

Re: [sage-devel] Cremona's database of elliptic curves over rationals : compilation?

['Julien Puydt' via sage-devel]

Hi,

Le 20/08/2019 à 17:02, John Cremona a écrit :
> Julien,
> 
> [By the way, the optional spkg which is relevant here is
> database_cremona_ellcurve and *not* elliptic_curves.]

Yes ; in Debian:
- sagemath's standard elliptic_curves is
sagemath-database-elliptic-curves (I'm the maintainer) ;
- sagemath's optional database_cremona_ellcurve will be
sagemath-database-cremona-elliptic-curves (I'll be the maintainer).

> I have tried your new py code to produce a new version of the database
> file: it appears to work perfectly, and will compare it with what the
> existing Sage code creates.  I know rather little about SQLITE -- should
> the resulting files be identical?  Even if not, I will try using both
> output db files and running all Sage tests.  The db files have the same
> size (613924864 bytes -- the new version will contain over 50 more
> curves than the old) so perhaps the only difference is the order in
> which data was added.  I'll test.

Thanks!

> I did also  need to patch sage/databases/cremona.py  since the build()
> function requires SAGE_SHARE to be imported.  Running that, I see that
> (as you may have noticed) there are many files in the ecdata repository
> / tarball which Sage does not use at all.  I adjusted the tar command to
> only extract the ones used.  (It would be possible for Sage to extract
> more and use more, but that is an issue for another day).

Yes, I was pondering just not shipping them.

> So I will soon post a new spkg at trac #28372.  Other than that, what is
> the plan?  I would like to add JP's python script to the ecdata/scripts
> directory for future use anyway.  I have wondered exactly why Sage's
> codebase contained this code for creating a specific new optional spkg. 
> Of course in the same file (src/databases/cremona) is code for creating
> the mini version of the database, but that is something which never
> needs to be updated.

I'm all for using a simple standalone Python script instead of depending
on all of sagemath...

Cheers,

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/da72a46e-62db-037b-e9fc-3c781a825a1e%40laposte.net.

Re: [sage-devel] Cremona's database of elliptic curves over rationals : compilation?

['Julien Puydt' via sage-devel]

Le 21/07/2019 à 13:19, John Cremona a écrit :
>  
> On Sat, 20 Jul 2019 at 21:08, 'Julien Puydt' via sage-devel
> mailto:sage-devel@googlegroups.com>> wrote:
> 
> Le 19/07/2019 à 16:41, John Cremona a écrit :
> 
> > Not written by me, just used by me to update Sage's optional package. 
> > William would remember who wrote it.
> 
> I crossed the build/pkgs/elliptic_curves and
> src/sage/databases/cremona.py files and obtained the following build
> script.
> 
> 
> I'm a bit annoyed because the elliptic_curve pkg ships a 470M
> cremona.db, and I get a 479M cremona.db ; but perhaps it's because I
> pack everything (no bound on the genus : everything in the files!)?
> 
> "genus" --> "conductor".  This would be explained (I think) by the fact
> that the shipped spkg goes up to conductor 400k while ecdata on github
> now goes up to 410k.  That's all.  I will soon have finished to 500k and
> then the spkg will presumably be around 500M.

Yes, conductor.

Could you add a nice LICENSE file to clarify things? I think it's public
domain since it's a list of mathematical objects... but I'd rather have
a nice file by the author to tell that :-P

Thanks,

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/63694530-e253-7c92-f0f5-2d2838d2e666%40laposte.net.

Re: [sage-devel] Cremona's database of elliptic curves over rationals : compilation?

['Julien Puydt' via sage-devel]

Le 19/07/2019 à 16:41, John Cremona a écrit :

> Not written by me, just used by me to update Sage's optional package. 
> William would remember who wrote it.

I crossed the build/pkgs/elliptic_curves and
src/sage/databases/cremona.py files and obtained the following build script.


I'm a bit annoyed because the elliptic_curve pkg ships a 470M
cremona.db, and I get a 479M cremona.db ; but perhaps it's because I
pack everything (no bound on the genus : everything in the files!)?

Does it look good?

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6a8ed2dc-7166-fe90-5f1e-f0956fab9386%40laposte.net.
#!/usr/bin/python3

import os
from sqlite3 import connect

def create_db():

target = 'cremona.db'

print("Creating database {0}".format(target))
if os.path.exists(target):
os.remove(target)

con = connect(target)

con.execute('CREATE TABLE t_class(conductor INTEGER,'
' class TEXT PRIMARY KEY, rank INTEGER, L REAL, deg INTEGER)')
con.execute('CREATE TABLE t_curve(class TEXT,'
' curve TEXT PRIMARY KEY, eqn TEXT UNIQUE,'
' gens TEXT, tors INTEGER, cp INTEGER,'
' om REAL, reg REAL, sha)')
con.execute('CREATE INDEX i_t_class_conductor ON t_class(conductor)')
con.execute('CREATE INDEX i_t_curve_class ON t_curve(class)')

return con

def populate_allcurves(con):
print('Inserting all curves')
for filename in sorted(os.listdir('allcurves')):
class_data = []
curve_data = []
with open(os.path.join('allcurves', filename)) as fich:
print('\tConsidering {0}'.format(filename))
for line in fich.readlines():
N, iso, num, ainvs, r, tor = line.split()
cls = N+iso
cur = cls+num
if num == "1":
class_data.append((N,cls,r))
curve_data.append((cur,cls,ainvs,tor))
con.executemany('INSERT INTO t_class (conductor,class,rank)'
' VALUES (?,?,?)', class_data)
con.executemany('INSERT INTO t_curve (curve,class,eqn,tors)'
' VALUES (?,?,?,?)', curve_data)
con.commit()

def populate_allbsd(con):
print('Inserting all BSD')
for filename in sorted(os.listdir('allbsd')):
# why, oh why? There's a single problematic file...
if not filename.startswith('allbsd'):
break
class_data = []
curve_data = []
with open(os.path.join('allbsd', filename)) as fich:
print('\tConsidering {0}'.format(filename))
for line in fich.readlines():
N, iso, num, eqn, rank, tor, cp, om, L, reg, sha  = line.split()
cls = N+iso
if num == "1":
class_data.append((L,cls))
curve_data.append((cp,om,reg,eval(sha),cls+num))
con.executemany("UPDATE t_class SET L=? WHERE class=?", class_data)
con.executemany("UPDATE t_curve SET cp=?,om=?,reg=?,sha=? WHERE "
" curve=?", curve_data)
con.commit()

def populate_allgens(con):
print('Inserting all gens')
for filename in sorted(os.listdir('allgens')):
curve_data = []
with open(os.path.join('allgens', filename)) as fich:
print('\tConsidering {0}'.format(filename))
for line in fich.readlines():
v = line.split()
gens = '['+','.join(v[6:6+int(v[4])]).replace(':',',')+']'
curve_data.append((gens,''.join(v[:3])))
con.executemany("UPDATE t_curve SET gens=? WHERE curve=?",
curve_data)
con.commit()

def populate_degphi(con):
print('Inserting all degphi')
for filename in sorted(os.listdir('degphi')):
class_data = []
with open(os.path.join('degphi', filename)) as fich:
print('\tConsidering {0}'.format(filename))
for line in fich.readlines():
N, iso, num, degree, primes, curve = line.split()
class_data.append((degree,N+iso))
con.executemany('UPDATE t_class SET deg=? WHERE class=?',
class_data)
con.commit()

def repack(db):
print('Repacking the database')
con.execute('VACUUM')

if __name__ == '__main__':
con = create_db()
populate_allcurves(con)
populate_allbsd(con)
populate_allgens(con)
populate_degphi(con)
repack(con)
con.close()

Re: [sage-devel] Cremona's database of elliptic curves over rationals : compilation?

['Julien Puydt' via sage-devel]

Le 19/07/2019 à 15:53, John Cremona a écrit :
> The code to create the database is in Sage itself. 
> See 
> https://github.com/sagemath/sage/blob/master/src/sage/databases/cremona.py.

Oh, dear... I'll see if I can't turn it into a much shorter piece of code...

> I recommend that you hold off for a short while since I am about to
> update the database to include all conductors up to 50 (now it is
> 40).  This is thanks to Andrew Sutherland + Simon Foundation +
> Google CP, which ran 80,000 simultaneous jobs on 600,000 cores last
> night.  So right now I am drowning in data but it will all be sorted
> before long.

Oh! That sounds like an amazing project!

I can still try to prepare the package with the old data, and only
upload to Debian when the new data is there.

Thanks!

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/65226129-a3dc-5805-3760-23b1b3a5388b%40laposte.net.

[sage-devel] Cremona's database of elliptic curves over rationals : compilation?

['Julien Puydt' via sage-devel]

Hi,

I'm considering packaging this database for Debian.

I have upstream files: https://github.com/JohnCremona/ecdata

I know sagemath wants a cremona.db sqlite3 database, as that's what is
in the src/ for the pkg.

What I miss is the file turning the data files into the database!

For the smaller database, there is:
https://git.sagemath.org/sage.git/tree/build/pkgs/elliptic_curves/spkg-install.py

But as far as I can tell the two databases don't even have the same format:
https://git.sagemath.org/sage.git/tree/src/sage/databases/cremona.py

Can someone lend a hand?

JP

-- 
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/922ea2c1-1525-7060-4bbb-06a268f64f5b%40laposte.net.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)

['Julien Puydt' via sage-devel]

Le 10/01/2019 à 22:03, Jeroen Demeyer a écrit :

On 2019-01-10 21:51, 'Julien Puydt' via sage-devel wrote:

Didn't François mention changing SAGE_ROOT wasn't needed?


He said

SAGE_ROOT should only be needed for the packaging system
and possibly the doctests. I regard any needs for SAGE_ROOT at runtime
a bug.


In other words: it is still needed, but that's a bug. And I agree with 
that.



https://trac.sagemath.org/ticket/27040


JP

--
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)

['Julien Puydt' via sage-devel]

Hi,

Le 10/01/2019 à 21:48, Jeroen Demeyer a écrit :

On 2019-01-10 20:46, 'Julien Puydt' via sage-devel wrote:

Perhaps upstream would accept such a trivial change?


If you make a ticket for it, sure. But it won't help with SAGE_ROOT.


Didn't François mention changing SAGE_ROOT wasn't needed?

JP

--
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)

['Julien Puydt' via sage-devel]

Le 10/01/2019 à 20:07, François Bissey a écrit :

I have recently made the following change in sage-on-gentoo’s env.py
_add_variable_or_fallback('SAGE_LOCAL',  sysconfig.get_config_var("prefix”))

which means SAGE_LOCAL is now pulled from the system rather than
a seeded value (as it was before).



Perhaps upstream would accept such a trivial change?

JP

--
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

['Julien Puydt' via sage-devel]

Hi,

On 26/08/2018 17:47, Frédéric Chapoton wrote:
The patchbot report on sage+python3  for 8.4.b2 has still *many* (and I 
mean *_many_*) failing doctests. But it also stops badly in the way 
shown below, complaining that too many files are open. Could somebody 
investigate this issue, please ?
That probably means the doctesting framework is leaking file 
descriptors, ie: it opens each and every file but never closes them.


I would search:
(1) either a single piece of code which does all the opening and never 
closes anything during the whole run (the least likely scenario)
(2) or a piece of code forking correct workers (ie: they would 
open+close correctly) but leaking them (so the closing part doesn't 
happen) (the most likely scenario).


Someone familiar with the code should probably have a look and would be 
more efficient at spotting the problem.


jpuydt on irc.debian.org

--
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] GNU/Linux debian sid/testing: "Error building Sage" 8.3 from git

['Julien Puydt' via sage-devel]

Hi,

Le 17/08/2018 à 11:17, Jörg-Volker a écrit :

Another question I have after looking at the binary package of sage for 
debian 9 is: how was that built? Since in this package all packages 
using blas and lapack are linked against the system libraries 
libblas.so, liblapack.so, and libopenblas.so.


Building sage isn't as simple as we'd like yet:
https://wiki.debian.org/DebianScience/Sage

jpuydt on irc.debian.org

--
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] GNU/Linux debian sid/testing: "Error building Sage" 8.3 from git

['Julien Puydt' via sage-devel]

Hi,

Le 14/08/2018 à 11:20, Jörg-Volker a écrit :


Hi,
trying to build Sage 8.3 on my GNU/Linux debian testing/sid system with 
local gcc suite version 8.2.0 fails while compiling scipy. This is on a 
desktop computer with 4 cores (8 threads) and 32 GB RAM.


I have no clue what "testing/sid" might be... since as far as I know 
"sid==unstable"



The build command was

MAKE='make -j8' SAGE_INSTALL_GCC=no SAGE_BUILD_DIR=/tmp/sage-b  make
build


The relevant log file shows

 Traceback (most recent call last):
   File "", line 1, in 
   File "/tmp/.cache-walt/pip-9Uwgks-build/setup.py", line 416, in 

 setup_package()
   File "/tmp/.cache-walt/pip-9Uwgks-build/setup.py", line 396, in 
setup_package
 from numpy.distutils.core import setup
   File
"/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/__init__.py", 
line 142, in 
 from . import add_newdocs
   File
"/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/add_newdocs.py", 
line 13, in 
 from numpy.lib import add_newdoc
   File
"/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/lib/__init__.py", 
line 8, in 
 from .type_check import *
   File

"/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/lib/type_check.py", 
line 11, in 
 import numpy.core.numeric as _nx
   File

"/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/core/__init__.py", 
line 26, in 
 raise ImportError(msg)
 ImportError:
 Importing the multiarray numpy extension module failed.  Most
 likely you are trying to import a failed build of numpy.
 If you're working with a numpy git repo, try `git clean -xdf` (removes 
all
 files not under version control).  Otherwise reinstall numpy.

 Original error was: /usr/lib/x86_64-linux-gnu/libblas.so.3: undefined 
symbol: sgemv_thread_n

 Running setup.py install for scipy: finished with status 'error'

The system has OpenBLAS installed but with a newer version 0.3.2.

Any ideas?

I've built previous versions of Sage on this system before (with gcc 7.3.0).



Notice that there is a sagemath 8.3 in preparation for Debian, see :
https://people.debian.org/~thansen/debian-sage-status.html

so perhaps you could lend a hand making it to unstable?

jpuydt on irc.debian.org

--
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

['Julien Puydt' via sage-devel]

Hi,

Le 25/10/2017 à 00:08, Eric Gourgoulhon a écrit :
> Le mardi 24 octobre 2017 20:58:17 UTC+2, Emmanuel Charpentier a écrit :
> 
> 
> It is true. But we are hoisted by our own petard : from our tutorial
>  :
> "The Sage download file comes with “batteries included”. In other
> words, although Sage uses Python, IPython, PARI, GAP, Singular,
> Maxima, NTL, GMP, and so on, you do not need to install them
> separately as they are included with the Sage distribution."
> I fail to see how this would not apply to OpenSSL (under the heading
> "and so on")...
> 
>  
> I have the feeling that the current tendency is towards a more modular
> and lighter Sage, which deviates from the original "batteries included"
> philosophy. Maybe the latter should be rephrased as "mathematical
> batteries included". This would exclude standard "technical"  software
> like OpenSSL, which should be provided systemwide.

I'd vote for a strict separation of sage-the-distribution and
sage-the-software : I'm not interested at all in the former, and I think
it hampers the latter for which I care.

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

['Julien Puydt' via sage-devel]

Le 23/10/2017 à 15:40, Emmanuel Charpentier a écrit :
> BTW : the vote closes in about 20 minutes. This is your last chance to
> take back any "too hasty" votes.

My vote: no openSSL now - wait until the license issues are solved

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Use system R with sage?

['Julien Puydt' via sage-devel]

Hi,

Le 22/10/2017 à 10:17, Dima Pasechnik a écrit :
> my limited experience with helping advanced R users was that it is not really 
> possible for them to use R from Sage, as they needed R packages that in turn 
> needed Java runtime.
> 
> And they much preferred things done in R-studio.

At some point, the question of correctly separating
sage-the-distribution and sage-the-software will have to be tackled...

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] python3 status

['Julien Puydt' via sage-devel]

Hi,

Le 13/10/2017 à 17:56, Frédéric Chapoton a écrit :
> Cool, no ? Or maybe nobody cares ?

Extremely cool!

> Many things are still not working. The cmp problem has been much
> reduced, but still not fully fixed. On our way is a large-scale unicode
> problem, and maybe another large scale hash problem.

Why are unicode and hash problems?

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Faster way to load python code

['Julien Puydt' via sage-devel]

Hi,

Le 17/09/2017 à 11:56, Simon King a écrit :
> On 2017-09-17, Dima Pasechnik  wrote:
>> Isn't it what pickle/cPickle is for? 
> 
> I don't want to store data, I want to read them. And I am not the
> one who stored them. So, I have to take the textfiles as I get
> them.

You could have the textfiles *and* the pickles, with the following api:
- "refresh" loads the textfiles and dumps them to pickles (that is slow,
and done only when the textfiles are updated) ;
- "load" load the pickles (that is fast and is done most often).

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Calculation Error

['Julien Puydt' via sage-devel]

Hi,

Le 26/08/2017 à 22:57, Dr. David Kirkby (Kirkby Microwave Ltd) a écrit :
> I'm not a mathematician, but believe 0^0 is undefined.

You can either consider 0^0 to be undefined or that it is 1 by
convention : both are "correct", and neither should be considered a bug.

Snark on #debian-science

-- 
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] python3 (not yet, and not for soon)

['Julien Puydt' via sage-devel]

Hi,

Le 07/08/2017 à 11:54, Erik Bray a écrit :

> I'm working on a better solution to this as part of a more general
> reworking of how Sage's dist handles dependencies that can be
> fulfilled by multiple packages (in this case the dependency being
> 'python'--specifically the Python used for Sage itself).  I have a
> prototype at [1] but there are several things about it I'm unhappy
> with, and I want to redo it on top of some even lower-level overhauls
> I'm working on (e.g. [2]).

I would like to make the point that having a packaging which is :
- versioned ;
- with dependency resolution ;
- including virtual packages ;
is definitely a sage-as-a-distribution problem.

Please take into account that sage-as-a-software should be kept easily
package-able by other distributions.

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Python3?

['Julien Puydt' via sage-devel]

Hi,

On 19/01/2017 18:44, William Stein wrote:

On Thu, Jan 19, 2017 at 9:39 AM, Jeroen Demeyer  wrote:

On 2017-01-19 17:17, William Stein wrote:


... and presumably what we already decided is now completely
impossible to implement and banned from Python3?



I don't think we ever decided anything. For Parents, we use Robert
Bradshaw's implementation from 2008 but it's not documented what it does or
why it does things that way. For example, there is a doctest

sage: ZZ < QQ
True

but I doubt that this is the right thing to do.


Let me rewrite the above: ... and presumably what we already
**implemented** is now completely
impossible to implement and banned from Python3?


Well, if it is implemented but doesn't really make sense, is it that big 
a problem to drop it for the transition to Python 3 ?


Snark on #debian-science

--
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Python3?

['Julien Puydt' via sage-devel]

Hi,

On 19/01/2017 08:47, Frédéric Chapoton wrote:


The problem with cmp is quite hard, and it seems that every instance of
cmp() must be handled separately. I have gained some experience on the
subject, but given the lack of reviewers, this implies a very slow pace.
This cmp problem should be the last remaining thing to handle before
reaching 1A) and maybe even 1B)


is there some place with a good summary of the cmp situation, and can 
you point at some patches showing how the matter is fixed?


Thanks,

Snark on #debian-science

--
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Release note auto-generation RFC

['Julien Puydt' via sage-devel]

On 12/01/2017 09:54, Kwankyu Lee wrote:

Wouldn't some directive like "If you think ticket #314159 is of wider
interest, all you have to do is to fill in the Changes-7.6.rst file"
make it possible to both drop this new tool and allow a richer
structure? Said Changes-.rst could start as a copy from a
Changes-template.rst with a prepared structured, which the release
manager would prune at the last moment to remove empty sections.

I guess the idea is to have one "news fragment" file for one merged
ticket instead of a single file that contains all news.


And my point is that this tool doesn't bring anything substantial : if 
you have to get out of your way to add something to the news, then at 
least do so for something nice and complete. In my opinion the 
categories provided by towncrier make it a tiny convenience for a small 
project and uninteresting for a large project.


Now, if towncrier made it possible to name the fragment files something 
like 314159.features.algebraic-geometry.elliptic-curves and generated a 
more structured changelog from that, that would be more convincing. 
[Using a dictionary somewhere to turn the various filename chunks into 
something human-readable and falling back to changing '-' to space and 
capitalizing the first word, say].


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Release note auto-generation RFC

['Julien Puydt' via sage-devel]

Hi,

On 12/01/2017 00:09, Volker Braun wrote:

There is a somewhat painless approach to generating human-readable
release notes using https://github.com/hawkowl/towncrier. As far as the
ticket author is concerned, if you think that your ticket #12435 is of
wider interest and should be announced then all you'd have to do is add
a file

echo "Added the last twin prime" > newsfragments/12435.feature

Note that the fragment filename starts with the ticket number, so it
won't conflict with other news fragments. Then, when making a new
release, I concatenate the fragments into NEWS.rst as, for example,
in https://github.com/hawkowl/towncrier/blob/master/NEWS.rst


I have to point out that this isn't auto-generated since a specific 
command has to be entered.


I also notice that towncrier has pretty rough single-level structuring 
(feature, bugfix, doc, removal, misc), which might be a bit limitative 
for a large project like sagemath.


Wouldn't some directive like "If you think ticket #314159 is of wider 
interest, all you have to do is to fill in the Changes-7.6.rst file" 
make it possible to both drop this new tool and allow a richer 
structure? Said Changes-.rst could start as a copy from a 
Changes-template.rst with a prepared structured, which the release 
manager would prune at the last moment to remove empty sections.


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

['Julien Puydt' via sage-devel]

Hi,

On 28/10/2016 15:39, Emmanuel Charpentier wrote:


However, this does not seem to be a problem per se : Debian (one of the
most nitpicking distros in terms of licensing)   happily ships libraries
and utilities (such as cups, for starter) linked with openssl-linked
libcurl. I think that it would be interesting to ask them how they
reconcile the (inconsistent) wordings of the licenses involved.


It's easy to ask:

https://www.debian.org/legal/

Snark on #debian-science

--
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Upstream links for purely sage package

['Julien Puydt' via sage-devel]

Hi,

On 07/10/2016 12:19, Jeroen Demeyer wrote:

On 2016-10-06 12:58, 'Julien Puydt' via sage-devel wrote:

For those sage-is-upstream packages, I was pointing the helper to
 http://files.sagemath.org/spkg/upstream/
but now it looks like those are not available anymore on the
sagemath.org server.


I believe that this is a temporary outage of the files.sagemath.org server.



I asked because it lasted since a few days, but indeed it looks like 
everything is back.


Thanks!

Snark on #debian-science

--
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Upstream links for purely sage package

['Julien Puydt' via sage-devel]

Hi,

I'm the maintainer of a few Debian packages, for which sage is 
considered upstream:

   rubiks
   sagemath-database-mutually-combinatorial-designs
   sagemath-database-conway-polynomials
   sagemath-database-elliptic-curves
   sagemath-database-graphs
   sagemath-database-polytopes

To detect when a new upstream is available, Debian uses a helper, which 
analyses homepages/download pages to see which versions are available 
(uscan).


For those sage-is-upstream packages, I was pointing the helper to
http://files.sagemath.org/spkg/upstream/
but now it looks like those are not available anymore on the 
sagemath.org server.


I could point to mirrors, like say:
http://www-ftp.lip6.fr/pub/math/sagemath/spkg/upstream/
but I think it would be better to have a real upstream link.

Let me insist : the links are used to check for new versions, by either 
developers working on the package, or by the Debian servers to update 
status page ; downloading the sources of a new version is done by hand 
(well, triggered by hand -- using the helper script in download mode), 
by developers : users of the Debian packages then get the sources from 
Debian mirrors. It shouldn't overload the main servers.


Can you point me to a correct place?

Thanks,

Snark on #debian-science

--
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: What in Sage uses Boost ? And who maintains it ?

['Julien Puydt' via sage-devel]

Polybori is now brial if I remember well.

Snark on? #sagemathLe 11 nov. 2015 15:21, Simon King  
a écrit :
>
> Hi! 
>
> On 2015-11-11, 'Martin Albrecht' via sage-devel  
> wrote: 
> >> 1) What in Sage uses Boost ? 
> > 
> > I know this one: PolyBoRi. 
> >  
> >> 2) Is someone maintaining it ? 
>
> Wasn't there some discussion to remove PolyBoRi? 
>
> Cheers, 
> Simon 
>
> -- 
> 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@googlegroups.com. 
> Visit this group at http://groups.google.com/group/sage-devel. 
> For more options, visit https://groups.google.com/d/optout. 

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] which computation is right?

['Julien Puydt' via sage-devel]

Hi,

Le 20/10/2015 22:28, Sarfo a écrit :

could anyone please tell me which computation evaluated in the attached
file is right?
Thank you.


All of them?

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

['Julien Puydt' via sage-devel]

Le 16/10/2015 11:20, Samuel Lelievre a écrit :


2015-10-12 22:45:08 UTC+2, Snark:

Le lundi 12 oct. 2015 à 13:02:38 (-0700), Volker Braun a écrit :
 > 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 ;-)
 >

We are uncomfortable with packaging sage-the-distribution's libgap
in Debian,
because as the name doesn't say it's sage-specific, we might be in
some trouble
if GAP were to release a real-GAP libgap (even in some years...
Debian is about
long-term).

So if that lib could get upstream's blessing (or just get renamed
libsagegap),
that would make things easier.


See a discussion of that point on the gap development list at

https://mail.gap-system.org/pipermail/gap/2015-October/000176.html


Thanks!

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

['Julien Puydt' via sage-devel]

Le lundi 12 oct. 2015 à 13:50:04 (+0100), Alexander Konovalov a écrit :
> we are happy to announce the First Joint GAP-​Sage Days which 
> will take place in St Andrews on January 18th-22nd, 2016. They 
> will be preceded by a GAP Coding Sprint on January 13th-16th.
> 
> For the 1st Joint GAP-Sage Days, the focus of the workshop will 
> be on improving GAP-SageMath integration and interaction between 
> our systems and between their developers. The focus of the GAP 
> Coding Sprint will be on converging GAP and HPC-GAP development 
> branches.

Does that mean that the libgap in sagemath will get part of upstream GAP?

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

['Julien Puydt' via sage-devel]

Le lundi 12 oct. 2015 à 13:02:38 (-0700), Volker Braun a écrit :
> 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 ;-)
> 

We are uncomfortable with packaging sage-the-distribution's libgap in Debian,
because as the name doesn't say it's sage-specific, we might be in some trouble
if GAP were to release a real-GAP libgap (even in some years... Debian is about
long-term).

So if that lib could get upstream's blessing (or just get renamed libsagegap),
that would make things easier.

Cheers,

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Fwd: Re: nauty in Sage

['Julien Puydt' via sage-devel]

Hi,

Le vendredi 09 oct. 2015 ą 07:30:06 (-0700), Dima Pasechnik a écrit :
> On Thursday, 8 October 2015 11:46:34 UTC-7, Jeroen Demeyer wrote:
> >
> > On 2015-10-08 20:22, Dima Pasechnik wrote: 
> > > if it talks about changes, this means changes are allowed, no? 
> > Well, in principle I agree, but it's safer not to assume anything. 
> >
> 
> Brendan replied that remaining two clauses in the license fall under Sect. 
> 7 of  GPL v3.
> 
> Indeed the latter does allow extra clauses to be added, no?
> 

Hmmm... will he publish a full version with this copyright notice? Because
if he does, then distributions could start packaging it.

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Fwd: Re: nauty in Sage

['Julien Puydt' via sage-devel]

Le vendredi 09 oct. 2015 à 09:43:31 (-0700), Dima Pasechnik a écrit :
>
> On Friday, 9 October 2015 09:26:48 UTC-7, Nathann Cohen wrote:
> >
> > > we talk about nauty being included into Sage - the permission is being 
> > given 
> > > for this, and only this, AFAIU... 
> >
> > I don't think that " + must only be used in Sage" is 
> > GPL-compatible. 
> >
> 
> As long we we do not write this in... 
> I suppose I should make it clear for Brendan that someone will be able to 
> create a Sage fork consisting of nauty 
> under essentially GPL.

William had a point when he said : stick to a known license, don't try
to invent your own.

The author might actually be interested by BSD-3-clause, in fact.

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Nauty vs SageMath speed comparisons?

[Julien Puydt]

Hi,

Le mardi 06 oct. 2015 à 16:28:57 (-0700), Dima Pasechnik a écrit :
> 
> On Tuesday, 6 October 2015 06:18:43 UTC-7, Jeroen Demeyer wrote:
> >
> > On 2015-10-06 15:15, kcrisman wrote: 
> > > Wasn't there some email relatively recently where the author of nauty 
> > > said it was actually okay to use in Sage 
> >
> > Yes, there was. However his statement was very vague, it was not clear 
> > what he really meant. I don't think that anybody ever asked for further 
> > clarification. 
> >
> 
> Where was that? Well, we might ask for details, why not? It currently says:
> 
> Permission is hereby given for use and/or distribution with the exception 
> of sale for profit or application with nontrivial military significance. 
> You must not remove this copyright notice, and you must document any 
> changes that you make to this program. This software is subject to this 
> copyright only, irrespective of any copyright attached to any package of 
> which this is a part. 
> 

This is indeed the nauty license I know about, and this is definitely
completely GPL-incompatible so can't go into anything (sage, Debian, etc).

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Julien Puydt]

Le dimanche 04 oct. 2015 à 13:31:19 (-0700), Simon King a écrit :
> 
> OK. But what should happen, if I replace it with $(INST)/$(MEATAE) ? 
> Shouldn't it fail with an error? Well, it didn't (which was a bug, IMHO), 
> at least on a branch that was not very old. Hopefully the latest develop 
> works better.
> 

If MEATAE isn't defined, you add a depend on $(INST)/, which does exist, so
it's an always-satisfied dep and not an error, isn't it?

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] William Stein - CEO, SageMath, Inc. http://sagemath.com

[Julien Puydt]

Hi,

On 12/08/2015 19:55, Nathann Cohen wrote:

Hello William,

I cannot say that I like your new signature the slightest bit [1].

I feel like the work to software I contribute is being stolen by
somebody who wants to make money off it. I feel like its name has been
stolen too. Sagemath is clearly a free software for mathematics, and
Sagecloud can pass for being something something different.

But when sagemath.com is a website that sells Sage Cloud, we have a problem.

Regards,

Nathann

[1] https://groups.google.com/d/msg/sage-cloud/31raOrutcog/DkKI2wGKCAAJ



as long as sagemathcloud is free (as in freedom) software, I see no 
reason to complain... or can you point to a place where the license 
hasn't been followed ?


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Automatically test Maple, Magma [...] when running the tests

[Julien Puydt]

Hi,

Le 17/07/2015 12:59, Dima Pasechnik a écrit :


On Friday, 17 July 2015 11:40:04 UTC+1, Snark wrote:

Hi,

Le 16/07/2015 13:16, Jeroen Demeyer a écrit :
  On 2015-07-16 13:03, Nathann Cohen wrote:
  What is somebody has such an
  install and *wants* to use it with Sage?
  This points to the core problem: we simply have no way to guess
whether
  people want to do that or not.
 
  Here is a possible compromise proposal:
  * keep default optional package as they are now
  * add a new flag --optional=external (or change --optional=all to do
  this) to test all auto-detected-but-not-part-of-Sage packages like
  mathematica.
  * add a corresponding Makefile target running tests with this flag.
 

Here is another idea : don't put the interface to the external package
in sage-the-library, but in an optional package.


this presently means that such packages become upstream w.r.t. Sage.
An extra burden to maintain etc...


I'm not sure I understand how it can be an extra burden, and I have no 
clue about the caetera...


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Automatically test Maple, Magma [...] when running the tests

[Julien Puydt]

Hi,

Le 16/07/2015 13:16, Jeroen Demeyer a écrit :

On 2015-07-16 13:03, Nathann Cohen wrote:

What is somebody has such an
install and *wants* to use it with Sage?

This points to the core problem: we simply have no way to guess whether
people want to do that or not.

Here is a possible compromise proposal:
* keep default optional package as they are now
* add a new flag --optional=external (or change --optional=all to do
this) to test all auto-detected-but-not-part-of-Sage packages like
mathematica.
* add a corresponding Makefile target running tests with this flag.



Here is another idea : don't put the interface to the external package 
in sage-the-library, but in an optional package.


That way, doctests are only run for people who care. That, and it would 
be possible to have an optional package for foo17 and another for 
foo21... hence supporting incompatible versions.


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Build system changes in 6.8.beta7

[Julien Puydt]

Hi,

Le vendredi 03 juil. 2015 à 16:51:19 (+0100), Nathann Cohen a écrit :
  but this is not interactive and no confirmation is requested.  Should it?
 
 My understanding is that you do not need to in this situation: the
 user explicitly asked to install a non-GPL-compatible software, so he
 is assumed to know what he is doing.

Sure, the user specifically asked to install a piece of software ; but
did (s)he know it was non-GPL-compatible? Unless there's non-free or some such
in the package name, that isn't clear.

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: About the planarity package

[Julien Puydt]

Le 23/06/2015 12:40, Jeroen Demeyer a écrit :

On 2015-06-23 09:44, Julien Puydt wrote:

But after some digging around :
- the tarball isn't pristine, it's heavily patched ;

It's not heavily patched, just the build system was changed.


*just* !


- one has to wonder why the remaining patches aren't in the tarball
already...

Are you serious? You would surely complain even more if this was the case.


I'm not serious, I'm sarcastic : what's the point of putting aside a few 
patches in a clean way if the upstream tarball is a mess already?


You might name that trolling, I name it calling out lousy practices.

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: About the planarity package

[Julien Puydt]

Hi,

Le 22/06/2015 17:25, Nathann Cohen a écrit :


I was heartily congratulating about having small reasonable patches to
upstream, and you tell me that they're in fact against an heavily patched
upstream, and upstream's licensing situation is muddy... no need to troll
when the facts are so preposterous already.


Depends how you see it. If you want to see it like it's bad, then it's
bad. All I can say is that I spent several week-ends and nights (no
joke) over this problem (learning autotools and stuff), and that as a
result we can hope that Sage's archive will be a copy of upstream in
the long run. As a byproduct, upstream will have been improved too.


I have nothing against improving upstream : indeed, I do that myself on 
a regular basis. It's good that you lent a hand there.


What I'm railing against is that this is a package where I obtained on 
the one hand a nice upstream/planarity-2.2.0.tar.bz2 and on the other 
end I have a very clean build/pkgs/planarity/ directory with simple 
patches : wonderful!


But after some digging around :
- the tarball isn't pristine, it's heavily patched ;
- those modifications aren't documented ;
- one has to wonder why the remaining patches aren't in the tarball 
already...

- it has license issues.


I'll just wait until the dust settles before packaging that piece of code...


Precisely. And there should not be much work left to do then.


Well, according to your explanations, the ball is already rolling, so 
there isn't that much to do anyway, is there?


If I had found a pristine upstream and a sage packaging with big 
preliminary patches marked help, I wouldn't have complained : I would 
have helped.


I'm not very active on the sagemath side because my spare time is 
already busy enough doing packaging work on the Debian side.


I can't make a Debian package where what I claim are the upstream 
sources isn't pristine, except if I provide a script and explanation 
detailing how I did and why I felt the need to do so. In that case the 
tarball isn't foo_3.14.tar.gz, it's foo_3.14+dfsg2.57.tar.gz -- never 
lie! It's rare to do so, and it generally means there are licensing 
redistribution issues behind.


I can't make a Debian package where I didn't check files for copyright 
notices and licensing quirks : part of the packaging is writing a 
copyright file which will get triple-checked before the package can 
enter. Yes, I have had package proposals failed for a single file where 
I didn't do a thorough enough job.


Making a Debian package is hard. Should I complain? No : this strictness 
is the reason why Debian can have something like 22000 source packages 
and 45000 binary packages and still cope. Better take a few more 
days/weeks to get something which will last months/years than just take 
anything and collapse within hours.


I'm not just slacking off and critisizing... I'm just busy elsewhere!

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: About the planarity package

[Julien Puydt]

Le 22/06/2015 16:24, Nathann Cohen a écrit :

How did a package in such a messy state become standard !?


If you honestly want to find out and it's not just trolling, here is all I know:

commit 7197d452d277ac0e186776e60176ade03ab952ec
Author: Nomail Name devnull@localhost
Date:   Mon Feb 4 14:49:02 2008 -0800

 planarity graph O(n) thank you boyer

Nathann


I was heartily congratulating about having small reasonable patches to 
upstream, and you tell me that they're in fact against an heavily 
patched upstream, and upstream's licensing situation is muddy... no need 
to troll when the facts are so preposterous already.


I'll just wait until the dust settles before packaging that piece of code...

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] About the planarity package

[Julien Puydt]

Hi,

I was pondering packaging the planarity package in debian, but :

- where is the upstream repository ? [the SPKG.txt only gives the 
author's name]


- the patches look nice : were they sent upstream ?

Thanks,

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: About the planarity package

[Julien Puydt]

Hi,

Le 22/06/2015 13:53, Nathann Cohen a écrit :

Hell,

- where is the upstream repository ? [the SPKG.txt only gives the
author's name]


https://code.google.com/p/planarity/

- the patches look nice : were they sent upstream ?


There is a long litterature about this package on #18187 [1], and even
more on private emails that were exchanged with the package's author.
There are two main problems:

1) upstream does not have an autotoolized build system (though the one
we wrote in Sage's archive of 'planarity' could be used)
2) upstream's license is... Well, incorrect (it claims to be New-BSD,
but ships 'Nauty' code which are not New-BSD-compatible)

The author is aware of those, and promised to split the source code into
two part to settle the license problem. We agreed together that he would
then use our autotoolized build system in his repository, and then we
should only have to reduce Sage's package to a trivial copy of upstream.

Nathann

[1] http://trac.sagemath.org/ticket/18187


How did a package in such a messy state become standard !?

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Packaging rant

[Julien Puydt]

Hi,

Le 12/06/2015 11:18, Jeroen Demeyer a écrit :

On 2015-06-11 10:31, Julien Puydt wrote:

Open software is about cooperation.

Of course. The question is: what should we do if upstream does not want
to cooperate? I don't want to call names in this thread, but I have
proposed patches to many upstream projects which are part of Sage
(usually they are small bugfixes). The chances of actually getting a
patch accepted by upstream are unfortunately much smaller than I would
wish.

Some people think that Sage should only add patches to upstream packages
if they are accepted by upstream. This is frustrating, because it really
slows down Sage development.


Nothing will slow development down like dozens of forked packages to 
maintain, especially if upstreams consider you hostile.


There's a joke around here which one could translate as The fastest and 
shortest way down is off the cliff -- I prefer hiking!


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Packaging rant

[Julien Puydt]

Hi,

Le 11/06/2015 10:28, Jeroen Demeyer a écrit :

On 2015-06-11 03:40, François Bissey wrote:

* fork upstream and keep it as a separate package but
no one really wants to be the maintainer.


If it's decided that we are allowed to fork polybori, can this be
applied to other packages too?

I have often been frustrated in Sage by people complaining that we
should stay as close to upstream as possible, that we shouldn't patch
packages in Sage, that we should stick to release (non-development)
versions of packages in Sage.

Most recently for example in #18450 I was forced to rewrite part of a
patch because upstream Cython didn't want to accept a patch (I still
think that my patch was reasonable and I don't understand why upstream
doesn't like it).

And every time I make a change to PARI, I feel resistance because we're
moving further away from the released PARI version.

So I hope that you understand my frustration if other people can do with
polybori what they want but I constantly hit walls because I am not
allowed to patch other packages.

Really, I wish we could just give up on this whole packaging Sage for
distributions effort.


I can hardly disagree more.

That basically means that instead of working on sagemath, sage devs will 
end up working on keeping hundreds of more or less nonsensical forks, 
with hundreds of hostile upstreams.


Open software is about cooperation.

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Is there an online index of the standard packages shipped in Sage?

[Julien Puydt]

Hi,

Le 12/05/2015 17:19, Thierry a écrit :

On Tue, May 12, 2015 at 07:19:07AM -0700, Volker Braun wrote:

IMHO:

* The package type (standard/optional/experimental) should be in a file
inside the package directory


+1. Actually, i have a prototype of this for the purpose of checking to
the upstream website if a newerver version is out (i did it mainly for
openssl, but it now covers most packages), and get some other information
by browsing the source code (e.g. which are installed, how many patches,
...).


Is your prototype to check for latest versions of upstream as good as 
uscan ? [ see https://wiki.debian.org/debian/watch ]


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.6 -- bdist?

[Julien Puydt]

Le Sat, 18 Apr 2015 16:17:53 -0700 (PDT),
Volker Braun vbraun.n...@gmail.com a écrit :

 Its a quad-core ARMv7 Cortex-A9 with 4gb ram iirc. (Calxeda)


That's much more powerful than what I have here, and it shouldn't take
that long to build sage 6.6 : the chromebook I (try to) use has an
exynos 5 and 2Go of RAM and  think building sage 6.5 takes something
like 6h and then the bdist must take 1h to build (I'm not sure about
the exact duractions, but at least the orders are right).

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

[Julien Puydt]

Le Sat, 18 Apr 2015 11:20:59 +0200,
Nathann Cohen nathann.co...@gmail.com a écrit :

 Hello,
 
  We somehow have to come to a conclusion.
 +1
 
  Never change positive_review_tickets (and adapt developer guide,
  see #18228)
 -1
 
  Cool-off period
 +0.5
  Freezing tickets once release manager starts merging them
  (various variants proposed:
  - post a comment
 +1
  - change status to closed
 +1
  - some new status)
 +0 (I don't see how to add a new 'status' in trac)
 
 I don't mind implementing the trigger if somebody can tell me where it
 is to be written.
 
 Nathann
 


May I notice that :
(1) the ticket is in stage needs_review or positive_review ;
(2) what is actually reviewed is a precise commit in a git branch ;
(3) nothing forces the ticket and the branch to be synchronized.


so you might discuss things as much as you want, decide whatever you
want : it's going to be a pain as long as the above three points stand!

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] [ARM] sage 6.6 -- bdist?

[Julien Puydt]

Hi,

will a bdist of sage 6.6 for ARM be available using a buildbot, or
shall I compile one myself ?

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.6 -- bdist?

[Julien Puydt]

Le Fri, 17 Apr 2015 04:52:10 -0700 (PDT),
Volker Braun vbraun.n...@gmail.com a écrit :

 Still building!
 
 On Friday, April 17, 2015 at 4:06:38 AM UTC-4, Snark wrote:
 
  Hi, 
 
  will a bdist of sage 6.6 for ARM be available using a buildbot, or 
  shall I compile one myself ? 
 
  Snark on #sagemath 
 

That's good news : my chromebook is almost unusable, so I'm glad it
won't need to stay up long for sage! [For the record : wifi is mostly
broken in the stable, beta and devel channel, with nice reboots -- and
last time I tried the devel channel for a would-be fix, the french
keyboard was broken...]

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: pynac-0.3.3

[Julien Puydt]

Le Thu, 09 Apr 2015 18:38:24 +0200,
Vincent Delecroix 20100.delecr...@gmail.com a écrit :

 Hello,
 
 I found
 
 sage: abs(sqrt(x))
 sqrt(abs(x))
 
 much better than
 
 (%i1) abs(sqrt(x));
 (%o1)   sqrt(x)
 
 We discussed in #15605 that variables in the symbolic ring should be 
 thougt as complex variables (if not specified otherwise). The maxima 
 version is wrong when x is real negative.
 
 What is the answer to
 
 sage: sqrt(abs(x)**2) == abs(x)
 sage: abs(x**2)
 sage: (-1)^(2/3)   # see ticket 15605


I can't help but notice that under the convention that sqrt is a
function from non-negative reals to non-negative reals, what maxima
does makes perfect sense.

Snark on #sagemath

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: On MacDonald polynomials and pickling

[Julien Puydt]

Hi,

Le 23/03/2015 19:22, Volker Braun a écrit :

The pickle jar is about old pickles, to test that they can be unpickled. So
the pickles were created with an old version of Sage. Its odd that we lost
the ability to pickle them over time.


Hmmm... so the pickling problem I'm trying to debug is about :

(1) a failing doctest which passes within sage, but nobody knows exactly 
what fixed it (trac ticket #5038) ;


(2) the deserialization of an object where only the unpickling is tested 
-- the obtained object might be worth nothing ;


(3) regenerating the serialization is broken, but nobody knows exactly 
since when and why.


Should I file a ticket ?

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] On MacDonald polynomials and pickling

[Julien Puydt]

Hi,

I'm still trying to track why calling unpickle_all twice leads to a 
SIGABRT crash with our experimental debian package.


After some toying around, it turned out that within the whole pickle 
jar, only the files related to MacDonald polynomials are giving issues.


That is why I'm trying to experiment on them (within a vanilla sage), 
but I'm hitting a small problem : I don't even manage to dump them as 
pickle!


Indeed, the following :

import pickle

t = QQ['t'].gen()
obj = SymmetricFunctions(QQ['t'].fraction_field()).macdonald(q=t,t=1) 


with open('/tmp/mcdopols.sobj','w') as fich:
pickle.dump(fich, obj)

only triggers:
AttributeError: 'Macdonald' object has no attribute 'write'


So I'm wondering how they were put into the pickle jar ?

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: libgap pickling

[Julien Puydt]

Le 15/03/2015 21:16, Simon King a écrit :

Hi Vincent,

On 2015-03-15, Vincent Delecroix 20100.delecr...@gmail.com wrote:

But in that very particular case, just evaluating the string
representation in GAP gives you back the same group


Yes, in *that* very particular case. So, it is not possible to make a
*general* pickling method for GAP-related objects. String representation
sometimes works, sometimes doesn't. Of course, if you implement
something where the pickling-by-representation happens to work, then you
can exploit it.


If pickling gap objects is so fragile, and works only by luck, accident 
or both, perhaps a doctest should be added to any code which expects it 
to work -- to check that a later gap upgrade still satisfies this 
welcome coincidence ?


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: White-haired needs_review tickets

[Julien Puydt]

Le 14/03/2015 16:32, Ralf Stephan a écrit :

On Wednesday, March 11, 2015 at 5:44:53 PM UTC+1, Snark wrote:


What should be really done with long-waiting needs_review tickets ?


See them as a database of ideas, similar to 5-year old requests for
enhancement.


Tickets are a database of ideas. A needs_review ticket is something 
which requires some action on a short time scale. So a several months 
(or worse, years) old ticket is ok, but a needs_review one not quite so.



Honestly, those are not the problem, but rather the failure to push
necessary but painful changes like the declare_var/function command,
presumably because of... changing all the books, again!


I don't know what this declare_var/function command is about. Could you 
expand (or give a link), please?


Thanks,

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] White-haired needs_review tickets

[Julien Puydt]

Hi,

I was thinking it would be interesting to have a look at the tickets 
needing review, so I browsed the list... and saw one of them was waiting 
since about three years (sic). I put it to needs_info because obviously 
everything in it is so clearly outdated. But then there are also many 
who are waiting since hundred of days...


I was pondering moving them en-masse to needs_info, but that's obviously 
neither a very helpful nor tactful way to handle things, so I prefer 
discussing the matter here.


What should be really done with long-waiting needs_review tickets ? 
Where should the time limit be between It's just taking long and It's 
outdated ?


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] White-haired needs_review tickets

[Julien Puydt]

Le 11/03/2015 17:53, William Stein a écrit :

   1. Setup/write an editorial notification system to encourage the
reviewing of tickets, similar to how every journal on the planet has
an automated system for ensuring papers get reviewed, seeing the
status of outstanding papers, etc.   Maybe we could even just use an
existing journal review system


What is the difference between what you describe and a bug tracking system ?

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] About sys_path_security.patch in the python spkg

[Julien Puydt]

Le 09/03/2015 16:51, Jeroen Demeyer a écrit :

On 2015-03-09 16:47, Julien Puydt wrote:

I was wondering about the sys_path_security.patch patch in the python
spkg:
(1) where is it coming from?

http://trac.sagemath.org/ticket/13579


(2) why what it does isn't made in src/sage/doctest/control.py, where
the test_safe_directory function looks like the ideal place for this ?

Because the check has nothing to do with doctesting, it is much more
general than that.


(3) has it been forwarded upstream?

Yes, see
* http://bugs.python.org/issue16202
* https://github.com/ipython/ipython/issues/7044



Thanks! That's a complete answer which shouldn't go to waste : ticket 
#17923 is up for review.


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Looking at sage compiling

[Julien Puydt]

Le 09/03/2015 11:23, Jeroen Demeyer a écrit :

On 2015-03-09 11:04, Julien Puydt wrote:

(2) ... which brings me to the second remark : install.log ends by
telling me the doc will be built... but it's still compiling sage
itself! So a whole chunk of the compilation happens without a log : is
it normal?

If that's true, it's a bug. However, in order to reproduce, we would
need to know what you did before and during the make.

http://trac.sagemath.org/ticket/17794 fixed one such bug, are you
compiling a version with that applied?


I'm on the develop branch, 6.6.beta3.

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] About sys_path_security.patch in the python spkg

[Julien Puydt]

Hi,

I was wondering about the sys_path_security.patch patch in the python spkg:
(1) where is it coming from?
(2) why what it does isn't made in src/sage/doctest/control.py, where 
the test_safe_directory function looks like the ideal place for this ?

(3) has it been forwarded upstream?

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Looking at sage compiling

[Julien Puydt]

Hi,

I'm bored, looking at sage compiling once again... and notice two things :

(1) there is a good amount of warnings flying by (well, flying might 
not be very accurate... the box is slow) ; I guess most of them are 
harmless and might be due to cython spitting out innocent code, but 
still, it would be nice to check...


(2) ... which brings me to the second remark : install.log ends by 
telling me the doc will be built... but it's still compiling sage 
itself! So a whole chunk of the compilation happens without a log : is 
it normal?


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] [Debian] Strange crash in ECL

[Julien Puydt]

Le 26/02/2015 10:08, Francois Bissey a écrit :

So I think we can say there is something going with gmp 6.0.0.
I think that should narrow things down considerably.


I'll report our findings to upstream -- that should definitely interest 
them, and help pinpoint the issue.


Thanks!

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] [Debian] Strange crash in ECL

[Julien Puydt]

Le 26/02/2015 10:15, Julien Puydt a écrit :

Le 26/02/2015 10:08, Francois Bissey a écrit :

So I think we can say there is something going with gmp 6.0.0.
I think that should narrow things down considerably.


I'll report our findings to upstream -- that should definitely interest
them, and help pinpoint the issue.


I set ECL_OPT_SET_GMP_MEMORY_FUNCTIONS to 0 in src/c/main.d, and that 
made the crash disappear!


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] [Debian] Strange crash in ECL

[Julien Puydt]

Le 26/02/2015 09:05, Francois Bissey a écrit :

Ok what version of gmp? 5.1.3 here.


I have 6.0.0.

Snark

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [Debian] Strange crash in ECL

[Julien Puydt]

Le 25/02/2015 17:20, Nils Bruin a écrit :

On Wednesday, February 25, 2015 at 1:56:39 AM UTC-8, Snark wrote:


Hi,

it is a strange problem I have : using either debian's ecl or upstream's
the following code :

(ext:set-limit 'ext:heap-size 0)
(setq a (expt 10 (expt 10 5)))
(setq b (expt a 600))

gives a crash (SIGABRT) Duplicate large block deallocation.



That is not an out-of-memory error from ecl.

 but trac's ticket #6722 is about spellchecking some modules...


Googling ecl memory site:trac.sagemath.org tells me this likely should be

   http://trac.sagemath.org/ticket/6772



Ah, very good, but that discusses the addition of the:
(ext:set-limit 'ext:heap-size 0)

and doctest... it doesn't say anything about a SIGABRT. :-/

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] [Debian] Strange crash in ECL

[Julien Puydt]

Hi,

Le 25/02/2015 10:56, Julien Puydt a écrit :

it is a strange problem I have : using either debian's ecl or upstream's
the following code :

(ext:set-limit 'ext:heap-size 0)
(setq a (expt 10 (expt 10 5)))
(setq b (expt a 600))

gives a crash (SIGABRT) Duplicate large block deallocation.

Where things get interesting, is that I get this code from sage, where
it actually works! What is annoying is that the last line comes from
this test (src/sage/interfaces/maxima.py, around line 570) :

 Test that we can use more than 256MB RAM (see trac :trac:`6722`)::

 sage: a = maxima(10)^(10^5)
 sage: b = a^600  # long time -- about 10-15
seconds


but trac's ticket #6722 is about spellchecking some modules... so I
guess there used to be a problem like the one I have, but I don't know
what was done to fix it.

Does someone remember ?


Upstream acknowledged it is a bug, still present in the devel version. 
I'll try to help them pinpoint and fix the problem -- if someone here 
has a clue why it works in sage, I'm sure they would appreciate the 
information.


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] [Debian] Strange crash in ECL

[Julien Puydt]

Le 25/02/2015 22:43, François Bissey a écrit :


That's fun, on Gentoo my ecl from the system just chew it without crashing.
What options are you using to build ecl I currently have
--enable-unicode -with-x and the rest turned off. Would it be thread
related by any chance?


Sage is using mpir and doesn't have the problem.
Debian is using gmp and does have the problem.

What are you using?

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] [Debian] Strange crash in ECL

[Julien Puydt]

Salut,

Le 25/02/2015 23:00, Jean-Pierre Flori a écrit :

Not really related but it seems ECL saw an update!


Their homepage says 15.2.21, but the dowload page is always 13.5.1.

As I mentioned, upstream confirmed the bug, including for their latest 
and greatest.


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] [Debian] Strange crash in ECL

[Julien Puydt]

Le 26/02/2015 08:20, Francois Bissey a écrit :

On 26/02/2015, at 20:12, Julien Puydt julien.pu...@laposte.net wrote:

Le 25/02/2015 22:43, François Bissey a écrit :


That's fun, on Gentoo my ecl from the system just chew it without crashing.
What options are you using to build ecl I currently have
--enable-unicode -with-x and the rest turned off. Would it be thread
related by any chance?


Sage is using mpir and doesn't have the problem.
Debian is using gmp and does have the problem.

What are you using?


Oh, gmp just as you do. Using mpir is hard on sage-on-distro as
you would know.


Snif. The gmp vs mpir difference was my favored explanation after I 
ruled out :

- disable-threads for ecl
- enable-large-config for Boehm's gc

Debian and upstream-on-debian have the crash. I don't know what the 
upstream developer was using when he reproduced it.


Gentoo doesn't have the crash, and I had a report ubuntu didn't either.

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] [Debian] Strange crash in ECL

[Julien Puydt]

Hi,

it is a strange problem I have : using either debian's ecl or upstream's 
the following code :


(ext:set-limit 'ext:heap-size 0)
(setq a (expt 10 (expt 10 5)))
(setq b (expt a 600))

gives a crash (SIGABRT) Duplicate large block deallocation.

Where things get interesting, is that I get this code from sage, where 
it actually works! What is annoying is that the last line comes from 
this test (src/sage/interfaces/maxima.py, around line 570) :


Test that we can use more than 256MB RAM (see trac :trac:`6722`)::

sage: a = maxima(10)^(10^5)
sage: b = a^600  # long time -- about 10-15 seconds


but trac's ticket #6722 is about spellchecking some modules... so I 
guess there used to be a problem like the one I have, but I don't know 
what was done to fix it.


Does someone remember ?

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.5

[Julien Puydt]

Hi,

Le 21/02/2015 17:25, Volker Braun a écrit :

The atlas build script just aborts with SAGE_ATLAS_ARCH=base, nothing else
to see here.


I compiled sage-6.5 with my usual setup, then tried:
export SAGE_FAT_BINARY=yes
./sage -f atlas

and the compilation with :
Traceback (most recent call last):
  File ./spkg-install, line 510, in module
rc = build()
  File ./spkg-install, line 448, in build
rc = configure(arch, isa_ext)
  File ./spkg-install, line 256, in configure
arch, isa_ext, thread_limit = configure_base()
  File ./spkg-install, line 396, in configure_base
raise NotImplementedError('I don\'t know a base configuration for 
your cpu.')

NotImplementedError: I don't know a base configuration for your cpu.

I think something should be done in the configure_base function -- but 
since I haven't found how from configuration import conf works, I 
don't know exactly how to make that work.



Pointing to a specific location for the atlas library isn't going to be
much use in a binary that we distribute.


As pointed out by J.-P. Flori, ARM is a generic name for a whole 
processor family, so providing something which works everywhere isn't 
easy... or even possible.


Still, we can perhaps shoot for something better.

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.5

[Julien Puydt]

Le 23/02/2015 15:05, Julien Puydt a écrit :

Le 23/02/2015 14:27, Julien Puydt a écrit :

That will take some time though : this box isn't fast. And I work on it
while it plays with sage.


In fact, when an arch is given, it does compile ad nauseum so it doesn't 
take that much time.



The box is currently toying with the following patch :

diff --git a/build/pkgs/atlas/spkg-install b/build/pkgs/atlas/spkg-install
index 2d2972e..b5c2808 100755
--- a/build/pkgs/atlas/spkg-install
+++ b/build/pkgs/atlas/spkg-install
@@ -392,6 +392,12 @@ def configure_base():
  elif conf['IA64?']:
  print('Base configuration on Itanium.')
  arch = 'IA64Itan'
+elif conf['ARM?']:
+print('Base configuration on ARM.')
+if conf['processor'] == 'armv7l':
+arch = 'ARMv7'
+else:
+arch = 'ARMv6'
  else:
  raise NotImplementedError('I don\'t know a base
configuration for your cpu.')
  return (arch, isa_ext, thread_limit)


Does it look good?


What about that one :
diff --git a/build/pkgs/atlas/spkg-install b/build/pkgs/atlas/spkg-install
index 2d2972e..7733f65 100755
--- a/build/pkgs/atlas/spkg-install
+++ b/build/pkgs/atlas/spkg-install
@@ -392,6 +392,13 @@ def configure_base():
 elif conf['IA64?']:
 print('Base configuration on Itanium.')
 arch = 'IA64Itan'
+elif conf['ARM?']:
+if conf['processor'] == 'armv7l':
+print('Base configuration on ARMv7.')
+arch = 'ARMv7'
+else:
+print('Base configuration on ARMv6.')
+arch = 'ARMv6'
 else:
 raise NotImplementedError('I don\'t know a base 
configuration for your cpu.')

 return (arch, isa_ext, thread_limit)


?

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.5

[Julien Puydt]

Hi,

Le 23/02/2015 12:13, Volker Braun a écrit :

In spkg-install you need to add a suitable branch in configure_base():


Yes, but my question was : how do I know how to write that branch? I 
didn't manage to get from configuration import conf to work, so I 
couldn't look at 'conf' to know what values I have in there on my ARM box.


Now I have found the time do dig around, and found configuration.py just 
right there in build/pkgs/atlas/, so I think I'll be able to do 
something :-P


That will take some time though : this box isn't fast. And I work on it 
while it plays with sage.


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.5

[Julien Puydt]

Le 23/02/2015 15:34, Volker Braun a écrit :

The base configuration is supposed to be a fixed one. If you want to tune
for your respective cpu then we can do that already.


What do we fix to, then armv7 or armv6 ?

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.5

[Julien Puydt]

Le 23/02/2015 15:33, Dima Pasechnik a écrit :


hmm, shouldn't there also be a distinction between hardware and software
floats?
(Although I believe ARM chips you want to run Sage on all have hardware
floats - but the question is how the OS is configured).


There is already code in spkg-install to force hf on ARM -- I didn't 
touch that.


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.5

[Julien Puydt]

Le 23/02/2015 14:27, Julien Puydt a écrit :

Hi,

Le 23/02/2015 12:13, Volker Braun a écrit :

In spkg-install you need to add a suitable branch in configure_base():


Yes, but my question was : how do I know how to write that branch? I
didn't manage to get from configuration import conf to work, so I
couldn't look at 'conf' to know what values I have in there on my ARM box.

Now I have found the time do dig around, and found configuration.py just
right there in build/pkgs/atlas/, so I think I'll be able to do
something :-P

That will take some time though : this box isn't fast. And I work on it
while it plays with sage.



The box is currently toying with the following patch :

diff --git a/build/pkgs/atlas/spkg-install b/build/pkgs/atlas/spkg-install
index 2d2972e..b5c2808 100755
--- a/build/pkgs/atlas/spkg-install
+++ b/build/pkgs/atlas/spkg-install
@@ -392,6 +392,12 @@ def configure_base():
 elif conf['IA64?']:
 print('Base configuration on Itanium.')
 arch = 'IA64Itan'
+elif conf['ARM?']:
+print('Base configuration on ARM.')
+if conf['processor'] == 'armv7l':
+arch = 'ARMv7'
+else:
+arch = 'ARMv6'
 else:
 raise NotImplementedError('I don\'t know a base 
configuration for your cpu.')

 return (arch, isa_ext, thread_limit)


Does it look good?

We should have the time to discuss before the compilation finishes...

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.5

[Julien Puydt]

Le 23/02/2015 15:40, Jean-Pierre Flori a écrit :


I agree with Volker, just put one thing here.
I would say: arch='ARMv6' for base (and arch=ARMv7 for fast if you want
to enable a fast configuration).
It would also be good to put ISA= (don't remember the var name or syntax)
to explicitely disable isa extensions for the base configuration.
I would have to think more to remember what to put for the fast
configuration.


For the base, isa_ext is set to none at the start of the config_base 
function.


I'm now trying on my armv7l box with the ARMv6 arch :
diff --git a/build/pkgs/atlas/spkg-install b/build/pkgs/atlas/spkg-install
index 2d2972e..f201c42 100755
--- a/build/pkgs/atlas/spkg-install
+++ b/build/pkgs/atlas/spkg-install
@@ -392,6 +392,9 @@ def configure_base():
 elif conf['IA64?']:
 print('Base configuration on Itanium.')
 arch = 'IA64Itan'
+elif conf['ARM?']:
+print('Base configuration on ARM.')
+arch = 'ARMv6'
 else:
 raise NotImplementedError('I don\'t know a base 
configuration for your cpu.')

 return (arch, isa_ext, thread_limit)


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.5

[Julien Puydt]

Le 23/02/2015 15:48, Julien Puydt a écrit :

Le 23/02/2015 15:40, Jean-Pierre Flori a écrit :


I agree with Volker, just put one thing here.
I would say: arch='ARMv6' for base (and arch=ARMv7 for fast if you want
to enable a fast configuration).
It would also be good to put ISA= (don't remember the var name or
syntax)
to explicitely disable isa extensions for the base configuration.
I would have to think more to remember what to put for the fast
configuration.


For the base, isa_ext is set to none at the start of the config_base
function.

I'm now trying on my armv7l box with the ARMv6 arch :
diff --git a/build/pkgs/atlas/spkg-install b/build/pkgs/atlas/spkg-install
index 2d2972e..f201c42 100755
--- a/build/pkgs/atlas/spkg-install
+++ b/build/pkgs/atlas/spkg-install
@@ -392,6 +392,9 @@ def configure_base():
  elif conf['IA64?']:
  print('Base configuration on Itanium.')
  arch = 'IA64Itan'
+elif conf['ARM?']:
+print('Base configuration on ARM.')
+arch = 'ARMv6'
  else:
  raise NotImplementedError('I don\'t know a base
configuration for your cpu.')
  return (arch, isa_ext, thread_limit)



If I put something similar in configure_fast, will I be able to test it 
looks good using :

export SAGE_ATLAS_ARCH=fast
./sage -f atlas

?

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.5

[Julien Puydt]

Le 23/02/2015 16:25, Volker Braun a écrit :

Yes, exactly!

On Monday, February 23, 2015 at 4:16:40 PM UTC+1, Snark wrote:


If I put something similar in configure_fast, will I be able to test it
looks good using :
export SAGE_ATLAS_ARCH=fast
./sage -f atlas




It's ticket #17843. And this time it looks like I managed to attach a 
branch without naming it help (or anything inappropriate).


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] [debian] Strange numerical errors in sage's libpari code

[Julien Puydt]

Hi,

Le 18/02/2015 13:53, Julien Puydt a écrit :

I'm having strange numerical behaviour with my experimental sage using
debian packages, with two failing doctests in the src/sage/libs/pari/
directory (both in gen.pyx) :

Failed example:
 (s*z)^5
Expected:
 2.00 - 1.08420217248550 E-19*I
Got:
 2.00 + 0.E-19*I

Failed example:
 e.ellztopoint(1+i)
Expected:
 [0.E-19 - 1.02152286795670*I, -0.149072813701096 -
0.149072813701096*I]
Got:
 [0.E-18 - 1.02152286795670*I, -0.149072813701096 -
0.149072813701096*I]


If those are indeed more numerical noise than serious issues, how can 
one relax the doctests so they don't fail at each pari upgrade, but 
still detect big problems ?


I don't think a simple # tol 1e-15 will do the trick here, will it ?

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] GP/PARI hangs with sage-6.4.1/6.5 on Ubuntu 14.04.2 LTS

[Julien Puydt]

Hi,

Le 22/02/2015 20:34, Franco Saliola a écrit :

Hello sage-devel,

I sent the following email to sage-release, but I think it really belongs
here. I'm looking for ideas on how to debug (or better, how to fix) the
problems with GP/PARI interface that are causing sage to hang.



The symptoms look like what one gets if gprc.expect isn't found : gp and 
pexpect don't agree, so sometimes pexpect stays stuck because it doesn't 
get what it wanted. The recently closed #17796 makes sage more resilient 
to that.


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

[Julien Puydt]

Le 21/02/2015 11:15, Volker Braun a écrit :

I agree that we should have some user configuration mechanism to customize
how we build packages (including replacing sage packages with distro
dependencies), but going about it by patching Sage or adding $DISTRO
subdirectories everywhere are crap. Something like yaml config files (e.g.
hashdist) is imho the way to go.


Felix Salfelder did a GSOC about using a configure script.

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.5

[Julien Puydt]

Le 21/02/2015 14:56, Volker Braun a écrit :

We have an ARM buildbot but it doesn't work: atlas install fails when
SAGE_FAT_BINARY=yes is set. If you have an idea about suitable defaults
then we could make it automatic *hint*



Is there a trac ticket or some such on the matter, with some kind of log 
I could have a look at ?


I generally build my bdist with SAGE_ATLAS_LIB set to /usr/lib -- or 
else just atlas takes something a full day (I can't remember exactly).


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] [ARM] sage 6.5

[Julien Puydt]

Hi,

is there an ARM build box which will take care of preparing a bdist 
which I'll just have to unpack, or shall I build such a bdist as usual ?


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

[Julien Puydt]

Hi,

Le 20/02/2015 01:22, William Stein a écrit :

On Thu, Feb 19, 2015 at 12:51 PM, Francesco Biscani
bluesca...@gmail.com wrote:

On 19 February 2015 at 18:05, Julien Puydt julien.pu...@laposte.net wrote:


All distributions have thousands of packages, and deps are not a big
issue. Sage-the-distribution has about a hundred, and it's a big issue.



This is something I have failed to understand so far. What is it that makes
Sage require such special handling of dependencies (i.e., package everything
in one monolithic blob and with ad-hoc patching)?


See http://wiki.sagemath.org/faq/bigsagerant for another past Sage
release manager's rant on this topic from long ago (maybe 2008?).

== Wouldn't it be way better if Sage did not ship as a gigantic bundle? ==

This has been discussed over and over again and it plainly doesn't
work. The Sage in Debian does not pass doctests, not even close. In
general the combinatorial explosion of configurations to debug is way
too large and it is next to impossible to find any distribution where
the version numbers even remotely match. We updated to GAP 4.4.12 in
Sage 3.3 and the doctests involving GAP will in certain files be
broken with any previous GAP release. If you used the Debian packages
for Singular Sage won't work since we patch NTL and when those NTL
libs come in conflict either Sage doesn't compile or Singular blows
up. I can go on and on and on about similar issues and that is only
the stuff I know about right on top of my head. I have never taken the
time to go out and do dumb things to break Sage :)

In the near future we plan to upgrade to a svn release of the
development version of pari and then closely track it as bugs we
report are often only fixed in pari-2.4.3svn. There is *no* way any
distribution can track this without potentially breaking other code
dependent on pari and you will be royally screwed if you want to use
pari 2.3.4 in Sage (the stable release at this point) since Sage won't
even build. We will fix all in tree code that gets broken with the new
pari-svn and push it back upstream, but until that shows up in a
distribution we will long have shipped Sage 4.0.

The way we do it is the only way and I have doubts that any
distribution packaged Sage will even be able to keep up with the
official release given that I (=Michael Abshoff) spend working full
time as the Sage
release manager :)


Yes, the same drama as usual :

- sage is incredibly complex
   = FACTS: all distributions are orders of magnitude more complex

- sage has extremely special needs because it's mathematics
   = FACTS: all software has special needs, and being about 
mathematics doesn't make it worse -- just put unit tests, we'll run them 
after the build and no package failing them will get out the door (eclib 
and flint come to mind as example of good-behaving mathematics software 
packages)


- sage is on the bleeding edge
   = FACTS: there are quite a few packages where sage can barely keep 
up with upstream -- see 
https://people.debian.org/~thansen/debian-sage-dev-status.html


- sage needs to be able to use dev versions
   = FACTS: you can, and please do! But :
  (1) label them clearly as not upstream versions, and make sure you 
stay compatible with upstream dev versions so the next upstream stable 
will be a drop-in replacement to your stuff (pari)
  (2) if you (plan to) stay away from upstream long, then actually fork 
upstream with a clear name so we can package in a co-installable form 
(libgap and cddlib)


- debian's sage sucks
   = FACTS: it did, and now there is none. When there will be, no 
package won't get out of the door if it doesn't pass doctests. Of 
course, some of them will be disabled, like those checking paths, or 
checking that the available color maps in matplotlib is some short list, 
but that shouldn't matter.



There's a lot of complex software around with long dependency chains
(Firefox, Chrome, KDE, GNOME, OpenOffice, ...) and it seems like most Linux
distributions are able to deal with this, without too many issues, via
system-wide libraries.


Those are a different domain of software engineering.  Mathematics
software is fundamentally different than word processing, graphical
desktop, and web browser software.   It doesn't matter much if a line
in a UI is off by one pixel.  In mathematics, being off by 1 can
result in major bugs all over Sage.


Off by one can be a crash in word processing, graphical desktop, web 
browser software and pretty much anything else : it does matter 
everywhere. Packagers routinely run make check in their build scripts 
so they don't ship clearly broken software.



The Sage distribution model, which has frequently been attacked every
single year for nearly a decade, is one of the most important reasons
for Sage's success.


Is it a good reason to push third-party packagers around like 
second-class citizens? Let me quote François Bissey :

But some of us would like to be given some consideration.


That said

Re: [sage-devel] Re: Sage trac : can't stay logged in

[Julien Puydt]

Le 19/02/2015 17:20, Julien Puydt a écrit :

Le 19/02/2015 16:30, Volker Braun a écrit :

worked for me...


Sigh... still doesn't... so there's a problem on my end :-(


Cleared everything I could, checked I didn't block anything, the logged 
in, refreshed, still logged in, tried to add myself to Authors, trac 
says I don't have the permission and indeed I'm logged off.


Tried to do the same in a private navigation window... same symptoms.

Forced my navigator to use https -- it complains a lot, but now it works.

Snark

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

[Julien Puydt]

Le 19/02/2015 18:54, Michael Orlitzky a écrit :

This presupposes that the status quo is not madness. My sage builds work
for about two weeks before some invisible dependency update breaks them.
There's a line in sage beyond which we just don't care about
dependencies. We ship gcc, some utilities, and a bunch of math software.
But we don't ship e.g. glibc. Guess what happens when I rebuild glibc on
my machine? Sage breaks. What happens if I rebuild gd on my machine?
Sage breaks. What happens if I rebuild dvipng on my machine? Sage breaks.


As much as I despise sage-the-distribution for getting in my way and 
taking way too much disk space on my poor box (a chromebook has 16Gb... 
that's for chromeOS+ubuntu+sage), I have to defend it here : if you 
recompile something which isn't API+ABI compatible with what it 
replaces, it's quite normal that it breaks things, and sage certainly 
isn't the only one you break when you do something like this! Especially 
if it's the libc...


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

[Julien Puydt]

Le 19/02/2015 10:19, Jeroen Demeyer a écrit :

On 2015-02-19 08:31, Marc Mezzarobba wrote:

On a perhaps related note, Sage used to be about building the car,
didn't it?

I would say it still is about building the car. I think this refers to
using dependencies where possible. Instead of writing our own functions
to compute in number fields, we wrap PARI's number field functionality.

What you do is to take only certain parts of the Sage car, change the
bodywork and then complain that the wheels no longer fit.


I find it ironic how hard sage makes it for other projects
to rely on it

You seem to think that Sage is actively making it hard for other
projects. I simply think that the way how Sage development is done is
fundamentally incompatible with what the distros want.


Well, examples exist where poor choices have been made which make(made) 
it harder for other projects.


From the top of my head :
(1) ECL was configured to disable SIGCHLD... by patching it! I proposed 
a two-line patch which did it programmatically from sage's code.
(2) PARI/GP is configured using a gprc... shipped by the spkg -- ticket 
#17796 is about pushing that in sage's code.


So yes, the impression is there that given the choice between doing 
things in sage-the-software and working for everyone and doing things in 
sage-the-distribution and breaking for everyone else, some sage 
developers have a tendency to choose the later.



I think this sentence from Volker is completely on the spot:

-1 to delaying a Sage version for $DISTRO to catch up.


I don't think software was ever delayed for debian.

The point is about doing things cleanly, which open the door to 
everyone, instead of favoring sage-the-distribution.


Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Sage trac : can't stay logged in

[Julien Puydt]

Hi,

I'm having a hard time setting #17796 back to needs_review after I 
followed Jeroen's remarks : I keep getting disconnected!


Whenever I click on login, it refreshes and I'm in. And afterwards, 
whenever it refreshes, I'm off again... that includes refreshing because 
I ask to modify the ticket :-/


I tried from a chrome on chromeOS, a chrome on ubuntu and a chrome on 
android... and it's all I have in reach for now.


Is it just me ?

Snark on #sagemath

--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.