Where is that interface available?
El sábado, 9 de enero de 2016, 22:15:51 (UTC+1), William escribió:
>
>
>
> On Friday, January 8, 2016, Jori Mäntysalo > wrote:
>
>> I am basically just a sysadmin.
>>
>> For normal users and normal processes I can for example userdel -r to
>> totally remove a u
On Sun, 10 Jan 2016, Nils Bruin wrote:
I would argue the opposite, making local accounts is exactly what you
usually do to let users run their own programs (i.e. execute arbitrary
code).
I would agree with that. However, one would also expect that a notebook
server that can manage accounts
1) Is it easily possible to extract documentation without testable parts
from Sage source code? For example from
def foo()
"""
Return 42.
EXAMPLES:
Basic usage::
sage: foo()
42
"""
return 42
one could get
Return 42.
Basic usage:
2) Can Sage compute L
Hi,
On the ticket
http://trac.sagemath.org/ticket/18529
the patchbots report a failed plugins.startup_modules:
http://patchbot.sagemath.org/ticket/18529/
Clicking on "diff", one gets the report
== plugins.startup_modules ==
--- 7.0.beta3
+++ 7.0.beta3 + #18529
-Total count: 2
Hello Eric,
The plugin is very naive: it just looks for new modules on startup. And
you added one. You should not worry about it. The patchbot green light
is not at all mandatory to get a ticket reviewed.
Vincent
On 11/01/16 06:55, Eric Gourgoulhon wrote:
Hi,
On the ticket
http://trac.sage
Its not really an error, but one should strive to not add unneccessary
modules.
On Monday, January 11, 2016 at 10:55:36 AM UTC+1, Eric Gourgoulhon wrote:
>
> Hi,
>
> On the ticket
> http://trac.sagemath.org/ticket/18529
> the patchbots report a failed plugins.startup_modules:
> http://patchbo
Le lundi 11 janvier 2016 12:35:36 UTC+1, vdelecroix a écrit :
>
> Hello Eric,
>
> The plugin is very naive: it just looks for new modules on startup. And
> you added one. You should not worry about it. The patchbot green light
> is not at all mandatory to get a ticket reviewed.
>
>
OK, I see.
Le lundi 11 janvier 2016 12:38:50 UTC+1, Volker Braun a écrit :
>
> Its not really an error, but one should strive to not add unneccessary
> modules.
>
>
>
Yes, I thought this was taken into account by using only lazy_import, as we
do
(except in sage.all, where the import
from sage.manifolds.
Can you think of ways to move development step-by-step to github?
What would be wrong with accepting pull requests for *some parts of Sage,
then review, followed by submission to trac by an intermediary?
This would need a second repository I guess. Permissions to merge could be
given on request.
Hi,
For what it is worth I'm highly supportive of Sage development moving to
github. However, I think the release manager should be completely 100% in
charge of where Sage dev happens. It's much more important that we have a
solid process for doing sage releases than anything else.
Robert Brad
On 11 January 2016 at 11:26, William Stein wrote:
>
> For what it is worth I'm highly supportive of Sage development moving to
> github.
>...
> Anyway what github have accomplished in the last few years is very
> impressive.
>
+1
--
You received this message because you are subscribed to the Go
On 2016-01-10 20:36, Volker Braun wrote:
> 1) don't cdef class attributes, it just makes debugging unnecessary
> hard. Unless you are wrapping C-level types where you can't avoid it, of
> course. Just keep it in python, maybe use cpdef if you must.
Ok.
> 2) I'd recommend using __cinit__ instead o
On 2016-01-10 21:20, Jeroen Demeyer wrote:
> On 2016-01-10 18:26, Daniel Krenn wrote:
>> This shows that the problem is += in
>>s += self.separator.join(E)
>
> Are you sure? I already get a problem here:
Nevermind; already solved.
Thanks
Daniel
--
You received this message because you are
As William already said, there is the github<->trac bot. Even without that,
you can just copy branches over. So if you want to do the review on github
and then stick it into trac thats easy to do.
But if you want to use the github issue tracker then that wouldn't work as
easily. I don't think w
>
>
> But if you want to use the github issue tracker then that wouldn't work as
> easily. I don't think we even can import our current trac database, not to
> mention that some fields (e.g. Reviewer) are missing.
>
>
There's also the non-trivial (though not blocker, probably) issue that
zilli
On Mon, Jan 11, 2016 at 10:43 AM, kcrisman wrote:
>
>>
>>
>> But if you want to use the github issue tracker then that wouldn't work as
>> easily. I don't think we even can import our current trac database, not to
>> mention that some fields (e.g. Reviewer) are missing.
>>
>
> There's also the non
On Mon, Jan 11, 2016 at 10:52 AM, William Stein wrote:
> On Mon, Jan 11, 2016 at 10:43 AM, kcrisman wrote:
>>
>>>
>>>
>>> But if you want to use the github issue tracker then that wouldn't work as
>>> easily. I don't think we even can import our current trac database, not to
>>> mention that some
On 2016-01-11 17:26, William Stein wrote:
Hi,
For what it is worth I'm highly supportive of Sage development moving to
github.
I like trac (especially the way Sage uses it) a lot better than github.
What I mostly dislike about github is that "issues" and "pull requests"
are different things.
On Monday, January 11, 2016 at 8:20:45 PM UTC+1, William wrote:
>
> Following up on this, that we don't fully support people doing
> development for Sage by creating independent pip-installable packages
Where is the problem, I did that before and it works just fine.
Of course sage isn't on py
On Mon, Jan 11, 2016 at 11:39 AM, Volker Braun wrote:
> On Monday, January 11, 2016 at 8:20:45 PM UTC+1, William wrote:
>>
>> Following up on this, that we don't fully support people doing
>> development for Sage by creating independent pip-installable packages
>
>
> Where is the problem, I did th
20 matches
Mail list logo
