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
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 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 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 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
>
>
> 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
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
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
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 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
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
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.
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.
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.
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
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
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
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
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
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
20 matches
Mail list logo
