[sage-devel] Re: Problems building/installing on Fedora 32

[Enrique Artal]

Have you tried with gcc package. For me it works with an intel precessor.

El lunes, 15 de junio de 2020, 11:13:49 (UTC+2), Robert Poole escribió:
>
> I've been trying to build and install Sage locally on a Fedora 32 system 
> (64-bit), running on a Ryzen 4700U APU with 8 GB of RAM.
>
> I have attached the relevant logs for your analysis.  I'm really stumped 
> by this.
>
> My configure parameters are:
>
> ./configure --prefix=$SAGE_ROOT  --enable-4ti2=yes --enable-boost=yes 
> --enable-libogg=yes --enable-libtheora=yes --enable-valgrind=yes 
>
> Here's the error that showed up in the console:
>
> [nose-1.3.7] 
>> == 
>> [nose-1.3.7] FAIL: test_addSuccess (test_xunit.TestXMLOutputWithXML) 
>> [nose-1.3.7] 
>> -- 
>> [nose-1.3.7] Traceback (most recent call last): 
>> [nose-1.3.7]   File 
>> "/home/tarquin/Sage/var/tmp/sage/build/nose-1.3.7/src/build/tests/unit_tests/test_xunit.py",
>>  
>> line 282, in test_addSuccess 
>> [nose-1.3.7] eq_(tc.attrib['classname'], "test_xunit.TC") 
>> [nose-1.3.7] AssertionError: 'test_xunit.mktest..TC' != 
>> 'test_xunit.TC' 
>> [nose-1.3.7]  >> begin captured stdout << 
>> - 
>> [nose-1.3.7] b'> name="nosetests" tests="1" errors="0" failures="0" skip="0">> classname="test_xunit.mktest.locals.TC" name="runTest" 
>> time="0.000">' 
>> [nose-1.3.7]  
>> [nose-1.3.7] - >> end captured stdout << 
>> -- 
>> [nose-1.3.7]  
>> [nose-1.3.7] 
>> -- 
>> [nose-1.3.7] Ran 387 tests in 16.913s 
>> [nose-1.3.7]  
>> [nose-1.3.7] FAILED (SKIP=15, failures=7) 
>> [nose-1.3.7]  
>> [nose-1.3.7] real0m25.836s 
>> [nose-1.3.7] user0m15.340s 
>> [nose-1.3.7] sys0m4.335s 
>> [nose-1.3.7] 
>>  
>> [nose-1.3.7] Error testing package nose-1.3.7 
>> [nose-1.3.7] 
>>  
>> [nose-1.3.7] Please email sage-devel (
>> http://groups.google.com/group/sage-devel) 
>> [nose-1.3.7] explaining the problem and including the log file 
>> [nose-1.3.7]   /home/tarquin/Sage/sage-9.1/logs/pkgs/nose-1.3.7.log 
>> [nose-1.3.7] Describe your computer, operating system, etc. 
>> [nose-1.3.7] If you want to try to fix the problem yourself, *don't* just 
>> cd to 
>> [nose-1.3.7] /home/tarquin/Sage/var/tmp/sage/build/nose-1.3.7 and type 
>> 'make check' or whatever is appropriate. 
>> [nose-1.3.7] Instead, the following commands setup all environment 
>> variables 
>> [nose-1.3.7] correctly and load a subshell for you to debug the error: 
>> [nose-1.3.7]   (cd '/home/tarquin/Sage/var/tmp/sage/build/nose-1.3.7' && 
>> '/home/tarquin/Sage/sage-9.1/sage' --buildsh) 
>> [nose-1.3.7] When you are done debugging, you can type "exit" to leave 
>> the subshell. 
>> [nose-1.3.7] 
>>  
>> make[3]: *** [Makefile:2147: 
>> /home/tarquin/Sage/var/lib/sage/installed/nose-1.3.7] Error 1 
>> make[3]: Leaving directory '/home/tarquin/Sage/sage-9.1/build/make' 
>> make[2]: *** [Makefile:1823: all-start] Error 2 
>> make[2]: Leaving directory '/home/tarquin/Sage/sage-9.1/build/make' 
>>  
>> real82m0.129s 
>> user80m42.912s 
>> sys0m59.296s 
>> *** 
>> Error building Sage. 
>>  
>> The following package(s) may have failed to build (not necessarily 
>> during this run of 'make all-start'): 
>>  
>> * package: nose-1.3.7 
>>   last build time: Jun 14 01:31 
>>   log file:/home/tarquin/Sage/sage-9.1/logs/pkgs/nose-1.3.7.log 
>>   build directory: /home/tarquin/Sage/var/tmp/sage/build/nose-1.3.7 
>>  
>> [snip]
>>  
>> make[1]: *** [Makefile:33: all-start] Error 1 
>> make[1]: Leaving directory '/home/tarquin/Sage/sage-9.1' 
>> make: *** [Makefile:13: all] Error 2 
>>
>
> What's strange is, I even tried to install nose 1.3.7 manually using 
> easy_install and it seemed to succeed -- but the Sage build isn't seeing 
> it.  Any ideas?
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b6f818c5-595c-4e52-8bda-a301f41a4962o%40googlegroups.com.

[sage-devel] Re: Possible bug regarding the mod() method for multi-variable polynomials

[Enrique Artal]

HI,
I think it is related with ticket #17638 
. There is a mathematical origin in 
this situation. When considering a non local ordering, one is working in a 
localized ideal, where any polynomial whose leading term is a non-zero 
constant is invertible. Singular works silently in this new ring without 
explicit declaration. I think that for Sage, a new structure should be 
constructed, but I do not know how. Best, Enrique.

El lunes, 6 de abril de 2020, 9:46:26 (UTC+2), Yang Zhou escribió:
>
> Hi,
>
> I am trying to truncate a multi-variable polynomial by moding out higher 
> order term and found
> the following (simplified) example. I am wondering if it is a bug.
>
>
> *Reproducible Example: *
>
>> R. = PolynomialRing(QQ, order='negdeglex')
>>
> f = 1 + x
>> I = R.ideal(x^2)
>> f.mod(I)
>>
> *Expected output:*
>
>> 1 + x
>>
> *Actual output:*
>
>> 1
>>
>
>
> *Note: *
> The actual output will be 1+x when I omit the "order='negdeglex" parameter.
>
> *SageMath version:*
> SageMath version 9.0, Release Date: 2020-01-01
>
> *Operating system:*
> OS: Ubuntu 19.10 x86_64 
> Kernel: 5.3.0-45-generic 
>
> Best regards,
> Yang
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/593546a3-8c04-471f-a78f-3ff9400e9b03%40googlegroups.com.

[sage-devel] Re: [sage-trac] #29314: update GAP to version 4.11

[Enrique Artal]

There are also upgrades of gap packages. Should gap_packages be upgraded to?

El miércoles, 11 de marzo de 2020, 12:13:43 (UTC+1), Dima Pasechnik 
escribió:
>
> new version of GAP, 4.11, is out, we should upgrade. Here is the ticket. 
>
> -- Forwarded message - 
> From: sage-trac > 
> Date: Wed, Mar 11, 2020 at 11:12 AM 
> Subject: [sage-trac] #29314: update GAP to version 4.11 
> To: 
>
>
> #29314: update GAP to version 4.11 
> +-- 
>Reporter:  dimpase   | Type:  enhancement 
>  Status:  new   | Priority:  major 
>   Milestone:  sage-9.1  |Component:  packages: standard 
>Keywords:|Merged in: 
> Authors:|Reviewers: 
> Report Upstream:  N/A   |  Work issues: 
>  Branch:|   Commit: 
>Dependencies:| Stopgaps: 
> +-- 
>  GAP 4.11.0 has been released. 
>
>  tarball: 
>  https://www.gap-system.org/pub/gap/gap-4.11/tar.bz2/gap-4.11.0.tar.bz2 
>
> -- 
> Ticket URL:  
> Sage  
> Sage: Creating a Viable Open Source Alternative to Magma, Maple, 
> Mathematica, and MATLAB 
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1af9a8da-854c-4b41-8676-282d0aba3deb%40googlegroups.com.

Re: [sage-devel] Poll: set online=True as the default for threejs viewer

[Enrique Artal]

It does affect also when using jupyterhub, (by the way, also to jsmol).

El martes, 12 de febrero de 2019, 9:20:48 (UTC+1), Jeroen Demeyer escribió:
>
> > Why neither nbviewer nor binder are able to find 
> > (or serve or ?) these javascript files? 
>
> The problem is these lines in src/sage/repl/rich_output/backend_ipython.py 
>
>  
>  
>
> These paths should be changed to take into account the base URL of the 
> server (don't ask me *how* to do this precisely). 
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Jupyterhub kernel and SAGE_ROOT

[Enrique Artal]

I tried your solution, it didn't work for me. In jupyter the kernel did not 
start, in jupyterlab there was also some style issues.

El lunes, 5 de noviembre de 2018, 14:56:50 (UTC+1), Enrique Artal escribió:
>
> That's true. I just edit the kernel.json for each new release (I read it 
> in some tutorial for jupyterhub+sagemath). I will try this.
>
> El lunes, 5 de noviembre de 2018, 10:20:59 (UTC+1), Kwankyu Lee escribió:
>>
>> The 
>>
>> On Monday, November 5, 2018 at 5:53:35 PM UTC+9, Jori Mäntysalo wrote:
>>>
>>> On Mon, 5 Nov 2018, Enrique Artal wrote: 
>>>
>>> > For me it works adding "env": { "SAGE_ROOT": "where_SAGE_ROOT_is" } in 
>>> > kernel.json 
>>>
>>> Thanks, seems to be much better solution.
>>
>>
>> A problem with this is that it is overwritten when Sage is rebuilt for 
>> upgrade. A much much better solution is to include the following 
>> into jupyterhub_config.py:
>>
>> c.Spawner.environment = {'SAGE_ROOT': 'where_SAGE_ROOT_is'} 
>>
>> Good luck.
>>
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Jupyterhub kernel and SAGE_ROOT

[Enrique Artal]

That's true. I just edit the kernel.json for each new release (I read it in 
some tutorial for jupyterhub+sagemath). I will try this.

