So here are the logs. And a larger bit of the install.log
singular-3.1.7p1.p2] loading cache .././config.cache
[singular-3.1.7p1.p2] checking whether make -j1 sets ${MAKE}... (cached) yes
[singular-3.1.7p1.p2] checking for gcc... (cached) gcc
[singular-3.1.7p1.p2] checking whether the C compiler (
Dear leif, dear Nils,
Thank you for your replies.
> That's obviously wrong. It should get 8 there. You might want to do a:
>
> $ grep "size of long" install.log
>
$grep "size of long" install.log
[python2-2.7.10.p2] checking size of long... 8
[python2-2.7.10.p2] checking size of long long... 8
One more nice example.
sage -t src/sage/combinat/integer_vector_weighted.py
**
File "src/sage/combinat/integer_vector_weighted.py", line 125, in
sage.combinat.integer_vector_weighted.WeightedIntegerVectors_all.__init__
Failed exa
I am playing with an experimental implementation of "enumerated" axiom. The
results are interesting.
sage -t src/sage/combinat/posets/posets.py
**
File "src/sage/combinat/posets/posets.py", line 755, in
sage.combinat.posets.pose
leif wrote:
> leif wrote:
>> leif wrote:
>>> Vincent Delecroix wrote:
Hello,
In the optional package giacpy there are some extension classes that
depend on SageObject. Hence if I do some modification to SageObject and
perform "make" the giacpy package is broken. Is there a
leif wrote:
> leif wrote:
>> Vincent Delecroix wrote:
>>> Hello,
>>>
>>> In the optional package giacpy there are some extension classes that
>>> depend on SageObject. Hence if I do some modification to SageObject and
>>> perform "make" the giacpy package is broken. Is there a solution to
>>> rebui
leif wrote:
> Vincent Delecroix wrote:
>> Hello,
>>
>> In the optional package giacpy there are some extension classes that
>> depend on SageObject. Hence if I do some modification to SageObject and
>> perform "make" the giacpy package is broken. Is there a solution to
>> rebuild external packages
Vincent Delecroix wrote:
> Hello,
>
> In the optional package giacpy there are some extension classes that
> depend on SageObject. Hence if I do some modification to SageObject and
> perform "make" the giacpy package is broken. Is there a solution to
> rebuild external packages that depends on sag
Hello,
In the optional package giacpy there are some extension classes that
depend on SageObject. Hence if I do some modification to SageObject and
perform "make" the giacpy package is broken. Is there a solution to
rebuild external packages that depends on sagelib when doing "make"?
Cheers,
Simon Brandhorst wrote:
> So far I am using precompiled binaries. They work. Now I am thinking on
> writing my own branch/contributing to sage so I followed the instructions on
>
> http://doc.sagemath.org/html/en/developer/walk_through.html
>
> to get a developer version of sage.
> Basically I ju
On Wednesday, August 31, 2016 at 12:38:51 PM UTC-7, Simon Brandhorst wrote:
>
> So far I am using precompiled binaries. They work. Now I am thinking on
> writing my own branch/contributing to sage so I followed the instructions on
>
> http://doc.sagemath.org/html/en/developer/walk_through.html
>
>
Just in case some more hardware details:
Architecture: x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):8
On-line CPU(s) list: 0-7
Thread(s) per core:2
Core(s) per socket:4
Socket(s): 1
NUMA node(s): 1
So far I am using precompiled binaries. They work. Now I am thinking on
writing my own branch/contributing to sage so I followed the instructions on
http://doc.sagemath.org/html/en/developer/walk_through.html
to get a developer version of sage.
Basically I just typed
git clone git://github.com/
Sorry for posting twice. Got confused after the first time since the post
did not appear right away.
I can do the next step and open a ticket. Though first I have to get the
source code of sage compiled... (was working with binaries before)
I'll post the log file in another thread.
On Wednesd
On Wed, Aug 31, 2016 at 6:14 PM, Travis Scrimshaw wrote:
> I was able to get Cygwin64 to build successfully using 7.4.beta2 + Pynac
> 0.6.9 upgrade (#21369) + interpreter hack (#19868). I did have an issue with
> twisted not picking up zope_interface, but I was able to fix it by forcing a
> reinst
I was able to get Cygwin64 to build successfully using 7.4.beta2 + Pynac
0.6.9 upgrade (#21369) + interpreter hack (#19868). I did have an issue
with twisted not picking up zope_interface, but I was able to fix it by
forcing a reinstall of zope_interface and then building twisted again.
For Cyg
On 31 August 2016 at 16:24, leif wrote:
> John Cremona wrote:
> > Indeed, that is a bug in line 371 of the file
> > sage/modules/free_quadratic_module.py -- an easy fix.
>
> ... and more than 8 years old.
>
> The check whether the rank is even or not is useless as well; '//' in
> Python is intege
John Cremona wrote:
> Indeed, that is a bug in line 371 of the file
> sage/modules/free_quadratic_module.py -- an easy fix.
... and more than 8 years old.
The check whether the rank is even or not is useless as well; '//' in
Python is integer division (taking the floor).
(And the docstrings don'
yes, indeed this is a bug. Thanks for reporting.
Would you like to make the next step to solve that ? Then you should ask
for an account on trac.sagemath.org and open a ticket.
Instructions are available here:
http://www.sagemath.org/git-developer-guide/
Frederic
Le mercredi 31 août 2016 15:3
On 31/08/16 02:36, Ralf Stephan wrote:
On Tuesday, August 30, 2016 at 5:45:16 PM UTC+2, vdelecroix wrote:
sage: x = SR.variable(domain = GF(3))
sage: n = SR.variable(domain = ZZ)
This is good design(TM). The usage however duplicates
Sage's polynomial rings,so why burden calculus with that?
Indeed, that is a bug in line 371 of the file sage/
modules/free_quadratic_module.py -- an easy fix.
Perhaps someone ought to look through all occurrences of ^ in .py files
outside of docstrings (where they are OK thanks to preparsing).
John
On 31 August 2016 at 13:44, Simon Brandhorst wrote:
Dear all,
the first ever workshop for women in Sage in Europe (the previous ones were
in the US) will be organized January 9 - 13, 2017 by Jessica Striker,
Jennifer Balakrishnan, and myself.
We will rent a house in Paris area and organize coding sprints, tutorials,
and presentations.
All Sage le
{{{
sage: q=FreeQuadraticModule(ZZ,2,inner_product_matrix=1)
sage: q
Ambient free quadratic module of rank 2 over the principal ideal domain
Integer Ring
Inner product matrix:
[1 0]
[0 1]
sage: q.determinant()
1
sage: q.discriminant()
-2
}}}
This output is wrong. The discriminant should be -1.
{
sage: q=FreeQuadraticModule(ZZ,2,inner_product_matrix=1)
sage: q
Ambient free quadratic module of rank 2 over the principal ideal domain
Integer Ring
Inner product matrix:
[1 0]
[0 1]
sage: q.determinant()
1
sage: q.discriminant()
-2
}
#The expected value here is -1
The following example shoul
leif wrote:
> Erik Bray wrote:
>> On Tue, Aug 30, 2016 at 10:12 PM, Jeroen Demeyer
>> wrote:
>>> On 2016-08-30 19:44, leif wrote:
Anyway, our current policy is that *only* the release manager is allowed
to close tickets, so I wouldn't do without first asking.
>>>
>>>
>>> I have the
Erik Bray wrote:
> On Tue, Aug 30, 2016 at 10:12 PM, Jeroen Demeyer
> wrote:
>> On 2016-08-30 19:44, leif wrote:
>>>
>>> Anyway, our current policy is that *only* the release manager is allowed
>>> to close tickets, so I wouldn't do without first asking.
>>
>>
>> I have the "power" to close ticke
I'm surprised at the apparent consensus that the only solution is to
re-implement "verbose" by some totally different method. I came across this
issue before and I found a perfectly acceptable fix, which I didn't bother
to make a ticket for because I didn't know if anyone else cared about this
issu
Erik Bray wrote:
> On Wed, Aug 31, 2016 at 1:02 AM, leif wrote:
>> leif wrote:
>>> Dima Pasechnik wrote:
On Tuesday, August 30, 2016 at 5:20:37 PM UTC, leif wrote:
FWIW, I now have *significant* delay in (apparently) *all*
notifications
from trac, even bet
On Wed, Aug 31, 2016 at 1:02 AM, leif wrote:
> leif wrote:
>> Dima Pasechnik wrote:
>>>
>>> On Tuesday, August 30, 2016 at 5:20:37 PM UTC, leif wrote:
>>>
>>> FWIW, I now have *significant* delay in (apparently) *all*
>>> notifications
>>> from trac, even between those for the same tic
On Tue, Aug 30, 2016 at 10:12 PM, Jeroen Demeyer wrote:
> On 2016-08-30 19:44, leif wrote:
>>
>> Anyway, our current policy is that *only* the release manager is allowed
>> to close tickets, so I wouldn't do without first asking.
>
>
> I have the "power" to close tickets, but I don't do that becau
Le mardi 30 août 2016 19:33:20 UTC+2, leif a écrit :
> > Making R optional *will* break existing code.
>
> How do you come to that conclusion?
>
To be precise : any code relying on R being standard and using it without
bothering checking this assumption.
I have such code myself (e. g. a cou
Hi,
i noticed that one hour ago after Frederic told me there was an issue, i
relaunched the patchbot after some cleanup.
Thanks for the reporting anyway !
Ciao,
Thierry
On Wed, Aug 31, 2016 at 10:57:17AM +0200, Jeroen Demeyer wrote:
> The patchbot tmonteil-debian-jessie-32 is spamming all tic
On 2016-08-30 23:10, Dima Pasechnik wrote:
please post (or email me) headers in an example of your message.
Here is a worse example, a delay of 2 hours and 40 minutes:
Received: from o1.30nn.fshared.sendgrid.net
(o1.30nn.fshared.sendgrid.net [167.89.55.59])
(using TLSv1.2 with ciphe
On 2016-08-30 23:10, Dima Pasechnik wrote:
please post (or email me) headers in an example of your message.
Just an example of one notification with a small delay. Here you see a
delay of 6 minutes (note the different timezone, CEST==UTC+2).
[...]
Received: from o1.30nn.fshared.sendgrid.net
The patchbot tmonteil-debian-jessie-32 is spamming all tickets as
BuildFailed because of "No space left on device".
See for example
https://patchbot.sagemath.org/log/21126/debian/8.3/i686/3.16.0-4-586/tmonteil-debian-jessie-32/2016-08-31%2001:20:27?short
--
You received this message because y
35 matches
Mail list logo
