Re: [sage-devel] Notebooks from admin viewpoint
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 user and files of him/her. Or use top or ps to see who is >> eating memory or burning cpu. Or even put on some ulimits to users. >> Sometimes chown some files etc. >> >> What of these features are going to be on notebooks talked about in this >> list? As an example: Will it be possible to restrict memory use of students >> to lower level than staff? >> >> > SMC has extensive support for this sort of thing with a graphical > interface for configuration... You can control numerous Linux cgroups > parameters, quota, etc. > > > > >> -- >> Jori Mäntysalo >> > > > -- > Sent from my massive iPhone 6 plus. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Notebooks from admin viewpoint
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 for, say, a class, allows creation/modification/deletion of accounts via the web interface it provides (via its admin account). Currently SageNB allows creation and modification of accounts. I think that real deletion is still impossible, i.e. the worksheets remain even after deleting a user account. And more, a new user with same username will see them. (Btw, that happens also on plain Linux, if you delete a user with largest uid and there was files not looked at by userdel -r.) -- Jori Mäntysalo
[sage-devel] Extracting documentation
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 Levenstein distance or words? 3) The reason? See (already reviewed) http://trac.sagemath.org/ticket/19852 . -- Jori Mäntysalo
[sage-devel] plugins.startup_modules error
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: 2202
+Total count: 2205
+New:
+sage.manifolds
+sage.manifolds.all
+sage.manifolds.sage
+
+sage.manifolds
+sage.manifolds.all
+sage.manifolds.sage
-plugins.startup_modules Passed
+plugins.startup_modules Failed
Now, regarding modules, all that this ticket does is to add the line
from sage.manifolds.all import *
to src/sage/all.py, the content of src/sage/manifolds/all.py being
from sage.misc.lazy_import import lazy_import
lazy_import('sage.manifolds.manifold', 'Manifold')
I don't understand this plugin error and did not find any hint on
http://wiki.sagemath.org/buildbot.
What am I missing? Thank you for your help.
Eric.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] plugins.startup_modules error
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.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: 2202
+Total count: 2205
+New:
+sage.manifolds
+sage.manifolds.all
+sage.manifolds.sage
+
+sage.manifolds
+sage.manifolds.all
+sage.manifolds.sage
-plugins.startup_modules Passed
+plugins.startup_modules Failed
Now, regarding modules, all that this ticket does is to add the line
from sage.manifolds.all import *
to src/sage/all.py, the content of src/sage/manifolds/all.py being
from sage.misc.lazy_import import lazy_import
lazy_import('sage.manifolds.manifold', 'Manifold')
I don't understand this plugin error and did not find any hint on
http://wiki.sagemath.org/buildbot.
What am I missing? Thank you for your help.
Eric.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: plugins.startup_modules error
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://patchbot.sagemath.org/ticket/18529/
> Clicking on "diff", one gets the report
>
> == plugins.startup_modules ==
>
> --- 7.0.beta3
>
> +++ 7.0.beta3 + #18529
>
>
> -Total count: 2202
> +Total count: 2205
> +New:
> +sage.manifolds
> +sage.manifolds.all
> +sage.manifolds.sage
> +
>
> +sage.manifolds
> +sage.manifolds.all
> +sage.manifolds.sage
>
> -plugins.startup_modules Passed
> +plugins.startup_modules Failed
>
>
> Now, regarding modules, all that this ticket does is to add the line
>
> from sage.manifolds.all import *
>
> to src/sage/all.py, the content of src/sage/manifolds/all.py being
>
> from sage.misc.lazy_import import lazy_import
> lazy_import('sage.manifolds.manifold', 'Manifold')
>
> I don't understand this plugin error and did not find any hint on
> http://wiki.sagemath.org/buildbot.
> What am I missing? Thank you for your help.
>
> Eric.
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] plugins.startup_modules error
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. Thanks for your answer! Eric. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: plugins.startup_modules error
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.all import * is not a lazy one, even if sage.manifolds.all contains only lazy_import). In the present case, the above line in sage.all is necessary, isn't it ? Otherwise, the lazy_import in sage.manifolds.all would not be accessible. Best regards, Eric. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] incremental migration to github?
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. Other ideas? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] incremental migration to github?
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 Bradshaw once wrote some sort of github <---> trac bot. Maybe he can say something about that. Anyway what github have accomplished in the last few years is very impressive. William On Monday, January 11, 2016, Ralf Stephan wrote: > 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. > > Other ideas? > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com > > . > To post to this group, send email to sage-devel@googlegroups.com > . > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- Sent from my massive iPhone 6 plus. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] incremental migration to github?
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 Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: cython string problem
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 of __init__ with cdef classes > and use more of a RAII-style design. The cython ctor is always is > called, the python ctor not necessarily! You are calling > lazy_list_abstract.__new__ a couple of times and not manually > initializing self.name, this is where your None (NULL in C) string > attributes come from. Thanks; it works now. Daniel -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] cython string problem
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 subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: incremental migration to github?
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 we even can import our current trac database, not to mention that some fields (e.g. Reviewer) are missing. I also think that one of the nice features of the current workflow is that ticket information is summarized in the merge commit. If you use github's merge button then it won't be there, making the history more difficult to understand. Also there is no comparable free CI to our buildbot instance, e.g. travis-ci doesn't have any platform diversity (ok, the paid version also has OSX in addition to their linux docker instance). On Monday, January 11, 2016 at 5:20:38 PM UTC+1, Ralf Stephan wrote: > > 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. > > Other ideas? > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: incremental migration to github?
> > > 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 zillions of links to trac.sagemath.org would instantly be obsolete, and we'd be dependent upon a private company to maintain our bug tracker - one which might not be easily recreatable in the event GH gets bought or they go out of business or the service is taken down for whatever reason. On a curiosity note, would GH be able to import the many cross-references within Trac itself to its native xref link creation? (I mean things like the [comment:56:ticket:100 this link to a really vital comment] and #12345 syntax, presumably those are themselves some kind of plugin to Trac.) - kcrisman -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: incremental migration to github?
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-trivial (though not blocker, probably) issue that > zillions of links to trac.sagemath.org would instantly be obsolete, No. We wouldn't shut down running trac for a long, long time. > and we'd > be dependent upon a private company to maintain our bug tracker - one which > might not be easily recreatable in the event GH gets bought or they go out > of business or the service is taken down for whatever reason. Nothing is black and white like you make it out above. It's a tradeoff. Having used GH, it's definitely way, way more than worth that tradeoff. Not making this tradeoff could easily lead to the death of Sage, since Sage development is definitely WAY WAY too hard and full of friction. If somebody else came along with something like Sage that used GH and provided a much more pleasant development experience, the Sage project would be in very serious trouble. Waiting until it is too late is no solution. I'm so glad that certain people (not me!) had the foresight to switch away from Mercurial! > On a curiosity note, would GH be able to import the many cross-references > within Trac itself to its native xref link creation? (I mean things like > the [comment:56:ticket:100 this link to a really vital comment] and #12345 > syntax, presumably those are themselves some kind of plugin to Trac.) GH is amazing at automatically cross referencing. As are the many integrations, e.g. with gitter, slack, etc. William > > - kcrisman > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: incremental migration to github?
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 fields (e.g. Reviewer) are missing. >>> >> >> There's also the non-trivial (though not blocker, probably) issue that >> zillions of links to trac.sagemath.org would instantly be obsolete, > > No. We wouldn't shut down running trac for a long, long time. > >> and we'd >> be dependent upon a private company to maintain our bug tracker - one which >> might not be easily recreatable in the event GH gets bought or they go out >> of business or the service is taken down for whatever reason. > > Nothing is black and white like you make it out above. It's a > tradeoff. Having used GH, it's definitely way, way more than worth > that tradeoff. Not making this tradeoff could easily lead to the > death of Sage, since Sage development is definitely WAY WAY too hard > and full of friction. If somebody else came along with something like > Sage that used GH and provided a much more pleasant development > experience, the Sage project would be in very serious trouble. > Waiting until it is too late is no solution. I'm so glad that > certain people (not me!) had the foresight to switch away from > Mercurial! Following up on this, that we don't fully support people doing development for Sage by creating independent pip-installable packages (which depend on sage) is a *major* point of friction for our project. The sage dev process is very heavy and confusing compared to what it should be.This friction could kill us. William -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] incremental migration to github?
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. I very much prefer the trac model where you create a ticket, discuss things, then have multiple people work together on a branch all on the same page. With github, it sometimes happens that you have one issue and several pull requests by different people which are all about the same thing. I get lost more easily in the github forest. Another useful thing is that everything on trac is in one git tree. I can do "git fetch" and have all tickets ready to check out without any hassle. I don't know if you can easily checkout a pull request from github. Finally a stupid thing: I don't get why github discussions don't have a "reply" button. I must admit that I don't use github that heavily, so maybe there are things that I am missing. Jeroen. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: incremental migration to github?
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 pypi so you can't auto-download it as a dependency, but then its doubtful that this would work anyways. There are way too may specialized shared-library dependencies, and if there is one thing that really sucks then that's (pip,npm,rvm,...)-packages that start compiling gobs of third-party C/C++ code when installing. Neither is pip/wheel/... made for distributing binaries of third-party code. So realistically there should always be a "sage runtime" to compile the dependencies before installing Sage-the-python-library. But you can just use pip to install packages depending on Sage on top of that, no problem. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: incremental migration to github?
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 that before and it works just fine. Technically there is no problem. The problem is mostly one of documentation and culture. How many sage dependent packages are on pypi? > > Of course sage isn't on pypi so you can't auto-download it as a dependency, > but then its doubtful that this would work anyways. There are way too may > specialized shared-library dependencies, and if there is one thing that > really sucks then that's (pip,npm,rvm,...)-packages that start compiling > gobs of third-party C/C++ code when installing. Neither is pip/wheel/... > made for distributing binaries of third-party code. So realistically there > should always be a "sage runtime" to compile the dependencies before > installing Sage-the-python-library. But you can just use pip to install > packages depending on Sage on top of that, no problem. Yes, the latter. We could have a simple dependency, e.g., "sagelib" or something, that pip pulls in, and it simply checks that sage is installed, and if not, explains the situation. Then in a few years when I prove you wrong regarding "you can't auto-download it as a dependency, but then its doubtful that this would work anyways." then we can replace that with sage itself. William > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