El lunes, 5 de noviembre de 2018, 10:20:59 (UTC+1), Kwankyu Lee escribió:
>
> The 
>
> On Monday, November 5, 2018 at 5:53:35 PM UTC+9, Jori Mäntysalo wrote:
>>
>> On Mon, 5 Nov 2018, Enrique Artal wrote: 
>>
>> > For me it works adding "env": { "SAGE_ROOT": "where_SAGE_ROOT_is" } in 
>> > kernel.json 
>>
>> Thanks, seems to be much better solution.
>
>
> A problem with this is that it is overwritten when Sage is rebuilt for 
> upgrade. A much much better solution is to include the following 
> into jupyterhub_config.py:
>
> c.Spawner.environment = {'SAGE_ROOT': 'where_SAGE_ROOT_is'} 
>
> Good luck.
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Jupyterhub kernel and SAGE_ROOT

[Enrique Artal]

For me it works adding "env": { "SAGE_ROOT": "where_SAGE_ROOT_is" } in 
kernel.json

El lunes, 5 de noviembre de 2018, 8:21:31 (UTC+1), François Bissey escribió:
>
> Didn’t we have that conversation a couple of months ago? 
> The message here comes from this section of code in sage-env 
>
> # New value for SAGE_ROOT: either SAGE_ROOT (if given) 
> # or a guessed value based on pwd. 
> if [ -n "$SAGE_ROOT" ]; then 
> NEW_SAGE_ROOT="$SAGE_ROOT" 
> elif [ -f sage -a -d build ]; then 
> NEW_SAGE_ROOT="." 
> elif [ -f ../../sage -a -d ../../build ]; then 
> NEW_SAGE_ROOT="../.." 
> else 
> # No idea what SAGE_ROOT should be... 
> echo >&2 "Error: You must set the SAGE_ROOT environment variable or 
> run this" 
> echo >&2 "script from the SAGE_ROOT or SAGE_ROOT/local/bin/ 
> directory." 
> return 1 
> fi 
>
> There is some more code in there to make you trip. Touching sage-env could 
> solve your problem. 
> Another interesting file you could try to seed with the value of SAGE_ROOT 
> is 
> /etc/environment 
>
> François 
>
> > On 5/11/2018, at 20:11, Jori Mäntysalo > 
> wrote: 
> > 
> > I am trying to marry SageMath and Jupyterhub. I think I got them 
> engaged, but the wedding night has a problem: 
> > 
> > Error: You must set the SAGE_ROOT environment variable or run this 
> > script from the SAGE_ROOT or SAGE_ROOT/local/bin/ directory. 
> > Error setting environment variables by sourcing 
> '/home/jupkernelit/sage-8.4/local/bin/sage-env'; 
> > possibly contact sage-devel (see 
> http://groups.google.com/group/sage-devel) 
> > 
> > First I think that I just set SAGE_ROOT in the command line before 
> jupytehub-command, set it with export-command, or put it to /etc/profile. 
> They all failed, so jupyterhub seems to ignore environment. 
> > 
> > What next? 
> > 
> > -- 
> > Jori Mäntysalo 
>
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Note on building sagemath-8.2 with GCC 8.1.0

[Enrique Artal]

Bug #1576671. The solution proposed by Dario Asprone works for me.

Sagemath does not compile in Fedora 28

El viernes, 18 de mayo de 2018, 12:24:39 (UTC+2), Dima Pasechnik escribió:
>
>
>
> On Friday, May 18, 2018 at 5:53:21 AM UTC+1, Dario Asprone wrote:
>>
>> So, summing up, I tried compiling the library on Fedora 28 64bit, which 
>> ships with gcc 8.1 by default.
>> I encountered 3 different issues, 2 already addressed by fidelbc and one 
>> more with python 3.6.1
>> While I resolved the issue with python2 in the same way fidelbc did, I 
>> couldn't find any ready-made patch for the behaviour, so I analyzed the 
>> linbox code a bit:
>> in more than one place they used the double template specialization 
>> syntax, that is:
>> template<>
>> template
>> class Class1<Type1>{
>> ...
>> }
>> This construct doesn't work with the compilers listed in the #ifdef, but 
>> it worked with gcc7 (and MSVC I think).
>> Apparently with gcc8 and the corresponding template rules tightening, 
>> this approach was made non-standard, and since removing template<> 
>> shouldn't affect compilability, in other source files that part was 
>> commented out.
>> Since it was not in that particular header file (but I don't know why), I 
>> chose to add __GNUC__ to the list of constants the #ifdef checks for. 
>> This modification is in the attached patch multiple_templates.patch
>>
>> Python-3.6.1 was quite thougher. As Dima wrote, the solution is basically 
>> loading the patch he linked. Since the patch modifies configure.ac 
>> though, the package must first be rebuilt, then the commands
>> aclocal
>> autoconf
>> autoheader
>> run in sequence, and then the modifications apported by this commands put 
>> in a patch.
>>
>
> the above can be just one line:
>
> autoreconf -ivf
>  
>
>> After doing that, the package built correctly.
>> Sadly, I don't have any more information about the cause of the error 
>> than: on Fedora 28 *crypt()*, the thread unsafe version, is broken (or 
>> at least its usage in python).
>>
>
> it appears that crypt() on Fedora 28 has a totally different 
> implementation.
>
> https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
>
> This might explain why it's not visible on other distros with gcc 8.
>
>
>  
>
>> I have a few additional debug informations, but only on what happens, not 
>> on why it does.
>> The two patches to apply for python-3.6.1 are, respectively, crypt.patch 
>> and zzz_conf.patch.
>> I will now try to open a trac ticket with all the patches to fix the 
>> compilation on Fedora 28, specifying that 2 of them actually fix gcc 8.1 
>> compatibility issues in general.
>> I will also include the python2 patch, since with the current python2 
>> version compilation is still impossible.
>>
>
> your branch on trac should be dependent on the python2 fix ticket (and use 
> the branch there)
>  
>
>>
>> Il giorno venerdì 18 maggio 2018 04:24:30 UTC+1, Dima Pasechnik ha 
>> scritto:
>>>
>>> As I wrote - you need to backport the patch from 
>>> https://bugs.python.org/issue28503 
>>> <https://www.google.com/url?q=https%3A%2F%2Fbugs.python.org%2Fissue28503=D=1=AFQjCNESigXVaeH_9SZmQSbKTb4LZ_KiFQ>
>>> Hopefully he opens a ticket with the fix soon (he just got his trac 
>>> account fixed).
>>>
>>> On Thursday, May 17, 2018 at 10:39:46 PM UTC+1, Enrique Artal wrote:
>>>>
>>>> I would be interested on how he solved the problem!
>>>>
>>>> El jueves, 17 de mayo de 2018, 21:04:15 (UTC+2), Dima Pasechnik 
>>>> escribió:
>>>>>
>>>>> On Fedora 28 (another gcc-8 system) Dario (my student) also had 
>>>>> problem with building python3, as we were getting a broken crypt module.
>>>>> A remedy he found, after a lot of debugging, was to backport the patch 
>>>>> from
>>>>> https://bugs.python.org/issue28503 
>>>>> <https://www.google.com/url?q=https%3A%2F%2Fbugs.python.org%2Fissue28503=D=1=AFQjCNESigXVaeH_9SZmQSbKTb4LZ_KiFQ>
>>>>> (which uses crypt_r if available) 
>>>>>
>>>>> On Thursday, May 17, 2018 at 7:23:30 AM UTC+1, vdelecroix wrote:
>>>>>>
>>>>>> Dear F, 
>>>>>>
>>>>>> Thanks! 
>>>>>>
>>>>>> For Python 2.7-14 we will be switching for 2.7-15 that does cause any 
>>>>>> t

Re: [sage-devel] Note on building sagemath-8.2 with GCC 8.1.0

[Enrique Artal]

Thanks! I have just seen also your answer in bugzilla.redhat.com.

El viernes, 18 de mayo de 2018, 6:53:21 (UTC+2), Dario Asprone escribió:
>
> So, summing up, I tried compiling the library on Fedora 28 64bit, which 
> ships with gcc 8.1 by default.
> I encountered 3 different issues, 2 already addressed by fidelbc and one 
> more with python 3.6.1
> While I resolved the issue with python2 in the same way fidelbc did, I 
> couldn't find any ready-made patch for the behaviour, so I analyzed the 
> linbox code a bit:
> in more than one place they used the double template specialization 
> syntax, that is:
> template<>
> template
> class Class1<Type1>{
> ...
> }
> This construct doesn't work with the compilers listed in the #ifdef, but 
> it worked with gcc7 (and MSVC I think).
> Apparently with gcc8 and the corresponding template rules tightening, this 
> approach was made non-standard, and since removing template<> shouldn't 
> affect compilability, in other source files that part was commented out.
> Since it was not in that particular header file (but I don't know why), I 
> chose to add __GNUC__ to the list of constants the #ifdef checks for. 
> This modification is in the attached patch multiple_templates.patch
>
> Python-3.6.1 was quite thougher. As Dima wrote, the solution is basically 
> loading the patch he linked. Since the patch modifies configure.ac 
> though, the package must first be rebuilt, then the commands
> aclocal
> autoconf
> autoheader
> run in sequence, and then the modifications apported by this commands put 
> in a patch.
> After doing that, the package built correctly.
> Sadly, I don't have any more information about the cause of the error 
> than: on Fedora 28 *crypt()*, the thread unsafe version, is broken (or at 
> least its usage in python).
> I have a few additional debug informations, but only on what happens, not 
> on why it does.
> The two patches to apply for python-3.6.1 are, respectively, crypt.patch 
> and zzz_conf.patch.
> I will now try to open a trac ticket with all the patches to fix the 
> compilation on Fedora 28, specifying that 2 of them actually fix gcc 8.1 
> compatibility issues in general.
> I will also include the python2 patch, since with the current python2 
> version compilation is still impossible.
>
> Il giorno venerdì 18 maggio 2018 04:24:30 UTC+1, Dima Pasechnik ha scritto:
>>
>> As I wrote - you need to backport the patch from 
>> https://bugs.python.org/issue28503 
>> <https://www.google.com/url?q=https%3A%2F%2Fbugs.python.org%2Fissue28503=D=1=AFQjCNESigXVaeH_9SZmQSbKTb4LZ_KiFQ>
>> Hopefully he opens a ticket with the fix soon (he just got his trac 
>> account fixed).
>>
>> On Thursday, May 17, 2018 at 10:39:46 PM UTC+1, Enrique Artal wrote:
>>>
>>> I would be interested on how he solved the problem!
>>>
>>> El jueves, 17 de mayo de 2018, 21:04:15 (UTC+2), Dima Pasechnik escribió:
>>>>
>>>> On Fedora 28 (another gcc-8 system) Dario (my student) also had problem 
>>>> with building python3, as we were getting a broken crypt module.
>>>> A remedy he found, after a lot of debugging, was to backport the patch 
>>>> from
>>>> https://bugs.python.org/issue28503 
>>>> <https://www.google.com/url?q=https%3A%2F%2Fbugs.python.org%2Fissue28503=D=1=AFQjCNESigXVaeH_9SZmQSbKTb4LZ_KiFQ>
>>>> (which uses crypt_r if available) 
>>>>
>>>> On Thursday, May 17, 2018 at 7:23:30 AM UTC+1, vdelecroix wrote:
>>>>>
>>>>> Dear F, 
>>>>>
>>>>> Thanks! 
>>>>>
>>>>> For Python 2.7-14 we will be switching for 2.7-15 that does cause any 
>>>>> trouble with GCC 8.1.0. See [1]. 
>>>>>
>>>>> For linbox, there is at least [2] opened (but no patch for the 
>>>>> moment). 
>>>>>
>>>>> BTW, when I did build Sage with 8.1.0 few times ago I also had 
>>>>> troubles 
>>>>> with fflas that you do not mention (complaints about "const void"). 
>>>>>
>>>>> [1] https://trac.sagemath.org/ticket/25204 
>>>>> [2] https://trac.sagemath.org/ticket/25353 
>>>>>
>>>>> Vincent 
>>>>>
>>>>> On 17/05/2018 04:59, fidelbc wrote: 
>>>>> > Hello all, 
>>>>> > 
>>>>> > Wanted to leave this note for anybody running into gcc8 compiling 
>>>>> issues. 
>>>>> > This was built on archlinux using their gcc 8.1.0-1 

Re: [sage-devel] Note on building sagemath-8.2 with GCC 8.1.0

[Enrique Artal]

I would be interested on how he solved the problem!

El jueves, 17 de mayo de 2018, 21:04:15 (UTC+2), Dima Pasechnik escribió:
>
> On Fedora 28 (another gcc-8 system) Dario (my student) also had problem 
> with building python3, as we were getting a broken crypt module.
> A remedy he found, after a lot of debugging, was to backport the patch from
> https://bugs.python.org/issue28503
> (which uses crypt_r if available) 
>
> On Thursday, May 17, 2018 at 7:23:30 AM UTC+1, vdelecroix wrote:
>>
>> Dear F, 
>>
>> Thanks! 
>>
>> For Python 2.7-14 we will be switching for 2.7-15 that does cause any 
>> trouble with GCC 8.1.0. See [1]. 
>>
>> For linbox, there is at least [2] opened (but no patch for the moment). 
>>
>> BTW, when I did build Sage with 8.1.0 few times ago I also had troubles 
>> with fflas that you do not mention (complaints about "const void"). 
>>
>> [1] https://trac.sagemath.org/ticket/25204 
>> [2] https://trac.sagemath.org/ticket/25353 
>>
>> Vincent 
>>
>> On 17/05/2018 04:59, fidelbc wrote: 
>> > Hello all, 
>> > 
>> > Wanted to leave this note for anybody running into gcc8 compiling 
>> issues. 
>> > This was built on archlinux using their gcc 8.1.0-1 package. 
>> Fortunately 
>> > there are fixes floating around, please see attached patches. 
>> > 
>> > - Python-2.7.14 
>> > 
>> > Error (sorry for the lack of details, lost the log file:-/ ): 
>> > /bin/sh: line 5: 25857 Segmentation fault  (core dumped) ... 
>> > Fix: 
>> > Place attached patch gcc8_python.patch (also available at [1]) under 
>> > $SAGEDIR/build/pkgs/python2/patches. I guess this is now fixed at 
>> 2.7.15, 
>> > see [2]. 
>> > 
>> > 
>> > - linbox-1.5.2 
>> > 
>> > Error: 
>> > ../../linbox/matrix/densematrix/blas-transposed-matrix.h:74:8: error: 
>> too 
>> > many template-parameter-lists 
>> >class TransposedBlasMatrix< TransposedBlasMatrix< Matrix > > : 
>> public 
>> > Matrix { 
>> >  ^~ 
>> > Fix: 
>> > Place attached patch gcc8_linbox.patch (also available at [3]) under 
>> > $SAGEDIR/build/pkgs/linbox/patches 
>> > 
>> > Best, 
>> > f 
>> > 
>> > [1]: 
>> https://mail.python.org/pipermail/python-dev/2018-January/152011.html 
>> > [2]: 
>> > 
>> https://github.com/python/cpython/commit/0b91f8a668201fc58fa732b8acc496caedfdbae0
>>  
>> > [3]: 
>> > 
>> https://git.archlinux.org/svntogit/community.git/tree/trunk/linbox-gcc8.patch?h=packages/linbox
>>  
>> > 
>>
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Error in the communication with singular

[Enrique Artal]

I have an issue with sage-8.1 (also with 8.0). This is my code:

R.=PolynomialRing(QQ,order='neglex')
f=(y^2-x^3)*(y^2-x^2*y-x^3)
singular.lib("all.lib")
f._singular_().bernstein().sage()
f._singular_().bfct().sage()

The two last functions are two different algorithms in order to compute 
Bernstein-Sato polynomial and they should provide the same solution, but 
there is exactly one distinct root. The result is the same for both 
functions if I use Singular (both with my own installation and with 
Singular in Sage) and it coincides with the one of bfct.

Any clue. Thanks, Enrique.

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Import into sage nb causes internal error

[Enrique Artal]

Same problem here, I put the log in case it helps

2017-11-05T20:37:57+0100 [stdout#info] error uploading worksheet Could not 
build url for endpoint 'home' with values ['username']. Did you mean 
'worksheet_listing.home'
instead? 
Could not build url for endpoint 'home' with values ['username']. Did you 
mean 'worksheet_listing.home' instead? 
Traceback (most recent call last): 
 File "/usr/local/sage-8.0/local/lib/python2.7/site-packages/flask/app.py", 
line 1475, in full_dispatch_request 
   rv = self.dispatch_request() 
 File "/usr/local/sage-8.0/local/lib/python2.7/site-packages/flask/app.py", 
line 1461, in dispatch_request 
   return self.view_functions[rule.endpoint](**req.view_args) 
 File 
"/usr/local/sage-8.0/local/lib/python2.7/site-packages/sagenb/flask_version/decorators.py",
 
line 22, in wrapper 
   return f(*args, **kwds) 
 File 
"/usr/local/sage-8.0/local/lib/python2.7/site-packages/sagenb/flask_version/worksheet_listing.py",
 
line 427, in upload_worksheet 
   return current_app.message(s, url_for('home', username=g.username), 
username=g.username) 
 File 
"/usr/local/sage-8.0/local/lib/python2.7/site-packages/flask/helpers.py", 
line 312, in url_for 
   return appctx.app.handle_url_build_error(error, endpoint, values) 
 File "/usr/local/sage-8.0/local/lib/python2.7/site-packages/flask/app.py", 
line 1641, in handle_url_build_error 
   reraise(exc_type, exc_value, tb) 
 File 
"/usr/local/sage-8.0/local/lib/python2.7/site-packages/flask/helpers.py", 
line 305, in url_for 
   force_external=external) 
 File 
"/usr/local/sage-8.0/local/lib/python2.7/site-packages/werkzeug/routing.py", 
line 1758, in build 
   raise BuildError(endpoint, values, method, self) 
BuildError: Could not build url for endpoint 'home' with values 
['username']. Did you mean 'worksheet_listing.home' instead?



El jueves, 5 de octubre de 2017, 15:23:08 (UTC+2), Angela Hicks escribió:
>
> You're correct.  (I just uploaded a .sws file without problem.)  I'm glad 
> to see it's otherwise being reported.
>
> On Thursday, October 5, 2017 at 5:55:42 AM UTC-4, Dima Pasechnik wrote:
>>
>>
>>
>> On Thursday, October 5, 2017 at 10:22:38 AM UTC+1, Angela Hicks wrote:
>>>
>>> There's some speculation this is related to: this post 
>>>  which 
>>> seems not unreasonable, but I'll post the details here (at kcrisman's 
>>> suggestion).
>>>
>>> I'm running Fedora 26 as a virtual machine, I recently installed Sage 
>>> 8.0 from source. The installation worked great until I:
>>>
>>> 1) Uploaded a zipped file into the old sage notebook gui.
>>>
>>
>> Yes, indeed, this doesn't work with *.zip archives any more. :-(
>> https://github.com/sagemath/sagenb/issues/433
>>
>> Does it work for you with individual *.sws files (the "original" sagenb 
>> format)?
>> (this does work, I think)
>>
>>  
>>
>>> This triggers a 500:internal error on screen
>>> and a "Build Error:Could not build url for endpoint 'home' with values 
>>> ['username']. Did you mean 'worksheet_listing.home' instead?" on the 
>>> command line.
>>> The error seems benign (can be ignored) until I
>>> 2) Restart sage
>>> 3) Start the new Notebook Exporter gui.
>>> The gui has no links (so is not useable), and the command line reports a 
>>> much longer error, which is posted in entirety here 
>>> ,
>>>  
>>> where I first reported the problem.  
>>> Repeated restarts do not fix the problem, although after a single 
>>> restart both the notebook gui and the jupiter gui work fine.  I can 
>>> consistently replicate the same steps if I start again with a new copy of 
>>> the same virtual machine.  I have not tried reinstalling sage to see if I 
>>> can replicate the problem afterwards.
>>>
>>> In the linked post, someone pointed out that they assumed no one would 
>>> continue using sagenb, so if it was triggering a problem, it might not 
>>> affect very many.  I'm not sure how widespread this problem is, but it's 
>>> worth pointing out I seem to be triggering it by doing exactly what people 
>>> will tend to do as they update their sage server to 8.0:  First import old 
>>> notebooks into sagenb, then use the Notebook Exporter to switch them to 
>>> Jupyter.  
>>>
>>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: From SageNB to jupyter

