Minimal associated primes #3705
Conversation
|
@ederc : Could you have a look at the tests? I don't understand what's going wrong. But maybe |
|
Thanks for wrapping this @HechtiDerLachs ! |
|
Well, the tests fail because you try to apply |
|
The problem I meant occured in an earlier test run. Some call to But what you say about |
|
There was a missing caching of the |
|
is there anything holding this PR up @HechtiDerLachs ? |
|
The tests were still failing. I just had a look and it seems there is another bug in |
HechtiDerLachs
force-pushed
the
minimal_associated_primes
branch
from
9aa5177
to
2cd696e
Compare
|
@ederc : I'm sorry, but it looks like I accidentally overwrote your fixes to this branch when doing a rebase. Do you still have them somewhere? If yes, could you push them here again? Thx! |
|
I do not have this code anymore, we need to look again where the |
The Github UI shows |
|
@HechtiDerLachs Caching |
|
Thanks a lot @ederc and @benlorenz ! I was hoping that something like this was possible, but didn't know how. Unfortunately it seems that a lot of tests time out. Or something else goes wrong which I do not fully understand, yet. Edit: I checked two of the failing tests locally around the point where they were cancelled and they run just fine on my machine. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3705 +/- ##
==========================================
- Coverage 84.63% 79.61% -5.02%
==========================================
Files 600 615 +15
Lines 82622 86506 +3884
==========================================
- Hits 69927 68873 -1054
- Misses 12695 17633 +4938
|
|
I really can't make sense of the failing tests. Everything that I tried on my local machine about things where the CI gets stuck really goes through for me. And in some cases I can't even find the error messages. |
|
Its still under Hans aegis:
|
|
@hannes14 updated Singular_jll and just told me that Singular.jl should automatically use that. So I've now restarted the tests, let's see if it helps. |
|
I looked into the errors / warnings a bit, so far I have found the following: This is triggered from an atexit handler from the perl code which tries to clean up polymake objects. Not totally sure why this error doesn't appear during normal process exit, maybe because some other finalizers need to run first but these are not triggered correctly for these processes. This is also during process exit, maybe because multiple processes are trying to modify the same files at the same time (and this is not really a place where we can add a pidlock). All these processes are trying to save the same new auto-generated code that was probably triggered in the original process. This is in a macos job and I don't really know what exactly triggers this, but this could also be due to code running at exit without some julia exit handlers running before this, maybe related to this: Note: Many of the CI jobs also timed out, something got a lot slower here or got stuck somewhere? |
|
I ran the Oscar tests on this branch locally and after a while it also got stuck with many processes (22 processes including the main one), all of them seem to be sleeping / waiting. The main process (28895) is deep inside some singular code, called from One Process (1803) is in a wait call: One Process (1843) is in a futex_wait (called from some openmp exit handlers?): And finally there are further 19 processes which are waiting in a read like this: I can keep those processes alive for a while if there is anything I should check, they don't need much memory and all are idle anyway. |
|
The |
|
There are still exit handlers running which I think is problematic. But at least I don't see any stuck jobs that ran into a timeout. Many of the failing jobs don't have any logs for the |
|
@hannes14 so I guess that ball is in your court again ;-). Out of curiosity, how does Singular determine how many processes to fork? Does it take the number of cores and/or RAM into account? |
|
Singular uses sysconf(_SC_NPROCESSORS_ONLN) resp. sysconf(_SC_NPROCESSORS_CONF), |
| result = typeof(I)[] | ||
| # `unique!` does not work for lists of ideals. I don't know why, but for the moment we need the | ||
| # following workaround. | ||
| for p in filter!(!is_one, vcat([minimal_primes(j; algorithm, factor_generators=false) for j in J]...)) |
There was a problem hiding this comment.
| for p in filter!(!is_one, vcat([minimal_primes(j; algorithm, factor_generators=false) for j in J]...)) | |
| for p in filter!(!is_one, reduce(vcat, [minimal_primes(j; algorithm, factor_generators=false) for j in J])) |
An attempt to make the specialized functionality in Singular for zero dimensional ideals available.
This seemed to be useful for @simonbrandhorst in some examples, but now I can't even get the tests to terminate. Let's see what the CI says.
@wdecker : The documentation reads as if only
QQwas allowed as a coefficient ring. Do you remember whether this is the case? Because it seems to have run also over number fields.