[sage-combinat-devel] Re: The reading tableau of a partition
Hey Andrew, I have been distracted from sage for quite some time but this morning I started playing again and I came across the *reading_tableau *method of a partition. The documentation for this method reads: Return the reading tableau of the reading word under the Robinson-Schensted correspondence of the (standard) tableau `T` labeled down (in English convention) each column to the shape of ``self``. For an example of the tableau `T`, consider the partition `\lambda = (3,2,1)`, then we have:: 1 4 6 2 5 3 For more, see :func:`~sage.combinat.rsk.RSK()`. EXAMPLES:: sage: Partition([3,2,1]).reading_tableau() [[1, 3, 6], [2, 5], [4]] The example in the text and the example that is doc-test appear to disagree. My guess is that the example in the text is what is expected. Is this right? [In 5.8 the behaviour is as in the doc-test.] This is correct. The documentation is describing the tableau T, which then it takes the reading word (which is [3, 2, 5, 1, 4, 6]), and then runs RSK on that permutation and pulls the reading tableau. While the documentation is not the best, it is accurate (I had to read it a few times myself). Best, Travis -- 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-combinat-devel] Re: The reading tableau of a partition
Travis, Any reasonable definition of reading word of tableau will have the property that the result of inserting the reading word of the tableau, is the original tableau. So I think there is a problem somewhere here. --Mark Hey Andrew, I have been distracted from sage for quite some time but this morning I started playing again and I came across the *reading_tableau *method of a partition. The documentation for this method reads: Return the reading tableau of the reading word under the Robinson-Schensted correspondence of the (standard) tableau `T` labeled down (in English convention) each column to the shape of ``self``. For an example of the tableau `T`, consider the partition `\lambda = (3,2,1)`, then we have:: 1 4 6 2 5 3 For more, see :func:`~sage.combinat.rsk.RSK()`. EXAMPLES:: sage: Partition([3,2,1]).reading_tableau() [[1, 3, 6], [2, 5], [4]] The example in the text and the example that is doc-test appear to disagree. My guess is that the example in the text is what is expected. Is this right? [In 5.8 the behaviour is as in the doc-test.] This is correct. The documentation is describing the tableau T, which then it takes the reading word (which is [3, 2, 5, 1, 4, 6]), and then runs RSK on that permutation and pulls the reading tableau. While the documentation is not the best, it is accurate (I had to read it a few times myself). Best, Travis -- 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. -- 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] Sage notebook server with combinat patches installed
Dear Sage developers, On https://combinat.sagemath.org:8080/ You will find a publicly accessible notebook server running with the Sage-Combinat patches applied. Main use cases: giving access to colleagues to your in-development code. As the front page says, it's still pretty experimental. In particular Sage and Sage-Combinat are updated manually ... when I get to do it ... I'll advertise it more widely (in particular on the wiki) when we will have beta tested it more. Fell free to volunteer to take over the maintenance! 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.
Re: [sage-combinat-devel] Sage notebook server with combinat patches installed
Hi Nicolas, Cool! Thank you for setting this up! This will be immensely useful to let people try out code who are not (yet) developers! Cheers, Anne On 4/12/13 1:19 PM, Nicolas M. Thiery wrote: Dear Sage developers, On https://combinat.sagemath.org:8080/ You will find a publicly accessible notebook server running with the Sage-Combinat patches applied. Main use cases: giving access to colleagues to your in-development code. As the front page says, it's still pretty experimental. In particular Sage and Sage-Combinat are updated manually ... when I get to do it ... I'll advertise it more widely (in particular on the wiki) when we will have beta tested it more. Fell free to volunteer to take over the maintenance! 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] Re: The reading tableau of a partition
Hi Travis, What confused me is that the example in the documentation seems to say that the reading tableau for the *partition* (3,2,1) should be 1 4 6 2 5 3 whereas the example in the doc-test says that it is 1 3 6 2 5 4 These two tableaux are different. I need the first of these tableaux and I thought that this is what reading_tableau() was supposed to return. This isn't a big deal for me because I can get this tableau easily a different way. All these concerns aside, however, I am still confused by the documentation as it the example contained in the help for reading_tableau seems to contradict what the function actually does. Notice that this a method for a partition which returns a tableau -- there are no permutations in sight here. Andrew -- 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
Hi there. On Thu, Apr 11, 2013 at 11:48:17PM +0200, Tobias Hansen wrote: so theres the inevitable question to ask: would it be an option to eventually split c_lib and the python modules to different packages? If they are each in a selfcontained folder it's not too much hassle to repack them from the one tarball. (Ok, still some hassle.) However, I don't see why they should not be in one source package. Because linking to c_lib has to be done differently when it is not installed on the system when the package is built? An important implication of having stuff together in a source package is usually that they have to be updated together. That is the case for the parts of Sage. By the way, does c_lib have a stable ABI so that it is reasonable to have it as a public shared library? Would that be useful? i don't see the c_lib/python sage lib as critical as the gentoo people do. but: if some distribution -- for whatever reason -- requires/fancies seperate packages, seperate packages would make sage more distribution friendly. (no actual problem here). what frightens me is that the spkgs for the core parts have vanished in https://github.com/sagemath/sage.git (the git-transition). if this is serious (and not a temporary kludge), we really would have to repack tarballs. this (imo) is not just 'some hassle': try to cherry-pick a patch from current sage-python that makes the release candidate work with, say singular-(sage-singular-version+0.0.1). this scenario is realistic, as it doesnt seem possible to always ship exact dependencies within debian/gentoo/whatever. now try to cherry-pick that patch after repacking and loosing history. im not saying it's not possible. but it would be seriously distribution-unfriendly. It would still be nice if the top level script could be used by distributions. [...] i'm not convinced. once all parts (including python-sage and c_lib) are in a distributable/configurable shape, any distribution will be able to pick them up easily. especially there will be no need for distributions to use sage's built in top-level script. whatever a top level script does, it will never fit the needs of all distributions at once. just think about building a multiarch ready package out of c_lib, while it is only accessible within a tarball containing the sources of five other packages, through a patchwork of a sage-toplevel script and an spkg-install script calling scons install through a static makefile (or setup.py or whatever). Sounds reasonable. Would you take care that the Sage distribution also build python-sage, c_lib, etc using the new configurable process? that would be the primary objective. treat python-sage, c_lib, sage-scripts, extcode, whatnoteverelse as *packages* just like all the other packages. now understand the sage-toplevel repository as a sage distribution (distributing spkgs or successors). sage will be distribution-friendly as soon as all packages have sane build systems. regards felix -- 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
Am 12.04.2013 10:25, schrieb Felix Salfelder: Hi there. On Thu, Apr 11, 2013 at 11:48:17PM +0200, Tobias Hansen wrote: so theres the inevitable question to ask: would it be an option to eventually split c_lib and the python modules to different packages? If they are each in a selfcontained folder it's not too much hassle to repack them from the one tarball. (Ok, still some hassle.) However, I don't see why they should not be in one source package. Because linking to c_lib has to be done differently when it is not installed on the system when the package is built? An important implication of having stuff together in a source package is usually that they have to be updated together. That is the case for the parts of Sage. By the way, does c_lib have a stable ABI so that it is reasonable to have it as a public shared library? Would that be useful? i don't see the c_lib/python sage lib as critical as the gentoo people do. but: if some distribution -- for whatever reason -- requires/fancies seperate packages, seperate packages would make sage more distribution friendly. (no actual problem here). what frightens me is that the spkgs for the core parts have vanished in https://github.com/sagemath/sage.git (the git-transition). if this is serious (and not a temporary kludge), we really would have to repack tarballs. Only if we want multiple Sage Debian source packages. this (imo) is not just 'some hassle': try to cherry-pick a patch from current sage-python that makes the release candidate work with, say singular-(sage-singular-version+0.0.1). this scenario is realistic, as it doesnt seem possible to always ship exact dependencies within debian/gentoo/whatever. now try to cherry-pick that patch after repacking and loosing history. im not saying it's not possible. but it would be seriously distribution-unfriendly. To the git transition team: Have you considered using git submodules for the different Sage components? It would certainly solve this issue. Would it also have other advantages? Is there a reason not to do it? Cheers, Tobias -- 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: Global options
It would be nice if we could implement the syntax in the IPython configuration stuff: A.options.foobar = 1 in addition to A.options(foobar=1) This would require us to rename the existing methods of GlobalOptions with underscores. Also, for consistency we should recommend / enforce a name for the options. Should it be A.options or A.global_options or what? The docs use various conventions. On Friday, April 12, 2013 2:17:35 AM UTC+1, Andrew Mathas wrote: Dear Developers, As part of the clean up of the partitions code by Travis (Trac 13605http://trac.sagemath.org/sage_trac/ticket/13605) I implemented a generic options interface in sage which can be used for controlling (global) options for sage objects. See sage.structure.global_options for details. This patch, including the global_options, was merged in sage-5.8.beta3. Novosel has just complained, quite justifiably, on the ticket above that the global options should have been given their own ticket rather than being hidden in a large patch. Apologies for this, but these options just grew as part of my review patch with fine tune-tuning (and reviewing) from Travis and Nicolas at ICERM... Given the obscure manner in which this options framework has entered sage, and Novosel's comment on the ticket, I now take the opportunity to advertise them. Andrew -- 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 12/04/13 20:59, Tobias Hansen wrote: Am 12.04.2013 10:25, schrieb Felix Salfelder: Hi there. On Thu, Apr 11, 2013 at 11:48:17PM +0200, Tobias Hansen wrote: so theres the inevitable question to ask: would it be an option to eventually split c_lib and the python modules to different packages? If they are each in a selfcontained folder it's not too much hassle to repack them from the one tarball. (Ok, still some hassle.) However, I don't see why they should not be in one source package. Because linking to c_lib has to be done differently when it is not installed on the system when the package is built? An important implication of having stuff together in a source package is usually that they have to be updated together. That is the case for the parts of Sage. By the way, does c_lib have a stable ABI so that it is reasonable to have it as a public shared library? Would that be useful? i don't see the c_lib/python sage lib as critical as the gentoo people do. but: if some distribution -- for whatever reason -- requires/fancies seperate packages, seperate packages would make sage more distribution friendly. (no actual problem here). what frightens me is that the spkgs for the core parts have vanished in https://github.com/sagemath/sage.git (the git-transition). if this is serious (and not a temporary kludge), we really would have to repack tarballs. Only if we want multiple Sage Debian source packages. this (imo) is not just 'some hassle': try to cherry-pick a patch from current sage-python that makes the release candidate work with, say singular-(sage-singular-version+0.0.1). this scenario is realistic, as it doesnt seem possible to always ship exact dependencies within debian/gentoo/whatever. now try to cherry-pick that patch after repacking and loosing history. im not saying it's not possible. but it would be seriously distribution-unfriendly. To the git transition team: Have you considered using git submodules for the different Sage components? It would certainly solve this issue. Would it also have other advantages? Is there a reason not to do it? I'd like to note that on gentoo we only use things like sage-singular-xxx as an exception - singular is a particularly good example, since it was the last one we had years ago. Compared to debian we have a little bit more freedom on the versions a user can install. My own experience over the years is that singular and pari are possibly the most problematic one followed by polybori (but it is improving dramatically in that regard in the latest release), networkx and lately ppl. The biggest reason of doing sage-foo for everything is to use mpir instead of gmp. sage-on-gentoo is using gmp as switching to mpir distro wide would require agreement from the toolchain people. There are way of giving people the choice but that involves changing every package currently using gmp 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: Sage part of Google's Summer of Code 2013
Can someone edit the project proposals page to include the gui for controling the vm? On 11 abr, 10:49, Harald Schilly harald.schi...@gmail.com wrote: Hi, this is a reminder, that students start proposing ideas in the dedicated forum over here:https://groups.google.com/forum/?fromgroups#!forum/sage-gsoc H On Monday, April 8, 2013 11:03:40 PM UTC+2, Harald Schilly wrote: Good News, like last year Sage is once again part of Google's Summer of Code. This means, until April 22 at 19:00 UTC students can submit their applications and mentors will review them and do the matching. Please share this with prospective students or think about being a mentor this year! gsoc page:http://www.google-melange.com/gsoc/org/google/gsoc2013/sage ideas:http://goo.gl/l0CRl(check back for updates) Harald -- 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 04/11/2013 11:48 PM, Tobias Hansen wrote: If they are each in a selfcontained folder it's not too much hassle to repack them from the one tarball. (Ok, still some hassle.) However, I don't see why they should not be in one source package. Because linking to c_lib has to be done differently when it is not installed on the system when the package is built? An important implication of having stuff together in a source package is usually that they have to be updated together. That is the case for the parts of Sage. I agree. I see no reason at all for having separate packages for c_lib and the sage library for example. Perhaps Gentoo has its reasons, but normally I expect this to remain one package. -- 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: new optional (or experimental) package CSDP?
On 2013-04-11, Nathann Cohen nathann.co...@gmail.com wrote: --=_Part_629_6688666.1365672308379 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 I had never heard of Flagmatic before. Looks GREAT :-D it implements a range of recent ideas due to Razborov et al, which produced a lot of progress in extremal (hyper)graph theory recently. Dima Nathann On Thursday, April 11, 2013 6:56:45 AM UTC+2, Snark wrote: Le 11/04/2013 06:32, Nils Bruin a =EF=BF=BDcrit :=20 On Apr 10, 8:52 pm, Dima Pasechnikdimp...@gmail.com wrote:=20 2) yes to CSDP becoming an experimental package.=20 =20 Doing that requires no different work from preparing it to be an=20 optional package, so why not do that first? Once that's done I would=20 expect it'll be pretty smooth sailing into optional status.=20 +1=20 Snark on #sagemath=20 -- 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] R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance
Hi, I tried to do some plotting in R after break from using R inside Sage, but I encountered error: Error in png() : X11 module cannot be loaded In addition: Warning message: In png() : unable to load shared object '/usr/local/sage/sage-5.8-opt/local/lib/R//modules//R_X11.so': /usr/lib/libharfbuzz.so.0: undefined symbol: FT_Get_Advance I checked it, and libharfbuzz.so.0 (dependency of pango/cairo) in my system is 0.9.15, the symbol it looks for is defined in my system-wide freetype installation ( 2.4.11 ), but is missing from Sage-installed freetype (2.3.5) that is linked in R_X11.so. rebuilding R with --without-cairo helps, and it still can generate png files using grGraphics - was cairo enabled on purpose and is used somewhere else in Sage version of R? Thanks, Andrzej. -- 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: R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance
Can you use the Xlib backend in R?
sage: print r.eval('capabilities()')
jpeg png tifftcltk X11 aqua http/ftp sockets
libxml fifo cledit
FALSEFALSEFALSEFALSEFALSEFALSE TRUE TRUE
TRUE TRUE TRUE
iconv NLS profmemcairo
TRUE TRUEFALSEFALSE
You need more than just the Sage minimal requirements for R graphics. At
least X11 development, ideally a working cairo. I think we should just
disable our own freetype if the OS provides a working freetype (with
headers). Otherwise you need a pretty large stack, cairo + freetype +
harfbuzz + ... to produce high-quality plots.
--
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] Blocker tickets
There are 2 blocker tickets remaining for Sage 5.9, both of them need review: #14371: Race condition in singular doctest http://trac.sagemath.org/sage_trac/ticket/14371 #14426: Runaway/Segfaulting ECL processes http://trac.sagemath.org/sage_trac/ticket/14426 There is already 1 blocker for Sage 5.10, which also needs review: #14433: Increase number of matches to tree in sagedoc.py doctest http://trac.sagemath.org/sage_trac/ticket/14433 -- 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: R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance
Well, there are no X-es on this machine, but it is ready to use png
backend with or without cairo when compiled with freetype on host:
capabilities()
jpeg png tifftcltk X11 aqua http/ftp sockets
TRUE TRUE TRUE TRUEFALSEFALSE TRUE TRUE
libxml fifo clediticonv NLS profmemcairo
TRUE TRUE TRUE TRUE TRUEFALSE TRUE
I don't care much about X11 there, I'm actually testing this to do R
trough Sage Cell server for one of courses I teach. When I enter
capabilities inside Sage, I get false almost everywhere, but the
unable to load shared object shows up as well.
On Fri, Apr 12, 2013 at 3:33 PM, Volker Braun vbraun.n...@gmail.com wrote:
Can you use the Xlib backend in R?
sage: print r.eval('capabilities()')
jpeg png tifftcltk X11 aqua http/ftp sockets
libxml fifo cledit
FALSEFALSEFALSEFALSEFALSEFALSE TRUE TRUE
TRUE TRUE TRUE
iconv NLS profmemcairo
TRUE TRUEFALSEFALSE
You need more than just the Sage minimal requirements for R graphics. At
least X11 development, ideally a working cairo. I think we should just
disable our own freetype if the OS provides a working freetype (with
headers). Otherwise you need a pretty large stack, cairo + freetype +
harfbuzz + ... to produce high-quality plots.
--
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.
Re: [sage-devel] Re: R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance
On Friday, April 12, 2013 3:35:41 PM UTC+1, Andrzej Giniewicz wrote: Well, there are no X-es on this machine, but it is ready to use png backend with or without cairo when compiled with freetype on host There are 3 backends that can write png in R, and they are cairo, Xlib, and quartz. If you can generate png and have neither X11 nor cairo then you are on a Mac. -- 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: R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance
Well, to be more clear I have only xvfb + dependencies, so I should have said I have headless Xes On Fri, Apr 12, 2013 at 4:48 PM, Volker Braun vbraun.n...@gmail.com wrote: On Friday, April 12, 2013 3:35:41 PM UTC+1, Andrzej Giniewicz wrote: Well, there are no X-es on this machine, but it is ready to use png backend with or without cairo when compiled with freetype on host There are 3 backends that can write png in R, and they are cairo, Xlib, and quartz. If you can generate png and have neither X11 nor cairo then you are on a Mac. -- 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.
Re: [sage-devel] Blocker tickets
Hi,
Tickt 14433 fails on my system:
sage:len(search_doc('tree', interact=False).splitlines()
3956
sage: version()
'Sage Version 5.8, Release Date: 2013-03-15'
bg,
Johannes
On 12.04.2013 16:01, Jeroen Demeyer wrote:
There are 2 blocker tickets remaining for Sage 5.9, both of them need
review:
#14371: Race condition in singular doctest
http://trac.sagemath.org/sage_trac/ticket/14371
#14426: Runaway/Segfaulting ECL processes
http://trac.sagemath.org/sage_trac/ticket/14426
There is already 1 blocker for Sage 5.10, which also needs review:
#14433: Increase number of matches to tree in sagedoc.py doctest
http://trac.sagemath.org/sage_trac/ticket/14433
--
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 Fri, Apr 12, 2013 at 09:23:45PM +1200, Francois Bissey wrote: I'd like to note that on gentoo we only use things like sage-singular-xxx as an exception - singular is a particularly good example, since it was the last one we had years ago. Compared to debian we have a little bit more freedom on the versions a user can install. My own experience over the years is that singular and pari are possibly the most problematic one followed by polybori (but it is improving dramatically in that regard in the latest release), networkx and lately ppl. but i guess, you would switch to unprefixed versions, if they worked as well. The biggest reason of doing sage-foo for everything is to use mpir instead of gmp. sage-on-gentoo is using gmp as switching to mpir distro wide would require agreement from the toolchain people. There are way of giving people the choice but that involves changing every package currently using gmp in debian one would probably postfix libraries linked against mpir instead of gmp with -mpir, like for example libmpfr-mpir, libmpfi-mpir or libpari-mpir. this is not difficult, does not require a distro-wide switch and is only indirectly related to sage. providing mpir versions is something we/debian should do after sage is packaged and working (and there is an indication to do so). regards felix -- 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 13/04/2013, at 4:24, Felix Salfelder fe...@salfelder.org wrote: On Fri, Apr 12, 2013 at 09:23:45PM +1200, Francois Bissey wrote: I'd like to note that on gentoo we only use things like sage-singular-xxx as an exception - singular is a particularly good example, since it was the last one we had years ago. Compared to debian we have a little bit more freedom on the versions a user can install. My own experience over the years is that singular and pari are possibly the most problematic one followed by polybori (but it is improving dramatically in that regard in the latest release), networkx and lately ppl. but i guess, you would switch to unprefixed versions, if they worked as well. Yes and we currently do not use prefixed version singular was the last one several year ago. 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] Sage notebook server virtual machine
Hi, I just installed a new notebook server on: https://combinat.sagemath.org:8080/ following http://wiki.sagemath.org/SageServer Thanks Jason for the great step-by-step instructions! This made me wonder: we currently are distributing a virtual machine containing a sage notebook server for private usage, mostly for the convenience of our windows users. Would it make sense to distribute another virtual machine that would be preconfigured as a public notebook server? Then, someone wanting to run such a server at a meeting, or in his lab, or in a class, could just fire the virtual machine and be basically, up to maybe some virtualbox/qemu network configuration. It should be straightforward to script the instructions on the wiki, to make the building of the virtual machine roughly automatic. Of course any long term usage of such a server would still require more tweaking, but that would be a good easy starting point. Just throwing the idea; I am not really volunteering ... Cheers, Nicolas PS: by the way the instructions to create the sage user accounts are currently broken on the wiki. I used this instead: for i in $(seq 0 9); do cp ~sageserver/.ssh/id_dsa.pub /home/sage$i/.ssh/authorized_keys; done for i in $(seq 0 9); do chmod 700 /home/sage$i/.ssh; done for i in $(seq 0 9); do chmod 600 /home/sage$i/.ssh/authorized_keys; done for i in $(seq 0 9); do chown -R sage$i:sageuser /home/sage$i/.ssh; done -- 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-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: new optional (or experimental) package CSDP?
I had never heard of Flagmatic before. Looks GREAT :-D it implements a range of recent ideas due to Razborov et al, which produced a lot of progress in extremal (hyper)graph theory recently. I had no idea it had evolved into an open source project already :-) 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: GSoC project: make the Sage build system more distribution friendly
First a disclaimer: I was at Sage Days 47 (working on the transition to git), but I'm not a git expert and I don't know the technical justification for some of the choices made (I think the best people to speak up in that direction would be Andrew Ohana, Keshav Kini, Robert Bradshaw, Timo Kluck or Julian Ruth). I also use OS X so I personally have no interest in working on packaging efforts, though I'm grateful to those of you who do, both for the increased exposure of Sage in the Linux world and for the progress toward the goal of being able to checkout different versions of Sage with different spkgs installed and have them build and work. But speaking as someone who contributes a lot to the Sage library itself, I'm strongly in support of Robert Bradshaw's proposal that we combine the different Sage repositories (root, devel, script and ext). It's much easier to work on issues that involve code in these different repositories once you only have to make a commit to a single unified repo. On Fri, Apr 12, 2013 at 2:59 AM, Tobias Hansen than...@debian.org wrote: Am 12.04.2013 10:25, schrieb Felix Salfelder: Hi there. On Thu, Apr 11, 2013 at 11:48:17PM +0200, Tobias Hansen wrote: so theres the inevitable question to ask: would it be an option to eventually split c_lib and the python modules to different packages? If they are each in a selfcontained folder it's not too much hassle to repack them from the one tarball. (Ok, still some hassle.) However, I don't see why they should not be in one source package. Because linking to c_lib has to be done differently when it is not installed on the system when the package is built? An important implication of having stuff together in a source package is usually that they have to be updated together. That is the case for the parts of Sage. By the way, does c_lib have a stable ABI so that it is reasonable to have it as a public shared library? Would that be useful? i don't see the c_lib/python sage lib as critical as the gentoo people do. but: if some distribution -- for whatever reason -- requires/fancies seperate packages, seperate packages would make sage more distribution friendly. (no actual problem here). what frightens me is that the spkgs for the core parts have vanished in https://github.com/sagemath/sage.git (the git-transition). if this is serious (and not a temporary kludge), we really would have to repack tarballs. I'm not sure whether the spkgs you refer to correspond to the four repositories I mentioned above, but if so then the merging is intended to be permanent. this (imo) is not just 'some hassle': try to cherry-pick a patch from current sage-python that makes the release candidate work with, say singular-(sage-singular-version+0.0.1). this scenario is realistic, as it doesnt seem possible to always ship exact dependencies within debian/gentoo/whatever. now try to cherry-pick that patch after repacking and loosing history. im not saying it's not possible. but it would be seriously distribution-unfriendly. To the git transition team: Have you considered using git submodules for the different Sage components? It would certainly solve this issue. Would it also have other advantages? Is there a reason not to do it? Exactly what do you mean by different Sage components? I do know that there was some discussion of git submodules, but it was discarded for technical reasons that I don't recall. David -- 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: Global options
On Friday, 12 April 2013 19:23:31 UTC+10, Volker Braun wrote: It would be nice if we could implement the syntax in the IPython configuration stuff: A.options.foobar = 1 in addition to A.options(foobar=1) This would require us to rename the existing methods of GlobalOptions with underscores. One advantage of this is of course would be tab-completion for the options. I'm not entirely sure about renaming the existing methods, however. The methods for a GlobalOptions object are currently: category, db, default_value, dispatch, dump, dumps, rename, reset, reset_name, save, version The methods in red are all standard SageObject methods which probably should not be renamed. Also, for consistency we should recommend / enforce a name for the options. Should it be A.options or A.global_options or what? The docs use various conventions. I see two different use cases: - global options which control the general behaviour of one or more classes (as with the currently implemented global_options methods of Partitions, Tableaux, PartitionTuples, ...) - options which control how particular instances of class function Encouraging global_options for the former and options for the latter would make sense. Andrew -- 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.