[Enrique Artal]

It is a server with 8 cores and 32GB of RAM, but with several other sagenb 
processes and twenty users on jupyterhub plus 60 on the sagenb instances 
cause no performance issue (usually)

El sábado, 9 de septiembre de 2017, 15:03:53 (UTC+2), kcrisman escribió:
>
>
>
> On Saturday, September 9, 2017 at 6:12:49 AM UTC-4, Enrique Artal wrote:
>>
>> It is quite useful, indeed. We have installed it in our servers.
>>
>
> Could it be made "even easier" to deploy?  Sagenb really just required 
> someone who knew how to give things a domain name and commands to start a 
> server. 
>
> Also, more formal testing of the requirements for memory would be helpful 
> - many local sagenb installs only had a couple gig of RAM available on a 
> virtual machine and so couldn't handle more than a dozen or so users at a 
> time.
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: From SageNB to jupyter

[Enrique Artal]

It is quite useful, indeed. We have installed it in our servers.

El viernes, 8 de septiembre de 2017, 16:48:49 (UTC+2), kcrisman escribió:
>
>
>
> On Thursday, September 7, 2017 at 11:16:14 AM UTC-4, Dima Pasechnik wrote:
>>
>> did you see this:
>> https://benjamin-hackl.at/2016/01/16/jupyterhub-with-sagemath-kernel/
>>
>> It seems that all of the requirements you list are there...
>>
>
> This seems very interesting, especially if it could be packaged up in a 
> box, so to speak, for deployment. 
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: From SageNB to jupyter

