Opened 5 years ago

Last modified 3 years ago

#17254 closed enhancement

Upgrade to Singular-4-0-1 — at Version 84

Reported by: jdemeyer Owned by:
Priority: major Milestone: sage-7.5
Component: packages: standard Keywords:
Cc: jpflori, burcin, jakobkroeker, fbissey, malb, mkoeppe, vbraun, nthiery, bhutz, mmarco, gjorgenson Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: u/jakobkroeker/ticket.17254.squashed.new (Commits) Commit: 179ecd8b461135724979671c786301e515abb00c
Dependencies: Stopgaps:

Description (last modified by jakobkroeker)

Lots of stuff has changed in Singular 4. But now the attached branch is almost working.

Repackaged upstream tarball: https://www.dropbox.com/s/3io9k5srkcjrysr/singular-4.0.2.latest.tar.bz2?dl=0

Change History (84)

comment:1 Changed 5 years ago by jdemeyer

  • Branch set to u/jdemeyer/ticket/17254
  • Commit set to 2fcaeb5fadff9391624d03819bd9a4d405fdda72
  • Description modified (diff)

comment:2 follow-up: Changed 5 years ago by jpflori

Yeah, the update is non trivial, that's a reason to get #17184 (and so #16882) inbetween.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 5 years ago by jdemeyer

Replying to jpflori:

Yeah, the update is non trivial

I wonder if we even have a Sage developer who is familiar enough with Singular to do this (for the record: not me, I know nothing about Singular).

that's a reason to get #17184 (and so #16882) inbetween.

Of course, I'm not arguing with that.

comment:4 in reply to: ↑ 3 Changed 5 years ago by jpflori

  • Cc burcin added

Replying to jdemeyer:

Replying to jpflori:

Yeah, the update is non trivial

I wonder if we even have a Sage developer who is familiar enough with Singular to do this (for the record: not me, I know nothing about Singular).

Maybe Burcin would do... IIRC the update was proposed as a GSoC project.

comment:5 Changed 5 years ago by jakobkroeker

  • Cc jakobkroeker added

comment:6 Changed 5 years ago by jakobkroeker

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/singular-4.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 follow-up: Changed 5 years ago by jpflori

You have to put a tarball repackaged by the spkg-src 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 jpflori

