On Wednesday, July 4, 2012 11:27:17 PM UTC+1, Michael Orlitzky wrote:
>
> 6 Principle of least surprise: most (all?) other external projects
> are distributed as SPKGs, so this one should be too unless there's
> a good reason not to.
>
If you rummage around in sage.misc then I think y
On 07/04/2012 06:07 PM, William Stein wrote:
> On Wed, Jul 4, 2012 at 11:45 AM, Michael Orlitzky
> wrote:
>> On 07/03/12 23:06, Keshav Kini wrote:
>>>
>>> IMO it's usually better to depend on someone else's code than to absorb
>>> it, because then you can more easily pick up bugfixes later, and a
On Wed, Jul 4, 2012 at 3:07 PM, William Stein wrote:
> Added the code as an spkg or to the Sage library unchanged (without
> adding doctests) is equivalent from this perspective. Code put in the
> sage library as a file unchanged is no more or less "absored" than
> code put in an spkg.
>
I dis
On Wed, Jul 4, 2012 at 11:45 AM, Michael Orlitzky wrote:
> On 07/03/12 23:06, Keshav Kini wrote:
>>
>> IMO it's usually better to depend on someone else's code than to absorb
>> it, because then you can more easily pick up bugfixes later, and also it
>> makes it clearer that we are benefiting from
On 07/03/12 23:06, Keshav Kini wrote:
>
> IMO it's usually better to depend on someone else's code than to absorb
> it, because then you can more easily pick up bugfixes later, and also it
> makes it clearer that we are benefiting from their work. To choose
> absorbing code instead of depending on
On Jul 4, 2012, at 3:46 PM, Goutam Paul wrote:
> Really need the contents.
>
> Got an error message:
> "There was an error uploading the worksheet. It could be an old
> unsupported format or worse. If you desperately need its contents
> contact the sage-support group and post a link to your works
Le mercredi 4 juillet 2012 06:50:24 UTC-4, David Loeffler a écrit :
>
> > On 4 July 2012 03:05, Maarten Derickx
> wrote:
> >> Dear All,
> >>
> >> Today I was trying to compute some stuff using modular symbols. And I
> found
> >> the following slightly worrying:
>
> Yup, this is definitely
On Wednesday, July 4, 2012 3:40:28 PM UTC+2, Volker Braun wrote:
>
> I've been thinking about this yesterday for some other reasons, and I
> think we should work towards getting rid of static libraries altogether.
> From a software distribution/maintenance/updating/testing point of view its
>
I've been thinking about this yesterday for some other reasons, and I think
we should work towards getting rid of static libraries altogether. From a
software distribution/maintenance/updating/testing point of view its really
terrible to have static libraries floating about without knowing for s
Dear all,
In the process of updating FLINT spkg to use upstream version 2.3, we're
updating the spkg-install script and came accross an old hack to be sure
that the shared library links to the shared library version of NTL.
But that's not really the problem here.
Indeed, building of the shared
Hi guys,
ticket 12806, upgrading 2 year old networkx 1.2 to version 1.6, needs an
extra review.
The technical part was already positively reviewed by Keshav Kini, but
Jeroen pointed
out a docbuild failure due to a tex error. I patched the problem, and now
need a new
review. The patch consists
> On 4 July 2012 03:05, Maarten Derickx wrote:
>> Dear All,
>>
>> Today I was trying to compute some stuff using modular symbols. And I found
>> the following slightly worrying:
Yup, this is definitely a bug. The "old submodule" it calculates isn't
Hecke-invariant:
sage: M.hecke_matrix(17).restr
+1 for just implementing lazy strings in the sage library.
Using speaklater for SAGE_TEMP is completely outside of the scope of the
upstream project. Its unlikely that we would contribute anything thats
useful for translations upstream, nor would we benefit from any further
translation specifi
You are setting elements one by one, which is really really slow over GF(2).
I'd rather set the 64-bit words directly.
On Wednesday 04 Jul 2012, Javier López Peña wrote:
> On Tuesday, July 3, 2012 9:19:50 PM UTC+1, Robert Bradshaw wrote:
> > You're right, one does want to ensure that there's a hi
On Tuesday, July 3, 2012 9:19:50 PM UTC+1, Robert Bradshaw wrote:
>
> You're right, one does want to ensure that there's a high probability
> of changing its rank. One could also change O(n) entries (one on each
> row/column) rather than all O(n^2). This will have a larger impact for
> large fi
It does look like a bug to me. I have CC'd sage-nt.
John
On 4 July 2012 03:05, Maarten Derickx wrote:
> Dear All,
>
> Today I was trying to compute some stuff using modular symbols. And I found
> the following slightly worrying:
>
> sage: M=ModularSymbols(Gamma1(22),sign=1)
> sage: S=M.cuspidal
David Roe writes:
> [ ] Import speaklater from sagenb
I should also mention, this doesn't literally mean import speaklater
*from* sagenb, since speaklater is not inside sagenb. It would just look
like::
import speaklater
Again, speaklater is just another separate PyPI package, like babel,
Le 04/07/2012 05:06, Keshav Kini a écrit :
IMO it's usually better to depend on someone else's code than to absorb
it, because then you can more easily pick up bugfixes later, and also it
makes it clearer that we are benefiting from their work. To choose
absorbing code instead of depending on it
I'm fine with any of:
> [ X ] Make speaklater a standard spkg
>
> [ ] Import speaklater from sagenb
>
> [ X ] Include speaklater.py in sage without any doctests.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-deve
19 matches
Mail list logo