[Enrique Artal]

And probably the ability of sharing worksheets, I did not find it in 
jupyter or jupyterhub; of course SMC would be OK but I see only the option 
of campus accounts or personal docker copies.

El jueves, 7 de septiembre de 2017, 13:32:02 (UTC+2), Jori Mäntysalo 
escribió:
>
> On Thu, 7 Sep 2017, Dima Pasechnik wrote: 
>
> > What exactly are you missing from jupyter nb, or jupyter hub, or some 
> version of SMC 
> > people managed to get running on their intranets? 
>
> I don't actually know; SageNB has just been a working piece of software. 
>
> What we need is 
>
> - User management from LDAP or Shibboleth, so that everyone with an 
> account on them can just sign in to Sage. 
> - Local user accounts too. 
> - Security, so that a user A can not see worksheets for user B. 
> - Importing SageNB worksheet to a new system worksheet. 
>
> -- 
> Jori Mäntysalo

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: DeprecationWarning: OpenSSL.rand is deprecated (on sage 8.0)

[Enrique Artal]

I also has this message; I did make ssl. Best, Enrique

El lunes, 24 de julio de 2017, 21:46:15 (UTC+2), Eric Gourgoulhon escribió:
>
> Hi Vincent,
>
> I've installed Sage 8.0 on Ubuntu 16.04 from a fresh git clone and without 
> any optional package (i.e. just performing make after the git clone). I do 
> not get any deprecation warning when quitting.
>
> Best regards,
>
> Eric.
>
>
> Le lundi 24 juillet 2017 16:05:28 UTC+2, vdelecroix a écrit :
>>
>> Hello, 
>>
>> After an upgrade to sage 8.0 on Ubuntu, if I launch Sage and quit I see 
>> the following warning 
>>
>> quasar:~$ sage -q 
>> sage: quit 
>> Exiting Sage (CPU time 0m0.04s, Wall time 0m0.76s). 
>> /home/vdelecro/sage_patchbot/local/lib/python2.7/site-packages/twisted/protocols/tls.py:41:
>>  
>>
>> DeprecationWarning: OpenSSL.rand is deprecated - you should use 
>> os.urandom instead 
>>from OpenSSL.SSL import Error, ZeroReturnError, WantReadError 
>> quasar:~$ 
>>
>> Does anybody has an idea where it might come from? It is the source of 
>> ~20 doctest failures. Note that I installed most of the optional 
>> packages. 
>>
>> I am right now recompilong from scratch to see and will do a full test 
>> suite without packages and with all optional packages. 
>>
>> Vincent 
>>
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: new sagenb pre-release, please test

