sagenb.org is so slow as to be unusable right now. Can someone
investigate? Perhaps restart it?
Thanks,
Dan
--
--- Dan Drake
- http://mathsci.kaist.ac.kr/~drake
---
signature.asc
Description: Digital signature
Sorry, my mistake. I thought that the base ring should be the smallest ring
which contained the element, but you are right in that the function agrees
both with the documentation and with common usage.
Andrew
On Friday, 20 April 2012 08:35:22 UTC+10, AlexGhitza wrote:
>
> Hi,
>
> On Fri, Apr 20
I don't know whether this has ben mentioned already on this list, but
also Python has problems with Debian multi-arch. Python doesn't know
that it has to look in /usr/lib/i386-linux-gnu for libraries, so
building the crypt module fails and building some of the hash functions
for hashlib fails.
Se
Hi there,
In the process of trying to help fixing broken links in the documentation, I'd
like to share some info and call for a vote:
> > > I think "_included_private_doc_" attribute would be great.
I was writing a patch to allows for including private methods through an
attribute "_includ
Le lundi 23 avril, Jeroen Demeyer a écrit:
> I don't know whether this has ben mentioned already on this list, but
> also Python has problems with Debian multi-arch. Python doesn't know
> that it has to look in /usr/lib/i386-linux-gnu for libraries, so
> building the crypt module fails and buildin
Hi David,
> > Sage documentation still has a lot of dangling links. To check if there are
> > some please use the recently added option --warn-links as in:
> >
> > sage --docbuild --warn-links reference html
> >
> > Beware that it triggers a full recompilation of the doc the first time y
We really have to patch every single Python package? That's awful.
If only distutils/setuptools wouldn't be so broken... why do they
hard-code the directories to look for .so files?
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an em
Le lundi 23 avril, Jeroen Demeyer a écrit:
> We really have to patch every single Python package? That's awful.
No, only python packages which insist on overriding lib paths, because
that means even a patched compiler/interpreter which knows where to
look, will still fail because of the override.
I hate Python's installer and distutils/setuptools.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL:
On 2012-04-23 14:33, Jeroen Demeyer wrote:
> I hate Python's installer and distutils/setuptools.
... but I hate it less than I hate SCons, which is broken by design, for
example by ignoring environment variables on purpose!
--
To post to this group, send an email to sage-devel@googlegroups.com
To
Le lundi 23 avril, Jeroen Demeyer a écrit:
> On 2012-04-23 14:33, Jeroen Demeyer wrote:
> > I hate Python's installer and distutils/setuptools.
> ... but I hate it less than I hate SCons, which is broken by design,
> for example by ignoring environment variables on purpose!
Uh, like : http://trac.
On Mon, Apr 23, 2012 at 12:11 AM, Dan Drake wrote:
> sagenb.org is so slow as to be unusable right now. Can someone
> investigate? Perhaps restart it?
It gets automatically restarted twice a day anyways. It's just
massively overused compared to the server resources and scalability of
the app.
Florent Hivert writes:
> [ ] use the Sphinx automethod standard trick.
> [ ] use a special Sage attribute "_included_private_doc_"
No opinion.
> [ ] leave things as they are and rely on the preceding "automethod" or
> "_included_private_doc_" trick to document special methods.
> [ ] inc
[x] use the Sphinx automethod standard trick.
[ ] use a special Sage attribute "_included_private_doc_"
[ ] leave things as they are and rely on the preceding "automethod" or
"_included_private_doc_" trick to document special methods.
[x] include __*__ and _*_ method by default in the doc.
Wi
On Mon, Apr 23, 2012 at 08:29:47AM -0700, Andrey Novoseltsev wrote:
> [x] use the Sphinx automethod standard trick.
> [ ] use a special Sage attribute "_included_private_doc_"
>
> [ ] leave things as they are and rely on the preceding "automethod" or
> "_included_private_doc_" trick to documen
On Apr 23, 9:39 am, Florent Hivert wrote:
> On Mon, Apr 23, 2012 at 08:29:47AM -0700, Andrey Novoseltsev wrote:
> > [x] use the Sphinx automethod standard trick.
> > [ ] use a special Sage attribute "_included_private_doc_"
>
> > [ ] leave things as they are and rely on the preceding "automethod"
On Monday, April 23, 2012 7:59:11 AM UTC-4, Snark wrote:
>
> No, only python packages which insist on overriding lib paths, because
> that means even a patched compiler/interpreter which knows where to
> look, will still fail because of the override
>
Yes thats awful.
It is yet another thing that
Ok, switching to a newer version of ubuntu solved the eclib problem.
Now i have another one. Building the sage package i get this error
message:
Building modified file sage/ext/interpreters/wrapper_el.pyx.
Executing 296 commands (using 4 threads)
Traceback (most recent call last):
File "setup.py
On 2012-04-23 20:06, Volker Braun wrote:
> It is yet another thing that could be solved once-and-for-all with the
> compilerwrapper ;-)
Here, this is not the case. The problem is not with gcc here, the
problem is with Python "detecting" which libraries are installed. No
compilerwrapper can solve
Em 23 de abril de 2012 16:54, mmarco escreveu:
> Ok, switching to a newer version of ubuntu solved the eclib problem.
> Now i have another one. Building the sage package i get this error
> message:
>
> Building modified file sage/ext/interpreters/wrapper_el.pyx.
> Executing 296 commands (using 4 t
On 23 Apr., 12:05, Florent Hivert wrote:
> This is a second question: It seems that several Sage developers consider
> Python's (``.__*__``) and Sage's (``._*_``) *special* methods as public so
> that they should be included in the doc by default. On the opposite, *private*
> methods starts by ``_
On 2012-04-23 23:22, leif wrote:
> Same here. I wouldn't say that +38 MB (or +21.5%) is "a bit"; it also
> multiplies with the number of Sage installations.
Also: how much memory do we need to *build* the documentation?
Currently (i.e. without this change), Sage needs about 2.5GB to build
the docu
On 23 April 2012 20:54, mmarco wrote:
> Ok, switching to a newer version of ubuntu solved the eclib problem.
I did not report back to you but there is now a new eclib spkg at
http://trac.sagemath.org/sage_trac/ticket/10993
John
> Now i have another one. Building the sage package i get this err
On Apr 23, 3:22 pm, leif wrote:
> Adding docstrings to such functions (or improving existing ones) is
> orthogonal to including them into the HTML or PDF documentation in
> general.
I'd also say that docbuild time, documentation size, and amount of
necessary memory are orthogonal to (not) adding
On Mon, 23 Apr 2012 at 06:02AM -0700, William Stein wrote:
> On Mon, Apr 23, 2012 at 12:11 AM, Dan Drake wrote:
> > sagenb.org is so slow as to be unusable right now. Can someone
> > investigate? Perhaps restart it?
>
> It gets automatically restarted twice a day anyways. It's just
> massively
>
> I did not look very closely at a related issue in chroot'ed builds in x86,
> but it should be possible to make python multiprocessing use some
> other approach like pipes in these conditions. What I did to get sage
> to build in the Mandriva build system was to "backport" the previous
> logi
Hi Andrey,
> I'd also say that docbuild time, documentation size, and amount of
> necessary memory are orthogonal to (not) adding special methods to the
> documentation.
I totally agree.
> I am not saying that they are irrelevant, but if we hit
> limits on these the solution is perhaps to
On 4/23/12 5:20 PM, Dan Drake wrote:
On Mon, 23 Apr 2012 at 06:02AM -0700, William Stein wrote:
On Mon, Apr 23, 2012 at 12:11 AM, Dan Drake wrote:
sagenb.org is so slow as to be unusable right now. Can someone
investigate? Perhaps restart it?
It gets automatically restarted twice a day anywa
On 23 Apr., 23:49, Andrey Novoseltsev wrote:
> On Apr 23, 3:22 pm, leif wrote:
>
> > Adding docstrings to such functions (or improving existing ones) is
> > orthogonal to including them into the HTML or PDF documentation in
> > general.
>
> I'd also say that docbuild time, documentation size, and
> I mostly agree on that. We just have to get rid of Sphinx. flame>
Or rewrite it in Cython !!! Please Do !!!
> > I had people asking me how to check if an element is in a set and
> > complaining that it is not written in the documentation. Well, the
> > reasonable search on a doc page is for "
On 24 Apr., 00:23, mmarco wrote:
> > I did not look very closely at a related issue in chroot'ed builds in x86,
> > but it should be possible to make python multiprocessing use some
> > other approach like pipes in these conditions. What I did to get sage
> > to build in the Mandriva build syste
On 24 Apr., 02:36, leif wrote:
> On 24 Apr., 00:23, mmarco wrote:
>
> > > I did not look very closely at a related issue in chroot'ed builds in
> > > x86,
> > > but it should be possible to make python multiprocessing use some
> > > other approach like pipes in these conditions. What I did to
On 24 Apr., 01:18, Florent Hivert wrote:
> > I mostly agree on that. We just have to get rid of Sphinx. > flame>
>
> Or rewrite it in Cython !!! Please Do !!!
I
>
> > > I had people asking me how to check if an element is in a set and
> > > complaining that it is not written in the documentatio
On 24 Apr., 01:18, Florent Hivert wrote:
> > I mostly agree on that. We just have to get rid of Sphinx. > flame>
>
> Or rewrite it in Cython !!! Please Do !!!
If only I had the time... (although I wouldn't use Cython I think)
> > > I had people asking me how to check if an element is in a set
You are right, they don't seem to do autotools-style library detection.
Thats messed up ;-)
On Monday, April 23, 2012 4:50:18 PM UTC-4, Jeroen Demeyer wrote:
>
> On 2012-04-23 20:06, Volker Braun wrote:
> > It is yet another thing that could be solved once-and-for-all with the
> > compilerwra
On Monday, 23 April 2012 21:02:05 UTC+8, William wrote:
>
> On Mon, Apr 23, 2012 at 12:11 AM, Dan Drake <> wrote:
> > sagenb.org is so slow as to be unusable right now. Can someone
> > investigate? Perhaps restart it?
>
> It gets automatically restarted twice a day anyways. It's just
> massively
On Mon, Apr 23, 2012 at 8:49 PM, Dima Pasechnik wrote:
> On Monday, 23 April 2012 21:02:05 UTC+8, William wrote:
>>
>> On Mon, Apr 23, 2012 at 12:11 AM, Dan Drake <> wrote:
>> > sagenb.org is so slow as to be unusable right now. Can someone
>> > investigate? Perhaps restart it?
>>
>> It gets autom
37 matches
Mail list logo
