Hello !!
With this release I cannot building the doc ends with this :
[calculus ] Exception occurred:
[calculus ] File "ecl.pyx", line 337, in sage.libs.ecl.ecl_safe_eval
(sage/libs/ecl.c:4352)
[calculus ] RuntimeError: ECL says: Module error: Don't know how to REQUIRE
MAXIMA.
[calculus ] The f
On Sunday, May 25, 2014 3:11:21 AM UTC-7, Volker Braun wrote:
>
> New beta is out now, get it while its hot ;)
>
On two OS X 10.9 machines, I'm getting timeouts on some doctests. Here is a
sample of the output from "make ptestlong":
-
These are all due to the Singular interface..
I also see them relatively often but usually its only one or two that fail.
There was a bug in pexpect that got fixed in beta3, maybe you can try that
version and report back.
On Saturday, June 7, 2014 6:42:41 PM UTC+1, John H Palmieri wrote:
>
>
>
On Saturday, June 7, 2014 11:49:43 AM UTC-7, Volker Braun wrote:
>
> These are all due to the Singular interface..
>
> I also see them relatively often but usually its only one or two that
> fail. There was a bug in pexpect that got fixed in beta3, maybe you can try
> that version and report ba
On 2014-06-07, John H Palmieri wrote:
>
>
> On Saturday, June 7, 2014 11:49:43 AM UTC-7, Volker Braun wrote:
>>
>> These are all due to the Singular interface..
>>
>> I also see them relatively often but usually its only one or two that
>> fail. There was a bug in pexpect that got fixed in beta3,
On Saturday, June 7, 2014 12:09:50 PM UTC-7, John H Palmieri wrote:
>
>
>
> On Saturday, June 7, 2014 11:49:43 AM UTC-7, Volker Braun wrote:
>>
>> These are all due to the Singular interface..
>>
>> I also see them relatively often but usually its only one or two that
>> fail. There was a bug in
On Monday, June 9, 2014 1:50:17 PM UTC-7, John H Palmieri wrote:
>
>
>
> On Saturday, June 7, 2014 12:09:50 PM UTC-7, John H Palmieri wrote:
>>
>>
>>
>> On Saturday, June 7, 2014 11:49:43 AM UTC-7, Volker Braun wrote:
>>>
>>> These are all due to the Singular interface..
>>>
>>> I also see them r
Thanks for the investigative work!
Using the terminal echo isn't really a solution, maybe it doesn't fail as
often but it cannot work all the time. The terminal echo can and will
occasionally (rarely) be interleaved with the stdout.
Did I mention that I hate pexpect ;-)
--
You received this m
On Monday, June 9, 2014 3:55:52 PM UTC-7, Volker Braun wrote:
>
> Thanks for the investigative work!
>
> Using the terminal echo isn't really a solution, maybe it doesn't fail as
> often but it cannot work all the time. The terminal echo can and will
> occasionally (rarely) be interleaved with
Would need the maxima build log as that kind of stuff means that building
maxima.fas and
installing it failed.
Francois
On 26/05/2014, at 22:41, Nathann Cohen wrote:
> Hello !!
>
> With this release I cannot building the doc ends with this :
>
> [calculus ] Exception occurred:
> [calculus ]
> Would need the maxima build log as that kind of stuff means that building
> maxima.fas and
> installing it failed.
O_o
I do not remember the install saying that anything went wrong... O_o
Will give you this asap.
Nathann
--
You received this message because you are subscribed to the Google
sage -f ecl, followed by sage -f maxima did it for me.
On 26 May 2014 12:41, "Nathann Cohen" wrote:
> Hello !!
>
> With this release I cannot building the doc ends with this :
>
> [calculus ] Exception occurred:
> [calculus ] File "ecl.pyx", line 337, in sage.libs.ecl.ecl_safe_eval
> (sage/libs/e
I had the same problem. As I was in no hurry I just did a distclean
(doc-clean was not sufficient).
John
On 26 May 2014 11:58, Ralf Stephan wrote:
> sage -f ecl, followed by sage -f maxima did it for me.
>
> On 26 May 2014 12:41, "Nathann Cohen" wrote:
>>
>> Hello !!
>>
>> With this release I
> sage -f ecl, followed by sage -f maxima did it for me.
Did the job for me. Thanks ! :-)
nathann
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-release+
Alternatively, build with SAGE_UPGRADING=yes (this will check dependencies
and reinstall Maxima after ECL has been updated).
Peter
Op maandag 26 mei 2014 13:23:37 UTC+1 schreef Nathann Cohen:
>
> > sage -f ecl, followed by sage -f maxima did it for me.
>
> Did the job for me. Thanks ! :-)
>
>
> Alternatively, build with SAGE_UPGRADING=yes (this will check dependencies
> and reinstall Maxima after ECL has been updated).
What is the reason for not making this the default ?
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To un
On Monday, May 26, 2014 3:17:18 PM UTC+2, Nathann Cohen wrote:
>
> > Alternatively, build with SAGE_UPGRADING=yes (this will check
> dependencies
> > and reinstall Maxima after ECL has been updated).
>
> What is the reason for not making this the default ?
>
Lazyness?
--
You received this m
> Lazyness?
You are not lazy, and neither am I. Do we change that ? It seems that
setting this to False does not help in any way, least of all if it is
the default behaviour.
My problem is that I do not know how to change such things. Do you ?
Nathann
--
You received this message because you a
Nathann Cohen wrote:
Alternatively, build with SAGE_UPGRADING=yes (this will check dependencies
and reinstall Maxima after ECL has been updated).
What is the reason for not making this the default ?
I cannot currently edit your ~/.bashrc (nor your ~/.sage/sagerc *) ...
Whether we should mak
> Whether we should make it the default in the top-level Makefile has been
> discussed a couple of times in the past years, and IIRC most agreed we
> should do so, but so far even 'sudo open a ticket' failed.
I really do not know how such things are changed ...
Nathann
--
You received this mess
Nathann Cohen wrote:
Whether we should make it the default in the top-level Makefile has been
discussed a couple of times in the past years, and IIRC most agreed we
should do so, but so far even 'sudo open a ticket' failed.
I really do not know how such things are changed ...
E.g. by simply a
> E.g. by simply adding the lines
>
> SAGE_UPDGRADING ?= yes
> export SAGE_UPGRADING
I know how to fix "my" problem, I just don't know how to fix Sage.
> (And I originally only wanted to add an additional target 'upgrade', setting
> the variable to 'yes' and depending on 'build'. When 'yes' is t
On Monday, May 26, 2014 3:39:33 PM UTC+2, Nathann Cohen wrote:
>
> > Whether we should make it the default in the top-level Makefile has been
> > discussed a couple of times in the past years, and IIRC most agreed we
> > should do so, but so far even 'sudo open a ticket' failed.
>
> I really d
> Open a ticket and someone might feel less lazy :)
I don't believe in opening tickets without writing the patch and
setting them to needs_review :-P
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group and st
Nathann Cohen wrote:
E.g. by simply adding the lines
SAGE_UPDGRADING ?= yes
export SAGE_UPGRADING
I know how to fix "my" problem, I just don't know how to fix Sage.
To the top-level *Makefile* that is. ('?=' is not [ba]sh syntax AFAIK.)
(And I originally only wanted to add an additional
On Monday, May 26, 2014 4:14:56 PM UTC+2, Nathann Cohen wrote:
>
> > Open a ticket and someone might feel less lazy :)
>
> I don't believe in opening tickets without writing the patch and
> setting them to needs_review :-P
>
Set them to "blocker".
That will get the release manager attention.
Yoo !!
>> Why would we need a buggy upgrade script ?
>
> Backwards compatibility. And I personally don't want ATLAS to get rebuilt
> just because someone decided to change the spkg-install script of readline
> such that Python gets rebuilt upon which unfortunately ATLAS depends, just
Nathann Cohen wrote:
(And I originally only wanted to add an additional target 'upgrade', setting
the variable to 'yes' and depending on 'build'. When 'yes' is the default,
I don't know what the opposite target should be called;
'quick-and-dirty-upgrade-not-really-rebuilding-dependent-packages'
Nathann Cohen wrote:
Yoo !!
Why would we need a buggy upgrade script ?
Backwards compatibility. And I personally don't want ATLAS to get rebuilt
just because someone decided to change the spkg-install script of readline
such that Python gets rebuilt upon which unfortunately ATLAS
You have my attention. We can of course wait with any future releases until
somebody fixes this.
In an ideal world we would have reliable library versioning, so you
wouldn't need to rebuild maxima UNLESS the ecl library version changes in
an incompatible way (which can be read off from the name
I have reread this thread and I'm asking myself if the ecl upgrade
shouldn't have simply bumped the package-version.txt of maxima at
patchlevel, thus forcing a rebuild. I mean the author of that ticket surely
had the same fail when testing, and the reviewer too?
Please tell what I'm missing.
Reg
On Tuesday, May 27, 2014 6:02:20 AM UTC+2, Ralf Stephan wrote:
>
> I have reread this thread and I'm asking myself if the ecl upgrade
> shouldn't have simply bumped the package-version.txt of maxima at
> patchlevel, thus forcing a rebuild. I mean the author of that ticket surely
> had the same
On Monday, May 26, 2014 10:08:19 PM UTC+8, leif wrote:
>
> Nathann Cohen wrote:
> >> Whether we should make it the default in the top-level Makefile has
> been
> >> discussed a couple of times in the past years, and IIRC most agreed we
> >> should do so, but so far even 'sudo open a ticket' f
John Palmieri recently helped me with a ticket (#16350) where the
spkg-install
of a package was changed but that was not enough to trigger the necessary
rebuild. That could be accomplished by adding '.p0' to the
package-version.txt
because patch level changes don't change the actual version string
P Purkayastha wrote:
On Monday, May 26, 2014 10:08:19 PM UTC+8, leif wrote:
Nathann Cohen wrote:
>> Whether we should make it the default in the top-level Makefile
has been
>> discussed a couple of times in the past years, and IIRC most
agreed we
>> should do so, but s
Ralf Stephan wrote:
John Palmieri recently helped me with a ticket (#16350) where the
spkg-install
of a package was changed but that was not enough to trigger the necessary
rebuild. That could be accomplished by adding '.p0' to the
package-version.txt
because patch level changes don't change the
Hello,
John Palmieri recently helped me with a ticket (#16350) where the
> spkg-install
> of a package was changed but that was not enough to trigger the necessary
> rebuild. That could be accomplished by adding '.p0' to the
> package-version.txt
> because patch level changes don't change the ac
On Tuesday, May 27, 2014 4:09:11 AM UTC-7, leif wrote:
>
> P Purkayastha wrote:
> > On Monday, May 26, 2014 10:08:19 PM UTC+8, leif wrote:
> >
> > Nathann Cohen wrote:
> > >> Whether we should make it the default in the top-level Makefile
> > has been
> > >> discussed a co
John H Palmieri wrote:
On Tuesday, May 27, 2014 4:09:11 AM UTC-7, leif wrote:
P Purkayastha wrote:
> Just use "sage --upgrade"
Yes, that's what ordinary users should use (and developers /pulling/ a
new [devel] version, instead of 'git pull ... && make').
I just tried this: I w
John H Palmieri wrote:
On Sunday, May 25, 2014 3:11:21 AM UTC-7, Volker Braun wrote:
New beta is out now, get it while its hot ;)
On two OS X 10.9 machines, I'm getting timeouts on some doctests.
That's presumably because it's no longer hot.
Do you also get (the same?) timeouts when rer
On 9 June 2014 23:55, Volker Braun wrote:
> Thanks for the investigative work!
>
> Using the terminal echo isn't really a solution, maybe it doesn't fail as
> often but it cannot work all the time. The terminal echo can and will
> occasionally (rarely) be interleaved with the stdout.
>
> Did I men
John Cremona wrote:
On 9 June 2014 23:55, Volker Braun wrote:
Thanks for the investigative work!
Using the terminal echo isn't really a solution, maybe it doesn't fail as
often but it cannot work all the time. The terminal echo can and will
occasionally (rarely) be interleaved with the stdout.
On 10 June 2014 09:53, leif wrote:
> John Cremona wrote:
>>
>> On 9 June 2014 23:55, Volker Braun wrote:
>>>
>>> Thanks for the investigative work!
>>>
>>> Using the terminal echo isn't really a solution, maybe it doesn't fail as
>>> often but it cannot work all the time. The terminal echo can an
John Cremona wrote:
On 10 June 2014 09:53, leif wrote:
John Cremona wrote:
On 9 June 2014 23:55, Volker Braun wrote:
Thanks for the investigative work!
Using the terminal echo isn't really a solution, maybe it doesn't fail as
often but it cannot work all the time. The terminal echo can an
On 10 June 2014 10:23, leif wrote:
> John Cremona wrote:
>>
>> On 10 June 2014 09:53, leif wrote:
>>>
>>> John Cremona wrote:
On 9 June 2014 23:55, Volker Braun wrote:
>
>
> Thanks for the investigative work!
>
> Using the terminal echo isn't really a solution,
On Tue, Jun 10, 2014 at 10:53 AM, leif wrote:
> R isn't used in Sage library code AFAIK.
>
There is one place in sage/stats/r.py which basically go away and be
replace by an rpy2 call.
> Not sure whether the library interfaces offer the full functionality [yet].
rpy2 can do everything what R ca
46 matches
Mail list logo
