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
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 (
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 pretty well. There's a
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 pretty well. There's a
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 as well :)
> > On 1/09/2016, at 19:
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 unsub
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 all
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
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
>
> a
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 message
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:
>
> /home/simon/sage/local/var/tmp/sa
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 just
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 ca
> ... 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 na
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 soluti
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 soluti
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
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 namespace when one can
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 Google
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
>>
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 giacp
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
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 CommutativeRings() in
> the
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 browser-based
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 just installed the li
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 i
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 o
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 b
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
Ooo
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 yo
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/ pac
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
Ok,
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
>> /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/lat
I did it triple-safe.
Doesn't seem to work. Here is the log.
-simon
On Friday, September 2, 2016 at 1:48:46 AM UTC+2, leif wrote:
>
> 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
34 matches
Mail list logo
