-
-
Notifications
You must be signed in to change notification settings - Fork 482
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update ECL to 20.4.24 #22191
Comments
Branch: u/dimpase/ecl16.1.3 |
Commit: |
New commits:
|
This comment has been minimized.
This comment has been minimized.
comment:2
oops, somewhat wrong branch... testing anyway |
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
Author: Dima Pasechnik |
comment:6
The FPE problem on #18920 in comment 99 might be due to
while 16.1.2 happily returns
|
comment:7
with 6.1.3 there is apparently new |
comment:8
If it is an option for |
comment:9
There is already an option |
crash gdb log |
Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
|
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
Work Issues: sort out SIGFPE |
comment:14
this is a clean update branch for ECL 16.1.3 - needs work to sort out SIGFPE. |
comment:15
I'm pretty sure the change in behaviour comes from this check-in on ECL: https://gitlab.com/embeddable-common-lisp/ecl/commit/c2b2941768f39544f45f24e19a30081d316eeb71 Clearly, this code will be setting FPE generation flags in more places than before. Probably ECL doesn't go out of its way to reset FPE flags when ECL is exiting. So probably, after executing ECL code, it is now the case that (often?) the FPE flags are set the way ECL wants; not the way we want. So in addition to restoring the SIG handlers, we should probably sprinkle an appropriate amount of fesetenv calls around the ECL entry and exit wrappers. |
comment:249
Probably better to do https://gitlab.com/embeddable-common-lisp/ecl/-/issues/599#note_369508934 |
comment:250
Replying to @mkoeppe:
in progress now |
comment:251
The diff has a line |
comment:252
Replying to @pjbruin:
removed (needless to say it has no effect on functionality). we're still not done with this, due to Cygwin errors. I'll post details on them. |
comment:253
Replying to @dimpase:
Thanks. By the way, I just opened #30063 for upgrading Maxima (though I am not planning to work on this myself). |
comment:254
cygwin errors: pexpect chocked? something else?
the following resembles #8772 - apparently just pexpect choking under heavy load?
the following - already mentioned:
is not a big deal, just a floating point noise. Pexpext, again (?):
|
Attachment: ptest.log cygwin-standard run |
comment:255
see the attachment for complete ptest.log on Cygwin |
comment:256
As we don't see errors on embedded Maxima, but only on pexpect Maxima, I am inclined to say it is OK. |
comment:257
Maybe not "OK", but I think acceptable for the next beta. But the precise failure mode of the maxima pexpect interface should be investigated. This is clearly a regression from the older ECL. |
comment:258
Replying to @dimpase:
Yes, let's reuse that old ticket to investigate this more. |
comment:259
it could actually be an improvement - maxima runs faster, and on a heavily loaded host this leads to this mess. I will try another round of Cygwin tests, with tests not run in parallel. |
comment:260
It would be really good to simulate these tests without having to build all of Sage so that this could become part of the CI in spaghettisalat/ecl#1 |
comment:261
Replying to @dimpase:
tests running at https://github.com/dimpase/sage/actions/runs/157700338 |
comment:262
by the way, there are also a number of giac tests failing on Cygwin, with a very similar pexpect under heavy load (see attachment ptest results); so I really think there is nothing wrong with ECL on Cygwin per se, it's pexpect that plays up in this particular testing configuration. |
comment:263
Replying to @mkoeppe:
this can be rewritten as follows,
avoiding pexpect, I think. Indeed, it's 5 times faster:
|
comment:265
Replying to @dimpase:
and this ran out of time limit, so no interesting tests were performed. I think we should proceed with merging this ticket, anyway, and speed up Maxima things on #30071 |
Changed branch from public/packages/ecl20 to |
Changed commit from |
comment:268
Replying to @dimpase:
Sorry for the late reply, I've been busy. I agree that a bugfix release is needed. This will probably still take a bit though, I want to take a look at some other bugs first (https://gitlab.com/embeddable-common-lisp/ecl/-/issues/594 and https://gitlab.com/embeddable-common-lisp/ecl/-/issues/586) and then there's still tests to run. |
ECL-20.4.24 has been released (on 2020/04/24)
https://common-lisp.net/project/ecl/posts/ECL-20424-release.html
We should update, as it will resolve some Maxima bugs, and is essential for resolving other Maxima bugs.
Tarball: see checksums.ini [upstream_url].
(To configure Sage to download from the upstream URL, use
./configure --enable-download-from-upstream-url
)Upstream: Fixed upstream, but not in a stable release.
CC: @rwst @kiwifb @jdemeyer @EmmanuelCharpentier @jpflori @antonio-rojas @timokau @saraedum @infinity0 @slel @tobihan @embray @orlitzky
Component: packages: standard
Keywords: upgrade, ecl
Author: Marius Gerbershagen, Nils Bruin, Dima Pasechnik, Erik Bray
Branch:
f82c716
Reviewer: Dima Pasechnik, Nils Bruin, François Bissey, Emmanuel Charpentier, Matthias Koeppe
Issue created by migration from https://trac.sagemath.org/ticket/22191
The text was updated successfully, but these errors were encountered: