Opened 5 years ago
Last modified 3 years ago
#17254 closed enhancement
Upgrade to Singular401 — at Version 70
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:  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  public/ticket/17254 (Commits)  Commit:  ab68eb0be8aec650b12e3c922ce282f5bd506490 
Dependencies:  Stopgaps: 
Description (last modified by )
Lots of stuff has changed in Singular 4. But now the attached branch is almost working.
Repackaged upstream tarball: http://www.lmona.de/files/sage/singular4.0.1p1.tar.bz2
Change History (70)
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 4 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 4 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 4 years ago by
It seems I don't have access to boxen anymore...
comment:68 Changed 4 years ago by
And I don't have the p1
tarball Jeroen posted.
comment:69 Changed 4 years ago by
I have a tarball answering that description. Up on the lmona.de server....
comment:70 Changed 4 years ago by
 Description modified (diff)
Yeah, the update is non trivial, that's a reason to get #17184 (and so #16882) inbetween.