On May 6, 9:12 pm, David Joyner wrote:
> Hi:
>
> The contribution at #10153 by Thomas Feulner is huge and,
> IMHO, important. It basically generalizes what Robert Miller did for
> automorphisms of codes in the binary case to the non-binary
> case. Robert himself has run the valgrind on the doct
On Fri, May 6, 2011 at 2:19 PM, Ondrej Certik wrote:
> On Fri, May 6, 2011 at 11:26 AM, Robert Bradshaw
> wrote:
> [...]
>> Were I to design the system from scratch, I'd put
>> all our code (devel/scripts/...) in a single repo, along with the
>> top-level files, and a list of dependencies (spkgs)
On Fri, May 6, 2011 at 11:26 AM, Robert Bradshaw
wrote:
[...]
> Were I to design the system from scratch, I'd put
> all our code (devel/scripts/...) in a single repo, along with the
> top-level files, and a list of dependencies (spkgs). Building sage
> would fetch (locally or remotely) the depende
On Fri, May 6, 2011 at 11:41 AM, Martin Albrecht
wrote:
>> The other problem is that so much isn't under revision control (eg.
>> what versions of spkgs to use), or in multiple repositories that need
>> to be kept in sync. Were I to design the system from scratch, I'd put
>> all our code (devel/sc
> The other problem is that so much isn't under revision control (eg.
> what versions of spkgs to use), or in multiple repositories that need
> to be kept in sync. Were I to design the system from scratch, I'd put
> all our code (devel/scripts/...) in a single repo, along with the
> top-level files
On Fri, May 6, 2011 at 12:12 AM, Keshav Kini wrote:
> Hi Jeroen,
>
> I'd suggest that SPKG authors make their final commit themselves rather than
> just allowing Jeroen's script to do it for them - this keeps the "blame
> history" intact (assuming Jeroen's script doesn't mine people's names from
>
On Fri, May 6, 2011 at 8:26 AM, Jeroen Demeyer wrote:
> On 2011-05-06 15:26, Dr. David Kirkby wrote:
>> So, it it was possible to protect against that, I think it would be a
>> good idea.
> One check could be done in the merger script:
> If the new and old spkgs have the same upstream version (i.e
On Fri, May 6, 2011 at 6:26 AM, Dr. David Kirkby
wrote:
> On 05/ 6/11 10:08 AM, Jeroen Demeyer wrote:
>>
>> On 2011-05-05 23:42, Dr. David Kirkby wrote:
>>>
>>> I've often wondered if it would be possible to safely remove the write
>>> permissions from the "src" directory and everything below it,
On Fri, May 6, 2011 at 12:24 AM, Keshav Kini wrote:
> Hi Simon,
>
> There is no 4.7 yet, so I'm not sure how the patchbot can do what you want.
> Robert Bradshaw has set up the patchbot to work from the last stable
> release, which is 4.6.2. You may need to rebase your entire ticket (with its
> in
On May 6, 9:18 am, Nils Bruin wrote:
> A basic implementation would be to insist that W=W1=W2 and then
> compute M1+M2 = (V1+V2)/W and M1.intersect(M2) = V1.intersect(V2)/W .
> This seems to work with naively created submodules (coming from
> kernels and images of morphisms, for instance), but wil
On May 5, 2:56 am, Guilherme wrote:
> IDA is shown as the last on the series DASSL -> DASPK -> IDA.
> Sundials is C ++(?) coded.
>
> Could you handle Mass matrix with DASSL?
DASSL handles implicit ODEs of the form F(t, x, x') = 0, so I think it
would work for non-constant mass matrices too, b
On May 4, 10:04 pm, Thierry Dumont wrote:
> Do you mean that it is possible to define the RHS as a Cython *callback*
> function? or is there an other trick ? Can you give me a pointer to that ?
The code can for instance be found in the file sage/gsl/ode.pyx (the
gsl directory has other classes
On May 5, 2:37 pm, Rob Beezer wrote:
> Without time to experiment and refresh my memory from many months ago
> - can you not just use the intersection method that already exists,
> but with a pair of submodules?
Unfortunately, they do not exist on FGP_Module. They do on free
modules. There
F1+F2
On 2011-05-06 15:26, Dr. David Kirkby wrote:
> So, it it was possible to protect against that, I think it would be a
> good idea.
One check could be done in the merger script:
If the new and old spkgs have the same upstream version (i.e. the
version numbers are the same except for the patch level),
Hi Keshav,
On 6 Mai, 09:24, Keshav Kini wrote:
> There is no 4.7 yet, so I'm not sure how the patchbot can do what you want.
OK.
> Robert Bradshaw has set up the patchbot to work from the last stable
> release, which is 4.6.2. You may need to rebase your entire ticket (with its
> instructions f
On 05/ 6/11 10:08 AM, Jeroen Demeyer wrote:
On 2011-05-05 23:42, Dr. David Kirkby wrote:
I've often wondered if it would be possible to safely remove the write
permissions from the "src" directory and everything below it, so files
can't be accidentally changed.
I believe that would reduce the c
Hi:
The contribution at #10153 by Thomas Feulner is huge and,
IMHO, important. It basically generalizes what Robert Miller did for
automorphisms of codes in the binary case to the non-binary
case. Robert himself has run the valgrind on the doctests for #10153
and says that none of the doctests in
[message by Karim Belabas copied from PARI mailing list]
[updating PARI in Sage: #11130]
Dear PARI lovers,
I would like to announce the release of pari-2.4.4-BETA. The sources
are available at the address
http://pari.math.u-bordeaux.fr/download.html
The testing development branch is now matu
OK, so on my OSX 10.5 PPC "make test" passed without errors, after I
applied #11297.
On May 6, 11:32 am, Dima Pasechnik wrote:
> On May 5, 5:44 pm, Francois Bissey
> wrote:
>
>
>
>
>
> > > On May 5, 6:35 am, Francois Bissey
>
> > > wrote:
> > > > > On May 4, 8:43 pm, Francois Bissey
>
> > > >
Dear Guilherme and rest of the developers,
I am not an specialist in DAE at all, but I just wanted to point out
that the function desolve_odeint on version >=4.6 already supports
stiff systems (via the BDF method). If you look at the documentation
of desolve_odeint you will find the example
#Anot
The semantics of SAGE64 is "force build 64 bit, even if the toolchain
defaults to 32 bit". The only implication is
SAGE64==yes => sage.misc.misc.is_64_bit==True
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-de
On 2011-05-05 23:42, Dr. David Kirkby wrote:
> I've often wondered if it would be possible to safely remove the write
> permissions from the "src" directory and everything below it, so files
> can't be accidentally changed.
>
> I believe that would reduce the chances of the "src" being corrupted.
Hi!
On an installation of Sage on bsd.math, I obtain
sage: sage.misc.misc.is_64_bit
True
sage: sage.misc.misc.is_32_bit
False
sage: os.environ['SAGE64']
'no'
Is that a bug? After all, I have built that installation without
setting SAGE64, and apparently SAGE64 is not "yes". Or what is
Hi Simon,
There is no 4.7 yet, so I'm not sure how the patchbot can do what you want.
Robert Bradshaw has set up the patchbot to work from the last stable
release, which is 4.6.2. You may need to rebase your entire ticket (with its
instructions for dependencies etc.) on 4.6.2, or include as dep
Hi Jeroen,
I'd suggest that SPKG authors make their final commit themselves rather than
just allowing Jeroen's script to do it for them - this keeps the "blame
history" intact (assuming Jeroen's script doesn't mine people's names from
SPKG.txt and commit under those names!).
I sometimes worry
25 matches
Mail list logo
