txt
> which is
>
> openblas-devel
>
> Most probably the pc file for openblas will be there, and we would not
> have to try solving this puzzle for you
>
> first do
>
> make openblas-clean
>
> to remove (broken?) Sage installation of
> openblas.
>
>
&g
source.
On Monday, May 17, 2021 at 9:08:07 AM UTC-7 dim...@gmail.com wrote:
>
>
> On Mon, 17 May 2021, 16:42 Richard_L, wrote:
>
>> What I find in common for the 7 failures is:
>> "/home/rllozes/sage-9.3/local/lib/libopenblas.so.0(zgemm_kernel_n+0x9d)[0x7f2b0f
2:32:59 AM UTC-7 dim...@gmail.com wrote:
> On Sun, May 16, 2021 at 4:26 PM Richard_L wrote:
> >
> > 'make ptestlong' gave the following error summary on a new build from
> source:
> >
> > --
> >
'make ptestlong' gave the following error summary on a new build from
source:
--
sage -t --long --warn-long 103.3 --random-seed=0
src/sage/calculus/riemann.pyx # Killed due to illegal instruction
sage -t --long --warn-long
Thanks.
On Tuesday, December 15, 2020 at 10:02:12 AM UTC-8 Michael Orlitzky wrote:
> On 10/1/20 6:05 PM, Richard_L wrote:
> > I get the above message when I ask SageMath 9.1 to swallow a large
> > expression (attached file). Is anyone else seeing this message?
> &g
I get the above message when I ask SageMath 9.1 to swallow a large
expression (attached file). Is anyone else seeing this message?
All variables are declared real. The message did not show up until I
started using 9.1
For now, my workaround is to raise the recursion limit:
import sys
> integrals
> is to observe that the integral of a sum is the sum of the integrals,
> there is
> very little use for such a table.
>
>
> On Monday, December 16, 2019 at 7:14:02 AM UTC-8, Richard_L wrote:
>>
>> Apparently, someone disagrees. See Ernest Lampl
You could e-mail the authors, now that you have names and addresses.
Maybe they'd part with source.
On Monday, December 16, 2019 at 7:39:11 AM UTC-8, Dima Pasechnik wrote:
>
>
>
> On Mon, 16 Dec 2019, 15:14 Richard_L, >
> wrote:
>
>> Apparently, someone disagrees.
Apparently, someone disagrees. See Ernest Lample's posting to the arXiv:
https://arxiv.org/abs/1912.05752
On Friday, September 27, 2019 at 8:06:31 AM UTC-7, Dima Pasechnik wrote:
>
> https://openreview.net/pdf?id=S1eZYeHFDS
>
> I wish they had code available...
>
--
You received this message
Since converting all my old noteboks over to Jupyter, and making pretty
printing my default, I have seen 404 errors in the console log. These look
something like:
> 404 GET
> /nbextensions/mathjax/fonts/HTML-CSS/TeX/otf/MathJax_AMS-Regular.otf
> (127.0.0.1) 2.94ms
>
Dima,
If it were reproducible behavior, I would definitely post a notebook. As
things stand, I think it best to wait for the problem to re-occur.
As to your other questions, I run Firefox 60.7.2esr on openSUSE 42.3, and
build with gcc 6.2.1.
--
You received this message because you are
That behavior seems to be transient.
After closing down sage completely and restarting, the echo is no longer
evident.
I see that, just before the echoing began, there is a crash message:
2019-07-17T11:47:54-0700 [__builtin__.QuietSite#info] Starting factory
<__builtin__.QuietSite instance at
I have just built sagemath 8.8, with no errors during build or during
testing (ptestlong).
Now when I run previous notebooks, I see that all input and output is
echoed to stdout (console). This is new behavior since sagemath 8.5, which
is what I ran until today.
Is this a 'feature' of this
Continuing with the example first discussed on ask.sagemath.org and
graciously corrected/answered by Eric G, I now find that setting *nproc* to
anything but *1* in the following will cause the last line to give
incorrect results.
I am running sagemath version 8.5. According to trac, this
+1 for "_SAGE_FUNC". The user should not have to think about the Maxima
pre-defined name space unless s/he wants to use a Maxima function:
"When I use a word, it means what I choose it to mean, neither more nor
less."
-- Humpty-Dumpty
On Tuesday, February 26, 2019 at 10:33:23 AM UTC-8, Nils
Thanks, Eric.
I never would have guessed that I could not use the most common notation in
quantum mechanics!
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
I set up a 3-dimensional Euclidean manifold, defining both Cartesian and
spherical coordinates, charts, and frames..
Next, I define a scalar field:
> psi = E.scalar_field({c_E: function('psi')(r,th,ph)},
> name='psi',latex_name='\psi')
>
See attached file "Euclid.sage" for details
Now,
I neglected to note that I am running 'SageMath version 8.5, Release Date:
2018-12-22'
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Is this potentially the same bug as Maxima's #3324?
(to which both Robert and Nils contributed last year)
Advice please: Should I start a new ticket at Maxima, or add to the old one?
Thanks
On Wednesday, June 20, 2018 at 11:57:58 AM UTC-7, Richard_L wrote:
>
> Thank you.
> Now
Thank you.
Now to report the bug.
On Wednesday, June 20, 2018 at 11:15:36 AM UTC-7, Nils Bruin wrote:
>
> On Wednesday, June 20, 2018 at 10:12:24 AM UTC-7, Richard_L wrote:
>>
>> ..."domain:complex" is not the default for which code: Maxima or Sage?
>>
>
at it happens before I get the
sage prompt. (Otherwise the override would get stomped on.)
On Wednesday, June 20, 2018 at 8:33:56 AM UTC-7, Nils Bruin wrote:
>
> On Wednesday, June 20, 2018 at 7:15:11 AM UTC-7, Richard_L wrote:
>>
>> Thank you! maxima_calculus.eval(&qu
e same bug.
On Tuesday, June 19, 2018 at 3:22:07 PM UTC-7, Nils Bruin wrote:
>
> On Tuesday, June 19, 2018 at 2:30:46 PM UTC-7, Richard_L wrote:
>>
>> It would be useful if one could override Sage's default "domain:complex",
>> at least until the Maxima fix comes through.
There are several ways to avoid the seg-fault. Consider this script:
> display2d:false$
> domain:complex; /*setting domain to real causes success in
> all cases below*/
> declare([m1,m2,m3],real);
> declare([r12,r13,r23],real);
> assume(r12>0,r13>0,r23>0);
> assume(r12
See also Robert Dodier's related thread showing that Maxima seems not to be
the culprit.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
See also Robert Daudier's related thread showing that Maxima seems not to
be the culprit.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
I attach here
1. a stripped-down Sage script,
2. a PDB script which leads to the failing statement.
The failing Sage code reads:
> >
> /home/rllozes/Development/sage/local/lib/python2.7/site-packages/sage/interfaces/maxima_lib.py(452)_eval_line()
> -> result = ((result + '\n') if
I will post the failing Sage call on the original thread, along with the
full PDB script.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
That appears to be what I'm running via the Sage interface:
[sage-beta is my soft-link to sage-8.3-beta5]
rllozes@linux-yzi3:~/temp> sage-beta --maxima
;;; Loading
#P"/home/rllozes/Development/sage/local/lib/ecl/sb-bsd-sockets.fas"
;;; Loading
I can find.
- Richard
On Thursday, June 14, 2018 at 3:13:55 PM UTC-7, Nils Bruin wrote:
>
> On Thursday, June 14, 2018 at 1:45:12 PM UTC-7, Richard_L wrote:
>>
>>
>> Might anyone have a work-around please?
>>
>> Delete the assumptions and the domain decl
Last year I reported failure of this simple matrix inversion. Despite an
updated Maxima (8.3.beta3), this problem persists.
I attach the simplest sage source causing the error, along with a log.
Given that the error messages are identical to last year, I conclude that
maxima / ECL is still the
I apologize for the noise! You are quite right: according to the
timestamps, this occurred during "make ptestlong", which I started a few
minutes after building completed.
On Friday, January 12, 2018 at 1:59:04 AM UTC-8, Jeroen Demeyer wrote:
>
> On 2018-01-10 21:41, Richard
I happened to look through my system's dump log and discovered that
building Sage, at least as far back as 8.0, consistently and silently dumps
core 11 times (give or take). Here is a snip from the dump log, showing the
latest build I did:
TIMEPID UID GID SIG
At this point it appears two tickets are warranted:
1. Modify simplify_trig() (and its siblings) to scan the input
expression to see if there's any reason to call Maxima.
2. Incorporate a newer version of Maxima and its associated ECL/SBCL.
Anything else, for example, THROW/CATCH logic
Ralf,
Do we have a convention concerning calls to upstream packages like maxima?
That is, which side of the interface is responsible for the scan to
determine whether the main code invoked upstream should be executed: the
caller (in this case manifolds.utilities) or the callee (in this case
, 2017 at 2:19:34 AM UTC-8, Dima Pasechnik wrote:
>
>
>
> On Sunday, November 26, 2017 at 8:16:53 AM UTC, Ralf Stephan wrote:
>>
>> On Sunday, November 26, 2017 at 12:54:04 AM UTC+1, Richard_L wrote:
>>>
>>> Calling ...simplify_trig() results in a traceback,
Calling ...simplify_trig() results in a traceback, somewhat elided here:
Traceback (most recent call last):
File
"/home/rllozes/Development/sage/local/lib/python2.7/site-packages/sage/manifolds/differentiable/metric.py",
line 692, in inverse
self._inverse._restrictions[dom] =
, Richard_L wrote:
>
> Thank you. I missed that in the examples. Is there documentation listing
> all Manifold.options? I cannot find one with the documentation search.
>
> On Saturday, November 18, 2017 at 3:40:41 PM UTC-8, Eric Gourgoulhon wrote:
>>
>> HI,
>>
>>
Thank you. I missed that in the examples. Is there documentation listing
all Manifold.options? I cannot find one with the documentation search.
On Saturday, November 18, 2017 at 3:40:41 PM UTC-8, Eric Gourgoulhon wrote:
>
> HI,
>
> Le samedi 18 novembre 2017 23:55:35 UTC+1, Richa
Applying ExpressionNice() to an expression containing partial derivatives
cleans up the presentation, suppressing the display of function arguments
in the partial derivatives. However, zeroth order derivatives (i.e., the
function alone) are not cleaned up.
I think it would be useful to extend
[X] Require OpenSSL to be installed on the system.
This sidesteps the whole license issue and, since more bugs are sure to be
found, we do not have to keep yet another package up to date.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
Removing system-wide R has no effect on ptestlong. The same three failures
occur.
I'm out of ideas and out of time to work on this. For now, I will redirect
the libreadline symlink to that belonging to the system, and get back to
mathematical physics!
Thanks for your efforts,
- Richard
On
Both r-3.4.0.p0.log and rpy2-2.8.2.p0.log show
sh: /home/rllozes/Development/sage/local/lib/libreadline.so.6: no
version information available (required by sh)
With or without restoring my hacked symlink to its original state,
ldd local/lib/R/lib/libR.so and
ldd
No. LD_LIBRARY_PATH is not set.
The curious thing is that there are 29 lib*.so in the sage/local/lib folder
that are in common with the system /lib64 folder, although not necessarily
of the same version/sub-version. Only libreadline.so gives trouble during
make ptestall.
NB! Just grep'd all
As I observed on the sage-release Sage.8.1.beta3 thread, a library conflict
causes 'make ptestlong' to fail under openSUSE LEAP 42.2. Reworking the
offending symlink in the sage installation to point to the system library
fixes the problem. The two copies of "libreadline.so.6.3" are NOT
;
> In short, don’t do that again.
>
> François
>
> > On 14/08/2017, at 13:20, Richard_L <rich...@lozestech.com >
> wrote:
> >
> > Downloaded sage-8.1-beta-1, dropped into a clean copy of sage-8.0, and
> tried to make.
> > Received message
> >
Downloaded sage-8.1-beta-1, dropped into a clean copy of sage-8.0, and
tried to make.
Received message
Makefile:1709: recipe for target
'/home/rllozes/sage-8.1-beta-1/local/var/lib/sage/installed/gf2x-1.2' failed
Log file attached.
My system:
openSUSE Leap 42.2
kernel: 4.4.79-18.23-default
Clearly Robert has found a bug in maxima. Here's a little test further to
my earlier "puzzle":
If I write in sage as follows:
#$is
(equal(-(_SAGE_VAR_r13^2*_SAGE_VAR_r23-_SAGE_VAR_r23^3)/((-_SAGE_VAR_r23^4)+2*_SAGE_VAR_r13^2*_SAGE_VAR_r23^2-_SAGE_VAR_r13^4+_SAGE_VAR_r12^4),0))$
var('r12 r13
+oo)")
One therefore expects r12, etc. to be real.
- Richard
On Thursday, August 10, 2017 at 10:34:40 PM UTC-7, Robert Dodier wrote:
>
> On 2017-08-10, Richard_L <rich...@lozestech.com > wrote:
>
> > The following string sent to maxima causes a seg-fault and c
Eric,
I will be happy to test as soon as source code is modified. Just let me
know.
- Richard
On Friday, August 11, 2017 at 2:22:24 AM UTC-7, Eric Gourgoulhon wrote:
>
> Hi,
>
> Le vendredi 11 août 2017 08:12:42 UTC+2, David Roe a écrit :
>>
>> Note that this is changed in
The following string sent to maxima causes a seg-fault and core dump:
>
/home/rllozes/sage-8.0/local/lib/python2.7/site-packages/sage/interfaces/maxima_lib.py(452)_eval_line()
450 line = line[ind_semi+1:]
451 if statement:
2-> 452
I have now built sage-8.0 on two openSUSE systems, one with gcc 5.3.1 and
one with gcc 4.8.5.
In both cases I find errors relating to the compiler in config.log.
Examples:
configure:3987: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation
51 matches
Mail list logo
