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
Its a neat twist on just making multiple clones of the Sage repo; In terms
of rebuild time it doesn't give you really anything different.
On Thursday, January 7, 2016 at 12:03:15 AM UTC+1, Dima Pasechnik wrote:
>
> This is a newish (since git 2.5) feature of git that apparently makes
> switchi
This is a newish (since git 2.5) feature of git that apparently makes
switching between different branches very quick.
https://git-scm.com/docs/git-worktree
I imagine it is diskspace-hungry, but, OK, this should only be big deal on
VMs...
Has anyone tried it? Getting rid of "I checked out that b
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
On Wednesday, 6 January 2016 20:50:10 UTC, Volker Braun wrote:
>
> There is a src/sage/combinat/matrices/dancing_links_c.h header in the
> repository, if you don't have that file then something went wrong when
> unpacking. See e.g.:
>
or perhaps with downloading the tarball?
Did you check the md
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
On Wednesday, 6 January 2016 20:53:37 UTC, vdelecroix wrote:
>
> Indeed, wouldn't it possible to make it as follows
>
> sage: G0 = libgap.SO(3,4)
> sage: so = libgap.GeneratorsOfGroup(G0)
> etc
>
of course it would. But what's the point of having all these intermediate
libgap objects being
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
Indeed, wouldn't it possible to make it as follows
sage: G0 = libgap.SO(3,4)
sage: so = libgap.GeneratorsOfGroup(G0)
etc
Vincent
On 06/01/16 17:48, Nathann Cohen wrote:
Hello everybody,
A ticket is in needs_review at #19661 [1], and the branch's main
feature is a new graph constructor. I writ
There is a src/sage/combinat/matrices/dancing_links_c.h header in the
repository, if you don't have that file then something went wrong when
unpacking. See e.g.:
https://github.com/sagemath/sage/tree/master/src/sage/combinat/matrices
On Tuesday, January 5, 2016 at 8:05:34 PM UTC+1, jhonrubi
Hello everybody,
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* that is sent to GAP for evaluation.
http://git
On Wednesday, January 6, 2016, Vincent Delecroix <20100.delecr...@gmail.com>
wrote:
> On 06/01/16 16:52, William Stein wrote:
>
>> On Wed, Jan 6, 2016 at 11:44 AM, Vincent Delecroix <
>> 20100.delecr...@gmail.com> wrote:
>>
>> On 06/01/16 16:23, Bill Page wrote:
>>>
>>> On 6 January 2016 at 13:12,
On 06/01/16 16:52, William Stein wrote:
On Wed, Jan 6, 2016 at 11:44 AM, Vincent Delecroix <
20100.delecr...@gmail.com> wrote:
On 06/01/16 16:23, Bill Page wrote:
On 6 January 2016 at 13:12, Vincent Delecroix <20100.delecr...@gmail.com>
wrote:
Why making it a python package?!
Yes, that i
On Wed, Jan 6, 2016 at 11:44 AM, Vincent Delecroix <
20100.delecr...@gmail.com> wrote:
> On 06/01/16 16:23, Bill Page wrote:
>
>> On 6 January 2016 at 13:12, Vincent Delecroix <20100.delecr...@gmail.com>
>> wrote:
>>
>>> Why making it a python package?!
>>>
>>
>> Yes, that is a very good question.
On Wed, Jan 6, 2016 at 11:23 AM, Bill Page
wrote:
> On 6 January 2016 at 13:12, Vincent Delecroix <20100.delecr...@gmail.com>
> wrote:
> > Why making it a python package?!
>
> Yes, that is a very good question.
We should move the entire Sage development process to use Python's
packaging system
On 06/01/16 16:23, Bill Page wrote:
On 6 January 2016 at 13:12, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
Why making it a python package?!
Yes, that is a very good question. The original motivation came as a
result of a comment by William Stien on an SMC issue concerning Ocatve
in
On 6 January 2016 at 13:12, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> Why making it a python package?!
Yes, that is a very good question. The original motivation came as a
result of a comment by William Stien on an SMC issue concerning Ocatve
in Sage worksheets on SMC. See emails bel
Why making it a python package?! If it was a git branch it would be much
easier to see the difference with the actual sage/interfaces/octave.py
and test it... You can have a look at
http://doc.sagemath.org/html/en/developer/index.html
1. You should get rid of the following commented lines
Hello developers,
I recently put up a thread regarding contribution to sagemath. It has been
helpful to me, I want to be helpful to community in any possible way.
I was setting up the development environment, prefer Pycharm IDE for the
same.
I just forked the sage repository and built it from so
I am interested in comments and criticism concerning the following work in
progress:
https://pypi.python.org/pypi/sage_octave
Bill Page
-- Forwarded message --
From: Bill Page
Date: 6 January 2016 at 00:54
Subject: Re: [smc] %octave mode in sage worksheets is flaky simply becaus
Hello developers,
I recently put up a thread regarding contribution to sagemath. It has been
helpful to me, I want to be helpful to community in any possible way.
I was setting up the development environment, prefer Pycharm IDE for the
same.
I just forked the sage repository and built it from so
On Wednesday, January 6, 2016 at 1:17:12 PM UTC+1, Min RK wrote:
>
> Files aren't used for output. The filesystem should only be involved, if
> at all, in the exceptional case of output overflow.
>
Everything is a file of sorts... map is just ram with filesystem backing.
You can put large stuff
On Wed, Jan 6, 2016 at 1:02 PM, Volker Braun wrote:
> On Wednesday, January 6, 2016 at 11:55:36 AM UTC+1, Min RK wrote:
>>
>> If we truncate instead of virtual-scroll, then we have a choice for
>> whether truncated output is included in the document or not, which
>> alleviates the problem of open
On Wednesday, January 6, 2016 at 11:55:36 AM UTC+1, Min RK wrote:
>
> If we truncate instead of virtual-scroll, then we have a choice for
> whether truncated output is included in the document or not, which
> alleviates the problem of opening notebooks that have a problematic amount
> of output
On Wednesday, January 6, 2016 at 10:05:32 AM UTC+1, Volker Braun wrote:
>
> IMHO output capture into a web browser isn't really different from the
> scrollback buffer of a terminal. We obviously enjoy the infinite scrollback
> but do not want an unbounded drawing surface in the terminal (= dom
On 2016-01-06 10:05, Volker Braun wrote:
And certainly nobody wants a piece of
their output discarded in a long-running computation.
+1. Actually throwing away output is the worst solution. The full output
should still be available somehow.
--
You received this message because you are subscr
IMHO output capture into a web browser isn't really different from the
scrollback buffer of a terminal. We obviously enjoy the infinite scrollback
but do not want an unbounded drawing surface in the terminal (= dom nodes
in the web browser). And certainly nobody wants a piece of their output
di
29 matches
Mail list logo
