Opened 5 years ago
Last modified 3 years ago
#17254 closed enhancement
Upgrade to Singular4.x.x — at Version 349
Reported by:  jdemeyer  Owned by:  

Priority:  major  Milestone:  sage7.5 
Component:  packages: standard  Keywords:  
Cc:  jpflori, burcin, jakobkroeker, fbissey, malb, mkoeppe, vbraun, nthiery, bhutz, mmarco, gjorgenson  Merged in:  
Authors:  Jakob Kroeker, JeanPierre Flori, Jeroen Demeyer  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  public/singular4 (Commits)  Commit:  f8362a9c233f198d6d97dc22d16d09c47fd431c8 
Dependencies:  #17635  Stopgaps: 
Description (last modified by )
Lots of stuff has changed in Singular 4. This is a big update.
Build system completely changed, and a lot of internal stuff.
Upstream tarball at:
Modified tarball made with spkgsrc at:
This corresponds to commit a070b84d whose message tells 4.0.3p3 and on which this branch was based:
You can also make your own tarball based on this commit or another one with
env SINGULAR_GIT_COMMIT=a070b84d ./sage sh build/pkgs/singular/spkgsrc ./sage package fixchecksum singular
This script is loosely based on the make_tar.sh
script from upstream.
Change History (349)
comment:1 Changed 5 years ago by
 Branch set to u/jdemeyer/ticket/17254
 Commit set to 2fcaeb5fadff9391624d03819bd9a4d405fdda72
 Description modified (diff)
comment:2 followup: ↓ 3 Changed 5 years ago by
comment:3 in reply to: ↑ 2 ; followup: ↓ 4 Changed 5 years ago by
comment:4 in reply to: ↑ 3 Changed 5 years ago by
 Cc burcin added
comment:5 Changed 5 years ago by
 Cc jakobkroeker added
comment:6 Changed 5 years ago by
Q: where to get the singular tarball for this commit? I get a failure at
Trying to download http://www.sagemath.org/packages/upstream/singular/singular4.0.1p1.tar.bz2
2.
Update to Singular 4.0.1
Maybe Burcin would do...
Could the update to 4.0.1. be done by at least two or three persons to spread the knownledge about Singular internals?
comment:7 followup: ↓ 16 Changed 5 years ago by
You have to put a tarball repackaged by the spkgsrc
script in the upstream
folder directly.
Once the ticket is merged, the tarball will be put on the official mirror and could be downloaded automatically but not at the moment.
I've put a repackaged tarball at:
comment:8 Changed 5 years ago by
(I'm not sure the checksums will the same as what Jeroen branch expect, run ./sage sh sagefixpkgchecksums
after you have downloaded the tarball to fix this.)
comment:9 Changed 5 years ago by
And I'd be happy to work on the upgrade and learn more about Singular's internals, but please also review the "easy" #17184 (where I've already learnt some stuff) firsT.
comment:10 Changed 5 years ago by
 Description modified (diff)
comment:11 followup: ↓ 17 Changed 5 years ago by
Singular 4.0.1. compiles now in sage but sage does not yet  I just pushed a branch 'u/jakobkroeker/ticket/17254'. You have to correct the 'singular4.0.1p1.tar.bz2' tarball to get it work ( the 'm4' folder is missing).
For the moment I removed some patches; we probably will have to adjust them later on. For example there is meanwhile no such thing like 'lomalloc_ndebug' so if we want to disable some debug functionality or output for omalloc we have to do that by passing appropriate flags to omalloc/configure, e,g 'enableoptimizationflags disabledebug withoutdebug' ?
Also I disabled the currently broken 'enabledebugoutput' configure flag for the standalone 'factory' and informed Oleksander Motsak about the issue.
Could someone of you take care of the sage compile errors and figure out what is going wrong and/or ask for help in the Singular forum? I can't do that easily, because within the Singularteam I'm outoffavor because I constantly criticise their software and thus I will likely get little or no support.
Jakob
comment:12 Changed 5 years ago by
 Branch changed from u/jdemeyer/ticket/17254 to u/jakobkroeker/ticket/17254
 Commit changed from 2fcaeb5fadff9391624d03819bd9a4d405fdda72 to 4c0bba332e4d67e3fc28df9b1ec9d136eb895b4a
New commits:
4c0bba3  singular 4.0.1 builds now, but sage does not due to changes in libsingular?

comment:13 Changed 5 years ago by
 Branch changed from u/jakobkroeker/ticket/17254 to u/jdemeyer/ticket/17254
 Commit changed from 4c0bba332e4d67e3fc28df9b1ec9d136eb895b4a to 2fcaeb5fadff9391624d03819bd9a4d405fdda72
comment:14 Changed 5 years ago by
first hint: for example the interface of 'naIsZero' seems changed from
BOOLEAN naIsZero(number a)
to
BOOLEAN naIsZero(number a, const coeffs cf)
Persons who might have an idea about the changes:
Oleksandr Motsak Mohamed Barakat Martin Lee Hans Schönemann
see contact details at http://www.mathematik.unikl.de/agag/mitglieder/
comment:15 Changed 5 years ago by
 Cc fbissey added
comment:16 in reply to: ↑ 7 Changed 5 years ago by
Replying to jpflori:
I've put a repackaged tarball at:
That's an older version than the one that I put in the ticket description, any reason...?
comment:17 in reply to: ↑ 11 Changed 5 years ago by
Replying to jakobkroeker:
You have to correct the 'singular4.0.1p1.tar.bz2' tarball to get it work ( the 'm4' folder is missing).
My tarball compiled fine, so what is the problem?
comment:18 Changed 5 years ago by
You should never run ./autogen.sh
, that is supposed to be run at packagingtime, not buildtime.
comment:19 Changed 5 years ago by
 Commit changed from 2fcaeb5fadff9391624d03819bd9a4d405fdda72 to 80a6b05a08e391fa9718e1f83df861c93e2e5967
comment:20 Changed 5 years ago by
My tarball compiled fine, so what is the problem?
Confirm; cannot reproduce the issue. So likely I didn't use the recent tarball, or I screwed something up.
You should never run ./autogen.sh, that is supposed to be run at packagingtime, not buildtime.
I'm guilty ;)
comment:21 Changed 5 years ago by
singulars spkginstall:
the 'enabledebugoutput' configure flag for standalone factory needs now in additon 'enablestreamio withoutSingular'
comment:22 Changed 5 years ago by
 Branch changed from u/jdemeyer/ticket/17254 to u/jakobkroeker/ticket/17254
 Cc malb added
 Commit changed from 80a6b05a08e391fa9718e1f83df861c93e2e5967 to f178dfc5c45529826a973815b62ab5be2a7f7136
After a little more tweaking and temporarily disabling the extension fields/rings, I was able to build some parts of sage with Singular 4.0.1 on a 'fc18 system' and then.. sage crashes at start! That happens because I didn't update ring creation right  I only recently discovered examples at './libpolys/tests/rings_test.h'. And some sage packages create common rings at loading time.
remaining riddles:
 during build one sage file tried to link to lsingular (I have no idea why), instead to the libSingular* files (that changed!), so I worked around by manually creating links to libSingular* files.
 on a ScientificLinux? system I get errors like "ImportError?: /home/kroeker/Projects/sagesingular4.0.1/local/lib/python2.7/sitepackages/sage/rings/polynomial/plural.so: undefined symbol: wFunctionalBuch". This symbol is in libSingular*
 fix ring creation. See examples at './libpolys/tests/rings_test.h'
 the extension fields will need some more love. See 'algext.h' and 'transext.h'. @Martin: could you take a look?
 some mapping functions (e.g. nr2mMapZp) now require a source and dst (coefficient) parameter. Not sure if I did it right (source: currentRing, dest: _ring or vice versa?)
 I didn't fix unused interface definitions in singularcdefs.pxi. TODO
See branch u/jakobkroeker/ticket/17254 and some notes at https://github.com/jakobkroeker/jk_test_sage/issues/13
If a build get stuck before errors described above, then maybe a 'make distclean' is necessary. And of course, the Singular tarball http://boxen.math.washington.edu/home/jdemeyer/spkg/singular4.0.1p1.tar.bz2 is required.
Any help appreciated.
New commits:
79c079f  Upgrade to Singular401

2fcaeb5  Update Singular to 4.0.1

4c0bba3  singular 4.0.1 builds now, but sage does not due to changes in libsingular?

80a6b05  Merge commit '4c0bba3' into ticket/17254

2ae243a  messy fixes

ff2a9dc  required changes for singular to build sage; should be fixed upstream

3b7877e  hacking sage to build with Singular 4.0.1. needs more love for extension coefficient fields and a refactoring

f178dfc  fixing nr2mMapZp call

comment:23 Changed 5 years ago by
 Commit changed from f178dfc5c45529826a973815b62ab5be2a7f7136 to 8ba17d8bc77cab7d3cffdda267dde132cbaff45e
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
8ba17d8  messy fixes

comment:24 Changed 5 years ago by
 Commit changed from 8ba17d8bc77cab7d3cffdda267dde132cbaff45e to c2a21bd383e0f9d82dd409efbd4b48a4317be0c7
Branch pushed to git repo; I updated commit sha1. New commits:
2ae243a  messy fixes

ff2a9dc  required changes for singular to build sage; should be fixed upstream

3b7877e  hacking sage to build with Singular 4.0.1. needs more love for extension coefficient fields and a refactoring

f178dfc  fixing nr2mMapZp call

8e82387  Merge branch 'u/jakobkroeker/jakobkroeker.ticket.17254' of git://trac.sagemath.org/sage into jakobkroeker.ticket.17254

c2a21bd  fixed some ring creation

comment:25 Changed 5 years ago by
 Branch changed from u/jakobkroeker/ticket/17254 to trac/u/jakobkroeker/ticket.17254.squashed
 Commit c2a21bd383e0f9d82dd409efbd4b48a4317be0c7 deleted
comment:26 Changed 5 years ago by
 Branch changed from trac/u/jakobkroeker/ticket.17254.squashed to u/jakobkroeker/ticket.17254.squashed
 Commit set to 6384b9b8d22905e7dcc72b84df33effae9c8a517
New commits:
6384b9b  Upgrade to Singular 4.0.1: incomplete, messy patch(first aproach)

comment:27 Changed 5 years ago by
 Description modified (diff)
comment:28 Changed 5 years ago by
 Commit changed from 6384b9b8d22905e7dcc72b84df33effae9c8a517 to 221c5d63e02d7f1d7fdc57cf6c819677553dd262
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
221c5d6  Upgrade to Singular 4.0.1: incomplete, messy patch(first aproach)

comment:29 Changed 5 years ago by
 Commit changed from 221c5d63e02d7f1d7fdc57cf6c819677553dd262 to 1e847897b9fce54fa25f1b91dea78f9e225ad0c9
Branch pushed to git repo; I updated commit sha1. New commits:
1e84789  one more renaming from libsingular to libSingular

comment:30 Changed 5 years ago by
 Commit changed from 1e847897b9fce54fa25f1b91dea78f9e225ad0c9 to 3a512cd7e08e21a4a4e66bfe9179290601717ba0
Branch pushed to git repo; I updated commit sha1. New commits:
3a512cd  improved error handling messages when loading Singular

comment:31 Changed 5 years ago by
What is the status of this ticket? I see the branch is off 6.5.rc0, which is quite old already...
comment:32 followup: ↓ 33 Changed 5 years ago by
What is the status of this ticket? I see the branch is off 6.5.rc0, which is quite old already...
I'm busy and can't work on the ticket currently and expect to have time for the ticket at end of June, not earlier...
with the state as is, sage should build and start (using the Singular tarball from above), but extension fields and transcendental fields are not functional yet and also a cython Singularinterface cleanup has to be done.
comment:33 in reply to: ↑ 32 Changed 5 years ago by
Replying to jakobkroeker:
I'm busy and can't work on the ticket currently and expect to have time for the ticket at end of June, not earlier...
with the state as is, sage should build and start (using the Singular tarball from above), but extension fields and transcendental fields are not functional yet and also a cython Singularinterface cleanup has to be done.
I'm at SD64.25 and am willing to work on this, but I'll need some handholding since I haven't worked on a package like this before. Do you have any suggestions for ways to test extension and transcendental fields?
comment:34 followup: ↓ 56 Changed 5 years ago by
I just applied this to 6.4.1 and encountered the message,
fatal error: Singular/libsingular.h: No such file or directory
while compiling
build/cythonized/sage/algebras/letterplace/free_algebra_element_letterplace.cpp
Any ideas what causes this?
comment:35 followup: ↓ 36 Changed 5 years ago by
I haven't looked yet at the new singular 4.0.x but the first port of call would be to check if the header is indeed installed in $SAGE_LOCAL/include
.
comment:36 in reply to: ↑ 35 Changed 5 years ago by
Replying to fbissey:
I haven't looked yet at the new singular 4.0.x but the first port of call would be to check if the header is indeed installed in
$SAGE_LOCAL/include
.
Shortly after, that installation of Sage fell completely apart (not sure why) so now I'm working on Sage6.7.
On 6.7, git identifies some issues with merging in singular.pyx and ring.pyx, but they're fairly clear to fix, so I did. (Unless they weren't easy.) Things went much further this time, until I encountered this error:
**************************************************** ### Singular spkginstall: choose_patches ### ### Singular spkginstall: apply_patches ### Applying /Applications/sage6.7/local/var/tmp/sage/build/singular4.0.1p1.p0/patches/stricmp.patch can't find file to patch at input line 7 Perhaps you used the wrong p or strip option? The text leading up to this was:  stricmp is being deprecated in Cygwin. One should use strcasecmp. See https://cygwin.com/ml/cygwin/201410/msg00359.html diff druN src/latest/Singular/run.c src/latest/Singular/run.c  latest/Singular/run.c 20141119 14:06:05.000000000 +0100 +++ latest/Singular/run.c 20150116 09:32:45.771298300 +0100  File to patch: Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored Error applying '/Applications/sage6.7/local/var/tmp/sage/build/singular4.0.1p1.p0/patches/stricmp.patch' Error building Singular (error in apply_patches).
Here's what the file in question suggests:
stricmp is being deprecated in Cygwin. One should use strcasecmp. See https://cygwin.com/ml/cygwin/201410/msg00359.html diff druN src/latest/Singular/run.c src/latest/Singular/run.c  latest/Singular/run.c 20141119 14:06:05.000000000 +0100 +++ latest/Singular/run.c 20150116 09:32:45.771298300 +0100 @@ 45,6 +45,7 @@ #include <sys/stat.h> #include <sys/cygwin.h> #include <sys/unistd.h> + #define stricmp strcasecmp //WinMainCRTStartup() { mainCRTStartup(); } #else #include <direct.h>
Indeed, I do not find run.c
in local/var/tmp/sage/build/singular4.0.1p1.p0/src/latest/Singular/
, which I am guessing is where this is supposed to be; instead, I find only run.h.
In my local distribution of Singular, I find a run.c
. If I copy it over & try to make, I get the same complaint, & it looks as if the file is actually deleted. Suggestions?
comment:37 Changed 5 years ago by
Did you mean local/var/tmp/sage/build/singular4.0.1p1.p0/src/Singular/
the latest
bit should be stripped by the p1
option to patch.
comment:38 Changed 5 years ago by
The patch has latest
in it; that's why I wrote that in there, so that is what I mean. Is your meaning that latest
should not be there? That directory doesn't exist when I look through the paths.
comment:39 followup: ↓ 40 Changed 5 years ago by
It is expected for that directory not to exist for you. Whoever wrote the patch was working in a folder named latest
but it is their own naming. It doesn't matter anyway. Let me explain to you how the p
option of patch works.
Your patch has a header that helps you locate the file to patch:
 latest/Singular/run.c 20141119 14:06:05.000000000 +0100 +++ latest/Singular/run.c 20150116 09:32:45.771298300 +0100