[Enrique Artal]

Is there any particular change to test?

El miércoles, 10 de mayo de 2017, 16:12:26 (UTC+2), Dima Pasechnik escribió:
>
> Please test ​https://github.com/sagemath/sagenb/tree/1.0.rc0 (copy of the 
> current master) before I go ahead with making a new Sage package. It works 
> for me following the instructions in HASKING (updated, to take care of 
> changed names and of the need to deal with mathjax).
>
> Report issues on github, please.
>
>
> Dima
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: ulimit issues and IPython 5.0

[Enrique Artal]

Sorry for the noise. With this modification, the notebook server runs but 
at some unexpected moment it stops. I saw these error messages in log, 
maybe related:


Apr 24 14:10:08 sage-mtm saged.mtm[14139]: 2017-04-24T14:10:08+0200 [-] 
WSGI application error 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011Traceback (most recent call 
last): 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/python/threadpool.py",
 
line 262, in  
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011inContext.theWork = 
lambda: context.call(ctx, func, *args, **kw) 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/python/context.py",
 
line 118, in callWithContext 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011return 
self.currentContext().callWithContext(ctx, func, *args, **kw) 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/python/context.py",
 
line 83, in callWithContext 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011self.contexts.pop() 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/web/wsgi.py", 
line 521, in run 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011self.started = True 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011---  
--- 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/web/wsgi.py", 
line 499, in run 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011self.write(elem) 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/web/wsgi.py", 
line 454, in write 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011self.reactor, wsgiWrite, 
self.started) 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/internet/threads.py",
 
line 122, in blockingCallFromThread 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011result.raiseException() 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File "", line 2, 
in raiseException 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011exceptions.AttributeError: 
'NoneType' object has no attribute 'write' 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: 2017-04-24T14:10:08+0200 [-] 
Unhandled Error 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011Traceback (most recent call 
last): 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/application/app.py",
 
line 390, in startReactor 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011self.config, oldstdout, 
oldstderr, self.profiler, reactor) 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/application/app.py",
 
line 311, in runReactorWithLogging 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011reactor.run() 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/internet/base.py",
 
line 1194, in run 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011self.mainLoop() 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/internet/base.py",
 
line 1203, in mainLoop 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011self.runUntilCurrent() 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011---  
--- 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/internet/base.py",
 
line 798, in runUntilCurrent 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011f(*a, **kw) 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/web/wsgi.py", 
line 509, in wsgiError 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011 
   self.request.loseConnection() 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011  File 
"/usr/local/sage-7.6/local/lib/python2.7/site-packages/twisted/web/http.py", 
line 1345, in loseConnection 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011 
   self.channel.loseConnection() 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011exceptions.AttributeError: 
'NoneType' object has no attribute 'loseConnection' 
Apr 24 14:10:08 sage-mtm saged.mtm[14139]: #011



El lunes, 24 de abril de 2017, 20:32:08 (UTC+2), Enrique Artal escribió:
>
> Not sure either, but I changed the file. Anyway, probably the issue had to 
> do with the number of open files. I added the following lines in 
> limits.conf:
> root sof

[sage-devel] Re: ulimit issues and IPython 5.0

[Enrique Artal]

Not sure either, but I changed the file. Anyway, probably the issue had to 
do with the number of open files. I added the following lines in 
limits.conf:
root soft nofile 655360 
sage soft nofile 655360 
root hard nofile 655360 
sage hard nofile 655360

(sage is the user owning sage notebooks). After a reboot the 7.6 notebooks 
work OK.


El jueves, 20 de abril de 2017, 17:33:36 (UTC+2), Samuel Lelievre escribió:
>
> Not sure if this is related, but one thing that goes wrong with
> the upgrade to IPython 5.0 is that multiline output gets an
> extraneous blank line, for example instead of
>
> sage: identity_matrix(2)
> [1 0]
> [0 1]
>
> we get
>
> sage: identity_matrix(2)
>
> [1 0]
> [0 1]
>
> This is solved in IPython 5.3 but Sage has not upgraded to
> that version yet. You can fix this on your installation by editing
> the "prompts.py" file located at (from your SAGE_ROOT):
>
> local/lib/python/site-packages/IPython/terminal/prompts.py
>
> and replacing the definition of the RichPromptDisplayHook class
> by the version at
>
>
> https://github.com/takluyver/ipython/blob/83d273e24b28b9c06f0fa4f5bf90581db7c29be8/IPython/terminal/prompts.py
>
> ie
>
> #
> class RichPromptDisplayHook(DisplayHook):
> """Subclass of base display hook using coloured prompt"""
> def write_output_prompt(self):
> sys.stdout.write(self.shell.separate_out)
> # If we're not displaying a prompt, it effectively ends with a 
> newline,
> # because the output will be left-aligned.
> self.prompt_end_newline = True
>
> if self.do_full_cache:
> tokens = self.shell.prompts.out_prompt_tokens()
> prompt_txt = ''.join(s for t, s in tokens)
> if prompt_txt and not prompt_txt.endswith('\n'):
> # Ask for a newline before multiline output
> self.prompt_end_newline = False
>
> if self.shell.pt_cli:
> self.shell.pt_cli.print_tokens(tokens)
> else:
> sys.stdout.write(prompt_txt)
> #
>
> In case this extra blank line is interpreted somehow
> as something returning None, this might explain why
> you get the error message you quote:
>
> TypeError: 'NoneType' object is not iterable
>
> Just a wild guess, maybe worth a try...
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: ulimit issues and IPython 5.0