(I'm not sure the checksums will the same as what Jeroen branch expect, run ./sage -sh sage-fix-pkg-checksums after you have downloaded the tarball to fix this.)

comment:9 Changed 5 years ago by jpflori

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 jdemeyer

  • Description modified (diff)

comment:11 follow-up: Changed 5 years ago by jakobkroeker

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 'singular-4.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 '--enable-optimizationflags --disable-debug --without-debug' ?

Also I disabled the currently broken '--enable-debugoutput' 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 Singular-team I'm out-of-favor because I constantly criticise their software and thus I will likely get little or no support.

Jakob

comment:12 Changed 5 years ago by jdemeyer

  • 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 jdemeyer

  • 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 jakobkroeker

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.uni-kl.de/agag/mitglieder/

comment:15 Changed 5 years ago by fbissey

  • Cc fbissey added

comment:16 in reply to: ↑ 7 Changed 5 years ago by jdemeyer

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 jdemeyer

Replying to jakobkroeker:

You have to correct the 'singular-4.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 jdemeyer

You should never run ./autogen.sh, that is supposed to be run at packaging-time, not build-time.

comment:19 Changed 5 years ago by git

  • Commit changed from 2fcaeb5fadff9391624d03819bd9a4d405fdda72 to 80a6b05a08e391fa9718e1f83df861c93e2e5967

Branch pushed to git repo; I updated commit sha1. New commits:

79c079fUpgrade to Singular-4-0-1
4c0bba3 singular 4.0.1 builds now, but sage does not due to changes in libsingular?
80a6b05Merge commit '4c0bba3' into ticket/17254

comment:20 Changed 5 years ago by jakobkroeker

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 packaging-time, not build-time.

I'm guilty ;-)

comment:21 Changed 5 years ago by jakobkroeker

singulars spkg-install:

the '--enable-debugoutput' configure flag for standalone factory needs now in additon '--enable-streamio --without-Singular'

comment:22 Changed 5 years ago by jakobkroeker

  • 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/sage-singular-4.0.1/local/lib/python2.7/site-packages/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 singular-cdefs.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/singular-4.0.1p1.tar.bz2 is required.

Any help appreciated.


New commits:

79c079fUpgrade to Singular-4-0-1
2fcaeb5Update Singular to 4.0.1
4c0bba3 singular 4.0.1 builds now, but sage does not due to changes in libsingular?
80a6b05Merge commit '4c0bba3' into ticket/17254
2ae243amessy fixes
ff2a9dcrequired changes for singular to build sage; should be fixed upstream
3b7877ehacking sage to build with Singular 4.0.1. needs more love for extension coefficient fields and a refactoring
f178dfcfixing nr2mMapZp call

comment:23 Changed 5 years ago by git

  • Commit changed from f178dfc5c45529826a973815b62ab5be2a7f7136 to 8ba17d8bc77cab7d3cffdda267dde132cbaff45e

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

8ba17d8messy fixes

comment:24 Changed 5 years ago by git

  • Commit changed from 8ba17d8bc77cab7d3cffdda267dde132cbaff45e to c2a21bd383e0f9d82dd409efbd4b48a4317be0c7

Branch pushed to git repo; I updated commit sha1. New commits:

2ae243amessy fixes
ff2a9dcrequired changes for singular to build sage; should be fixed upstream
3b7877ehacking sage to build with Singular 4.0.1. needs more love for extension coefficient fields and a refactoring
f178dfcfixing nr2mMapZp call
8e82387Merge branch 'u/jakobkroeker/jakobkroeker.ticket.17254' of git://trac.sagemath.org/sage into jakobkroeker.ticket.17254
c2a21bdfixed some ring creation

comment:25 Changed 5 years ago by jakobkroeker

  • Branch changed from u/jakobkroeker/ticket/17254 to trac/u/jakobkroeker/ticket.17254.squashed
  • Commit c2a21bd383e0f9d82dd409efbd4b48a4317be0c7 deleted

comment:26 Changed 5 years ago by jakobkroeker

  • Branch changed from trac/u/jakobkroeker/ticket.17254.squashed to u/jakobkroeker/ticket.17254.squashed
  • Commit set to 6384b9b8d22905e7dcc72b84df33effae9c8a517

New commits:

6384b9bUpgrade to Singular 4.0.1: incomplete, messy patch(first aproach)

comment:27 Changed 5 years ago by jakobkroeker

  • Description modified (diff)

comment:28 Changed 5 years ago by git

  • Commit changed from 6384b9b8d22905e7dcc72b84df33effae9c8a517 to 221c5d63e02d7f1d7fdc57cf6c819677553dd262

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

221c5d6Upgrade to Singular 4.0.1: incomplete, messy patch(first aproach)

comment:29 Changed 5 years ago by git

  • Commit changed from 221c5d63e02d7f1d7fdc57cf6c819677553dd262 to 1e847897b9fce54fa25f1b91dea78f9e225ad0c9

Branch pushed to git repo; I updated commit sha1. New commits:

1e84789one more renaming from libsingular to libSingular

comment:30 Changed 5 years ago by git

  • Commit changed from 1e847897b9fce54fa25f1b91dea78f9e225ad0c9 to 3a512cd7e08e21a4a4e66bfe9179290601717ba0

Branch pushed to git repo; I updated commit sha1. New commits:

3a512cdimproved error handling messages when loading Singular

comment:31 Changed 5 years ago by Snark

What is the status of this ticket? I see the branch is off 6.5.rc0, which is quite old already...

comment:32 follow-up: Changed 5 years ago by jakobkroeker

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 Singular-interface cleanup has to be done.

comment:33 in reply to: ↑ 32 Changed 5 years ago by john_perry

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 Singular-interface cleanup has to be done.

I'm at SD64.25 and am willing to work on this, but I'll need some hand-holding 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 follow-up: Changed 5 years ago by 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?

comment:35 follow-up: Changed 5 years ago by 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.

comment:36 in reply to: ↑ 35 Changed 5 years ago by john_perry

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 Sage-6.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 spkg-install: choose_patches ###
### Singular spkg-install: apply_patches ###
Applying /Applications/sage-6.7/local/var/tmp/sage/build/singular-4.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/2014-10/msg00359.html
|diff -druN src/latest/Singular/run.c src/latest/Singular/run.c
|--- latest/Singular/run.c	2014-11-19 14:06:05.000000000 +0100
|+++ latest/Singular/run.c	2015-01-16 09:32:45.771298300 +0100
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
1 out of 1 hunk ignored
Error applying '/Applications/sage-6.7/local/var/tmp/sage/build/singular-4.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/2014-10/msg00359.html
diff -druN src/latest/Singular/run.c src/latest/Singular/run.c
--- latest/Singular/run.c       2014-11-19 14:06:05.000000000 +0100
+++ latest/Singular/run.c       2015-01-16 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/singular-4.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 fbissey

Did you mean local/var/tmp/sage/build/singular-4.0.1p1.p0/src/Singular/ the latest bit should be stripped by the -p1 option to patch.

comment:38 Changed 5 years ago by john_perry

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 follow-up: Changed 5 years ago by fbissey

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       2014-11-19 14:06:05.000000000 +0100
+++ latest/Singular/run.c       2015-01-16 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 spkg-install 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/singular-4.0.1p1.p0/src/Singular/run.c OK?

comment:40 in reply to: ↑ 39 Changed 5 years ago by john_perry

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/singular-4.0.1p1.p0/src/Singular/run.c OK?

There is no such directory. I can get to local/var/tmp/sage/build/singular-4.0.1p1.p0/src/ but the only directories in there are latest and shared.

comment:41 Changed 5 years ago by fbissey

OK you seem to be right. The tarball has been packaged strangely and I am not sure I have the right spkg-install. 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 john_perry

How do I remove it? If I move it & make anew, the file reappears.

comment:43 Changed 5 years ago by fbissey

git rm build/pkgs/singular/patches/stricmp.patch?

comment:44 follow-up: Changed 5 years ago by john_perry

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 john_perry

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):

