Re: [sage-devel] Re: xcode and gcc
On Thu, Jan 26, 2012 at 1:33 PM, William Stein wrote: > Also, we could have a dmg available that would install GCC (including > gfortran) somewhere, and could be used to build Sage on OS X. +big_number Even outside the context of Sage, when teaching purely 'scipy stack' to students (many of whom have macs in US academia) it's really frustrating to hit that stupid Xcode hurdle just so I can show them how Cython works (or weave a little while back). Just last wekend I was answering questions precisely on this for our python bootcamp at Berkeley (http://register.pythonbootcamp.info), we ended up disabling all weave/cython stuff because we were going to drown in installation hassles (we had ~150 people). If you guys can put out a gcc/gfortran installer for the Mac that's a simple download, click, install, you'll benefit lots of people even beyond Sage. Back to the peanut gallery... f -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: xcode and gcc
Hi, so far, three distinct topics evolved in this thread: 1. Make Sage not needing a C compiler, when one changed only .py files and then types "sage -b". That's the topic of trac #12365 (see the original post), and up to now, I read only supportive comments (to which I say +1 also). 2. Discussion of using the "LLVM-backend gcc" (or even the Clang compiler itself, which amounts to almost to the same) versus using the "FSF- backend gcc" for Sage, at least on OS X. 3. Make Sage on OS X independent of having XCode installed. I'll concentrate on this second and third points. FWIW, on my OS X 10.7.2 partition I was able to build Sage-4.8 using the "FSF-backend" gcc (using the R project's gcc42 package alluded to above), and a ptestlong run only showed doctest failures in three files (for which I failed to make up trac tickets up to now). William had reported these failures (all seem to be numerical noise) elsewhere in another thread for some "LLVM-backend gcc" OS X 10.7 test build of his. But there he reported also failures in "interrupt.pyx", which I didn't see with the "FSF-backend gcc" build of mine. IMHO, Sage should be able to rely on either GCC (FSF-flavour) or else Clang --- we really shouldn't target the "LLVM-flavour gcc", since support of this might go away soon. The LLVM project says e.g. that as of their current 3.0 release, "llvm-gcc is no longer supported" (see http://llvm.org/releases/3.0/docs/ReleaseNotes.html), and Apple also seems determined to replace it with Clang as soon as possible. This leaves three alternatives: a) Stay with the old "FSF-flavor" Apple version of gcc v4.2.1 "build 5666.3", as has been included in XCode 3.2.6, 4.0. and 4.1 (but no longer from 4.2 onwards), and that gcc42 package. b) Use newer FSF gcc's on OS X, e.g. gcc-4.4 (with the benefit of the possibility to use an up-to-date gfortran also). c) Support building Sage with Clang (BTW, that's a general theme, which is not restricted to OS X at all!) --- but both gfortran and g95 seem to rely on the FSF gcc backends. Does any one know the status of building some fortran compiler with/relying on nothing but Clang (should be possible, since usually Fortran code is translated to C code first, and only then compiled)? Note that this still says next to nothing about point 3) above (getting independent of XCode). If one wants to build Sage from source on OS X, one needs not only "make" and such (which a vanilla OS X 10.7 install does not provide), but also certain library headers (which e.g. on Debian would be in those "dev"-packages), and the like. I'm not sure whether there is any solution for that available yet. (Both MacPorts and Gentoo Prefix seem to require XCode at least for bootstrapping themselves.) Especially when interfacing with Cocoa/graphics is concerned (Python itself does this, matplotlib, R, i.e. several non-trivial components of Sage), the respective headers are needed, and it may very well be that only XCode provides these in a "neatly downloadable" way (those "SDKs"). One could patch all these parts out of Sage (they are "OS X only" parts, after all, so Sage runs certainly without). I did that once to get Sage building in 64bit on OS X 10.4 (for which those Cocoa parts are supported only in 32bit), so it is definitely possible --- but it's not some "minor" effort to get this ready for "prime-time" mainline Sage releases, as you certainy want "plot" to show something (maybe we would need Qt, or another alternative to Cocoa/Aqua graphics)! I'd modestly suggest staying with the requirement of XCode for building Sage from source on OS X (merely using Sage, and doing Sage library development, is something different, though). Cheers, Georg -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: xcode and gcc
On 1/27/12 2:18 AM, Fernando Perez wrote: If you guys can put out a gcc/gfortran installer for the Mac that's a simple download, click, install, you'll benefit lots of people even beyond Sage. https://github.com/kennethreitz/osx-gcc-installer is one possible place to look for gcc, at least. Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: xcode and gcc
On Fri, Jan 27, 2012 at 12:55 AM, Jason Grout wrote: > https://github.com/kennethreitz/osx-gcc-installer is one possible place to > look for gcc, at least. Nice, thanks! I didn't know about that, it's excellent and does help a lot. Cheers, f -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Minimizing dependencies of Sage library (#12329) needs review
I have a patch to remove unneeded dependencies of the Sage library in spkg/standard/deps (the patch only touches this file). This might speed up builds of Sage, especially upgrades. Please review http://trac.sagemath.org/sage_trac/ticket/12329 Thanks, Jeroen. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: webgl
I have just tested on chromium and firefor under linux. It does work on both (but i have the impression that performance is better in chromium). Strangely, it does work on the version of firefox that i have compiled in my computer, but it doesn't in the binary version from the firefox site. I guess that there is some compile option that is disabled in the binary package. On 27 ene, 00:41, Volker Braun wrote: > On Thursday, January 26, 2012 2:14:36 PM UTC-8, William wrote: > > > [1] If you're using Chrome, check out > >http://www.chromeexperiments.com/webgl > > Unless you use Linux, where chrome doesn't support webgl despite what the > documentation says. Works in Firefox, though. > > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] PyCox: Computing with (finite) Coxeter groups and Iwahori-Hecke algebras
I just noticed this post to the arXiv. Is Meinholf Geck in touch with
Sage?
--Dave
Title: PyCox: Computing with (finite) Coxeter groups and Iwahori-Hecke
algebras
Authors: Meinolf Geck
Categories: math.RT
Comments: 31 pages
MSC-class: 20C40, 20C08
\\
We introduce the computer algebra package {\sf PyCox}, written
entirely in
the {\sf Python} language. It implements a set of algorithms - in a
spirit
similar to the older {\sf CHEVIE} system - for working with Coxeter
groups and
Hecke algebras. This includes a new variation of the traditional
algorithm for
computing Kazhdan-Lusztig cells and $W$-graphs, which works
efficiently for all
groups of rank $\leq 8$ (except $E_8$). Our experiments suggest a re-
definition
of Lusztig's "special" representations which, conjecturally, should
also apply
to the unequal parameter case.
\\ ( http://arxiv.org/abs/1201.5566 , 39kb)
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: xcode and gcc
On Fri, Jan 27, 2012 at 00:51, Georg S. Weber wrote: > Hi, > > so far, three distinct topics evolved in this thread: > > 1. > Make Sage not needing a C compiler, when one changed only .py files > and then types "sage -b". That's the topic of trac #12365 (see the > original post), and up to now, I read only supportive comments (to > which I say +1 also). +1 from me as well > > 2. > Discussion of using the "LLVM-backend gcc" (or even the Clang compiler > itself, which amounts to almost to the same) versus using the "FSF- > backend gcc" for Sage, at least on OS X. > > > 3. > Make Sage on OS X independent of having XCode installed. > > > > I'll concentrate on this second and third points. > FWIW, on my OS X 10.7.2 partition I was able to build Sage-4.8 using > the "FSF-backend" gcc (using the R project's gcc42 package alluded to > above), and a ptestlong run only showed doctest failures in three > files (for which I failed to make up trac tickets up to now). William > had reported these failures (all seem to be numerical noise) elsewhere > in another thread for some "LLVM-backend gcc" OS X 10.7 test build of > his. But there he reported also failures in "interrupt.pyx", which I > didn't see with the "FSF-backend gcc" build of mine. IMHO, Sage should > be able to rely on either GCC (FSF-flavour) or else Clang --- we > really shouldn't target the "LLVM-flavour gcc", since support of this > might go away soon. The LLVM project says e.g. that as of their > current 3.0 release, "llvm-gcc is no longer supported" (see > http://llvm.org/releases/3.0/docs/ReleaseNotes.html), and Apple also > seems determined to replace it with Clang as soon as possible. This > leaves three alternatives: > > a) > Stay with the old "FSF-flavor" Apple version of gcc v4.2.1 "build > 5666.3", as has been included in XCode 3.2.6, 4.0. and 4.1 (but no > longer from 4.2 onwards), and that gcc42 package. > > b) > Use newer FSF gcc's on OS X, e.g. gcc-4.4 (with the benefit of the > possibility to use an up-to-date gfortran also). +1 However, if we do release a binary based upon this, it would need to have a simple tool to switch toolchains, for developers who need to use XCode for other projects (such as iPhone apps) -- I personally am a fan of gentoo (prefix), which has the convenient gcc-config tool that makes this super simple (although, it may have to be modified to work with XCode). > c) > Support building Sage with Clang (BTW, that's a general theme, which > is not restricted to OS X at all!) --- but both gfortran and g95 seem > to rely on the FSF gcc backends. Does any one know the status of > building some fortran compiler with/relying on nothing but Clang > (should be possible, since usually Fortran code is translated to C > code first, and only then compiled)? +1 if feasible However, according to Wikipedia (which is know to be always correct :p) "For other languages, including Java, Fortran, and Ada, LLVM remains dependent on GCC." [1] > > > Note that this still says next to nothing about point 3) above > (getting independent of XCode). If one wants to build Sage from source > on OS X, one needs not only "make" and such (which a vanilla OS X 10.7 > install does not provide), but also certain library headers (which > e.g. on Debian would be in those "dev"-packages), and the like. I'm > not sure whether there is any solution for that available yet. (Both > MacPorts and Gentoo Prefix seem to require XCode at least for > bootstrapping themselves.) However, we would only distribute a binary (most likely based upon MacPorts or Gentoo Prefix) installer, so the bootstrapping process should not be required from a users perspective (the only thing that I'm not so sure about is libc). > Especially when interfacing with Cocoa/graphics is concerned (Python > itself does this, matplotlib, R, i.e. several non-trivial components > of Sage), the respective headers are needed, and it may very well be > that only XCode provides these in a "neatly downloadable" way (those > "SDKs"). > One could patch all these parts out of Sage (they are "OS X only" > parts, after all, so Sage runs certainly without). I did that once to > get Sage building in 64bit on OS X 10.4 (for which those Cocoa parts > are supported only in 32bit), so it is definitely possible --- but > it's not some "minor" effort to get this ready for "prime-time" > mainline Sage releases, as you certainy want "plot" to show something > (maybe we would need Qt, or another alternative to Cocoa/Aqua > graphics)! > > I'd modestly suggest staying with the requirement of XCode for > building Sage from source on OS X (merely using Sage, and doing Sage > library development, is something different, though). -1 if feasible Building sage from source is part of sage development, adding XCode as a requirement will add a cost barrier (although minimal) to sage development on OSX. > > > Cheers, > Georg > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this
Re: [sage-devel] Re: webgl
On Fri, Jan 27, 2012 at 1:10 AM, mmarco wrote: > I have just tested on chromium and firefor under linux. It does work > on both (but i have the impression that performance is better in > chromium). Strangely, it does work on the version of firefox that i > have compiled in my computer, but it doesn't in the binary version > from the firefox site. I guess that there is some compile option that > is disabled in the binary package. Hi, I just looked at WebGL and other options for a while, and though WebGL is neat and "the future", etc., it is almost the farthest thing possible from "just working". It's the exact opposite of what I think the Sage notebook desperately needs (and which JMOL does *not* provide despite its promise), which is rock solid 3d graphics that just work everywhere (except Internet Explorer, where Sage barely works anyways). Of course, having WebGL support will be amazing for high-performance applications, e.g, as an alternative to VTK. But it doesn't work on my cell phone. I had hoped that Bill Cauchois's canvas3d rendered (that is in Sage) would fill this void, but it is still a very basic wireframe renderer, and isn't very useful in practice. At least it works on everything that supports HTML5 canvas 2d. I found another newer 3d library called Pre3d [1]. This is a 3d javascript library that uses HTML5 canvas 2d, which is the same thing that Rado's graph editor uses (and Cauchois's library), and works on iphones, android tablets, firefox, chrome, safari, etc.It does hidden surface removal and transparency. Having looked through the code, I think a library based on Pre3d could be the best *default* for 3d graphics for Sage. It obviously doesn't look as good as jmol, but it is very lightweight, uses little memory, loads quickly, doesn't crash, works on my phone, etc. It will have to be extended to do what we want, e.g., it does not currently support text, but that should be easy given that canvas2d has excellent text support. [1] http://deanm.github.com/pre3d/ Any thoughts? We would also have to write javascript code that could parse a 3d scene described using some JSON representation, draw the scene, etc. It would also be critical to add some sort of selector support to pre3d (which has none). At least manipulating the scene is straightforward javascript, so it should be easier to integrate more tightly with Sage than JMOL is. -- William > On 27 ene, 00:41, Volker Braun wrote: >> On Thursday, January 26, 2012 2:14:36 PM UTC-8, William wrote: >> >> > [1] If you're using Chrome, check out >> >http://www.chromeexperiments.com/webgl >> >> Unless you use Linux, where chrome doesn't support webgl despite what the >> documentation says. Works in Firefox, though. >> >> > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] PyCox: Computing with (finite) Coxeter groups and Iwahori-Hecke algebras
On Fri, Jan 27, 2012 at 1:21 AM, davidp wrote:
> I just noticed this post to the arXiv. Is Meinholf Geck in touch with
> Sage?
>
> --Dave
I'm not sure, but he mentions Sage numerous times on page 1, and
suggests Sage was the inspiration for him writing the code in Python.
Also, he explains how to use his package within Sage.
>
> Title: PyCox: Computing with (finite) Coxeter groups and Iwahori-Hecke
> algebras
> Authors: Meinolf Geck
> Categories: math.RT
> Comments: 31 pages
> MSC-class: 20C40, 20C08
> \\
> We introduce the computer algebra package {\sf PyCox}, written
> entirely in
> the {\sf Python} language. It implements a set of algorithms - in a
> spirit
> similar to the older {\sf CHEVIE} system - for working with Coxeter
> groups and
> Hecke algebras. This includes a new variation of the traditional
> algorithm for
> computing Kazhdan-Lusztig cells and $W$-graphs, which works
> efficiently for all
> groups of rank $\leq 8$ (except $E_8$). Our experiments suggest a re-
> definition
> of Lusztig's "special" representations which, conjecturally, should
> also apply
> to the unequal parameter case.
> \\ ( http://arxiv.org/abs/1201.5566 , 39kb)
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Unifying Command line options
So I've been looking into restarting ticket #21 now that we have
argparse in python 2.7. The basic premise of the ticket was to make
our command line options use a standard library, however, since it was
opened (a long time ago), the command line options have become an
incredibly cluttered mess as more and more functionality has been
added. To that end, I think we should discuss some sort of uniform
design to command line options. Looking through what sorts of
arguments we already have, and playing around with argparse, I
personally came to the conclusion that sage would do well with
subcommand/subparsers (like mecurial, git, apt-get, aptitude, ...).
Some examples:
% sage ARGS # this would be for running sage scripts, or a couple of
oddball arguments
% sage notebook ARGS
% sage pkg ARGS # this would include spkg stuff
% sage pkg install # since install has some special flags like -f or -s
% sage test ARGS
% sage build ARGS
% sage {python,maxima,R,gp,...} ARGS # we can consider these programs
as subcommands of sage
Obviously, this is a fairly significant departure from the current set
command line options, and I'm not convinced this is necessarily the
best way to handle them (I don't necessarily see how to add in
debugging options), which is why I'm bringing this up as more of a
brainstorm rather than any sort of vote (that may be a future thread,
depending on the fallout of this one).
So as far as feedback I would like
1) If you think the above is the general direction we should go, any
thoughts on how it could be improved, and why (also, a +1 wouldn't
hurt, if you don't have any suggestions)
2) If you don't like the direction of above, but have some other idea
of how we could go about it, and why
3) You don't think we should make any effort to clean up command line
options, and why
For 3, I'm well aware that current users would need to relearn command
line options (which is the main argument I see for that perspective),
but ideally any new set of commands should be intuitive, and easy to
learn (plus we have the deprecation period for a reason). If you think
this is a more serious issue than I am making it out to be, please let
me know (and "I don't want to relearn the command line" does not make
a serious issue).
--
Andrew
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
Come over to Padelford: Robert and I are working on something like this. :-)
David
On Fri, Jan 27, 2012 at 02:04, R. Andrew Ohana wrote:
> So I've been looking into restarting ticket #21 now that we have
> argparse in python 2.7. The basic premise of the ticket was to make
> our command line options use a standard library, however, since it was
> opened (a long time ago), the command line options have become an
> incredibly cluttered mess as more and more functionality has been
> added. To that end, I think we should discuss some sort of uniform
> design to command line options. Looking through what sorts of
> arguments we already have, and playing around with argparse, I
> personally came to the conclusion that sage would do well with
> subcommand/subparsers (like mecurial, git, apt-get, aptitude, ...).
> Some examples:
>
> % sage ARGS # this would be for running sage scripts, or a couple of
> oddball arguments
> % sage notebook ARGS
> % sage pkg ARGS # this would include spkg stuff
> % sage pkg install # since install has some special flags like -f or -s
> % sage test ARGS
> % sage build ARGS
> % sage {python,maxima,R,gp,...} ARGS # we can consider these programs
> as subcommands of sage
>
> Obviously, this is a fairly significant departure from the current set
> command line options, and I'm not convinced this is necessarily the
> best way to handle them (I don't necessarily see how to add in
> debugging options), which is why I'm bringing this up as more of a
> brainstorm rather than any sort of vote (that may be a future thread,
> depending on the fallout of this one).
>
> So as far as feedback I would like
>
> 1) If you think the above is the general direction we should go, any
> thoughts on how it could be improved, and why (also, a +1 wouldn't
> hurt, if you don't have any suggestions)
> 2) If you don't like the direction of above, but have some other idea
> of how we could go about it, and why
> 3) You don't think we should make any effort to clean up command line
> options, and why
>
> For 3, I'm well aware that current users would need to relearn command
> line options (which is the main argument I see for that perspective),
> but ideally any new set of commands should be intuitive, and easy to
> learn (plus we have the deprecation period for a reason). If you think
> this is a more serious issue than I am making it out to be, please let
> me know (and "I don't want to relearn the command line" does not make
> a serious issue).
>
> --
> Andrew
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: Unifying Command line options
P.S. Link to the ticket http://trac.sagemath.org/sage_trac/ticket/21
(although most of what is there is old to very old).
On Fri, Jan 27, 2012 at 02:04, R. Andrew Ohana wrote:
> So I've been looking into restarting ticket #21 now that we have
> argparse in python 2.7. The basic premise of the ticket was to make
> our command line options use a standard library, however, since it was
> opened (a long time ago), the command line options have become an
> incredibly cluttered mess as more and more functionality has been
> added. To that end, I think we should discuss some sort of uniform
> design to command line options. Looking through what sorts of
> arguments we already have, and playing around with argparse, I
> personally came to the conclusion that sage would do well with
> subcommand/subparsers (like mecurial, git, apt-get, aptitude, ...).
> Some examples:
>
> % sage ARGS # this would be for running sage scripts, or a couple of
> oddball arguments
> % sage notebook ARGS
> % sage pkg ARGS # this would include spkg stuff
> % sage pkg install # since install has some special flags like -f or -s
> % sage test ARGS
> % sage build ARGS
> % sage {python,maxima,R,gp,...} ARGS # we can consider these programs
> as subcommands of sage
>
> Obviously, this is a fairly significant departure from the current set
> command line options, and I'm not convinced this is necessarily the
> best way to handle them (I don't necessarily see how to add in
> debugging options), which is why I'm bringing this up as more of a
> brainstorm rather than any sort of vote (that may be a future thread,
> depending on the fallout of this one).
>
> So as far as feedback I would like
>
> 1) If you think the above is the general direction we should go, any
> thoughts on how it could be improved, and why (also, a +1 wouldn't
> hurt, if you don't have any suggestions)
> 2) If you don't like the direction of above, but have some other idea
> of how we could go about it, and why
> 3) You don't think we should make any effort to clean up command line
> options, and why
>
> For 3, I'm well aware that current users would need to relearn command
> line options (which is the main argument I see for that perspective),
> but ideally any new set of commands should be intuitive, and easy to
> learn (plus we have the deprecation period for a reason). If you think
> this is a more serious issue than I am making it out to be, please let
> me know (and "I don't want to relearn the command line" does not make
> a serious issue).
>
> --
> Andrew
--
Andrew
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
I'm +1 to making sweeping changes to argument syntax & parsing in sage-5.0
or sage-6.0.
On Friday, January 27, 2012, R. Andrew Ohana wrote:
> So I've been looking into restarting ticket #21 now that we have
> argparse in python 2.7. The basic premise of the ticket was to make
> our command line options use a standard library, however, since it was
> opened (a long time ago), the command line options have become an
> incredibly cluttered mess as more and more functionality has been
> added. To that end, I think we should discuss some sort of uniform
> design to command line options. Looking through what sorts of
> arguments we already have, and playing around with argparse, I
> personally came to the conclusion that sage would do well with
> subcommand/subparsers (like mecurial, git, apt-get, aptitude, ...).
> Some examples:
>
> % sage ARGS # this would be for running sage scripts, or a couple of
> oddball arguments
> % sage notebook ARGS
> % sage pkg ARGS # this would include spkg stuff
> % sage pkg install # since install has some special flags like -f or -s
> % sage test ARGS
> % sage build ARGS
> % sage {python,maxima,R,gp,...} ARGS # we can consider these programs
> as subcommands of sage
>
> Obviously, this is a fairly significant departure from the current set
> command line options, and I'm not convinced this is necessarily the
> best way to handle them (I don't necessarily see how to add in
> debugging options), which is why I'm bringing this up as more of a
> brainstorm rather than any sort of vote (that may be a future thread,
> depending on the fallout of this one).
>
> So as far as feedback I would like
>
> 1) If you think the above is the general direction we should go, any
> thoughts on how it could be improved, and why (also, a +1 wouldn't
> hurt, if you don't have any suggestions)
> 2) If you don't like the direction of above, but have some other idea
> of how we could go about it, and why
> 3) You don't think we should make any effort to clean up command line
> options, and why
>
> For 3, I'm well aware that current users would need to relearn command
> line options (which is the main argument I see for that perspective),
> but ideally any new set of commands should be intuitive, and easy to
> learn (plus we have the deprecation period for a reason). If you think
> this is a more serious issue than I am making it out to be, please let
> me know (and "I don't want to relearn the command line" does not make
> a serious issue).
>
> --
> Andrew
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at
http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] PyCox: Computing with (finite) Coxeter groups and Iwahori-Hecke algebras
On Fri, Jan 27, 2012 at 01:21:05AM -0800, davidp wrote: > I just noticed this post to the arXiv. Is Meinholf Geck in touch with > Sage? Yes! We had invited him two years ago at Sage Days 20 in Marseille. He is invited again at the upcoming Sage-Combinat days in Montreal, precisely to discuss the integration of the code he wrote in the mean time. Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
On Friday, January 27, 2012, William Stein wrote:
> I'm +1 to making sweeping changes to argument syntax & parsing in
sage-5.0 or sage-6.0.
>
Though I don't want to loose any features... and have some respect for our
1-year deprecation policy.
> On Friday, January 27, 2012, R. Andrew Ohana
wrote:
>> So I've been looking into restarting ticket #21 now that we have
>> argparse in python 2.7. The basic premise of the ticket was to make
>> our command line options use a standard library, however, since it was
>> opened (a long time ago), the command line options have become an
>> incredibly cluttered mess as more and more functionality has been
>> added. To that end, I think we should discuss some sort of uniform
>> design to command line options. Looking through what sorts of
>> arguments we already have, and playing around with argparse, I
>> personally came to the conclusion that sage would do well with
>> subcommand/subparsers (like mecurial, git, apt-get, aptitude, ...).
>> Some examples:
>>
>> % sage ARGS # this would be for running sage scripts, or a couple of
>> oddball arguments
>> % sage notebook ARGS
>> % sage pkg ARGS # this would include spkg stuff
>> % sage pkg install # since install has some special flags like -f or -s
>> % sage test ARGS
>> % sage build ARGS
>> % sage {python,maxima,R,gp,...} ARGS # we can consider these programs
>> as subcommands of sage
>>
>> Obviously, this is a fairly significant departure from the current set
>> command line options, and I'm not convinced this is necessarily the
>> best way to handle them (I don't necessarily see how to add in
>> debugging options), which is why I'm bringing this up as more of a
>> brainstorm rather than any sort of vote (that may be a future thread,
>> depending on the fallout of this one).
>>
>> So as far as feedback I would like
>>
>> 1) If you think the above is the general direction we should go, any
>> thoughts on how it could be improved, and why (also, a +1 wouldn't
>> hurt, if you don't have any suggestions)
>> 2) If you don't like the direction of above, but have some other idea
>> of how we could go about it, and why
>> 3) You don't think we should make any effort to clean up command line
>> options, and why
>>
>> For 3, I'm well aware that current users would need to relearn command
>> line options (which is the main argument I see for that perspective),
>> but ideally any new set of commands should be intuitive, and easy to
>> learn (plus we have the deprecation period for a reason). If you think
>> this is a more serious issue than I am making it out to be, please let
>> me know (and "I don't want to relearn the command line" does not make
>> a serious issue).
>>
>> --
>> Andrew
>>
>> --
>> To post to this group, send an email to sage-devel@googlegroups.com
>> To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
>> For more options, visit this group at
http://groups.google.com/group/sage-devel
>> URL: http://www.sagemath.org
>>
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
>
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
On Fri, Jan 27, 2012 at 02:11, William Stein wrote:
>
>
> On Friday, January 27, 2012, William Stein wrote:
>> I'm +1 to making sweeping changes to argument syntax & parsing in sage-5.0
>> or sage-6.0.
>>
>
> Though I don't want to loose any features... and have some respect for our
> 1-year deprecation policy.
+1
The hard part with what I propose are the optional subparsers
(something that isn't currently in argparse, but has a ticket), and
multiple subparsers (to build then test). Hopefully whatever we
implement can be pushed upstream.
>
>
>> On Friday, January 27, 2012, R. Andrew Ohana
>> wrote:
>>> So I've been looking into restarting ticket #21 now that we have
>>> argparse in python 2.7. The basic premise of the ticket was to make
>>> our command line options use a standard library, however, since it was
>>> opened (a long time ago), the command line options have become an
>>> incredibly cluttered mess as more and more functionality has been
>>> added. To that end, I think we should discuss some sort of uniform
>>> design to command line options. Looking through what sorts of
>>> arguments we already have, and playing around with argparse, I
>>> personally came to the conclusion that sage would do well with
>>> subcommand/subparsers (like mecurial, git, apt-get, aptitude, ...).
>>> Some examples:
>>>
>>> % sage ARGS # this would be for running sage scripts, or a couple of
>>> oddball arguments
>>> % sage notebook ARGS
>>> % sage pkg ARGS # this would include spkg stuff
>>> % sage pkg install # since install has some special flags like -f or -s
>>> % sage test ARGS
>>> % sage build ARGS
>>> % sage {python,maxima,R,gp,...} ARGS # we can consider these programs
>>> as subcommands of sage
>>>
>>> Obviously, this is a fairly significant departure from the current set
>>> command line options, and I'm not convinced this is necessarily the
>>> best way to handle them (I don't necessarily see how to add in
>>> debugging options), which is why I'm bringing this up as more of a
>>> brainstorm rather than any sort of vote (that may be a future thread,
>>> depending on the fallout of this one).
>>>
>>> So as far as feedback I would like
>>>
>>> 1) If you think the above is the general direction we should go, any
>>> thoughts on how it could be improved, and why (also, a +1 wouldn't
>>> hurt, if you don't have any suggestions)
>>> 2) If you don't like the direction of above, but have some other idea
>>> of how we could go about it, and why
>>> 3) You don't think we should make any effort to clean up command line
>>> options, and why
>>>
>>> For 3, I'm well aware that current users would need to relearn command
>>> line options (which is the main argument I see for that perspective),
>>> but ideally any new set of commands should be intuitive, and easy to
>>> learn (plus we have the deprecation period for a reason). If you think
>>> this is a more serious issue than I am making it out to be, please let
>>> me know (and "I don't want to relearn the command line" does not make
>>> a serious issue).
>>>
>>> --
>>> Andrew
>>>
>>> --
>>> To post to this group, send an email to sage-devel@googlegroups.com
>>> To unsubscribe from this group, send an email to
>>> sage-devel+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/sage-devel
>>> URL: http://www.sagemath.org
>>>
>>
>> --
>> William Stein
>> Professor of Mathematics
>> University of Washington
>> http://wstein.org
>>
>>
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
--
Andrew
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
On 2012-01-27 11:04, R. Andrew Ohana wrote: > So I've been looking into restarting ticket #21 now that we have > argparse in python 2.7. -1 to making Python a requirement to run $SAGE_ROOT/sage. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
Why? So that things like sage -i can work without python? David On Fri, Jan 27, 2012 at 02:15, Jeroen Demeyer wrote: > On 2012-01-27 11:04, R. Andrew Ohana wrote: >> So I've been looking into restarting ticket #21 now that we have >> argparse in python 2.7. > -1 to making Python a requirement to run $SAGE_ROOT/sage. > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
On 2012-01-27 11:17, David Roe wrote: > Why? So that things like sage -i can work without python? Exactly. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
On Fri, Jan 27, 2012 at 02:17, David Roe wrote: > Why? So that things like sage -i can work without python? > David Which is a valid, given that we can do that now before building sage. > > On Fri, Jan 27, 2012 at 02:15, Jeroen Demeyer wrote: >> On 2012-01-27 11:04, R. Andrew Ohana wrote: >>> So I've been looking into restarting ticket #21 now that we have >>> argparse in python 2.7. >> -1 to making Python a requirement to run $SAGE_ROOT/sage. >> >> -- >> To post to this group, send an email to sage-devel@googlegroups.com >> To unsubscribe from this group, send an email to >> sage-devel+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/sage-devel >> URL: http://www.sagemath.org > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- Andrew -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
On Fri, Jan 27, 2012 at 02:07, David Roe wrote:
> Come over to Padelford: Robert and I are working on something like this. :-)
Is it at all similar to what I proposed? If not, please share :)
> David
>
> On Fri, Jan 27, 2012 at 02:04, R. Andrew Ohana wrote:
>> So I've been looking into restarting ticket #21 now that we have
>> argparse in python 2.7. The basic premise of the ticket was to make
>> our command line options use a standard library, however, since it was
>> opened (a long time ago), the command line options have become an
>> incredibly cluttered mess as more and more functionality has been
>> added. To that end, I think we should discuss some sort of uniform
>> design to command line options. Looking through what sorts of
>> arguments we already have, and playing around with argparse, I
>> personally came to the conclusion that sage would do well with
>> subcommand/subparsers (like mecurial, git, apt-get, aptitude, ...).
>> Some examples:
>>
>> % sage ARGS # this would be for running sage scripts, or a couple of
>> oddball arguments
>> % sage notebook ARGS
>> % sage pkg ARGS # this would include spkg stuff
>> % sage pkg install # since install has some special flags like -f or -s
>> % sage test ARGS
>> % sage build ARGS
>> % sage {python,maxima,R,gp,...} ARGS # we can consider these programs
>> as subcommands of sage
>>
>> Obviously, this is a fairly significant departure from the current set
>> command line options, and I'm not convinced this is necessarily the
>> best way to handle them (I don't necessarily see how to add in
>> debugging options), which is why I'm bringing this up as more of a
>> brainstorm rather than any sort of vote (that may be a future thread,
>> depending on the fallout of this one).
>>
>> So as far as feedback I would like
>>
>> 1) If you think the above is the general direction we should go, any
>> thoughts on how it could be improved, and why (also, a +1 wouldn't
>> hurt, if you don't have any suggestions)
>> 2) If you don't like the direction of above, but have some other idea
>> of how we could go about it, and why
>> 3) You don't think we should make any effort to clean up command line
>> options, and why
>>
>> For 3, I'm well aware that current users would need to relearn command
>> line options (which is the main argument I see for that perspective),
>> but ideally any new set of commands should be intuitive, and easy to
>> learn (plus we have the deprecation period for a reason). If you think
>> this is a more serious issue than I am making it out to be, please let
>> me know (and "I don't want to relearn the command line" does not make
>> a serious issue).
>>
>> --
>> Andrew
>>
>> --
>> To post to this group, send an email to sage-devel@googlegroups.com
>> To unsubscribe from this group, send an email to
>> sage-devel+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/sage-devel
>> URL: http://www.sagemath.org
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
--
Andrew
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
We could bake into $SAGE_ROOT/sage (a shell script) the functionality to launch anything someone with an unbuilt copy of Sage would need (such as release management utilities or whatever you have in mind), which should be a pretty small subset of Sage's full functionality (right?). And then $SAGE_LOCAL/sage-sage can be a Python script. Just a thought. (Incidentally, why does $SAGE_LOCAL point to $SAGE_ROOT/local/bin and not $SAGE_ROOT/local as the name would suggest?) -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
We're working on rewriting the doctest framework only. So we're still
just sticking to hyphens, but are making them UNIX-compliant: --gdb
instead of -gdb for example. My first impression of your proposal is
that I like it, though there are some ambiguities in the syntax: in
mercurial the subcommand is required, whereas in sage we would also
want to allow "sage ARGS". So you have to be careful what you mean by
"sage test": are you running sage on a file called test, or are you
running the subcommand test with no arguments.
I think that we can separate out the functionality which should be
available before building python (sage -i for example). Overall I
think using python for the majority of sage's option parsing is a good
idea.
David
On Fri, Jan 27, 2012 at 02:20, R. Andrew Ohana wrote:
> On Fri, Jan 27, 2012 at 02:07, David Roe wrote:
>> Come over to Padelford: Robert and I are working on something like this. :-)
>
> Is it at all similar to what I proposed? If not, please share :)
>
>> David
>>
>> On Fri, Jan 27, 2012 at 02:04, R. Andrew Ohana
>> wrote:
>>> So I've been looking into restarting ticket #21 now that we have
>>> argparse in python 2.7. The basic premise of the ticket was to make
>>> our command line options use a standard library, however, since it was
>>> opened (a long time ago), the command line options have become an
>>> incredibly cluttered mess as more and more functionality has been
>>> added. To that end, I think we should discuss some sort of uniform
>>> design to command line options. Looking through what sorts of
>>> arguments we already have, and playing around with argparse, I
>>> personally came to the conclusion that sage would do well with
>>> subcommand/subparsers (like mecurial, git, apt-get, aptitude, ...).
>>> Some examples:
>>>
>>> % sage ARGS # this would be for running sage scripts, or a couple of
>>> oddball arguments
>>> % sage notebook ARGS
>>> % sage pkg ARGS # this would include spkg stuff
>>> % sage pkg install # since install has some special flags like -f or -s
>>> % sage test ARGS
>>> % sage build ARGS
>>> % sage {python,maxima,R,gp,...} ARGS # we can consider these programs
>>> as subcommands of sage
>>>
>>> Obviously, this is a fairly significant departure from the current set
>>> command line options, and I'm not convinced this is necessarily the
>>> best way to handle them (I don't necessarily see how to add in
>>> debugging options), which is why I'm bringing this up as more of a
>>> brainstorm rather than any sort of vote (that may be a future thread,
>>> depending on the fallout of this one).
>>>
>>> So as far as feedback I would like
>>>
>>> 1) If you think the above is the general direction we should go, any
>>> thoughts on how it could be improved, and why (also, a +1 wouldn't
>>> hurt, if you don't have any suggestions)
>>> 2) If you don't like the direction of above, but have some other idea
>>> of how we could go about it, and why
>>> 3) You don't think we should make any effort to clean up command line
>>> options, and why
>>>
>>> For 3, I'm well aware that current users would need to relearn command
>>> line options (which is the main argument I see for that perspective),
>>> but ideally any new set of commands should be intuitive, and easy to
>>> learn (plus we have the deprecation period for a reason). If you think
>>> this is a more serious issue than I am making it out to be, please let
>>> me know (and "I don't want to relearn the command line" does not make
>>> a serious issue).
>>>
>>> --
>>> Andrew
>>>
>>> --
>>> To post to this group, send an email to sage-devel@googlegroups.com
>>> To unsubscribe from this group, send an email to
>>> sage-devel+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/sage-devel
>>> URL: http://www.sagemath.org
>>
>> --
>> To post to this group, send an email to sage-devel@googlegroups.com
>> To unsubscribe from this group, send an email to
>> sage-devel+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/sage-devel
>> URL: http://www.sagemath.org
>
>
>
> --
> Andrew
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
If we keep $SAGE_ROOT/sage as a shell script that calls the python script $SAGE_ROOT/local/bin/sage-sage, we could work around the optional subparsers issue in $SAGE_ROOT/sage itself, i.e. insert an argument "--" if $1 is not in the list of sage-sage subparsers hardcoded into $SAGE_ROOT/sage . In any case, we should eventually accept, say, "sage -- python" to mean "run the sage script called 'python'", as a form of escaping. -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
On Friday, January 27, 2012, Keshav Kini wrote: > We could bake into $SAGE_ROOT/sage (a shell script) the functionality to launch anything someone with an unbuilt copy of Sage would need (such as release management utilities or whatever you have in mind), which should be a pretty small subset of Sage's full functionality (right?). And then $SAGE_LOCAL/sage-sage can be a Python script. Just a thought. > > (Incidentally, why does $SAGE_LOCAL point to $SAGE_ROOT/local/bin and not $SAGE_ROOT/local as the name would suggest?) > It does point to $SAGE_ROOT/local. > -Keshav > > > Join us in #sagemath on irc.freenode.net ! > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
On Fri, Jan 27, 2012 at 18:28, William Stein wrote: >> (Incidentally, why does $SAGE_LOCAL point to $SAGE_ROOT/local/bin and not >> $SAGE_ROOT/local as the name would suggest?) >> > > It does point to $SAGE_ROOT/local. Oops, why did I think it didn't? Sorry for the noise. (I'll keep that in mind when writing about where to apply patches on trac tickets...) -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
On Fri, Jan 27, 2012 at 18:26, David Roe wrote: > We're working on rewriting the doctest framework only. So we're still > just sticking to hyphens, but are making them UNIX-compliant: --gdb > instead of -gdb for example. My first impression of your proposal is > that I like it, though there are some ambiguities in the syntax: in > mercurial the subcommand is required, whereas in sage we would also > want to allow "sage ARGS". So you have to be careful what you mean by > "sage test": are you running sage on a file called test, or are you > running the subcommand test with no arguments. I mentioned this elsewhere in the thread, but I think we can use "--" as an escaper of sorts. (git does this, for example). So `sage test` would run the subcommand "test" with no arguments, and `sage -- test` would run a sage script in a file called "test". -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Please someone upgrade sagenb so it has R graphics support
William did this, apparently. https://groups.google.com/d/msg/sage-devel/2aANS7hEdMQ/E7WiRKN5Q4EJ -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
On Fri, Jan 27, 2012 at 02:26, David Roe wrote:
> We're working on rewriting the doctest framework only. So we're still
> just sticking to hyphens, but are making them UNIX-compliant: --gdb
> instead of -gdb for example. My first impression of your proposal is
> that I like it, though there are some ambiguities in the syntax: in
> mercurial the subcommand is required, whereas in sage we would also
> want to allow "sage ARGS". So you have to be careful what you mean by
> "sage test": are you running sage on a file called test, or are you
> running the subcommand test with no arguments.
This was actually brought up in the python ticket to add optional
subparsers to argparse [1], however it is not completely unheard of, I
know at least aptitude does this.
Maybe I should have put "sage OPTIONS", since I envision that all
commands that don't use a subparser to not need any arguments (like
--help, --root, etc.), so there would be no ambiguity since those
would only start with dashes. The only exeption to this rule would be
sage scripts, which would occur if you wanted to run a script simply
title say 'test' or 'build' or 'python', but you shouldn't be doing
that anyway since the script should have a suffix.
>
> I think that we can separate out the functionality which should be
> available before building python (sage -i for example). Overall I
> think using python for the majority of sage's option parsing is a good
> idea.
> David
>
> On Fri, Jan 27, 2012 at 02:20, R. Andrew Ohana wrote:
>> On Fri, Jan 27, 2012 at 02:07, David Roe wrote:
>>> Come over to Padelford: Robert and I are working on something like this.
>>> :-)
>>
>> Is it at all similar to what I proposed? If not, please share :)
>>
>>> David
>>>
>>> On Fri, Jan 27, 2012 at 02:04, R. Andrew Ohana
>>> wrote:
So I've been looking into restarting ticket #21 now that we have
argparse in python 2.7. The basic premise of the ticket was to make
our command line options use a standard library, however, since it was
opened (a long time ago), the command line options have become an
incredibly cluttered mess as more and more functionality has been
added. To that end, I think we should discuss some sort of uniform
design to command line options. Looking through what sorts of
arguments we already have, and playing around with argparse, I
personally came to the conclusion that sage would do well with
subcommand/subparsers (like mecurial, git, apt-get, aptitude, ...).
Some examples:
% sage ARGS # this would be for running sage scripts, or a couple of
oddball arguments
% sage notebook ARGS
% sage pkg ARGS # this would include spkg stuff
% sage pkg install # since install has some special flags like -f or -s
% sage test ARGS
% sage build ARGS
% sage {python,maxima,R,gp,...} ARGS # we can consider these programs
as subcommands of sage
Obviously, this is a fairly significant departure from the current set
command line options, and I'm not convinced this is necessarily the
best way to handle them (I don't necessarily see how to add in
debugging options), which is why I'm bringing this up as more of a
brainstorm rather than any sort of vote (that may be a future thread,
depending on the fallout of this one).
So as far as feedback I would like
1) If you think the above is the general direction we should go, any
thoughts on how it could be improved, and why (also, a +1 wouldn't
hurt, if you don't have any suggestions)
2) If you don't like the direction of above, but have some other idea
of how we could go about it, and why
3) You don't think we should make any effort to clean up command line
options, and why
For 3, I'm well aware that current users would need to relearn command
line options (which is the main argument I see for that perspective),
but ideally any new set of commands should be intuitive, and easy to
learn (plus we have the deprecation period for a reason). If you think
this is a more serious issue than I am making it out to be, please let
me know (and "I don't want to relearn the command line" does not make
a serious issue).
--
Andrew
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
>>>
>>> --
>>> To post to this group, send an email to sage-devel@googlegroups.com
>>> To unsubscribe from this group, send an email to
>>> sage-devel+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/sage-devel
>>> URL: http://www.sagemath.org
>>
>>
>>
>> --
>> Andrew
>>
>> --
>> To post to this group, send an e
Re: [sage-devel] Unifying Command line options
On Fri, Jan 27, 2012 at 02:32, Keshav Kini wrote: > On Fri, Jan 27, 2012 at 18:26, David Roe wrote: >> We're working on rewriting the doctest framework only. So we're still >> just sticking to hyphens, but are making them UNIX-compliant: --gdb >> instead of -gdb for example. My first impression of your proposal is >> that I like it, though there are some ambiguities in the syntax: in >> mercurial the subcommand is required, whereas in sage we would also >> want to allow "sage ARGS". So you have to be careful what you mean by >> "sage test": are you running sage on a file called test, or are you >> running the subcommand test with no arguments. > > I mentioned this elsewhere in the thread, but I think we can use "--" > as an escaper of sorts. (git does this, for example). So `sage test` > would run the subcommand "test" with no arguments, and `sage -- test` > would run a sage script in a file called "test". I don't mind this, I don't really like it, but I think it is a fair solution. > > -Keshav > > > Join us in #sagemath on irc.freenode.net ! > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- Andrew -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
On Jan 27, 2012, at 11:32 AM, Keshav Kini wrote: > On Fri, Jan 27, 2012 at 18:26, David Roe wrote: >> We're working on rewriting the doctest framework only. So we're still >> just sticking to hyphens, but are making them UNIX-compliant: --gdb >> instead of -gdb for example. My first impression of your proposal is >> that I like it, though there are some ambiguities in the syntax: in >> mercurial the subcommand is required, whereas in sage we would also >> want to allow "sage ARGS". So you have to be careful what you mean by >> "sage test": are you running sage on a file called test, or are you >> running the subcommand test with no arguments. > > I mentioned this elsewhere in the thread, but I think we can use "--" > as an escaper of sorts. (git does this, for example). So `sage test` > would run the subcommand "test" with no arguments, and `sage -- test` > would run a sage script in a file called "test". This is a standard part of the getopt C library which I imagine python uses, or at least mimics. It is something that should be mentioned in the documentation though for people who aren't familiar with it. I'm a big fan of the subcommand syntax and using standard option parsing, so I give the proposal a +1, though I think that we need to support the old syntax for a while. There are almost certainly scripts that will have to support both old and new versions during a transition period. I'm thinking in particular of the Mac app which has some scripts and would otherwise lose the ability to run old versions of Sage. Also, the last time we talked about this people wanted to keep some commands out of python since it made things slower. IIRC it was commands like --gap and --gp that start interactive shells. I don't know if feelings have changed since then. -Ivan -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
On 2012-01-27 11:23, Keshav Kini wrote: > We could bake into $SAGE_ROOT/sage (a shell script) the functionality to > launch anything someone with an unbuilt copy of Sage would need (such as > release management utilities or whatever you have in mind), which should > be a pretty small subset of Sage's full functionality (right?). And then > $SAGE_LOCAL/sage-sage can be a Python script. Just a thought. Note that #11073 moved $SAGE_LOCAL/bin/sage-sage to $SAGE_ROOT/spkg/bin/sage, such that it is available right after downloading Sage, without needing to install sage_scripts. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
Le 26/01/2012 10:53, Dima Pasechnik a écrit : Is the popcount() there even big-endian/little-endian safe? It's not obvious. As well, it will blow on architectures that have a different from x86 idea about the length of int... So one quick test would be to use __builtin_popcount(i) and see if it makes a difference... I stupidly ran "rm -rf sage-4.8" in the terminal which pointed to sage-4.8 full install thinking it was the terminal which pointed to sage-4.8 spkg sources, so I had to rebuild from scratch. Sigh. Anyway, I finally have sage-4.8 again on that box, and the result of using the builtin popcount is that it still doesn't work. Where do we go from that point on? Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: DYLD on Mac... again
On Jan 27, 12:31 am, "Justin C. Walker" wrote: > On Jan 26, 2012, at 20:00 , kcrisman wrote: > > > > > > > > > > > > > On Jan 26, 10:55 pm, kcrisman wrote: > >> My apologies if I have missed a reference to this elsewhere; it's late > >> and I didn't search as thoroughly as I might have, though I did > >> search. > > >> Found while reviewing #11977: > > >> sage: matrix_plot(matrix(2,[1,2,3,4])) > >> dyld: Library not loaded: /usr/X11/lib/libfreetype.6.dylib > >> Referenced from: /usr/X11/bin/fc-list > >> Reason: Incompatible library version: fc-list requires version > >> 13.0.0 or later, but libfreetype.6.dylib provides version 10.0.0 > >> dyld: Library not loaded: /usr/X11/lib/libfreetype.6.dylib > >> Referenced from: /usr/X11/bin/fc-list > >> Reason: Incompatible library version: fc-list requires version > >> 13.0.0 or later, but libfreetype.6.dylib provides version 10.0.0 > > > Could be older. I only got it the *first* time; even restarting Sage > > didn't cause it to happen again. Sorry if this is noise. ? > > FWIW, I just tried this on 10.6.8/Intel, where > /usr/X11/lib/libfreetype.6.dylib exists. I had no problems reported, and did > get a "plot" shown (in Preview). Yup, same platform for me. I'm just reporting this bizarre error, which I only saw this one time, and seemed related to other threads where DYLD... was set. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
Hell !! > Anyway, I finally have sage-4.8 again on that box, and the result of using > the builtin popcount is that it still doesn't work. > > Where do we go from that point on? Hmmm O_o Well, I read the code again and the only weird thing I was able to find was that : the function find_order defined in vertex_separation.pyx should have a "cdef int next_set" somewhere, otherwise the variable is considered as a Python variable. Well, it is bad from a performance point of view, and perhaps it could also make a difference there... Could you try adding this cdef int next_set at the beginning of the function, just to check ? O_o Nathann -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
On Fri, Jan 27, 2012 at 02:05:25PM +0100, Julien Puydt wrote: > Le 26/01/2012 10:53, Dima Pasechnik a écrit : > >Is the popcount() there even big-endian/little-endian safe? > >It's not obvious. As well, it will blow on architectures that have > >a different from x86 idea about the length of int... > >So one quick test would be to use __builtin_popcount(i) and see if it > >makes a difference... > > I stupidly ran "rm -rf sage-4.8" in the terminal which pointed to > sage-4.8 full install thinking it was the terminal which pointed to > sage-4.8 spkg sources, so I had to rebuild from scratch. Sigh. > > Anyway, I finally have sage-4.8 again on that box, and the result of > using the builtin popcount is that it still doesn't work. > > Where do we go from that point on? Is char signed or unsigned on your platform? If unsigned, vertex_separation.pyx will have some problems. Does the compiler show any warnings when compiling this file, by the way? -Willem Jan -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
Le 27/01/2012 16:25, Nathann Cohen a écrit : Hell !! Anyway, I finally have sage-4.8 again on that box, and the result of using the builtin popcount is that it still doesn't work. Where do we go from that point on? Hmmm O_o Well, I read the code again and the only weird thing I was able to find was that : the function find_order defined in vertex_separation.pyx should have a "cdef int next_set" somewhere, otherwise the variable is considered as a Python variable. Well, it is bad from a performance point of view, and perhaps it could also make a difference there... Could you try adding this cdef int next_set at the beginning of the function, just to check ? O_o I added it, and the problem is still there. Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
Le 27/01/2012 16:52, Willem Jan Palenstijn a écrit : On Fri, Jan 27, 2012 at 02:05:25PM +0100, Julien Puydt wrote: Le 26/01/2012 10:53, Dima Pasechnik a écrit : Is the popcount() there even big-endian/little-endian safe? It's not obvious. As well, it will blow on architectures that have a different from x86 idea about the length of int... So one quick test would be to use __builtin_popcount(i) and see if it makes a difference... I stupidly ran "rm -rf sage-4.8" in the terminal which pointed to sage-4.8 full install thinking it was the terminal which pointed to sage-4.8 spkg sources, so I had to rebuild from scratch. Sigh. Anyway, I finally have sage-4.8 again on that box, and the result of using the builtin popcount is that it still doesn't work. Where do we go from that point on? Is char signed or unsigned on your platform? Good question ; how do I find out? If unsigned, vertex_separation.pyx will have some problems. Why? Does the compiler show any warnings when compiling this file, by the way? None. Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
Le 27/01/2012 17:02, Julien Puydt a écrit :
Le 27/01/2012 16:52, Willem Jan Palenstijn a écrit :
Is char signed or unsigned on your platform?
Good question ; how do I find out?
If I put the following in test.c :
#include
#include
int
main()
{
printf ("%d\n", CHAR_MIN);
return 0;
}
then compile and run it, I get 0 ; so I guess it's unsigned.
Snark on #sagemath
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
On Fri, Jan 27, 2012 at 05:07:56PM +0100, Julien Puydt wrote:
> Le 27/01/2012 17:02, Julien Puydt a écrit :
> >Le 27/01/2012 16:52, Willem Jan Palenstijn a écrit :
> >>Is char signed or unsigned on your platform?
> >
> >Good question ; how do I find out?
>
> If I put the following in test.c :
>
> #include
> #include
>
> int
> main()
> {
> printf ("%d\n", CHAR_MIN);
> return 0;
> }
>
>
> then compile and run it, I get 0 ; so I guess it's unsigned.
Indeed. That will mean that the initialization of neighborhoods to (char)-1
will have the effect that the check
if neighborhoods[current] < 0:
fails because (char)-1 is positive, which will no doubt cause the algorithm to
break completely.
-Willem Jan
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
Le 27/01/2012 17:14, Willem Jan Palenstijn a écrit :
On Fri, Jan 27, 2012 at 05:07:56PM +0100, Julien Puydt wrote:
Le 27/01/2012 17:02, Julien Puydt a écrit :
Le 27/01/2012 16:52, Willem Jan Palenstijn a écrit :
Is char signed or unsigned on your platform?
Good question ; how do I find out?
If I put the following in test.c :
#include
#include
int
main()
{
printf ("%d\n", CHAR_MIN);
return 0;
}
then compile and run it, I get 0 ; so I guess it's unsigned.
Indeed. That will mean that the initialization of neighborhoods to (char)-1
will have the effect that the check
if neighborhoods[current]< 0:
fails because (char)-1 is positive, which will no doubt cause the algorithm to
break completely.
I added a few "unsigned" keywords here and there and got the test right!
I'll open a ticket with a nice patch as soon as I'll have cleaned things
a little.
Thanks for the help!
Snark on #sagemath
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
Very interesting! Perhaps some other doctest failures on ARM are also related to unsigned char business? E.g. the pickling problem might be also due to this messing with bits -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
Wait... It means that on your platform the default "char" are unsigned ? O_o I'm almost scared right now O_O Nathann -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
Le 27/01/2012 18:00, Nathann Cohen a écrit : Wait... It means that on your platform the default "char" are unsigned ? O_o I'm almost scared right now O_O You'll be happy to learn (eh, I just learnt it this very afternoon) that the C standards says that char can be either "unsigned char" or "signed char"... so if you want to be safe, just use the most precise form. Here is the ticket with the promised patch and a few remarks : http://trac.sagemath.org/sage_trac/ticket/12371 Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
Le 27/01/2012 17:56, Dima Pasechnik a écrit : Perhaps some other doctest failures on ARM are also related to unsigned char business? E.g. the pickling problem might be also due to this messing with bits I'll get to this pickling problem sooner or later ; I've known it to be there ever since my first successful compilation... but never found the time to dig the matter. Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
>> I'm almost scared right now O_O > > You'll be happy to learn (eh, I just learnt it this very afternoon) that the > C standards says that char can be either "unsigned char" or "signed char"... > so if you want to be safe, just use the most precise form. Ok now I'm scared O_O;;; > Here is the ticket with the promised patch and a few remarks : > http://trac.sagemath.org/sage_trac/ticket/12371 Nice ! Could I *please* ask you to add the "cdef int next_set" I mentionned in my previous post ? I'd put it secretly in another patch otherwise but I'm sure I would eventually forget ^^; Nathann -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
Le 27/01/2012 18:08, Nathann Cohen a écrit : I'm almost scared right now O_O You'll be happy to learn (eh, I just learnt it this very afternoon) that the C standards says that char can be either "unsigned char" or "signed char"... so if you want to be safe, just use the most precise form. Ok now I'm scared O_O;;; Here is the ticket with the promised patch and a few remarks : http://trac.sagemath.org/sage_trac/ticket/12371 Nice ! Could I *please* ask you to add the "cdef int next_set" I mentionned in my previous post ? I'd put it secretly in another patch otherwise but I'm sure I would eventually forget ^^; Well, no : this is an independent change and hence needs an independent patch. But perhaps a patch to : 1. change those "int" uses where it's known to really be an "unsigned char" between 0 and the cardinal of the graph 1. add a "cdef unsigned char next_set" as an aside but related fix in a new ticket will suit you? Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
> Well, no : this is an independent change and hence needs an independent > patch. Oh. Ok, well, it was juste one line and changed nothing to the code's behaviour. > between 0 and the cardinal of the graph > 1. add a "cdef unsigned char next_set" as an aside but related fix > > in a new ticket will suit you? Well, replacing "int" by "unsigned char" will not be a huge memory saving and will not help make the code easier to read either ^^; I will add this line in another patch, it is not important :-) Nathann -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Literal matrix syntax
> Currently one must write > > sage: matrix([[1, 2], [3, 4]]) > [1 2] > [3 4] > sage: matrix([[1, 2], [3, 4]]) * matrix([[5, 6], [7, 8]]) > [19 22] > [43 50] Well, one can avoid writing to much square brackets by doing : sage: matrix(2, [1,2,3,4]) [1 2] [3 4] sage: matrix(2, [1, 2, 3, 4]]) * matrix(2, [5, 6, 7, 8]) [19 22] [43 50] SL -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Unifying Command line options
On Friday, January 27, 2012 2:19:59 AM UTC-8, Jeroen Demeyer wrote: > > On 2012-01-27 11:17, David Roe wrote: > > Why? So that things like sage -i can work without python? > Exactly. > And also for speed issues, as William brought up a year or two ago when we discussed this sort of thing. If you run "sage --gp ...", you want it to start quickly, and not to include the overhead of starting Python. Ticket #21 had a workaround for this: use a shell script for a few basic command line arguments for which speed was important, and then if none of those were present, pass everything to a Python script for more sophisticated option parsing. -- John -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
Instead of sprinkling "unsigned" around until it works, we should IMHO use C99 integer types if the code assumes signedness and/or a particular bit width for "char". Just include inttypes.h (C) or cinttypes (C++), then int8_t is a signed 8-bit integer and uint8_t is an unsigned 8-bit integer. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Create numpy-functions from sage symbolic functions
Hi @all, I'm very new to the developers list. About my background: I'm studying physics (in Berlin) and I'm using sage regularly for some physical calculations. Three days ago I wondered if there is any possibility to create a "numpy-enabled" function from a sage's symbolic expression. But i couldn't find a solution. (Right: there is fast_callable, but it doesn't "eat" numpy arrays) So I came to an own solution, and thought it might be of interest for you. You can find it here: https://github.com/faucon/numpybuilder I would be happy to contribute this to sage, if you think there is a need for it. Cheers Maximilian PS: i know: the subfunctions are not yet fully documented, like described in the developer manual, and the mapping should be larger for general use. But these are things I would do only if there is interest in it ;-) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
Le 27/01/2012 19:14, Volker Braun a écrit : Instead of sprinkling "unsigned" around until it works, Well, that's not exactly what happened. Once it was recognized that the problem was that the code was using "char" thinking it meant "signed char" and that was wrong (surprise!), then I checked each use of "char" to see if it was meant to be a signed or unsigned one, and added the appropriate keyword. It's only when I was finished that I ran the test -- and got a positive result. That means the test passes on my platform, and certainly on all others, as a consequence of a deliberate fix, not a series of random changes with a halting condition as you seem to assume. I hope these precisions will calm your anxiety on the matter, Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] sage-4.8 ptestlong failures with graphs
I didn't doubt that what you do works, but even "unsigned char" isn't the same as a unsigned 8-bit integer on every platform. Plus whoever will contribute in the future is bound to trip over the same issue again, omitting "unsigned" because its not necessary on i386. While "unsigned char" is clearly better than just "char", both obscure the issue that you actually want an integer with a small range. int8_t is both shorter and more expressive. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Create numpy-functions from sage symbolic functions
Well, I think that looks very useful. I often get frustrated using numpy in Sage, this looks like it would make quite a few things easier. So you get a +1 from me at least. -Marshall Hampton On Jan 27, 12:27 pm, Maximilian Trescher wrote: > Hi @all, > > I'm very new to the developers list. > About my background: I'm studying physics (in Berlin) and I'm using sage > regularly for some physical calculations. > > Three days ago I wondered if there is any possibility to create a > "numpy-enabled" function from a sage's symbolic expression. But i > couldn't find a solution. > (Right: there is fast_callable, but it doesn't "eat" numpy arrays) > > So I came to an own solution, and thought it might be of interest for > you. You can find it here: > > https://github.com/faucon/numpybuilder > > I would be happy to contribute this to sage, if you think there is a > need for it. > > Cheers > Maximilian > > PS: > i know: the subfunctions are not yet fully documented, like described in > the developer manual, and the mapping should be larger for general use. > But these are things I would do only if there is interest in it ;-) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