[Enrique Artal]

I tried again to launch sagenb server (7.6) again avoiding the ulimit 
restrictions, and it seems ulimit is not responsible for it. After some 
hours the server does not respond, syslog register tons of these messages:

Apr 19 12:41:47 sage-mtm saged.mtm[15141]: 2017-04-19T12:41:47+0200 
[twisted.protocols.tls.TLSMemoryBIOFactory] Could not accept new connection 
(EMFILE) 
Apr 19 12:41:47 sage-mtm saged.mtm[15141]: message repeated 12402 times: [ 
2017-04-19T12:41:47+0200 [twisted.protocols.tls.TLSMemoryBIOFactory] Could 
not accept new con

And after the failure in the command line one gets this:
sage: 1+1 
2 
--- 
TypeError Traceback (most recent call last) 
 in () 
> 1 Integer(1)+Integer(1) 

/usr/local/sage-7.6/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc
 
in __call__(self, result) 
   244 self.start_displayhook() 
   245 self.write_output_prompt() 
--> 246 format_dict, md_dict = self.compute_format_data(result) 
   247 self.update_user_ns(result) 
   248 self.fill_exec_result(result) 

/usr/local/sage-7.6/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc
 
in compute_format_data(self, result) 
   148 
   149 """ 
--> 150 return self.shell.display_formatter.format(result) 
   151 
   152 # This can be set to True by the write_output_prompt method in a 
subclass 

/usr/local/sage-7.6/local/lib/python2.7/site-packages/sage/repl/display/formatter.pyc
 
in format(self, obj, include, exclude) 
   158 # First, use Sage rich output if there is any 
   159 PLAIN_TEXT = u'text/plain' 
--> 160 sage_format, sage_metadata = self.dm.displayhook(obj) 
   161 assert PLAIN_TEXT in sage_format, 'plain text is always 
present' 
   162 if sage_format.keys() != [PLAIN_TEXT]: 

TypeError: 'NoneType' object is not iterable

I checked that before the upgrade of IPython everything works OK. Thanks, 
Enrique.



El lunes, 27 de marzo de 2017, 15:51:29 (UTC+2), Enrique Artal escribió:
>
> As expected, no change in 7.6. I thought about creating a ticket but 
> besides the fact that the upgrade of ipython seems to be responsible I have 
> no idea how.
>
> El miércoles, 15 de febrero de 2017, 14:26:35 (UTC+1), Enrique Artal 
> escribió:
>>
>> The following may be related, I encountered it doing some administration 
>> in our notebooks (sagenb). The following happens in both Sage 7.4 and 7.5 
>> (it executes the orders but the warning may suggest some issue in the 
>> relationship of sagenb and ipython). No warning in 7.3
>>
>>
>> sage: import sys 
>> sage: 1+1 
>> 2 
>> sage: import sagenb.notebook.notebook 
>> sage: 1+1 
>> 2 
>> --- 
>>
>> TypeError Traceback (most recent call 
>> last) 
>>  in () 
>> > 1 Integer(1)+Integer(1) 
>>
>> /usr/local/sage-7.4/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc
>>  
>> in __call__(self, result) 
>> 244 self.start_displayhook() 
>> 245 self.write_output_prompt() 
>> --> 246 format_dict, md_dict = 
>> self.compute_format_data(result) 
>> 247 self.update_user_ns(result) 
>> 248 self.fill_exec_result(result) 
>>
>> /usr/local/sage-7.4/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc
>>  
>> in compute_format_data(self, result) 
>> 148 
>> 149 """ 
>> --> 150 return self.shell.display_formatter.format(result) 
>> 151 
>> 152 # This can be set to True by the write_output_prompt method 
>> in a subclass 
>>
>> /usr/local/sage-7.4/local/lib/python2.7/site-packages/sage/repl/display/formatter.pyc
>>  
>> in format(self, obj, include, exclude) 
>> 158 # First, use Sage rich output if there is any 
>> 159 PLAIN_TEXT = u'text/plain' 
>> --> 160 sage_format, sage_metadata = self.dm.displayhook(obj) 
>> 161 assert PLAIN_TEXT in sage_format, 'plain text is always 
>> present' 
>> 162 if sage_format.keys() != [PLAIN_TEXT]: 
>>
>> TypeError: 'NoneType' object is not iterable 
>>
>> El miércoles, 8 de febrero de 2017, 8:28:27 (UTC+1), Enrique Artal 
>> escribió:
>>>
>>> I start a new thread in this list as a continuation of "How to limit 
>>> heavy computations" in sage-support. I try to summarize the problem. In my 
&

Re: [sage-devel] Re: jsmol.js

[Enrique Artal]

Is there an easy way to make it work in jupyterhub? In jupyter, sage-7.6 
works without any problem; for jupyterhub, threejs works but jsmol still 
doesn't. Thanks for the hard work. I can test any solution. Best, Enrique.

El martes, 1 de noviembre de 2016, 20:03:52 (UTC+1), Volker Braun escribió:
>
> Its not a proper notebook extension; The code is 
> in src/sage/repl/display/jsmol_iframe.py
>
>
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: ulimit issues and IPython 5.0

[Enrique Artal]

As expected, no change in 7.6. I thought about creating a ticket but 
besides the fact that the upgrade of ipython seems to be responsible I have 
no idea how.

El miércoles, 15 de febrero de 2017, 14:26:35 (UTC+1), Enrique Artal 
escribió:
>
> The following may be related, I encountered it doing some administration 
> in our notebooks (sagenb). The following happens in both Sage 7.4 and 7.5 
> (it executes the orders but the warning may suggest some issue in the 
> relationship of sagenb and ipython). No warning in 7.3
>
>
> sage: import sys 
> sage: 1+1 
> 2 
> sage: import sagenb.notebook.notebook 
> sage: 1+1 
> 2 
> --- 
>
> TypeError Traceback (most recent call 
> last) 
>  in () 
> > 1 Integer(1)+Integer(1) 
>
> /usr/local/sage-7.4/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc
>  
> in __call__(self, result) 
> 244 self.start_displayhook() 
> 245 self.write_output_prompt() 
> --> 246 format_dict, md_dict = 
> self.compute_format_data(result) 
> 247 self.update_user_ns(result) 
> 248 self.fill_exec_result(result) 
>
> /usr/local/sage-7.4/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc
>  
> in compute_format_data(self, result) 
> 148 
> 149 """ 
> --> 150 return self.shell.display_formatter.format(result) 
> 151 
> 152 # This can be set to True by the write_output_prompt method in 
> a subclass 
>
> /usr/local/sage-7.4/local/lib/python2.7/site-packages/sage/repl/display/formatter.pyc
>  
> in format(self, obj, include, exclude) 
> 158 # First, use Sage rich output if there is any 
> 159 PLAIN_TEXT = u'text/plain' 
> --> 160 sage_format, sage_metadata = self.dm.displayhook(obj) 
> 161 assert PLAIN_TEXT in sage_format, 'plain text is always 
> present' 
>     162 if sage_format.keys() != [PLAIN_TEXT]: 
>
> TypeError: 'NoneType' object is not iterable 
>
> El miércoles, 8 de febrero de 2017, 8:28:27 (UTC+1), Enrique Artal 
> escribió:
>>
>> I start a new thread in this list as a continuation of "How to limit 
>> heavy computations" in sage-support. I try to summarize the problem. In my 
>> University, we have two servers to run math labs; it is done in several 
>> instances of sagenb using server_pool to enhance (at least a little bit) 
>> security. The sagenb instances are launched with ulimit options but it 
>> seems they have no effect.
>> In the first term of this academic year, we had several issues affecting 
>> the use of this server. Some students started long loops or heavy 
>> computations that stop the server (basically their computations blocked one 
>> instance and the error messages of the nginx processes grew so much that 
>> filled the hard disk). After restarting the machines, the problems came 
>> back again; at this point, when we detected such a process it was 
>> immediately stopped, but for some reason its instance of sagenb became 
>> unusable, causing problems to other students, since it needed restarting 
>> (and someone to do it). It was possible (not easy, thanks to Jori 
>> Mäntysalo) to identify the actual owner of the process, since stopping the 
>> computation by himself caused less harm.
>>
>> Using ulimit in the OS, namely with the restrictions hard  "as   600" 
>> and "hard   cpu   10", it worked. If a computation was too heavy, the 
>> process stopped with some error message, but the instance was usable by any 
>> other user of the sagenb instance (including the person with the long 
>> computation). This was true for Sage 7.3, but no more in Sage 7.4 (and 7.5) 
>> where the process was stopped by the instance became unusable in few 
>> minutes.
>>
>> Dima Pasechnik proposed to git-bisect and with the help of Miguel Marco, 
>> I think I found the patch causing this behavior. I started checking with 
>> 7.4 beta and rc and I saw that beta0 had the issue. Looking at the history 
>> of changes, it worked after 
>> 2b3eb14 Trac #20621: Simpler code and better error messages in Sequence()
>> and it didn't work after
>> 9831d4b Trac #21006: Upgrade to IPython 5.0
>>
>> Is there any chance to look into this change in order to localize and 
>> solve the problem?
>>
>> Regards, Enrique.
>>
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: what happened to ipython?

[Enrique Artal]

I tried to downgrade to ipython 4.x from Sage 7.5 but there is a problem 
with python module prompts

El lunes, 20 de febrero de 2017, 16:30:53 (UTC+1), Sébastien Labbé escribió:
>
> @bennigoetz reported the same problem in December 2016 :
> https://github.com/ipython/ipython/issues/9816#issuecomment-258242213
>
> For now, the only solution seems to go back to IPython 4.x ...
>
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: SageNB -> Jupyter conversion needs testers

[Enrique Artal]

We have trying in my university some solutions usingy jupyterhub; we have 
some ideas about sharing and we still do not know how safe it is. 

El sábado, 25 de febrero de 2017, 15:01:38 (UTC+1), kcrisman escribió:
>
>
> At https://trac.sagemath.org/ticket/22433 there is a ticket implementing 
>> a move from SageNB towards Jupyter. It does conversion of SageNB 
>> notebooks to Jupyter, hopefully with little loss of functionality (but I 
>> know it's not 100% perfect and it never will be). If you are currently 
>> using SageNB, please test this ticket and tell us your experience. 
>>
>> I propose that the SageMath version after 7.6 will be 8.0 and that this 
>> is merged in 8.0. 
>>
>
> Thank you SO much for your diligent work on this.  I have had virtually no 
> Sage development time for a couple years (largely due to involvement with 
> Sage-related things like MBX and ask.sagemath) but really appreciate 
> everyone who is helping make this transition robust and not abandonware for 
> so many users (such as many reporting on ask.sagemath).  Hopefully a good 
> spring break project for me to do some testing of my sizable notebook 
> collection.  I think that it's reasonable to make 8.0 more or less about 
> this, with sufficient testing.
>
> My big question is what would happen in the server situation?Has 
> anyone tested what would be different for those running sagenb servers, 
> from launch to running?   One of the disappointments is that there still 
> doesn't seem to be an easy-to-install-and-use Jupyter equivalent for the 
> multi-user server which has served many people so well, even if 
> imperfectly.  Perhaps Jupyterhub is now ready for this - but I imagine it 
> would be challenging to have a migration from sagenb to that?
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: what happened to ipython?

[Enrique Artal]

I filed some issues in the thread "ulimit issues and IPython 5.0" in this 
list.

El miércoles, 22 de febrero de 2017, 17:23:41 (UTC+1), kcrisman escribió:
>
>
>
>
> Is it possible? It seems to cause problems to sagenb ...
>>
>>>
>>>
> Really? What sort of problems?  Just not a new enough version for other 
> dependencies?
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: what happened to ipython?

[Enrique Artal]

Is it possible? It seems to cause problems to sagenb ...

El lunes, 20 de febrero de 2017, 16:30:53 (UTC+1), Sébastien Labbé escribió:
>
> @bennigoetz reported the same problem in December 2016 :
> https://github.com/ipython/ipython/issues/9816#issuecomment-258242213
>
> For now, the only solution seems to go back to IPython 4.x ...
>
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: ulimit issues and IPython 5.0

[Enrique Artal]

The following may be related, I encountered it doing some administration in 
our notebooks (sagenb). The following happens in both Sage 7.4 and 7.5 (it 
executes the orders but the warning may suggest some issue in the 
relationship of sagenb and ipython). No warning in 7.3


sage: import sys 
sage: 1+1 
2 
sage: import sagenb.notebook.notebook 
sage: 1+1 
2 
--- 
TypeError Traceback (most recent call last) 
 in () 
> 1 Integer(1)+Integer(1) 

/usr/local/sage-7.4/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc
 
in __call__(self, result) 
244 self.start_displayhook() 
245 self.write_output_prompt() 
--> 246 format_dict, md_dict = self.compute_format_data(result) 
247 self.update_user_ns(result) 
248 self.fill_exec_result(result) 

/usr/local/sage-7.4/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc
 
in compute_format_data(self, result) 
148 
149 """ 
--> 150 return self.shell.display_formatter.format(result) 
151 
152 # This can be set to True by the write_output_prompt method in 
a subclass 

/usr/local/sage-7.4/local/lib/python2.7/site-packages/sage/repl/display/formatter.pyc
 
in format(self, obj, include, exclude) 
158 # First, use Sage rich output if there is any 
159 PLAIN_TEXT = u'text/plain' 
--> 160 sage_format, sage_metadata = self.dm.displayhook(obj) 
161 assert PLAIN_TEXT in sage_format, 'plain text is always 
present' 
162 if sage_format.keys() != [PLAIN_TEXT]: 

TypeError: 'NoneType' object is not iterable 

El miércoles, 8 de febrero de 2017, 8:28:27 (UTC+1), Enrique Artal escribió:
>
> I start a new thread in this list as a continuation of "How to limit heavy 
> computations" in sage-support. I try to summarize the problem. In my 
> University, we have two servers to run math labs; it is done in several 
> instances of sagenb using server_pool to enhance (at least a little bit) 
> security. The sagenb instances are launched with ulimit options but it 
> seems they have no effect.
> In the first term of this academic year, we had several issues affecting 
> the use of this server. Some students started long loops or heavy 
> computations that stop the server (basically their computations blocked one 
> instance and the error messages of the nginx processes grew so much that 
> filled the hard disk). After restarting the machines, the problems came 
> back again; at this point, when we detected such a process it was 
> immediately stopped, but for some reason its instance of sagenb became 
> unusable, causing problems to other students, since it needed restarting 
> (and someone to do it). It was possible (not easy, thanks to Jori 
> Mäntysalo) to identify the actual owner of the process, since stopping the 
> computation by himself caused less harm.
>
> Using ulimit in the OS, namely with the restrictions hard  "as   600" 
> and "hard   cpu   10", it worked. If a computation was too heavy, the 
> process stopped with some error message, but the instance was usable by any 
> other user of the sagenb instance (including the person with the long 
> computation). This was true for Sage 7.3, but no more in Sage 7.4 (and 7.5) 
> where the process was stopped by the instance became unusable in few 
> minutes.
>
> Dima Pasechnik proposed to git-bisect and with the help of Miguel Marco, I 
> think I found the patch causing this behavior. I started checking with 7.4 
> beta and rc and I saw that beta0 had the issue. Looking at the history of 
> changes, it worked after 
> 2b3eb14 Trac #20621: Simpler code and better error messages in Sequence()
> and it didn't work after
> 9831d4b Trac #21006: Upgrade to IPython 5.0
>
> Is there any chance to look into this change in order to localize and 
> solve the problem?
>
> Regards, Enrique.
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] ulimit issues and IPython 5.0