...
byte-compiling /Applications/sage-6.7/local/lib/python2.7/site-packages/sage_setup/find.py to find.pyc
byte-compiling /Applications/sage-6.7/local/lib/python2.7/site-packages/sage_setup/optional_extension.py to optional_extension.pyc
running install_egg_info
Removing /Applications/sage-6.7/local/lib/python2.7/site-packages/sage-6.8.beta0-py2.7.egg-info
Writing /Applications/sage-6.7/local/lib/python2.7/site-packages/sage-6.8.beta0-py2.7.egg-info

real	0m25.849s
user	0m11.855s
sys	0m3.847s
[ -f local/etc/sage-started.txt ] || local/bin/sage-starts
build/pipestatus "./sage --docbuild --no-pdf-links all html  2>&1" "tee -a logs/dochtml.log"
Deleting empty directory /Applications/sage-6.7/src/doc/common/static
Deleting empty directory /Applications/sage-6.7/src/doc/en/reference/combinat/static
Deleting empty directory /Applications/sage-6.7/src/doc/en/reference/combinat/templates
Deleting empty directory /Applications/sage-6.7/src/doc/en/reference/polynomial_rings/static
Deleting empty directory /Applications/sage-6.7/src/doc/en/reference/polynomial_rings/templates
Deleting empty directory /Applications/sage-6.7/src/doc/en/reference/repl/static
Deleting empty directory /Applications/sage-6.7/src/doc/en/reference/repl/templates
Deleting empty directory /Applications/sage-6.7/src/doc/en/reference/tensor_free_modules/static
Deleting empty directory /Applications/sage-6.7/src/doc/en/reference/tensor_free_modules/templates
Deleting empty directory /Applications/sage-6.7/src/doc/output/inventory/en/reference/combinat
Traceback (most recent call last):
  File "/Applications/sage-6.7/src/doc/common/builder.py", line 1619, in <module>
    import sage.all
  File "/Applications/sage-6.7/local/lib/python2.7/site-packages/sage/all.py", line 98, in <module>
    from sage.rings.all      import *
  File "/Applications/sage-6.7/local/lib/python2.7/site-packages/sage/rings/all.py", line 68, in <module>
    from number_field.all import *
  File "/Applications/sage-6.7/local/lib/python2.7/site-packages/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/sage-6.7/local/lib/python2.7/site-packages/sage/rings/polynomial/polynomial_ring_constructor.py", line 465, in PolynomialRing
    R = _single_variate(base_ring, name, sparse, implementation)
  File "/Applications/sage-6.7/local/lib/python2.7/site-packages/sage/rings/polynomial/polynomial_ring_constructor.py", line 539, in _single_variate
    R = m.PolynomialRing_integral_domain(base_ring, name, sparse, implementation)
  File "/Applications/sage-6.7/local/lib/python2.7/site-packages/sage/rings/polynomial/polynomial_ring.py", line 1544, in __init__
    sparse=sparse, element_class=element_class)
  File "/Applications/sage-6.7/local/lib/python2.7/site-packages/sage/rings/polynomial/polynomial_ring.py", line 1451, in __init__
    sparse=sparse, element_class=element_class, category=category)
  File "/Applications/sage-6.7/local/lib/python2.7/site-packages/sage/rings/polynomial/polynomial_ring.py", line 305, in __init__
    from sage.matrix.matrix_space import is_MatrixSpace
  File "/Applications/sage-6.7/local/lib/python2.7/site-packages/sage/matrix/matrix_space.py", line 57, in <module>
    import matrix_mpolynomial_dense
