Le 21/02/2013 04:06, Dima Pasechnik a écrit :
I'd like to add autoconf stuff, and libtool, to something I'd like to
make an optional spkg
https://github.com/dimpase/csdp
(there were also requests for this on
sage-support):
So far I only "regularized" the header files to be installed.
What remai
I'd like to add autoconf stuff, and libtool, to something I'd like to
make an optional spkg
https://github.com/dimpase/csdp
(there were also requests for this on
sage-support):
So far I only "regularized" the header files to be installed.
What remains is to libtoolize the library in lib/, and
(
>
> > --
> > | Sage Version 4.4.4, Release Date: 2010-06-23
> > |
> > | Type notebook() for the GUI, and license() for information.
> > |
> > -
Ready for review.
David
On Wed, Feb 20, 2013 at 4:16 PM, David Roe wrote:
> http://trac.sagemath.org/sage_trac/ticket/14155. I'm going to try to
> write something.
> David
>
>
> On Wed, Feb 20, 2013 at 3:29 PM, kcrisman wrote:
>
>> Huh, how did I miss that... William says:
>>
>> I think the
I see. Thanks so much for your advice! Will get the C lib upgraded then!
On Tuesday, February 19, 2013 5:35:54 AM UTC+8, Keshav Kini wrote:
>
> Keshav Kini > writes:
> > Jeroen Demeyer > writes:
> >> On 2013-02-18 10:10, sea21 wrote:
> >>> It's "ldd (GNU libc) 2.3.3".
> >> That is an extremely
http://trac.sagemath.org/sage_trac/ticket/14155. I'm going to try to write
something.
David
On Wed, Feb 20, 2013 at 3:29 PM, kcrisman wrote:
> Huh, how did I miss that... William says:
>
> I think the optimal answer for gcd(Mod(5,6), 5) would be Mod(1,6), and
> the optimal answer for gcd(Mod(
On Wednesday, February 20, 2013 6:03:04 PM UTC+1, fhivert wrote:
>
> Hi Jean-Pierre,
>
> > > > * A parallel build (using the usual MAKE="make -jN") can speed up
> the
> > > > docbuilding time. Note that the speed-up factor is closer to N/2
> than to
> > > > N because two passes are neede
"D. S. McNeil" writes:
> I think this is a known issue: see
>
> http://groups.google.com/d/topic/sage-support/_LvmAECVeDg/discussion
Ah, I missed that too - ignore my previous post. Thanks :)
-Keshav
--
You received this message because you are subscribed to the Google Groups
"sage-devel" gro
kcrisman writes:
> This caused an interact in class today to break. Yikes. Why does
> this no longer work?
>
> --
> | Sage Version 5.7.rc0, Release Date: 2013-02-16
> |
> | Type "notebook()" for the browser-b
Huh, how did I miss that... William says:
I think the optimal answer for gcd(Mod(5,6), 5) would be Mod(1,6), and
the optimal answer for gcd(Mod(11,6), 5) would also be Mod(1,6)
Can you implement that? :-)
On Wednesday, February 20, 2013 5:12:21 PM UTC-5, D. S. McNeil wrote:
>
> On Wed, Feb 20,
On Wed, Feb 20, 2013 at 4:58 PM, kcrisman wrote:
> This caused an interact in class today to break. Yikes. Why does this no
> longer work?
>
> --
> | Sage Version 5.7.rc0, Release Date: 2013-02-16 |
> | Type
This caused an interact in class today to break. Yikes. Why does this no
longer work?
--
| Sage Version 5.7.rc0, Release Date: 2013-02-16 |
| Type "notebook()" for the browser-based notebook interface.
On Wednesday, February 20, 2013 11:30:08 AM UTC-5, Nathann Cohen wrote:
>
> Yep, same opinion : I think that it's ok. When I do it, it is because I
> think that it should not appear in the list of "tickets needing review",
> just in case somebody goes there to find something to review. It's not
Hi Jean-Pierre,
> > > * A parallel build (using the usual MAKE="make -jN") can speed up the
> > > docbuilding time. Note that the speed-up factor is closer to N/2 than to
> > > N because two passes are needed now.
> >
> > This is not quite true. I don't have precise timing. Put most of the
On Tuesday, February 19, 2013 7:40:43 PM UTC+1, fhivert wrote:
>
> Dear All,
>
> > * A parallel build (using the usual MAKE="make -jN") can speed up the
> > docbuilding time. Note that the speed-up factor is closer to N/2 than to
> > N because two passes are needed now.
>
> This is not q
Yep, same opinion : I think that it's ok. When I do it, it is because I
think that it should not appear in the list of "tickets needing review",
just in case somebody goes there to find something to review. It's not
funny to do so when half of the tickets needing review are actually totally
aba
Thank you all for the replies. Just going through the ticket list I had
compiled that I'd go through now.
~KnS
On Wed, Feb 20, 2013 at 9:38 PM, Jeroen Demeyer wrote:
> On 2013-02-20 17:04, Kannappan Sampath wrote:
> > Hello!!
> >
> > Is it considered good manners to change the status of a (need
On 2013-02-20 17:04, Kannappan Sampath wrote:
> Hello!!
>
> Is it considered good manners to change the status of a (needs_review)
> ticket to sth else (of course, other than giving (positive_review)) when
> you are not the reviewer, but the reviewer has left some comments
> indicating some work
I think that's fine. Tickets can have multiple reviewers. It's probably
good to give an explanation of why you're changing the status in a comment.
David
On Wed, Feb 20, 2013 at 9:04 AM, Kannappan Sampath wrote:
> Hello!!
>
> Is it considered good manners to change the status of a (needs_revie
Hello!!
Is it considered good manners to change the status of a (needs_review)
ticket to sth else (of course, other than giving (positive_review)) when
you are not the reviewer, but the reviewer has left some comments
indicating some work to be done or asking for some more information about
the pa
On Wed, Feb 20, 2013 at 5:25 AM, Volker Braun wrote:
> I agree that it would be nice if the non-notebook non-mathematical utility
> stuff were available independently. We could just have a sage.util
> submodule, say, with the convention that it must not import anything outside
> of sage.util. Then
IMHO there shouldn't be a warning printed when you can compute the correct
answer without the optional package. Every computation can be sped up with
a table of pre-computed values. The documentation should, of course,
mention that there is an optional spkg that can be used.
On Wednesday, Febr
I agree that it would be nice if the non-notebook non-mathematical utility
stuff were available independently. We could just have a sage.util
submodule, say, with the convention that it must not import anything
outside of sage.util. Then we could put all the cache decorators and
inspection and
On Wednesday, February 20, 2013 12:23:08 PM UTC+1, Simon King wrote:
>
> Hi!
>
> I currently work on making default arguments of __init__ automatically
> available to UniqueRepresentation, so that it won't be needed to
> override __classcall__ in order to deal with default arguments.
>
> Prob
2013/2/19 Jeroen Demeyer :
> On 2013-02-19 20:54, David Roe wrote:
>> I'm fairly sure the problem is that the defining polynomial for the
>> relative extension is not monic. One solution would be to use an
>> equivalent monic polynomial and keep track of a simple transformation
>> allowing one to
Hi!
I currently work on making default arguments of __init__ automatically
available to UniqueRepresentation, so that it won't be needed to
override __classcall__ in order to deal with default arguments.
Problem: I would need to determine the argspec of some __init__ methods
during startup, in pa
Dear all,
Is there any way to do this? I seem to remember seeing something like
is_package_installed in module_list.py.
Is it completely forbidden to have such ideas?
For #8335, we'd like to use the Cunningham table, but it's currently an
optional package, so if you try to use them, Sage will is
The big patches for coverage of rings (#13618 and #13685, both by Travis
Scrimshaw) pushed Sage over the 90%-coverage mark:
Overall weighted coverage score: 90.6%
Total number of functions: 31495
We need 1397 more functions to get to 95% coverage.
We need 2657 more functions to get to 99% covera
28 matches
Mail list logo