[Enrique Artal]

I start a new thread in this list as a continuation of "How to limit heavy 
computations" in sage-support. I try to summarize the problem. In my 
University, we have two servers to run math labs; it is done in several 
instances of sagenb using server_pool to enhance (at least a little bit) 
security. The sagenb instances are launched with ulimit options but it 
seems they have no effect.
In the first term of this academic year, we had several issues affecting 
the use of this server. Some students started long loops or heavy 
computations that stop the server (basically their computations blocked one 
instance and the error messages of the nginx processes grew so much that 
filled the hard disk). After restarting the machines, the problems came 
back again; at this point, when we detected such a process it was 
immediately stopped, but for some reason its instance of sagenb became 
unusable, causing problems to other students, since it needed restarting 
(and someone to do it). It was possible (not easy, thanks to Jori 
Mäntysalo) to identify the actual owner of the process, since stopping the 
computation by himself caused less harm.

Using ulimit in the OS, namely with the restrictions hard  "as   600" 
and "hard   cpu   10", it worked. If a computation was too heavy, the 
process stopped with some error message, but the instance was usable by any 
other user of the sagenb instance (including the person with the long 
computation). This was true for Sage 7.3, but no more in Sage 7.4 (and 7.5) 
where the process was stopped by the instance became unusable in few 
minutes.