patch < mypatch.patch
or equivalently patch p0< mypatch.patch
will look for the file
latest/Singular/run.c
relative to where patch is executed. pN
will strip the N
first folders in front of the file name so
patch p1< mypatch.patch
will look for Singular/run.c
. In spkginstall
for singular, patches are applied with patch p1 <"$patch"
so you shouldn't care about latest
it is discarded. Look for local/var/tmp/sage/build/singular4.0.1p1.p0/src/Singular/run.c
OK?
comment:40 in reply to: ↑ 39 Changed 5 years ago by
I think you misunderstand.
Replying to fbissey:
It is expected for that directory not to exist for you.
Why not? That directory does exist for me. The problem is that the file run.c
does not exist in it.
Look for
local/var/tmp/sage/build/singular4.0.1p1.p0/src/Singular/run.c
OK?
There is no such directory. I can get to local/var/tmp/sage/build/singular4.0.1p1.p0/src/
but the only directories in there are latest
and shared
.
comment:41 Changed 5 years ago by
OK you seem to be right. The tarball has been packaged strangely and I am not sure I have the right spkginstall
. It is a cygwin patch and cygwin support in singular seems to have changed considerably. I would just remove the patch for now, it doesn't/cannot apply anywway any new fix for cygwin would have to be done from scratch by someone with a cygwin system.
comment:42 Changed 5 years ago by
How do I remove it? If I move it & make
anew, the file reappears.
comment:43 Changed 5 years ago by
git rm build/pkgs/singular/patches/stricmp.patch
?
comment:44 followup: ↓ 54 Changed 5 years ago by
Thanks, that worked. Now I get failure on a line in ring.pyx,
if is_64_bit:
Namely, Cython (?) claims this is undefined. I guess this is a change in Cython, since that isn't introduced by this patch. I found online another way to test this (sys.maxsize > 2**32
) so I'm trying with that. Found another issue, but that was easy. Proceeding with fingers crossed... it's still compiling, which is already an progress...!
comment:45 Changed 5 years ago by
It seems to have built, but Sage doesn't run. Here's the last few lines of the compilation (sorry for so much, but I wanted to show what it was saying at the end of what looks like a successful build, too):
... bytecompiling /Applications/sage6.7/local/lib/python2.7/sitepackages/sage_setup/find.py to find.pyc bytecompiling /Applications/sage6.7/local/lib/python2.7/sitepackages/sage_setup/optional_extension.py to optional_extension.pyc running install_egg_info Removing /Applications/sage6.7/local/lib/python2.7/sitepackages/sage6.8.beta0py2.7.egginfo Writing /Applications/sage6.7/local/lib/python2.7/sitepackages/sage6.8.beta0py2.7.egginfo real 0m25.849s user 0m11.855s sys 0m3.847s [ f local/etc/sagestarted.txt ]  local/bin/sagestarts build/pipestatus "./sage docbuild nopdflinks all html 2>&1" "tee a logs/dochtml.log" Deleting empty directory /Applications/sage6.7/src/doc/common/static Deleting empty directory /Applications/sage6.7/src/doc/en/reference/combinat/static Deleting empty directory /Applications/sage6.7/src/doc/en/reference/combinat/templates Deleting empty directory /Applications/sage6.7/src/doc/en/reference/polynomial_rings/static Deleting empty directory /Applications/sage6.7/src/doc/en/reference/polynomial_rings/templates Deleting empty directory /Applications/sage6.7/src/doc/en/reference/repl/static Deleting empty directory /Applications/sage6.7/src/doc/en/reference/repl/templates Deleting empty directory /Applications/sage6.7/src/doc/en/reference/tensor_free_modules/static Deleting empty directory /Applications/sage6.7/src/doc/en/reference/tensor_free_modules/templates Deleting empty directory /Applications/sage6.7/src/doc/output/inventory/en/reference/combinat Traceback (most recent call last): File "/Applications/sage6.7/src/doc/common/builder.py", line 1619, in <module> import sage.all File "/Applications/sage6.7/local/lib/python2.7/sitepackages/sage/all.py", line 98, in <module> from sage.rings.all import * File "/Applications/sage6.7/local/lib/python2.7/sitepackages/sage/rings/all.py", line 68, in <module> from number_field.all import * File "/Applications/sage6.7/local/lib/python2.7/sitepackages/sage/rings/number_field/all.py", line 7, in <module> from totallyreal import enumerate_totallyreal_fields_prim File "sage/rings/number_field/totallyreal_data.pxd", line 16, in init sage.rings.number_field.totallyreal (build/cythonized/sage/rings/number_field/totallyreal.c:10339) File "sage/rings/number_field/totallyreal_data.pyx", line 39, in init sage.rings.number_field.totallyreal_data (build/cythonized/sage/rings/number_field/totallyreal_data.c:11133) File "/Applications/sage6.7/local/lib/python2.7/sitepackages/sage/rings/polynomial/polynomial_ring_constructor.py", line 465, in PolynomialRing R = _single_variate(base_ring, name, sparse, implementation) File "/Applications/sage6.7/local/lib/python2.7/sitepackages/sage/rings/polynomial/polynomial_ring_constructor.py", line 539, in _single_variate R = m.PolynomialRing_integral_domain(base_ring, name, sparse, implementation) File "/Applications/sage6.7/local/lib/python2.7/sitepackages/sage/rings/polynomial/polynomial_ring.py", line 1544, in __init__ sparse=sparse, element_class=element_class) File "/Applications/sage6.7/local/lib/python2.7/sitepackages/sage/rings/polynomial/polynomial_ring.py", line 1451, in __init__ sparse=sparse, element_class=element_class, category=category) File "/Applications/sage6.7/local/lib/python2.7/sitepackages/sage/rings/polynomial/polynomial_ring.py", line 305, in __init__ from sage.matrix.matrix_space import is_MatrixSpace File "/Applications/sage6.7/local/lib/python2.7/sitepackages/sage/matrix/matrix_space.py", line 57, in <module> import matrix_mpolynomial_dense ImportError: dlopen(/Applications/sage6.7/local/lib/python2.7/sitepackages/sage/matrix/matrix_mpolynomial_dense.so, 2): Symbol not found: __Z17initCanonicalFormv Referenced from: /Applications/sage6.7/local/lib/python2.7/sitepackages/sage/matrix/matrix_mpolynomial_dense.so Expected in: flat namespace in /Applications/sage6.7/local/lib/python2.7/sitepackages/sage/matrix/matrix_mpolynomial_dense.so make: *** [dochtml] Error 1
comment:46 Changed 5 years ago by
It appears that it should be generated by initCanonicalForm
but no functions of that name is to be found in the source code I have for singular 4.0.2 here and I am expecting it to be the same for you. I think you may have old singular headers on your system that are interfering (factory.h
) we'll have to develop a proper upgrade procedure to remove singular 3.1.x stuff before installing 4.x. That or the singular 4.x headers have not been installed properly. local/include/factory/factory/factory.h
and local/include/factory/factory.h
both have this function in singular 3.1.7 but it shouldn't be present in the equivalent headers from singular 4.x.
comment:47 Changed 5 years ago by
I don't seem to have a local/include/factory
at all...
comment:48 Changed 5 years ago by
I really have to inspect the spkg. I think I went overboard with the factory
in the path. Should have been local/include/factory.h
and local/include/factory/factory.h
. Do you have a factory.h
and does it contains initCanonicalForm
?
comment:49 Changed 5 years ago by
make distclean
then make
seems to have fixed my problems. I am apparently running Singular 4, albeit with the changes I mentioned earlier. At startup, I see the following:
ring with rational coefficient field created _ring.ShortOut 1 _ring.N 2 polynomial ring over integers created _ring.ShortOut 1 _ring.N 2 ring with rational coefficient field created _ring.ShortOut 1 _ring.N 2
I found that in the source code, so I'm guessing this was put in to test.
comment:50 Changed 5 years ago by
Well, this is bad.
sage: R=PolynomialRing(GF(32003),'x',7) sage: I = sage.rings.ideal.Cyclic(R,7).homogenize()  RuntimeError Traceback (most recent call last) <ipythoninput259ae6a3e91c7> in <module>() > 1 I = sage.rings.ideal.Cyclic(R,Integer(7)).homogenize() /Applications/sage6.7/local/lib/python2.7/sitepackages/sage/rings/ideal.pyc in Cyclic(R, n, homog, singular) 1607 n = R.ngens() 1608 > 1609 singular.lib("poly") 1610 R2 = R.change_ring(RationalField()) 1611 R2._singular_().set_ring() /Applications/sage6.7/local/lib/python2.7/sitepackages/sage/interfaces/singular.pyc in lib(self, lib, reload) 783 if not reload and lib in self.__libs: 784 return > 785 self.eval('LIB "%s"'%lib) 786 self.__libs.append(lib) 787 /Applications/sage6.7/local/lib/python2.7/sitepackages/sage/interfaces/singular.pyc in eval(self, x, allow_semicolon, strip, **kwds) 585 x += ';' 586 > 587 s = Expect.eval(self, x, **kwds) 588 589 if s.find("error") != 1 or s.find("Segment fault") != 1: /Applications/sage6.7/local/lib/python2.7/sitepackages/sage/interfaces/expect.pyc in eval(self, code, strip, synchronize, locals, allow_use_file, split_lines, **kwds) 1220 elif split_lines: 1221 return '\n'.join([self._eval_line(L, allow_use_file=allow_use_file, **kwds) > 1222 for L in code.split('\n') if L != '']) 1223 else: 1224 return self._eval_line(code, allow_use_file=allow_use_file, **kwds) /Applications/sage6.7/local/lib/python2.7/sitepackages/sage/interfaces/expect.pyc in _eval_line(self, line, allow_use_file, wait_for_prompt, restart_if_needed) 817 try: 818 if self._expect is None: > 819 self._start() 820 E = self._expect 821 try: /Applications/sage6.7/local/lib/python2.7/sitepackages/sage/interfaces/singular.pyc in _start(self, alt_message) 410 """ 411 self.__libs = [] > 412 Expect._start(self, alt_message) 413 # Load some standard libraries. 414 self.lib('general') # assumed loaded by misc/constants.py /Applications/sage6.7/local/lib/python2.7/sitepackages/sage/interfaces/expect.pyc in _start(self, alt_message, block_during_init) 427 # Change pexpect errors to RuntimeError 428 raise RuntimeError("unable to start %s because the command %r failed: %s\n%s" % > 429 (self.name(), cmd, e, self._install_hints())) 430 except BaseException: 431 self._expect = None RuntimeError: unable to start singular because the command 'Singular t tickspersec 1000' failed: The command was not found or was not executable: Singular.
comment:51 Changed 5 years ago by
For what it's worth, lots of other things work.: I can, for instance, compute an ideal's Gröbner basis, its Hilbert [numerator, series, polynomial], and so forth.
comment:52 Changed 5 years ago by
Indeed, there is no Singular binary in local/bin. I presume this is the problem, though I have no idea what became of it.
comment:53 followup: ↓ 55 Changed 5 years ago by
I'm guessing that failure to install the singular binary is because of a symlink: local/bin/singular' points to
local/bin/Singular and removing the old (3.x)
Singular wasn't enough to allow the new one in. I removed
local/bin/singular` and it's now working.
This may be an issue with Apple's file system, because after installing the new Singular
I wasn't allowed to create the symlink.
comment:54 in reply to: ↑ 44 Changed 5 years ago by
is_64_bit
is deprecated. In Cython, check sizeof(the_type_that_you_care_about)
instead.
Do not use sys.maxsize
, that's much slower.
comment:55 in reply to: ↑ 53 Changed 5 years ago by
Replying to john_perry:
I'm guessing that failure to install the singular binary is because of a symlink:
local/bin/singular' points to
local/bin/Singularand removing the old (3.x)
Singularwasn't enough to allow the new one in. I removed
local/bin/singular` and it's now working.This may be an issue with Apple's file system, because after installing the new
Singular
I wasn't allowed to create the symlink.
Yes you may have seen another ticket in which I demonstrated that something like Singular
was really singular
. OS X file system is not case sensitive but it gives the impression of being one.
comment:56 in reply to: ↑ 34 ; followups: ↓ 57 ↓ 62 ↓ 63 Changed 5 years ago by
Replying to john_perry:
I just applied this to 6.4.1 and encountered the message,
fatal error: Singular/libsingular.h: No such file or directory
while compiling
build/cythonized/sage/algebras/letterplace/free_algebra_element_letterplace.cpp
Any ideas what causes this?
It's now certain that this, too, was caused by the failure to install Singular
because singular
exists in the directory (what can I say, it's a Mac). Removing that link and reinstalling the spkg fixed all these problems.
Meanwhile, I discovered some memoryrelated bugs in the patch. For instance, ring.pyx has the line
assert( exponent == base_ring.degree() )
which causes a failure. I'm not sure why those should be equal (the test I used had Zmod(2^3)
where exponent==3
and base_ring.degree()==1
), but commenting it out leads to a failure on these lines:
_param.GFChar = ch; _param.GFDegree = base_ring.degree(); _param.GFPar_name = omStrDup(base_ring.gen());
because _param
has not been initialized. Adding
_param = <GFInfo *>omAlloc(sizeof(GFInfo));
before the access gives me a ring. However,
 I'm not sure whether
omAlloc
or one of the otheromAlloc*
commands is more appropriate (e.g.,omAlloc0
). Anyone know?  I suppose this has to be freed somewhere... I know there's an obvioussounding place, so I'll find it.
There are other places this change has to occur. One more question:
 A few lines before the ones I cited above is the test for 64bits. I've switched to jdemeyer's test (
sizeof(long)>4
). However, the code in the patch is exactly the same for both 32 and 64bit. Is there a recommendation for what to do here? I'm not sufficiently familiar with this to know what to do.
comment:57 in reply to: ↑ 56 Changed 5 years ago by
Replying to john_perry:
Meanwhile, I discovered some memoryrelated bugs in the patch. For instance, ring.pyx has the line
assert( exponent == base_ring.degree() )which causes a failure. I'm not sure why those should be equal (the test I used had
Zmod(2^3)
whereexponent==3
andbase_ring.degree()==1
)...
To wit, the source code for base_ring.degree()
is, in total,
def degree(self): """ Return 1. EXAMPLE:: sage: R = Integers(12345678900) sage: R.degree() 1 """ return integer.Integer(1)
I don't know what is meant by the degree of a ring here, so I'll need guidance. For now I've commented it out.
comment:58 Changed 5 years ago by
 Branch changed from u/jakobkroeker/ticket.17254.squashed to u/john_perry/ticket.17254.squashed
comment:59 Changed 5 years ago by
 Commit changed from 3a512cd7e08e21a4a4e66bfe9179290601717ba0 to 1f4ebcbf9e431a629ba1a899267dd9b42d4ed0cf
Pushed code should build on 6.7. Mac users may have problems; if so, delete local/bin/singular
and then sagespkg singular
; it should work after that. (In fact, I have to do it again myself now.) I have to run to the train (leaving SD) or I'd do it before leaving.
New commits:
bdb0851  first attempt to resolve

1f4ebcb  fix for _param and discrepancy between exponent and degree

comment:60 Changed 5 years ago by
Forgot to remove that bad patch; that will come in a subsequent push. Still have the problem with local/bin/Singular
because of the local symlink; it's a problem with the package itself, because I deleted both symlink and local copy before running the install. I don't know how to fix that, so advice would be appreciated.
comment:61 Changed 5 years ago by
 Commit changed from 1f4ebcbf9e431a629ba1a899267dd9b42d4ed0cf to 9aa24564da611fd23d29dd9c5866cfef0be5b4f2
Branch pushed to git repo; I updated commit sha1. New commits:
9aa2456  delete stricmp.patch

comment:62 in reply to: ↑ 56 Changed 5 years ago by
Replying to john_perry:
However, the code in the patch is exactly the same for both 32 and 64bit. Is there a recommendation for what to do here?
Obviously, replace
if condition: X else: X
by
X
comment:63 in reply to: ↑ 56 Changed 5 years ago by
Replying to john_perry:
 A few lines before the ones I cited above is the test for 64bits. I've switched to jdemeyer's test (
sizeof(long)>4
). However, the code in the patch is exactly the same for both 32 and 64bit. Is there a recommendation for what to do here? I'm not sufficiently familiar with this to know what to do.
Look at the diff for the old corresponding code: this doesn't have the branch.
comment:64 Changed 5 years ago by
I would also recommend you to keep the logic of the old code where applicable. For example, the old code started with
if ch.is_power_of(2): exponent = ch.nbits() 1 # it seems Singular uses ints somewhere # internally, cf. #6051 (Sage) and #138 (Singular) if exponent <= 30:
and I see no reason to change this.
comment:65 Changed 5 years ago by
 Branch changed from u/john_perry/ticket.17254.squashed to public/ticket/17254
 Commit changed from 9aa24564da611fd23d29dd9c5866cfef0be5b4f2 to ab68eb0be8aec650b12e3c922ce282f5bd506490
naive rebase.
The spkg is no longer available from boxen..
New commits:
ab68eb0  Merge branch 'u/john_perry/ticket.17254.squashed' into 6.9.b0

comment:66 Changed 5 years ago by
The [singular 4.0.1] spkg is no longer available from boxen..
That is unfortunate. @jdemeyer/@jpflori: could you upload the singular 4.0.1.p1 tarball to somewhere else?
naive rebase. [by chapoton] Conflicts:
src/sage/libs/singular/singularcdefs.pxi
the file src/sage/libs/singular/singularcdefs.pxi
is even missing in the ticket branch
public/ticket/17254
@chapoton
Did you set the ticket branch to broken public/ticket/17254
instead of leaving it
'u/john_perry/ticket.17254.squashed
' by accident?
comment:67 Changed 5 years ago by
It seems I don't have access to boxen anymore...
comment:68 Changed 5 years ago by
And I don't have the p1
tarball Jeroen posted.
comment:69 Changed 5 years ago by
I have a tarball answering that description. Up on the lmona.de server....
comment:70 Changed 5 years ago by
 Description modified (diff)
comment:71 Changed 5 years ago by
 Branch changed from public/ticket/17254 to u/jakobkroeker/ticket.17254.squashed
 Commit changed from ab68eb0be8aec650b12e3c922ce282f5bd506490 to aa40c90711a6c50fe3b78fc0668370a9046f20a2
comment:72 Changed 5 years ago by
@chapoton
naive rebase.
except for the issue with src/sage/libs/singular/singularcdefs.pxi
, how did you do the rebase?
Did you a rebase by hand, or did you create a patch after merge and then apply the patch to 6.9.b0?
comment:73 Changed 5 years ago by
 Commit changed from aa40c90711a6c50fe3b78fc0668370a9046f20a2 to 72ef9273b6d33a7771fd7c42a47ac5e430a81197
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
72ef927  squashed singular upgrade changes in one commit

comment:74 Changed 5 years ago by
 Commit changed from 72ef9273b6d33a7771fd7c42a47ac5e430a81197 to 4adc75d8a3982aed7b9e66a9a567cfeb4c2fc81b
Branch pushed to git repo; I updated commit sha1. New commits:
4adc75d  squashed singular upgrade changes in one commit

comment:75 Changed 5 years ago by
 Commit changed from 4adc75d8a3982aed7b9e66a9a567cfeb4c2fc81b to f492ef2752f810b0fec487ac6bd7044c5d75827c
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
f492ef2  squashed singular upgrade changes in one commit

comment:76 followup: ↓ 77 Changed 5 years ago by
@john_perry thanks for the bugfix!
I am willing to work on this
somehow I overlooked your messages in my emails in the past.Are you still available for help? Maybe we could work together on the remaining issues? (skype?)
An example of creating extension fields can be found in Singulars
libpolys/tests/polys_test.h :: test_Q_Ext_a()
)
while the basic data structure idea is sketched in
libpolys/polys/ext_fields/algext.h
comment:77 in reply to: ↑ 76 Changed 5 years ago by
Replying to jakobkroeker:
@john_perry somehow I overlooked your messages in my emails in the past.Are you still available for help? Maybe we could work together on the remaining issues? (skype?)
I'm willing to collaborate on it, but I've had a more pressing project which has consumed my attention/free time. I thought I'd be done with it months ago :) so I can't promise to be very helpful and/or focus on this at the moment, but I do hope to be available from time to time, until the current project passes in which case I could focus on this a little bit.
comment:78 Changed 5 years ago by
 Branch changed from u/jakobkroeker/ticket.17254.squashed to u/jakobkroeker/ticket.17254.squashed.new
 Commit changed from f492ef2752f810b0fec487ac6bd7044c5d75827c to 90cefc5509dbe54f05781a82d76935319da3364a
New commits:
90cefc5  bugfixes

comment:79 Changed 5 years ago by
added support for extensions over QQ; fixed some bugs of mine
open tasks:
put back si2sa_GFqGivaro, si2sa_GFqNTLGF2E, si2sa_GFq_generic
and fix failing tests  a lot of tests (about 100) still fail:
naMap00()
call in singular.pyx
crashes  either I use it incorrectly or there is a bug in Singular.
comment:80 Changed 5 years ago by
 Commit changed from 90cefc5509dbe54f05781a82d76935319da3364a to b4d049557c374f61a497d5c61d27ca13b2993281
Branch pushed to git repo; I updated commit sha1. New commits:
b4d0495  removed printouts

comment:81 Changed 5 years ago by
repackaged latest Singular
https://www.dropbox.com/s/3io9k5srkcjrysr/singular4.0.2.latest.tar.bz2?dl=0
comment:82 Changed 5 years ago by
 Commit changed from b4d049557c374f61a497d5c61d27ca13b2993281 to 5e14c77bd2222d901b33588f0f67bb694c3c1b48
Branch pushed to git repo; I updated commit sha1. New commits:
5e14c77  updated to latest singular

comment:83 Changed 5 years ago by
 Commit changed from 5e14c77bd2222d901b33588f0f67bb694c3c1b48 to 179ecd8b461135724979671c786301e515abb00c
Branch pushed to git repo; I updated commit sha1. New commits:
179ecd8  support building singular in debug mode

comment:84 Changed 5 years ago by
 Description modified (diff)
comment:85 Changed 5 years ago by
@malb
while upgrading to Singular 4 I'm currently hit a segfault in Singular for
sage: x = var('x') sage: K.<z> = QQ.extension(x^2 + 1) sage: P.<v,w> = K[] sage: P._singular_() sage: P(1) # crash
Since I neither familiar enough with the sage interface to Singular nor with Singular internals, I'm currently stuck. Could you take a look?
comment:86 Changed 5 years ago by
comment:87 Changed 5 years ago by
So far, I have no luck even building this. Did you see this before:
ImportError: …/sagereview/local/lib/python2.7/sitepackages/sage/matrix/matrix_mpolynomial_dense.so: undefined symbol: _Z17initCanonicalFormv
comment:88 followups: ↓ 89 ↓ 97 Changed 5 years ago by
So far, I have no luck even building this. Did you see this before: ImportError?: …/sagereview/local/lib/python2.7/sitepackages/sage/matrix/matrix_mpolynomial_dense.so: undefined symbol: _Z17initCanonicalFormv
Yes. These are clearly artifacts from singular 3.1.7. In Singular 4 is no 'initCanonicalForm'.
Either this is a caching issue, incorrect dependency issue(in sage/cython) or somewhere are files from 3.1.7 left. On which OS do you build singular( See also comment 55 )? Did you try 'make distclean'? ( If you have a better solution for this, please share it)
comment:89 in reply to: ↑ 88 Changed 5 years ago by
Replying to jakobkroeker:
Either this is a caching issue, incorrect dependency issue(in sage/cython) or somewhere are files from 3.1.7 left.
If it is a dependency issue (which looks the most likely), please make a new ticket for it.
comment:90 Changed 5 years ago by
Indeed, building from scratch made it go away … this will be fun to deal with eventually.
comment:91 followup: ↓ 92 Changed 5 years ago by
Hi, I have rebuild Singular + Sage extension with SAGE_DEBUG=yes and it seems trouble starts a few lines earlier in your minimal example:
sage: x = var('x') sage: K.<z> = QQ.extension(x^2 + 1) sage: P.<v,w> = K[] ***omError_WrongSize: wrong size specification of addr [677/4609] occured at: #0 at ??:0 in ?? occured for addr:0x7f7c9b303190 size:32 specified size:24 // ***dPolyReportError: memory error occured at occured for poly: z2+1 addr:0x7f7c9b303190 size:32 ***omError_WrongSize: wrong size specification of addr occured at: #0 at ??:0 in ?? occured for addr:0x7f7c9b303190 size:32 specified size:24 // ***dPolyReportError: memory error occured at occured for poly: !!longrat: NULL in monomials/p_polys.cc:3598 !!longrat: NULL in monomials/p_polys.cc:3598 oz2+oz2+... addr:0x7f7c9b303190 size:32 ***omError_WrongSize: wrong size specification of addr occured at: #0 at ??:0 in ?? occured for addr:0x7f7c9b303190 size:32 specified size:24 // ***dPolyReportError: memory error occured at occured for poly: !!longrat: NULL in monomials/p_polys.cc:3598 !!longrat: NULL in monomials/p_polys.cc:3598 oz2+oz2+... addr:0x7f7c9b303190 size:32 ***omError_WrongSize: wrong size specification of addr occured at: #0 at ??:0 in ?? occured for addr:0x7f7c9b303190 size:32 specified size:24 // ***dPolyReportError: memory error occured at occured for poly: !!longrat: NULL in monomials/p_polys.cc:3598 !!longrat: NULL in monomials/p_polys.cc:3598 oz2+oz2+... addr:0x7f7c9b303190 size:32 ***omError_WrongSize: wrong size specification of addr occured at: #0 at ??:0 in ?? occured for addr:0x7f7c9b303190 size:32 specified size:24 // ***dPolyReportError: memory error occured at occured for poly: !!longrat: NULL in monomials/p_polys.cc:3598 !!longrat: NULL in monomials/p_polys.cc:3598 oz2+oz2+... addr:0x7f7c9b303190 size:32
comment:92 in reply to: ↑ 91 Changed 4 years ago by
Replying to malb:
Hi, I have rebuild Singular + Sage extension with SAGE_DEBUG=yes and it seems trouble starts a few lines earlier in your minimal example:
sage: x = var('x') sage: K.<z> = QQ.extension(x^2 + 1) sage: P.<v,w> = K[] ***omError_WrongSize: wrong size specification of addr [...]
Do you know in detail what happens or should happen in sage for
sage: P.<v,w> = K[] sage: P(1)
behind the scenes?
With that information we could ask Singular's developers if we use libSingular
correctly.
comment:93 followup: ↓ 95 Changed 4 years ago by
It'll construct a ring for the extension and then a ring in in v, w. I'll try to investigate further what's going wrong there (sorry, I'm being slow on this)
comment:94 Changed 4 years ago by
 Commit changed from 179ecd8b461135724979671c786301e515abb00c to 7803030893acbea4a6f54c1a3ee3d08ce1d04042
Branch pushed to git repo; I updated commit sha1. New commits:
7803030  located algext issue

comment:95 in reply to: ↑ 93 Changed 4 years ago by
Replying to malb:
It'll construct a ring for the extension and then a ring in in v, w. I'll try to investigate further what's going wrong there (sorry, I'm being slow on this)
trouble starts a few lines earlier in your minimal example:
Indeed. With printouts I tracked down the issue to ring creation in
src/sage/libs/singular/ring.pyx
I guess that I incorrectly assembly the minpoly in ring construction
(omalloc magic or whatever)
Or there is an issue with the AlgExtInfo
declaration or in nInitChar()
call.
Could you take a look or even fix it?
See the corresponding Singular example test_Q_Ext_a()
in
latest/libpolys/tests/polys_test.h
comment:96 Changed 4 years ago by
 Branch changed from u/jakobkroeker/ticket.17254.squashed.new to u/jdemeyer/ticket.17254.squashed.new
comment:97 in reply to: ↑ 88 Changed 4 years ago by
 Commit changed from 7803030893acbea4a6f54c1a3ee3d08ce1d04042 to 1f7f7f10c73bee55118e2644546a6dfa08bae2bd
 Summary changed from Upgrade to Singular401 to Upgrade to Singular402
Replying to jakobkroeker:
So far, I have no luck even building this. Did you see this before: ImportError?: …/sagereview/local/lib/python2.7/sitepackages/sage/matrix/matrix_mpolynomial_dense.so: undefined symbol: _Z17initCanonicalFormv
Yes. These are clearly artifacts from singular 3.1.7. In Singular 4 is no 'initCanonicalForm'.
The problem was with the include path containing old files, this is now fixed.
New commits:
1f7f7f1  Fix Singular include path

comment:98 Changed 4 years ago by
Any progress Martin? I'll rebuild a debug version of Sage and give it a try as well in the next few days.
comment:99 Changed 4 years ago by
 Branch changed from u/jdemeyer/ticket.17254.squashed.new to u/jpflori/ticket/17254
 Commit changed from 1f7f7f10c73bee55118e2644546a6dfa08bae2bd to b39fe932f1938dadd332bd54c007d7c95a147a6e
comment:100 Changed 4 years ago by
I looked a little bit into the problem and from what I see when the multivariate gets created the first thing done is to create the number field in Singular. Just after the number field creation, the first memory error Singular complains about is related to the polynomial defining the number field, so I would say the number field creation already went wrong (or the number field is wrongly used once created).
comment:101 Changed 4 years ago by
Here is the backtrace of the first error reporting:
(gdb) bt #0 omReportError (error=omError_WrongSize, report_error=omError_NoError, r=0x3fffa170be00 <omTestBinAddrSize+68>, fmt=0x3fffa171bd80 "") at omError.c:83 #1 0x00003fffa17120b0 in omReportAddrError (error=omError_WrongSize, report_error=omError_NoError, addr=0x3fffa13001f0, bin_size=0x18, flags=262, r=0x3fffa170be00 <omTestBinAddrSize+68>, fmt=0x3fffa171bd80 "") at omDebugCheck.c:409 #2 0x00003fffa1710d5c in omDoCheckBinAddr (addr=0x3fffa13001f0, bin_size=0x18, flags=262, level=1 '\001', report=omError_NoError, r=0x3fffa170be00 <omTestBinAddrSize+68>) at omDebugCheck.c:211 #3 0x00003fffa17108b8 in omDoCheckAddr (addr=0x3fffa13001f0, bin_size=0x18, flags=262, level=1 '\001', report=omError_NoError, r=0x3fffa170be00 <omTestBinAddrSize+68>) at omDebugCheck.c:169 #4 0x00003fffa170fd2c in _omCheckAddr (addr=0x3fffa13001f0, size_bin=0x18, flags=262, check=1 '\001', report=omError_NoError, r=0x3fffa170be00 <omTestBinAddrSize+68>) at omDebugCheck.c:46 #5 0x00003fffa170cd8c in _omDebugAddr (addr=0x3fffa13001f0, bin_size=0x18, flags=258, check=1 '\001') at omDebug.c:283 #6 0x00003fffa170be00 in omTestBinAddrSize (addr=0x3fffa13001f0, size=24, check_level=1) at omDebug.c:46 #7 0x00003fffa1b64c14 in _p_Test (p=0x3fffa13001f0, r=0x3fffa13344d0, level=0) at pDebug.cc:223 #8 0x00003fffa1c1fcd0 in naInitChar (cf=0x3fffa131c9a8, infoStruct=0x3fffffff9240) at ext_fields/algext.cc:1419 #9 0x00003fffa1c5b114 in nInitChar (t=n_algExt, parameter=0x3fffffff9240) at numbers.cc:385 #10 0x00003fffa0f81758 in __pyx_f_4sage_4libs_8singular_4ring_singular_ring_new ... }
comment:102 Changed 4 years ago by
And of the second one:
(gdb) bt #0 dPolyReportError (p=0x3fffa13001f0, r=0x3fffa13344d0, fmt=0x3fffa1cb5140 "%s ") at pDebug.cc:46 #1 0x00003fffa1b64c54 in _p_Test (p=0x3fffa13001f0, r=0x3fffa13344d0, level=0) at pDebug.cc:223 #2 0x00003fffa1c1fcd0 in naInitChar (cf=0x3fffa131c9a8, infoStruct=0x3fffffff9240) at ext_fields/algext.cc:1419 #3 0x00003fffa1c5b114 in nInitChar (t=n_algExt, parameter=0x3fffffff9240) at numbers.cc:385 #4 0x00003fffa0f81758 in __pyx_f_4sage_4libs_8singular_4ring_singular_ring_new ... }
comment:103 Changed 4 years ago by
Some pointers, I have to quit now and tomorrow I'll have forgotten everything:
comment:104 Changed 4 years ago by
Got a suggestion from Hannes:
Additional issue:
 we should clean up old headers when upgrading.
comment:105 Changed 4 years ago by
The above suggestion fixes the problem.
comment:106 Changed 4 years ago by
I still get a bunch of crashes/errors when testing sage/libs/singular
, working on it.
comment:107 Changed 4 years ago by
 Commit changed from b39fe932f1938dadd332bd54c007d7c95a147a6e to bea5a27251a7be04fccb22c0032905218f13a301
Branch pushed to git repo; I updated commit sha1. New commits:
bea5a27  Correctly initialize Singular polynomials.

comment:108 Changed 4 years ago by
 Branch changed from u/jpflori/ticket/17254 to u/jakobkroeker/ticket.17254.squashed.new
 Commit changed from bea5a27251a7be04fccb22c0032905218f13a301 to e6a30ffadfd625e4baf1def440fab8f9489976bc
I still get a bunch of crashes/errors when testing sage/libs/singular, working on it.
I was able to fix the issue with naSetMap()
and nlInit2gmp()
usage in sa2si_NF()
)
and this reduces the number of segfaults significantly
The example
sage: x = var('x') sage: K.<z> = QQ.extension(x^2 + 1) sage: P.<v,w> = K[] sage: P._singular_() sage: P(2/3)
does not crash any more!
A remaining task is to reuse the plain polynomial ring qqr = QQ['x']
over Q in
sa2si_NF()
instead of rebuilding it everytime. (variable name is irrelevant)
.
.
Next interesting riddle in sa2si_ZZmod()
; simple failing example:
sage: sage: R.<a> = Zmod(5)['a', 'b'] sage: R(1) #crash
New commits:
e6a30ff  fixed issue with nMapFuncPtr usage

comment:109 Changed 4 years ago by
 Branch changed from u/jakobkroeker/ticket.17254.squashed.new to u/jpflori/ticket/17254
 Commit changed from e6a30ffadfd625e4baf1def440fab8f9489976bc to d2529486683b3bb464ec6ed3a51311084114666d
comment:110 Changed 4 years ago by
The segfault is due to a division by zero (happening in gmp which aborts I guess):
#0 0x00003fffadbeaf28 in __gmpz_mod (rem=0x3fffa03ce230, dividend=0x3fffa03ce220, divisor=0x0) at mod.c:29 #1 0x00003fffa0d1558c in nrnMapGMP (from=0x3fffa03ce220, dst=0x3fffa03bc9a8) at rmodulon.cc:766 #2 0x00003fffa0d1561c in nrnMapZ (from=0x3fffa03ce220, src=0x3fffa03bc680, dst=0x3fffa03bc9a8) at rmodulon.cc:790 #3 0x00003fffa014903c in __pyx_f_4sage_4libs_8singular_8singular_sa2si_ZZmod ( __pyx_v_d=0x3fff986212e0, __pyx_v__ring=0x3fffa03d43a8)
I guess the ring is wrongly initialized.
comment:111 Changed 4 years ago by
Note that the same thing works when 5
is replaced by anything nonprime.
And indeed during ring creation the former is caught at the beginning of the method in sage/libs/singular/ring.pyx
as field
, finite
and prime
whereas the latter is caught as integer_mod_ring
.
comment:112 Changed 4 years ago by
 Commit changed from d2529486683b3bb464ec6ed3a51311084114666d to 92304e83987a9c31b6d77de91e6264b46bfb8e21
Branch pushed to git repo; I updated commit sha1. New commits:
92304e8  Properly initial prime fields in singular.

comment:113 Changed 4 years ago by
Why does this branch change build/bin/sagespkg
???
comment:114 Changed 4 years ago by
No idea, mistake from me surely...
comment:115 Changed 4 years ago by
 Commit changed from 92304e83987a9c31b6d77de91e6264b46bfb8e21 to 97c8bb68b01a1129df50a224eb0a2deb494558ff
Branch pushed to git repo; I updated commit sha1. New commits:
97c8bb6  Revert "Properly initial prime fields in singular."

comment:116 Changed 4 years ago by
Ok the issue is indeed a mix between Zmod
and GF
.
The ring was initially created in singular as a "finite field" but then for some reason the conversion is made as for a "modular integer".
The former one uses int
s whereas the second one uses mpz
s.
comment:117 Changed 4 years ago by
I've not checked but I guess the reason is as follow:
 to create the singular ring we ask if the base ring is a prime finite field, not if it's a class derived from
FiniteField
, so classes derived fromIntegerModRing
are caught,  when sending something into the ring we follow the "classes" logic, boom.
comment:118 Changed 4 years ago by
 Commit changed from 97c8bb68b01a1129df50a224eb0a2deb494558ff to 18a6be12c9a551f71cd145a4dcc86eaa86653de4
Branch pushed to git repo; I updated commit sha1. New commits:
18a6be1  Fix for the GF vs Zmod issue with Singular.

comment:119 Changed 4 years ago by
Ok next issue:
napoly
and slnumber
do not exist anymore, seemingly since a long time...
comment:120 Changed 4 years ago by
 Commit changed from 18a6be12c9a551f71cd145a4dcc86eaa86653de4 to bf2aedeae41383316835925a3dcd70ce6edb6b93
Branch pushed to git repo; I updated commit sha1. New commits:
bf2aede  WIP to use new Singular API.

comment:121 Changed 4 years ago by
 Branch changed from u/jpflori/ticket/17254 to u/jdemeyer/ticket/17254
comment:122 Changed 4 years ago by
 Commit changed from bf2aedeae41383316835925a3dcd70ce6edb6b93 to 2ecb686790acddc33ee8a09bf1045955a6b53f45
Branch pushed to git repo; I updated commit sha1. New commits:
2ecb686  Fix several doctest failures in libs/singular

comment:123 Changed 4 years ago by
 Milestone changed from sage6.4 to sage6.10
comment:124 Changed 4 years ago by
 Commit changed from 2ecb686790acddc33ee8a09bf1045955a6b53f45 to e949c00c1f15ae70c9c8d929f9148750c031595d
Branch pushed to git repo; I updated commit sha1. New commits:
e949c00  Fix error message formatting

comment:125 Changed 4 years ago by
 Branch changed from u/jdemeyer/ticket/17254 to u/jpflori/ticket/17254
 Commit changed from e949c00c1f15ae70c9c8d929f9148750c031595d to d3566cbab7cdda4a78772aaa041055ba08885573
comment:126 Changed 4 years ago by
 Commit changed from d3566cbab7cdda4a78772aaa041055ba08885573 to 8c0275427c66b709413188b82da7845a3196e4bb
Branch pushed to git repo; I updated commit sha1. New commits:
8c02754  Use new Singular overflow limits.

comment:127 Changed 4 years ago by
 Commit changed from 8c0275427c66b709413188b82da7845a3196e4bb to cab5fc5fc3126901bb20ef18455e09ca68a8444a
Branch pushed to git repo; I updated commit sha1. New commits:
cab5fc5  groebner_norm Singular function does not exist, groebner does.

comment:128 Changed 4 years ago by
 Commit changed from cab5fc5fc3126901bb20ef18455e09ca68a8444a to 35b9919c0b21cc300fde75fee3570d4f4a6b70a3
Branch pushed to git repo; I updated commit sha1. New commits:
35b9919  Fix some order changes and normalization changes in Singular output.

comment:129 Changed 4 years ago by
 Commit changed from 35b9919c0b21cc300fde75fee3570d4f4a6b70a3 to ee62dcd20702fe1ea0f8e180497ac92091b66a94
Branch pushed to git repo; I updated commit sha1. New commits:
ee62dcd  Yet another (doubtful) different normalization (1 == 2 mod 3).

comment:130 Changed 4 years ago by
 Commit changed from ee62dcd20702fe1ea0f8e180497ac92091b66a94 to 31c98df2aeb4a4e943db65be32214fa316cf3b24
Branch pushed to git repo; I updated commit sha1. New commits:
31c98df  New uniform overflow limit for Singular exponents.

comment:131 Changed 4 years ago by
 Commit changed from 31c98df2aeb4a4e943db65be32214fa316cf3b24 to d7a3f36965dd6b12c4ae48a27556c9c18d77e923
Branch pushed to git repo; I updated commit sha1. New commits:
d7a3f36  singclap_isSqrFree was removed from Singular 4.

comment:132 Changed 4 years ago by
 Commit changed from d7a3f36965dd6b12c4ae48a27556c9c18d77e923 to b610f9d96cf75479349b5b94ce849d78a72e8002
Branch pushed to git repo; I updated commit sha1. New commits:
b610f9d  Another overflow in Singular related change.

comment:133 Changed 4 years ago by
 Branch changed from u/jpflori/ticket/17254 to u/jdemeyer/ticket/17254
comment:134 Changed 4 years ago by
 Commit changed from b610f9d96cf75479349b5b94ce849d78a72e8002 to d7fd9ba94ff7c4c160d44d72f8a6814196795330
New commits:
d7fd9ba  Better overflow check

comment:135 Changed 4 years ago by
 Branch changed from u/jdemeyer/ticket/17254 to u/jpflori/ticket/17254
 Commit changed from d7fd9ba94ff7c4c160d44d72f8a6814196795330 to a5b45a346c6796296ec86208db97c12bf96104cd
Strange way to deal with floats accuracy, see: https://groups.google.com/forum/#!topic/libsingulardevel/kj3KlcrcNo8
Now looking into the weighted degree issue.
New commits:
bf9ec9d  Change in doctest now that Integers(2)[x, y, ...] uses Singular's Zn type.

a0a71c9  Merge remotetracking branch 'trac/u/jdemeyer/ticket/17254' into singular

a5b45a3  Yet others overflow related changes.

comment:136 Changed 4 years ago by
Note for myself: the issue is that at some point r>pFDeg gets replaced from p_WTotalDegree by p_TotalDegree. Don't know why yet.
comment:137 Changed 4 years ago by
This is triggered here:
if ((r>pFDeg==p_WTotaldegree) && rOrd_is_MixedDegree_Ordering(r)) r>pFDeg = p_Totaldegree;
line 3837/8 of ring.cc
.
comment:138 Changed 4 years ago by
Made by:
Maybe the 0 in the weights makes think Singular the order is useless.
comment:139 Changed 4 years ago by
Question to upstream here:
comment:140 Changed 4 years ago by
 Commit changed from a5b45a346c6796296ec86208db97c12bf96104cd to 199169e84b29678c6dd94a8d8e2231359cc131a1
Branch pushed to git repo; I updated commit sha1. New commits:
199169e  Forgotten overflow stuff + use user defined degree.

comment:141 Changed 4 years ago by
 Commit changed from 199169e84b29678c6dd94a8d8e2231359cc131a1 to 69ea9a493840a4d0c85cf5d40339784309852ee8
Branch pushed to git repo; I updated commit sha1. New commits:
69ea9a4  Order changed in Singular output.

comment:142 followup: ↓ 143 Changed 4 years ago by
 Commit changed from 69ea9a493840a4d0c85cf5d40339784309852ee8 to 7b5bb325da3e5f7816aa93dd38c8e8bc90962e49
Branch pushed to git repo; I updated commit sha1. New commits:
7b5bb32  Use correct function for degree.

comment:143 in reply to: ↑ 142 Changed 4 years ago by
Replying to git:
Branch pushed to git repo; I updated commit sha1. New commits:
7b5bb32 Use correct function for degree.
I get the following errors for the last change:
Error compiling Cython file:  ... deg = 0 if p == NULL: return 1 if(r != currRing): rChangeCurrRing(r) if x == NULL: return r.pDeg(p,°,r) ^  sage/libs/singular/polynomial.pyx:534:15: Object of type 'ring' has no attribute 'pDeg' Error compiling Cython file:  ... deg = 0 if p == NULL: return 1 if(r != currRing): rChangeCurrRing(r) if x == NULL: return r.pDeg(p,°,r) ^  sage/libs/singular/polynomial.pyx:534:23: Cannot convert 'poly *' to Python object Error compiling Cython file:  ... deg = 0 if p == NULL: return 1 if(r != currRing): rChangeCurrRing(r) if x == NULL: return r.pDeg(p,°,r) ^  sage/libs/singular/polynomial.pyx:534:24: Cannot convert 'int *' to Python object Error compiling Cython file:  ... deg = 0 if p == NULL: return 1 if(r != currRing): rChangeCurrRing(r) if x == NULL: return r.pDeg(p,°,r) ^
comment:144 Changed 4 years ago by
Yes I guess I made a typo and forgot to push the latest commit.
comment:145 Changed 4 years ago by
Or forgot to add the function prototype.
comment:146 Changed 4 years ago by
 Commit changed from 7b5bb325da3e5f7816aa93dd38c8e8bc90962e49 to 5c3c32009985e3972b16497af058c76e57c3cef9
Branch pushed to git repo; I updated commit sha1. New commits:
5c3c320  Add declaration for Singular pDeg.

comment:147 Changed 4 years ago by
Hopefully better now although I did not test the fix.
From what I remember the next issue was a segfault when letterplace stuff elements were multiplied.
comment:148 Changed 4 years ago by
 Commit changed from 5c3c32009985e3972b16497af058c76e57c3cef9 to 2b762791944972470678f8c6b478082ed1565064
Branch pushed to git repo; I updated commit sha1. New commits:
2b76279  Correct fix for the degree in singular.

comment:149 followup: ↓ 154 Changed 4 years ago by
Problem with letterplace algebra:
sage: F.<x> = FreeAlgebra(ZZ, implementation='letterplace') sage: x**2 sage: x**2 sage: x**2
comment:150 Changed 4 years ago by
I seem to remember there was a double free.
comment:151 Changed 4 years ago by
Did you manage to build the branch and reproduce the letterplace error?
comment:152 Changed 4 years ago by
 Branch changed from u/jpflori/ticket/17254 to u/tscrim/upgrade_singular17254
 Commit changed from 2b762791944972470678f8c6b478082ed1565064 to ef0b4e053f7b5fb73c6b4ea7c9fd336f63f43699
 Milestone changed from sage6.10 to sage7.2
I rebased the branch (as best as I could), and I did get an error with letterplace:
sage: F.<x> = FreeAlgebra(ZZ, implementation='letterplace') sage: x**2 0
I am also getting a variety of failures in testing the rings/polynomial
folder, but most of them seem to be related to constructing ideals. I haven't run tests elsewhere.
New commits:
ef0b4e0  Rebase #17254 on 7.1.rc0.

comment:153 Changed 4 years ago by
 Commit changed from ef0b4e053f7b5fb73c6b4ea7c9fd336f63f43699 to dca98ec292ca4e782a9e641e61ea92d60089fd09
Branch pushed to git repo; I updated commit sha1. New commits:
dca98ec  Fixing an issue with my rebase.

comment:154 in reply to: ↑ 149 Changed 4 years ago by
Replying to jpflori:
Problem with letterplace algebra:
sage: F.<x> = FreeAlgebra(ZZ, implementation='letterplace') sage: x**2 sage: x**2 sage: x**2
when I compile the recent 'u/jpflori/ticket/17254' or 'u/tscrim/upgrade_singular17254' with SAGE_DEBUG=yes on my 32 bit fedora22
export SAGE_DEBUG=yes ./sage f singular
I get an printout from Singular:
pmLPshift: too big shift requested
the corresponding Singular source snippet is (look at 'shiftgb.cc')
if (L+sh1 > uptodeg) { #ifdef PDEBUG PrintS("pmLPshift: too big shift requested\n"); #endif return(NULL); /* violation, 2check */ }
This seems to be a bug, but the next question is, why do we get there and is this an error caused by a previous one or not.
comment:155 Changed 4 years ago by
remaining failing tests (probably not all related to Singular):
./sage t src/sage/schemes/affine/affine_rational_point.py # Killed due to abort ./sage t src/sage/schemes/affine/affine_point.py # Killed due to segmentation fault ./sage t src/sage/schemes/affine/affine_morphism.py # Killed due to segmentation fault ./sage t src/sage/schemes/generic/algebraic_scheme.py # Killed due to segmentation fault ./sage t src/sage/schemes/elliptic_curves/isogeny_small_degree.py # Killed due to abort ./sage t src/sage/libs/cremona/newforms.pyx # IOError in doctesting framework ./sage t src/sage/algebras/letterplace/free_algebra_letterplace.pyx # Bad exit: 14 ./sage t src/sage/algebras/letterplace/free_algebra_element_letterplace.pyx # Timed out (and interrupt failed) ./sage t src/sage/rings/polynomial/multi_polynomial_sequence.py # Killed due to segmentation fault ./sage t src/sage/rings/polynomial/multi_polynomial_ideal.py # Killed due to segmentation fault ./sage t src/sage/rings/polynomial/pbori.pyx # 7 doctests failed ./sage t src/sage/schemes/projective/projective_morphism.py # 9 doctests failed ./sage t src/sage/rings/polynomial/polynomial_element.pyx # 1 doctest failed ./sage t src/sage/rings/polynomial/plural.pyx # 6 doctests failed ./sage t src/sage/schemes/jacobians/abstract_jacobian.py # 1 doctest failed ./sage t src/sage/schemes/plane_curves/projective_curve.py # 1 doctest failed ./sage t src/sage/rings/polynomial/polynomial_singular_interface.py # 1 doctest failed ./sage t src/sage/rings/number_field/number_field_ideal.py # 2 doctests failed ./sage t src/sage/modular/modform_hecketriangle/abstract_space.py # 1 doctest failed ./sage t src/sage/rings/polynomial/infinite_polynomial_element.py # 4 doctests failed ./sage t src/sage/rings/finite_rings/finite_field_ext_pari.py # 1 doctest failed ./sage t src/doc/en/constructions/algebraic_geometry.rst # 1 doctest failed ./sage t src/sage/graphs/generic_graph.py # 1 doctest failed ./sage t src/sage/modular/modform_hecketriangle/graded_ring_element.py # 7 doctests failed ./sage t src/sage/rings/finite_rings/finite_field_givaro.py # 1 doctest failed ./sage t src/sage/algebras/free_algebra.py # 12 doctests failed ./sage t src/sage/rings/multi_power_series_ring_element.py # 5 doctests failed ./sage t src/sage/rings/polynomial/infinite_polynomial_ring.py # 1 doctest failed ./sage t src/sage/graphs/base/graph_backends.pyx # 4 doctests failed ./sage t src/sage/symbolic/relation.py # 7 doctests failed ./sage t src/sage/interfaces/singular.py # 5 doctests failed ./sage t src/sage/rings/quotient_ring_element.py # 1 doctest failed ./sage t src/sage/structure/element.pyx # 1 doctest failed ./sage t src/sage/schemes/product_projective/wehlerK3.py # 17 doctests failed ./sage t src/sage/categories/pushout.py # 1 doctest failed ./sage t src/sage/rings/quotient_ring.py # 12 doctests failed ./sage t src/sage/structure/sage_object.pyx # 1 doctest failed
comment:156 Changed 4 years ago by
@jpflori
when using 'r.pLDeg()' instead of 'p_Deg()' in 'singular_polynomial_deg()' (src/sage/libs/singular/polynomial.pyx)
some test from above pass, for example:
./sage t src/sage/schemes/affine/affine_point.py ./sage t src/sage/schemes/affine/affine_morphism.py ./sage t src/sage/rings/polynomial/pbori.pyx ./sage t src/sage/rings/polynomial/infinite_polynomial_element.py
especially some segfaults disappear but then probably other passing tests get broken?
Which example did you have in mind when you changed 'r.pLDeg()' to 'p_Deg()' in 'singular_polynomial_deg()' (src/sage/libs/singular/polynomial.pyx)?
Maybe we should discuss with Hans his commit in case it breaks something
https://groups.google.com/forum/#!topic/libsingulardevel/jregxlk8Mw
comment:157 Changed 4 years ago by
The plDeg
function is a Singular internal function, made for ecart, and has some restrictions regarding the ordering it can be applied to (no negative weights or things like that).
It gets constructed by Singular at initialization of the object from p_Deg
.
What we want in Sage is the "usual" degree which is p_Deg
.
Maybe the doctests were just wrong, i have no idea.
comment:158 Changed 4 years ago by
Which branch are you using? The branch on this ticket seems to have multiple conflicts with the current develop
.
comment:159 Changed 4 years ago by
The conflicts seem to be because of #20386.
comment:160 followup: ↓ 163 Changed 4 years ago by
 Branch changed from u/tscrim/upgrade_singular17254 to u/jakobkroeker/ticket.17254.squashed.latest
 Commit changed from dca98ec292ca4e782a9e641e61ea92d60089fd09 to 048e5c5bb4fa7b300933ffaa05fe936684a72ec5
fixed some more issues.
A rebase on recent develop branch was too hard for me so I squashed everything in a new commit.
@jdemeyer I had to revert some of your changes in src/module_list.py
(removing singular from include path)
because I failed to do the same for Singular 4.
comment:161 Changed 4 years ago by
actually, in my recent branch the 'upgrade.patch' file is missing. No idea how that happened, but this is a fact.
I will fix that tomorrow or on friday. At the moment I'm just too tired.
comment:162 Changed 4 years ago by
 Commit changed from 048e5c5bb4fa7b300933ffaa05fe936684a72ec5 to 3312a178e07d7441722425857096d228ab2148f9
Branch pushed to git repo; I updated commit sha1. New commits:
3312a17  upgrade.patch was not staged, staging it

comment:163 in reply to: ↑ 160 ; followup: ↓ 165 Changed 4 years ago by
Replying to jakobkroeker:
A rebase on recent develop branch was too hard for me so I squashed everything in a new commit.
@jdemeyer I had to revert some of your changes in
src/module_list.py
Both of these are quite bad. Do you want me to have a look?
comment:164 Changed 4 years ago by
 Commit changed from 3312a178e07d7441722425857096d228ab2148f9 to ff98a0b4399f1ee25be9ce17398a12f864819e5c
comment:165 in reply to: ↑ 163 Changed 4 years ago by
Replying to jdemeyer:
Replying to jakobkroeker:
A rebase on recent develop branch was too hard for me so I squashed everything in a new commit.
@jdemeyer I had to revert some of your changes in
src/module_list.py
Both of these are quite bad. Do you want me to have a look?
That would be good.
The latest u/jakobkroeker/ticket.17254.squashed.latest
(just committed with force) should have no conflicts with develop/master branch
comment:166 Changed 4 years ago by
Question : why trac shows me that trac's automerging failed?
comment:167 Changed 4 years ago by
I experience several strange doctest failures, for example:
File "src/sage/modular/modform_hecketriangle/abstract_space.py", line 379, in sage.modular.modform_hecketriangle.abstract_space.FormsSpace_abstract.one_element Failed example: MF.one_element() Expected: doctest:...: DeprecationWarning: .one_element() is deprecated. Use .one() instead. See http://trac.sagemath.org/17694 for details. 1 + O(q^5) Got: doctest:1: DeprecationWarning: .one_element() is deprecated. Use .one() instead. See http://trac.sagemath.org/17694 for details. Running doctests with ID 201605152009372e7003e6. 1 + O(q^5) *******************
any idea what is wrong here or how to fix it?
make distclean
and ccache clear
did not help
comment:168 followup: ↓ 171 Changed 4 years ago by
Is it based off develop
or master
? These are different as develop
is the (released today) 7.3.beta2, whereas master
is 7.2
.
comment:169 followup: ↓ 170 Changed 4 years ago by
I've seen some errors somewhat similar to that before. It is as if something in the doctesting output gets read with an offset to what it should. I forget exactly what I've done in the past to fix this, but I think it came from a specific type of doctest failure...
comment:170 in reply to: ↑ 169 Changed 4 years ago by
Replying to tscrim:
I've seen some errors somewhat similar to that before. It is as if something in the doctesting output gets read with an offset to what it should. I forget exactly what I've done in the past to fix this, but I think it came from a specific type of doctest failure...
are you able to reproduce some of these (falsepositive) doctest failures?
comment:171 in reply to: ↑ 168 ; followup: ↓ 172 Changed 4 years ago by
Replying to tscrim:
Is it based off
develop
ormaster
? These are different asdevelop
is the (released today) 7.3.beta2, whereasmaster
is7.2
.
Based on develop (https://github.com/sagemath/sage) on my machine it merges without conflicts with master and develop branch.
comment:172 in reply to: ↑ 171 Changed 4 years ago by
Replying to jakobkroeker:
Replying to tscrim:
Is it based off
develop
ormaster
? These are different asdevelop
is the (released today) 7.3.beta2, whereasmaster
is7.2
.Based on develop (https://github.com/sagemath/sage) on my machine it merges without conflicts with master and develop branch.
The automerging that is used on trac is not as good as what local versions of git can do.
As for comment:170, I haven't testing this branch yet.
comment:173 Changed 4 years ago by
 Branch changed from u/jakobkroeker/ticket.17254.squashed.latest to u/jdemeyer/ticket.17254.squashed.latest
comment:174 Changed 4 years ago by
 Commit changed from ff98a0b4399f1ee25be9ce17398a12f864819e5c to a80b3a0929c2d5fd93337e682ba85e4a870fd4fb
There was a merge conflict with Sage 7.3.beta2, I fixed it.
New commits:
a80b3a0  Merge tag '7.3.beta2' into t/17254/ticket.17254.squashed.latest

comment:175 Changed 4 years ago by
 Commit changed from a80b3a0929c2d5fd93337e682ba85e4a870fd4fb to e8fbe03ca40868b74694ead4a1182804b881b9de
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
e8fbe03  Upgrade to Singular4.0.2

comment:176 Changed 4 years ago by
 Commit changed from e8fbe03ca40868b74694ead4a1182804b881b9de to 5b8343bedcf79691520953721c432b5e88cbc764
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
5b8343b  Upgrade to Singular4.0.2

comment:177 followups: ↓ 179 ↓ 182 Changed 4 years ago by
I cleaned up the patch and removed some unacceptable parts. Right now it doesn't build, that still needs to be fixed.
comment:178 Changed 4 years ago by
I think it's best to discuss with upstream about the crazy #include
directory structure. It was already bad in Singular 3 and it seems to have gotten worse with Singular 4.
comment:179 in reply to: ↑ 177 Changed 4 years ago by
Replying to jdemeyer:
I cleaned up the patch and removed some unacceptable parts. Right now it doesn't build, that still needs to be fixed.
what has to be done to get it compiling?
comment:180 Changed 4 years ago by
I am working on a hack to fix the includes, hang on...
comment:181 Changed 4 years ago by
 Commit changed from 5b8343bedcf79691520953721c432b5e88cbc764 to 1426ad88ab3e8a3d72a75f952727deca44f951a7
Branch pushed to git repo; I updated commit sha1. New commits:
1426ad8  Fix singular include directories

comment:182 in reply to: ↑ 177 ; followup: ↓ 183 Changed 4 years ago by
Replying to jdemeyer:
I cleaned up the patch and removed some unacceptable parts. Right now it doesn't build, that still needs to be fixed.
Are these the unacceptable parts? (e.g in src/sage/rings/polynomial/polydict.pyx)
diff git a/src/sage/rings/polynomial/polydict.pyx b/src/sage/rings/polynomial/polydict.pyx index fd858f7..0b49f38 100644  a/src/sage/rings/polynomial/polydict.pyx +++ b/src/sage/rings/polynomial/polydict.pyx @@ 506,7 +506,7 @@ cdef class PolyDict: don't put negative signs on the generators. :: sage: Integers(2)['x,y'].gens()  (1*x, 1*y) + (x, y) We make sure that intervals are correctly represented. ::
The 1*x output stems from Singular4 and that seems the new behaviour for that ring, for whatever reasons.
same for
diff git a/src/sage/rings/multi_power_series_ring_element.py b/src/sage/rings/multi_power_series_ring_element.py index 7293a91..7b9ca6e 100644  a/src/sage/rings/multi_power_series_ring_element.py +++ b/src/sage/rings/multi_power_series_ring_element.py @@ 32,7 +32,7 @@ Power series arithmetic, tracking precision:: sage: f*=s; f s + 2*s^2 + 3*s^3 + O(s, t)^8 sage: f%2  1*s + 1*s^3 + O(1*s, 1*t)^8 + s + s^3 + O(s, t)^8 sage: (f%2).parent() Multivariate Power Series Ring in s, t over Ring of integers modulo 2 @@ 1078,7 +1078,7 @@ class MPowerSeries(PowerSeries): sage: R.<a,b,c> = PowerSeriesRing(ZZ) sage: f = a^3*b*c^2 + a^2*b^2*c^4  12*a^3*b^3*c^3 + R.O(10) sage: g = f % 2; g  1*a^3*b*c^2 + 1*a^2*b^2*c^4 + O(1*a, 1*b, 1*c)^10 + a^3*b*c^2 + a^2*b^2*c^4 + O(a, b, c)^10 sage: g in R False sage: g in R.base_extend(Zmod(2))
also floats are now put in braces, maybe because otherwise parsing the string '1.7E+30*5' in Singular would be wronng or fail? (just guessing)
so removing the following hack
 a/src/sage/rings/real_double.pyx +++ b/src/sage/rings/real_double.pyx @@ 689,21 +689,6 @@ cdef class RealDoubleElement(FieldElement): sage: RDF(10^100) 1e+100 """  if isinstance(x,basestring):  # a hack for parsing float strings beginning with braces  if len(x)>2 and x.count('(')==1 and x.count(')')==1:  try:  if (x[0] == '(' or x[1] == '(') and x[1] == ')':  if (x[0] == '' and x[1] == '(') :  x = x[2:1]  self._value =  float(x)  return  else:  x = x[1:1]  self._value = float(x)  return  except:  pass self._value = float(x) def _magma_init_(self, magma):
