On Sat, 9 Jan 2016, Dima Pasechnik wrote:
all what "# optional - blah" does is to look up "blah" in the --optional
command line argument.
So you can doctest stuff dependent on "blah", too.
Ah, OK. So I was (once again) thinking too complicated. Thanks.
--
Jori Mäntysalo
On Saturday, 9 January 2016 10:19:48 UTC, Jori Mäntysalo wrote:
>
> On Sat, 9 Jan 2016, Jeroen Demeyer wrote:
>
> >> How it is then doctested? Does #optional work for additional packages
> >> installed to a "sub-program" of Sage, like some R pacakge?
>
> > You use
> >
> > # optional - gap_pa
On Sat, 9 Jan 2016, Jeroen Demeyer wrote:
How it is then doctested? Does #optional work for additional packages
installed to a "sub-program" of Sage, like some R pacakge?
You use
# optional - gap_packages
But http://wiki.sagemath.org/InstallingGapPackages says that "- - but
still you migh
On 2016-01-09 10:39, Jori Mäntysalo wrote:
On Wed, 6 Jan 2016, David Joyner wrote:
Just to be clear what the disagreement is, as far as I can tell, this
is not simply a call to GAP but a call to a GAP package "Grape" which
is not part of Sage's standard installation of GAP.
How it is then doc
On Wed, 6 Jan 2016, David Joyner wrote:
Just to be clear what the disagreement is, as far as I can tell, this
is not simply a call to GAP but a call to a GAP package "Grape" which
is not part of Sage's standard installation of GAP.
How it is then doctested? Does #optional work for additional p
> "should instead expose in the Sage mathematical objects those features from
> GAP that you need" (could anyone translate this for me?)
It means that:
- If you write native GAP code to implement this, I believe that it is
because you cannot run those computations by simply calling methods
from Sa
On Wednesday, 6 January 2016 22:13:02 UTC, Dima Pasechnik wrote:
>
> On 6 January 2016 at 21:13, Volker Braun <> wrote:
> > A slightly more useful solution would be to put the gap code into a gap
> file
> > in src/ext/gap/ and load it from there. For starters, it could then also
> be
> > loa
On Wednesday, 6 January 2016 21:07:09 UTC, David Joyner wrote:
>
> Just to be clear what the disagreement is, as far as I can tell, this
> is not simply a call to GAP but a call to a GAP package "Grape" which
> is not part of Sage's standard installation of GAP.
>
I understand that Len Soicher
On 6 January 2016 at 21:13, Volker Braun wrote:
> A slightly more useful solution would be to put the gap code into a gap file
> in src/ext/gap/ and load it from there. For starters, it could then also be
> loaded into a plain gap session.
I never heard about src/ext/gap/ - is it documented anywh
A slightly more useful solution would be to put the gap code into a gap
file in src/ext/gap/ and load it from there. For starters, it could then
also be loaded into a plain gap session.
Either way it doesn't really win any beauty contents, but then its just
constructing a particular named graph
Just to be clear what the disagreement is, as far as I can tell, this
is not simply a call to GAP but a call to a GAP package "Grape" which
is not part of Sage's standard installation of GAP.
As a compromise: can a (possibly slower) version be written as well,
which does not call an optional packa
tl;dr; :
On 6 January 2016 at 20:48, Nathann Cohen wrote:
> A ticket is in needs_review at #19661 [1], and the branch's main
> feature is a new graph constructor. I write here because of a
> disagreement Dima and I have about the code: I do not like at all that
> most of the code is a *string* tha
12 matches
Mail list logo
