[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"

Simon Brandhorst wrote: > Thank you leif. Sorry for taking so long to answer. I did not bring my > laptop to work - so I could not get the log until now. Never mind. Please post / attach /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.log . > A workaround would

[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"

leif wrote: > Simon Brandhorst wrote: >> Thank you leif. Sorry for taking so long to answer. I did not bring my >> laptop to work - so I could not get the log until now. > > Never mind. Please post / attach > /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.log

Re: [sage-devel] Re: Declaring a parent in a category as a finite enumerated set

On Thursday, September 1, 2016 at 4:53:00 PM UTC+2, Daniel Krenn wrote: > > On 2016-09-01 01:47, Kwankyu Lee wrote: > > I am playing with an experimental implementation of "enumerated" axiom. > > From what I guess is, that this axiom implies an implementation of > __getitem__, correct? > If

Re: [sage-devel] Re: giacpy depends (silently) on SageObject

On 02/09/16 01:51, Michael Orlitzky wrote: On 09/01/2016 09:46 AM, leif wrote: Exactly. (See also my other reply.) It would be dumb and totally annoying if all such packages would get rebuilt upon *any* change to the Sage library, and just as bad as having to "manually" figure out /which/

[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"

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

Re: [sage-devel] tutte_polynomial tests

On Sep 1, 2016 09:46, "Francois Bissey" wrote: > > https://trac.sagemath.org/ticket/21355 > and > https://trac.sagemath.org/ticket/21289 > for the fix Ah, thanks! I searched my email for reference to it but not Trac. Should probably just subscribe to sage-trac

Re: [sage-devel] giacpy depends (silently) on SageObject

On 2016-08-31 23:26, Vincent Delecroix wrote: Hello, In the optional package giacpy there are some extension classes that depend on SageObject. Does it really only need SageObject? I see no reason why giacpy would need to do that. So the easiest solution seems to make giacpy *not* depend on

Re: [sage-devel] tutte_polynomial tests

https://trac.sagemath.org/ticket/21355 and https://trac.sagemath.org/ticket/21289 for the fix François > On 1/09/2016, at 19:39, Erik Bray wrote: > > Hi, > > Recently updated my Cygwin branch of Sage to merge in the latest > develop branch. For the most part it's gone

Re: [sage-devel] tutte_polynomial tests

https://trac.sagemath.org/ticket/21355 and https://trac.sagemath.org/ticket/21289 for the fix François > On 1/09/2016, at 19:39, Erik Bray wrote: > > Hi, > > Recently updated my Cygwin branch of Sage to merge in the latest > develop branch. For the most part it's gone

[sage-devel] tutte_polynomial tests

Hi, Recently updated my Cygwin branch of Sage to merge in the latest develop branch. For the most part it's gone pretty well. There's a test suite though for the sage.graphs.tutte_polynomial module (I have no idea what that is) which took a very long time after the update. Prior to the update

[sage-devel] Re: tutte_polynomial tests

Francois Bissey wrote: > https://trac.sagemath.org/ticket/21355 > and > https://trac.sagemath.org/ticket/21289 > for the fix And you may consider subscribing to sage-release... ;-) -leif -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"

Simon Brandhorst wrote: > So here are the logs. And a larger bit of the install.log Thanks, but we'd need the config.log files from Singular, not Sage's top-level one, in your case: /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.log and since omalloc takes an

[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"

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

[sage-devel] Categories catalog?

Should we move all categories in a catalog, e.g. rename FiniteSemigroups to categories.FiniteSemigroups Even if you think that categories belong in the top-level namespace, I think it would still be useful to have a catalog such that TAB-completion can give a list of all named categories in

[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"

leif wrote: > Simon Brandhorst wrote: >> So here are the logs. And a larger bit of the install.log > > Thanks, but we'd need the config.log files from Singular, not Sage's > top-level one, in your case: > > /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.log > >

[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"

On Thursday, September 1, 2016 at 8:48:13 AM UTC, leif wrote: > > Simon Brandhorst wrote: > > So here are the logs. And a larger bit of the install.log > > Thanks, but we'd need the config.log files from Singular, not Sage's > top-level one, in your case: > >

[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"

Dima Pasechnik wrote: > not sure whether it's worth the trouble fighting with outdated Singular > package refusing to work with > gcc 6.1.1. Perhaps it might be easier to use the bleeding edge > https://trac.sagemath.org/ticket/17635 and > https://trac.sagemath.org/ticket/17254 Well, he was

[sage-devel] Re: Categories catalog?

Jeroen Demeyer wrote: > Should we move all categories in a catalog, e.g. rename > > FiniteSemigroups > > to > > categories.FiniteSemigroups > > Even if you think that categories belong in the top-level namespace, I > think it would still be useful to have a catalog such that > TAB-completion

Re: [sage-devel] Re: Categories catalog?

> ... while you don't need a catalog to create such an alias. But then we would have even more stuff in the global namespace. > Still, having a catalog wouldn't be bad. +1 to having the catalogue. +1 to allowing aliases in that catalogue. +1 to removing not-very-common categories from global

Re: [sage-devel] Categories catalog?

On 2016-09-01 11:11, Jeroen Demeyer wrote: > Even if you think that categories belong in the top-level namespace, I > think it would still be useful to have a catalog such that > TAB-completion can give a list of all named categories in Sage. +1 for having a catalog. -- You received this

[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"

leif wrote: > Simon Brandhorst wrote: >> Thank you leif. Sorry for taking so long to answer. I did not bring my >> laptop to work - so I could not get the log until now. > > Never mind. Please post / attach > /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.log

[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"

leif wrote: > leif wrote: >> Simon Brandhorst wrote: >>> Thank you leif. Sorry for taking so long to answer. I did not bring my >>> laptop to work - so I could not get the log until now. >> >> Never mind. Please post / attach >>

Re: [sage-devel] giacpy depends (silently) on SageObject

On 01/09/16 04:34, Jeroen Demeyer wrote: On 2016-08-31 23:26, Vincent Delecroix wrote: Hello, In the optional package giacpy there are some extension classes that depend on SageObject. Does it really only need SageObject? I see no reason why giacpy would need to do that. So the easiest

Re: [sage-devel] disallow mixing of pos.char.ring elements and symbolic variables

On Tuesday, August 30, 2016 at 5:44:59 PM UTC+2, Jeroen Demeyer wrote: > > Is it easy to actually do that? > https://trac.sagemath.org/ticket/21391 This catches add,mul,pow which is sufficient IMHO to communicate the issue. -- You received this message because you are subscribed to the

[sage-devel] Re: Categories catalog?

On 2016-09-01, Johan S H Rosenkilde wrote: > +1 to removing not-very-common categories from global namespace as well. I agree. Now, as we have the axiom framework, it is very easy to create a specific category, and there is no need to have CommutativeRings() in the global

[sage-devel] Re: giacpy depends (silently) on SageObject

Vincent Delecroix wrote: > On 31/08/16 19:48, 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

Re: [sage-devel] giacpy depends (silently) on SageObject

On 01/09/16 04:34, Jeroen Demeyer wrote: On 2016-08-31 23:26, Vincent Delecroix wrote: Hello, In the optional package giacpy there are some extension classes that depend on SageObject. Does it really only need SageObject? I see no reason why giacpy would need to do that. So the easiest

Re: [sage-devel] Re: giacpy depends (silently) on SageObject

On 31/08/16 19:48, 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 solution

[sage-devel] Re: giacpy depends (silently) on SageObject

Vincent Delecroix wrote: > On 01/09/16 04:34, Jeroen Demeyer wrote: >> On 2016-08-31 23:26, Vincent Delecroix wrote: >>> Hello, >>> >>> In the optional package giacpy there are some extension classes that >>> depend on SageObject. >> >> Does it really only need SageObject? I see no reason why

[sage-devel] Re: Categories catalog?

Simon King wrote: > On 2016-09-01, Johan S H Rosenkilde wrote: >> +1 to removing not-very-common categories from global namespace as well. > > I agree. Now, as we have the axiom framework, it is very easy to create > a specific category, and there is no need to have

[sage-devel] line_profiler (%lprun) also broken from IPython upgrade

I just installed the line profiler because I want to do %lprun, but this is broken in 7.4.beta2 (likely is beta0) ┌┐ │ SageMath version 7.4.beta2, Release Date: 2016-08-26 │ │ Type "notebook()" for the

Re: [sage-devel] line_profiler (%lprun) also broken from IPython upgrade

these might be useful: https://github.com/rkern/line_profiler/issues/61 https://github.com/rkern/line_profiler/issues/62 https://github.com/rkern/line_profiler/pull/65 https://github.com/rkern/line_profiler/pull/68 Best S. * Travis Scrimshaw [2016-09-01 07:03:31]: >I

Re: [sage-devel] Re: Declaring a parent in a category as a finite enumerated set

On 2016-09-01 01:47, Kwankyu Lee wrote: > I am playing with an experimental implementation of "enumerated" axiom. >From what I guess is, that this axiom implies an implementation of __getitem__, correct? Does it also imply something on the index set (e.g. natural numbers) of this object? Or does

Re: [sage-devel] Re: giacpy depends (silently) on SageObject

On 09/01/2016 09:46 AM, leif wrote: > > Exactly. (See also my other reply.) > > It would be dumb and totally annoying if all such packages would get > rebuilt upon *any* change to the Sage library, and just as bad as having > to "manually" figure out /which/ packages might need rebuilding after

[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"

Thank you leif. Sorry for taking so long to answer. I did not bring my laptop to work - so I could not get the log until now. A workaround would be great. Then I can get started. Tried to build sage devel at work and got a different error. Should I open a thread for that as well? (If it works