Re: [sage-combinat-devel] Re: Sage-combinat Days in Paris
On Sun, Mar 17, 2013 at 02:48:27AM -0700, tom d wrote: Is there a sense of whether the meeting will be in Paris or Orsay yet? Just a quick update for now: it will be in Orsay. I'll send later this week more detailed information, and in particular how to reserve rooms. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Queue on 5.8 -- (mostly) good news
Hi! There is only one patch that needs to be rebased in order to apply to 5.8. trac_12876_category-fix_abstract_class-nt-rel11521.patch needs to be rebased over #14254. It looks like this is just be a matter of making a one-line change to the context. (And importing #14254 and its dependencies into the queue.) No rush as far as I am concerned, but I figured since 5.8 has been released, it was worth reporting this. cheers, Hugh -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
On Sun, Mar 17, 2013 at 9:28 AM, Julien Puydt julien.pu...@laposte.net wrote: Le 17/03/2013 15:22, leif a écrit : than...@debian.org wrote: Am Samstag, 16. März 2013 20:57:13 UTC+1 schrieb leif: But if we switch to git, improve Sage's package management (as a first step, split vanilla upstream sources off the spkgs :P ), ... Is splitting the vanilla upstream sources off planned? That would be very helpful for distributions. Another helpful thing would be a clear distinction between fixes/adjustment to the library and Sage glue, because we need all the Sage glue, but want to decide ourselves which other patches to apply. We discussed this many times, and hopefully due to switching to git this will finally happen, because the src/ (upstream) dirs in spkgs aren't tracked, should always be vanilla (modulo fixing weird file permissions in a few cases), and hence do not change the often many times we bump an spkg's patch level (making just small changes to the Sage part which is under our revision control, including patches to upstream). Here is what is used when managing a debian package with git, to store upstream sources in a branch and get a unpatched (pristine) source tarball when needed : http://joeyh.name/code/pristine-tar/ when a new upstream gets out, a script makes it easy to update the upstream source by just pointing to the new tarball: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html As has been mentioned, we're hoping to move to something like that at the workshop later this month as we've greatly outgrown the home-grown solution that currently exists. As is, any one-character change to an spkg's spkg-install script, say, means you have to again download the whole compressed archive (often 12 MB+) just to check the changes or reinstall the package. Although we have an upgrade path (untarred sage source dist accessible via http or rsync) in addition to the source distribution tarball, the former still just contains the compressed, self-contained spkgs. (Even worse, sometimes unmodified spkgs get repackaged from release to release such that not just their file modifications times but also their md5sums differ, for no real reason.) I.e., you currently cannot simply pull changes to (Sage's part of) spkgs. A branch for upstream, a branch for packaging, and scripts which make it easy to work with both ; see for example: Another thing are patch headers. Sometimes I can't find out what a patch in a spkg does, for example I found patches that just move a few lines of code somewhere else. I can't apply a patch when I don't know what it does. In Debian we have this specification for patch headers to document what they do: http://dep.debian.net/deps/dep3/ Well, every spkg contains an SPKG.txt file with a changelog and -- hopefully -- a Patches section (if appropriate), which in a perfect world precisely documents what's done why (including what patches are applied for what reason, whether they come from or went upstream etc.). Each patch should be its own documentation -- even if it's just to say Look in SPKG.txt, silly!. It's extremely silly. SPKG.txt and manually creating/applying/checking in patches is basically a poor man's revision control, with all the data on an external website, and some critical pieces not in revision control at all (e.g. what packages and versions are in a specific release of Sage). (Each entry of the changelog should also contain a Sage trac ticket number -- unfortunately sometimes more or less just this, which means further reading.) There's usually also a Special Update/Build Instructions section, which for example states patch foo can and should be removed once we upgrade to upstream version x.y, or check whether patch foo is still required. Unfortunately the distinction between generic fixes to upstream and Sage-specific modifications isn't always that clear; a single patch may even include both. In addition, there's the Mercurial history (but the repo is again only in the spkg itself), although few people provide detailed commit messages. This is perhaps suboptimal, but similar to the patches to the Sage library (see below), which hardly ever contain details, but just the corresponding trac ticket numbers in their commit messages. I'd be happy if Sage in whole was more modular / less monolithic; I'm not very optimistic regarding the Sage /library/ though. What do you mean with the Sage /library/? The Sage library is contained in a sage-x.y.z spkg, has its own repo (one can pull from for official/final releases, hg.sagemath.org), and contains the heart of Sage, i.e., genuine Sage code, as opposed to upstream components. In a Sage installation, it lives in $SAGE_ROOT/devel/sage/ (meant to get [cloned and] modified by pretty ordinary users as well; every Sage user is [also] a Sage developer). H... there is no .hg in $SAGE_ROOT/devel/sage/, but
[sage-devel] Sage 5.8 released
Sage 5.8 was released on 15 March 2013. It is available in source and binary form from: * http://www.sagemath.org/download.html Sage (http://www.sagemath.org/) is developed by volunteers and combines over 90 open source packages. For instructions about installing Sage, see * http://www.sagemath.org/doc/installation The following page lists the platforms on which Sage should work: * http://wiki.sagemath.org/SupportedPlatforms If you have any questions and/or problems, please report them to any of these Google groups: * sage-support: http://groups.google.com/group/sage-support * sage-devel: http://groups.google.com/group/sage-devel You can also drop by in #sagemath on freenode or post your questions at http://ask.sagemath.org/ The following 76 people contributed to this release. Of those, 10 made their first contribution to Sage: - Alejandro Morales [first contribution] - Alexander Dreyer - Aly Deines - Andrew Mathas - André Apitzsch - Anne Schilling - Ben Hutz - Ben Salisbury [first contribution] - Benjamin Jones - Chris Berg - Christian Nassau - Christian Stump - Dan Orr [first contribution] - Darij Grinberg - David Coudert - David Harvey - David Joyner - David Loeffler - David Roe - Dmitrii Pasechnik - Emily Gunawan [first contribution] - Eric Rowland [first contribution] - Florent Hivert - Francis Clarke - Franco Saliola - François Bissey - Frithjof Schulze - Frédéric Chapoton - Gregg Musiker - Ivan Andrus - Jason Bandlow - Javier López Peña - Jean-Pierre Flori - Jeroen Demeyer - John Palmieri - John Perry - Julian Rueth - Kannappan Sampath - Karl-Dieter Crisman - Kevin Halasz - Kwankyu Lee - Leif Leonhardy - Lucas David-Roesler [first contribution] - Luis Felipe Tabera Alonso - Mario Pernici - Mark Shimozono - Martin Albrecht - Michael Orlitzky - Michelle Manes [first contribution] - Miguel Marco - Mike Hansen - Mike Zabrocki - Mitesh Patel - Nathann Cohen - Nicholas Kirchner [first contribution] - Nicolas M. Thiéry - Niles Johnson - Nils Bruin - Paul Zimmermann - Paul-Olivier Dehaye - Punarbasu Purkayastha - R. Andrew Ohana - Robert Miller - Salvatore Stella [first contribution] - Samuel Lelièvre - Sara Billey [first contribution] - Simon King - Simon Spicer - Stepan Starosta - Sébastien Labbé - Timo Kluck - Travis Scrimshaw - Vincent Delecroix - Volker Braun - Wai Yan Pong - William Stein * Release manager: Jeroen Demeyer. * We closed 144 tickets in this release. For details, see http://boxen.math.washington.edu/home/release/sage-5.8/tickets.html Closed tickets: #2694: Hecke algebra basis not implemented [Reviewed by Travis Scrimshaw] #3426: bessel_K function is broken [Reviewed by Karl-Dieter Crisman, Benjamin Jones] #4230: implement arbitrary precision Bessel Y function [Reviewed by Karl-Dieter Crisman, Benjamin Jones] #12349: linbox fails to builds in sage-5.0_beta1 [Reviewed by François Bissey] #13603: .DS_Store garbage in rpy2-2.0.8.p0 [Reviewed by Karl-Dieter Crisman] #14074: saving fill in eps doesn't work right for some reason [Reviewed by Punarbasu Purkayastha] #4294: sage -t under %pdb [Reviewed by David Roe] #7493: Implement sage -t --time [Reviewed by Jeroen Demeyer] #9224: Unify sage-test and sage-ptest [Reviewed by David Roe] #9449: The summary printed after running doctests is inaccurate. [Reviewed by Jeroen Demeyer] #10760: Improve coverage test for gsl/interpolation.pyx [Reviewed by Kannappan Sampath] #12024: 90% doctest coverage thrust metaticket [Reviewed by Travis Scrimshaw] #13383: Fix missing documentation of sage/rings/real_lazy in doc/en/reference/rings_numerical.rst [Reviewed by Volker Braun] #13652: Error in pari when dealing with algebraic numbers [Reviewed by Jeroen Demeyer] #14113: affine root system ambient lattice issue [Reviewed by Nicolas M. Thiéry] #12357: Make groupoids garbage collectable [Reviewed by Simon King, Jean-Pierre Flori] #13904: Better deletion of items of TripleDict [Reviewed by Simon King, Jean-Pierre Flori] #11525: file name conflict in SageTeX using sage.tex [Reviewed by Ivan Andrus, Karl-Dieter Crisman] #12253: SVD segfaults on complex matrices [Reviewed by Luis Felipe Tabera Alonso] #12686: Add sage.rings.finite_rings to the reference manual [Reviewed by Travis Scrimshaw] #9194: Expose and extend the thematic tutorial on symmetric functions [Reviewed by Jason Bandlow, Anne Schilling, Mike Zabrocki, Nicolas M. Thiéry] #13296: unicode default encoding is not utf-8 in command line [Reviewed by John Palmieri] #13991: Mitigate speed regressions in symmetric function related code due to #12313 [Reviewed by Simon King] #14201: During upgrade to sage 5.7 ppl is using gmpxx headers from the system [Reviewed by Wai Yan Pong, Volker Braun] Merged in sage-5.8.beta0: #6495: Mitesh Patel, John Palmieri, Florent Hivert: Build the reference manual incrementally [Reviewed by Volker
Re: [sage-devel] Intel MKL
On Sun, 17 Mar 2013 10:35:47 Volker Braun wrote: Well it is registered under my name so I'm not going to post the keys to the mailing list ;-) But as far as I understand it, the MKL binaries can be distributed. I haven't had time yet to really look and see what the non-distributable part is (partly because my laptop died). OK that would have been interesting I can theoretically build sage-on-gentoo against MKL but do not have a license or know anyone with a license to check. I don't know if MKL will work properly in lmona.de but the answer is probably yes. If you have no ticket for that work I guess we'll have to dump stuff on this thread for a while. Francois -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Problems building docs on sage-5.8.beta4
On 03/17/2013 02:48 PM, Stephen Montgomery-Smith wrote: On 03/09/2013 06:40 PM, Montgomery-Smith, Stephen wrote: Building on FreeBSD, the doc creation process freezes at some point I have done more investigation. The following patch fixes the problem, so it is definitely a problem to do with multithreading. Anyway, so that I can get sage-5.8 in the FreeBSD port, I will include this patch. I provide it for your information only, as I don't think any other OS will need it. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out. --- sage-5.8.rc0/doc/common/builder.py-orig 2013-03-17 20:50:38.0 + +++ sage-5.9.beta0/doc/common/builder.py 2013-03-17 20:56:42.0 + @@ -272,13 +272,16 @@ # build the other documents in parallel from multiprocessing import Pool -pool = Pool(NUM_THREADS, maxtasksperchild=1) +# pool = Pool(NUM_THREADS, maxtasksperchild=1) L = [(doc, name, kwds) + args for doc in others] -# map_async handles KeyboardInterrupt correctly. Plain map and -# apply_async does not, so don't use it. -pool.map_async(build_other_doc, L, 1).get(9) -pool.close() -pool.join() +# Pool doesn't work properly in FreeBSD. Instead: +for iii in L: +build_other_doc(iii) +# # map_async handles KeyboardInterrupt correctly. Plain map and +# # apply_async does not, so don't use it. +# pool.map_async(build_other_doc, L, 1).get(9) +# pool.close() +# pool.join() logger.warning(Elapsed time: %.1f seconds.%(time.time()-start)) logger.warning(Done building the documentation!) @@ -464,12 +467,15 @@ continue output_dir = self._output_dir(format, lang) from multiprocessing import Pool -pool = Pool(NUM_THREADS, maxtasksperchild=1) +# pool = Pool(NUM_THREADS, maxtasksperchild=1) L = [(doc, lang, format, kwds) + args for doc in self.get_all_documents(refdir)] -# (See comment in AllBuilder._wrapper about using map instead of apply.) -pool.map_async(build_ref_doc, L, 1).get(9) -pool.close() -pool.join() +# Pool doesn't work properly in FreeBSD. Instead: +for iii in L: +build_ref_doc(iii) +# # (See comment in AllBuilder._wrapper about using map instead of apply.) +# pool.map_async(build_ref_doc, L, 1).get(9) +# pool.close() +# pool.join() # The html refman must be build at the end to ensure correct # merging of indexes and inventories. # Sphinx is run here in the current process (not in a
[sage-devel] Re: Intel MKL
On 3/18/13 5:18 PM, François Bissey wrote: On Sun, 17 Mar 2013 10:35:47 Volker Braun wrote: Well it is registered under my name so I'm not going to post the keys to the mailing list ;-) But as far as I understand it, the MKL binaries can be distributed. I haven't had time yet to really look and see what the non-distributable part is (partly because my laptop died). OK that would have been interesting I can theoretically build sage-on-gentoo against MKL but do not have a license or know anyone with a license to check. I don't know if MKL will work properly in lmona.de but the answer is probably yes. If you have no ticket for that work I guess we'll have to dump stuff on this thread for a while. A while ago they posted on the numpy list telling people that Intel was offering MKL licenses to them because they were an open-source scientific Python project: http://numpy-discussion.10968.n7.nabble.com/MKL-licenses-for-core-scientific-Python-projects-td32530.html Is this MKL license through the same sort of program? Jason -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Problems building docs on sage-5.8.beta4
On Mar 18, 9:43 pm, Stephen Montgomery-Smith step...@missouri.edu wrote: On 03/17/2013 02:48 PM, Stephen Montgomery-Smith wrote: On 03/09/2013 06:40 PM, Montgomery-Smith, Stephen wrote: Building on FreeBSD, the doc creation process freezes at some point I have done more investigation. The following patch fixes the problem, so it is definitely a problem to do with multithreading. Anyway, so that I can get sage-5.8 in the FreeBSD port, I will include this patch. I provide it for your information only, as I don't think any other OS will need it. spkg-patch-sage_-_doc_common_builder.py 2KViewDownload Well, but should we incorporate it as well? -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Intel MKL
Yes, thats it. On Monday, March 18, 2013 10:26:55 PM UTC-4, jason wrote: A while ago they posted on the numpy list telling people that Intel was offering MKL licenses to them because they were an open-source scientific Python project: http://numpy-discussion.10968.n7.nabble.com/MKL-licenses-for-core-scientific-Python-projects-td32530.html Is this MKL license through the same sort of program? -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Problems building docs on sage-5.8.beta4
On Monday, March 18, 2013 6:43:03 PM UTC-7, Stephen Montgomery-Smith wrote: On 03/17/2013 02:48 PM, Stephen Montgomery-Smith wrote: On 03/09/2013 06:40 PM, Montgomery-Smith, Stephen wrote: Building on FreeBSD, the doc creation process freezes at some point I have done more investigation. The following patch fixes the problem, so it is definitely a problem to do with multithreading. Anyway, so that I can get sage-5.8 in the FreeBSD port, I will include this patch. I provide it for your information only, as I don't think any other OS will need it. Should we include this patch with a suitable block if using FreeBSD: use your version else: use multithreading Is there any good way of testing whether multithreading is broken, instead of just testing whether it's FreeBSD? -- John -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