ImportError: dlopen(/Applications/sage-6.7/local/lib/python2.7/site-packages/sage/matrix/matrix_mpolynomial_dense.so, 2): Symbol not found: __Z17initCanonicalFormv
  Referenced from: /Applications/sage-6.7/local/lib/python2.7/site-packages/sage/matrix/matrix_mpolynomial_dense.so
  Expected in: flat namespace
 in /Applications/sage-6.7/local/lib/python2.7/site-packages/sage/matrix/matrix_mpolynomial_dense.so
make: *** [doc-html] Error 1

comment:46 Changed 5 years ago by fbissey

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 john_perry

I don't seem to have a local/include/factory at all...

comment:48 Changed 5 years ago by fbissey

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 john_perry

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 john_perry

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)
<ipython-input-2-59ae6a3e91c7> in <module>()
----> 1 I = sage.rings.ideal.Cyclic(R,Integer(7)).homogenize()

/Applications/sage-6.7/local/lib/python2.7/site-packages/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/sage-6.7/local/lib/python2.7/site-packages/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/sage-6.7/local/lib/python2.7/site-packages/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/sage-6.7/local/lib/python2.7/site-packages/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/sage-6.7/local/lib/python2.7/site-packages/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/sage-6.7/local/lib/python2.7/site-packages/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/sage-6.7/local/lib/python2.7/site-packages/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 --ticks-per-sec 1000' failed: The command was not found or was not executable: Singular.

comment:51 Changed 5 years ago by john_perry

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 john_perry

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 follow-up: Changed 5 years ago by john_perry

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 jdemeyer

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 fbissey

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/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.

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 ; follow-ups: Changed 5 years ago by john_perry

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 memory-related 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,

  1. I'm not sure whether omAlloc or one of the other omAlloc* commands is more appropriate (e.g., omAlloc0). Anyone know?
  2. I suppose this has to be freed somewhere... I know there's an obvious-sounding 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 64-bits. I've switched to jdemeyer's test (sizeof(long)>4). However, the code in the patch is exactly the same for both 32- and 64-bit. Is there a recommendation for what to do here? I'm not sufficiently familiar with this to know what to do.
Last edited 5 years ago by john_perry (previous) (diff)

comment:57 in reply to: ↑ 56 Changed 5 years ago by john_perry

Replying to john_perry:

Meanwhile, I discovered some memory-related 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)...

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 john_perry

  • Branch changed from u/jakobkroeker/ticket.17254.squashed to u/john_perry/ticket.17254.squashed

comment:59 Changed 5 years ago by john_perry

  • 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 sage-spkg 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:

bdb0851first attempt to resolve
1f4ebcbfix for _param and discrepancy between exponent and degree

comment:60 Changed 5 years ago by john_perry

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 git

  • Commit changed from 1f4ebcbf9e431a629ba1a899267dd9b42d4ed0cf to 9aa24564da611fd23d29dd9c5866cfef0be5b4f2

Branch pushed to git repo; I updated commit sha1. New commits:

9aa2456delete stricmp.patch

