Re: [sage-combinat-devel] queue broken?
Ok,thanks! Just today there was another broken spot in the queue. (I upgraded to 5.8rc0 just in case, too.) I was wanting to rebase my affine permutations patch for the new documentation system so that it can finally get a review, and it was under the broken patch, so I just made the fixes and pushed... hope that's ok. applying trac_12876_category-fix_abstract_class-nt-rel11521.patch patching file sage/categories/homset.py Hunk #6 FAILED at 261 1 out of 11 hunks FAILED -- saving rejects to file sage/categories/homset.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_12876_category-fix_abstract_class-nt-rel11521.patch Abort On Saturday, March 16, 2013 12:57:22 AM UTC+3, Anne Schilling wrote: Hi Tom, Yes, I got the same error with sage-5.8.bet4. I rebased Ben Salisbury's patch. It should work now. Ben, please pull from the sage-combinat server before you keep working on your patch! Best, Anne On 3/15/13 2:51 PM, tom d wrote: From tonight's attempt to apply the queue in Sage 5.7rc0: applying trac_4327-root_system_plot_refactor-nt.patch patching file sage/combinat/root_system/type_affine.py Hunk #1 succeeded at 237 with fuzz 2 (offset -54 lines). applying trac_14143-alcove-path-al.patch applying trac_14192-infinity_crystal-bs.patch patching file sage/combinat/crystals/all.py Hunk #1 FAILED at 11 1 out of 1 hunks FAILED -- saving rejects to file sage/combinat/crystals/all.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_14192-infinity_crystal-bs.patch This persists after trying to qselect guards and recloning the combinat branch. Is this happening for others or do I need to suck it up and move on to true 5.7? -- 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] Reviewer for #12940?
I think Ticket #12940 is probably ready for review, at long last, if anyone can find a bit of time to look it over. It's a combinatorial implementation of the affine Weyl groups of types A,B,C,D and G. http://trac.sagemath.org/sage_trac/ticket/12940 cheers! -- 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-devel] Re: GSoC project: make the Sage build system more distribution friendly
Le 17/03/2013 00:36, than...@debian.org a écrit : 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. Let me add that there is also no clear distinction between tests which check the code does correct calculations and tests which check things are installed in some place and not in another ; see for example: http://trac.sagemath.org/sage_trac/ticket/12627 having such tests spread here and there makes fractioning sage in distribution packages more painful than should be. The current situation is the following: - an spkg, call him 'helper', provides an executable 'do_something'. - any other spkg, call them 'user1', ... 'userN' use 'do_something', but call it with a full path, to be sure it really runs the one from the helper spkg. That means that if one tries to use a system 'helper' package, one gets a breakage in many other places. A better situation would be the following: upon installation, the 'helper' spkg runs 'which do_something' in 'sage -sh', and checks that the correct path is returned (the one where it installed the executable). Then the 'user' spkg can just run 'do_something' and be confident that it will something appropriate will be done. 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/ Indeed, and notice in particular the 'Forwarded' field: by default, a debian patch has been forwarded upstream. The impression I have is that by default, a patch in an spkg has not. Snark on #debian-science and #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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Intel MKL
On 17/03/13 10:43, Volker Braun wrote: Just FYI, I received an Linux/OSX Intel MKL license (its closed-source BLAS) for the Sage project . As I've written earlier, I'm planning to make Sage more vendor-agnostic so we don't have ATLAS hardcoded everywhere. Cool. Is it only for you personally or can we get a generic one for sage development? Do you have a ticket for the ATLAS independence stuff? Or do you want to discuss it here. I greped the log of sage-on-gentoo and I officially declared sage-on-gentoo could use any BLAS in Gentoo on Friday 16th of July 2010: commit 44c5b767c3fe2af0b372a798d94f9021932bf6a8 Author: FranC3A7ois Bissey f.r.bis...@massey.ac.nz Date: Fri Jul 16 23:00:43 2010 +1200 Sage is independent of ATLAS and can be built against other BLAS. So if you work on that I have a deep interest in getting my sage-on-gentoo fixes go away and be replaced by something generic upstream. 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] Re: GSoC project: make the Sage build system more distribution friendly
On 17/03/13 21:38, Julien Puydt wrote: Le 17/03/2013 00:36, than...@debian.org a écrit : 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. Let me add that there is also no clear distinction between tests which check the code does correct calculations and tests which check things are installed in some place and not in another ; see for example: http://trac.sagemath.org/sage_trac/ticket/12627 having such tests spread here and there makes fractioning sage in distribution packages more painful than should be. Fortunately the instances of tests for that are not as many as you make it sound. There are indeed the issues of trac 12627. Actually in the case of Singular there is the added issue that sage install a singular file and calls it when upstream only ships Singular-3-1-5. In this case that make the sage call a bit more version independent. But there are doctests that indeed specify a path or part of a path that is sage specific, local/share/pari in sage/interfaces/gp.py and local/share/maxima in doc/en/constructions/plotting.rst are the only examples I can see. Other test are for precise version number when other versions works just as well (R, pari version is also tested but you should follow sage closely there). 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] Re: GSoC project: make the Sage build system more distribution friendly
On 2013-03-17 09:38, Julien Puydt wrote: The impression I have is that by default, a patch in an spkg has not. It really should be. It doesn't mean that upstream will *accept* the patch of course. Or sometimes, Sage contains patches to spkgs which are just meant for the Sage - package interface which would not make sense in the upstream tree. -- 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] A problem with exceptions in cached functions
Hellooo everybody !
I was writing a (very short) patch to expose a feature from GAP (#14291),
and the ony thing keeping it from passing all tests seems to be the caching
mechanism. My method is meant to catch TypeError exceptions, but they still
walk through my try/except.
Here's the behaviour of the method when I keep the @cached_method line :
sage: S3 = groups.permutation.Symmetric(3)
sage: S3.orbit([1,2], ontuples = True)
---
TypeError Traceback (most recent call last)
ipython-input-2-be05e9183676 in module()
1 S3.orbit([Integer(1),Integer(2)], ontuples = True)
/home/ncohen/.Sage/local/lib/python2.7/site-packages/sage/misc/cachefunc.so
in sage.misc.cachefunc.CachedMethodCaller.__call__
(sage/misc/cachefunc.c:7197)()
TypeError: unhashable type: 'list'
sage:
And when I remove it :
sage: S3 = groups.permutation.Symmetric(3)
sage: S3.orbit([1,2], ontuples = True)
[[1, 2], [2, 3], [2, 1], [3, 1], [1, 3], [3, 2]]
I also have to add that the behaviour is different when the code is written
in an external file. The following code loaded from a b.py file does not do
anything wrong :
def test(n):
d = {}
try:
return d[[1,2,3]]
except (KeyError, TypeError):
return Yeahh
@cached_function
def teste(n):
d = {}
try:
return d[[1,2,3]]
except (KeyError,TypeError):
return Yeahh
sage: teste(5)
'Yeahh'
sage: test(5)
'Yeahh'
Would anybody here know what's happening ?
Thnks for your help !!
Nathann
--
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: A problem with exceptions in cached functions
Hi Nathann, On 2013-03-17, Nathann Cohen nathann.co...@gmail.com wrote: TypeError: unhashable type: 'list' ... Would anybody here know what's happening ? The error message tells it: Lists (as opposed to tuples) can not be used as keys of a dictionary (are unhashable), because they are mutable. The values computed by a cached_function are stored in a dictionary (unless it is a cached method that takes no arguments apart from self). The arguments passed to the function are normalised (that's to say, there is no difference between passing an argument by position or by argument name) and then used as key for the dictionary. One *could* think of transforming lists into tuples while normalising the arguments. But if that isn't done (and I don't know if it should be done), use hashable arguments, or wrap it into a function that does the list-tuple transformation for you. Best regards, 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: A problem with exceptions in cached functions
HellO !!! The error message tells it: Lists (as opposed to tuples) can not be used as keys of a dictionary (are unhashable), because they are mutable. The values computed by a cached_function are stored in a dictionary (unless it is a cached method that takes no arguments apart from self). The arguments passed to the function are normalised (that's to say, there is no difference between passing an argument by position or by argument name) and then used as key for the dictionary. One *could* think of transforming lists into tuples while normalising the arguments. But if that isn't done (and I don't know if it should be done), use hashable arguments, or wrap it into a function that does the list-tuple transformation for you. It actually took me some time to understand that the exception I saw was not the one raised by my own code ^^; I do not think that it would be a good idea to reencode lists as tuples either, it would probably yield incorrect results eventually.. Would it make sense to you if there was a more meaningful warning when this problem arises ? Something like ValueError : the caching mechanism obviously cannot handle non-hashable input ? And I see no clean way out for my patch :-/ Nathann -- 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] Re: A problem with exceptions in cached functions
Well, the function only takes tuples as input right now. But I have no way to give a meaningful error message if the user feeds it with any other non-hashable iterable :-/ Nathann -- 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: GSoC project: make the Sage build system more distribution friendly
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). 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. 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 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). (There are also the Sage scripts, Sage root, and extcode spkgs / repositories; the former two less interesting to a typical user.) What I meant is that it's IMHO unlikely you'll one day be able to pick only the parts you want / need from it; there are optional Sage *spkgs* (interfacing with the Sage library), but everything else which is shipped in the huge Sage spkg is closely tied together, i.e., not really modular (although it perhaps could be [more] -- there's e.g. also Purple Sage -- purple.sagemath.org). -leif P.S.: IIRC, it took ages to get the obsolete (and broken) Sage 3.0.x package out of Debian's / Ubuntu's package repositories... ;-) -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- 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: GSoC project: make the Sage build system more distribution friendly
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 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!. (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 there is one in $SAGE_ROOT/, another in $SAGE_ROOT/local/bin/, another in $SAGE_ROOT/devel/sage-main/ and a fourth in $SAGE_ROOT/devel/ext-main/... [looking at a freshly compiled sage 5.7 on my ARM box] (There are also the Sage scripts, Sage root, and extcode spkgs / repositories; the former two less interesting to a typical user.) What I meant is that it's IMHO unlikely you'll one day be able to pick only the parts you want / need from it; there are optional Sage *spkgs* (interfacing with the Sage library), but everything else which is shipped in the huge Sage spkg is closely tied together,
Re: [sage-devel] Re: A problem with exceptions in cached functions
On Sunday, March 17, 2013 9:07:41 AM UTC-4, Nathann Cohen wrote: But I have no way to give a meaningful error message if the user feeds it with any other non-hashable iterable :-/ On the contrary, the error message that you get right now is 100% spot on. -- 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] Intel MKL
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). On Sunday, March 17, 2013 4:41:54 AM UTC-4, François wrote: On 17/03/13 10:43, Volker Braun wrote: Just FYI, I received an Linux/OSX Intel MKL license (its closed-source BLAS) for the Sage project . As I've written earlier, I'm planning to make Sage more vendor-agnostic so we don't have ATLAS hardcoded everywhere. Cool. Is it only for you personally or can we get a generic one for sage development? Do you have a ticket for the ATLAS independence stuff? Or do you want to discuss it here. I greped the log of sage-on-gentoo and I officially declared sage-on-gentoo could use any BLAS in Gentoo on Friday 16th of July 2010: commit 44c5b767c3fe2af0b372a798d94f9021932bf6a8 Author: FranC3A7ois Bissey f.r.b...@massey.ac.nz javascript: Date: Fri Jul 16 23:00:43 2010 +1200 Sage is independent of ATLAS and can be built against other BLAS. So if you work on that I have a deep interest in getting my sage-on-gentoo fixes go away and be replaced by something generic upstream. 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.
[sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
Julien Puydt wrote: H... there is no .hg in $SAGE_ROOT/devel/sage/, but there is one in $SAGE_ROOT/, another in $SAGE_ROOT/local/bin/, another in $SAGE_ROOT/devel/sage-main/ and a fourth in $SAGE_ROOT/devel/ext-main/... [looking at a freshly compiled sage 5.7 on my ARM box] :-) devel/sage is a symbolic link to devel/sage-main (unless you switched the branch, then it points to devel/sage-branch). -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- 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/09/2013 06:40 PM, Montgomery-Smith, Stephen wrote: Building on FreeBSD, the doc creation process freezes after this point: [history_a] loading pickled environment... not yet created [history_a] building [inventory]: targets for 1 source files that are out of date [history_a] updating environment: 1 added, 0 changed, 0 removed [history_a] reading sources... [100%] index [history_a] loading cross citations... [history_a] pickling environment... done [history_a] checking consistency... done [history_a] preparing documents... done [history_a] writing output... [100%] index [history_a] dumping object inventory... done [history_a] build succeeded. OK, I have done a lot of work trying to figure this out. What I discovered is that some of the doc building simply isn't finishing. For example: [calculus ] loading pickled environment... not yet created [calculus ] building [inventory]: targets for 20 source files that are out of date [calculus ] updating environment: 20 added, 0 changed, 0 removed [calculus ] reading sources... [ 5%] index [calculus ] reading sources... [ 10%] sage/calculus/calculus [categorie] loading pickled environment... not yet created You see, it starts building for calculus, and then it just stops. Then categories starts building. This is all with NUMBERTHREADS set to 1. If the building of calculus just stops, but the number of threads is 1, why then doesn't everything just stop? Instead it seems to stop on a pool_join command in builder.py? I'll give more details to anyone who is interested. In the meantime, if anyone has any ideas, I would appreciate hearing them. Thanks, Stephen -- 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] Is it OK to add a module intended for teaching?
Hello, http://trac.sagemath.org/sage_trac/ticket/14288 provides a module for teaching the simplex method, i.e. you should NOT use it routinely to just get solutions of optimization problems. Dima has pointed out that an optional package may be more appropriate in such cases. Does anyone else has an opinion on these matters? As I see it, the disadvantage for getting it in as a module is increasing the code base, in this case source.tar.gz will get about +25kb. Disadvantages of optional packages - less visibility and extra work for those who want to use it. In particular, interacts will not be possible, unless someone maintains a Sage Cell Server with suitable optional packages installed or includes optional modules into the cell (3916 lines in this case). Advantages: no limits on size, e.g. it would be possible to bundle supporting worksheets with rendered plots and formulas, perhaps some lecture notes. I'd prefer to have computational modules as a part of standard distribution and big documentation extras - as packages. If this will turn out to be OK with others: should there be a special place for such modules? Dima has suggested sage/teaching. Thank you! Andrey -- 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] Is it OK to add a module intended for teaching?
On Sun, Mar 17, 2013 at 5:19 PM, Andrey Novoseltsev novos...@gmail.com wrote: Hello, http://trac.sagemath.org/sage_trac/ticket/14288 provides a module for teaching the simplex method, i.e. you should NOT use it routinely to just get solutions of optimization problems. Dima has pointed out that an optional package may be more appropriate in such cases. Does anyone else has an opinion on these matters? +1 I know of at least one OR person at the USNA who will use that in teaching. As I see it, the disadvantage for getting it in as a module is increasing the code base, in this case source.tar.gz will get about +25kb. Disadvantages of optional packages - less visibility and extra work for those who want to use it. In particular, interacts will not be possible, unless someone maintains a Sage Cell Server with suitable optional packages installed or includes optional modules into the cell (3916 lines in this case). Advantages: no limits on size, e.g. it would be possible to bundle supporting worksheets with rendered plots and formulas, perhaps some lecture notes. I'd prefer to have computational modules as a part of standard distribution and big documentation extras - as packages. If this will turn out to be OK with others: should there be a special place for such modules? Dima has suggested sage/teaching. Thank you! Andrey -- 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. -- 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: Is it OK to add a module intended for teaching?
At the end of the day, you are writing a toy implementation of an algorithm that can be used for teaching. It is also a great resource to check results of more optimized algorithms, so I see it as a useful part of the Sage library whether you use it for teaching or not. In this particular case there is already some framework for different LP backends, and it would be best-integrated if you could push your code into a separate (toy-) backend. If that is not feasible (and I don't really know myself) then I would put it the same subdirectory as the other LP stuff as toy_simplex.py or some such. On Sunday, March 17, 2013 5:19:46 PM UTC-4, Andrey Novoseltsev wrote: Hello, http://trac.sagemath.org/sage_trac/ticket/14288 provides a module for teaching the simplex method, i.e. you should NOT use it routinely to just get solutions of optimization problems. Dima has pointed out that an optional package may be more appropriate in such cases. Does anyone else has an opinion on these matters? As I see it, the disadvantage for getting it in as a module is increasing the code base, in this case source.tar.gz will get about +25kb. Disadvantages of optional packages - less visibility and extra work for those who want to use it. In particular, interacts will not be possible, unless someone maintains a Sage Cell Server with suitable optional packages installed or includes optional modules into the cell (3916 lines in this case). Advantages: no limits on size, e.g. it would be possible to bundle supporting worksheets with rendered plots and formulas, perhaps some lecture notes. I'd prefer to have computational modules as a part of standard distribution and big documentation extras - as packages. If this will turn out to be OK with others: should there be a special place for such modules? Dima has suggested sage/teaching. Thank you! Andrey -- 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.