will result in a lot of failing doctests...
comment:183 in reply to: ↑ 182 ; followup: ↓ 186 Changed 4 years ago by
It's not because Singular prints something in a certain way that Sage has to print it that way. The correct fix is changing the way how Sage prints Singular objects then.
comment:184 followup: ↓ 185 Changed 4 years ago by
I added a fix for the include file issue.
comment:185 in reply to: ↑ 184 Changed 4 years ago by
comment:186 in reply to: ↑ 183 ; followup: ↓ 187 Changed 4 years ago by
Replying to jdemeyer:
It's not because Singular prints something in a certain way that Sage has to print it that way. The correct fix is changing the way how Sage prints Singular objects then.
At least we should understand the reasons
 for
1*x
 and for braces around floats
I do not know whether it is safe to remove the 1*
and the braces around floats.
I don't know what Sage does for example with _repr_()
, (which calls singular_polynomial_str()
which in turn calls p_String
And if it' safe, how we should do that? regexping each polynomial string on the fly?
comment:187 in reply to: ↑ 186 Changed 4 years ago by
comment:188 Changed 4 years ago by
remaining failing tests:
./sage t long src/sage/arith/misc.py # 1 doctest failed ./sage t long src/sage/modular/modform_hecketriangle/graded_ring_element.py # 7 doctests failed ./sage t long src/sage/interfaces/singular.py # 1 doctest failed ./sage t long src/sage/categories/pushout.py # 1 doctest failed ./sage t long src/sage/quivers/algebra_elements.pyx # Timed out (and interrupt failed) ./sage t long src/sage/algebras/free_algebra.py # 12 doctests failed ./sage t long src/sage/algebras/letterplace/free_algebra_letterplace.pyx # Bad exit: 14 ./sage t long src/sage/algebras/letterplace/letterplace_ideal.pyx # Killed due to abort ./sage t long src/sage/algebras/letterplace/free_algebra_element_letterplace.pyx # Killed due to segmentation fault ./sage t long src/sage/rings/quotient_ring_element.py # 1 doctest failed ./sage t long src/sage/rings/ring.pyx # Killed due to abort ./sage t long src/sage/rings/quotient_ring.py # 12 doctests failed ./sage t long src/sage/rings/multi_power_series_ring_element.py # 3 doctests failed ./sage t long src/sage/rings/polynomial/infinite_polynomial_ring.py # 1 doctest failed ./sage t long src/sage/rings/polynomial/multi_polynomial_sequence.py # Killed due to segmentation fault ./sage t long src/sage/rings/polynomial/plural.pyx # 6 doctests failed ./sage t long src/sage/rings/polynomial/multi_polynomial_libsingular.pyx # 2 doctests failed ./sage t long src/sage/rings/polynomial/polynomial_singular_interface.py # 1 doctest failed ./sage t long src/sage/rings/polynomial/symmetric_ideal.py # 12 doctests failed ./sage t long src/sage/rings/polynomial/infinite_polynomial_element.py # 4 doctests failed ./sage t long src/sage/rings/polynomial/polydict.pyx # 1 doctest failed ./sage t long src/sage/rings/polynomial/multi_polynomial_ideal.py # Killed due to segmentation fault ./sage t long src/sage/schemes/projective/projective_morphism.py # Killed due to segmentation fault ./sage t long src/sage/schemes/plane_curves/projective_curve.py # 1 doctest failed ./sage t long src/sage/schemes/affine/affine_rational_point.py # Killed due to abort ./sage t long src/sage/schemes/affine/affine_point.py # Killed due to segmentation fault ./sage t long src/sage/schemes/affine/affine_morphism.py # Killed due to segmentation fault ./sage t long src/sage/schemes/jacobians/abstract_jacobian.py # 1 doctest failed ./sage t long src/sage/schemes/generic/algebraic_scheme.py # Killed due to segmentation fault ./sage t long src/sage/schemes/elliptic_curves/isogeny_small_degree.py # Timed out (with hangup after interrupt) ./sage t long src/sage/structure/element.pyx # 1 doctest failed ./sage t long src/doc/en/constructions/algebraic_geometry.rst # 1 doctest failed
any volunteers?
comment:189 followup: ↓ 190 Changed 4 years ago by
Do you still get the letterplace segfault?
comment:190 in reply to: ↑ 189 Changed 4 years ago by
Replying to jpflori:
Do you still get the letterplace segfault?
I did not fix that one because I have no idea what FreeAlgebra? is neither I know something about letterplace implementation, so I did not even try.
comment:191 Changed 4 years ago by
 Branch changed from u/jdemeyer/ticket.17254.squashed.latest to u/jakobkroeker/ticket.17254.Jeroen_Demeyer.version
 Commit changed from 1426ad88ab3e8a3d72a75f952727deca44f951a7 to df297d6c6a4dc2955ef985bdef3646f8a7217be1
New commits:
df297d6  add meaninful messages to Singular error

remark: the patch above does not solve the issue with letterplace segfault
comment:192 Changed 4 years ago by
simplest failing example:
sage: A.<x> = AffineSpace(GF(3^2, 't'), 1) ## line 299 ## Ideal(x).weil_restriction()
comment:193 Changed 4 years ago by
added debug printouts in
u/jakobkroeker/jdemeyer_ticket.17254.latest.debug
for the example
sage: F.<x> = FreeAlgebra(ZZ, implementation='letterplace') sage: x**2
in free_algebra_element_letterplace.pyx
, __pow__()
routine
after copying the polynomial from one ring to another (with prCopyR
) something seems broken
(look at the polynomial degree!)
and for the
sage: A.<x> = AffineSpace(GF(3^2, 't'), 1) ## line 299 ## Ideal(x).weil_restriction()
after the subs()
command in the weil_restriction()
Routine something is screwed up
(look at the polynomial degree!)
@jpflori Any idea?
comment:194 Changed 4 years ago by
 Commit changed from df297d6c6a4dc2955ef985bdef3646f8a7217be1 to 88ce71f30b3d013eac38df7470679caec832f15f
Branch pushed to git repo; I updated commit sha1. New commits:
88ce71f  call rComplete for singular ring

comment:195 Changed 4 years ago by
p_Deg seems to have problems with lex ordering:
k = QQ S.<a,b>=PolynomialRing(k, 2, {"a","b"}, order='lex') a.degree() # 65536 k = QQ S.<a,b>=PolynomialRing(k, 2, {"a","b"}, order='degrevlex') a.degree() #1
comment:196 followups: ↓ 197 ↓ 199 Changed 4 years ago by
@jpflori
Singulars degree function calls pLDeg
and not p_Deg
,
(grep for 'jjDEG
' in Singular sources), so we should do the same/similar by default.
one of the reasons: p_Deg
seems returning garbage for lexicographic orderings
(see comment 195)
Question: is the behaviour described in the documentation of the 'degree' function in sage
Note that a matrix term ordering alters the grading of the generators of the ring; see the tests below. To avoid this behavior, use either ``exponents()`` for the exponents themselves, or the optional argument ``std_grading=False``.
natural and is it what a user would expect? Then we could(?) fix it using a different appropriate call:
sage: sage: tord = TermOrder(matrix([3,0,1,1,1,0,1,0,0])) sage: sage: R.<x,y,z> = PolynomialRing(QQ,'x',3,order=tord) sage: sage: (x^3*y+x*z^4).degree() # 9 ('p_Totaldegree', 4) ('p_WTotaldegree', 9) ('p_WDegree', 9) ('pFDeg', 4) ('pLDeg', 5)
comment:197 in reply to: ↑ 196 Changed 4 years ago by
Replying to jakobkroeker:
Question: is the behaviour described in the documentation of the 'degree' function in sage
Note that a matrix term ordering alters the grading of the generators of the ring; see the tests below. To avoid this behavior, use either ``exponents()`` for the exponents themselves, or the optional argument ``std_grading=False``.natural and is it what a user would expect?
I bumped into this a long time ago. It shocked me then, but I adapted & now my code depends on it. If this is true of me, it is probably true of others.
This, for example, is from Sage 6.7:
sage: T = TermOrder(matrix(3,3,[1,2,3,3,4,5,0,0,1])) sage: R.<x,y,z> = PolynomialRing(QQ,'x',3,order=T) sage: y.degree() 2 sage: version() 'SageMath Version 6.7, Release Date: 20150517'
So IMHO we should mimic Singular for compatibility reasons (i.e., we're mimicking Sage itself).
comment:198 Changed 4 years ago by
 Branch changed from u/jakobkroeker/ticket.17254.Jeroen_Demeyer.version to u/tscrim/upgrade_singular17254
 Commit changed from 88ce71f30b3d013eac38df7470679caec832f15f to 9ec51342d57b7b66aa576edca3b1810768f3a593
 Milestone changed from sage7.2 to sage7.3
Rebased on latest beta.
New commits:
9ec5134  Merge branch 'u/jakobkroeker/ticket.17254.Jeroen_Demeyer.version' of git://trac.sagemath.org/sage into u/jakobkroeker/ticket.17254.Jeroen_Demeyer.version

comment:199 in reply to: ↑ 196 ; followup: ↓ 200 Changed 4 years ago by
Replying to jakobkroeker:
Question: is the behaviour described in the documentation of the 'degree' function in sage
Note that a matrix term ordering alters the grading of the generators of the ring; see the tests below. To avoid this behavior, use either ``exponents()`` for the exponents themselves, or the optional argument ``std_grading=False``.natural and is it what a user would expect? Then we could(?) fix it using a different appropriate call:
sage: sage: tord = TermOrder(matrix([3,0,1,1,1,0,1,0,0])) sage: sage: R.<x,y,z> = PolynomialRing(QQ,'x',3,order=tord) sage: sage: (x^3*y+x*z^4).degree() # 9 ('p_Totaldegree', 4) ('p_WTotaldegree', 9) ('p_WDegree', 9) ('pFDeg', 4) ('pLDeg', 5)
As the person who introduced the matrix term ordering into Sage, I think that it was just due to the Singular behavior that a matrix term ordering changes the grading of the generators according to the first row of the matrix in Sage. It shocked everyone including John, and was regarded as a bug. So if we can make the grading and the matrix term ordering independent, switching to Singular 4, then I would be happy. Of course it should go with an appropriate deprecation warning.
comment:200 in reply to: ↑ 199 Changed 4 years ago by
comment:201 followup: ↓ 202 Changed 4 years ago by
 Cc mkoeppe added
Polymake (#20892) looks for a binary called libsingularconfig
. Is this something that will be installed by Singular 4?
comment:202 in reply to: ↑ 201 Changed 4 years ago by
comment:203 Changed 4 years ago by
This will hopefully build with GCC 6.x... (cf. #20738) :P
comment:204 Changed 4 years ago by
 Branch changed from u/tscrim/upgrade_singular17254 to u/jakobkroeker/tscrim.upgrade_singular17254
 Commit changed from 9ec51342d57b7b66aa576edca3b1810768f3a593 to 738fe43d05806edcd1e4f8c8b7dd1b086b9ca7e2
Currently I implemented singular_polynomial_deg
as follows
to mimic its behaviour as it was with Singular 3.1.7(and older)
... cdef long _deg, deg deg = 1 _deg = 1 if x == NULL: while p: _deg = p_WTotaldegree(p,r) if _deg > deg: deg = _deg p = pNext(p) return deg ...
The degreerelated tests seem to pass now.
Remakr: pDeg() seems not usable/has different behaviour; see https://groups.google.com/forum/?_escaped_fragment_=topic/libsingulardevel/dulzKFTF3g8#!topic/libsingulardevel/dulzKFTF3g8 for details.
Further changes: added some missing rComplete() calls ( otherwise prCopyR cannot be used, for instance, see https://groups.google.com/forum/?_escaped_fragment_=topic/libsingulardevel/4JRHxVXIF70#!topic/libsingulardevel/4JRHxVXIF70 )
New commits:
b1e228e  replacement for pLDeg from Singular 3 (behaviour of pLDeg changed in Singular 4)

a511817  added missing rComplete calls

738fe43  disable short output for Singular

comment:205 Changed 4 years ago by
only few issues are left;
who will fix the next one? that should be easy!
./sage t long src/sage/arith/misc.py # 1 doctest failed ./sage t long src/sage/modular/modform_hecketriangle/graded_ring_element.py # 7 doctests failed ./sage t long src/sage/quivers/algebra_elements.pyx # Timed out (and interrupt failed) ./sage t long src/sage/algebras/letterplace/free_algebra_letterplace.pyx # Killed due to segmentation fault ./sage t long src/sage/algebras/letterplace/letterplace_ideal.pyx # Killed due to abort ./sage t long src/sage/algebras/letterplace/free_algebra_element_letterplace.pyx # Timed out (and interrupt failed) ./sage t long src/sage/rings/ring.pyx # Killed due to abort ./sage t long src/sage/rings/multi_power_series_ring_element.py # 2 doctests failed ./sage t long src/sage/rings/polynomial/multi_polynomial_libsingular.pyx # 2 doctests failed ./sage t long src/sage/rings/polynomial/polynomial_singular_interface.py # 1 doctest failed ./sage t long src/sage/rings/polynomial/polydict.pyx # 1 doctest failed ./sage t long src/sage/rings/polynomial/multi_polynomial_ideal.py # 1 doctest failed ./sage t long src/sage/schemes/projective/projective_morphism.py # Timed out (with hangup after interrupt) ./sage t long src/sage/schemes/affine/affine_rational_point.py # Killed due to abort ./sage t long src/sage/schemes/jacobians/abstract_jacobian.py # 1 doctest failed ./sage t long src/sage/schemes/elliptic_curves/isogeny_small_degree.py # Killed due to segmentation fault ./sage t long src/sage/structure/element.pyx # 1 doctest failed ./sage t long src/doc/en/constructions/algebraic_geometry.rst # 1 doctest failed
comment:206 Changed 4 years ago by
 Commit changed from 738fe43d05806edcd1e4f8c8b7dd1b086b9ca7e2 to ac8e614777f6e5e49149f6227d40ba1cc71585c9
comment:207 followup: ↓ 208 Changed 4 years ago by
Failing of
sage: F.<x> = FreeAlgebra(ZZ, implementation='letterplace') sage: x**2
is caused by an upstream bug; (reported: https://www.singular.unikl.de:8005/trac/ticket/767#ticket)
Letterplace over fields should work (please check)
comment:208 in reply to: ↑ 207 Changed 4 years ago by
Replying to jakobkroeker:
Failing of
sage: F.<x> = FreeAlgebra(ZZ, implementation='letterplace') sage: x**2is caused by an upstream bug; (reported: https://www.singular.unikl.de:8005/trac/ticket/767#ticket)
Letterplace over fields should work (please check)
Thanks for devising this!
comment:209 Changed 4 years ago by
the upsream issue
pathed in http://git.sagemath.org/sage.git/commit/?id=ac8e614777f6e5e49149f6227d40ba1cc71585c9 (upgrade.patch)
is now reported on upstream with a pull request:
comment:210 Changed 4 years ago by
could someone please look what goes wrong with
./sage t long src/sage/modular/modform_hecketriangle/graded_ring_element.py
?
comment:211 Changed 4 years ago by
 Branch changed from u/jakobkroeker/tscrim.upgrade_singular17254 to public/singular4
 Commit changed from ac8e614777f6e5e49149f6227d40ba1cc71585c9 to 7e99c41f6a6332cf01d73abb9841020ecc67a356
 Description modified (diff)
 Summary changed from Upgrade to Singular402 to Upgrade to Singular4.x.x
I've removed a bunch of very old hackish stuff in spkginstall
, especially regarding Solaris and sparc.
Maybe too much, but the Singular build system changed so much and it does not seem we have real support for such systems anymore that we should only reintroduce removed hacks if found that are still needed.
It also seems this upgrade to git version rebroke some stuff...
New commits:
637b2b7  Merge remotetracking branch 'trac/u/jakobkroeker/tscrim.upgrade_singular17254' into singular

be4f5e7  Update Singular to 4.0.3p1.

5b98496  Let's play with singular git version.

3a5baec  Work with Singular git version.

7e99c41  Use Singular git version.

comment:212 Changed 4 years ago by
In particular, in function.pyx
, in __init__
after calling
if currRingHdl == NULL: currRingHdl = ggetid("my_awesome_sage_ring") if currRingHdl == NULL: currRingHdl = enterid("my_awesome_sage_ring", 0, RING_CMD, &IDROOT, 1) currRingHdl.data.uring.ref += 1
the last line segfaults because:
(gdb) print currRingHdl.data $2 = { i = 0, uring = 0x0, p = 0x0, n = 0x0, uideal = 0x0, umap = 0x0, umatrix = 0x0, ustring = 0x0, iv = 0x0, bim = 0x0, l = 0x0, li = 0x0, pack = 0x0, pinf = 0x0 }
I guess some additional funciton should be used to initialize properly currRingHdl
.
comment:213 Changed 4 years ago by
The culprit might be https://github.com/Singular/Sources/commit/595145c77dbdb42114960862678d5ca6351578be
comment:214 Changed 4 years ago by
So everyone's always using the latest git version in spkgsrc
?
FWIW, sed i
isn't portable, e.g. won't work on Oraclis.
SPKG.txt
now says "Patches: None" whereas there is upgrade.patch
.
comment:215 followup: ↓ 217 Changed 4 years ago by
That's just work in progress... This upgrade is hell.
comment:216 Changed 4 years ago by
 Commit changed from 7e99c41f6a6332cf01d73abb9841020ecc67a356 to 4a85552db111bb7dae27a61b7e46cf9943673ce6
Branch pushed to git repo; I updated commit sha1. New commits:
4a85552  enterid does not initialize underlying ring anymore, fix for function.pyx.

comment:217 in reply to: ↑ 215 ; followup: ↓ 220 Changed 4 years ago by
Replying to jpflori:
That's just work in progress... This upgrade is hell.
Sure. So you'll (by default) check out a specific commit once you know which one is suited best?
comment:218 followup: ↓ 221 Changed 4 years ago by
Just for the record:
make_tar.sh
checks out HEAD
, and calls autogen.sh
(without checking for errors) which in turn runs (some random version of) autoreconf
.
comment:219 Changed 4 years ago by
FYI, explanation for the removal and readdition of nlDelete
:
https://groups.google.com/d/msg/libsingulardevel/EtEblVqdV3I/CyJJ5jaJCAAJ
comment:220 in reply to: ↑ 217 ; followup: ↓ 222 Changed 4 years ago by
Replying to leif:
Replying to jpflori:
That's just work in progress... This upgrade is hell.
Sure. So you'll (by default) check out a specific commit once you know which one is suited best?
Sure! Hopefully it should be 4.1 upstream version though I don't know when it's planned. 4.0.3p1 seems to be a poorer choice as a bunch of bugs reported here where fixed in Singular after that release and the fixes would have to be backported...
comment:221 in reply to: ↑ 218 ; followup: ↓ 223 Changed 4 years ago by
Replying to leif:
Just for the record:
make_tar.sh
checks outHEAD
, and callsautogen.sh
(without checking for errors) which in turn runs (some random version of)autoreconf
.
Yes and tries to copy some files from the person who wrote the script :)
comment:222 in reply to: ↑ 220 Changed 4 years ago by
Replying to jpflori:
Replying to leif:
So you'll (by default) check out a specific commit once you know which one is suited best?
Sure! Hopefully it should be 4.1 upstream version though I don't know when it's planned.
I was just about to ask you that, as there are many recent commits mentioning 4.1.
I'll probably add something to spkgsrc
regarding checkout and autogen.sh
/ make_tar.sh
unless you're going to as well.
comment:223 in reply to: ↑ 221 ; followup: ↓ 226 Changed 4 years ago by
Replying to jpflori:
Replying to leif:
make_tar.sh
checks outHEAD
, and callsautogen.sh
(without checking for errors) which in turn runs (some random version of)autoreconf
.Yes and tries to copy some files from the person who wrote the script :)
I just stumbled upon
cp /tmp/wawai/share/singular/LIB/all.lib singular$VERSION/Singular/LIB/.
Did you mean that, or is there more?
comment:224 followup: ↓ 227 Changed 4 years ago by
After all, it's spielwiese
(~= playground).
Is the repo on GitHub their "master" one, or do they (occasionally) just sync from elsewhere?
comment:225 Changed 4 years ago by
 Commit changed from 4a85552db111bb7dae27a61b7e46cf9943673ce6 to d0c7069423e49673bd3ea4a722f8da34af56b38d
Branch pushed to git repo; I updated commit sha1. New commits:
d0c7069  Update singular git version.

comment:226 in reply to: ↑ 223 Changed 4 years ago by
Replying to leif:
Replying to jpflori:
Replying to leif:
make_tar.sh
checks outHEAD
, and callsautogen.sh
(without checking for errors) which in turn runs (some random version of)autoreconf
.Yes and tries to copy some files from the person who wrote the script :)
I just stumbled upon
cp /tmp/wawai/share/singular/LIB/all.lib singular$VERSION/Singular/LIB/.
Did you mean that, or is there more?
There is also a nonexisting fedora (IIRC) file.
comment:227 in reply to: ↑ 224 Changed 4 years ago by
Replying to leif:
After all, it's
spielwiese
(~= playground).Is the repo on GitHub their "master" one, or do they (occasionally) just sync from elsewhere?
I would say the spielwiese
branch on github is the real master one.
As you can see, the following commit:
https://github.com/Singular/Sources/commit/b412eebf8435fb44680b5160c7f8d524cdb20b2b
just followed my post on libsingulardevel:
https://groups.google.com/forum/#!topic/libsingulardevel/EtEblVqdV3I
comment:228 Changed 4 years ago by
Things seem good. A ptest yeilds:
sage t warnlong 121.7 src/doc/en/prep/Advanced2DPlotting.rst # Killed due to segmentation fault sage t warnlong 121.7 src/sage/calculus/riemann.pyx # Timed out (and interr upt failed) sage t warnlong 121.7 src/sage/schemes/elliptic_curves/isogeny_small_degree. py # Killed due to segmentation fault sage t warnlong 121.7 src/sage/schemes/elliptic_curves/ell_number_field.py # Timed out sage t warnlong 121.7 src/sage/libs/gap/all_documented_functions.py # Timed out sage t warnlong 121.7 src/sage/plot/plot.py # Timed out sage t warnlong 121.7 src/sage/libs/gap/assigned_names.py # Timed out sage t warnlong 121.7 src/sage/finance/time_series.pyx # Timed out sage t warnlong 121.7 src/sage/plot/plot3d/implicit_plot3d.py # Timed out sage t warnlong 121.7 src/sage/plot/plot3d/parametric_plot3d.py # Timed out sage t warnlong 121.7 src/sage/plot/plot3d/plot3d.py # Timed out sage t warnlong 121.7 src/sage/plot/graphics.py # Timed out sage t warnlong 121.7 src/sage/plot/plot3d/base.pyx # Timed out sage t warnlong 121.7 src/doc/en/prep/Calculus.rst # Killed due to segmentation fault sage t warnlong 121.7 src/sage/modular/local_comp/type_space.py # Timed out sage t warnlong 121.7 src/sage/modular/modform_hecketriangle/graded_ring_element.py # 7 doctests failed sage t warnlong 121.7 src/sage/schemes/projective/projective_morphism.py # 4 doctests failed sage t warnlong 121.7 src/sage/misc/randstate.pyx # 1 doctest failed sage t warnlong 121.7 src/sage/arith/misc.py # 1 doctest failed sage t warnlong 121.7 src/sage/structure/element.pyx # 1 doctest failed sage t warnlong 121.7 src/sage/doctest/test.py # Timed out sage t warnlong 121.7 src/sage/tests/french_book/mpoly.py # 1 doctest failed sage t warnlong 121.7 src/sage/rings/polynomial/multi_polynomial_ideal.py # 4 doctests failed sage t warnlong 121.7 src/sage/homology/simplicial_complex.py # 1 doctest failed sage t warnlong 121.7 src/sage/plot/misc.py # 1 doctest failed sage t warnlong 121.7 src/sage/interfaces/singular.py # 3 doctests failed sage t warnlong 121.7 src/sage/rings/polynomial/multi_polynomial_libsingular.pyx # 4 doctests failedsage t warnlong 121.7 src/sage/schemes/affine/affine_rational_point.py # Killed due to abort sage t warnlong 121.7 src/sage/libs/singular/function.pyx # 6 doctests failed sage t warnlong 121.7 src/sage/rings/multi_power_series_ring_element.py # 2 doctests failed sage t warnlong 121.7 src/sage/rings/polynomial/polynomial_singular_interface.py # 3 doctests failed sage t warnlong 121.7 src/sage/rings/polynomial/multi_polynomial_ideal_libsingular.pyx # 1 doctest failed sage t warnlong 121.7 src/sage/schemes/jacobians/abstract_jacobian.py # 1 doctest failed sage t warnlong 121.7 src/sage/rings/polynomial/polydict.pyx # 1 doctest failed 
I assume many of them are unrelated to Singular, and due to the POWER7 arch, especially the plots ones.
comment:229 Changed 4 years ago by
The singular related ones seem to be:
 schemes/elliptic_curves/isogeny_small_degree.py: segfault.
 modular/modform_hecketriangle/graded_ring_element.py: lots of singular stuff, including coercion.
 schemes/projective/projective_morphism.py: not sure... something about mpfr!
 arith/misc.py: representation of finite fields changed, easy to fix.
 structure/element.pyx: new limitation in max exponent?
 tests/french_book/mpoly.py: different result, might be just as good as the previous one.
 rings/polynomial/multi_polynomial_ideal.py: some different results, surely just as good and even better
 interfaces/singular.py: different Singular printing.
 rings/polynomial/multi_polynomial_libsingular.pyx: printing and squarefree stuff.
 schemes/affine/affine_rational_point.py: bad abort.
 src/sage/libs/singular/function.pyx: hopefully mostly random values changed in internal singular functions.
 rings/multi_power_series_ring_element.py: printing of power series changed.
 rings/polynomial/polynomial_singular_interface.py: printing changed.
 rings/polynomial/multi_polynomial_ideal_libsingular.pyx: different result, might be just as good.
 schemes/jacobians/abstract_jacobian.py: coercion error?
 rings/polynomial/polydict.pyx: printing of polys changed (x > 1*x).
comment:230 Changed 4 years ago by
Automake complains about LIBTOOL
not being defined although libtool is used.
And finally I'm getting: curl: command not found
... :)
comment:231 Changed 4 years ago by
Thread for the "1*" issue: https://groups.google.com/forum/#!topic/libsingulardevel/X29H_bv94
comment:232 Changed 4 years ago by
 Commit changed from d0c7069423e49673bd3ea4a722f8da34af56b38d to 9e14834568de9126fde80fff73f400ea93965fda
comment:233 Changed 4 years ago by
 Commit changed from 9e14834568de9126fde80fff73f400ea93965fda to 62735be27fa6ac2517463e24795a1d84d34922f8
Branch pushed to git repo; I updated commit sha1. New commits:
62735be  Let's use Singular finite field struct for finite rings of prime char.

comment:234 Changed 4 years ago by
As a sidenote, if we really want to stick to a finite ring structure rather than a finite field structure for Z/2Z and Z/pZ, we could do so. Hans fixed the "1*" disturbing behavior.
comment:235 Changed 4 years ago by
 Commit changed from 62735be27fa6ac2517463e24795a1d84d34922f8 to cc921ec4cc64b04c70bd6571fd54749446bd1d89
Branch pushed to git repo; I updated commit sha1. New commits:
2d84044  In Singular 4 limit for exponents is the same on 32 and 64 bit.

75efae0  Let's stick with integer mod ring in Singular at the moment.

919165a  Integer mod ring printing is not centered anymore in Singular.

ace4d54  Spurious dot.

cc921ec  Singular printing changes.

comment:236 Changed 4 years ago by
 Commit changed from cc921ec4cc64b04c70bd6571fd54749446bd1d89 to 6c88bc303df3aa5ecc0437e414e742b4c0fae7c5
comment:237 followup: ↓ 238 Changed 4 years ago by
 Cc vbraun added
For the segfault in schemes/elliptic_curves/isogeny_small_degree.py
it seems that the following commit now triggers a double free or invalid free (use MALLOC_CHECK_=3 or it will just fails somewhere else randomly):
@Volker: could you have a look?
comment:238 in reply to: ↑ 237 Changed 4 years ago by
Replying to jpflori:
For the segfault in
schemes/elliptic_curves/isogeny_small_degree.py
it seems that the following commit now triggers a double free or invalid free (use MALLOC_CHECK_=3 or it will just fails somewhere else randomly):
Kind of painfuly got it:
 nlNormalize(x) can free whatever is in x and change x from a struct to a disqguised int.
 when calling sa2si on a polynomial we call nlGetDenom or such functions on pointers returned by p_GetCoeff for the coeffs, which in turn call nlNormalize and free the underlying memory and modify our pointer, but not the original pointers in the polynomial
 we call p_Delete on the polynomial which call nlDelete on the coeff which gives no indication the underlying memory is freed
 bang
comment:239 Changed 4 years ago by
The solution would be something like calling p_SetCoeff whenever we call p_GetCoeff to be sure any hackish modification gets transmitted back to the original place.
comment:240 Changed 4 years ago by
 Commit changed from 6c88bc303df3aa5ecc0437e414e742b4c0fae7c5 to 20e0b22fda544da53b11d64b99da703b454bdd3e
comment:241 Changed 4 years ago by
 Commit changed from 20e0b22fda544da53b11d64b99da703b454bdd3e to 765b60a6a82cbe5a554778c2ca9981dc634f6373
comment:242 Changed 4 years ago by
 Commit changed from 765b60a6a82cbe5a554778c2ca9981dc634f6373 to e9b79db3dae782d97be4b8ac59c80dd74ed2d5dd
Branch pushed to git repo; I updated commit sha1. New commits:
e9b79db  Remove hack for singular 1*.

comment:243 Changed 4 years ago by
 Commit changed from e9b79db3dae782d97be4b8ac59c80dd74ed2d5dd to 21cf2a536cbdc604beec1cfb86354631b40a6f93
Branch pushed to git repo; I updated commit sha1. New commits:
21cf2a5  Hack to parse Singular polys with real coefficients.

comment:244 Changed 4 years ago by
Here is the current state of affairs for make testlong
on a POWER7/
sage t long src/sage/misc/randstate.pyx # 1 doctest failed sage t long src/sage/symbolic/function.pyx # 1 doctest failed sage t long src/sage/modular/modform_hecketriangle/graded_ring_element.py # 7 doctests failed sage t long src/sage/calculus/riemann.pyx # 2 doctests failed sage t long src/sage/schemes/projective/projective_morphism.py # Timed out sage t long src/sage/schemes/jacobians/abstract_jacobian.py # 1 doctest failed sage t long src/sage/schemes/curves/projective_curve.py # 2 doctests failed sage t long src/sage/schemes/curves/affine_curve.py # 1 doctest failed sage t long src/sage/rings/polynomial/multi_polynomial_ideal.py # 2 doctests failed sage t long src/sage/finance/time_series.pyx # 6 doctests failed sage t long src/sage/plot/graphics.py # 1 doctest failed sage t long src/sage/plot/contour_plot.py # Killed due to segmentation fault sage t long src/sage/plot/misc.py # 1 doctest failed sage t long src/sage/plot/plot.py # 1 doctest failed sage t long src/sage/plot/matrix_plot.py # Killed due to segmentation fault sage t long src/sage/tests/french_book/mpoly.py # 2 doctests failed sage t long src/sage/libs/singular/function.pyx # 6 doctests failed sage t long src/doc/en/prep/Advanced2DPlotting.rst # Killed due to segmentation fault sage t long src/doc/en/constructions/algebraic_geometry.rst # 14 doctests failed
comment:245 Changed 4 years ago by
misc/randstate.pyx # 1 doctest failed: unrelated, gap random different symbolic/function.pyx # 1 doctest failed: unrelated, precision issue modular/modform_hecketriangle/graded_ring_element.py # 7 doctests failed: singular, real coeffs printing with parenthesis calculus/riemann.pyx # 2 doctests failed: unrelated, precision issue schemes/projective/projective_morphism.py # Timed out: singular, real parsing schemes/jacobians/abstract_jacobian.py # 1 doctest failed: singular, real parsing schemes/curves/projective_curve.py # 2 doctests failed: singular, real parsing schemes/curves/affine_curve.py # 1 doctest failed: singular, different result rings/polynomial/multi_polynomial_ideal.py # 2 doctests failed: singular, gwalk and skipping text issue finance/time_series.pyx # 6 doctests failed: unrelated, precision issue plot/graphics.py # 1 doctest failed: unrelated, div by 0 plot/contour_plot.py # Killed due to segmentation fault: passed the second time plot/misc.py # 1 doctest failed: unrelated, div by 0 plot/plot.py # 1 doctest failed: unrelated, div by 0 plot/matrix_plot.py # Killed due to segmentation fault: passed the second time tests/french_book/mpoly.py # 2 doctests failed: singular, gwalk and skipping text issue libs/singular/function.pyx # 6 doctests failed: singular, arity code changes and skipping text issue
en/prep/Advanced2DPlotting.rst # Killed due to segmentation fault: passed the second time en/constructions/algebraic_geometry.rst # 14 doctests failed: singular, stuff in brnoeth.lib, undefined stuff
comment:246 Changed 4 years ago by
 Commit changed from 21cf2a536cbdc604beec1cfb86354631b40a6f93 to c6eaaf4d4549220c814945c7dacb82d8a980ce6d
comment:247 Changed 4 years ago by
 Commit changed from c6eaaf4d4549220c814945c7dacb82d8a980ce6d to 019204823624ca730576d6144336337e45e26de6
Branch pushed to git repo; I updated commit sha1. New commits:
0192048  Update "arity code" constants for Singular 4.

comment:248 Changed 4 years ago by
So we're hopefully left with:
 bug in mprimedec.lib (https://groups.google.com/forum/#!topic/libsingulardevel/94d9c574uvg)
 bug in brnoeth.lib (https://groups.google.com/forum/#!topic/libsingulardevel/DxjhbYqVfFQ)
 gwalk issue
 the "skipping text in
parameter
" output (when doing GB computations?)
comment:249 Changed 4 years ago by
The grwalk thing must be:
comment:250 Changed 4 years ago by
In fact the grwalk and brnoeth issues were caused by old lib
files in local/share/singular
.
Already fixed upstream.
comment:251 Changed 4 years ago by
 Commit changed from 019204823624ca730576d6144336337e45e26de6 to 526f0a2e93f12d5782a7202de3b2469e2ee9d53c
Branch pushed to git repo; I updated commit sha1. New commits:
526f0a2  Make sure old Singular lib files are deleted.

comment:252 Changed 4 years ago by
We're almost good now:
 the "skipping text from
parameter
" text only appears when an error previously happened in Singular, so we it now only appears when testinglibs/singular/function.pyx
becasuse of theGTZmod
error.  hopefully the
GTZmod
error will be fixed upstream soon and we can fix a commit to incule here (which should be more or less official Singular4.0.3
).
Can someone else please test the current branch?
You'll need to build your own tarball first using spkgsrc
.
(There will still be some polishing to do about the Singular C++ function we use, see the comments Hans added in some header files, but that can wait for another ticket.)
comment:253 Changed 4 years ago by
Oh crap, we should also reenable the possibility of debug builds. IIRC this was removed at some point in this ticket.
comment:254 Changed 4 years ago by
But that can wait for another ticket as well (at least the replace omalloc by malloc stuff).
comment:255 Changed 4 years ago by
 Commit changed from 526f0a2e93f12d5782a7202de3b2469e2ee9d53c to dcd4e1454c917f8cd9a89c59a77421a08d798868
Branch pushed to git repo; I updated commit sha1. New commits:
dcd4e14  More changes for Singular 4.

comment:256 Changed 4 years ago by
 Commit changed from dcd4e1454c917f8cd9a89c59a77421a08d798868 to 7366fb629a1aec7fc6e7167784406657baa8e9f0
Branch pushed to git repo; I updated commit sha1. New commits:
7366fb6  Better script to package singular tarball.

comment:257 Changed 4 years ago by
 Commit changed from 7366fb629a1aec7fc6e7167784406657baa8e9f0 to 9f016ae48d72d9dd51e90e36fbaabcf247bf3b58
Branch pushed to git repo; I updated commit sha1. New commits:
9f016ae  Apply patches to singular before debug hacks.

comment:258 Changed 4 years ago by
 Commit changed from 9f016ae48d72d9dd51e90e36fbaabcf247bf3b58 to cfe9a9cb6abba2030372c982b2cf2d7fb3a1b854
Branch pushed to git repo; I updated commit sha1. New commits:
cfe9a9c  Patch for Singular xalloc.

comment:259 Changed 4 years ago by
 Description modified (diff)
 Status changed from new to needs_review
Setting SAGE_DEBUG=yes
, debug mode with xalloc
should be ok although:
 I did not wait for the build to finish,
 it seems auto* wants to reconfigure everything,
 you get a alot of unsued stuff warnings but that's surely normal.
I removed a bunch of hacks from spkginstall
.
Please test!
comment:260 Changed 4 years ago by
 Cc nthiery added
comment:261 Changed 4 years ago by
 Commit changed from cfe9a9cb6abba2030372c982b2cf2d7fb3a1b854 to 7dd92be65babe002f265b9e3cd24e6493d8d0cd5
Branch pushed to git repo; I updated commit sha1. New commits:
7dd92be  Fix singular debug build mode.

comment:262 Changed 4 years ago by
the branch does not merge cleanly (so I had to do some manual editing), and after building singular I get
[sagelib7.4.beta1] ************************************************************************ [sagelib7.4.beta1] Traceback (most recent call last): [sagelib7.4.beta1] File "setup.py", line 47, in <module> [sagelib7.4.beta1] from module_list import ext_modules, library_order, aliases [sagelib7.4.beta1] File "/home/dima/software/sage/src/module_list.py", line 1587, in <module> [sagelib7.4.beta1] extra_compile_args = givaro_extra_compile_args), [sagelib7.4.beta1] NameError: name 'givaro_extra_compile_args' is not defined [sagelib7.4.beta1] ************************************************************************ [sagelib7.4.beta1] Error building the Sage library
although this might be due to me trying to merge this into the branch on #17635 (which should probably become a dependency here)
comment:263 followup: ↓ 265 Changed 4 years ago by
It built okay for me on my Ubunutu 16.04 LTS system.
Also, I think we should set a fixed tarball and checksum. Do you want me to do this?
comment:264 Changed 4 years ago by
 Dependencies set to #17635
 Status changed from needs_review to needs_work
The upgrade of givaro on #17635 has to be taken into account here.
comment:265 in reply to: ↑ 263 ; followup: ↓ 266 Changed 4 years ago by
Replying to tscrim:
Also, I think we should set a fixed tarball and checksum. Do you want me to do this?
I don't follow the ticket very closely, but that makes me jump: what about taking an upstream tarball instead of hacking something?
comment:266 in reply to: ↑ 265 Changed 4 years ago by
Replying to Snark:
Replying to tscrim:
Also, I think we should set a fixed tarball and checksum. Do you want me to do this?
I don't follow the ticket very closely, but that makes me jump: what about taking an upstream tarball instead of hacking something?
WIP / moving target:
commit 117ae9c7dde9eb9fcaa4cb899cfb7690addd6dfe Author: Hans Schoenemann <hannes@mathematik.unikl.de> Date: Fri Aug 26 18:47:06 2016 +0200 opt: prefer unsigned over int in for loops commit f5e732af7572071c189ad8185ce830f96ababa46 Author: Hans Schoenemann <hannes@mathematik.unikl.de> Date: Fri Aug 26 18:46:40 2016 +0200 compiler warnings commit 6e28802f29d0fee351ccab022adc6853e46bd3fe Author: Hans Schoenemann <hannes@mathematik.unikl.de> Date: Wed Aug 24 17:18:54 2016 +0200 opt: use id_Delete in syz1.cc commit 84963dfd52839fd9d4215c5d5b0534e80417dfad Author: Hans Schoenemann <hannes@mathematik.unikl.de> Date: Wed Aug 24 16:42:29 2016 +0200 opt: NULL in syResolvente>*res commit 495258ce8ff8e5b1376e6c7fa8ae2815387e8b4a Author: Hans Schoenemann <hannes@mathematik.unikl.de> Date: Mon Aug 22 16:04:20 2016 +0200 removed wrong warning (see Tst/Plural/docmoduleops.tst) commit 32e84f5b8f065a8070d982ae939de64e4721beab Author: Hans Schoenemann <hannes@mathematik.unikl.de> Date: Mon Aug 22 16:03:02 2016 +0200 removed AlgDepqso3dp.tst from Plural/short.lst: also in Plural.lst commit a070b84d59be835a2946d1386edd3221d80f3fe7 Author: Hans Schoenemann <hannes@mathematik.unikl.de> Date: Fri Aug 19 16:56:16 2016 +0200 Singular 4.0.3p3 commit 961c76da92efc86885b6506c8c83262f14e705ff Author: Hans Schoenemann <hannes@mathematik.unikl.de> Date: Fri Aug 19 16:34:25 2016 +0200 chg: n_IsMOne for Z/2: maybe n_Zp, n_Zn, n_Z2m ...
comment:267 followup: ↓ 284 Changed 4 years ago by
Minor thing: All error messages in spkginstall
should start with "Error
[:
] ..."
.
spkgsrc
could be beautified a bit as well (e.g. not unconditionally deleting singular.git
, and recording what we checked out, error checking), besides that curl
is nonstandard... ;)
comment:268 Changed 4 years ago by
P.S.: I'd prefer to not use lSingular
, but create a symlink from lower to uppercase instead.
comment:269 followup: ↓ 271 Changed 4 years ago by
aclocal is currently a dependency, probably due to warnings treated as errors:
[singular4.0.3p3] config.status: executing libtool commands [singular4.0.3p3] ### Singular spkginstall: build_singular ### [singular4.0.3p3] make[3]: Entering directory '/home/dima/Sage/sage/local/var/tmp/sage/build/singular4.0.3p3/src/latest' [singular4.0.3p3] CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/dima/Sage/sage/local/var/tmp/sage/build/singular4.0.3p3/src/latest/buildaux/missing aclocal1.14 I m4 [singular4.0.3p3] /home/dima/Sage/sage/local/var/tmp/sage/build/singular4.0.3p3/src/latest/buildaux/missing: line 81: aclocal1.14: command not found [singular4.0.3p3] WARNING: 'aclocal1.14' is missing on your system. [singular4.0.3p3] You should only need it if you modified 'acinclude.m4' or [singular4.0.3p3] 'configure.ac' or m4 files included by 'configure.ac'. [singular4.0.3p3] The 'aclocal' program is part of the GNU Automake package: [singular4.0.3p3] <http://www.gnu.org/software/automake> [singular4.0.3p3] It also requires GNU Autoconf, GNU m4 and Perl in order to run: [singular4.0.3p3] <http://www.gnu.org/software/autoconf> [singular4.0.3p3] <http://www.gnu.org/software/m4/> [singular4.0.3p3] <http://www.perl.org/> [singular4.0.3p3] make[3]: *** [Makefile:485: aclocal.m4] Error 127 [singular4.0.3p3] make[3]: Leaving directory '/home/dima/Sage/sage/local/var/tmp/sage/build/singular4.0.3p3/src/latest' [singular4.0.3p3] [singular4.0.3p3] real 0m28.318s [singular4.0.3p3] user 0m13.437s [singular4.0.3p3] sys 0m4.493s [singular4.0.3p3] ************************************************************************ [singular4.0.3p3] Error installing package singular4.0.3p3 [singular4.0.3p3] ************************************************************************
only caught this as I'm setting up a new laptop :)
comment:270 Changed 4 years ago by
I have aclocal1.15, but it insists on 1.14; weird, no?
comment:271 in reply to: ↑ 269 ; followups: ↓ 272 ↓ 273 Changed 4 years ago by
Replying to dimpase:
aclocal is currently a dependency
This should be fixed by running the necessary autotools in spkgsrc
.
comment:272 in reply to: ↑ 271 Changed 4 years ago by
comment:273 in reply to: ↑ 271 Changed 4 years ago by
Replying to jdemeyer:
Replying to dimpase:
aclocal is currently a dependency
This should be fixed by running the necessary autotools in
spkgsrc
.
I did make the tarball using spkgsrc
, as described.
I guess it's an upstream bug: they don't detect presence of aclocal1.14, even though they don't need it, and bail out, even though it's meant to be a warning.
Any, why 1.14
only? Won't they be happy with 1.14
or newer?
comment:274 Changed 4 years ago by
 Branch changed from public/singular4 to u/dimpase/singular4
 Commit changed from 7dd92be65babe002f265b9e3cd24e6493d8d0cd5 to 457bd233fc051f4ec6f8acf48dbf271af6d5bb46
 Status changed from needs_work to needs_review
modulo the following, ptestlong
passes with the new branch
sage t long warnlong 77.2 src/sage/schemes/curves/affine_curve.py ********************************************************************** File "src/sage/schemes/curves/affine_curve.py", line 494, in sage.schemes.curves.affine_curve.AffineCurve.resolution_of_singularities Failed example: C.resolution_of_singularities(extend=True)[0] # long time (2 seconds) Expected: (Affine Plane Curve over Number Field in a0 with defining polynomial y^4  4*y^2 + 16 defined by 24*x^2*ss1^3 + 24*ss1^3 + (a0^3  8*a0), Affine Plane Curve over Number Field in a0 with defining polynomial y^4  4*y^2 + 16 defined by 24*s1^2*ss0 + (a0^3  8*a0)*ss0^2 + (6*a0^3)*s1, Affine Plane Curve over Number Field in a0 with defining polynomial y^4  4*y^2 + 16 defined by 8*y^2*s0^4 + (4*a0^3)*y*s0^3  32*s0^2 + (a0^3  8*a0)*y) Got: (Affine Plane Curve over Number Field in a0 with defining polynomial y^4  4*y^2 + 16 defined by 24*x^2*ss1^3 + 24*ss1^3 + (a0^3  8*a0), Affine Plane Curve over Number Field in a0 with defining polynomial y^4  4*y^2 + 16 defined by 24*s1^2*ss0 + (a0^3  8*a0)*ss0^2 + (6*a0^3)*s1, Affine Plane Curve over Number Field in a0 with defining polynomial y^4  4*y^2 + 16 defined by 8*y^2*s0^4 + (4*a0^3)*y*s0^3  32*s0^2 + (a0^3  8*a0)*y) ********************************************************************** 1 item had failures: 1 of 23 in sage.schemes.curves.affine_curve.AffineCurve.resolution_of_singularities [195 tests, 1 failure, 3.51 s]
I don't know enough about resolution of singularities to decide whether the latter output is correct, or not (notice some signs are changed...)
Last 10 new commits:
5d8c1d9  adding a patch fixing the i386 with AVX issue

0d27874  Fix int size bug in the interface between singular and givaro (on 32bit arch)

162c717  preparing upgrade to linbox1.4.2rc0 fflasffpack2.2.2rc0 and givaro 4.0.2rc0

20e86b3  update to the lastest releases

2fb5502  * Merging and fixing conflicts.

85ce544  Merge branch 'u/cpernet/givaro_fflasffpack_linbox' of git://trac.sagemath.org/sage into givaroupd

b7233c9  Fix coercion bug: raise a TypeError exception whenever an ArithmeticError is caught, while trying to reduce an element mod the characteristic.

cd30aec  Merge branch 'u/cpernet/givaro_fflasffpack_linbox' of git://trac.sagemath.org/sage into givaroupd

0efcdec  Merge branch 'public/singular4' into givaro 4.0.2 branch from #17635

457bd23  missing capital 'S' in Singular

comment:275 followup: ↓ 278 Changed 4 years ago by
Could we please not mix commits from different upgrades?
I don't see an immediate reason to base this ticket on #17635 either; they're IMHO better first reviewed independently.
comment:276 followup: ↓ 283 Changed 4 years ago by
LGTM at least in principle. I'm going to try over the next day or two to test how this works on Cygwin64.
comment:277 Changed 4 years ago by
Also I guess the milestone for this ticket should be changed? I don't know what to though.
comment:278 in reply to: ↑ 275 Changed 4 years ago by
 Milestone changed from sage7.3 to sage7.4
comment:279 followup: ↓ 280 Changed 4 years ago by
IMO, we should get this in as soon as we can to get as much testing as we can before it goes into a stable release.
comment:280 in reply to: ↑ 279 Changed 4 years ago by
Replying to tscrim:
IMO, we should get this in as soon as we can to get as much testing as we can before it goes into a stable release.
+1; I'm trying to get cygwin testing ASAP, but first I have to get cygwin builds working against the current develop
(since my cygwin branch is from a couple months' old develop
). Should be close to that, but I'd be fine if this is merged in the meantime, and I can open a ticket for any issue I discover later.
comment:281 Changed 4 years ago by
#17635 is now closed, so you need to make sure that it doesn't conflict with that ticket.
comment:282 Changed 4 years ago by
...although Volker closes tickets before fully testing them, so there is still a chance that it will be reopened.
comment:283 in reply to: ↑ 276 Changed 4 years ago by
Replying to embray:
LGTM at least in principle. I'm going to try over the next day or two to test how this works on Cygwin64.
Thx, I absolutely did nothing Cygwinrelated on that one.
comment:284 in reply to: ↑ 267 Changed 3 years ago by
Replying to leif:
Minor thing: All error messages in
spkginstall
should start with"Error
[:
]..."
.
Yes.
spkgsrc
could be beautified a bit as well (e.g. not unconditionally deletingsingular.git
, and recording what we checked out, error checking), besides thatcurl
is nonstandard... ;)
Sure but curl
was already used in the script anyway and that's only to make the tarball, not for endusers.
comment:285 Changed 3 years ago by
I agree that using curl
in spkgsrc
is not a big issue.
comment:286 Changed 3 years ago by
 Milestone changed from sage7.4 to sagepending
This cannot go into Sage until there is a proper tarball.
comment:287 Changed 3 years ago by
What's the point of this commentedout code? Just remove it.
# C++11 workaround https://trac.sagemath.org/ticket/20926 # Since https://trac.sagemath.org/ticket/17635 linbox passes a std=gnu++11 flag, so we no longer need to add it # if [ "$UNAME" = CYGWIN ]; then # Special case for Cygwin https://trac.sagemath.org/ticket/21185 # CXXFLAGS="$CXXFLAGS std=gnu++98" # else # CXXFLAGS="$CXXFLAGS std=c++98" #fi
comment:288 Changed 3 years ago by
 Description modified (diff)
comment:289 Changed 3 years ago by
 Description modified (diff)
comment:290 Changed 3 years ago by
In build/pkgs/singular/spkginstall
, if you use set e
, it is pointless to do manual error checking like
if [ $? ne 0 ]; then echo >&2 "Error applying '$patch'" return 1 fi
comment:291 Changed 3 years ago by
What's the point of this commentedout code? Just remove it.
# Extension('sage.libs.linbox.linbox', # sources = ['sage/libs/linbox/linbox.pyx']),
More generally, better remove all commentedout code unless there is a clear purpose.
comment:292 Changed 3 years ago by
In
cdef enum n_coeffType: n_unknown=0 n_Zp=1 #/**< \F{p < 2^31} */ n_Q=2 #/**< rational (GMP) numbers */ [...]
I would remove the values (like =0
) because that is only confusing. And please either properly format the comments there or remove them.
comment:293 Changed 3 years ago by
This is also silly:
if sizeof(long) > 4: # it seems Singular uses ints somewhere # internally, cf. #6051 (Sage) and #138 (Singular) if exponent <= 30: ringtype = n_Z2m else: ringtype = n_Znm else: if exponent <= 30: ringtype = n_Z2m else: ringtype = n_Znm
You can change code of the form
if condition: A else: A
to
A
comment:294 Changed 3 years ago by
I think this regression is not acceptable:
sage: P.<x,y,z> = PolynomialRing(QQ) sage: f= x^2 + 2*x*y + 1/2*z sage: f.is_squarefree() Traceback (most recent call last): ... NotImplementedError: is_squarefree of multivariate polynomials over rings is not implemented.
Asking whether a multivariate polynomial is squarefree seems like a very natural thing to do and not something you should just break.
comment:295 Changed 3 years ago by
Also, I am not so happy with the regression in exponent overflow but that's a less serious issue.
comment:296 Changed 3 years ago by
 Status changed from needs_review to needs_work
comment:297 Changed 3 years ago by
Sorry to say this, but the code is really ugly and certainly uglier than it was before. I see lots of annoying things, like unneeded comments, indentation not a multiple of 4 spaces, needlessly complicated code.
I think this requires somebody to go over all the code and clean it up.
comment:298 Changed 3 years ago by
Another example:
libSingularFound = False for extension in ["so", "dylib", "dll"]: lib = os.environ['SAGE_LOCAL']+"/lib/libSingular."+extension # libsingular renamed to libSingular if os.path.exists(lib): libSingularFound = True handle = dlopen(lib, RTLD_GLOBALRTLD_LAZY) if not handle: err = dlerror() if err: print(err) break if not libSingularFound : raise OSError("did not find libsingular file") if handle == NULL: dlerrormsg = dlerror() if dlerrormsg == NULL: dlerrormsg = "" raise ImportError("failed to dlopen {} ({})".format(lib, dlerrormsg))
The handle == NULL
cannot be reached since we would error out before. The old code is simpler and better:
for extension in ["so", "dylib", "dll"]: lib = os.environ['SAGE_LOCAL']+"/lib/libsingular."+extension if os.path.exists(lib): handle = dlopen(lib, RTLD_GLOBALRTLD_LAZY) if not handle: err = dlerror() if err: print(err) break if handle == NULL: raise ImportError("cannot load libSINGULAR library")
There was no reason to make the code more complicated, why was it done???
comment:299 Changed 3 years ago by
Another example in plural.pyx
:
cdef n_coeffType unknownRingtype = n_unknown
What's the point of this?
comment:300 Changed 3 years ago by
To be clear: I am very happy with the work done on this ticket, really. I just feel that it's not ready to merge yet. I also feel that not much effort was done to reuse the existing code, that code was rewritten without reason. That makes it hard to review because the diff is huge.
comment:301 Changed 3 years ago by
No worry Jeroen, that's exactly the point of making a proper review. To this point this ticket is just a heap of changes, hacks, commits by different people to get the new singular working and at least on my side I did not really look at what the other did, especially given the huge diff. I'll try to polish the points you mentioned this week.
comment:302 followup: ↓ 303 Changed 3 years ago by
At least we have something that works (modulo the is_squarefree
issue). That is a very important starting point.
comment:303 in reply to: ↑ 302 Changed 3 years ago by
Replying to jdemeyer:
At least we have something that works (modulo the
is_squarefree
issue). That is a very important starting point.
surely Singular 4.0.3 still has the squarefree test, so it's matter of digging up how it is implemented:
> ring r=0,(x,y),dp; > poly p=x^2+2*x*y+y^2; >> ring r=0,(x,y),dp; > poly p=x^2+2*x*y+y^2; > sqrfree(p); [1]: _[1]=1 _[2]=x+y [2]: 1,2
comment:304 Changed 3 years ago by
 Commit changed from 457bd233fc051f4ec6f8acf48dbf271af6d5bb46 to aab3eb19842d5f119ead49a4210a93b6bc14558c
comment:305 Changed 3 years ago by
 Description modified (diff)
 Milestone changed from sagepending to sage7.4
 Status changed from needs_work to needs_review
merged last commit from givaro upgrade ticket, uploaded the tarball.
comment:306 Changed 3 years ago by
 Description modified (diff)
 Milestone changed from sage7.4 to sagepending
comment:307 Changed 3 years ago by
oops, we pushed similar stuff at the same time...
comment:308 Changed 3 years ago by
I'm working on this, so pleas refrain taking Jeroen comments into account right now :)
comment:309 Changed 3 years ago by
 Branch changed from u/dimpase/singular4 to public/singular4
 Commit changed from aab3eb19842d5f119ead49a4210a93b6bc14558c to 0c7c6a9990ec261455f46fdefb010b2767c94c84
 Status changed from needs_review to needs_work
Took some Jeroen comments into account.
New commits:
95b768a  Modify error handling in Singular spkginstall.

b4dad30  Merge remotetracking branch 'trac/u/dimpase/singular4' into singular

9124efc  Purify enum for singular ring types.

c60efc2  Remove print debug statement in singular ring creation.

34960ee  Revert simpler old code to load libsingular.

0c7c6a9  Don't define useless variable.

comment:310 Changed 3 years ago by
 Commit changed from 0c7c6a9990ec261455f46fdefb010b2767c94c84 to cd00aa122d2081d05a87c65d5ff2bcd44f6505a9
Branch pushed to git repo; I updated commit sha1. New commits:
5f99779  Remove useless import.

1d4ba4e  Simplify verbosity for singular.

cd3cd2f  Remove print debug statement in polynomial.pyx.

a4d5418  Remove old comments in singular ring creation.

b307cd0  Simplify cimport from singular.

cd00aa1  Remove print debug statement in singular lib.

comment:311 Changed 3 years ago by
I'm done for at least a couple of hours.
So feel free to play with the current branch.
And pleas push any changes on the public/singular4
branch.
comment:312 followup: ↓ 313 Changed 3 years ago by
with the new tarball, it complains about absent aclocal1.13...
Something needs to be done with this. Normally speaking, you want to make tarballs using make dist
, after running ./configure
, and not by hand. I'll try to go this route now, and see if this works. By right, it should not require any autotools then (of course one can remove stuff from the tarball, after it's done).
Probably one just needs to run automake addmissing copy
before making tarball.
comment:313 in reply to: ↑ 312 Changed 3 years ago by
Replying to dimpase:
with the new tarball, it complains about absent aclocal1.13...
Something needs to be done with this. Normally speaking, you want to make tarballs using
make dist
, after running./configure
, and not by hand. I'll try to go this route now, and see if this works. By right, it should not require any autotools then (of course one can remove stuff from the tarball, after it's done).
Is this using the autotools package from #21047?
comment:314 followups: ↓ 318 ↓ 325 Changed 3 years ago by
it should not use any autotools while installing, at all. It's clearly something is not done properly while making tarball (by spkgsrc).
comment:315 followups: ↓ 321 ↓ 334 Changed 3 years ago by
There was no reason to make the code more complicated, why was it done???
I changed the library loading code to annoy everyone ( just kidding ;) )
Revert simpler old code to load Singular
I disagree.
Please read my arguments first and reply to the arguments (or disprove them). @Jeroen, If it was your code I changed and it hurts you. I'm sorry for that. Still, try to understand the arguments for the change and accept the change if you agree with the arguments.
The old (and current) failing message is
raise ImportError("cannot load libSINGULAR library")
In some situations this message gives no clue about the error caused a failing and even worse, is misleading:
The issue I ran into was while working on this upgrade, the loading of libSINGULAR failed, but I could for hours not figure out the cause. The library file was there,
I was able to open it manually. The error message did mislead my thoughts in the wrong direction. The issue was that Singular changed the naming of 'libsingular.so'
to 'libSingular.so'
(did you note the difference? ('s' vs 'S') and dlopen failed because sage tried to open a nonexisting file!
Also, if we reach
if handle == NULL
it is legitimate to print for _which_ file we failed to dlopen, because we try several different extensions ("so", "dylib", "dll"
) in a loop! Otherwise, by just looking at the error message we would have NO CLUE, for _which_ file dlopen
failed. And they may exist all three of them in the same place.
comment:316 followup: ↓ 320 Changed 3 years ago by
Purify enum for singular ring types.
If the comments are not wellformatted, incomplete or incorrect, it would be better to fix them rather than removing.
(Have fun to guess by the names what they stand for)
comment:317 followup: ↓ 319 Changed 3 years ago by
Remove print debug statement in singular lib
If I recall correctly, if Singular ring creation fails (with exception), there is a fallback creating a sage ring, (sage catches the exception, and no exception is printed)
So my question is, how a developer should properly and easily detect, that Singular ring creation ended with an exception?
comment:318 in reply to: ↑ 314 Changed 3 years ago by
Replying to dimpase:
it should not use any autotools while installing, at all. It's clearly something is not done properly while making tarball (by spkgsrc).
spkgsrc
just calls autoreconf
which is the usual way to generate configure
and Makefile.in
.
Not sure why running configure
or make
decides to rerun autotools
.
Maybe some timestamps issues after patching but we don't patch a lot, especially we do nothing to configure
and Makefile.in
, so...
And IIRC I had no trace of autotools
getting rerun on my setup, except when using SAGE_DEBUG=yes
(which was already strange enough).
comment:319 in reply to: ↑ 317 Changed 3 years ago by
Replying to jakobkroeker:
Remove print debug statement in singular lib
If I recall correctly, if Singular ring creation fails (with exception), there is a fallback creating a sage ring, (sage catches the exception, and no exception is printed)
So my question is, how a developer should properly and easily detect, that Singular ring creation ended with an exception?
It's fine to have print
statement during development, but I would say it should not be there in "production" code.
comment:320 in reply to: ↑ 316 ; followup: ↓ 324 Changed 3 years ago by
Replying to jakobkroeker:
Purify enum for singular ring types.
If the comments are not wellformatted, incomplete or incorrect, it would be better to fix them rather than removing.
(Have fun to guess by the names what they stand for)
Comments are available here: https://github.com/Singular/Sources/blob/spielwiese/libpolys/coeffs/coeffs.h
I took the easy solution of removing them form the Cython wrapper.
comment:321 in reply to: ↑ 315 ; followup: ↓ 322 Changed 3 years ago by
Replying to jakobkroeker:
There was no reason to make the code more complicated, why was it done???
I changed the library loading code to annoy everyone ( just kidding ;) )
Revert simpler old code to load Singular
I disagree.
Please read my arguments first and reply to the arguments (or disprove them). @Jeroen, If it was your code I changed and it hurts you. I'm sorry for that. Still, try to understand the arguments for the change and accept the change if you agree with the arguments.
The old (and current) failing message is
raise ImportError("cannot load libSINGULAR library")In some situations this message gives no clue about the error caused a failing and even worse, is misleading:
The issue I ran into was while working on this upgrade, the loading of libSINGULAR failed, but I could for hours not figure out the cause. The library file was there, I was able to open it manually. The error message did mislead my thoughts in the wrong direction. The issue was that Singular changed the naming of
'libsingular.so'
to'libSingular.so'
(did you note the difference? ('s' vs 'S') and dlopen failed because sage tried to open a nonexisting file!Also, if we reach
if handle == NULLit is legitimate to print for _which_ file we failed to dlopen, because we try several different extensions (
"so", "dylib", "dll"
) in a loop! Otherwise, by just looking at the error message we would have NO CLUE, for _which_ filedlopen
failed. And they may exist all three of them in the same place.
Ok, so maybe we should put back a more verbose error message.
comment:322 in reply to: ↑ 321 Changed 3 years ago by
Replying to jpflori:
Replying to jakobkroeker:
There was no reason to make the code more complicated, why was it done???
I changed the library loading code to annoy everyone ( just kidding ;) )
Revert simpler old code to load Singular
I disagree.
Please read my arguments first and reply to the arguments (or disprove them). @Jeroen, If it was your code I changed and it hurts you. I'm sorry for that. Still, try to understand the arguments for the change and accept the change if you agree with the arguments.
The old (and current) failing message is
raise ImportError("cannot load libSINGULAR library")In some situations this message gives no clue about the error caused a failing and even worse, is misleading:
The issue I ran into was while working on this upgrade, the loading of libSINGULAR failed, but I could for hours not figure out the cause. The library file was there, I was able to open it manually. The error message did mislead my thoughts in the wrong direction. The issue was that Singular changed the naming of
'libsingular.so'
to'libSingular.so'
(did you note the difference? ('s' vs 'S') and dlopen failed because sage tried to open a nonexisting file!Also, if we reach
if handle == NULLit is legitimate to print for _which_ file we failed to dlopen, because we try several different extensions (
"so", "dylib", "dll"
) in a loop! Otherwise, by just looking at the error message we would have NO CLUE, for _which_ filedlopen
failed. And they may exist all three of them in the same place.Ok, so maybe we should put back a more verbose error message.
And rather than trying three different extensions, just try the one corresponding to the underlying system.
comment:323 Changed 3 years ago by
It's fine to have print statement during development, but I would say it should not be there in "production" code.
Thats fine to remove the (outcommented) debug statements.
My question is just about if there is a better way to detect a failed singular ring creation than printouts?.
comment:324 in reply to: ↑ 320 Changed 3 years ago by
Replying to jpflori:
Replying to jakobkroeker:
Purify enum for singular ring types.
If the comments are not wellformatted, incomplete or incorrect, it would be better to fix them rather than removing.
Comments are available here: https://github.com/Singular/Sources/blob/spielwiese/libpolys/coeffs/coeffs.h
I took the easy solution of removing them form the Cython wrapper.
Sure, there are some comments in spielwiese/libpolys/coeffs/coeffs.h
,
but then the reader has to investigate (how did _you_ find the coeffs.h
?)
At least I would add in decl.pxd
before the line cdef enum n_coeffType:
something like
# see libpolys/coeffs/coeffs.h for reference
What do you think?
Not that I did a better job, but do you agree, that several comments in coeffs.h
related to the enum n_coeffType
are not really helpful? (=> we should improve them?)
comment:325 in reply to: ↑ 314 ; followup: ↓ 327 Changed 3 years ago by
Replying to dimpase:
it should not use any autotools while installing, at all. It's clearly something is not done properly while making tarball (by spkgsrc).
I give up, I don't understand quite what's going on. There is a missing
script in buildaux/
that is called on aclocal<VERSION>
, where <VERSION>
is the autotools version the tarball is made with.
But I don't know why it is there and how to disable it.
comment:326 followups: ↓ 329 ↓ 337 Changed 3 years ago by
And rather than trying three different extensions, just try the one corresponding to the underlying system.
Not quite sure, since I 'm not a Mac OS user, but it might be (or might be not) a problem on Mac OS. Are you familiar with Mac OS?
If I recall correctly, on Mac OS we might have both (".so" and ".dylib") or only one of (".so" and ".dylib")? Is that true??
comment:327 in reply to: ↑ 325 Changed 3 years ago by
Replying to dimpase:
Replying to dimpase:
it should not use any autotools while installing, at all. It's clearly something is not done properly while making tarball (by spkgsrc).
I give up, I don't understand quite what's going on. There is a
missing
script inbuildaux/
that is called onaclocal<VERSION>
, where<VERSION>
is the autotools version the tarball is made with. But I don't know why it is there and how to disable it.
We could ask Jeroen or JeanPierre for help to package recent Singular,
...or ask Hans Schoenemann(Singular head developer) for the Singular release timetable...
comment:328 Changed 3 years ago by
the following hack appears to stop that aclocal nonsense:
 a/build/pkgs/singular/spkginstall +++ b/build/pkgs/singular/spkginstall @@ 65,6 +65,9 @@ remove_old_version() rm rf "$SAGE_LOCAL/share/singular" } +touch configure.ac aclocal.m4 configure Makefile.am Makefile.in +touch */configure.ac */aclocal.m4 */configure */Makefile.am */Makefile.in + config() { # configure notes (dates from Singular 3.x, maybe outdated for 4.x):
will do more tests on it, before pushing this change...
comment:329 in reply to: ↑ 326 Changed 3 years ago by
Replying to jakobkroeker:
And rather than trying three different extensions, just try the one corresponding to the underlying system.
Not quite sure, since I 'm not a Mac OS user, but it might be (or might be not) a problem on Mac OS. Are you familiar with Mac OS?
If I recall correctly, on Mac OS we might have both (".so" and ".dylib") or only one of (".so" and ".dylib")? Is that true??
I can tell you if you confirm for me where I should look. When I look in /Applications/sage6.7/src/build/lib.macosx10.9x86_642.7/sage/libs/singular/
I find only singular.so
. Do you know anywhere else we might put a library? (And is it likely anything would have changed since 6.7?
comment:330 Changed 3 years ago by
 Description modified (diff)
I guess this one corresponds to the commit I usd:
I repackaged it, but now it also fails on my system complaining about aclocal1.15
...
comment:331 Changed 3 years ago by
And the upstream tarball is not autoreconfed in the xalloc
directory so SAGE_DEBUG=yes
won't work.
comment:332 Changed 3 years ago by
I haven't been following this discussion closely, but if I were to test out this branch now should I expect it to work (for some value of "work"at least build?)
comment:333 Changed 3 years ago by
On my system, aclocal
first gets called in resources
seemingly because it thinks that files generated by libtool
in ../m4/
are older than aclocal.m4
.
comment:334 in reply to: ↑ 315 Changed 3 years ago by
Replying to jakobkroeker:
Please read my arguments first and reply to the arguments (or disprove them).
If there are arguments for that in one of the 315 comments above, sorry that I missed them :)
@Jeroen, If it was your code I changed and it hurts you. I'm sorry for that.
I don't care whose code it was. Probably not mine.
The old (and current) failing message is
raise ImportError("cannot load libSINGULAR library")In some situations this message gives no clue about the error caused a failing and even worse, is misleading:
Improving an error message is very good, but I don't see why you needed to complicate the whole code structure for that.
Also, if we reach
if handle == NULL
It wasn't clear to me whether it was even possible to reach that line.
Anyway, this has been improved now (although the nowunused variables dlerrormsg
and libSingularFound
should still be removed).
comment:335 Changed 3 years ago by
Note that at minute precision these files have similar timestamps, altough at second precision aclocal.m4
is actually older...
comment:336 followup: ↓ 338 Changed 3 years ago by
on 32bit Ubuntu 14.04 I get, with the touch
hack above, the following error while building sagelib:
[193/459] Cythonizing sage/libs/singular/singular.pyx Error compiling Cython file:  ... from sage.libs.singular.decl cimport number, poly, ring, currRing from sage.libs.singular.decl cimport rChangeCurrRing, rCopy0, rComplete, rDelete, idInit from sage.libs.singular.decl cimport omAlloc0, omStrDup, omAlloc, omAlloc0Bin, sip_sring_bin, rnumber_bin from sage.libs.singular.decl cimport ringorder_dp, ringorder_Dp, ringorder_lp, ringorder_rp, ringorder_ds, ringorder_Ds, ringorder_ls, ringorder_M, ringorder_C, ringorder_wp, ringorder_Wp, ringorder_ws, ringorder_Ws, ringorder_a from sage.libs.singular.decl cimport p_Copy, prCopyR from sage.libs.singular.decl cimport n_unknown, n_Zp, n_Q, n_R, n_GF, n_long_R, n_algExt,n_transExt,n_long_C, n_Z, n_Zn, n_Znm, n_Z2m, n_CF ^  sage/libs/singular/ring.pyx:26:0: 'sage/libs/singular/decl/n_Zn.pxd' not found Error compiling Cython file:  ... from sage.libs.singular.decl cimport number, poly, ring, currRing from sage.libs.singular.decl cimport rChangeCurrRing, rCopy0, rComplete, rDelete, idInit from sage.libs.singular.decl cimport omAlloc0, omStrDup, omAlloc, omAlloc0Bin, sip_sring_bin, rnumber_bin from sage.libs.singular.decl cimport ringorder_dp, ringorder_Dp, ringorder_lp, ringorder_rp, ringorder_ds, ringorder_Ds, ringorder_ls, ringorder_M, ringorder_C, ringorder_wp, ringorder_Wp, ringorder_ws, ringorder_Ws, ringorder_a from sage.libs.singular.decl cimport p_Copy, prCopyR ...
I don't know whether it's related to touch
applied, or not.
I can install the requested aclocal version and see whether without touch
I get the same error...
comment:337 in reply to: ↑ 326 Changed 3 years ago by
If I recall correctly, on Mac OS we might have both (".so" and ".dylib") or only one of (".so" and ".dylib")? Is that true??
Both exist for a different purpose. On OS X:
.dylib
= dynamic library (needed for the usual case of linking libraries at buildtime).
.so
= loadable module (needed for runtime linking, for example Python extension modules).
On most other OSes, there is no difference between these.
comment:338 in reply to: ↑ 336 ; followup: ↓ 341 Changed 3 years ago by
Replying to dimpase:
on 32bit Ubuntu 14.04 I get, with the
touch
hack above, the following error while building sagelib:[193/459] Cythonizing sage/libs/singular/singular.pyx Error compiling Cython file:  ... from sage.libs.singular.decl cimport number, poly, ring, currRing from sage.libs.singular.decl cimport rChangeCurrRing, rCopy0, rComplete, rDelete, idInit from sage.libs.singular.decl cimport omAlloc0, omStrDup, omAlloc, omAlloc0Bin, sip_sring_bin, rnumber_bin from sage.libs.singular.decl cimport ringorder_dp, ringorder_Dp, ringorder_lp, ringorder_rp, ringorder_ds, ringorder_Ds, ringorder_ls, ringorder_M, ringorder_C, ringorder_wp, ringorder_Wp, ringorder_ws, ringorder_Ws, ringorder_a from sage.libs.singular.decl cimport p_Copy, prCopyR from sage.libs.singular.decl cimport n_unknown, n_Zp, n_Q, n_R, n_GF, n_long_R, n_algExt,n_transExt,n_long_C, n_Z, n_Zn, n_Znm, n_Z2m, n_CF ^  sage/libs/singular/ring.pyx:26:0: 'sage/libs/singular/decl/n_Zn.pxd' not found Error compiling Cython file:  ... from sage.libs.singular.decl cimport number, poly, ring, currRing from sage.libs.singular.decl cimport rChangeCurrRing, rCopy0, rComplete, rDelete, idInit from sage.libs.singular.decl cimport omAlloc0, omStrDup, omAlloc, omAlloc0Bin, sip_sring_bin, rnumber_bin from sage.libs.singular.decl cimport ringorder_dp, ringorder_Dp, ringorder_lp, ringorder_rp, ringorder_ds, ringorder_Ds, ringorder_ls, ringorder_M, ringorder_C, ringorder_wp, ringorder_Wp, ringorder_ws, ringorder_Ws, ringorder_a from sage.libs.singular.decl cimport p_Copy, prCopyR ...I don't know whether it's related to
touch
applied, or not.
Nope, I must have screwed up when removing the comments in the enumeration.
I can install the requested aclocal version and see whether without
touch
I get the same error...
Thats not necessary, we cannot get away with only a touch
anyway because of xalloc
.
I'll rerun autoreconf on my side to get proper timestamps in all folders...
comment:339 followup: ↓ 340 Changed 3 years ago by
 Commit changed from cd00aa122d2081d05a87c65d5ff2bcd44f6505a9 to d6dee3c4a86a864952d164b7efa00c128e2b83cc
Branch pushed to git repo; I updated commit sha1. New commits:
d6dee3c  Fix enum in singular ring types.

comment:340 in reply to: ↑ 339 ; followup: ↓ 343 Changed 3 years ago by
Replying to git:
Branch pushed to git repo; I updated commit sha1. New commits:
d6dee3c Fix enum in singular ring types.
OK, this helps to get further; the latest error on 32bit Ubuntu is
[149/444] gcc fnostrictaliasing g O2 DNDEBUG g fwrapv O3 Wall Wnounused fPIC I/home/dima/sage/dev/sage/local/include I/home/dima/sage/dev/sage/local/include/python2.7 I/home/dima/sage/dev/sage/local/lib/python2.7/sitepackages/numpy/core/include I/home/dima/sage/dev/sage/src I/home/dima/sage/dev/sage/src/sage/ext I/home/dima/sage/dev/sage/src/build/cythonized I/home/dima/sage/dev/sage/src/build/cythonized/sage/ext I/home/dima/sage/dev/sage/local/include/python2.7 c /home/dima/sage/dev/sage/src/build/cythonized/sage/libs/singular/ring.cpp o build/temp.linuxi6862.7/home/dima/sage/dev/sage/src/build/cythonized/sage/libs/singular/ring.o fnostrictaliasing fnotreecopyrename error: command 'gcc' failed with exit status 1 /home/dima/sage/dev/sage/src/build/cythonized/sage/libs/singular/polynomial.cpp: In function ‘long int __pyx_f_4sage_4libs_8singular_10polynomial_singular_polynomial_deg(polyrec*, polyrec*, ip_sring*)’: /home/dima/sage/dev/sage/src/build/cythonized/sage/libs/singular/polynomial.cpp:6028:7: warning: ‘__pyx_v_i’ may be used uninitialized in this function [Wmaybeuninitialized] int __pyx_v_i; ^ make[3]: *** [sage] Error 1
It might be that gcc is too old, it uses gcc version 4.8.4 (Ubuntu 4.8.42ubuntu1~14.04.3).
Should I rather build Sage's gcc?
comment:341 in reply to: ↑ 338 Changed 3 years ago by
Replying to jpflori:
I can install the requested aclocal version and see whether without
touch
I get the same error...Thats not necessary, we cannot get away with only a
touch
anyway because ofxalloc
. I'll rerun autoreconf on my side to get proper timestamps in all folders...
I do touch stuff in */
too, not only in top level.
(probably *
is an overkill, but it works).
Indeed, I first tried to touch the top level only, it went a bit further, entered resources/
, and complained from there instead.
comment:342 Changed 3 years ago by
One also needs to touch [*/]_config.h.in
in order to prevent autoheader` invokation...
I'll modify the spkgsrc
script to:
 use the upstream tarball,
 autoreconf in xalloc,
 touch all files.
comment:343 in reply to: ↑ 340 ; followup: ↓ 345 Changed 3 years ago by
Replying to dimpase:
OK, this helps to get further; the latest error on 32bit Ubuntu is
What's the error message? (it's not in the piece that you quoted)
comment:344 Changed 3 years ago by
 Commit changed from d6dee3c4a86a864952d164b7efa00c128e2b83cc to f8362a9c233f198d6d97dc22d16d09c47fd431c8
Branch pushed to git repo; I updated commit sha1. New commits:
f8362a9  Hopefully a singular tarball not invoking autostuff.

comment:345 in reply to: ↑ 343 Changed 3 years ago by
comment:346 Changed 3 years ago by
Ok reuploaded a new tarball (same address). Please test. Note that I finally did:
 use upstream 4.0.3p3
 autoreconf
 autoreconf in xalloc
 touch files
If I only autoreconfed xalloc, then libtool complained about different versions so I autoreconfed evrything then xalloc. (Yes, I know I could build my own autotools to get matching versions but thats more time consuming.)
comment:347 Changed 3 years ago by
the link to the new tarball is not working
comment:348 Changed 3 years ago by
 Description modified (diff)
comment:349 Changed 3 years ago by
 Description modified (diff)
Yeah, the update is non trivial, that's a reason to get #17184 (and so #16882) inbetween.