comment:62 in reply to: ↑ 56 Changed 5 years ago by jdemeyer

Replying to john_perry:

However, the code in the patch is exactly the same for both 32- and 64-bit. 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 jdemeyer

Replying to john_perry:

  • A few lines before the ones I cited above is the test for 64-bits. I've switched to jdemeyer's test (sizeof(long)>4). However, the code in the patch is exactly the same for both 32- and 64-bit. 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 jdemeyer

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 4 years ago by chapoton

  • 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:

ab68eb0Merge branch 'u/john_perry/ticket.17254.squashed' into 6.9.b0

comment:66 Changed 4 years ago by jakobkroeker

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/singular-cdefs.pxi

the file src/sage/libs/singular/singular-cdefs.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 4 years ago by jpflori

It seems I don't have access to boxen anymore...

comment:68 Changed 4 years ago by jpflori

And I don't have the p1 tarball Jeroen posted.

comment:69 Changed 4 years ago by fbissey

I have a tarball answering that description. Up on the lmona.de server....

http://www.lmona.de/files/sage/singular-4.0.1p1.tar.bz2

comment:70 Changed 4 years ago by jakobkroeker

  • Description modified (diff)

comment:71 Changed 4 years ago by jakobkroeker

  • Branch changed from public/ticket/17254 to u/jakobkroeker/ticket.17254.squashed
  • Commit changed from ab68eb0be8aec650b12e3c922ce282f5bd506490 to aa40c90711a6c50fe3b78fc0668370a9046f20a2

bumped to recent sage dvelopment version.

The build may fail with 'undefined ..' error again. Probably this can be fixed with ./sage -ba; if not, make distclean-bazooka should work...


New commits:

8e259d1merged with recent develop
aa40c90check for local tarball

comment:72 Changed 4 years ago by jakobkroeker

@chapoton

naive rebase.

except for the issue with src/sage/libs/singular/singular-cdefs.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 4 years ago by git

  • Commit changed from aa40c90711a6c50fe3b78fc0668370a9046f20a2 to 72ef9273b6d33a7771fd7c42a47ac5e430a81197

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

72ef927squashed singular upgrade changes in one commit

comment:74 Changed 4 years ago by git

  • Commit changed from 72ef9273b6d33a7771fd7c42a47ac5e430a81197 to 4adc75d8a3982aed7b9e66a9a567cfeb4c2fc81b

Branch pushed to git repo; I updated commit sha1. New commits:

4adc75dsquashed singular upgrade changes in one commit

comment:75 Changed 4 years ago by git

  • Commit changed from 4adc75d8a3982aed7b9e66a9a567cfeb4c2fc81b to f492ef2752f810b0fec487ac6bd7044c5d75827c

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

f492ef2squashed singular upgrade changes in one commit

comment:76 follow-up: Changed 4 years ago by jakobkroeker

@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 4 years ago by john_perry

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 4 years ago by jakobkroeker

  • Branch changed from u/jakobkroeker/ticket.17254.squashed to u/jakobkroeker/ticket.17254.squashed.new
  • Commit changed from f492ef2752f810b0fec487ac6bd7044c5d75827c to 90cefc5509dbe54f05781a82d76935319da3364a

New commits:

90cefc5bugfixes

comment:79 Changed 4 years ago by jakobkroeker

-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 4 years ago by git

  • Commit changed from 90cefc5509dbe54f05781a82d76935319da3364a to b4d049557c374f61a497d5c61d27ca13b2993281

Branch pushed to git repo; I updated commit sha1. New commits:

b4d0495removed printouts

comment:82 Changed 4 years ago by git

  • Commit changed from b4d049557c374f61a497d5c61d27ca13b2993281 to 5e14c77bd2222d901b33588f0f67bb694c3c1b48

Branch pushed to git repo; I updated commit sha1. New commits:

5e14c77updated to latest singular

comment:83 Changed 4 years ago by git

  • Commit changed from 5e14c77bd2222d901b33588f0f67bb694c3c1b48 to 179ecd8b461135724979671c786301e515abb00c

Branch pushed to git repo; I updated commit sha1. New commits:

179ecd8support building singular in debug mode

comment:84 Changed 4 years ago by jakobkroeker

  • Description modified (diff)
Note: See TracTickets for help on using tickets.