Dima Pasechnik proposed to git-bisect and with the help of Miguel Marco, I 
think I found the patch causing this behavior. I started checking with 7.4 
beta and rc and I saw that beta0 had the issue. Looking at the history of 
changes, it worked after 
2b3eb14 Trac #20621: Simpler code and better error messages in Sequence()
and it didn't work after
9831d4b Trac #21006: Upgrade to IPython 5.0

Is there any chance to look into this change in order to localize and solve 
the problem?

Regards, Enrique.

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Several bugs

[Enrique Artal]

Hi all,
I have found several small bugs. They are unrelated but since I am not 
really able to solve them I put everything in the same message, hoping 
someone smarter than me will find the solution.

   1. For the first one, it was already reported, with an open ticket, but 
   I am worried about it since it produces wrong outputs. The problem appears 
   working with polynomial rings with local orders, e.g., 
   *R.x,y=PolynomialRing(QQ,order='neglex')*. If one defines a non 
   constant polynomial with constant leading monomial,  e.g. *f=1+x*, the 
   output of *1/f* is *1*; in general, the output of 1/(n+non-constant 
   monomials) is 1/n (n constant different from 0). It seems that the problem 
   comes from the fact that the algorithm to divide polynomials checks if the 
   denominator is a unit and in that case the process is to divide every 
   monomial of the numerator by the constant term (which is assumed to be 
   equal to the whole denominator). This is related to the fact that the 
   result of *(1+x).is_unit()* is *True* while the result of *1/(1+x) in R *is 
   *False*. Maybe the point is that for Singular the actual ring defined as 
   R is not the polynomial ring but the localization by the order (i.e., we 
   can divide by any non-zero polynomial whose leading term is a constant); in 
   fact, for algorithmic purposes one always works with polynomials (taking 
   out the possible denominators wisely), but the ring is not a polynomial. I 
   guess that a small change in the way of dividing polynomial would suffice.
   2. When doing some test for the above problem I realize that 
*R.x=PolynomialRing(QQ,order='neglex') 
   *does not take into account the order (the above *f* is not a unit). 
   This is not really an issue, the problem is the fact that the function 
   accept the entry *order* but it ignores it silently.
   3. Next one is completely different and I guess it does not have an 
   issue solution. The symbolic integration has issues when integrating square 
   roots. For example, the integration of *sqrt(sin(x)^2)* produces wrong 
   output.
   4. Finally, the last problem appeared when compiling sage-6.5 with ssl. 
   I followed the standard instructions (which worked in the previous 
   versions) but the compilation of pyopenssl fails. It complains for the 
   compilation of crl.c because of the static definition of a function already 
   declared in a file x509.h of the package openssl. This function 
   is X509_REVOKED_dup. If one eliminates the word static prior to the 
   definition, it works but I do not know if it could cause any issue.

I thank the developpers of this software and I am open to collaborate 
despite my poor level in programming. Best, Enrique.

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Several bugs

[Enrique Artal]

Hi Simon,
Thanks for the feedback

El jueves, 19 de febrero de 2015, 18:23:27 (UTC+1), Simon King escribió:

 Hi Enrique, 

 On 2015-02-19, Enrique Artal enriqu...@gmail.com javascript: wrote: 
 1. For the first one, it was already reported, with an open ticket, 
 but 
 I am worried about it since it produces wrong outputs. 

 If there is an open ticket for it, then there is no need to report it 
 again. However, if it gives wrong results and is not fixed soon then I 
 think 
 there should be a different ticket adding a stopgap (that will print a 
 warning to the user that the computation may have a wrong result. Has 
 the stopgap ticket not been opened as well? 


Not really. I do not know how to do it but I hope I will have some help 
tomorrow in my University 


 Maybe the point is that for Singular the actual ring defined as 
 R is not the polynomial ring but the localization by the order 

 That's very likely the problem. And I think that the cleanest solution 
 would be to take this into account by changing the string representation 
 of a 
 polynomial ring in local ordering: It should not be called 
 polynomial ring over ... with generators ... but localisation at ... 
 of polynomial ring over ... with generators  

 
I agree 


  (i.e., we 
 can divide by any non-zero polynomial whose leading term is a 
 constant); in 
 fact, for algorithmic purposes one always works with polynomials 
 (taking 
 out the possible denominators wisely), but the ring is not a 
 polynomial. I 
 guess that a small change in the way of dividing polynomial would 
 suffice. 

 Very probably not. We would need to deviate from the polynomial backend 
 (i.e., Singular) fairly much to implement this, which would be 
 complicated and slow. 


I think you are right; I think that Singular performs only polynomial 
computations while knowing that the actual ring is larger and this is OK 
for any point of view. I do not know if providing the right mathematical 
answer to division may force to complicate somehow the types of elements in 
the local rings.
 


 2. When doing some test for the above problem I realize that 
 *R.x=PolynomialRing(QQ,order='neglex') 
 *does not take into account the order (the above *f* is not a unit). 

 Yes, it is, since the ring is in fact localised. 

 This is not really an issue, the problem is the fact that the 
 function 
 accept the entry *order* but it ignores it silently. 

 Ahm, why do you think it is ignored? 

I have rechecked that  
*R.t=PolynomialRing(QQ,order='neglex');(1+t).is_unit()* yields False


 Best regards, 
 Simon 


Best regards, Enrique 

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Several bugs

[Enrique Artal]

I did not know this ticket but it is a related problem. I guess, following 
also Simon, that the best choice is to create something like 
LocalPolynomialRing admitting local orderings since even if all the 
algorithms can be performed inside the polynomials (as Singular does) the 
actual rings are different. In the example of ticket #10708, the ideal 
generated by 1-x is the unit ideal, i.e. the total local ring, and hence 
its Krull dimension is -1.

El jueves, 19 de febrero de 2015, 18:35:51 (UTC+1), Nils Bruin escribió:

 On Thursday, February 19, 2015 at 8:46:19 AM UTC-8, Enrique Artal wrote:

 For the first one, it was already reported, with an open ticket, but I am 
 worried about it since it produces wrong outputs. The problem appears 
 working with polynomial rings with local orders, e.g., 
 *R.x,y=PolynomialRing(QQ,order='neglex')*. If one defines a non 
 constant polynomial with constant leading monomial,  e.g. *f=1+x*, the 
 output of *1/f* is *1*;

 I assume you are referring to http://trac.sagemath.org/ticket/10708 . 
 Indeed, that is rather worrying behaviour.


-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Fraction field with local orderings

[Enrique Artal]

Hello,
I recently sent this message

https://groups.google.com/forum/#!topic/sage-support/2ixMoSTzz20

 to the support list. Following the advice of Miguel Marco I opened ticket 
#17638. Best, Enrique

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.