Merci!
liblinboxsage.so:
linux-vdso.so.1 => (0x7fff0fdff000)
libntl.so => /home/alex/install/sage-5.5/local/lib/libntl.so
(0x7f26ed612000)
liblinbox.so.0 =>
/home/alex/install/sage-5.5/local/lib/liblinbox.so.0 (0x7f26ed3e3000)
libgivaro.so.0 =>
/home
Ok, then what does ldd on that file says?
Francois
On 13/01/2013, at 11:58, "Vepxistqaosani"
mailto:frederick.bartl...@gmail.com>> wrote:
Thanks for the response, but I don't think that's it:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 290G 9.6G 266G 4% /
udev
Thanks for the response, but I don't think that's it:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 290G 9.6G 266G 4% /
udev2.0G 4.0K 2.0G 1% /dev
tmpfs 785M 1020K 784M 1% /run
none5.0M 0 5.0M 0% /run/lock
none2.0G
Probably disk full. What's the output of "df -h"
On Saturday, January 12, 2013 10:37:57 PM UTC, Vepxistqaosani wrote:
>
> /home/alex/install/sage-5.5/local/lib/liblinboxsage.so: could not read
> symbols: Input/output error
>
>
--
You received this message because you are subscribed to the Goo
Hi!
I'm attempting to install Sage 5.5 on a Sony Vaio VGNFW590f3b running an Intel
Core 2 Duo T6600 / 2.2 GHz ( Dual-Core ) at 64 bits. The OS is LinuxMint 14.
The install dies with an input/output error, as shown below.
Any suggestions?
Thanks!
cc1plus: warning: command line option ‘-Wstri
Create a new patch containing your changes:
hg qnew my.patch
The newly-created patch contains your changes. you can then import other
patches into your patch queue.
On Saturday, January 12, 2013 8:20:43 PM UTC, Johhannes wrote:
>
> Hi list,
> I cant import new patches to my sage installatio
Hi list,
I cant import new patches to my sage installation without committing
changes I've done to the code. But I don't want to commit them.
What is the mistake I'm doing?
my setup is the following:
- created a new branch
- imported to patches by hg_sage.import_patch()
- added two new files
-
Please review #13946, it does some misc cleanup of the signal handling
code without changing its functionality. It is mainly meant to provide
a more solid base for future enhancements to the signal code:
http://trac.sagemath.org/sage_trac/ticket/13946
Thanks,
Jeroen.
--
You received this messag
On Saturday, January 12, 2013 1:44:14 PM UTC, Simon King wrote:
> Hey, I was talking about deprecation in the Sage library!!
No, you are not. The deprecations in the Sage library are at for the user
interface, so that the user doesn't have the rug pulled from under his
feet. The Sage internal
Hi Volker,
On 2013-01-12, Volker Braun wrote:
> Deprecation works in the Sage library because it is being tested.
Hey, I was talking about deprecation in the Sage library!! What I suggest is
to find a way such that
sage: from sage.misc.misc import SAGE_DATA
imports SAGE_DATA with a deprecati
I haven't looked at it. The free version doesn't have a keyboard and I just
have a hard time spending $3 for the app, just to try out the keyboard.
Looking at the screen shots is definitely interesting. Has anyone seen other
keyboards that they like?
I've been meaning to improve the keyboard
Deprecation works in the Sage library because it is being tested. Nobody
can test optional spkgs against a wide range of past and future Sage
versions. And not tested = does not work.
Case in point, no Linux distribution makes any promises that packages from
other versions of their distribution
Hi Volker,
On 2013-01-12, Volker Braun wrote:
> --=_Part_1251_5192383.1357985444328
> Content-Type: text/plain; charset=ISO-8859-1
>
> Really, your point is that you can't just install spkg version X on sage
> version Y.
That's an over-simplifaction.
My main point was that in this example,
Hi all,
I just stumbled upon this:
sage: CDF(0)
0.0
sage: CDF['x'](0)
0
I would have liked these two to pretty-print identically. OK, I agree that this
is an ultra-minor nitpick, but it made doctest fail in the "french sage book"
(http://trac.sagemath.org/sage_trac/ticket/11672).
Should we
Really, your point is that you can't just install spkg version X on sage
version Y. Which is true. Having spkg versions depend on each other makes
things even worse. The solution is to keep the spkg build scripts in the
same repository as the sage library, so when you checkout Sage (any
version
15 matches
Mail list logo
